Jump to content

Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Superzoulou (talk | contribs) at 11:01, 22 July 2014 (→‎Support (Persondata removal): ced vote to qualified support in case that was not really clear rm mention of a bot as Magnus Manske is already doing the import). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


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

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is currently no consensus to force people to not use any of the deprecated HTML tags, in either articles or signitures. However, there does seem to be support for an edit filter, or other technical measures, to log (not warn) users when these tags are used, to allow editors to give users some advide about why they should be used, and what the alternative is. The opposes mainly seem to centre around the fact it is the system dev's problem, and not induvidual Wiki's. However, if the devs suddenly decide to no longer support these tags, and we are caught unawares, all sorts of havoc may reign supreme. Therefore, I feel the overall consensus of this thread is to take small steps (eg. advising people to change sigs), in order to start to prepare for the transition. --Mdann52talk to me! 08:05, 17 July 2014 (UTC)[reply]
Background
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 https://developer.mozilla.org/en-US/docs/Web/HTML/Element/font 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).
Question
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)

  • 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)[reply]
  • Note that similarly, deprecated attributes (bgcolor specifically) are already failing to work on Wikipedia (Template:Bugzilla). 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}} (e • t • c) 16:03, 13 June 2014 (UTC)[reply]
  • 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. Helder.wiki 16:39, 13 June 2014 (UTC)[reply]
  • 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)[reply]
    • 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}} (e • t • c) 05:06, 14 June 2014 (UTC)[reply]
      • 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)[reply]
        • 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}} (e • t • c) 15:27, 14 June 2014 (UTC)[reply]
  • I neither support nor oppose this, but do have a few comments:--LT910001 (talk) 10:04, 14 June 2014 (UTC)[reply]
    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.
  • 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)[reply]
    • 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}} (e • t • c) 15:10, 14 June 2014 (UTC)[reply]
      • I'm not sure you can, by the way. For example, any bot that tries to move a signature with a ≶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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
@PamD: If possible (probably so for most sigs), I think this would be great. --AmaryllisGardener talk 15:42, 20 June 2014 (UTC)[reply]
  • 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.
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}} (e • t • c) 16:08, 20 June 2014 (UTC)[reply]
Adam Cuerden and Nyttend ... --AmaryllisGardener talk 16:20, 20 June 2014 (UTC)[reply]
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)[reply]
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)[reply]
I found Template:Bug - 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)[reply]
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)[reply]

Support (deprecated elements)

  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}} (e • t • c) 02:42, 13 June 2014 (UTC)[reply]
  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)[reply]
    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}} (e • t • c) 03:29, 13 June 2014 (UTC)[reply]
    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)[reply]
    • 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}} (e • t • c) 04:46, 13 June 2014 (UTC)[reply]
    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)[reply]
    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}} (e • t • c) 13:31, 13 June 2014 (UTC)[reply]
  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)[reply]
  4. Support. This should have been done long ago! Ruslik_Zero 13:45, 13 June 2014 (UTC)[reply]
  5. Support per nom. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:05, 13 June 2014 (UTC)[reply]
  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). Helder.wiki 16:44, 13 June 2014 (UTC)[reply]
  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)[reply]
  8. Support This pretty much says it all. --AmaryllisGardener talk 17:39, 13 June 2014 (UTC)[reply]
  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)[reply]
  10. Support per nom. APerson (talk!) 20:32, 13 June 2014 (UTC)[reply]
  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)[reply]
    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}} (e • t • c) 18:35, 14 June 2014 (UTC)[reply]
  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)[reply]
    See my above comment. :) — {{U|Technical 13}} (e • t • c) 18:35, 14 June 2014 (UTC)[reply]
  13. Support; seems sensible. Ironholds (talk) 17:41, 14 June 2014 (UTC)[reply]
  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)[reply]
    • 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}} (e • t • c) 22:33, 14 June 2014 (UTC)[reply]
    • 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)[reply]
  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)[reply]
  16. Qualified support per SFB. Λυδαcιτγ 03:47, 22 June 2014 (UTC)[reply]
  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)[reply]
  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)[reply]
  19. Support. Jc86035 (talk • contributions) 12:22, 3 July 2014 (UTC)[reply]
  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)[reply]
  21. Support. -- Magioladitis (talk) 13:24, 9 July 2014 (UTC)[reply]
  22. Support The future is rushing to meet us. ;) Protonk (talk) 15:23, 15 July 2014 (UTC)[reply]

Oppose (deprecated elements)

  1. No. Wikitext != HTML. Legoktm (talk) 05:34, 13 June 2014 (UTC)[reply]
    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)[reply]
    Can't HTMLtidy or something similar convert the font tags? –xenotalk 10:55, 13 June 2014 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    • 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}} (e • t • c) 12:12, 13 June 2014 (UTC)[reply]
  2. Not necessary and can apparently be done in the html pre-processor when it is. –xenotalk 12:51, 13 June 2014 (UTC)[reply]
    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}} (e • t • c) 13:36, 13 June 2014 (UTC)[reply]
    The parser already does that... Don't worry about performance. Legoktm (talk) 22:58, 13 June 2014 (UTC)[reply]
    You seem to be overlooking the Wikipedia:Don't worry about performance#Editors still have a role to play clause. — {{U|Technical 13}} (e • t • c) 02:21, 14 June 2014 (UTC)[reply]
    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)[reply]
  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 (talk • contribs) 14:09, 13 June 2014 (UTC)[reply]
    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}} (e • t • c) 14:46, 13 June 2014 (UTC)[reply]
  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)[reply]
    Can't you increase the font size with the span tag, Technical 13? --AmaryllisGardener talk 01:15, 14 June 2014 (UTC)[reply]
    @Nyttend: Aha, Like this! Code: <span style="font-size: 150%;">Like this!</span> --AmaryllisGardener talk 01:22, 14 June 2014 (UTC)[reply]
    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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    • 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}} (e • t • c) 02:19, 14 June 2014 (UTC)[reply]
  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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
    • 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}} (e • t • c) 02:19, 14 June 2014 (UTC)[reply]
    It's not that much of a bold claim. MDN is full of elements which have been deprecated and then removed from broswers. The path is generally long because browser maintainers work hard to make sure they won't make sudden material changes to the web, but it still happens--the reverse, where deprecated elements are restored is incredibly uncommon. Continuing to use a deprecated element (especially in something like a signature, which can proliferate over many pages pretty easily) just makes the eventual and inevitable switchover harder. Protonk (talk) 13:17, 16 July 2014 (UTC)[reply]
  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)[reply]
    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}} (e • t • c) 12:13, 16 June 2014 (UTC)[reply]
    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)[reply]
  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)[reply]
    • 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}} (e • t • c) 22:12, 24 June 2014 (UTC)[reply]
      • 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)[reply]
        • 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}} (e • t • c) 22:21, 30 June 2014 (UTC)[reply]
  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)[reply]
    • 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)[reply]
  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)[reply]
    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)[reply]
    • 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}} (e • t • c) 13:30, 9 July 2014 (UTC)[reply]
    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)[reply]
    @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)[reply]
  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}} (t•c) 03:05, 9 July 2014 (UTC)[reply]
    @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)[reply]
    We shouldn't be leaving it up to the backend to fix our human error or laziness. — {{U|Technical 13}} (e • t • c) 13:36, 9 July 2014 (UTC)[reply]
    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}} (t•c)
    • 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}} (e • t • c) 17:50, 9 July 2014 (UTC)[reply]
    Any such browsers are broken; their brokenness is harmful. Unsupported HTML tags are to be ignored. <elvey>this</elvey> should display 'this' , not nothing.--{{U|Elvey}} (t•c) 21:04, 10 July 2014 (UTC)[reply]
    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}} (t•c) 15:52, 9 July 2014 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.


RFC: Naming of one and two digit numbers and years

Background

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.

Question

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)[reply]

Threaded Discussion

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)[reply]

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

Support

  1. Support as proposer. --NYKevin 21:51, 21 June 2014 (UTC)[reply]
  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)[reply]
  3. Support first half per Quondum. The current situation is truly awkward and needs to be solved. --cyclopiaspeak! 22:05, 22 June 2014 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]

Oppose

  1. Oppose for consistency's sake. --AmaryllisGardener talk 23:37, 21 June 2014 (UTC)[reply]
  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)[reply]
  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)[reply]
    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)[reply]
    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)[reply]
    Couldn't the AD-vs-CE debate be sidestepped entirely by using "(year)" as a disambiguator, as in "43 (year)"? — Jaydiem (talk) 22:27, 21 July 2014 (UTC)[reply]
  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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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 (Talk • Contributions • Log) 10:19, 10 July 2014 (UTC)[reply]
  13. Oppose – The value of consistency sways me to oppose, and the dramah potential sways me even further. Mojoworker (talk) 15:33, 15 July 2014 (UTC)[reply]
  14. Oppose "A.D." is presumed when there is no A.D. / B.C. I don't think such a generally accepted rule has to be amended. For the disambiguation issue, almost everyone seeing "5" in most articles (that is, non-mathematical articles) would expect a link to the year, as no one links "5" in those articles to the number, but there are people linking it to the year.Forbidden User (talk) 16:09, 17 July 2014 (UTC)[reply]
  15. Oppose, the drama potential with this change just screams "what could possibly go wrong"... Titoxd(?!? - cool stuff) 22:54, 21 July 2014 (UTC)[reply]

Polls are evil

  1. I'm going to hang out here on the Group W bench and watch for a bit. — {{U|Technical 13}} (e • t • c) 22:42, 21 June 2014 (UTC)[reply]
    How is this related to the topic?Forbidden User (talk) 09:35, 13 July 2014 (UTC)[reply]
    There is something to be said for listening first and deciding second. =) — Jaydiem (talk) 22:49, 21 July 2014 (UTC)[reply]

Cleanup after Project Tagger

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)[reply]

@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)[reply]

I've been using User:Kephir/gadgets/rater recently, and I'm pretty happy with it. WhatamIdoing (talk) 23:32, 10 July 2014 (UTC)[reply]

This tool is amazing and I recommend it to everyone :-). For best effect, combine it with the "Display an assessment of an article's quality as part of the page header for each article." option in Preferences > Gadgets. Andrew Gray (talk) 21:06, 12 July 2014 (UTC)[reply]

Category:Articles with disclosed paid contributions

Hello! I would like to propose add a category called "Category:Articles with disclosed paid contributions" or similar to the articles which have disclosed paid contributions according to the new terms of use. I think it could be a good method to inform to the reader that the article has paid contributions. --Kelseycf (talk) 11:47, 15 July 2014 (UTC)[reply]

Straight off the top of my head I see a problem with this: How do we decide when a paid contribution is no longer present in the article? For example if a paid editor writes a sentence, and that sentence is changed by other editors over time, at which point does the article cease to have a paid contribution on it? Sam Walton (talk) 11:50, 15 July 2014 (UTC)[reply]
@Samwalton9: You bring up a valid point, but I would think that a paid contributor would have constant eyes on said article. In theory the tagging of said article could be done and undone by consensus. ♥ Solarra ♥ ♪ 話 ♪ ߷ ♀ 投稿 ♀ 12:16, 15 July 2014 (UTC)[reply]
They may have constant eyes on said article to begin with, but as soon as the payment stops they no longer have a reason to watch it. --Redrose64 (talk) 12:45, 15 July 2014 (UTC)[reply]
Since the new terms of use indicate that the paid contribution have to be made with an appropriate edit summary, it should be straightforward to tell what the paid editor added. If the contribution were to be totally removed or written for some reason, any editor could remove the tag; a consensus would only be needed if the contributions were just changed partially. —Anne Delong (talk) 15:20, 15 July 2014 (UTC)[reply]
Such articles could be automatically added to the category by {{Paid contributions}} or whichever notices are appropriate. Would it make sense for this to be a hidden category? Ivanvector (talk) 17:21, 15 July 2014 (UTC)[reply]
Anne Delong, I believe that the terms of use require an edit summary or a note on the talk page or a note on your user page. In some instances it might be more difficult to identify exactly what is added. WhatamIdoing (talk) 19:00, 15 July 2014 (UTC)[reply]
Hmmm... too bad... the notice on individual edits would be so much more precise. It appears to me that a person could be paid to edit a particular page, and yet make thousands of contributions on other pages which were not paid. —Anne Delong (talk) 19:17, 15 July 2014 (UTC)[reply]

I think it should be a hidden maintenance category not a reader one. Treat it similar to Category:Living people in that it can be reviewed periodically. -- Ricky81682 (talk) 20:09, 15 July 2014 (UTC)[reply]

It could be hidden, yes, but my point is to inform the reader that the article have or had paid contributions. I think this is important when the article was created by paid editors. In Europe for example it is necessary to inform the reader in the article page, the disclosure in the talk page or user page is not enough. Furthermore, in the future it can be used for doing statistics about the contributors. Another possibility is having several categories like Category:Articles with revised disclosed paid contributions.--Kelseycf (talk) 11:32, 16 July 2014 (UTC)[reply]
Hidden cats are...hidden. How would they inform readers unless the readers take special steps (which are not obvious if I recall)? That seems less visible than a boxed note on the talkpage (which is the place well known to have notes about the article content-development)? If there is a specific legal requirement, it would have to go through WP:LEGAL (i.e., we here as editors cannot choose to be illegal). I'm bit hazy on how a Europan law impacts a US-based system. DMacks (talk) 17:52, 17 July 2014 (UTC)[reply]

Drafts and sandboxes can be visible in mainspace categories

If you include a category template anywhere, for instance in a user page or an article submitted for creation, then that "anywhere" will be visible in the referenced category. I consider this being a bug.

A similar, but reverse phenomenon, is that inline citation popups don't work in user space pages and articles submitted for creation. Highly annoying and costly in time for developing well-referenced articles. YohanN7 (talk) 01:11, 16 July 2014 (UTC)[reply]

@YohanN7: Not quite sure I understand your first point about "category templates". If you're referring to a category link such as [[Category:Living people]], then you may be interested to know that my bot comments out article categories from pages in userspace and draftspace. GoingBatty (talk) 02:11, 16 July 2014 (UTC)[reply]
If you have a local copy of an article you are working on, then it will be visible in any category you list in your local copy of the article. The same applies to articles submitted for creation. (This can even be embarrassing if your local copy is crap, since people might go and look at it).
It's nice that you have a bot cleaning up, but the template shouldn't kick in in the first place. YohanN7 (talk) 02:25, 16 July 2014 (UTC)[reply]
@YohanN7: There are categories that are appropriate for user pages and AfCs. I don't think Mediawiki is smart enough to differentiate an article category vs. a non-article category. GoingBatty (talk) 02:34, 16 July 2014 (UTC)[reply]
Okay, I can live with it. Any hope for popup citations working in sandboxes/user pages? I can't see why they shouldn't work. YohanN7 (talk) 03:01, 16 July 2014 (UTC)[reply]

Idea for specialized blocks

I have posted an idea at Wikipedia:Village pump (idea lab)#Specialized blocks for a proposal which I may soon present here. I am not sure if it is already ready to be put forth though, so I have posted it there. Dustin (talk) 02:18, 16 July 2014 (UTC)[reply]

Yeah, this sounds like a WP:Wikilawyer's dream, and seems to have no productive use. Editors are either a part of this community, and hence they need to follow any topic/page/interaction bans that the community has established under their own recognizance, or they act outside of the this community, and we block them from participating contributing at all. Technical issues aside, this doesn't look like something that should be pursued. VanIsaacWScont 02:34, 16 July 2014 (UTC)[reply]
I am afraid that I do not understand your reasoning. Why should someone who cannot keep him/herself off of a certain topic which he/she was banned from be left only with the option of indef block? That kind of thing can only cause harm to Wikipedia. If that person doesn't think he or she can do so, he/she should be able to request that him/herself to be blocked from x pages as a better way of enforcing bans. In that way, Wikipedia can trust that this editor no longer causes any problems in one area of the encyclopedia while remaining constructive in another. An indef block destroys the chance for any constructive contributions in or outside of that topic ever again. And that isn't even addressing the other two main points. Please reconsider. Dustin (talk) 02:47, 16 July 2014 (UTC)[reply]
In any case, I just brought this topic up to discuss whether or not that proposal has been crafted well enough to be presented here, not to discuss the idea in practice. The section for discussing will simply be under the name "Specialized blocks". Dustin (talk) 02:52, 16 July 2014 (UTC)[reply]
A system of specialized blocks would not be helpful. An editor who is so passionate that they cannot voluntarily follow the terms of a topic ban is not a good fit for Wikipedia as they will inevitably find other ways of promoting their cause due to their lack of self-restraint. A collaborative community is required and that involves self-restraint. I know it's just an idea at this stage, but I'm commenting here in case it ever becomes a proposal. Johnuniq (talk) 04:03, 16 July 2014 (UTC)[reply]
What about my third bulletpoint? Dustin (talk) 04:11, 16 July 2014 (UTC)[reply]
If someone "cannot keep him/herself off a certain topic which he/she was banned from", then by their actions they have said that they do not consider themselves a member of this community. There is no halfway on this where someone who flagrantly flaunts the restrictions this community has put in place in order to protect itself from them can be trusted in any way. Disdain for the norms of this community isn't restricted to subject areas. If you consider yourself to be above the rules and restrictions this community has established to protect itself from you, then there is no area in which you can be trusted. We only leave the talk page open so that you can indicate your commitment to abiding by the standards of this community. Now, I'd be happy to support expansion of the talkpage access to all pages in the User talk:<username> area, if you think there is a recurring need for that kind of access (ie, that the point #3 example is not a one-off exception). But fragmented blocks can only be used to implement schizophrenic policy, and that's not really in anyone's interest, except for those who violate topic/page/interaction bans, who would try to wikilawyer their way out of the consequences of their self-professed antipathy for this community. VanIsaacWScont 05:29, 16 July 2014 (UTC)[reply]

Since this functionality does not currently exist in MediaWiki, there is also the question of who would implement this. There is currently no team at the Wikimedia Foundation who could own this work, so you'd probably need to find a random developer to implement this, too. --Dan Garry, Wikimedia Foundation (talk) 05:55, 16 July 2014 (UTC)[reply]

Hmm... well, I guess that would be an issue with my plan... in any case, thank you for the reply. At the very least, if the is ever implemented, regardless of who does so, I would support allowing blocked users to have single-page block exemptions (i.e., apart from talk page edits, a user could edit one other page if required such as the Administrator's noticeboard). Dustin (talk) 06:00, 16 July 2014 (UTC)[reply]

Why is this being discussed in multiple places? The original is Wikipedia:Village pump (idea lab)#Specialized blocks. --Redrose64 (talk) 12:32, 16 July 2014 (UTC)[reply]

Satpal Maharaj/ Devine Light Mission

Details mentioned regarding Devine Light Mission should not be the part of Satpal Maharaj.

In any of the record in Govt. of Indian Department , This organization was not headed by Satpal Maharaj.

Satpal Mahraj is founder of Manav Utthan Sewa Samiti - A Non-profitable organization registered as per Society Registration act of India, 1961.

Manav Utthan Sewa Samiti's registration no is S/7341/1974

Devine Light Mission was headed by Prem Rawat.

Mentioning of Devine light Mission under this article is again to vandalize the image of a person.

Add "Contributing to Wikipedia" to main left hand side info links

Wikipedia:Contributing to Wikipedia is a new article (revamped to be honest) that I believe would be a great asset to many potential editors. I have a simple proposal to add the link Contributing under the "Interaction" section on the main left hand-side navigational links. lots of work has gone into the article with videos and all. We currently have links to info about Wikipedia its self, where people can help (Community portal) and a link to "Help:Contents". I believe a direct link to our MAIN "how to page" is a good idea over having to read over the "Help:Contents" to find the how to pages. I am not sure if this is the right place or not - but nevertheless I am trying to get a feel for this idea. -- Moxy (talk) 07:48, 18 July 2014 (UTC)[reply]

Make article titles case-preserving, not case-sensitive

Currently, the title of a Wikipedia article is case-sensitive except for the first character. This means allows articles like Gentleman's Agreement and gentleman's agreement to exist side by side. (If there is more than one place where a letter after the first might be capitalized, there can be more than two similarly titled articles.)

I submit that:

  • Instances where this is actually useful are quite rare.
  • Most computer searches, including Google's, treat words and phrases case-insensitively, so that's what most people will find obvious.
  • Library catalogs likewise access titles case-insensitively (indeed, the ones I'm familiar with don't even preserve the case of the original title).
  • The idea that in Wikipedia the first character is treated differently is additional level of non-obviousness, but does not cause any major problems.

On the other hand:

  • Disambiguation of similar article titles by suffixes like "(film)" or "(aviation)" or "(politician)" is common on Wikipedia and easily understood, and could easily be applied to cases like the example by renaming to "Gentleman's Agreement (film)" or "gentleman's agreement (concept)".
  • Indeed, in a number of cases the lower-case article is a disambiguation page that might as well have been named using the standard suffix "(disambiguation)".
  • In cases where such similarly titled articles exist, there is generally a hatnote pointing from each to the other. If the reader who opened gentleman's agreement wanted Gentleman's Agreement, their experience by following the hatnote will be no different if it points to "Gentleman's Agreement (film)".

I therefore propose that article titles should become case-preserving but no longer case-sensitive. Obviously this transition can't be done in a single step, but I propose the following sequence of steps to achieve it (note: I've edited this from my original posting, where I did not quite get it right).

  1. By "canonical name" I mean the lower-case form of an article title. Change the software that interprets URLs and implements the search blank so that if there is no hit on an article name as given, then the canonical name is tried.
  2. By "special redirect" I mean a redirect from the canonical name of an article to its actual name, e.g. from "william lyon mackenzie king" to William Lyon Mackenzie King. Change the article-creation software so that (1) when an article is created or retitled, if its title is not already in canonical form and there is no existing article with the canonical form of the title, then a corresponding special redirect is also automatically created; and (2) no further articles with the same canonical name as an existing article can be created, except for special redirects. Simultaneously change the editing software so that if an article is already a special redirect, it cannot be edited.
  3. Using a one-time bot, find all cases where the article title contains a capital letter and the canonical name is not already used for an article, and create a special redirect. If there are multiple articles whose canonical name would be the same, but no existing article whose name is the canonical one, the bot should create only one special redirect, making an arbitrary but sensible choice as to which one it redirects to: perhaps to the largest of the existing articles, or the one with the longest version history, or the one with the fewest capital letters in the title.
  4. Start a project where people would identify articles whose titles differ only in case, and retitle at least one of each such pair (or group), adding or cleaning up hatnotes as necessary. Redirects to other capitalizations of the same name, except for special redirects, can be deleted during this process. Once the process is complete as well as the above technical changes, the desired effect has been achieved.
  5. When this is complete, the final optional step is to clean up the article database to eliminate the special redirects. To do this, the database would be changed to make the canonical name the primary key for accessing each article, with the actual (case-preserving) title stored as an additional data item.

In writing all this, I primarily have English in mind, but of course the same would apply to titles in other languages that have the concept of case—and I guess to Wikipedias in all languages.

That's all I have to say. I don't plan to get involved in any way with the project I'm proposing, and if the Powers That Be think the whole idea is a non-starter, that's their prerogative. But I think it's a clear win, and I think the sequence I've set out should avoid situations where "you can't do that". Given that case-sensitive titling has always been kind of unexpected, I was actually a bit surprised that I didn't find it on the "perennial proposals" page; but I didn't, so I'm proposing it now.

--50.100.189.160 (talk) 06:09, 20 July 2014 (UTC)[reply]

  • Support! In principle, I think this is a fantastic idea. Imagine all the redirect-cruft from variant capitalizations that could be swept away forever!
⋮
I do have a quibble or two with the proposed implementation. For example: for the same reason that the "eBay" article is technically at "EBay", the "canonical" version of an article title should be the "display" title rendered entirely in lowercase, except for the first character, which, if a letter, should be in uppercase. This would not only accommodate the existing technical requirements of the MediaWiki software, but would also have the additional benefit that the vast majority of articles' "canonical" and "display" titles would be identical, in which case no "special redirect" would be necessary. Also, it would be worth considering that if a URL containing the name of an article incorrectly capitalized were followed, then MediaWiki would respond with an HTTP redirect, using either status code 301 (Moved permanently) or 303 (See other), to the URL with the article name capitalized correctly (i.e., matching the article's "display" title)—rather than accepting the misspelled URL and presenting the article page with a "(redirected from …… )" hatnote.
⋮
One hurdle to overcome will be the fact that usernames are case-sensitive, and it would not be feasible to make the "User:" and "User talk:" namespaces case-insensitive—at least, not to the left of the first "/" character. I also anticipate some grumbling about the special role of ALL-CAPS titles as shortcuts to things in namespaces such as "Help:" and "Wikipedia:". I'm not sure how much of a "collision" problem there would be if these namespaces were rendered case-insensitive, but my guess is that the number of WP:SHORTCUTS that share a spelling with a non-shortcut page to which they don't redirect (or both don't redirect to the same target) is very, very small.
⋮
In sum, while the implementation would be non-trivial from a technical standpoint, much of it could be automated, and my intuitive impression is that this change would be warmly welcomed by our readers and editors. — Jaydiem (talk) 22:14, 21 July 2014 (UTC)[reply]
  • Just to amplify what I said earlier about "redirect-cruft": A quick look at Category:Redirects from other capitalisations finds that it contains a mind-boggling 397,446 redirects, of which I'll bet at least 99% are completely pointless. And that number doesn't include what must be many more such redirects that exist but aren't linked to the category. We are talking about something on the order of half a million redirects that could be completely done away with by adopting case-insensitivity. It's a beautiful thing! — Jaydiem (talk) 07:19, 22 July 2014 (UTC)[reply]
  • Support These seems like it could solve several conflicts as well. I believe one of the reasons why sentence case article names makes sense is because when articles are linked in sentences it goes to the case linked. If we made them all equivalent it could mean that we could use title case for article names without requiring redirects or pipes in the links. This would allow some of the recent capitalization style differences of opinions to be less important. I think in addition to folding letters, certain symbols should be folded together as well. For example treat "-", "/", "–", and "—" as interchangeable when resolving the page. This means that the correct hyphen, or dash can be used in a title but that it could be found with the standard hyphen-minus character. It could also solve the upper vs lower case first character issue. I'm not sure we need to use 301 or 303 codes. I might suggest making the canonical URL always be the lowercase forum ( etc. ), and just store the preferred capitalization along with the article either internally as a separate data field, or similar to how article names are handled inline for lowercase letters. In which case all interwiki links should always then go to the canonical forum. PaleAqua (talk) 03:20, 22 July 2014 (UTC)[reply]

RfC: Should Persondata template be removed from articles?

Background (Persondata)

The question keeps arising on Wikipedia talk:Persondata and other forums on whether we should drop persondata now that Wikidata provides the same or similar information. I usually state eventually that is the goal, but I haven't heard anything else about it. I decided this time to be more proactive about it.

From Wikipedia:Persondata, "Persondata is a special set of metadata that can and should be added to biographical articles only. It consists of standardized data fields with basic information about the person (name, short description, birth and death days, and places of birth and death) that, unlike conventional Wikipedia content, can be extracted automatically and processed by cataloging tools and then used for a variety of purposes, such as providing advanced search capabilities, statistical analysis, automated categorization, and birthday lists."

At this time, I'm not aware of anyone using the data. DBpedia does gather the information and offers it for download. However, I'm not aware that they use it. Wikidata did have two bots running, which copied |SHORT DESCRIPTION= from persondata and put it into Wikidata. One bot worked only on dewiki. SamoaBot did work on enwiki. SamoaBot's operator stated that he doesn't "...recall having run that task in these months. However, tons of data have already been imported, and now it is up to the English Wikipedia community to decide whether they still want those data within articles." I did ask Wikidata about persondata.

{{Persondata}} does have many drawbacks. Some of which are:

  1. It is hidden, therefore it is often out of sync with the article text or infobox, with no current mechanism to keep it in sync.
  2. If an infobox is present, persondata becomes redundant.
  3. It is currently not being used by anybody (to my knowledge).
  4. |NAME= and |ALTERNATIVE NAME= parameters have no standard format. Format should be surname, firstname, but this isn't always followed. When a person as a stage/pen name, there is not standard on which parameter parameter gets what name.

Positives:

  1. If the article doesn't have an infobox, persondata can become a source of info.
  2. |SHORT DESCRIPTION= is of use to Wikidata.
  3. From Periglio's talk page, "Wikipedia has an easy accessible database of over 1 million people. It is data available for serious research projects. Why delete it?"

Question: Should the {{persondata}} template be removed from all articles and no longer be used?

Proposed by Bgwhite 21:21, 20 July 2014 (UTC)[reply]

Discussion (Persondata)

  • Have a comment?
Before implementing this change all the gadgets and tools that create or use this template must also be changed. Otherwise we will get them being created when others are trying to get rid of them. A comparable situation where the cite gadget creates "deprecated" cite template parameters that bot(s) go around undoing. So this should be done as a proper release, where wikidata, gadgets and tools are all synchronised with the policy implementation to stop wasted effort. Graeme Bartlett (talk) 22:08, 20 July 2014 (UTC)[reply]
Graeme Bartlett, Wikidata is currently not ingesting anything from Persondata. I'm aware of two tools that create Persondata, Persondata-o-matic and AWB. An AWB developer is aware of this proposal. Persondata-o-matic currently doesn't work. There are some scripts/gadgets that do allow for easy viewing persondata. Bgwhite (talk) 22:17, 20 July 2014 (UTC)[reply]
So I think that Wikidata should ingest this. It will be harder to harvest from history as it may not be possible to tell the "correct" version. AFC reviewer tool currently adds persondata. Graeme Bartlett (talk) 06:02, 21 July 2014 (UTC)[reply]
If this goes ahead, someone (I'm willing to help) will need to close up the Persondata and WikiProject Persondata and related pages. Also maybe notify members of the project (and places like WP:BIOG) that persondata is going to be removed. Is there a way of setting up an ongoing bot to send messages to users who add new persondata?—Msmarmalade (talk) 08:09, 21 July 2014 (UTC)[reply]

User:Rjwilmsi's bot occasionally adds/updates Persondata using AWB but it should be very easy to diactivate AWB's after we agree to stop adding/remove Persondata. -- Magioladitis (talk) 08:24, 21 July 2014 (UTC)[reply]

Wikipedia:WikiProject Biography and Wikipedia:WikiProject Infoboxes about this discussion. -- Magioladitis (talk) 08:27, 21 July 2014 (UTC)[reply]

My main concern is Category:Biography articles without infoboxes. This means we have 20,000+ that may have Persondata and not an infobox. -- Magioladitis (talk) 08:40, 21 July 2014 (UTC)[reply]

How reliable is Persondata anyway? in this edit a malformed article title was used to create a malformed NAME, and DATE OF BIRTH was copied from the completely unsourced infobox (it's not present in the body of the article). Where does that leave Persondata - or Wikidata if it scrapes up "information" using the same rules? PamD 10:40, 21 July 2014 (UTC)[reply]

  1. Questions - Perhaps it's just me, but there seems to be a failure of communications at work here. Even now, many WP editors remain in the dark about what Wikidata is doing, and how it will affect WP articles. In this example, for instance, would the supplantation of persondata by corresponding wikidata yield better WP articles? Will it, for instance, automatically populate WP infoboxes? What would the differences look like? How would they be made compliant with BLP, V, and other WP policies? Would WP editors still be able to correct errors, without having to learn their way around Wikidata? Are there some examples in place to show how these things will operate? LeadSongDog come howl! 20:40, 21 July 2014 (UTC)[reply]
    @LeadSongDog:. Some data in the infoboxes could be fetched from Wikidata, but that does not seeem to be the matter at hand here. {{Persondata}} is not meant to be used to populate infoboxes. -Superzoulou
    Thanks, but that really doesn't clear much up. The content of {{Persondata}}, {{Infobox person}}, etc should reasonably be automagically verifiable against the categories the article is put into. References supporting the assertions that cause those categories to be applied must be maintained if we are to avoid finding Koffi Annan in Category:Bollywood stars or something equally absurd. Will/does wikidata support checks to see that the categories are supported in the article, with references? Does it have a mechanism to support variances in sourcing policies between the different WP languages, or at least to attribute the sourcing to the WP language and article where the assertion originates? Vandalism isn't going to be disappearing anytime soon, after all. LeadSongDog come howl! 21:53, 21 July 2014 (UTC)[reply]
    I do not really understand what you are talking about. This proposal is not about deleting {{Infobox person}} and afaik, there is no consistency check between persondata and categories. Actually, I do not see how a bot could use Persondata in their current form to know that Koffi Annan should not be categorized as a Bollywood star.
    Many bots have added from which Wikipedia the data originated in the source part of the statement. One has added the actual reference that was used in the article (but this is more difficult so less widely implemented at the moment). --07:16, 22 July 2014 (UTC)

 Comment: There actually appears to be actually two issues:

  1. should we work toward removing Persondata now ?
  2. should we delete data from Persondata wtihout checkign with have their data in Wikidata first ?~

I am certainly in favour of 1), not of 2): if data in persondata match those in Wikidata, they can be deleted. It is a bit pointless that when we want to correct some data, we need to do it in two pages instead of one. But when there are gaps in Wikidata/mismatch with persondata, it should be checked before deleting anything. --Superzoulou (talk) 07:16, 22 July 2014 (UTC)[reply]

In that case, perhaps we should have a {{persondata moved to Wikdiata}} which can be applied (by humans or bots) once the data is verified as being in Wikidata. It should prevent further addition of Persondata, and enable us to check progress statistics. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:27, 22 July 2014 (UTC)[reply]

Support (Persondata removal)

  1. Support, unless anyone shows a temporary need to retain the data while it is copied to Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:55, 20 July 2014 (UTC)[reply]
  2. Support as redundant, --Gerda Arendt (talk) 22:07, 20 July 2014 (UTC)[reply]
  3. Support as redundant. I've never added it to an article, never understood why. Sometimes have to fix work of others who insert inconsistent data. Montanabw(talk) 02:48, 21 July 2014 (UTC)[reply]
  4. Support per others. --AmaryllisGardener talk 03:27, 21 July 2014 (UTC)[reply]
  5. Support as long as it is implemented cleanly, (see discussion above) and the information therein is not lost. This sort of data should appear in Wikidata instead, and is not really "encyclopedic" in itself. But it could be a tool to populate indexes, categories, or add to author records - more the thing for Wikidata. Graeme Bartlett (talk) 06:05, 21 July 2014 (UTC)[reply]
  6. Support as reduntant. Perhaps afterwards, focus should move to cleaning up infoboxes, and standardizing the dates, data, etc within them.—Msmarmalade (talk) 07:47, 21 July 2014 (UTC)[reply]
  7. Support as redundant. The use to which this data is potentially put is dubious, and the fact that it isn't sync'd seems to make the whole thing pointless. I'd like to see the automated insertion by AWB switched off immediately, and its complete reversal (into 'systematically remove' mode and not just neutral) if the RfC goes through. -- Ohc ¡digame! 09:10, 21 July 2014 (UTC)[reply]
  8. Qualified support remove data that are identical on to those on Wikidata so that we do not need to maintain them at two places. Check and then remove the other ones. --Superzoulou (talk) 10:11, 21 July 2014 (UTC) + Superzoulou (talk) 11:01, 22 July 2014 (UTC)[reply]
  9. Support Finally the time has come. You always had the highlights and details in infobox, there was no need of persondata like others may have thought as well. OccultZone (Talk • Contributions • Log) 10:44, 21 July 2014 (UTC)[reply]
  10. Support as redundant, and an annoyance to maintain. These can also be a pain to fix when disambiguating links because the link is there, but invisible. bd2412 T 13:33, 21 July 2014 (UTC)[reply]
  11. Support I like the idea of using a tool designed to keep track of this sort of data to keep track of this sort of data. Zell Faze (talk) 14:04, 21 July 2014 (UTC)[reply]
  12. Support, though make sure that the data we are removing already exists in Wikidata first. Cbrown1023 talk 17:45, 21 July 2014 (UTC)[reply]
  13. Support eventual removal - as and when we are confident it's been migrated to Wikidata. Removal on a case-by-case basis when migrated would be reasonable, and then deprecating the system. Andrew Gray (talk) 19:53, 21 July 2014 (UTC)[reply]
    Andrew Gray, Wikidata will not import anything but |SHORT DESCRIPTION=. A bot has already imported this data and will run again before Persondata's removal. Bgwhite (talk) 19:59, 21 July 2014 (UTC)[reply]
  14. Support The only reason I include persondata in my new stubs is because they otherwise got inserted with incorrect or incomplete data. I have never used the persondata and I believe it is redundant now with Wikidata - maybe someone could run some numbers on the accuracy of persondata vs Wikidata for 100 random biographies? depending on the results we could just rip them all out. Alternatively, we could agree to no longer insert persondata and manually delete whenever we check Wikidata and see the data exists on Wikidata. Jane (talk) 09:10, 22 July 2014 (UTC)[reply]

Oppose (Persondata removal)

  1. Oppose: First of all, the claim that Persondata are currently not being used by anybody is wrong. Tools that evaluate Persondata exist and are being used. Secondly, Wikidata cannot be taken seriously at this stage as its data (beyond the interwiki links) are simply not reliable. As elaborated in this discussion, Wikidata looks like a Wikipedia from 2003 without any references. A Wikipedia article, however, combines both, literature and references that backup the data given in the Persondata template. At the current state of affairs, the Wikipedia articles and their Persondata records should be considered as a source, not as a target for Wikidata. --AFBorchert (talk) 08:32, 21 July 2014 (UTC)[reply]
    And another observation: I just took a first look at one of the dumps of wikidata. They are as ugly as hell as they are embedding JSON within XML. To extract person data from Wikipedia dumps is pretty simple (and frequently done). This fun will be all gone when you have to turn to Wikidata dumps. --AFBorchert (talk) 08:43, 21 July 2014 (UTC)[reply]
    AFBorchert:
    Wikidata does not contain enough references, but English Persondata do not contain any, so I do not really understand what your point is. The real question would be which is more reliable between birth/death place/date in Wikidata and in English Persondata. I see no argument one way or the other.
    German Persondata appear to be more used than the English ones, but the discussion for removing them should be done in Wikipedia in German. Does any German tool use English Persondata ? --Superzoulou (talk) 09:56, 21 July 2014 (UTC)[reply]
    @Superzoulou: Persondata are embedded in articles that (hopefully) provide references to backup this data. Hence, you have both, data and references in one place very close to each other. If the article is updated in this regard, the persondata can be easily adapted in one edit. At Wikidata we have mostly a heap of data without any references. This does not help us and is surely no replacement for the current Persondata. I refered to the German discussions as de-wp as this was debated there half a year ago. I think it is always worthwile to look into other similar projects and their discussions. And indeed the Persondata were introduced at de-wp and later imported to en-wp. It is surely a predecessor to Wikidata and at some time it may be envisioned to deprecate it but currently I would see it as a great tool that helps in the transition to Wikidata which is not yet sufficiently mature to replace it in my opinion. --AFBorchert (talk) 11:54, 21 July 2014 (UTC)[reply]
    @AFBorchert: English Persondata are mostly meant for bots that are not smart enough to read the rest of the article, and for them references elsewhere in the page are not really useful. It is true that people who maintain the template can check the consistency between Persondata and the rest of the article, but I wonder how many people do it by hands. Bots can also check the consistency of the data between Wikidata and Wikipedia. --Superzoulou (talk) 13:17, 21 July 2014 (UTC)[reply]
    @Superzoulou: I do it “by hand” at en-wp as well as de-wp. And indeed the consistency check between Wikidata and Wikipedia is an important advantage that would get lost if we would give up Persondata too early. With very few exceptions, I do not edit data records corresponding to Persondata at Wikidata as it is no fun for me to click through all the Javascript-based forms. Wikitext can be edited far more conveniently (and if necessary even by an editor of my choice like Vim), I do not want to waste my time with clicking through a myriad of forms. --AFBorchert (talk) 13:28, 21 July 2014 (UTC)[reply]
    @AFBorchert: Consistency of Wikidata can also be checked against infoboxes, and even against the article's lead (Wikidata items about people are marked as such so which avoids the occasional topic mismatch between the infobox and the article proper). --Superzoulou (talk) 14:44, 21 July 2014 (UTC)[reply]
    @Superzoulou: Many biographic articles do not have infoboxes but Persondata (example). --AFBorchert (talk) 20:05, 21 July 2014 (UTC)[reply]
    @AFBorchert: I know, and I would suggest that we should start the removal with pages with infoboxes. But the data can also be parsed from the article's lead.
  2. Oppose (from wikiproject templates): until wikidata is brought online, persondata needs to stay in order to populate wikidata with the largest source we have of data on article subjects. I know that AWB automatically copies information from infoboxes to persondata, so there is obviously significant overlap on those two, and I am absolutely convinced that persondata's usefulness will soon expire. But we need to keep this on enwiki, up until a bot goes through and copies the persondata entries to wikidata (just like they did with interwiki links), and no later; nobody else has nearly the comprehensive coverage of biographies that would facilitate that transfer. VanIsaacWScont 09:28, 21 July 2014 (UTC)[reply]
    @Vanisaac: In what way is Wikidata not "online"? Are we confident that Persondata is reliable (accurate and up-to-date) enough to be copied to Wikidata? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:58, 22 July 2014 (UTC)[reply]
    It's not online in the same way that Obamacare is not online: Yeah, there's a lot of the substantive stuff that's there now, and the different features are getting implemented roughly when they are supposed to, but there's still more to come as time progresses, and it's going to take some effort by people to get to the level of coverage that the system was designed to have. VanIsaacWScont 10:04, 22 July 2014 (UTC)[reply]
    @Vanisaac: So you object to deprecating persondata in favour of Wikidata, even though Wikidata does everything that persondata does, and much more besides, because Wikdiata will do even yet more in the future? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:34, 22 July 2014 (UTC)[reply]
  3. Oppose — this seems slightly premature, and the linked discussion from Wikidata seems to indicate that they would not like to see Persondata nuked just yet. Titoxd(?!? - cool stuff) 18:26, 21 July 2014 (UTC)[reply]
  4. Oppose. The proposer has not provided any English-language documentation demonstrating that Wikidata is, or soon will be, a fit successor to Persondata. Jc3s5h (talk) 19:47, 21 July 2014 (UTC)[reply]
    • Jc3s5h, Nobody currently uses the data contained in Persondata. How can there be a successor to something nobody uses? People do use Wikidata and DBpedia. Bgwhite (talk) 20:26, 21 July 2014 (UTC)[reply]
      • The proposal uses Wikidata as partial justification for the removal, but there is no link to any documentation about the part of Wikidata that would cover people. As for nobody using Persondata, there seems to be some disagreement about that. Jc3s5h (talk) 20:51, 21 July 2014 (UTC)[reply]
    • @Jc3s5h: Wikidata entries for people include a |label= property, which is the equivalent of |SHORTDESCRIPTION=, but also multilingual. They also have |Also known as=, |date of birth=, |date of death=, |place of birth= and |place of death=. Not to mention dozens and dozens of other properties, not available in Persondata, such as |gender= and |VIAF identifier=. See, for example d:Q17279725. Each property can be programatically displayed in Wikipedia templates such as infoboxes, succession boxes, etc. - unlike Persondata. In short, Wikidata does everything that persondata does, and much more besides. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:26, 22 July 2014 (UTC)[reply]
  5. Oppose. I am just using Persondata to populate some missing birth/death dates in Wikidata; there are hundreds of thousands of statements that can be used on Wikidata. And if Wikidata were fully "populated", there is no reason to run bots to sync; the template can automatically show Wikidata information if no local data is set, and even add the page to a maintenance category if both is the case, so the information can be merged on Wikidata, and the local data can be removed. Once that is done everywhere, we can think about removing Persondata. Not before. --Magnus Manske (talk) 22:44, 21 July 2014 (UTC)[reply]
    1. @Magnus Manske: I fear a misunderstanding; Persondata is not displayed in this wiki. When do you anticipate finishing your bot run? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:42, 22 July 2014 (UTC)[reply]
      1. I am aware that it is not displayed here. I have only just started with the bot; there are many cases (e.g. "fuzzy" dates) that I am not sure how to handle yet. IMO it would be beyond strange to destroy data in the Persondata template unless we can be sure it has been properly synchronized with Wikidata. --Magnus Manske (talk) 09:13, 22 July 2014 (UTC)[reply]
        1. @Magnus Manske: Thanks for the prompt response; I was referring to your "the template can automatically show Wikidata information" comment. Are you confident that the persondata you are importing is accurate and up-to-date? Do you check it against visible values in the infobox, or lede? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:26, 22 July 2014 (UTC)[reply]
  6. Oppose People do use persondata. I am using the data extracted from Persondata on my own website to generate facts eg "Who is 50 years old today". Although my use may be regarded as trivial,it shows that Persondata is available for serious research - births and deaths of over a million notable people. A lot of people are stating that Persondata is not used, but on what evidence? Extraction tools exist, who knows what people do with the article they download?
    My second reason for opposing is that based on my own experience, Wikidata does not provide a reliable alternative for birth and death dates. Admittedly, there appears to be an editor who updates Wikidata death dates as soon as they happen, but new articles and fixes to old articles do not get onto Wikidata. Someone editing an article would not necessarily think that they need to fix Wikidata as well.
    Finally, again from my experience, Persondata is pretty accurate. I expanded my own software to validate the extract, comparing dates against categories for example. There were only two or three thousand entries, from 1.1 million articles, where persondata had vandalised or out of date data and I am currently fixing those! Periglio (talk) 23:38, 21 July 2014 (UTC)[reply]
    @Periglio: Why are the results of a "Who is 50 years old today" query on Wikidata not acceptable? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:39, 22 July 2014 (UTC)[reply]

Wibe | Surf Wikipedia with the Power of YouTube

Hi,

I am Akshit (Co-Founder of Wibe), we have made a Chrome Extension by which anyone will be able to watch relevant YouTube videos corresponding to the Wiki Article they are reading.

It is the deadly combination of Wikipedia and YouTube, it can really become a great new feature of Wikipedia. We developed it to solve our problem of switching to YouTube from Wiki to understand a particular thing.

I would be very thankful if you please try and review it. Then if you like Wibe, consider it to integrate as a functionality in Wikipedia for some days so that user can use and review this new feature.

Install the Extension and then try out "http://en.wikipedia.org/wiki/Wikipedia:About" page to see how it changes the original wiki page by integrating relevant videos from YouTube.

Cheers,

Akshit Agarwal (Co-Founder, Wibe)

Cool, But What Happens if Youtube is inaccessable? Wibe Messes up Chrome. Maybe we could integrate it into Wiki by having a <Youtube> Tag

Example:

Text Text Text <Youtube HTML= "https://www.youtube.com/watch?v=98uDPo7ZjVI">

Appears Like;

Text text Text [Youtube Video]

Just a Thought, TitusFox'Tribs 15:58, 21 July 2014 (UTC)[reply]

This cannot work with Wikipedia. First, you cannot embed external videos in a wiki article, unless they are explicitly published under a free license. 99% of the videos on YouTube are copyrighted and unsuitable for inclusion in Wikipedia. Second, even linking to such videos in the External links section of an article would not work without direct user supervision. Per WP:YT "Many videos hosted on YouTube or similar sites do not meet the standards for inclusion in External links sections, and copyright is of particular concern. Many YouTube videos of newscasts, shows or other content of interest to Wikipedia visitors are copyright violations and should not be linked. Links should be evaluated for inclusion with due care on a case-by-case basis." (emphasis mine) This means you cannot just automatically link to a bot-generated collection of videos in an article - they will be most likely either not completely relevant or possible copyright violations. 2Flows (talk) 16:53, 21 July 2014 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=617970371"