Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:PROPS)
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112
Centralized discussion
Proposals Discussions Recurring proposals

Note: inactive discussions, closed or not, should be archived.

RfC: Should deprecated/invalid/unsupported HTML tags be discouraged?[edit]

There has recently been some discussion on Wikipedia talk:Signatures#"Font" Deprecated? specifically about if "* Avoid deprecated markup such as the <font> tag." should be in the WP:SIGAPP section of our police on Wikipedia. Because of this disagreement, and based on a comment from that discussion by Redrose64, which I quote, the FONT element has been deprecated since at least HTML 4.01 (24 December 1999); in the present HTML 5 spec, it is marked as obsolete., I started doing some research as these elements have been deprecated nearly fifteen years now. Visiting the first thing I'm struck by is a big red box that says "Obsolete: This feature is obsolete. Although it may still work in some browsers, its use is discouraged since it could be removed at any time. Try to avoid using it.", reading just a little further down the page, there is a usage note that reads:

Do not use this element! Though once normalized in HTML 3.2, it was deprecated in HTML 4.01, at the same time as all elements related to styling only, then obsoleted in HTML5.

<basefont> has the same Do not use this element! warning. <acronym>, <big>, <dir>, <strike>, and <tt> also all have the big red box that says "Obsolete: This feature is obsolete. Although it may still work in some browsers, its use is discouraged since it could be removed at any time. Try to avoid using it." and even <center> has a big grey box that says "Deprecated: This feature has been removed from the Web. Though some browsers may still support it, it is in the process of being dropped. Do not use it in old or new projects. Pages or Web apps using it may break at any time." Heck, even w3schools has a big red warning that these tags are not supported or deprecated (example).
Should we technically discourage new instances of these HTML elements that are "in the process of being dropped" by major browsers? 02:43, 13 June 2014 (UTC)

Discussion (deprecated elements)[edit]

  • What counts as a new use? If I edit a section of an article that has some obsolete HTML markup in it, but I don't touch the passage with the obsolete markup, will it be treated as a new use? Jc3s5h (talk) 15:29, 13 June 2014 (UTC)
    • It will (or should) not per this proposal. Notifications for existing HTML that is obsolete is for another proposal if this one shows consensus. — {{U|Technical 13}} (etc) 15:51, 13 June 2014 (UTC)
  • Note that similarly, deprecated attributes (bgcolor specifically) are already failing to work on Wikipedia (Bugzilla: 66413). This should is a big red flag that we need to stop adding things that likely won't work much longer as they are already starting to be removed. — {{U|Technical 13}} (etc) 16:03, 13 June 2014 (UTC)
  • FYI: we should have an analogous of de:Wikipedia:WikiProjekt HTML5 here on English Wikipedia. It is useful to have quick examples of how to update the markup to not use deprecated HTML code. 16:39, 13 June 2014 (UTC)
  • The edit filter suggested below looks for deprecated elements in the new_html variable. I assume this is after templates are expanded. Which means if a template added to a page contains any deprecated elements, it will trigger the filter. So if we're going to use a filter, we need to make sure all templates are updated first. Mr.Z-man 03:53, 14 June 2014 (UTC)
    • The edit filter I used as an example is something I threw together in half an hour or so and didn't have time to thoroughly test. added_lines worked, but didn't seem to catch html that was injected by signatures (which I was using as the crème de la crème of templates), same with new_wikitext. I'm not sure what new_pst is suppose to be as it is new since last time I tried to create and editfilter and doesn't seem to be documented anywhere. I'm sure that someone more familiar with creating abuseFilters than I am (maybe Jackmcbarn) could adjust it to only catch new elements. There should likely be a second filter that only tags pages that are edited that contain existing bad code to make them easier for copyEditor HTML5 Nazis to find but not disrupt any other user. — {{U|Technical 13}} (etc) 05:06, 14 June 2014 (UTC)
      • While I'm not sure about this, if signatures work similar to templates in terms of how they're treated by the parser, it may be rather difficult to distinguish between them. Mr.Z-man 14:08, 14 June 2014 (UTC)
        • Perhaps a more feasible way to do this is right in core, but this RfC is more about whether or not we should do it or not and much less about how to do it. Quite frankly, these tags will eventually stop working altogether, and the question is whether or not the techie types want to just let it break and then see how long pages stay broken and don't work while everyone that knows a thing or two about html tries to fix them, or if we want to try and filter out as much of it now as we can so that when browsers stop supporting them (mobile browsers are likely first so that they can be as compact as possible to be able to use less memory and bandwidth) we barely even notice. I like the idea of not running my stress and anxiety through the roof trying to fix all the bad code myself... — {{U|Technical 13}} (etc) 15:27, 14 June 2014 (UTC)
  • I neither support nor oppose this, but do have a few comments:--LT910001 (talk) 10:04, 14 June 2014 (UTC)
    1. It's not ideal for WP to be supporting deprecated elements in HTML.
    2. I don't think the proposed technical solutions (bot or parsing edit attempts) are ideal
    3. The lack of clearly identified solutions may be contributing to consternation
    4. I suggest that a group of technically-minded users discuss how this might be achieved to find a more finessed solution, and then present that solution, which may have a greater chance of being accepted by the community.
    • There is a discussion above about <big> and replacing it with CSS. Obsolete tags are documented at Help:HTML in wikitext#Obsolete elements and replacement markup is discussed. For this case, <big> can be replaced with {{big}}, thus no raw HTML need be introduced into the content. We don't allow templates in signatures though. --  Gadget850 talk 10:48, 14 June 2014 (UTC)
      • For the record, Gadget850, templates are allowed as long as they are Substituted, but are discouraged. What we don't allow in signatures, that makes it a moot point, is anything that makes the text bigger. — {{U|Technical 13}} (etc) 13:46, 14 June 2014 (UTC)
    • LT910001, the only question in this proposal is if we should spend technically minded users' time to find a method to discourage users from using bad code. The edit filter is just one possible solution out of any possibility as posed in the question. — {{U|Technical 13}} (etc) 13:46, 14 June 2014 (UTC)
  • I agree that we should start removing deprecated elements, but I'm not sure if an edit filter is the best way to do so. Jackmcbarn (talk) 14:33, 14 June 2014 (UTC)
    • Then you support this proposal, which is "Should we technically discourage new instances of these HTML elements that are "in the process of being dropped" by major browsers?" Once we determine that, then "how" we do it should be figured out by the techies. Once that is accomplished, then the community can be presented with the options we considered, which one we think is the best, and if there are any objections to that method being implemented. — {{U|Technical 13}} (etc) 15:10, 14 June 2014 (UTC)
      • I'm not sure you can, by the way. For example, any bot that tries to move a signature with a &lg;font> tag to an archive page might then fail. If anything you need to start this process with logging deprecated tags/attributes. Amalthea 14:01, 16 June 2014 (UTC)
  • Lets look at specifics. As I documented at Help:HTML in wikitext#Obsolete elements, there are six obsolete elements that are whitelisted by Sanitizer.php: <big>, <center>, <font>, <rb> (we should just have this one removed from sanitizer), <strike> and <tt>. But there are also a number of attributes that are whitelisted but obsolete, such as abbr, axis, align, charoff, char and valign for <table>. Each of the obsolete elements have either a replacement tag or template. --  Gadget850 talk 16:20, 16 June 2014 (UTC)
    The <rb>...</rb> element was marked as obsolete in the 17 December 2012 revision of HTML5; since 29 April 2014 it's no longer obsolete. HTML5 is still in a fluid state, and we should not forbid the use of any element or attribute unless (i) it was never a formal part of HTML or (ii) browsers don't support it. An example is the bgcolor= attribute when used anywhere other than the <body> tag (see Wikipedia:Village pump (technical)/Archive 127#Background colour on mobile devices). But the <font>...</font> element, obsolete though it is, was a non-obsolete non-deprecated part of the formal spec, in HTML 3.2 --Redrose64 (talk) 20:31, 16 June 2014 (UTC)
  • We need to be kind to editors with deprecated code in their signatures. I think most such editors might appreciate being told about it outside the context of trying to make an edit to a talk page (where any delays might tangle up into edit conflicts, etc). Would it be possible for a bot to leave a message on the user talk page of any active (define: edited in last year?) editor whose signature includes deprecated elements (or is it just a case of the "<font>" which used to be recommended for colour change?), and leave a very clear, very polite, message, explaining that this is now old code which present or future browsers might not handle properly, and advising them to go to "Preferences" and change "this code" to "this new code"?
Or even - I have no idea how signatures are handled - would it be possible for the message on their user talk page to include: "Click this button to make the change to your signature automatically", giving a popup box showing "Your old signature looked like this: xyz; Your new signature looks like this: xyz. Click "OK" if all is well or "Cancel" to revert the change", with a "Help" button to click if they had to revert because something went wrong with the change? I'd guess that most editors would be happier to do this, at a time of their own choosing, rather than having to cope with negative information about their signature while wanting to concentrate something else (adding a message to a talk page). PamD 15:37, 20 June 2014 (UTC)
@PamD: If possible (probably so for most sigs), I think this would be great. --AmaryllisGardener talk 15:42, 20 June 2014 (UTC)
  • So, it appears that something is happening here in the browser world. I have an old BlackBerry that I recently updated the built in browser, and most of these deprecated and obsolete elements are just dropped. I have a screenshot of a simulation that I made of what I see on that device. I admit, it's an old device and an edge case at this point, but it strongly suggests that this change is coming.
Bad elements.png
We really need to do something to fix these issues. I've already started going through the interface messages, and all but a couple scripts that still have some <tt>s in them are cleaned up. I've also already worked through module, book, portal, and most of the other minor namespaces. I have been working on templates, categories, and file recently and once all of those are done, I'll start looking over draft and article spaces. There's only about 100K pages with obsolete and deprecated code on them. — {{U|Technical 13}} (etc) 16:08, 20 June 2014 (UTC)
Adam Cuerden and Nyttend ... --AmaryllisGardener talk 16:20, 20 June 2014 (UTC)
Surely, though, the CSS tags could cause exactly the same problems, given an old enough browser? They are more recent additions to HTML, after all. Adam Cuerden (talk) 17:06, 20 June 2014 (UTC)
To use CSS in a web page, you use the class= id= and style= attributes. These, together with the <span>...</span> element, were added to HTML with HTML 4.0 - way back in 1999, fifteen years ago (the <style>...</style> and <div>...</div> elements were included in HTML 3.2 but didn't provide full CSS capability). Support for these features had already been provided in some browsers, such as Internet Explorer 4 (1997). You'd need to still be using a browser as old as Internet Explorer 3 for CSS not to be supported. Wikipedia has trouble with IE 6 and isn't brilliant with IE 7, so anybody trying to view Wikipedia with IE 3 has difficulties more fundamental than the lack of CSS support. --Redrose64 (talk) 17:49, 20 June 2014 (UTC)
I found bug 24529 - Incrementally remove support for HTML elements removed from or deprecated in HTML5. The latest comment is "The Parsoid project is sponsoring a GSoC student to write "linttrap", a wikitext linter which can (hopefully) aid in the semi-automatic conversion of deprecated markup." --  Gadget850 talk 09:26, 25 June 2014 (UTC)
Note, there is currently a discussion on Wikitech-l about dropping support for Internet Explorer 6 and Internet Explorer 7. I don't see support for these being dropped, but the fact that the discussion is happening even should be a sign that those browsers are very very seldomly used with Wikipedia. Internet Explorer 5 and below are not considered supported by Mediawiki. So all people browsing Wikipedia ought to have at least some form of CSS support. Zell Faze (talk) 20:23, 3 July 2014 (UTC)
  • FYI... Currently, no article on enwiki has font tags or strike tags. Other Wikipedia sites have removed the big tags. We have been "fixing" the article when <font> or <strike> show up. This could be extended for other tags, but the <center> would take alot of work. Bgwhite (talk) 21:26, 26 June 2014 (UTC)
    • Not difficult at all, since the obsolete tags have equivalent templates or replacement tags:
      • <big> → {{big}}
      • <center> → {{center}}
      • <font> → {{font}}
      • <strike><s>
      • <tt><code>, <kbd> or <samp>
    • --  Gadget850 talk 17:48, 1 July 2014 (UTC)
      • Gadget850, manually it isn't difficult, just time consuming. It becomes difficult when automating as editors tend not to include closing tags, especially </center>. Bgwhite (talk) 21:54, 1 July 2014 (UTC)

Support (deprecated elements)[edit]

  1. Support as proposer. We can do this easily with a new edit filter like testwiki:Special:AbuseFilter/139, we would just have to link the table in the warning message and give the user a few more details to go on. I would be happy to work up a sandbox for this and post an {{Edit requested}} if there is consensus. — {{U|Technical 13}} (etc) 02:42, 13 June 2014 (UTC)
  2. Support—specifically I think three things should also be done. 1) A table should be created someplace, and linked from the appropriate policy/guideline, that lists what we should use instead of the unsupported tags. 2) A bot task should be created to replace the tags with the appropriate coding to ensure compliance going forward. 3) We need a way to assist people in updating their signatures ahead of time so that if an edit filter is put in place that we don't stop people from completely participating in discussions. Otherwise, I completely agree with the proposal. Imzadi 1979  03:13, 13 June 2014 (UTC)
    1. The warning table (like testwiki:MediaWiki:Abusefilter-warning-139) would hold all such relevant information.
    2. I worded this proposal with the intent of just reducing new errors from being introduced into the wiki, if there is support here, we can always come back and see if we should fix the existing errors after.
    3. The edit filter would warn with a table offering the acceptable alternatives and tag the edit if they choose to ignore the warning but would not prevent the obsolete code. This will give editors time to fix these things while still being able to edit.
    4. You do realize your post here includes both font and big tags which would be discouraged, right? — {{U|Technical 13}} (etc) 03:29, 13 June 2014 (UTC)
    Support with caveat. As phrased, I'm not sure who would disagree with adopting the most contemporary standard practices, but I would append "where possible" before the "Avoid..." line we discussed at SIGAPP. It's one thing to leave a friendly suggestion that one's signature can be better expressed another way, and it's another to point to a policy and look like the signature police. "Where possible" is what I'd suggest to mitigate that. czar  04:09, 13 June 2014 (UTC)
    • Just to be clear here czar, this is a proposal to add a sitewide edit filter to inform users that these elements shouldn't be used at all and isn't a signature specific issue. — {{U|Technical 13}} (etc) 04:46, 13 June 2014 (UTC)
    How can it be a proposal for a "sitewide edit filter" if it's not even mentioned in your proposal? czar  12:46, 13 June 2014 (UTC)
    When you read the question, it says "technically discourage" which means an edit filter or a core change to inform people that what they just added to the page is obsolete code and may break the page at any time and offer some possible alternatives so they can fix the issue for themselves. This will not prevent them from making the edit, but if they have bad code in their signature, it will nag them until they fix it. — {{U|Technical 13}} (etc) 13:31, 13 June 2014 (UTC)
  3. Support: I probably started off this whole discussion: I objected when an editor edited my signature on his talk page and then discovered that I'd got deprecated code in it and that he was entitled to fix it as a non-compliant signature. There was at that time the added complication that WP:SIG pointed to a tutorial which recommended the use of "<font>": this has since been updated, as a result of the discussion I started. It seems sensible that Wikipedia, in signatures and elsewhere, should abide by current standards. We don't know what technology our readers will use - perhaps especially those using innovative assistive technologies to compensate for a disability - and we not risk causing avoidable problems. PamD 13:08, 13 June 2014 (UTC)
  4. Support. This should have been done long ago! Ruslik_Zero 13:45, 13 June 2014 (UTC)
  5. Support per nom. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:05, 13 June 2014 (UTC)
  6. Support. The usage of these deprecated elements and attributes should only decrease. An edit filter would be a good way to ensure Wikipedia pages will get better markup over time and old code will stop proliferating in the articles (and from here to translated articles on other wikis). 16:44, 13 June 2014 (UTC)
  7. Support - Not much point "endorsing" the use of markups that either don't work or are obsolete, I'd imagine there's going to come a time when a certain mark up or 2 stops working for good .... and then we'll all be fucked, So as the balls rolling we may aswell do something about it. –Davey2010(talk) 16:48, 13 June 2014 (UTC)
  8. Support This pretty much says it all. --AmaryllisGardener talk 17:39, 13 June 2014 (UTC)
  9. Support Even if us non-techs had a reference list to refer to for these kind of mark-ups, this is way easier than checking regularly to see if the mark-up is still valid. The sooner the better as far as I am concerned. GenQuest "Talk to Me" 19:36, 13 June 2014 (UTC)
  10. Support per nom. APerson (talk!) 20:32, 13 June 2014 (UTC)
  11. Support logging and edit tagging only. In other words, don't bounce back editors with a warning message. The suggested solutions for this problem (which is still only a potential problem, not an active one) all seem to involve getting all Wikipedia users to learn an aspect of HTML. That is quite a high barrier to editing for many. Our first focus should be to clean up and monitor template usages (which could in theory lighten the load for less techie editors). Frankly, a better solution is required for a successful implementation regarding general edits in article space. SFB 14:26, 14 June 2014 (UTC)
    I wouldn't oppose a few months of a couple EditFilters that find all uses of deprecated code and only tags the edits (one would check the actual wikitext that the user entered and mark it that they entered deprecated code and the other would check a comparison of the new parsed text minus the old parsed text to catch only instances of templates or signatures that add the deprecated code) with deprecated elements so our templateFu elitists can fix as many of the templates as possible before we start warning/informing people they are adding bad text. We can also easily create a single notice template that can be added to Twinkle to inform people that they physically added deprecated elements to a page and how they can achieve the same result without that old code. In the cases of signatures, I already have the workings of a template in my userspace ({{User:Technical 13/Templates/badsig|existing sig|suggested replacement|code=yes}}) that would allow anyone with HTML/CSS-fu to easily post "your existing code is this" and "would you consider changing it to that which looks exactly the same and doesn't have deprecated elements" (even offers character counts to make it easy to see the 255 character limit). — {{U|Technical 13}} (etc) 18:35, 14 June 2014 (UTC)
  12. Support for content elements: articles, templates and the like. We still have a lot of templates that output invalid HTML. I wouldn't worry about user elements such as signatures. We will never fix old uses and new uses will get fixed if and when browsers stop supporting obsolete elements or break them. That is, if <font> is no longer supported, then users will be forced to figure out alternatives. --  Gadget850 talk 15:25, 14 June 2014 (UTC)
    See my above comment. :) — {{U|Technical 13}} (etc) 18:35, 14 June 2014 (UTC)
  13. Support; seems sensible. Ironholds (talk) 17:41, 14 June 2014 (UTC)
  14. Support, though I'd prefer a bot replacing old and new uses of obsolete HTML elements and attributes over an edit filter that prevents edits containing such HTML from being saved. I don't think replacing obsolete coding with correct coding can be considered "cosmetic" since it ensures that the code works (and will continue to work) correctly on all devices and browsers (addressing a comment below). SiBr4 (talk) 21:35, 14 June 2014 (UTC)
    • The point of the proposal is not to prevents edits containing such HTML from being saved but instead to warn a user, and then if they decide they want to save it anyways, to tag it as such. I've also mentioned in reply elsewhere, above, that a couple, three, six months of just tagging certain situations (for examples to find templates adding bad code, which I'm going to run a database scan for tonight to try and fix most of them preemptively) without the warnings would be a productive start. — {{U|Technical 13}} (etc) 22:33, 14 June 2014 (UTC)
    • I agree with this proposed approach, as long as any warnings or tags make it clear to the non-technically minded that they can still go ahead and save their edits with no immediate harm being done to the project. GenQuest "Talk to Me" 21:31, 15 June 2014 (UTC)
  15. Support: I was initially skeptical, but have been won over. Yes, we should technically discourage new uses of deprecated HTML. I am seeing in practice that editors will not be left in the lurch; mystified and without assistance. There are activists afoot who are capable and willing to help us sort it all out. So, better sooner than later. Fylbecatulous talk 20:51, 21 June 2014 (UTC)
  16. Qualified support per SFB. Λυδαcιτγ 03:47, 22 June 2014 (UTC)
  17. Support: While not needed right away, it will have to be done. Better to do it sooner. Bgwhite (talk) 21:22, 26 June 2014 (UTC)
  18. Support discouraging use provided that we allow the save to occur. Support logging any pages or edits found this way to a public place so editors interested in cleaning them up can do so. davidwr/(talk)/(contribs) 17:23, 1 July 2014 (UTC)
  19. Support. Jc86035 (talkcontributions) 12:22, 3 July 2014 (UTC)
  20. Support per the proposer. I subscribe to Wikitech-l. When this discussion is closed if someone pings me I can mention it on-list and see if anyone there is willing to try to come up with some technical solution to help us migrate already existing content away from deprecated tags. I'd also like to make them aware of the consensus of this discussion as I suspect it will inform discussion we have on-list in the future. Zell Faze (talk) 20:26, 3 July 2014 (UTC)
  21. Support. -- Magioladitis (talk) 13:24, 9 July 2014 (UTC)

Oppose (deprecated elements)[edit]

  1. No. Wikitext != HTML. Legoktm (talk) 05:34, 13 June 2014 (UTC)
    In the context of how MediaWiki handles these HTML tags, they are equal, as they are simply whitelisted HTML. Now that these tags are obsolete in HTML5 (which is the standard output now), they are invalid. To maintain obsolete tags and attributes as valid wiki markup, we would have to translate them to contemporary HTML/CSS. That makes issue a more fundamental one, where we need to investigate whether these tags are indeed regarded as 'official' wiki markup. Edokter (talk) — 09:52, 13 June 2014 (UTC)
    Can't HTMLtidy or something similar convert the font tags? –xenotalk 10:55, 13 June 2014 (UTC)
    Tidy is of no use; its purpose is to fix invalid html structure. There was once code in the html pre-processor to convert old html attributes to CSS, which was reverted due to some minor side effects. But that would be the proper place. Edokter (talk) — 11:58, 13 June 2014 (UTC)
    Plus, as Edokter wrote four months ago, not only is HTMLTidy no longer being maintained, it predates HTML 5. This means that it is probably unaware of all the HTML 5 obsolescences. Under HTML 4.01, the FONT element is merely deprecated, not obsolete, and deprecation of a feature doesn't mean "get rid of this because it no longer works" but "it is advised not to do it this way because it may stop working one day". There aren't actually that many obsolete features of HTML (that which were once part of the standard) that have ceased to be supported by browsers. <NEXTID> and <PLAINTEXT> are two of them; <FONT>...</FONT> isn't. --Redrose64 (talk) 12:47, 13 June 2014 (UTC)
    Right. Tidy isn't right solution. We know it sucks :). Doesn't mean we can't use something else. Legoktm (talk) 22:58, 13 June 2014 (UTC)
    • I'm currently not asking to convert existing uses, as I've seen that battle fought in the past at WP:BAG (IIRC) and apparently some think it falls under WP:COSMETICBOT. Once there is a consensus that we shouldn't be adding new uses because it will inevitably break the site, then we can discuss if the existing uses of these "bad" codes should be cleaned up, and how (I was thinking the best way would be to let the core developers do this since I'm sure that it is something that all wikis using this software would want/need). — {{U|Technical 13}} (etc) 12:12, 13 June 2014 (UTC)
  2. Not necessary and can apparently be done in the html pre-processor when it is. –xenotalk 12:51, 13 June 2014 (UTC)
    Your load times aren't bad enough already? If we fix the templates, and we fix our signatures (which are just templates stored in core inaccessible to anyone but the user), and we break the bad habits of users that are adding these code which could quit working at any time, then the processor isn't going to have to work as hard and it won't take as long for pages to save and load. Forcing the parser to fix out mistakes is a band-aid and a bad idea. — {{U|Technical 13}} (etc) 13:36, 13 June 2014 (UTC)
    The parser already does that... Don't worry about performance. Legoktm (talk) 22:58, 13 June 2014 (UTC)
    You seem to be overlooking the Wikipedia:Don't worry about performance#Editors still have a role to play clause. — {{U|Technical 13}} (etc) 02:21, 14 June 2014 (UTC)
    I am not sure anybody is going to make necessary changes to the preprocessor. One day one of the major browser will simply stop supporting them and the encyclopedia will become less readable. Ruslik_Zero 13:49, 13 June 2014 (UTC)
  3. Oppose, I say we should discourage it as a practice, but we should not be bothering 'plain users' with this kind of stuff. Especially since it's still used in templates etc all over the stuff. I'd be interested in having the edit filter gather some logs on how much new additions there are being made in general, and perhaps to issue warnings to sysops/template-editors for uses in Template namespace, but other than that, I don't think this is a problem worth pursuing, the preprocessor should be fixing it wherever possible in my view (other then <center> perhaps and a few other related special cases). —TheDJ (talkcontribs) 14:09, 13 June 2014 (UTC)
    How do you propose we discourage it as a practice without notifying the user that they are doing it? It has no effect on readers (unless FireFox 31 doesn't support these tags at all for example and all of the pages with these tags fail to render, then it would be a major problem that we weren't prepared for) other than a positive one as we won't be turning them away because things are broken. So, this only effects those that edit. I dare say that "most" 'plain users' aren't familiar with HTML elements and most likely won't be adding the bad tags to start with; even if there are a couple that do, a simple warning with a table that says "rst are obsolete, please use xyz instead" is a lot friendlier and efficient than them trying to figure out why their code isn't working because they read some tutorial someplace on SE or something and the latest version of IE or whatever browser they are using doesn't render that element anymore. — {{U|Technical 13}} (etc) 14:46, 13 June 2014 (UTC)
  4. No. How am I supposed to make something Huge in an editnotice, or a talk page message, or something like that? Maybe these old pieces of code aren't good for "formal" uses, but they get the job done simply and don't hurt anything in informal stuff like user talk messages and wikiproject pages. Perhaps its could be accompanied by something such as the suggested edit filter, so that HTML-savvy editors can come and clean up such uses in mainspace and templatespace, but we shouldn't have it add warnings after every use. Nyttend (talk) 01:04, 14 June 2014 (UTC)
    Can't you increase the font size with the span tag, Technical 13? --AmaryllisGardener talk 01:15, 14 June 2014 (UTC)
    @Nyttend: Aha, Like this! Code: <span style="font-size: 150%;">Like this!</span> --AmaryllisGardener talk 01:22, 14 June 2014 (UTC)
    Read Adam Cuerdon's note. Don't force me to ask for help leaving a simple message; you fail to remember that not all of us find span tags simple. Nyttend (talk) 01:50, 14 June 2014 (UTC)
    @Nyttend: I don't intend to be rude, but have you read my response to AC below? --AmaryllisGardener talk 02:00, 14 June 2014 (UTC)
    Yes. That's why I said "don't force me to ask for help", because people like me are getting along quite fine right now, and the only way you attempt to compensate for messing up my coding is an offer to help: all very fine for me, but it's just slightly more convenient for me to be able to code things by myself instead of asking you for help every time I'm attempting to write an editnotice for my talk page or emphasise something in a message — not to mention all the people who don't know about your offer. And what will you do about tons of uses of these tags in talk archives and old revisions of all sorts of pages? Nyttend (talk) 02:07, 14 June 2014 (UTC)
    Ah, I see what you mean now, I guess we'll just see if we have a choice in the future then. --AmaryllisGardener talk 02:09, 14 June 2014 (UTC)
    • I understand where you are coming from, but what is going to happen in three or six months or whenever <big> just stops working? All of those edit notices will no longer have big text where it was so important and everyone will be running around like a flock of headless chickens trying to clean up all the requests scattered across the dozen or two VPs and HDs and etc. For the record, what is wrong with {{Big}}, {{Larger}}, or any of the other {{Resize}} templates that we have just for this situation? — {{U|Technical 13}} (etc) 02:19, 14 June 2014 (UTC)
  5. Oppose Not everyone knows CSS, and we're basically setting up a situation whereby people will get confusing messages they won't have a hope in hell of correcting. Adam Cuerden (talk) 01:38, 14 June 2014 (UTC)
    @Adam Cuerden: I'll volunteer to help people replace their sigs, not just say "Your sig has deprecated tags, change it!". I'm sure others would follow suit also. After all, what's worse, someone having to change their sig and it not be as pretty and work in all browsers, or their sig be pretty in IE but be broken in Firefox and Chrome? Please correct me if I'm wrong. --AmaryllisGardener talk 01:45, 14 June 2014 (UTC)
    That's a bold claim. You're saying Firefox and Chrome don't support <big> and <font>?
    Well, I don't know about Google, but Mozilla says it may be removed from browsers at any time here. --AmaryllisGardener talk 02:03, 14 June 2014 (UTC)
    Could be, but probably won't be. And, even if true, does that require us to make a big sweeping change now, when we can't actually defend our position to the users affected? Adam Cuerden (talk) 02:08, 14 June 2014 (UTC)
    • It's not a question of if it will be removed, it is a question of how harsh of a result we want that removal to be. Do we want to start warning people now, while still allowing them to save (even with the bad code), and give them an opportunity to ask on literally any of the help desks, noticeboards, VPs, or other forums why they got that message and what they need to do to fix it; OR do we just want them to be removed from the MediaWiki core and then we'll kill our editor retention because people won't be able to edit with the bad code and get frustrated and just quit? Wouldn't it be better to let them use crap, so they can ask for help learning how to avoid the issue? — {{U|Technical 13}} (etc) 02:19, 14 June 2014 (UTC)
  6. This needs to be solved on the MediaWiki level, not in individual wikis. It affects all installations, there are many possible strategies; taking action locally is premature, and as proposed too intrusive.
    Personally I've always considered those tags/attributes wikitext features that just happen to be translated 1:1 to HTML. With the changes to HTML this mapping is no longer as simple as a whitelist, but many tags can and should certainly be converted by MediaWiki: wikitext should continue to be simple, and it makes sense to have simple presentational features in the language. Some, like the alignment attributes, may need to be deprectated, but this should still happen on the MediaWiki level where the affected pages can e.g. be categorized automatically.
    Either way, bothering our editors at this point is in my opinion way premature. Amalthea 11:40, 16 June 2014 (UTC)
    I entirely agree that this is an all project issue that needs to be resolved on the software level; however, I don't expect the developers to make it slow gentle transition. I would expect there would be some transition, I would expect it to one day just refuse to save the edit with an error like "Invalid HTML, please check your code and try again" and nothing more. Then I expect it to all just stop working... This proposal is local to this wiki in order to soften that and give all of our editors a chance to improve their habits before this happens. Wouldn't a softer transition be preferred? — {{U|Technical 13}} (etc) 12:13, 16 June 2014 (UTC)
    That question is a false dilemma on top of speculation, the softest transition is no change for the editors and MediaWiki handling it all. With lots of open bugzilla issues about it and no clear sense of where this is going we can only speculate, and I don't want to create work or distractions for editors until we know which way this is going. With that big a change we will have sufficient time to prepare, I see no reason for a hasty local decision here. Amalthea 13:55, 16 June 2014 (UTC)
  7. Opposed. The replacement aren't as easy for users to understand it seems. We abandoned formatting tables and later re-embraced. No sense in removing <big> while keeping <small>. It also very much bloats the wikitext. I wrote a table tags -> CSS convert and needed to limit the CSS expansion to keep some readability. About as stupid as the MiB vs MB issue. — Dispenser 21:42, 24 June 2014 (UTC)
    • How do you figure the replacements aren't as easy for users to understand? I must've offered help to a dozen or two users to get there signatures up-to-date in the last couple weeks, and I've not one that has objected to making the change (there is one pending that said they would "think about it", and if they choose not to accept my assistance, so-be-it, the ratio of better than 10:1 is fine by me). We haven't tried yet (which is what this RfC is suppose to facilitate, giving it a try. This has nothing to do with tables, which are very much still supported. I'm not sure why the W3 dropped big but kept small, that's a good question, but it's not the question here because content wrapped in small tags doesn't disappear from the page. Are you saying you think that pages that can't be read by some users on some browsers because these HTML elements are dropped is okay? I thought Wikipedia was suppose to be accessible and readable by everyone? — {{U|Technical 13}} (etc) 22:12, 24 June 2014 (UTC)
      • Are you saying you think that videos that can't be viewed by some users on some browsers because these codecs are unsupported is okay? I thought Wikipedia was suppose to be accessible and viewable by everyone? Couldn't resit the H.264 bait. W3C flip-flops and any decent web browser will render these tags for legacy compatibility. I'm alright to deprecating <font> in signatures and had report and conversion tool done years ago, but articles are another matter. — Dispenser 22:16, 30 June 2014 (UTC)
        • I'm saying there is a huge difference between people not being able to read the text on the page and not being able to see an accompanying video that is suppose to help support that text. Everyone should be able to read all the text, if they can't see the complimentary video, they still have a basic understanding of the text and they can still print out the text and make use of the "create a book" feature. — {{U|Technical 13}} (etc) 22:21, 30 June 2014 (UTC)
  8. Oppose. Obsolete tags should be interpreted by MediaWiki to produce correct modern HTML, but short tags that are easy to memorise are preferable to having editors write complicated span tags. Readable wikitext is important. —Kusma (t·c) 09:21, 27 June 2014 (UTC)
    • Kusma. 1) No need for span tags That is what {{font}} and other templates are for. You have a moot point. People already use the equally complicated font tag. 2) MediaWiki will be dropping HTMLTidy for Parsoid. Developers have already stated Parsoid will not convert all tags and will not convert tags in scenarios that HTMLTidy currently covers. For example, if you bring up the following text normally and in Visual Editor, it will be different: The brown fox jumps over lazy dog. Bgwhite (talk) 22:14, 1 July 2014 (UTC)
  9. Avoid the issue. The way to deal with these tags is at the back end, by having the software no longer parrot "<small>" to your browser, but to automatically convert it to "{{small}}" and then process it as such. They will simply be tags like <nowiki> instead of HTML then. Templates that are hardwired in this way can be indef-protected and exempted from rules against using templates in signatures and such. We shouldn't ask the users to change until we really need to, and we don't need to as long as someone is willing to arrange this to happen. Wnt (talk) 20:04, 8 July 2014 (UTC)
    • <small> is still valid. See the end of #Discussion (deprecated elements) for the five obsolete elements. The most complex to replace will be <font>. And then there are the obsolete attributes. --  Gadget850 talk 20:16, 8 July 2014 (UTC)
    Wayda minute. You're telling me that if this goes through, people will have to use {{big}} to make text big, but <small> will still be the standard for making it small? How the heck.......? Wnt (talk) 13:19, 9 July 2014 (UTC)
    • Nope, not what we are telling you at all. {{Small}} works for making text small just as {{Big}} works for making it big and people are welcome to go with that route for consistency if it makes it easier for them. — {{U|Technical 13}} (etc) 13:30, 9 July 2014 (UTC)
    I understand they can, but ... a person expects big and small tags to be symmetrical. They do the same thing, just different numbers. How can it possibly be that one is a problem we have to fix and the other is not? Wnt (talk) 17:48, 9 July 2014 (UTC)
    @Wnt: In HTML5, big is obsolete but small is not. Further, the traditional use of <small>...</small> (to reduce text size) has been replaced by the semantic meaning of "side comments such as small print. Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements." Thus, if it's not a side comment, it shouldn't be marked up with <small>...</small>. Ever since HTML 4 was raised to W3C Recommendation (December 1997) the preferred method for varying the size of text has been the font-size property in CSS. --Redrose64 (talk) 20:09, 9 July 2014 (UTC)
  10. Oppose Excessive bureaucracy. And because I am reminded of the idiotic move to ban <s>, based on what I discovered to be false claims that it was deprecated. And of stupid messages about missing archivedate (when the date could be found in the archiveurl field. And per Legoktm, ... I take Wnt's !vote immediately above to be an oppose..--{{U|Elvey}} (tc) 03:05, 9 July 2014 (UTC)
    @Elvey: The <s>...</s> element was deprecated in HTML 4.01 (and therefore in XHTML 1.0 also, which is what Wikipedia served until 17 September 2012), but is not deprecated in HTML 5 (which is what Wikipedia has served since 17 September 2012). --Redrose64 (talk) 13:00, 9 July 2014 (UTC)
    We shouldn't be leaving it up to the backend to fix our human error or laziness. — {{U|Technical 13}} (etc) 13:36, 9 July 2014 (UTC)
    User:Technical 13: Yes, we should be leaving these unharmful tags alone. It's only an error in the eyes of folks who deem deprecated tags an error (and weird badly written stuff, since unsupported tags should be ignored, IIRC) and they should chill out. Not to mention, again: Wikitext != HTML {{U|Elvey}} (tc)
    • Elvey, how do you construe the fact that in some browsers the sections contained in these tags are dropped instead of rendered breaking pages and making the wiki unreadable as unharmful? This comment confuses me. — {{U|Technical 13}} (etc) 17:50, 9 July 2014 (UTC)
    User:Redrose64: Irrelevant, even assuming that's all true. The idiotic ban on <s> was a clusterfuck; the banned usage was not in fact deprecated at the time it was banned; the deprecation was only ever partial. I wonder if the same applies to these tags; I haven't looked. {{U|Elvey}} (tc) 15:52, 9 July 2014 (UTC)

RFC: Naming of one and two digit numbers and years[edit]


For the longest time, it was necessary to link dates (e.g. January 1, 1970) so the wiki software could format them automatically. Because this was often used in mainspace, it was desirable to keep those links blue and relevant, so four-digit number articles, by convention, are about years (if it existed, the corresponding natural number would be at 1970 (number)). Since people write about lots of different time periods on Wikipedia, this also extends to three-, two- and one-digit numbers (but not five and larger, because we are (apparently) not the Long Now Foundation); 5 is the year 5, not the number 5.

However, this linking is no longer necessary. We had a nice long edit war over whether it should still happen, of course, but I digress. Currently, fewer than 50 pages link to 5,[1] while many more link to its numerical counterpart.[2] One wonders whether the year is truly the primary topic for the numeral.


Should we rename 1 through 99 to 1 AD through 99 AD (the precise naming scheme here is negotiable), then rename 1 (number) through 99 (number) to 1 through 99, and finally amend WP:NCNUM to account for the change?

NB: This intentionally only extends to one- and two-digit years, because larger numbers are less important while more recent years are more important. We may later revisit this discussion for three-digit years, but they are not part of this proposal. --NYKevin 21:51, 21 June 2014 (UTC)

Threaded Discussion[edit]

Shouldn't the relevant WikiProjects be informed of this RfC? As I have a particular opinion, I don't think I can create a neutral pointer, but at least Numbers, Mathematics, Years, and possibly its parent Time, should be notified. — Arthur Rubin (talk) 09:32, 27 June 2014 (UTC)

Done, also Disambiguation. So minimal as to raise no question of neutrality. PamD 14:24, 27 June 2014 (UTC)


  1. Support as proposer. --NYKevin 21:51, 21 June 2014 (UTC)
  2. Semi-support (first renaming only, i.e. years to include an indication such as AD or CE) – including up to three digits. But oppose renaming of articles on the numbers to remove the disambiguator: that would be unnecessary. However, I support that the freed up number like 5 become redirects to the correspond 5 (number) etc. On matters like this, a uniform convention should be the objective. —Quondum 23:49, 21 June 2014 (UTC)
  3. Support first half per Quondum. The current situation is truly awkward and needs to be solved. --cyclopiaspeak! 22:05, 22 June 2014 (UTC)
  4. The number is the primary topic at least for numbers up to a couple hundred. For consistency's sake, numbers and years should not be treated differently than chemical elements or countries: they occupy the un-disambiguated top spot only if they are the clear primary topic. —Kusma (t·c) 09:34, 27 June 2014 (UTC)
  5. Strong support I don't think of natural numbers below 1000 as years without an explicit AD/CE or BC/BCE. The number is clearly the primary topic until about then (rounding to an order of magnitude to be somewhat consistent and not have to decide on a case-by-case basis). Double sharp (talk) 10:38, 1 July 2014 (UTC)
  6. Strong support and people who will be upset will need to build a bridge and get over the AD/CE thing. Red Slash 05:46, 9 July 2014 (UTC)


  1. Oppose for consistency's sake. --AmaryllisGardener talk 23:37, 21 June 2014 (UTC)
  2. . A year is not a number. A year is a space of time conventionally designated by a number, conventionally written as an cardinal number, but actually meaning the first [etc] year of the particular era. DGG ( talk ) 05:47, 22 June 2014 (UTC)
  3. Oppose for now. To much drama creation potential. You first need to solve the harder problem of AD vs. CE. --Stephan Schulz (talk) 22:07, 22 June 2014 (UTC)
    We already have a precedent: 1 BC, 50 BC etc. Given this, do you anticipate it to be the source of a holdup? —Quondum 23:07, 22 June 2014 (UTC)
    AD vs CE provokes quite deep feelings on both sides. I wouldn't be surprised if the BC precedent were challenged if this proposal moves forward. And AD's meaning is potentially more offensive than BC. The present approach is an effective way to avoid a conundrum with no right answer. Add me to the Oppose count.--agr (talk) 01:44, 30 June 2014 (UTC)
  4. On balance, Oppose. I do see the point you're making, but we need to consider what people are likely to be thinking when they type a number into the search box. My suspicion is that people who are able to type '5' or '99' probably have an idea what these characters represent as numbers. When I look at 5 (number) I certainly see a lot of stuff, but it's of the form "the third prime number" or "there are five Exceptional Lie Groups" or "the atomic number of Boron", and so on. These sorts of things are certainly true, but I imagine they're more likely to be encountered as part of searches for prime number, Exceptional Lie Groups, Boron, and so on. The only interesting stuff that is not "accidentally" true of "5" is the history of the glyph. I might be persuadable, but I'm not persuaded so far. RomanSpa (talk) 06:39, 23 June 2014 (UTC)
    Of course you see mathematical information when you look up a mathematical object. How is that unhelpful or unreasonable? I just don't understand this objection. --NYKevin 01:51, 24 June 2014 (UTC)
    I think you've missed my point. Certainly the information that is presented is true, and, as you say, when you look up a mathematical object you see mathematical information. My point is that it's not interesting information. By this I mean that there is no particular reason why "the number of Exceptional Lie Groups" should be the same as "the third prime number" (or, at least, I'm not aware of such a claim). That the two have the same value is just coincidental, so the fact that they do is uninteresting. If it could be proven, knowing only the definition of a prime number, but not knowing that the third one is 5 that the number of exceptional Lie Groups should be the third member of the class of primes, then this would be an interesting result, but even then it would belong in the article on Lie Groups. What I'm trying to say is that most of the stuff about "5" is just a list of unrelated facts that only coincidentally apply to the same number. There's nothing deeper going on. RomanSpa (talk) 07:50, 1 July 2014 (UTC)
    This is an argument to not have articles on numbers at all. I don't believe it's germane to the discussion. If you'd like to do a mass-listing on AfD, feel free. --NYKevin 00:39, 2 July 2014 (UTC)
    It is indeed such an argument. However, we have the precedent that such pages exist, and I currently have no intention of proposing that such a precedent be reversed, as I don't believe that an AfD of the kind you suggest would succeed at the present time. I prefer to reserve my energies for matters of the possible, not the presently impossible. RomanSpa (talk) 04:56, 5 July 2014 (UTC)
  5. Oppose; the benefit from consistency seems to outweigh the benefit of a change (though both seem reasonably marginal). Andrew Gray (talk) 18:38, 23 June 2014 (UTC)
  6. Oppose; discussion on various WikiProjects (Numbers, Years, Mathematics) have lead to no consensus, I think the consistency argument dominates, but the newly created 2719 seems to have developed a local consensus that it shouldn't necessarily be done. — Arthur Rubin (talk) 03:38, 27 June 2014 (UTC)
  7. Oppose, for consistency sake. The benefit of the proposal is marginal (if any), while the drama potential and, more importantly, maintenance efforts (both initial and ongoing) are going to be high.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); June 27, 2014; 13:23 (UTC)
  8. Oppose: consistency is too useful here to overthrow, but we must be sure that every year page has a crystal-clear hatnote pointing directly to the number as well as the dab page. I think it's standard: I just picked 73 as a non-scientific sample and it looks fine. PamD 14:30, 27 June 2014 (UTC)
  9. Oppose. Consistency for me trumps other considerations. And anyway, this proposal would seem to exacerbate the whole AD versus CE business. Sławomir Biały (talk) 16:10, 27 June 2014 (UTC)
  10. Oppose; in this case, the consistency achieved by having years at all of the undisambiguated titles is more useful than not. Powers T 20:39, 29 June 2014 (UTC)
  11. Oppose at this time because AD vs. CE is not settled. Were that not an issue, I would support adding AD/CE/BC[E] to year articles. However, in any case I oppose dropping (number) from number articles. All bare numbers (1, 25, 308, 1904, 22545 etc.) should be dab pages given the vast possible selection of topics for each number, unless there really is only a single topic in which case the bare number should be a redirect (because they're cheap). This ensures consistency throughout the project, is simple, and avoids pointless conflicts over which article is the primary topic. Ivanvector (talk) 20:36, 4 July 2014 (UTC)
  12. Oppose Going through the archives, if they had decided to remove such they were correct. It is pretty obvious, anyone can understand the year. OccultZone (TalkContributionsLog) 10:19, 10 July 2014 (UTC)

Polls are evil[edit]

  1. I'm going to hang out here on the Group W bench and watch for a bit. — {{U|Technical 13}} (etc) 22:42, 21 June 2014 (UTC)


A lot of vertical navboxes are interfering with each other, infoboxes and lead images, making many articles extraordinarily messy. horizontal navboxes at the bottom of the articles are much better and don't interfere with readibility or layouts. I propose that we convert all vertical navboxes into horizontal ones. Aditya(talkcontribs) 18:18, 2 July 2014 (UTC)

Uh, no. This is bad policy. If you think a particular navbox should be converted, go ahead and do it. But some really need to be be available next to the information to which they pertain, and that means a vertical navbox that can be put to the right of the applicable section(s). VanIsaacWScont 20:20, 2 July 2014 (UTC)
Navoboxes are for articles, and generally not sections. They are almost never put to the right of the applicable section(s), rather they are put at the top or bottom of articles. And, what to do when it's not a particular navbox, but about tons of particular navboxes? Are expecting a concerned editor to discuss it out with dozens and dozens of wikiprojects one at a time? Aditya(talkcontribs) 03:27, 6 July 2014 (UTC)

Separate discussion from project tags[edit]

On most of our talk pages, there are two elements - a series of boxes about the article (Wikiprojects, deletion discussions, etc) and the actual discussion. I would suggest creating an "About:" namespace, which would contain the various project tags (in a few cases the talk FAQ would simply become the About page) and the Talk pages would be discussion only. Several advantages: First, if there is no discussion, discussion will be a red link, as opposed to now when the wikiproject tags turn it blue. Second, it will be easier to identify which pages should get wikiproject tags added (again, thanks to a red link). Third, it gives a place for edit notices or long FAQs for pages that need this sort of thing. This will also make implementing Flow a lot easier, since it would no longer need to accommodate these tags. I could see the Wikipedia template also having a Wikipedia About, while Template documentations could be moved to a Template About. Implementation could easily be done by a bot. Comments? Ego White Tray (talk) 05:12, 3 July 2014 (UTC)

I think WP:Flow already has a plan for this (a separate space at the top of the discussion page). In general, there would be some value to having metadata on a separate page (like categories: why should they be typed at the bottom of text, and disappear with any random blanking, instead of something inherently associated with the page itself?).
How would you handle FAQs and notices that people really need to see before engaging in any discussion? WhatamIdoing (talk) 05:41, 3 July 2014 (UTC)
I suggest you keep edit notices like we have them now, and also transclude them to the about page. Ego White Tray (talk) 14:30, 3 July 2014 (UTC)
As far as flow, I've seen the testbed at WP New Hampshire, and the tags look flaming ugly. Ego White Tray (talk) 14:32, 3 July 2014 (UTC)
It's not New Hampshire (U.S. state) but Hampshire (English county). --Redrose64 (talk) 15:18, 3 July 2014 (UTC)
Wait, a minute - you mean there is an old Hampshire? :) Ego White Tray (talk) 23:07, 3 July 2014 (UTC)
Yep. My brother lives there. WikiProject New Hampshire still has a sensible talk page, if a little quiet. --Redrose64 (talk) 23:26, 3 July 2014 (UTC)
WP:Edit notices appear when you start to edit a page. FAQs appear when you read a talk page. If you put the FAQs (e.g., "Q: Why does this page have the wrong name? A: Because it's actually the right name.") on "About:Example", how will people who are at "Talk:Example"see them? And if you're putting the FAQs on both, then aren't you defeating the goal, which you state as "Talk pages would be discussion only"? WhatamIdoing (talk) 18:32, 4 July 2014 (UTC)
Well, I'm proposing the big picture but we can discuss details. We certainly could transclude the edit notice to both the about and talk pages if there is agreement to do so. Nothing about my proposal prevents that. The point of the about is to tag articles and explain why the article is the way it is. If you want to put a simple link to the about page saying "read this first" on the talk page, I suppose we could do that. Again, this is details, not the overall concept. Ego White Tray (talk) 05:01, 5 July 2014 (UTC)
See also mw:Requests for comment/Associated namespaces. 18:44, 4 July 2014 (UTC)
Partly off topic comment: The more I see of Flow, the worse it seems to get. If that and Visual Editor become compulsory, I'll very likely be saying goodbye. Peridon (talk) 14:39, 7 July 2014 (UTC)

Proposed template contest[edit]

See User:Casliber/Template blitz and discuss on talk - all input appreciated. Cas Liber (talk · contribs) 22:33, 7 July 2014 (UTC)

Proposal to define aliases, e.g. UT for the "User talk" namespace[edit]

There was pretty strong consensus in this archived pump discussion but it was never officially closed or acted upon, just archived. Would an admin revive, act on and close it - I'd say there was consensus for the UT alias.

The proposal is/was to define "UT:" as an alias for the User talk namespace.

WP:Namespace warns:

In the search box, an alias is a real namespace, resulting in a search for the pagename in its namespace, but the "pseudo-namespace:pagename" search is in mainspace, not its pseudo-namespace. For example, the search "H:S" will not search Help.

I think that a number of the pseudo-namespaces should be 'upgraded' to true aliases. Users should be able to type T:quote into search, and get straight to Template:quote; likewise for T:fv, and the like. I'm not aware of any significant negative side effects of the existing 6 aliases. 4 of them probably only exist for historical reasons; they're essentially redirects, though I bet even the least used one is used many times. Why not add to WP and WT? UT seems like a great idea. U, not so much (User Talk pages are edited and accessed far, far more often than User pages.) I'd love to see T added; I'd use it a lot and 'Template' is a lot to type. I don't see much downside to converting the lot of them - T, CAT, MOS, P, and H. (And why not TT, CATT, MOST, PT, and HT?) Can a regular admin create an alias? --{{U|Elvey}} (tc) 00:00, 9 July 2014 (UTC)

That discussion was four years ago. Rather than close or act upon it now, it would be better to start afresh.
The existing shortcut prefixes WP: and WT: are not redirects - they are aliases, coded into the MediaWiki software to be exactly the same as the full namespaces Wikipedia: and Wikipedia talk. If I put a link here to [[WP:Village pump (proposals)]] it comes up black and bold (WP:Village pump (proposals)) because it's a direct link, and doesn't go through a redir. Of the various new aliases that you suggest:
  • T: does not currently have a defined meaning, but please see Wikipedia:Village pump (idea lab)#A template redirect? regarding that
  • tt: is an interlanguage link prefix for the Tatar Wikipedia, and since these prefixes are case-insensitive, TT: is as well
  • MOS is unsuitable for a namespace alias, since the true names of pages linked by the MOS: prefix are in more than one namespace - most are in Wikipedia: space, but many are in Help: space. An alias can only map to one true namespace.
  • MOST is unsuitable for a namespace alias for the same reason as MOS:
  • P: like T: is ambiguous - it could mean Project: or Portal: - compare Project:Trains with Portal:Trains.
  • PT: and HT: cannot be used for the same reason as TT: - pt: is the Portuguese Wikipedia, and ht: is the Haitian Wikipedia
The five others that you mention - CAT: CATT: H: U: UT: - are not currently defined; but as mentioned above, aliases are coded into the MediaWiki software, and altering that is not something that an admin can do - it would need a feature request at bugzilla:. --Redrose64 (talk) 10:50, 9 July 2014 (UTC)
Namespace aliases are configured through $wgNamespaceAliases. --  Gadget850 talk 17:39, 9 July 2014 (UTC)

Cleanup after Project Tagger[edit]

I have noticed that the now-abandoned Project Tagger tool (which could be used to add WikiProject templates to article talk pages) did the following things:

  • Added a "quality" parameter instead of a "class" parameter
  • Added new WikiProject templates above existing WPBIO templates (which is bad, right?)

See this edit as an example.

On the assumption that as a result of the use of this tool there are possibly hundreds of article talkpages with misplaced/malformed WikiProject templates (this user alone used the tool to tag dozens of talk pages, many/most of which are still the current revision - no reflection on that user, by the way; I assume they were just using the tool in good faith), would it be worthwhile (getting a bot to) go through and change all the "quality="s to "class=", and move any existing WPBIO template to the top?

Or would that not be worthwhile, because:

  • WikiProject Tagger only added an empty "quality" parameter (i.e. "quality=") and presumably if/when someone goes to assess the article, they will change "quality=" to "class=xxx", and/or
  • there are already bots which go around moving WPBIO templates to the top (is that true?)

Thanks. DH85868993 (talk) 03:07, 10 July 2014 (UTC)

@DH85868993: Moving WPBIO above other WikiProject templates is important when |living=yes to ensure the BLP box appears at the top of the talk page. It's not so important if the WikiProject templates are within {{WikiProjectBannerShell}}. I'm now running my BattyBot against Magiciandude's edits to see where {{WikiProjectBannerShell}} can be added, and changing |quality= to |class= in the process (e.g. See the revised Talk:Roberto Torres). Magioladitis and Josve05a have been doing a lot of cleanup on talk pages, so maybe they have some input too. GoingBatty (talk) 04:34, July 10, 2014 (UTC)
Thanks, @GoingBatty:. This list indicates other possible users of the tool, although it's not a complete list (note that Magiciandude is not listed). I think Project Tagger always includes "Project Tagger" in the edit summary, so that might be a way to find other edits made using the tool? DH85868993 (talk) 04:40, 10 July 2014 (UTC)