Wikipedia talk:WikiProject User scripts/Scripts/Formatter

The Formatter script automatically performs a number of common formatting operations.

To install, simply include this line in your monobook.js:

importScript('Wikipedia:WikiProject_User_scripts/Scripts/Formatter');

Optionally, for an automatic edit summary, also include this line:

importScript('Wikipedia:WikiProject_User_scripts/Scripts/Formatter/Auto Edit Summary');

Make sure you refresh (Ctrl+F5) after saving to complete the installation.

When using an edit box, you should have a tab called format. Click this to use Formatter. Make sure you preview all the changes before saving!

Functions

• Standardises and removes excess whitespace (tabs, spaces, carriage returns etc.)
  • Does not break special case of using a space at the start of the line for preformatted data
• Converts dashes, squared² and degree° symbols to Unicode characters, e.g. –, – or – to – (U+2013)
  • Makes sure not to break items which should not be converted to Unicode
• Fixes some common non-standard headings:
  • Standard headings have whitespace and capitalisation standardised, e.g. "== eXterNAL LiNKs ==" would become "==External links=="
  • "see also", "related topics", "related articles", "internal links" and "also see" sections become "See also"
  • "external links", "outside links", "web links" and "exterior links" sections become "External links"
  • Convert singular case to plural, e.g. "external link" becomes "External links"
  • "references", "reference", "sources" and "source" sections have whitespace, capitalisation, and pluralisation standardised as above
• Standardises appearances of categories, e.g. [[category : Test]] to [[Category:Test]]
• Fixes common syntax errors, e.g. converts <b>text</b> to '''text'''
• Removes external images and removes code from internal images
• Simplifies some links, e.g. [[Dog|dog]] to [[dog]] and [[Dog|dogs]] to [[dog]]s
• Loads as a tab on edit pages

Talk

Hi. I added this script to my monobook.js, but I'm not sure if it works (I don't see the difference). How is it supposed to work? Thanks. IronChris | (talk) 18:22, 14 May 2006 (UTC)

Ok I've found the "format" tab... But it doesn't work very well! It modifies some links so that they no longer send to the right article, etc. (see for example the effect on "[[United States]]" here). Am I the only one to have problems with it? IronChris | (talk) 18:31, 14 May 2006 (UTC)

It doesnt do that for me at all. Martin 19:38, 14 May 2006 (UTC)

I removed this :

//entities that should never be unicoded
 function noUnicodify(str) {
  str = str.replace(" & ", " & ");
  str = str.replace("&", "&").replace("<", "&lt;").replace(">", "&gt;").replace(""", "&quot;").replace("'", "&apos;");
  str = str.replace("−", "−").replace("×", "×");
  str = str.replace(" ", " ").replace(" ", " ").replace("­", "­");
  str = str.replace("′", "′");
  str = str.replace(/&(#0?9[13];)/, "&$1");
  str = str.replace(/&(#0?12[345];)/, "&$1");

  return str;
 }

from my monobook.js, that seems to have solved the problems I was having. Not sure what that function was for anyway. IronChris | (talk) 20:55, 14 May 2006 (UTC)

This happened because somebody put a nonbreaking space in between the works "United" and "States" to stop it being split by line wrap. IIRC, the web standard calls for nonbreaking spaces to be used via a specific code,   for precisely this sort of reason. The MediaWiki software by default converts all spaces in links to underscores, so this violation remained undiscovered until Formatter revealed it.

If you wanted the space in the link to be nonbreaking, the correct way would be to use the format [[United States|United States]], like so: United States. In the absence of being able to read users' minds, perhaps nonbreaking spaces in links should be converted to regular spaces? ― GrimRevenant 04:26, 22 February 2007 (UTC)

Documentation

Can we add a description of what this scipt does to the main page? It may be a good idea for those using it to have similar edit summary advertising this script, like [[Wikipedia:WikiProject User scripts/Scripts/Formatter|format]].-- _{Piotr Konieczny aka Prokonsul Piotrus  talk}  22:34, 25 July 2006 (UTC)

yes, that's a good idea. thanks Martin 08:26, 26 July 2006 (UTC)

I hope we do so, then - I am not familar enough with specific of what this script does to write a description.-- _{Piotr Konieczny aka Prokonsul Piotrus | talk}  19:51, 31 July 2006 (UTC)

Ahem. I've added a doc page at Wikipedia:WikiProject_User_scripts/Scripts/Formatter/doc and transcluded it at the start of the page, in a similar manner to the way template documentation works. This will let us keep discussion away from the documentation, while making the doc available. Hope it's useful like this! ― GrimRevenant 03:52, 22 February 2007 (UTC)

Problem with single brackets being wrongly doubled

I keep noticing a problem with this script: when there is a string enclosed in single brackets, like [foo], Formatter assumes from the lack of http: that it is supposed to be an internal link, and doubles the brackets. But http:// is not the only kind of resource; ftp links are valid as well as irc: or mail: links. In addition, even if there is a quote and one inserts an eluicidating comment like this: <nowiki>[they really meant this]</nowiki>, the brackets will be doubled regardless. There doesn't seem to be an easy way to make that regexp smart enough to deal with all these cases, so perhaps it should just be removed. --Gwern (contribs) 16:25, 20 October 2006 (UTC)

Agreed. Usualy a single bracket is intentional; what the formater should fix is a single bracket/two bracket error (when one bracket is missing from an ilink). -- _{Piotr Konieczny aka Prokonsul Piotrus | talk}  21:26, 5 December 2006 (UTC)

Fix level 1 headings

Other things to easily fix with the script: if the article has level 1 headings (=heading=), the formatter should add '=' to each heading. A slightly more complex: if a new user does not know how to make headings, they often create bolded text in a line, thus the formatter should convert lines containing only bold text into headings. Last but not least, another common newbie mistake is to start paragraphs without an extra line wiki needs; thus if the formatter could detect such 'unwikified' paras and instert an extra line, it would be another useful feature.-- _{Piotr Konieczny aka Prokonsul Piotrus | talk}  21:26, 5 December 2006 (UTC)

Recent change broken?

Did Ilmari's recent change break Formatter (and one's monobook.js in general) for anyone else? --Gwern (contribs) 19:45 14 January 2007 (GMT)

Yes, and for obvious reasons too. Sorry for the inconvenience. —Ilmari Karonen (talk) 21:13, 14 January 2007 (UTC)

Dash spacing

At present, this script incorrectly adds spaces around the dash in numerical ranges, e.g. changes "12–34" to "12 – 34". This goes against the Manual of Style.

All that needs to be done to correct this is make sure that the dash is not in a numerical range, i.e. include [^1-9] (or equivalent) at the start and end of the regexp. If I knew more about JavaScript I'd do it myself – actually, might test it in my own userscript if I get a chance and see how I go. ― GrimRevenant 00:52, 22 February 2007 (UTC)

To clarify, the issue was with en-dashes, and appears to be fixed with this change (links to my personal copy). I'm not sure what the procedure with updating the main script here is, but I'd certainly appreciate some feedback before I go ahead and change anything... cheers. ― GrimRevenant 01:30, 22 February 2007 (UTC)

It doesn't seem to be particularly maintained, so I'd go ahead if it compiles, runs, and seems to work. --Gwern (contribs) 03:52 22 February 2007 (GMT)

Cheers. Will do – hope it works as well for others as it does for me. ― GrimRevenant 04:04, 22 February 2007 (UTC)

Auto summary

Where to put this: document.editform.wpSummary.value = "Formatted using the [[Wikipedia talk:WikiProject User scripts/Scripts/Formatter|WikiProject Formatter]]"? -- Darkest Hour 21:04, 2 March 2007 (UTC)

• • Also, is it possible that it find <br> and replace it with <br />? -- Darkest Hour 21:25, 2 March 2007 (UTC)

I have to say, I rather dislike the autosummary. It seems to blindly wipe out all text already in there, which can be a serious annoyance: it obliterates my existing autosummary JS, and can overwrite manual summaries. This is a very bad change unless it can be smarter and only insert a summary if one is already there. --Gwern (contribs) 07:13 4 March 2007 (GMT)

I,ll do something about it, Darkest Hour 21:03, 5 March 2007 (UTC)

Done Darkest Hour 21:16, 5 March 2007 (UTC)

IPA

Can the scripts be made to ignore IPA symbols. I had a complaint the other day about my formatting IPA brackets [ɫ ɮ ʏ] = [[ɫ ɮ ʏ]]. I would like not to have another complaint like that one. Thanks for your thoughts on this matter, -- Darkest Hour 00:32, 8 March 2007 (UTC)

This is a generalization of my earlier complaint bout it blindly doubling single brackets. --Gwern (contribs) 02:09 8 March 2007 (GMT)

Useless edits?

I posted this on User talk:Darkest Hour, but he doesn't know why the script made a useless edit:

I'm curious about why you made this edit. First off, it's generally a bad idea to make edits that have no effect on the page, since they cause server load. Second, I wasn't aware that there was anything wrong with not placing a space between the asterisk and the bracket. Can you please point me to the guideline that supports your edit? Thank you. --NE2 23:17, 9 March 2007 (UTC)

Is this normal practice for the script? --NE2 23:37, 9 March 2007 (UTC)

The List guideline uses spaces in its format description. As regards normal practice for the script, I try not to make edits simply for minor markup changes; however, if I am editing the article for another reason, I will often run the Formatter and check what it picks up. Perhaps we should add an automatic "Show Changes" just to make sure people know what they are changing? (I've seen this in other scripts, and it is useful.) —GrimRevenant 11:07, 10 March 2007 (UTC)

It doesn't say that you need to use a space though. Also note that its whitespace in the heading disagrees with what this script does:

Standard headings have whitespace and capitalisation standardised, e.g. "== eXterNAL LiNKs ==" would become "==External links=="

--NE2 15:34, 10 March 2007 (UTC)

No, it doesn't say specifically that spaces are necessary. However, it does include them in the example we are meant to be following for lists. As for section headers, the examples in Help:Section use no spaces, which I would guess is the reason why the script does the same. Basically, it's formatting them according to the best authority we have on formatting minutiae. Again, this kind of stuff is definitely not worth solely editing an article over, but it doesn't hurt to do everything to standard if you're there anyway. —GrimRevenant 07:13, 13 March 2007 (UTC)

Just found Wikipedia:Manual of Style (headings), which says:

Spaces above and below headings are completely optional. Spaces between the == and the heading text are also optional (==Heading== vs == Heading ==). With the current Mediawiki software, these extra spaces will not affect the appearance of the heading in any way; the rendered page is identical. Multiple blank lines will add white space, however. It is much like the issue of whether to use one or two spaces after a full stop. It only affects the appearance of the text in the edit box, so use whichever approach best facilitates editing for you, but don't add or remove these spaces just as an edit style preference as it can cause large differences to appear in the edit history.

So really, the section heading part of the script needs either adjustment or removal, as it currently operates counter to the guideline. —GrimRevenant 07:35, 13 March 2007 (UTC)

I absolutely agree. Making useless style changes should be specifically discouraged. For example, was this edit really necessary? Just to add several thousand spaces between the asterisk and the italic markings in a list? Esn (talk) 07:38, 28 August 2008 (UTC)

Done

The adding of [[single]] to [single] is taken out until we can come up with a "smart" version that will know what to and what not to double bracket. Regards, -- Darkest Hour 17:06, 26 March 2007 (UTC)

"External link"

As per WP:EL (The header should be "External links" (plural) even if there is only a single link listed.) I think the following change should be made.

str = str.replace(/(== ?)(external link:?|web ?link:?|exterior link:?)( ?==)/gi, "$1External link$3");

↓

str = str.replace(/(== ?)(external link:?|web ?link:?|exterior link:?)( ?==)/gi, "$1External links$3");

—MrSomeone ^{( tlk • cntrb )} 02:56, 11 May 2007 (UTC)

I've worked the change in by merging with the previous regexp, like so:

 str = str.replace(/(== ?)(external links?:?|outside links?|web ?links?:?|exterior links?:?)( ?==)/gi, "$1External links$3");

In addition, I've made all References or Sources sections convert to the plural. I've tested on a private copy of the formatter script and it appears to be working fine. I'll commit the change and hopefully nothing will break. :) —GrimRevenant 16:27, 11 May 2007 (UTC)

Thanks, I'm not bold enough to make changes like this on pages being used by so many users ;) —MrSomeone ^{( tlk • cntrb )} 21:10, 11 May 2007 (UTC)

Bug

Note for clarity: User:Gerbrant copied this section from their talk page —GrimRevenant 09:43, 18 May 2007 (UTC)

See here (diff). Now I did use the formatter (diff) but the search and replace is what did this mess. Please fix thu bug. -- Darkest Hour 21:45, 7 March 2007 (UTC)

another example

diff —The preceding unsigned comment was added by Darkest Hour (talk • contribs) 21:52, 7 March 2007 (UTC).

Hm. My own formatter (while far from perfect) doesn't seem to cause quite as much mess. I'll take this to the wikiproject to ask whether this problem still exists and where people will have some familiarity with the code-base. Shinobu 19:52, 15 May 2007 (UTC)

Note: I'd fix it myself, but lately RL keeps me kind of busy. Shinobu 19:54, 15 May 2007 (UTC)

First: is this being caused by Formatter or by a search & replace tool? Your comment isn't quite clear to me. Second: seems like over-enthusiastic conversion of numerical codes to characters without checking that they're actually codes first (i.e. escaped by &;). I'll take a look and see what I can come up with. —GrimRevenant 07:45, 18 May 2007 (UTC)

While I realise this is some time later, I've run the formatter on the exact versions of both pages you reported problems with, and I can't duplicate any of these issues. If you hit this kind of issue, it can be worthwhile doing a force refresh (Ctrl+F5 in most browsers) to make sure you're using the latest version of any scripts you're using, before you cry "bug". Cheers. —GrimRevenant 07:58, 18 May 2007 (UTC)

Just checked the post dates against the edit history and realised that you had copied this here from your talk page. While there's nothing wrong with that, it would be better to have included some sort of notice, because it appears User:Darkest Hour's problem was with a different tool. —GrimRevenant 09:43, 18 May 2007 (UTC)

Actually, no. Darkest Hour used the Wikiproject Formatter, not my one, as you can see by looking at his edit summaries. So that's why I brought the issue here, because this is (was?) a bug in the formatter here, not in mine. And because I thought you would be more familiar with the code base than I am (after all I only use mine), I thought you could fix the problem (if any) faster than I could. Shinobu 14:55, 29 May 2007 (UTC)

From Darkest Hour's original post on your talk page (emphasis added): "Now I did use the formatter (diff) but the search and replace is what did this mess. Please fix thu bug." FWIW, I ran this formatter on the exact same page revisions Darkest Hour had problems with, and it worked flawlessly. I suspect we won't get to the bottom of this without more input from the original poster, especially regarding what exactly was searched and replaced... it's very easy to break something with a regex tool if it's used incorrectly, which I suspect may have been the case. Cheers. —GrimRevenant 04:36, 30 May 2007 (UTC)

@it's very easy to break something with a regex tool if it's used incorrectly: True. By the way, the only regex related tool I can find in his monobook.js is wikEd. And there is of course the possibility that he was using an old verions of any of these tools; in other words that the bug has already been fixed but that his cache needs purging. Let's wait for more details. Cheers, Shinobu 01:41, 4 June 2007 (UTC)

Tab location

I'm thinking about the location of the tab. Currently, it goes just before the edit tab, which seems strange. Perhaps it should go after the edit tab (and the "+" tab, if there is one)? One could do this by changing the getElementById statement near the end. Anyone else think this should be moved? — Tuvok[^T@lk/_{Improve me}] 21:28, 29 May 2007 (UTC)

Stub placement

It's a minor issue, but I just wanted to point out that this script removes the extra blank line between the stub template and the rest of the content. According to this, there should be two blank lines. I have no opinion which should be practiced (one or two blank lines), however this script and the guide should agree. -Rocket000 22:01, 2 September 2007 (UTC)

I generally remove superfluous newlines in all cases. But in the case of stubs the whole issue is pretty much moot, since a stub templates is by its nature a temporary notice. Shinobu 05:02, 4 November 2007 (UTC)

Formatting

When I click the format tab, it autosaves without giving a chance to preview. Is anyone else having this problem? Help! --Skylights76 (talk) 22:36, 12 April 2008 (UTC)

No problem here. --Gwern (contribs) 22:18 13 April 2008 (GMT)

Request to remove disruptive code

{{editprotected}} The script currently facilitates changing the headings "Related topics" and "Related articles" to "See also". The Wikipedia Manual of Style explicitly permits these as legitimate headings, and this script's removal of them is disruptive. Please stop this before it gets out of hand (it has to be manually reverted) by removing the following from the section of the page entitled "//Fix ==See also== and similar section common errors.":

"|related topics:?|related articles:?"

Many thanks, Skomorokh 00:55, 1 May 2008 (UTC)

Where in the MoS? I couldn't find it on a 30-second perusal. Happy‑melon 17:42, 1 May 2008 (UTC)

Sorry, I thought it would be a question of AGF; the specific reference is in WP:SEEALSO (a style guideline subpage of the MOS). It currently reads "A less common practice is to name the section "Related topics". Regards, Skomorokh 17:55, 1 May 2008 (UTC)

I do indeed assume that you would not be deliberately pushing a POV, but that doesn't mean that claims of support from the MoS shouldn't be unverified; honest mistakes and misinterpretations are just as common - my own knowledge of the MoS has just been found somewhat lacking in one instance. As it turns out, the phrase you referred to seems to have been removed by Dank55, so it seems that the issue is controversial. Per that, and meta:The Wrong Version,  Not done Happy‑melon 18:46, 4 May 2008 (UTC)

If you had read the talkpage, you would see that Dan neither Dan nor any other recent editors of the Layout support this "standardisation" of the wrong version. Someone made a mistake, no problem, bit why on earth exacerbate it? I came here because User:Iridescent, through no fault of her own, was performing unrelated cleanup tasks using AWB and inadvertently altered dozens of articles with "Related topics" sections to "See also". "See also" addresses the reader, in violation of encyclopedian tone. "Related articles" and "related topics" do not. I am restoring the edit protected request so that an administrator whose knowledge of the MoS is not lacking may address it. Thank you for your time, Skomorokh 21:01, 4 May 2008 (UTC)

I've reviewed the WP:SEEALSO section and it seems like the "Related topics" was removed as an acceptable alternative. In addition, I couldn't find "Related articles" in this MOS's recent history as being an alternative. I ran a database scan and found only 144 uses of "Related topics" (many of which were since converted to "See also"), and I noticed that you personally added a significant number of those. Also, only 72 articles used "Related articles". It seems to me that since it is now out of the MOS, this should be discussed further on that talk page before I go change the code on this script. So, I'm keeping the  Not done decision of Happy Melon, and opting for more discussion and consensus before making such a change. --CapitalR (talk) 01:06, 5 May 2008 (UTC)

I would really like to stop this bot from altering "related articles" and "related topics" headings to "see also". "See also" addresses the reader instead of adopting the detached tone of an encyclopaedia, and unlike "related x", does not describe the contents of the section. It's a pretty tall order to ask for consensus here to remove the code, as no-one else seems interesting in commenting or defending the code. WP:SEEALSO has long allowed for less common titles of such sections, as can be seen from reading that guideline's history. The burden of argument for including the code to replace names is on those favouring inclusion. Please comment. the skomorokh 17:20, 14 November 2008 (UTC)

I don't follow. If both are acceptable, then it should follow that one does not care if this script is modifying them, and one would endorse the status quo of the script modifying them. One only spends time and effort arguing that the status quo be changed if one actually prefers 'related articles/topics' to 'see also' (as you clearly do). --Gwern (contribs) 21:42 14 November 2008 (GMT)

I don't follow your not following ;) If both are acceptable, then scripts should not be programmed to replace one with the other, a task with no basis in policy and no consensus. the skomorokh 21:48, 14 November 2008 (UTC)

From the MoS: "In June 2005, the Arbitration Committee stated that when either of two styles is acceptable, it is inappropriate for an editor to change an article from one to the other without substantial reason."

"I clicked the 'format' button" is not a substantial reason, is it? the skomorokh 18:16, 15 November 2008 (UTC)

Removal of space character, e.g. changing [[Category:Denmark| ]] to [[Category:Denmark|]]

I love your script, but this is bad behaviour of the script. Categories calls like [[Category:Denmark| ]] put the article in the beginning of the category list, basically sorting it as a space character rather than an alphabetic character. This is intended behaviour, as it is always best to have the main article (if one exists) at the beginning of the category. Removing the space removes this functionality. So I have two requests. 1) Can you please fix the script not to behave in this manner; and 2) Can you tell me which line to change (and how) so that I can change it myself in my local version of your script? I copied the script to my own subpage so that I could do other edits as well, but I cannot figure out how to fix this one. Guess I'm not good enough at regular expressions.-Lilac Soul ^{(talk • contribs • count)} 07:10, 30 August 2008 (UTC)

Isn't the correct way of categorizing at the head [[Category:Denmark|*]]? --Gwern (contribs) 11:53 30 August 2008 (GMT)

That may be the correct way, but many, many articles use the space instead of the asterix. So it is still unfortunate that this script consistently produces erroneous results on such pages. Any input on how to fix this? -Lilac Soul ^{(talk • contribs • count)} 08:49, 15 September 2008 (UTC)

Using an asterisk causes the main page to appear under an asterisk heading. Using a space makes it the topmost entry. Thus, setting the main article to use [[Category:Zimbabwe| ]] and other articles of high priority to [[Category:Zimbabwe|*]] works very nicely. This may not be a wiki-wide policy, but it is an adopted style for articles within the scope of at least two WikiProjects in which I participate.

I chose Zimbabwe, because if the main article of Zimbabwe were asterisked, it would come at the end of all other articles categorized under an asterisk. That's not helpful for readers, who would expect the most important article to be listed first. The Zimbabwe articles could use this method:

• In "Zimbabwe" the category could be: [[Category:Zimbabwe| 0]] — most relevant
• "Portal:Zimbabwe" could use: [[Category:Zimbabwe| 1]] — second most relevant
• "Portal:Harare" (the capital) could use: [[Category:Zimbabwe| 2]] — third most relevant
• In "Economy of Zimbabwe" use an asterisk: [[Category:Zimbabwe|*]] — extremely relevant (use sparingly)
• In "Tiny Village in Zimbabwe" use the standard: [[Category:Zimbabwe]] — standard relevance (common)

That's not how Zimbabwe actually does it, and I've rarely seen the use of numbers or other punctuation to force a sort order like that, but the software permits it, so it should not be treated as an error by the script. Also, people can put spaces or any other punctuation in front of text to get all the same initial characters to sort together. Again, those are (usually) deliberate choices, not mistakes from what I've seen. --Willscrlt (→“¡¿Talk?!”) 03:43, 13 April 2009 (UTC)

Adding bad formatting to dashes

In addition to the inaccuracies with the see also find-and-replace function detailed above, the script seems to be adding spaces to emdashes in contravention of MOS:DASH. This means having to go back through an article dash by dash and correct it after clicking "format" before saving the page. I would appreciate it if someone with the privilege to do so would fix this, as it really mitigates the benefits of using the script. Skomorokh 15:11, 27 December 2008 (UTC) {{Editprotected}} In the "//dash — spacing" section, could an admin stop the script from inserting spaces on either side of emdashes? MOS:DASH instructs that "Em dashes should not be spaced". Thanks, Skomorokh 13:15, 30 December 2008 (UTC)

What exactly needs to be changed, code-wise? §hep • ¡Talk to me! 06:09, 8 January 2009 (UTC)

Not done for now:Please provide an exact copy of the code that needs to be inserted. The best method is to create a sandbox with the new code in it, so that the responding admin need only overwrite the protected page with the contents of the sandbox.--Aervanath talks like a mover, but not a shaker 18:55, 11 January 2009 (UTC)

I don't know the code, but had hoped that in the two weeks that Wikipedians were enthusiastically clicking "format" and violating the MoS someone with technical knowledge would have deigned to grace us with their presence. Skomorokh 19:03, 11 January 2009 (UTC)

Automated

Should it be necessarily automated? Can't it be like User:Cameltrader/Advisor.js asking you about errors one by one? It's a script so surely it can produce unwanted changes and just correcting them all in one go is a bit too much I think. -- Mentifisto 11:18, 31 January 2009 (UTC)

I'd love to have a configuration option that gives us a default choice. Or else two ways to activate the script, interactive or automatic. Usually I would prefer to fix errors interactively (sorry, I don't fully trust any automatic correcting tool), but if there are a lot of errors, then I'll just compare the differences after a fully-auto run. A really nice feature would be popup with checkboxes that lets us decided which fixes to make and whether we want interactive or full-auto. But that would require quite a bit more programming, I suppose. Sure would be nice, though! :-) --Willscrlt (→“¡¿Talk?!”) 03:47, 13 April 2009 (UTC)

Mark as historical?

Per the notice above, if it is replaced by a more frequently updated Wikipedia:AutoEd, why not mark it historical and retire? Also: what functions of the formatter are not supported by AutoEd? --_{Piotr Konieczny aka Prokonsul Piotrus| talk} 18:08, 27 April 2010 (UTC)