Misplaced Pages

:Village pump (proposals) - Misplaced Pages

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.

This is an old revision of this page, as edited by Redrose64 (talk | contribs) at 22:32, 21 June 2014 (→Signing posts: why not ask Slakr?). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Revision as of 22:32, 21 June 2014 by Redrose64 (talk | contribs) (→Signing posts: why not ask Slakr?)(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


« Archives, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Centralized discussion
Village pumps
policy
tech
proposals
idea lab
WMF
misc
For a listing of ongoing discussions, see the dashboard.

Watch also all redirects to a page

There is consensus that this would be a good optional tool to have. Number 57 10:05, 20 June 2014 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The proposal

For each page on the watch list, I would like to be able to choose whether all redirects to it should be watched too, without having to add them to the watch list. I would be notified about any new redirects to the page and they would become watched automatically (without a new entry being added to the watch list).

Motivation

Imagine that you watch Aaron Basketeer. Later, a redirect to it, Aaron basketeer, is created. After some time, the new redirect is changed to an article with nonsenses. Without the proposed feature, you will not be able to catch this change, while readers searching for "aaron basketeer" will end up on the bad article.

Support

  1. Proposer. Petr Matas 01:17, 16 May 2014 (UTC)
  2. I think this would be useful. –Quiddity (talk) 00:37, 17 May 2014 (UTC)
  3. I actually don't think this is a bad idea and perhaps would be rather useful. →Davey2010→→Talk to me!→ 02:58, 20 May 2014 (UTC)
  4. Assuming it's optional and opt-in. -- King of ♥ ♦ ♣ ♠ 23:24, 22 May 2014 (UTC)
  5. Support; would be a useful feature. APerson (talk!) 00:38, 24 May 2014 (UTC)
  6. Support. Not something I'd use, but I understand why some people would benefit. I don't think it should be opt-in — we should be given the option of watching all redirects. It seems a bit of extra work to program (with no particular benefit that I could see) if someone had to check a gadget or preference in order to have the option of watching redirects. After all, the proposal is asking that this be presented as a possibility when watching a page. Nyttend (talk) 15:06, 27 May 2014 (UTC)
  7. Support as opt-in. --AmaryllisGardener 19:48, 30 May 2014 (UTC)
  8. Support - So long as it is only something like a button you can choose to use or not use, what is there to lose? It sounds alright to me! I might think a little bit more about it if it was one of those pages with 50+ redirects, but I still like the idea. I am not sure how it would apply to section links though. Dustin (talk) 04:12, 13 June 2014 (UTC)
  9. Support It won't crowd your watchlist up since unlike regular articles it won't be regularly changed. This could be useful at times. Much easier than clicking "what links here" and adding each existing redirect to your watchlist individually. Dream Focus 09:02, 18 June 2014 (UTC)

Oppose

  1. Oppose, not really needed. GenQuest 04:20, 16 May 2014 (UTC)

Comments

  • Comment from Titodutta: Some comments
  1. If it is optional, then it is fine. Nothing should be forced.
  2. Imagine that you watch Aaron Basketeer. Later, a redirect to it, Aaron basketeer, is created. After some time, the new redirect is changed to an article with nonsenses — it happens very rarely.
  3. On the other hand, there are many pages with multiple/many redirects. So, by adding redirects to your watchlist, you'll badly increase your watchlist size.
  4. If someone change a redirect to an article, that can be CSD-ed as duplicate content.
    @Titodutta: The redirect could be also just retargetted, which will not trigger the WP:CSD process, I think. Petr Matas 02:17, 16 May 2014 (UTC)
  5. Finally, bot can handle such problematic/disruptive edits.
    @Titodutta: Can you provide a link to the documentation of such bot, please? Petr Matas 02:17, 16 May 2014 (UTC)
So, for now, I am not very interested in this proposal. Tito☸Dutta 02:00, 16 May 2014 (UTC)
  • I am replying here— the redirect could be also just retargetted, then we need to see if it is a valid re-targeting or not. I generally take redirects to RFD before redirecting. Can you provide a link to the documentation of such bot, please? — I do not any, most probably there is not one at this moment. --Tito☸Dutta 02:22, 16 May 2014 (UTC)
  • Idea/thought - I see the proposal as you click to watchlist something, and a dialogue asks if you'd "...also like redirects to this article added to your watchlist?", or similar. But as another suggestion, something kept on a talkpage (amongst the banners/article history) that is updated by a bot task, working and looking similar to WP:Article alerts. This could provide this type of information, and other important data, in a collapsible box that isn't intrusive. - Floydian  ¢ 00:21, 23 May 2014 (UTC)
    • I think this is a good idea. The history of redirects to the page would be gathered in the collapsible box for anybody's future reference and each addition to the box would trigger the watchlist system naturally. Futhermore, this solution does not require any modification of the MediaWiki software. Petr Matas 13:02, 2 June 2014 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Edit notice for deceased Wikipedians

I propose that a way to add an edit notice to the talk pages of deceased Wikipedias be implemented. This will give a visual indication that messages left for this user will never have a response from the user. -- 65.94.171.126 (talk) 11:25, 7 June 2014 (UTC)

I don't believe that it would be possible (although I could be wrong) to have such an editnotice displayed automatically, but it would definitely be possible to go around creating editnotices for talk pages of deceased users. We could have the editnotice be simply {{Deceased Wikipedian}}. Nyttend (talk) 19:27, 8 June 2014 (UTC)
I think it would be dangerous per WP:BLP or WP:OUTING to have such a notice (I realize we're using it already). For Wikipedians who we know to be deceased (i.e. not editing any more) why not just add {{retired}} instead? Ivanvector (talk) 14:53, 16 June 2014 (UTC)
  • Why, Ivan, do you think it would be dangerous? In order to be marked as deceased, a reliable source is required just like in any other BLP article. I see no issues there, but welcome your insight. Nyttend, it would be easy to write a script that would add a notice similar to an editnotice if a user's userpage has the {{Deceased Wikipedian}} template on it && that userpage was fully protected. This would accomplish this goal without creating a bunch of editnotices around the wiki and without putting editors at risk of being intentionally harassed by being marked as deceased (since it would require an admin to protect the page or add the template to an already fully protected page). There could be other safeguards put in place if so desired. If there is community consensus for such a script, I'll happily write it. — {{U|Technical 13}} 15:30, 16 June 2014 (UTC)
  • Apologies, I've misread the proposal. On the surface I see the potential for harm from a person's private information (their death) being published here, but I see also that there's an existing community tradition about this, along with well-developed process. Having {{Deceased Wikipedian}} plus full-protection seems like good criteria, as it ensures an admin has reviewed the case. Ivanvector (talk) 18:52, 16 June 2014 (UTC)

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

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

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

Oppose (deprecated elements)

  1. No. Wikitext != HTML. Legoktm (talk) 05:34, 13 June 2014 (UTC)
    In the context of how MediaWiki handles these HTML tags, they are equal, as they are simply whitelisted HTML. Now that these tags are obsolete in HTML5 (which is the standard output now), they are invalid. To maintain obsolete tags and attributes as valid wiki markup, we would have to translate them to contemporary HTML/CSS. That makes issue a more fundamental one, where we need to investigate whether these tags are indeed regarded as 'official' wiki markup. — Edokter (talk) — 09:52, 13 June 2014 (UTC)
    Can't HTMLtidy or something similar convert the font tags? –xeno 10:55, 13 June 2014 (UTC)
    Tidy is of no use; its purpose is to fix invalid html structure. There was once code in the html pre-processor to convert old html attributes to CSS, which was reverted due to some minor side effects. But that would be the proper place. — Edokter (talk) — 11:58, 13 June 2014 (UTC)
    Plus, as Edokter wrote four months ago, not only is HTMLTidy no longer being maintained, it predates HTML 5. This means that it is probably unaware of all the HTML 5 obsolescences. Under HTML 4.01, the FONT element is merely deprecated, not obsolete, and deprecation of a feature doesn't mean "get rid of this because it no longer works" but "it is advised not to do it this way because it may stop working one day". There aren't actually that many obsolete features of HTML (that which were once part of the standard) that have ceased to be supported by browsers. <NEXTID> and <PLAINTEXT> are two of them; <FONT>...</FONT> isn't. --Redrose64 (talk) 12:47, 13 June 2014 (UTC)
    Right. Tidy isn't right solution. We know it sucks :). Doesn't mean we can't use something else. Legoktm (talk) 22:58, 13 June 2014 (UTC)
    • I'm currently not asking to convert existing uses, as I've seen that battle fought in the past at WP:BAG (IIRC) and apparently some think it falls under WP:COSMETICBOT. Once there is a consensus that we shouldn't be adding new uses because it will inevitably break the site, then we can discuss if the existing uses of these "bad" codes should be cleaned up, and how (I was thinking the best way would be to let the core developers do this since I'm sure that it is something that all wikis using this software would want/need). — {{U|Technical 13}} 12:12, 13 June 2014 (UTC)
  2. Not necessary and can apparently be done in the html pre-processor when it is. –xeno 12:51, 13 June 2014 (UTC)
    Your load times aren't bad enough already? If we fix the templates, and we fix our signatures (which are just templates stored in core inaccessible to anyone but the user), and we break the bad habits of users that are adding these code which could quit working at any time, then the processor isn't going to have to work as hard and it won't take as long for pages to save and load. Forcing the parser to fix out mistakes is a band-aid and a bad idea. — {{U|Technical 13}} 13:36, 13 June 2014 (UTC)
    The parser already does that... Don't worry about performance. Legoktm (talk) 22:58, 13 June 2014 (UTC)
    You seem to be overlooking the Misplaced Pages:Don't worry about performance#Editors still have a role to play clause. — {{U|Technical 13}} 02:21, 14 June 2014 (UTC)
    I am not sure anybody is going to make necessary changes to the preprocessor. One day one of the major browser will simply stop supporting them and the encyclopedia will become less readable. Ruslik_Zero 13:49, 13 June 2014 (UTC)
  3. Oppose, I say we should discourage it as a practice, but we should not be bothering 'plain users' with this kind of stuff. Especially since it's still used in templates etc all over the stuff. I'd be interested in having the edit filter gather some logs on how much new additions there are being made in general, and perhaps to issue warnings to sysops/template-editors for uses in Template namespace, but other than that, I don't think this is a problem worth pursuing, the preprocessor should be fixing it wherever possible in my view (other then <center> perhaps and a few other related special cases). —TheDJ (talk • contribs) 14:09, 13 June 2014 (UTC)
    How do you propose we discourage it as a practice without notifying the user that they are doing it? It has no effect on readers (unless FireFox 31 doesn't support these tags at all for example and all of the pages with these tags fail to render, then it would be a major problem that we weren't prepared for) other than a positive one as we won't be turning them away because things are broken. So, this only effects those that edit. I dare say that "most" 'plain users' aren't familiar with HTML elements and most likely won't be adding the bad tags to start with; even if there are a couple that do, a simple warning with a table that says "rst are obsolete, please use xyz instead" is a lot friendlier and efficient than them trying to figure out why their code isn't working because they read some tutorial someplace on SE or something and the latest version of IE or whatever browser they are using doesn't render that element anymore. — {{U|Technical 13}} 14:46, 13 June 2014 (UTC)
  4. No. How am I supposed to make something Huge in an editnotice, or a talk page message, or something like that? Maybe these old pieces of code aren't good for "formal" uses, but they get the job done simply and don't hurt anything in informal stuff like user talk messages and wikiproject pages. Perhaps its could be accompanied by something such as the suggested edit filter, so that HTML-savvy editors can come and clean up such uses in mainspace and templatespace, but we shouldn't have it add warnings after every use. Nyttend (talk) 01:04, 14 June 2014 (UTC)
    Can't you increase the font size with the span tag, Technical 13? --AmaryllisGardener 01:15, 14 June 2014 (UTC)
    @Nyttend: Aha, Like this! Code: <span style="font-size: 150%;">Like this!</span> --AmaryllisGardener 01:22, 14 June 2014 (UTC)
    Read Adam Cuerdon's note. Don't force me to ask for help leaving a simple message; you fail to remember that not all of us find span tags simple. Nyttend (talk) 01:50, 14 June 2014 (UTC)
    @Nyttend: I don't intend to be rude, but have you read my response to AC below? --AmaryllisGardener 02:00, 14 June 2014 (UTC)
    Yes. That's why I said "don't force me to ask for help", because people like me are getting along quite fine right now, and the only way you attempt to compensate for messing up my coding is an offer to help: all very fine for me, but it's just slightly more convenient for me to be able to code things by myself instead of asking you for help every time I'm attempting to write an editnotice for my talk page or emphasise something in a message — not to mention all the people who don't know about your offer. And what will you do about tons of uses of these tags in talk archives and old revisions of all sorts of pages? Nyttend (talk) 02:07, 14 June 2014 (UTC)
    Ah, I see what you mean now, I guess we'll just see if we have a choice in the future then. --AmaryllisGardener 02:09, 14 June 2014 (UTC)
    • I understand where you are coming from, but what is going to happen in three or six months or whenever <big> just stops working? All of those edit notices will no longer have big text where it was so important and everyone will be running around like a flock of headless chickens trying to clean up all the requests scattered across the dozen or two VPs and HDs and etc. For the record, what is wrong with {{Big}}, {{Larger}}, or any of the other {{Resize}} templates that we have just for this situation? — {{U|Technical 13}} 02:19, 14 June 2014 (UTC)
  5. Oppose Not everyone knows CSS, and we're basically setting up a situation whereby people will get confusing messages they won't have a hope in hell of correcting. Adam Cuerden 01:38, 14 June 2014 (UTC)
    @Adam Cuerden: I'll volunteer to help people replace their sigs, not just say "Your sig has deprecated tags, change it!". I'm sure others would follow suit also. After all, what's worse, someone having to change their sig and it not be as pretty and work in all browsers, or their sig be pretty in IE but be broken in Firefox and Chrome? Please correct me if I'm wrong. --AmaryllisGardener 01:45, 14 June 2014 (UTC)
    That's a bold claim. You're saying Firefox and Chrome don't support <big> and <font>?
    Well, I don't know about Google, but Mozilla says it may be removed from browsers at any time here. --AmaryllisGardener 02:03, 14 June 2014 (UTC)
    Could be, but probably won't be. And, even if true, does that require us to make a big sweeping change now, when we can't actually defend our position to the users affected? Adam Cuerden 02:08, 14 June 2014 (UTC)
    • It's not a question of if it will be removed, it is a question of how harsh of a result we want that removal to be. Do we want to start warning people now, while still allowing them to save (even with the bad code), and give them an opportunity to ask on literally any of the help desks, noticeboards, VPs, or other forums why they got that message and what they need to do to fix it; OR do we just want them to be removed from the MediaWiki core and then we'll kill our editor retention because people won't be able to edit with the bad code and get frustrated and just quit? Wouldn't it be better to let them use crap, so they can ask for help learning how to avoid the issue? — {{U|Technical 13}} 02:19, 14 June 2014 (UTC)
  6. This needs to be solved on the MediaWiki level, not in individual wikis. It affects all installations, there are many possible strategies; taking action locally is premature, and as proposed too intrusive.
    Personally I've always considered those tags/attributes wikitext features that just happen to be translated 1:1 to HTML. With the changes to HTML this mapping is no longer as simple as a whitelist, but many tags can and should certainly be converted by MediaWiki: wikitext should continue to be simple, and it makes sense to have simple presentational features in the language. Some, like the alignment attributes, may need to be deprectated, but this should still happen on the MediaWiki level where the affected pages can e.g. be categorized automatically.
    Either way, bothering our editors at this point is in my opinion way premature. Amalthea 11:40, 16 June 2014 (UTC)
    I entirely agree that this is an all project issue that needs to be resolved on the software level; however, I don't expect the developers to make it slow gentle transition. I would expect there would be some transition, I would expect it to one day just refuse to save the edit with an error like "Invalid HTML, please check your code and try again" and nothing more. Then I expect it to all just stop working... This proposal is local to this wiki in order to soften that and give all of our editors a chance to improve their habits before this happens. Wouldn't a softer transition be preferred? — {{U|Technical 13}} 12:13, 16 June 2014 (UTC)
    That question is a false dilemma on top of speculation, the softest transition is no change for the editors and MediaWiki handling it all. With lots of open bugzilla issues about it and no clear sense of where this is going we can only speculate, and I don't want to create work or distractions for editors until we know which way this is going. With that big a change we will have sufficient time to prepare, I see no reason for a hasty local decision here. Amalthea 13:55, 16 June 2014 (UTC)

If you didn't notify, notification shouldn't be signed by you or in your contributions

This question on The Teahouse appears to indicate a situation that should be corrected. If a person does not actually notify someone, but the notification comes from him/her by some automatic process, that person's notification shouldn't appear in any history as coming from that person, or in that person's contributions. And yet Twinkle has an automatic notification feature which, in this case, sent a user a notification from himself on his own talk page. He was afraid his account had been compromised.— Vchimpanzee · talk · contributions · 21:09, 13 June 2014 (UTC)

I probably haven't explained this well, so I will include this description of the problem:

Hey Jodosma. Here's what happened. When you list a discussion at RfD using Twinkle it gives you an option to "Notify page creator if possible?"; if you don't take the checkmark out of the box Twinkle then provides a warning for editors of the category through your account automatically when you save. Here, since you are the only editor of Category:Mountain passes of the Appenines, when you listed it for discussion in this edit using Twinkle, you automatically warned yourself the same second (and then yelled at yourself for doing so:-)--Fuhghettaboutit (talk) 00:52, 13 June 2014 (UTC)

— Vchimpanzee · talk · contributions · 21:17, 13 June 2014 (UTC)

Twinkle isn't automatic. It is your responsibility to read the user manual. Legoktm (talk) 23:54, 13 June 2014 (UTC)
Thanks. I'll let them know.— Vchimpanzee · talk · contributions · 15:30, 14 June 2014 (UTC)

Make the background colour of Template:Historical more prominent

The background colour of Template:Historical is very unassuming, and almost blends in with WP's own background. This makes it quite difficult to see. Thus it is often lost visually among other templates. It's a rather vital notice, indicating a page is no longer used, and significantly changes the way a page is used (ie. pages won't be any more). I'm proposing that the background colour be made more prominent, so that the notice itself can be more readily seen. It doesn't look like the talk page gets much traffic, so I have proposed this here.

The discussion is here: Template_talk:Historical#Template_colour. --LT910001 (talk) 09:56, 14 June 2014 (UTC)

Special Symbols dictionary

I have long thought that a major difficulty with ordinary dictionaries is that there is insufficient attention paid to special symbols, such as letters with umlauts, accents and diereses, mathematical, musical and logical notation, notation from chemistry and physics, phonetic signs, and so on. Misplaced Pages has comprehensive lists on other matters, such as Latin phrases, and I think that a comprehensive list of special symbols with clear descriptions of where and how they are used, their relationship to other signs, and ideally, sound files to show pronunciation, would be a much used and appreciated feature.

Of course, there are some problems with listing such items, as often the user does not know what a special accent or symbol is called, and thus where to find them in a list. But, cultures with non-alphabetical languages have ways of doing this, and so can we. In particular, many letters with special accoutrements can simply be shown on the screen, where they could be selected by the user. Other symbols can be arranged according to the category they belong to (e.g. musical, mathematical) or arranged according to complexity of depiction. In the latter case, simple one stroke signs would come first, followed by ones which are more complicated. I know that there are disparate lists to be found in WP but I am thinking of something global, so that a user can look a a sign without knowing what category it belongs to.


I believe that the main reason that most people are completely flummoxed by even the look of mathematical equations is because they look like they are full of “squiggles”. If those squiggles had names and some simple description of what they do, then the reader would not regard them the same way. He or she might not be able to use the equations, or even follow them straight away, but simply by having some idea of what operations are performed by those symbols would give him or her a much better idea of what was being talked about. In other words, if you can READ a sentence with such includes such symbols, then you are a long way towards understanding it. It is the difference between looking at an English paragraph where you might only have a vague gist of its meaning, and seeing the same paragraph in a foreign language, where you have no idea at all.

Let me provide a simple example. The symbol “&” is called an ampersand, but many people do not know that. Thus, many people regard it as a doodle, and often do not know what it is, because they cannot look it up. Putting most such signs into Google, for example, brings up an error message.

Such a move towards clarifying symbols would require a special symbols dictionary with good search parameters. Nothing like that seems to be available, and Misplaced Pages would be the obvious place to compile one, because this is where such symbols must be used in articles where their occurrence is unavoidable, and also because this is where the world now comes to look for answers. And, after all, it is not as if we are talking about compiling another complete Oxford Dictionary. A thousand entries should pretty much cover all the symbols in question.

I am not sure how to go about compiling such a list, and I do not have the computer coding ability to construct search devices and so on. And for that matter, I do not even know if such an idea has been considered before. But at some language groups I visit, there has been considerable interest expressed, and I am wondering if there are any here thinks the idea has any merit. Myles325a (talk) 03:37, 15 June 2014 (UTC)

An interesting idea. One place many symbols are listed and named is the character table for Unicode: --LT910001 (talk) 05:18, 15 June 2014 (UTC)
  • At WP:WikiProject Writing systems, we've been working on getting good coverage of the characters of the major script families - so all of the Latin characters, included accented, all the Greek and Cyrillic, Japanese kana, Braille patterns, and all the Semitic (Hebrew, Arabic, Aramaic, Phoenecian, etc). I've got one Indic family letter, Ka (Indic), with long-term plans to fill out the Brahmi-derived characters. But symbols have sort of taken a back seat in that effort, and could probably use an effort coordinated between Writing systems and some of the technical wikiprojects like Mathematics. I'd suggest heading over to the Writing systems talkpage and put this there; I'm sure that there are people who'd like to engage with some other wikiprojects to get this kind of content out. VanIsaacWS 08:00, 15 June 2014 (UTC)
Very interesting indeed. --AmaryllisGardener 19:15, 17 June 2014 (UTC)

Elevate Misplaced Pages:Redirects for discussion/Redirects from foreign languages to guideline

We are seeing a lot of foreign-to-English redirects showing up on WP:RFD of late, with mixed outcomes, but generally either way with appeals to this essay. It seems to me that we should endorse this essay and promote it to guideline status so as to expedite these discussions. Mangoe (talk) 17:23, 16 June 2014 (UTC)

RfC: Should Template:Geographic reference be split into separate templates for each source?

I have no idea if this belong here but I started an RfC at Template:Geographic reference. Template:Geographic reference is a very extensively used template that, in my opinion, does nothing more than provide a hard-coded instance of ten separate and very loosely connected sources. The RfC asks if we should split the references out into separate templates. I imagine there are technical implications to it but I don't see how this is any difference than all the other templates at TfD where we discuss splitting or deleting. -- Ricky81682 (talk) 22:46, 16 June 2014 (UTC)

Discussion notice

A discussion is occurring at Template talk:Find sources regarding updating the Find sources template with links to the Google News and Google newspapers searches. Interested editors are invited to contribute to the discussion. The discussion is located here. NorthAmerica 08:09, 18 June 2014 (UTC)

Signing posts

Why should I have to remember to append my posts with the clunky ~~~~? Why can't that be added automatically? Eric Corbett 20:18, 21 June 2014 (UTC)

Because sometimes, what you post isn't all new, but a correction to something that you added earlier. Then there are new "posts" to talk pages which should never be signed, such as the addition of a template at the top, or when a thread is moved from the wrong venue to the correct one. --Redrose64 (talk) 20:24, 21 June 2014 (UTC)
Curious how many objections are raised when any change is proposed. I don't end my emails with ~~~~, so why should I have to end my posts with that detritus? Wouldn't at least a step into the 21st century make life a little easier for new editors? Eric Corbett 20:35, 21 June 2014 (UTC)
Wait. How does SineBot know when to sign unsigned "posts" then? Dustin (talk) 20:40, 21 June 2014 (UTC)
Quite. But maybe that's another one of those secrets that we mere peons are not privy to. Eric Corbett 20:43, 21 June 2014 (UTC)
To find out how SineBot (talk · contribs) decides what to sign and what to leave alone, have you considered asking Slakr (talk · contribs), the bot's operator? --Redrose64 (talk) 22:32, 21 June 2014 (UTC)
The actual answer is that there would be no point spending time changing the software, since in a couple of months WP:FLOW goes live, talkpages as we know them become a thing of the past, and signing talkpage posts becomes one with Nineveh and Tyre. If you want to see what talkpages will look like come Christmas, take a look at Misplaced Pages talk:WikiProject Hampshire which has the dubious honour of having been chosen to trial the new-look software. And yes, everyone except the WMF thinks that font size is ridiculously large, but unfortunately someone at the WMF read something, somewhere, that says people work better in giant boldface fonts so it ain't changing. 80.44.183.160 (talk) 21:07, 21 June 2014 (UTC)
Misplaced Pages talk:WikiProject Breakfast is where it's really at. Besides, user talk pages will still around for a while, possibly forever if enough people kick up a stink and climb the Reichstag. I'm curious where in the morass of documentation you say Flow goes live in a couple of months - I thought it would be limited rollout only for 2014. BethNaught (talk) 21:12, 21 June 2014 (UTC)
The rollout date used to be "Mid to late 2014". I didn't realise Maryana had quietly changed the date to 2015 a couple of months ago. 80.44.183.160 (talk) 21:21, 21 June 2014 (UTC)
I don't like the thought of not being able to use a custom signature. That would mean that regardless of what I tried to do, the "V. S." would end up being included. The other stuff sounds helpful, but... Dustin (talk) 21:35, 21 June 2014 (UTC)
I think I read somewhere that there will be a preferred name setting, but I have no clue if that is still on the cards or even where I read it. BethNaught (talk) 21:40, 21 June 2014 (UTC)
Why not just standardise the way that signatures appear? Who needs all the silly upside down stuff for instance? Eric Corbett 21:43, 21 June 2014 (UTC)
Flow will be just like VE, an opt-out disaster, and for much the same reasons. Eric Corbett 21:47, 21 June 2014 (UTC)

RFC: Naming of one and two digit numbers and years

Please consider joining the feedback request service.
An editor has requested comments from other editors for this discussion. This page has been added to the following lists: When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

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 Misplaced Pages, 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, while many more link to its numerical counterpart. 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)

Threaded Discussion

Support

  1. Support as proposer. --NYKevin 21:51, 21 June 2014 (UTC)

Oppose

Polls are evil

Categories: