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 Technical 13 (talk | contribs) at 22:12, 24 June 2014 (Oppose (deprecated elements): So, it's okay to have pages with all kinds of missing content because browsers are dropping the elements?). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Revision as of 22:12, 24 June 2014 by Technical 13 (talk | contribs) (Oppose (deprecated elements): So, it's okay to have pages with all kinds of missing content because browsers are dropping the elements?)(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. TitoDutta 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. --TitoDutta 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.

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)
  16. Qualified support per SFB. Λυδαcιτγ 03:47, 22 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 (talkcontribs) 14:09, 13 June 2014 (UTC)
    How do you propose we discourage it as a practice without notifying the user that they are doing it? It has no effect on readers (unless FireFox 31 doesn't support these tags at all for example and all of the pages with these tags fail to render, then it would be a major problem that we weren't prepared for) other than a positive one as we won't be turning them away because things are broken. So, this only effects those that edit. I dare say that "most" 'plain users' aren't familiar with HTML elements and most likely won't be adding the bad tags to start with; even if there are a couple that do, a simple warning with a table that says "rst are obsolete, please use xyz instead" is a lot friendlier and efficient than them trying to figure out why their code isn't working because they read some tutorial someplace on SE or something and the latest version of IE or whatever browser they are using doesn't render that element anymore. — {{U|Technical 13}} 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)
  7. Opposed. The replacement aren't as easy for users to understand it seems. We abandoned formatting tables and later re-embraced. No sense in removing <big> while keeping <small>. It also very much bloats the wikitext. I wrote a table tags -> CSS convert and needed to limit the CSS expansion to keep some readability. About as stupid as the MiB vs MB issue. — Dispenser 21:42, 24 June 2014 (UTC)
    • How do you figure the replacements aren't as easy for users to understand? I must've offered help to a dozen or two users to get there signatures up-to-date in the last couple weeks, and I've not one that has objected to making the change (there is one pending that said they would "think about it", and if they choose not to accept my assistance, so-be-it, the ratio of better than 10:1 is fine by me). We haven't tried yet (which is what this RfC is suppose to facilitate, giving it a try. This has nothing to do with tables, which are very much still supported. I'm not sure why the W3 dropped big but kept small, that's a good question, but it's not the question here because content wrapped in small tags doesn't disappear from the page. Are you saying you think that pages that can't be read by some users on some browsers because these HTML elements are dropped is okay? I thought Misplaced Pages was suppose to be accessible and readable by everyone? — {{U|Technical 13}} 22:12, 24 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)
Why should I do that? You argued that it would be impossible to make such a simple change, and when faced with evidence to the contrary you try to put the onus back on me. Why don't you get off your arse instead? Eric Corbett 22:52, 21 June 2014 (UTC)
@Eric Corbett: "Why should I do that?" You don't need to: my reply was directed as much at Dustin V. S. as yourself: Dustin was the one who asked 'how does SineBot know when to sign unsigned "posts" then?', and you were the one who said that it was 'one of those secrets that we mere peons are not privy to' - I was merely offering a means by which you could find out. "You argued that it would be impossible to make such a simple change" - I said nothing of the sort, and certainly didn't use the word 'impossible': I offered three possible scenarios as to why it might be difficult. "faced with evidence to the contrary" - since Slakr seems to have overcome that difficulty, I say kudos to Slakr. "you try to put the onus back on me" - all I did was suggest that you ask Slakr how SineBot decides what to sign and what to leave alone. "Why don't you get off your arse instead?" - I don't care how SineBot works. I might not always sign my posts, but I fail to sign less than 5% of the time. SineBot does a pretty good job, all things considered; I'm not complaining about it. --Redrose64 (talk) 23:43, 21 June 2014 (UTC)
I would actually consider asking Slakr about it, but since you have already placed a user page link above, I do not think it will be necessary. Dustin (talk) 23:53, 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)
Yep, exactly. --AmaryllisGardener 23:53, 21 June 2014 (UTC)
I am going to be waiting in the enlistment line to protest. Those two Flow project test talk pages are just the saddest examples of design imaginable. Those dogs need to be taken to the pound. Fylbecatulous talk 12:58, 22 June 2014 (UTC)
I'm surprised there isn't a ban on bad-mouthing Flow. Anyway, if anyone really objects to tildes, they can always click the pencil-and-wiggle up at the top, like this: --Peridon (talk) 17:39, 22 June 2014 (UTC) which gives you a dash for free along with the tildes.
But why should you have to click anything? Why isn't it automatic? Eric Corbett 21:51, 22 June 2014 (UTC)
It's probably this simple: you can edit your posts later. Sites where you have no option to correct a post can auto-sign - no change possible except by moderators. Here, you can post in two parts of a thread in one go - with auto sign, where's it going to sign? It's going to look really clunky if you correct 'fro' to 'for' and find a new sig in the middle of a sentence - or even two or three if you missed things while correcting the first time. Peridon (talk) 10:08, 23 June 2014 (UTC)
With all due respect, that's a pretty silly objection. Eric Corbett 17:12, 23 June 2014 (UTC)
How is it silly when we often have a legitimate need to amend our posts? BethNaught (talk) 17:27, 23 June 2014 (UTC)
(edit conflict) Not an objection - a likely explanation. I can see quite some difficulty in auto-signing on a talk page. Listing in a History list is easy - but, as I pointed out, do you really want every addition of a missing bracket or correction of hte or yopu to have a sig attached on the page? And when there is more than one location for these corrections, which gets signed? The lot, or none? I would think THEY would have brought it in if it could be done easily. The best attempt seems to be SignBot - and that is hit and miss. I'll put a note at Technical to see if they have any ideas. Peridon (talk) 17:39, 23 June 2014 (UTC)

Someone could probably write a MediaWiki extension that automatically signs posts when a user saves a page, using much the same algorithm that SineBot does. However, a) due to the nature of wikitext, it wouldn't be perfect, and b) fairly soon we will have Flow, which will always sign posts correctly. There are a lot of things that we can't do because we are tied to wikitext, and perfect post-signing is one of them. — Mr. Stradivarius 02:07, 24 June 2014 (UTC)

@Eric Corbett: Discussion pages aren't forums, nor vice versa. Numerous formats exist for discussion pages and afford more flexibility than forums (i.e., no need for specialized programming knowledge) to make them whatever they need to be for improving the encyclopedia. Given this freedom, the general convention (i.e., the guideline) is that if someone will likely want to know who added (or changed, or WP:REFACTORed, etc...) something, you mark it in a way concordant with whatever format is in use on that discussion page. --slakr 06:03, 24 June 2014 (UTC)
One of the things that's always puzzled me about WP is the constant eagerness to find reasons not to change anything. Eric Corbett 11:25, 24 June 2014 (UTC)
I hope Slakr weighs in. I raised this question years ago, and was told it was harder than one thinks, for reasons that have been mentioned here. However, sinebot seems to have figured it out, so I'm interested in learning why it is that sinebot can do it right, not making the mistake or re-signing when you re-edit your own post, not making the mistake of signing when you post at pages where you aren't supposed to sign, etc. yet we are supposed to believe that a user can figure out the coding, but a developer cannot. Something doesn't add up. If Flow were really two months away, it would be one thing, but Flow seems to be like Brazil, the country of the future, and it will always be so.
I didn't know that, but was noticing it wasn't being signed, and wondering if there were some hurdle. Oh well, takes away a bit of the point, but not all of it.

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)
  2. Semi-support (first renaming only, i.e. years to include an indication such as AD or CE) – including up to three digits. But oppose renaming of articles on the numbers to remove the disambiguator: that would be unnecessary. However, I support that the freed up number like 5 become redirects to the correspond 5 (number) etc. On matters like this, a uniform convention should be the objective. —Quondum 23:49, 21 June 2014 (UTC)
  3. Support first half per Quondum. The current situation is truly awkward and needs to be solved. --cyclopia 22:05, 22 June 2014 (UTC)

Oppose

  1. Oppose for consistency's sake. --AmaryllisGardener 23:37, 21 June 2014 (UTC)
  2. . A year is not a number. A year is a space of time conventionally designated by a number, conventionally written as an cardinal number, but actually meaning the first year of the particular era. DGG ( talk ) 05:47, 22 June 2014 (UTC)
  3. Oppose for now. To much drama creation potential. You first need to solve the harder problem of AD vs. CE. --Stephan Schulz (talk) 22:07, 22 June 2014 (UTC)
    We already have a precedent: 1 BC, 50 BC etc. Given this, do you anticipate it to be the source of a holdup? —Quondum 23:07, 22 June 2014 (UTC)
  4. On balance, Oppose. I do see the point you're making, but we need to consider what people are likely to be thinking when they type a number into the search box. My suspicion is that people who are able to type '5' or '99' probably have an idea what these characters represent as numbers. When I look at 5 (number) I certainly see a lot of stuff, but it's of the form "the third prime number" or "there are five Exceptional Lie Groups" or "the atomic number of Boron", and so on. These sorts of things are certainly true, but I imagine they're more likely to be encountered as part of searches for prime number, Exceptional Lie Groups, Boron, and so on. The only interesting stuff that is not "accidentally" true of "5" is the history of the glyph. I might be persuadable, but I'm not persuaded so far. RomanSpa (talk) 06:39, 23 June 2014 (UTC)
    Of course you see mathematical information when you look up a mathematical object. How is that unhelpful or unreasonable? I just don't understand this objection. --NYKevin 01:51, 24 June 2014 (UTC)
  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)

Polls are evil

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

Restoring sortable tables initial order

I've come across this problem many times and thought I'd discuss it here. There is a sortable table. I click on a field to see it in a different order, then I click on another and then I decide to go back to the original order. There is no way of doing it... is there? Maybe there should be some sort of a button or link to restore the original sorting of the table? What do you think? Le Grand Bleu (talk) 04:46, 23 June 2014 (UTC)

There isn't indeed. The original sorting is 'unsorted' or 'random' or 'sorted by a human'. I don't think we should have a state in the sorter that reflects that, it seems like an interface workaround to a problem that shouldn't really exist (if you human sort correctly and annotate the table correctly). —TheDJ (talkcontribs) 18:58, 23 June 2014 (UTC)
I think that the only "button" for restoring the original order is the "reload page" button on your browser. WhatamIdoing (talk) 19:30, 23 June 2014 (UTC)
I've noticed this, and occasionally thought it would be useful, but given that I can reload the page as WhatamIdoing notes, and that is extremely easy, I can't justify any time spent to find a solution.

Average edits per day

Can you please add "Average edits per day: " (calculated by "number of edits"/"number of days since account registration") in Special:Preferences under "General" next to "Number of edits: "? Average edits per day are good to know for anyone who strive after Misplaced Pages:Service awards. --David Hedlund (talk) 19:56, 23 June 2014 (UTC)

You can see that in the X!'s Tools (look at the "Ø number of edits per day" in the top section) – https://tools.wmflabs.org/xtools/ec/?user=David%20Hedlund&project=en.wikipedia.org 2Flows (talk) 20:19, 23 June 2014 (UTC)
Thank you! @2Flows: --David Hedlund (talk) 06:16, 24 June 2014 (UTC)
How would this be useful? I can some use for total edits and length of time, but not the overall average. ~ J. Johnson (JJ) (talk) 20:41, 23 June 2014 (UTC)

"Sharemap" link presentation

At Panama Canal Railway, and presumably in other places too, there is a link to an "interactive version" of a map that is presented as an internal Misplaced Pages link but actually dumps out to an external commercial ad-driven site (sharemap.org). Behind the scenes, this link seems to invoke a special "sharemap"-specific syntax, which I know nothing about. Nevertheless, this unexpected behaviour needs fixing, I suggest, by changing this "sharemap" thing to show as an external link. 86.179.0.72 (talk) 20:46, 23 June 2014 (UTC)

Translation of earliest recorded cuneiform advice into other languages?

Please let me know where I can find help translating Siduri's Advice (Fill your belly. Day and night make merry. Let days be full of joy, dance and make music day and night. And wear fresh clothes. And wash your head and bathe. Look at the child that is holding your hand, and let your wife delight in your embrace. These things alone are the concern of men) from the Epic of Gilgamesh into other languages? I have current drafts for many languages at: Talk:Epic_of_Gilgamesh#Translation of Siduri's advice into other languages but I do not know if these translations are correct.

Once I have the correct translation confirmed, I/we intend to include the translation in an image that can be used on the Epic of Gilgamesh and Siduri wikipedia pages for that language.Gilgamesh-for-the-World (talk) 22:39, 23 June 2014 (UTC)

@Gilgamesh-for-the-World: The editors at Misplaced Pages:Reference desk/Language may well be able to help you. — Scotttalk 15:13, 24 June 2014 (UTC)
Wonderful, thank you Scott.Gilgamesh-for-the-World (talk) 21:28, 24 June 2014 (UTC)

Free semi-auto edit bots for GNU/Linux

"AutoWikiBrowser (often abbreviated AWB) is a semi-automated MediaWiki editor for Windows XP and later, designed to make tedious repetitive tasks quicker and easier. (AWB also functions reasonably well under Wine on Linux but this is not officially supported.)" - https://en.wikipedia.org/Wikipedia:AutoWikiBrowser

I cannot find a single software for GNU/Linux in https://en.wikipedia.org/Wikipedia:Tools/Editing_tools#Semi-auto_edit_bots

Are there any free software development in progress that might not be on that list? --David Hedlund (talk) 06:18, 24 June 2014 (UTC)

Categories: