Jump to content

Wikipedia talk:Manual of Style/Dates and numbers/Archive 116

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 110←Archive 114Archive 115Archive 116Archive 117Archive 118→Archive 120


Gibibytes versus Gigabytes

Discussion moved to /IEC.

Restarting the RFC

(See above section)

Given the issues on the current RFC draft, I propose a simpler version, that is a !voting straw poll, with five questions (will be reworded)

  1. Should WP aim to have a date autoformatting system in place?
    • Sections for support, oppose, neutral
  2. Should dates (including month-day, and full month-day-year dates) be linked to solely invoke WP's current version of date autoformatting, even where there is no other reason to linkignoring all other impacts of that result?
    • This would be a support, oppose, neutral outcome. A brief intro would have the general pros and cons on DA to avoid having to reiterate these in the discussion
  3. How often should month-day dates be linked to the appropriate "month-day" articles?
    • This would have answers of "always", "sometimes", and "never".
  4. How often should year-only dates be linked to the approach year articles?
    • This would have answers of "always", "sometimes", and "never".
  5. When using "year in X" links, should this be in context ("blah in (1900 in x|1900)",), inline ("blah in 1900 (other x in 1900)"), or seealsos?
    • Answers of "context", "inline", "seealso", and neutral.

Getting the answers to these four will clearly tell us how DA is taken, and how the readers would want to see dates links. The date linking questions (last 3) will include points to the arguments already laid down (Greg L's sewer cover challenge, etc.) so that if people agree with that, they can simple !vote "per arguments given". Nothing about bots or all that. Once we have this, then it will be clear how to rewrite MOSNUM. --MASEM 13:27, 19 November 2008 (UTC)

OK, that looks more promising than the previous proposed RfC, but I still don't quite see it. Question 1 is out of our hands. Question 2 probably needs rewording, since I don't entirely understand it. The remaining questions are gross oversimplifications as they stand.--Kotniski (talk) 14:01, 19 November 2008 (UTC)
On Q1, it is not out of our hands in the sense that the devs will only be motivated to fix the problems with the current DA if there is sufficient demand for the feature - it makes no sense to correct if we decide not to use it. Q2 is trying to separate the problems of current DA (what anon/non-pref editors see) from the date linking/overlinking issue altogether, and yes, probably can be rewritten to reflect that - I just don't want to confluence the two different issues, and keep when dates are linked as a separate factor. The other questions are meant to be simple as we need to gauge where consensus is for when dates are to be linked - once that is know we can then craft the language needed for MOSNUM to reflect that as well as consider specific cases if the responses call for only partial date linking. --MASEM 14:09, 19 November 2008 (UTC)
Masem, I'm not being perverse or contrarian, but I don't understand any of the proposals. Can you reword them? (1) Logical issue, since we do have a DA system in place (it's just not used now). (2) I'm confused. (3 and 4) "How often"? (5) Needs rewording. Tony (talk) 14:19, 19 November 2008 (UTC)
Rewording is fine, whatever is needed to make these clearer - I'm trying to get the spirit of the questions down, but making sure to have the right questions that are direct as possible. specifically:
  • On 1, the question is "should we be using "any" DA system on WP? Is it a crutch? Is it useful? That's a variable I see in the talk here. The question presumes that a DA "works perfectly" to meet all needs and avoids any issues.
  • On 2, the question is specifically on the current DA system if we should keep using it or not, strictly focusing on what date output it produces in various cases (and the problems arising from that) and ignoring the fact that it produces links.
  • For the "sometimes" responses of 3 and 4, the RFC would encourage uses to explain when in their responses.
If others are satisfied that there are no other questions, I'll draft the RFC up after a while, and then we can edit the exact nature of the questions to be clear as possible. This RFC should be designed to allow editors to quickly get to speed, supply responses, and go on with other things, which is why I have no qualms editing for clarity. --MASEM 14:39, 19 November 2008 (UTC)
I have copy-edited to invoke. I think I know what ignoring all other impacts of that result is intended to mean, but it will be clear as mud to anyone who hasn't followed this discussion. I would recommend solely and even where there is no other reason to link. Septentrionalis PMAnderson 17:40, 19 November 2008 (UTC)
That's what I mean but better - changed to make the convo easier. --MASEM 17:47, 19 November 2008 (UTC)
This looks great (especially with the proposed changes to question #1). I agree with Septentrionalis that more options might make sense for the final question, but in general this is a step in the right direction. —Locke Cole • t • c 19:18, 19 November 2008 (UTC)
Based on the above input, I've created Wikipedia:Manual of Style (dates and numbers)/Date Linking RFC. Please feel free edit to improve the language or add more choices or whatever, but please do not use it yet to state your opinions on the matters at hand. If you have pre-loaded essays you'd like to link to, please do so (if they are to the contrary, .. uh, we'll figure a way to link them in) --MASEM 19:31, 19 November 2008 (UTC)
Thanks, Masem, for starting this. Should we add an additional question on whether dates should be mass-delinked if consensus says that datelinking should be deprecated? Some people may support changing the guideline without changing all the articles at once. Karanacs (talk) 19:46, 19 November 2008 (UTC)
I'd rather not ask that question - it's mixing up matters. The way I see this going forward is that we run the RFC, get the input, and then figure out what are the next steps. A bot may be necessary then, and if we've shown (for example) DA is depreciate with wide support and only a handful of dates should be linked, I see no reason why a date stripping bot would be problematic - Lightbot et al are only in the crosshairs because there are those that felt no consensus was present on the fundamental date linking issues to proceed forward. We'll have some consensus and thus the task at hand should go smoothly. --MASEM 20:08, 19 November 2008 (UTC)
Thanks, Greg. Now, Masem, I'm still in the dark about No. 1. Do you mean "Should the current proscription on date autoformatting be removed from MOSNUM?"? Tony (talk) 06:34, 20 November 2008 (UTC)
No, whichever way #1 goes does not directly influence the MOS, it only should be reflected back to the devteam to let them know if they should actively pursue a different DA approach, or if their efforts will go to naught here (though if they still want to make it, hey, they can). Basically, almost to a point, this is essentially determining if we should close that one bugzilla bug about DA. The MOS, specifically removing the proscription on DA being deprecated, would only occur if point #2 shows consensus towards keeping the DA as it stands. Now, if #1 shows we want the devteam to provide a better DA, and they do come back and provide that, then we'll change it, but that's not a direct result of the RFC. Again, the removal of "DA is deprecated" will only occur in the immediate future if #2 shows support to keep it around. Hope that helps explain it (and feel free to rewrite as needed if this is confusing) --MASEM 06:53, 20 November 2008 (UTC)
smile: "if this is confusing" - yeah you bet it is confusing! edit: i've transplanted my comment to here. Sssoul (talk) 11:20, 20 November 2008 (UTC)
  • One thing which gets mentioned but never has a proposed independent solution: DA was introduced to provide uniform formats via preferences; preferences are only available to registered editors; use of this preference (is claimed to make/makes) editors blind to format discrepancies within articles. I've never seen any actual stat's on how many editors have the pref turned on, nor on exactly how much impact that pref has on article quality, as opposed to laziness. It would be really great to see that claim substantiated ("editors turn date pref on and miss problems OMG") - but would another approach be to just turn date prefs off (as in, remove the clickbuttons from u-prefs)? That would de-link date-links from date-formats. Franamax (talk) 07:02, 20 November 2008 (UTC)
That option controls the display of time and date in article histories, watchlists, and other Wikipedia listings; it isn't just for autoformatting. --Ckatzchatspy 07:09, 20 November 2008 (UTC)
Time to break that link then, isn't it? I've always made sure that the dtm's I see are as raw as possible. History and watchlists ("personal presentation of editing-relevant data") are one thing - but the notion that this would obscure our presentation to our readership is just intolerable. Editors have no privilege over anonymous readers, in fact they are one level below. That is the first link to sever. Franamax (talk) 08:02, 20 November 2008 (UTC)
It's hardly a "privilege", given that anyone can sign up; editors certainly aren't the only ones who have access. Furthermore, why is there so much disdain for the idea of interface customization? If it causes problems for IPs, we should be looking to improve their access to a feature, not stripping it away from everyone else. This is the 21st century, and every other level of technology is moving forward to make Internet access seamless and personalized. (Just look at operating systems, phones, music players, and so on.) --Ckatzchatspy 08:19, 20 November 2008 (UTC)
No arguments, really. What I'm saying is that if registered editors can set a preference that makes them blind to article problems that our general readership (the great unwashed who only come here to learn something) will definitely see - that is the problem we should solve first. In this case, this is Tony's repeated assertion that date preferences keep our editors from seeing mismatched date formats in our articles and correcting them. I've seen no evidence this is true, beyond the bald assertion - and laziness is an equally valid explanation. Nevertheless, I'm quite willing to concede the point, in which case, let's turn off date formatting within articles so that particular point becomes moot.
And in general, if there is any little bitty thing that gives registered editors an edge over my grandma when it comes to just viewing an article - our general readership comes first and always, all they have to do is click once. You're right, it would be great to have datepref's autoset by the incoming IP address or by local cookies, but that's quite unlikely in the near future. (It's probably on the list, just after "finish the other stuff") In fact, that's one of the reasons I'm hesitant about mass stripping of date links altogether. I don't really buy the "sea-of-blue" argument against (people know what to expect when they click a date-link) and I'm concerned about all the loss of future potential of those existing links (the meta-data argument). As far as the parser goes, it's likely pretty darn easy to uncouple date prefs from the in-article presentation. That's the first place to start, since it also uncouples the various arguments here. Franamax (talk) 08:55, 20 November 2008 (UTC)
I agree with the wording of the draft and look forward to the vote. More should be done to encourage users to create accounts, but that's another discussion. Us defining one date format over the other defeats the purpose of the date preferences. By formatting the dates with links the system will honour user preferences. If that user doesn't have an account or preferences set then they'll see it however the editor formatted it. This way at least those with accounts see formatting according to their preferences. Otherwise NO ONE is likely to see the date in the way they're accustomed. I think it'd be fine to pick a specific format, such as U.S., i.e. MONTH and DAY, however do it with links to honour preferences. I'm not supporting U.S. format or another, but if one needs selected then by all means do so, but I'd specify in the MOS to do it with links, because again not doing so ensures that no one is satisfied. Nja247 (talk • contribs) 12:32, 20 November 2008 (UTC)
Why does the order of the day and the month matter? I am American, yet I can understand 12 July just as well as July 12. I don't see editors clamoring to autoformat words like honor (honour) or organize (organise) so that Americans can see their preferred spellings and everybody else in the world sees theirs. Dabomb87 (talk) 13:32, 20 November 2008 (UTC)
I'm sorry but arguments like 'it doesn't matter' are irrelevant especially when Wikipedia offers a date preference option. Surely it matters when people use dates like 3/11. It causes un-due confusion as some people see that as the 3rd of November versus the 11th of March. Editors may end up un-necessarily go through articles to 'fix' the date formats, whilst another may go back and fix them again. If the MOS says use U.S. formats fine, but do so in links that way preferences are honoured. It makes no sense to have the preference option only to overlook it. My question is how does it hurt for anons to see a date formatted inside links? Nja247 (talk • contribs) 13:51, 20 November 2008 (UTC)
The MOS says don't use dates like 3/11. Use 3 November or March 11. Jheald (talk) 14:19, 20 November 2008 (UTC)
True, but it goes on to say they may be used in tables. I understand this is a limited area, but confusion is still possible. Formatting them avoids the confusion per user preferences. Further, it avoids possible un-needed edits by users who prefer one style over another. I still haven't seen convincing arguments as to why linking is bad. Nja247 (talk • contribs) 14:45, 20 November 2008 (UTC)
We're not talking about dates like 3/11 here, that's irrelevant. All these are arguments that have been gone over and over and over. Editors are more likely to make mistakes if they have date preferences set (since they can't see what readers see), so serious editors should not set them, and are therefore deprived of the "benefit" of seeing dates the way they prefer them in watchlists etc. If you follow the strange logic that if we have something, we must find a way to make it useful, then you should certainly support removing the autoformatting links (or switching off autoformatting), so that all responsible editors can take "advantage" of the date preference option (I put "benefit" and "advantage" in quotes, since the actual benefit is negligible). Too many links hurt (or at least inconvenience) "anons" (99.99% of our readership) because it makes it more difficult for them to identify and follow the links that are likely to be relevant to their understanding of the topic (see WP:OVERLINK). Dabomb gets it exactly right - if anyone really cared about this sort of thing (as opposed to just opposing change in principle because it makes them feel uneasy) they would be - and would for a long time have been - making similar proposals about spelling and about words that have different meanings in US and UK English. As I keep saying, this whole discussion is motivated by people trying to find solutions to a complete non-problem.--Kotniski (talk) 14:30, 20 November 2008 (UTC)
That makes absolutely no sense to me, sorry. If the date is linked it'll appear to anons in exactly the format the editor made it (either DD MM or MM DD per MoS). The same is also true if it's not linked, i.e. it'll show up exactly as formatted whether linked or not to anons. The only difference in the former instance is that editor's with preferences set see the date how they prefer. I definitely require an example of how having it otherwise robs me of any benefit or advantage. (Note: I've received an example, though I believe non-lazy and careful editors will ensure article consistency and not overlook these things -- I do). Also I'd enjoy reading the details of whatever survey/report you're citing where anon's, et al, have complained that date links cause confusion. Nja247 (talk • contribs) 14:45, 20 November 2008 (UTC)
You've apparently missed the point about 99.99% of Wikipedia users not having preferences set. From their point of view, all that date linking does is make for a flood of meaningless links. It doesn't help at all, it just confuses our readership. --Pete (talk) 23:13, 20 November 2008 (UTC)
  • Looks like it's time to make available the list of problems with DA, as put about for the past few months. Perhaps you missed this, Nja.
Disadvantages of date-autoformatting


  • (1) In-house only
  • (a) It works only for registered (Wikipedian) users who have set their date preferences and are logged in.
  • (b) To our readers out there, it displays all-too-common inconsistencies in raw formatting in bright-blue underlined text, yet conceals them from WPians who are logged in and have chosen preferences.
  • (2) Avoids what are merely trivial differences
  • (a) It is trivial whether the order is day–month or month–day. It is more trivial than color/colour and realise/realize, yet our consistency-within-article policy on spelling (WP:ENGVAR) has worked very well. English-speakers readily recognise both date formats; all dates after our signatures are international, and no one objects.
  • (3) Colour-clutter: the bright-blue underlining of all dates
  • (a) It dilutes the impact of high-value links.
  • (b) It makes the text slightly harder to read.
  • (c) It doesn't improve the appearance of the page.
  • (4) Typos and misunderstood coding
  • (a) There's a disappointing error-rate in keying in the auto-function; not bracketing the year, and enclosing the whole date in one set of brackets, are examples.
  • (b) Once autoformatting is removed, mixtures of US and international formats are revealed in display mode, where they are much easier for WPians to pick up than in edit mode; so is the use of the wrong format in country-related articles.
  • (c) Many WPians don't understand date-autoformatting—in particular, how it differs from ordinary linking; often it's applied simply because it's part of the furniture.
  • (5) Edit-mode clutter
  • (a) It's more work to enter an autoformatted date, and it doesn't make the edit-mode text any easier to read for subsequent editors.
  • (6) Limited application
  • (a) It's incompatible with date ranges ("January 3–9, 1998", or "3–9 January 1998", and "February–April 2006") and slashed dates ("the night of May 21/22", or "... 21/22 May").
  • (b) By policy, we avoid date autoformatting in such places as quotations; the removal of autoformatting avoids this inconsistency.

Tony (talk) 15:01, 20 November 2008 (UTC)

Tony, is this in your userspace or essayified anywhere? It would be good to include a link to this in the RFC as to avoid having to rehash this points in discussion. --MASEM 15:07, 20 November 2008 (UTC)
Masem, it's all over the place. This might be useful, and contains the capped "disadvantages", but as you can imagine, it's completely POV: User:Tony1/Information_on_the_removal_of_DA. Tony (talk) 15:12, 20 November 2008 (UTC)
That's fine that it's POV - if you see the RFC, we are presenting the statement as to add the language "DA is deprecated for various reasons" to MOSNUM and asking people to support or oppose that statement. Your reasoning highlights most of the issues even if POV-ish, and makes complete sense since you're the largest proponent of removing DA. --MASEM 17:52, 20 November 2008 (UTC)
My advocacy has since been overtaken by the voices of many others. Tony (talk) 10:08, 22 November 2008 (UTC)
  • Can we please keep points in discussions clear regarding whether they are about DA or DL? The Aug/Sep decision was made with most headings being about DL, and barely a mention of DA --JimWae (talk) 10:31, 22 November 2008 (UTC)


Time to vote on something

  • KISS: Enough arguing about the shape of the negotiating table. Maybe we’re being overly ambitious by trying to agree upon the wording of too many points at once. How about we just vote on one point at a time (and keep it simple too). The wording of other questions will likely become clearer as we progress through this. How about this one:

Should “this date throughout history” articles such as April 1 be routinely linked to within articles?

Who’s up for this? Let’s settle something and move on. Greg L (talk) 02:43, 21 November 2008 (UTC)
    • Since we are looking to evoke mechanisms to get as many eyes as possible onto the issue at hand, addressing issues one at a time would be slow and wasteful. The RFC as is now seems to be in shape to bring it to wide announcement in a few days barring any major objections. --MASEM 03:02, 21 November 2008 (UTC)
  • Ha. Slower and more wasteful than all the monkeying around above?!? Not possible, Masem. All we have is a bunch of gaming and brinkmanship going on; nothing really productive. If you don’t want to vote, that is you’re right. In the mean time, my above proposal stays active and I encourage others to help finally put this one, drop-dead-simple issue to rest once and for all. Greg L (talk) 03:18, 21 November 2008 (UTC)
  • The point of doing the RFC properly is to get consensus to put an end to all the issues that have been raised in the past month or so. Doing it this way will not achieve the same means; that's why the whole RFC process was put in place to begin with. --MASEM 03:28, 21 November 2008 (UTC)
  • Very well. And this doesn’t prevent any of that. It allows people to (*shudder*) express their opinion. Do what you want, but stop pretending to dictate where, how, and when others may express their opinions here. I believe, this is where you shout “Greg L is asking others about their opinions on something! Shut him up. Shut him up!” Greg L (talk) 03:31, 21 November 2008 (UTC)
  • I'm not trying to prevent anyone commenting. I do however want to make sure that a proper RFC is completed so that we aren't coming back here after a month of whatever decision is made with people saying "I don't like that!" and not having anything to point them to that said consensus at a wide scale was reached. Otherwise, you have a process that repeats over and over again. Go ahead and comment here, I absolutely can't stop you, but this issue needs a calm, rationale approach to resolve appropriately. --MASEM 03:41, 21 November 2008 (UTC)

(undent)"... not having anything to point them to that said consensus at a wide scale was reached." er ... is the RfC meant as a poll or as a consensus-reaching process? those are two different things, and i believe when you started the draft you were talking about a "straw poll" (or maybe that was Shereth, sorry); to me it's a major difference that needs to be kept in mind. a poll might show widespread disagreement, but that doesn't mean that no consensus can be reached; whether it's "wide-scale" or not depends on how many people stick around for that part. the RfC on birth/death-date links, for example: of course "there's no consensus", since it was treated merely as a poll; even the person who launched it ignored attempts to reach a consensus. obviously you can't make large numbers of poll "voters" stick around en masse for the consensus-forging part; only a few will stick around, and then people can later complain that whatever was decided wasn't a "community-wide consensus". which isn't the point, is it. Sssoul (talk) 09:36, 21 November 2008 (UTC)

  • "I do however want to make sure that a proper RFC is completed so that we aren't coming back here after a month of whatever decision is made with people saying: 'I don't like that!' " Well, you are opening up a can of worms here - nothing, but nothing will prevent what you fear, because it has happened already, and there's every chance it will happen again. Whichever way this RfC goes, I am prepared to wager that the 'losing side' will mount an even more powerful 'I don't agree with it' campaign, so you had better be ready for that. Ohconfucius (talk) 15:08, 21 November 2008 (UTC)
  • Conditional agreement that
  1. This consensus is dependent on other consensus related to dates, so it might need to be revisted after the RfC
  2. Provided that autoformatting is deprecated (which has been claimed, but not yet established), dates should not be routinely linked. This does not, however, necessarily discourage certain dates in an article being linked. If you want to extend "routinely" to "ever", this is a strong oppose.
  3. As the term is "routinely", bots should not be used to unlink dates.
  4. Even if agreed to, this would not reduce edit wars, because of the term "routinely".
  5. Even if agreed to, this page doesn't have sufficient visibility, so that it would need to be revisited in the RfC.
— Arthur Rubin (talk) 15:45, 21 November 2008 (UTC)
(to Ohconfucius and Greg L) - Sure, no one can pretend that even if a thousand editors showed up to voice a clear consensus (more that 90% !votes in one director), that people will come back to challenge it again. However, compared to what can be shown now about consensus for removing date links, which is based on conversation limited to WT:MOSNUM and to the indirect fact that FAs and other articles have been stripped of dates without complaints, at least this provides a strong consensus that can be directly linked to, and those that disagree will have to realize what's been stated already. Of course, consensus can change, and maybe in a year we're revisiting this; that's better than having to argue the point month after month for the same period. It is, of course, expected, that those participating in the current discussion will accept the consensus, as this is a dispute resolution pathway and the RFC is aimed to mediate that. Those that refuse to accept the results if they clearly are against their opinion and still argue against it can be handled by other means (WQA, for example). --MASEM 16:13, 21 November 2008 (UTC)
I don't agree with that assertion. I suspect many of the editors who object to the removal of dates from FAs are willing to abide by the claimed consensus that dates are to be removed, or are objecting here (even though Tony claims the discussion is supposed to be in regard WP:CONTEXT). All that can be realistically said is that there's a weak consensus among MOSNUM regulars. — Arthur Rubin (talk) 17:29, 21 November 2008 (UTC)
My possition is that this !vote cannot establish a Wikipedia-wide consensus, while a formal RfC, properly advertised, can. It's not clear from the phrasing above rather you agree or disagree. — Arthur Rubin (talk) 17:30, 21 November 2008 (UTC)
I think you are agreeing - I'm hoping all those presently aware and that will be aware via the formal RFC notices will understand this should conclude the matter and should accept whatever outcome results. --MASEM 17:33, 21 November 2008 (UTC)
  • All we can do is hold a big RfC, publicize it well, invite lots of comment, identify where the consensus is on various points, and align MOSNUM guidelines with that consensus. There certainly will be editors scurrying out from under the refrigerator a certain percentage of time when articles somewhere are affected. With 48,305,892 users, we’re just playing the odds. And if Lightbot is busy implementing (enforcing) MOSNUM guidelines, a small army of editors will come scurrying here. We will simply have to tell them “sorry, it’s been (thoroughly) discussed and you missed out, and here’s proof of those discussions and that the consensus is valid.” We had better do a good job of documenting this and ensuring we’ve done everything reasonably expected of us to be inclusive because there will always be editors who are more passionate than most who are willing to climb the Reichstag over the issue. (*sigh*) Greg L (talk) 23:05, 21 November 2008 (UTC)
  • This wouldn't even be an issue if twelve editors hadn't decided they could decide for the rest of the community whether date autoformatting was good or bad. The arrogance there is just astonishing. Even something as simple and benign as semi-protection took something over one hundred editors supporting it to implement... (and that was in December of 2005; Wikipedia has obviously grown since then). —Locke Cole • t • c 01:07, 22 November 2008 (UTC)
  • Back to what Kotniski and I were saying in the section above. The onus must be on those who object to the current wording to propose alternative wording for us to discuss on. As the RFC is only a request for comment, fellow editors should not treat this as the 'be all and end all'. Even if there is some consensus on the wider issues, the open-ended nature of some of the questions being asked (such as "when should dates be linked") and the range of acceptable answers will more or less guarantee that the outcome will be similarly open-ended. A proper discussion needs to be held on the exact wording of each outcome. Why doesn't someone just move to a wording when this is possible? To give an obvious example, in the 'Deprecating the current date autoformatting' section, we should move to a unambiguous proposal worded: "It is proposed that the the following text be deleted from the Linking and autoformatting of dates section of the guideline: "Autoformatting: Dates should not be linked purely for the purpose of autoformatting (even though in the past this was considered desirable)"Ohconfucius (talk) 22:45, 22 November 2008 (UTC)

This following comment and its discussion has been copied to Wikipedia talk:Manual of Style (dates and numbers)/Date Linking RFC please comment there.

As for Number 4 on the proposed RfC, I would note that WP:EGG advises to:

"[a]void piping links from "year" to "year something" or "something year" (e.g., [[1991 in music|1991]]) in the main prose of an article in most cases. Use an explicit cross-reference, e.g., ''(see [[1991 in music]])'', if it is appropriate to link a year to such an article at all. However, piped links may be useful:

  • in places where compact presentation is important (some tables, infoboxes and lists); and
  • in the main prose of articles in which such links are used heavily, as is often the case with sports biographies that link to numerous season articles."

I think these are pretty good guidelines for those type of date links that no one has disputed. I would suggest removing number four because it is not really at issue. Lightbot nor his script currently removes these type of links.--User:2008Olympianchitchatseemywork 01:52, 22 November 2008 (UTC)

  • I believe you mean #5 (Year in Field), which true, the linking MOS says to avoid hidden links, but this is not about just the piped version but any version of "year in field" links, which that MOS doesn't give the full answer to. Thus #5 seeks to get the clarity needed for that, which might result in rewording of that section there. --MASEM 12:51, 22 November 2008 (UTC)

This above comment and its discussion has been copied to Wikipedia talk:Manual of Style (dates and numbers)/Date Linking RFC please comment there.

Split proposal

I am proposing to split this MOS into two pages. One for the chronological items and one for the rest of the numbers (which possibly could include merging in the formula page mentioned at the top, but that is orthogonal discussion). The split makes sense as they really are two separate topics.

However, unlike the typical reasons for splitting an article, this one is not only an issue of space (though it is approaching 70KB/KiB) but of discussion of the article. Ignoring the political and religious discussions, there are a score or so editorial topics in Wikipedia that consensus has been difficult to reach even after years and years of discussion. Unfortunately, two of them are on this page:

  • The IEC binary prefixes.
  • Date Linking and automatic formatting.

These two discussions dominate the discussions so much and are responsible for so many edits that nothing else ever gets a chance to be discussed. Separating the pages should fix part of this.

So I propose that the Chronological items article to be split to Wikipedia:Manual of Style (time and dates) while renaming the main article Wikipedia:Manual of Style (numbers) Please comment on this proposal. -- KelleyCook (talk) 15:05, 20 November 2008 (UTC)

It does go in the opposite direction of the trend to rationalise the style guides. Tony (talk) 15:08, 20 November 2008 (UTC)
It would be sufficient simply to create separate discussion pages for these two topics. We seem to have succeeded with the IEC thing; maybe it's time to have another go with the date linking (I tried recently but someone objected). The latter subject is likely to move to a dedicated RFC page soon anyway, so that might be a good moment to officially declare this talk page a date-linking-free zone. --Kotniski (talk) 17:42, 20 November 2008 (UTC)

Full protection

As per a request on WP:RFPP and from noticing the ridiculous amounts of drama on WP:ANI and other locations, I have enacted a full protection on the Wrong Version of this page. I strongly encourage all involved editors to stick to discussion pages regarding this matter, and to immediately cease all large-scale reversions of each other, with bots or otherwise. GlassCobra 20:12, 20 November 2008 (UTC)

units and their definitions

Moved to Wikipedia_talk:Manual_of_Style_(dates_and_numbers)/IEC#units_and_their_definitions

No more.--Tznkai (talk) 19:03, 24 November 2008 (UTC)

Date linking discussions

Note to readers: There are two active requests for comment concerning the linking and autoformatting of dates. The discussions are taking place on subpages of this talk page:

RfC: Three proposals for change to MOSNUM

For this discussion, please see Wikipedia:Manual of Style (dates and numbers)/Three proposals for change to MOSNUM.

RfC: Date Linking RFC

For this discussion, please see Wikipedia:Manual of Style (dates and numbers)/Date Linking RFC.

Note: a discussion of alleged flaws in both RFCs can be found on the talk page of the first RFC.

Incidentally, is there any sign of either or both of these discussions being closed soon? People seem to be talking as if the results are already known.--Kotniski (talk) 10:13, 3 December 2008 (UTC)

Date Formats mdy v. dmy

The way I read the MoS on date formatting is that if the article does not have "strong ties to a particular English-speaking country," then the "the date format chosen by the first major contributor" is what determines the date format.

Therefore, if an article has ties to a non-English speaking country, then that article uses the first-chosen format instead of the format used by that country. I keep seeing articles where the date format is changed because, e.g., "Argentina uses dmy." If the other country does not speak English, then all that matters is how the article started under the MoS.--2008Olympianchitchatseemywork 04:44, 30 November 2008 (UTC)

  • IMO, the guidelines for choosing the most appropriate date format could use some tweaking. It currently gives too much emphasis to grandfathering-in whatever format the first major contributor used. Sure, that prevents editwarring amongst two editors who just must have it their way. But it also locks in often-less-than-optimum formats in some of our articles. Maybe, one day, we can simply look at what date format would be most suitable for any given article and just go with that. If I got my way—and remember, I’m American—I’d just as soon use dd mmm yyyy for most articles except when they are about, or closely associated with, the U.S., then editors would use mmm dd, yyyy format. It’s not complex if all editors simply embraced the concept of making articles most natural and fluid for the most likely readership. An article such as the Spokane River Centennial Trail or Kevin Coe should use American-style dates. An article on Kilogram or Argentina should use Euro-style dates. It seems simple enough to me. But I also know there are a lot of editors here who strongly feel that grandfathering is an important thing. Oh well… Greg L (talk) 05:48, 30 November 2008 (UTC)
  • P.S. Since I live in Spokane, I can easily add a picture for the Centennial Trail so we don’t have to resort to an external link to Flickr. I suppose I can also update Kevin Coe (“The South Hill Rapist”). The jury in his civil commitment trial unanimously found him to be suffering from a mental abnormality that made him more likely than not to reoffend. He is now in a special treatment center for sexual predators—likely for the rest of his life. I’ve saved my copy of the local paper so I can update that article. Greg L (talk) 06:00, 30 November 2008 (UTC)
  • Historically the MOS said to use what English speakers in that country would use. I don't know when or why it was changed to just English-speaking countries. Perhaps it was just a misguided attempt to simplify the language. I like Greg L's suggestion that we use dd mmm yyyy for non-US articles but that is my preference. Is it only the United States (and Canada to some degree) that favour mmm dd, yyyy or should we have each article's contributors decide which is the associated style? The "grandfather clause" also aids to avoid edit wars when the "tie" is unclear, like a biography of an American who is best known for career in Europe, or vice-versa. DoubleBlue (talk) 07:59, 30 November 2008 (UTC)
  • To answer your question, DoubleBlue: “Is it only the United States (and Canada to some degree) [that use U.S.-style dates]…?”; my understanding is that it is the U.S. and its territories (American Samoa, Guam, Northern Mariana Islands, Puerto Rico, U.S. Virgin Islands, Wake Island), as well as the Republic of the Marshall Islands, Federated States of Micronesia, and Republic of Palau; that use U.S.-style dates.

    Indeed, choosing date formats need not be complex. Why is so much effort being devoted to this? All we need is simple guideline to help editors when choosing the most suitable date format for editors to use in articles. Such a rule should be specific so there is no ambiguity and so editors don’t have run off to research anything, such as what is a “territory of the U.S.” We could start with something like this:

1. For articles on, or strongly associated with, the following countries and territories: The United States, American Samoa, Guam, Northern Mariana Islands, Puerto Rico, U.S. Virgin Islands, Wake Island, Republic of the Marshall Islands, Federated States of Micronesia, and Republic of Palau; editors should use the U.S.-style date format (“February 2, 2008”), otherwise, editors should use the international date format (“2 February 2008”) in articles.

The above guideline would be updated as editors with experience with specific locations weigh in.
As for articles on Canada, we should leave the writing of that guideline up to a committee of Canadian Wikipedians to decide. What I have become sensitive to is editors with no experience whatsoever in certain matters, trying to decide complex issues that affect a specific discipline (like complete non-mariners trying to decide in fifteen minutes how Wikipedia should handle certain nautical terms). We could do a much better job of inviting comment from experts in an affected field when we write guidelines. It’s *pretty* to think we can all be expert in any field by doing a Google search or two and reading up on something for ten minutes, but this is a hazard we should, IMO, try to avoid when writing official Wikipedia guidelines. Nothing is so important that we can’t post a notice on our Canada article inviting users to comment on an RfC to a simple question. Whatever the consensus of our Canadian editors; we go with that. Greg L (talk) 17:41, 30 November 2008 (UTC)
We should learn to leave things alone. That is the only guideline we have ever needed on this; the caveat that July 4, 1776, and 5 November 1605 are both easier for their likely audience only needs to be said to prevent waves of dogmatism from being imposed by "editors" on a power trip. Huh?!?  What are you talking about? Greg L (talk) 21:07, 30 November 2008 (UTC)
The Argentines speak Spanish. Buenos Aires can and should use either variety of English dates; the usage in the local dialect matters to the Spanish WP, which has its own guidelines, not to us. Septentrionalis PMAnderson 20:43, 30 November 2008 (UTC)
  • And to your second paragraph: I don’t “get” that either. Indeed, it doesn’t matter what Argentinians do with their date formats. I don’t much care how the many inhabitants of the Andromeda galaxy format their dates. Remember, I am an American. But this is not “us.Wikipedia”, this is “en.Wikipedia”, and most speakers of English (either as their first or second language) are not American and use Euro-style date formats. So, in recognition of this fact, what we’re trying to do is have a simple rule-set for date formats. Since general articles like Argentina, Diesel engine, Black holes, and Andromeda galaxy are not closely associated with the U.S. and will enjoy a world-wide audience with a preponderance of non-American readers, we have the most natural-reading text that causes the fewest (!) interrupts in the train of thought by using Euro-style dates

    Conversely, articles closely linked to the U.S. that will have a heavy preponderance of Americans reading it (Yellowstone National Park, Kevin Coe, California) should use American-style dates so we have the maximum chance of having natural, fluid-reading text for that readership. It is not at all complex and I can not even fathom what you are talking about when you write of “waves of dogmatism from being imposed by ‘editors’ on a power trip.” Holy smokes. What is going on here that would cause you to write such a thing?!? Greg L (talk) 21:07, 30 November 2008 (UTC)

    • On the contrary, most people who speak English as a first language (the others have other Wikipedias) are citizens of the United States; but numbers are not the point here, any more than they were when certain overheated American patriots were insisting on those grounds that we must use color and yogurt throughout Wikipedia.
    • I know that the various system-mongers are unlikely ever to get this; they should go and edit articles instead - and maybe add some utility to the encyclopedia. Greg's system is just as futile, bossy and destructive as the ones which would mandate using AD/BC or CE/BCE; or color, or any of these trivialities. Septentrionalis PMAnderson 21:26, 30 November 2008 (UTC)
  • Wow! I see… I wrote “most speakers of English (either as their first or second language) are not American.” And you come back with “On the contrary, most people who speak English as a first language…”. Well there’s the problem: you aren’t reading and comprehending others’ posts and come back with retorts that are founded upon a non sequitur.

    Further, your overheated tone, where you drag in irrelevant issues such as how some editors in the past have argued over dialect-based spelling issues (color v.s. colour, 500 BC v.s. 500 BCE, etc.) indicates to me, once again, that it is utterly futile trying to reason with you when you are so, uhm, *animated* and have sand wedged up various body orifices over so many extraneous issues.

    Finally, the thrust of your argument seems to amount to nothing more than “the first Brit to edit an American-based subject somehow ‘wins’.” Perhaps this satisfies your inner child or something, but I utterly fail to see how such a policy improves Wikipedia one twit. Frankly, I am quite surprised by your reaction, for, as an American, my proposal would clarify that most articles should default to Euro-style dates and should be American-style only if they are strongly associated with the US. You seem to prefer a more ambiguous rule-set that encourages editwarring and vitriol. I don’t see the need for it; just a rational guideline. Greg L (talk) 21:56, 30 November 2008 (UTC)

    • Such animated language: "inner child", "not reading and comprehending".
    • On the contrary: I read, I understood, I disagree; no system-monger can stand that. We are not intended for the billions with a smattering of English; we are intended for those who can read encyclopedic prose, and chiefly for those who are more fluent in English than anything else. The others have Simple English, and their own Wikipedias; that's why they exist.
    • We have rational guidance now: learn to live with diversity, and contribute to things which actually affect the content of the encyclopedia. (Greg misstates the guidance he would make into a straitjacket, I notice; if a Brit edits a strongly American subject and installs British format, it should be replaced, as things stand; so with an an American on Bristol.) Those who prefer to worship the Goddess of Reason are not consensus, yet. Septentrionalis PMAnderson 22:27, 30 November 2008 (UTC)
          • It's tangential to this discussion but an interesting question nonetheless: How many people have English as a first language and how are they distributed among the world's countries? If you juxtapose the U.S. vs. the UK, Ireland, Australia, South Africa, Canada, the Anglophone Caribbean, plus countries where large segments of the population speak English as their first language (such as India), I believe that estadounidenses are in the minority.--Goodmorningworld (talk) 01:10, 1 December 2008 (UTC)
              • Indian language statistics are a bit odd; there are a large number of Brahmins who claim Sanskrit as their "mother tongue" - and all of them are male. I should like to see some sources for English as a first language which rebut the suspicion that something strange is happening here too; remember "English as official language" does not imply "English as first language" any more than that held for Latin in mediaeval Europe. Septentrionalis PMAnderson 01:18, 1 December 2008 (UTC)
                • Good point about "official language" not being the same as "first language". This is anecdotal only, but I have met a number of Indians who tell me that their vocabulary is biggest in English and that they use the "local language" only to converse with the help. Similar, perhaps, to 19th century Russia where the "educated classes" spoke better French than Russian.--Goodmorningworld (talk) 01:30, 1 December 2008 (UTC)
  • Flowery oratory (“diversity”), delivered with a high brow. Little substance. And I’ll meet your flowery truisms and raise you: “If anything is certain, it is that change is certain.” And “The key to change... is to let go of fear.” So keep your fingers nimble for more pounding away on your keyboard in the near future, for MOSNUM guidelines are rapidly changing as a new consensus sweeps over the user community here that past practices haven’t been wise and there are better ways to do things and avoid discord. Greg L (talk) 22:49, 30 November 2008 (UTC)
  • P.S. “Worship the Goddess of Reason”: I like that one; I think I’ll spirit it away on my user page. Those rascally French. They came up with Kilogram and the rest of the metric system around that very same time. And they have French sauces too. Greg L (talk) 22:57, 30 November 2008 (UTC)
    • Ah, I see, the Wave of the Future is coming to MOSNUM, where the handful of cranks whose edit wars have gotten it protected (how many times?) in the past year will suddenly, magically, agree with each other to impose a New Order. Yeah, right. But let's start changing it:

{{editprotected}}. Please add {{disputedtag}} to the top of the page; there is no re4ason to believe that this page does, or ever has, represented a consensus of Wikipedians on anything. Septentrionalis PMAnderson 23:18, 30 November 2008 (UTC)

 Not done. Please, specify exactly what is under dispute (I do not think that the whole MoS is disputed). Ruslik (talk) 17:10, 2 December 2008 (UTC)
And what do you hope to achieve by adding that tag at the top?--Kotniski (talk) 15:02, 1 December 2008 (UTC)
Simple. Offset all temptation to use this page to install a System before Which All Wikipedia Must Tremble. (I don't think WP ever has trembled before MOSNUM, mind you; the most we've elicited is annoyance at pointless MOS edits, as here.) But the idea that this page can be so used is the root cause of the edit warring here. Septentrionalis PMAnderson 19:07, 1 December 2008 (UTC)
Edit warring here would end if the principle were respected that controversial substantial changes to guidelines require consensus. And having a style guide that carries some degree of authority is one of the best ways to prevent pointless edit wars all over WP - the greater the degree of authority, the more effectively it achieves that. --Kotniski (talk) 10:18, 2 December 2008 (UTC)
Anderson, many people are bored watching your extended one-person campaign to dilute the authority of the style guides. My message to you, since you seem not to have got it yet, is to give up and work towards the betterment of the project. Tony (talk) 10:46, 2 December 2008 (UTC)
It has no authority at all, it's only a guideline not a rule (policy). If you'd like to be able to use this to brow beat editors into submission you should see about getting it tagged with {{policy}}, but something tells me you won't get very far with it. —Locke Cole • t • c 12:09, 2 December 2008 (UTC)
It will never achieve any level of authority so long as it constantly tries to ignore the minority. —Locke Cole • t • c 12:09, 2 December 2008 (UTC)
  • (*sigh*) “Cranks”? Am I supposed to go “owe” here? How absurd. How many times do I have to say this: WT:MOSNUM is a marketplace where ideas are exchanged. Get used to it Anderson. I’m certain hopeful that you can rise to the challenge. Perhaps I should request that an Admin post a tag at the top of this page stating that “WT:MOSNUM is officially a NO WHINE ZONE.”

    And, by the way: With regard to your “…cranks whose edit wars have gotten [MOSNUM] protected…”, where do you see my latest edits in MOSNUM’s edit history??? My last edit was Sept. 13. I had nothing to do with the latest edit block. Let’s see… Let’s check the latest MOSNUM edit summary. Lo and behold! After my last edit, I find thirteen MOSNUM edits by you leading up to the latest block. Funny, these inconvenient truths. And don’t blame Tony; it takes two to tango.

    Innocent question. I’m just wondering: how old are you? I see from your block log that you’ve been blocked eleven times now for 3RR violations and tendentious editing. I’m seeing a disturbing pattern of your not being able to let things go (Pit Bull-like behavior). I’d truly would hate to see you get all spun out of control here because I am managing to pull your strings so damn easily; that tends to create enemies. Perhaps now, a nice cup of chill out is in order here?  Greg L (talk) 00:15, 1 December 2008 (UTC)

This is personal abuse; for the record, my last edit to WP:MOSNUM was this <irony>deeply controversial</irony> edit, three weeks before the page was protected. Unless someone signs on to Greg's One True Way, my jaws are letting go of this conversation; I have no idea what he is talking about, and no interest in dealing with him. Septentrionalis PMAnderson 01:03, 1 December 2008 (UTC)
  • Read my above words carefully. I am not always correct but I do endeavor to be precise when I write. I did not say you were responsible for the latest block. I was saying that it certainly was not me (as you clearly implied) since I last edited in mid-September and, if you want to get nitpicky, you edited thirteen times after I did. Let’s just keep our facts straight when you throw out words like “editors on a power trip” and “cranks” and attempt to impeach my message by suggesting that my tendentious editing was the root of the latest lockdown on MOSNUM; that’s not  too much to ask. Greg L (talk) 01:22, 1 December 2008 (UTC)

This is a very lame argument. It makes no difference whether it's written dd MMM yyyy or MMM dd, yyyy; just that it looks stylistically better to have the same format throughout an article. DoubleBlue (talk) 02:47, 1 December 2008 (UTC)

  • I get a very strong sense of déjà vu - we've been here quite recently before and I think a consensus was reached [in August?]. It's kind of tiring having people challenge consensus shortly afterwards using the "but I wasn't here" argument, or the "I didn't agree with it the last time" argument. Anyway, if we must have this discussion again, I would support having dd mmm in WP throughout so that there is absolute uniformity of date formats. Failing that, I would support what I understand to be the last consensus view reached, which is to adhere to the formats in Calendar date#Usage issues, except for Canada and those countries which habitually use yyyy mmm dd in their local language. Only in these cases we should default to a 'grandfather' of the article. Ohconfucius (talk) 03:52, 1 December 2008 (UTC)
  • I don’t know what exactly you are referring to, DoubleBlue. I don’t give a rip either, personally. Neither date format (American or Euro) causes confusion for anyone and neither causes (!) brain interrupts for me. What couldn’t be clearer though, is that date formats matter a great deal to many readers of Wikipedia and in the user community; otherwise, so much drama wouldn’t have transpired over so many years over this one issue. This simple fact is inescapable and neither you nor I can poo-poo these feelings away and and pretend that anything is solved by ignoring the issue.

    My feeling is that we should get past the temper tantrums of editors who don’t like to see change (there is too much of that attitude here and as many opinions as butt-holes), and come up with a simple, unambiguous guideline that anyone can follow and which optimizes Wikipedia content for the likely readership. The simple reality is that en.Wikipedia is read by a *world-wide* English-speaking audience and most English-speaking readers are accustomed to using Euro-style dates in their daily life. So, IMO, it’s best to accede to that reality and go with the flow on this: use Euro-style dates for most articles. But if it’s an article on or closely related to an American subject (e.g. Yellowstone National Park, Kevin Coe, and California) use American-style dates so those articles read most naturally for its likely readership.

    I think it is unrealistic to expect that Wikipedia is going to *teach* an American audience to change the way it formats its dates and visa versa with the rest of the world. It’s just as unrealistic as it was for us to think that our adoption of “kibibyte” instead of the “kilobyte” the rest of the world used would change anything; it didn’t. I also just don’t see grandfathering in what is arguably the wrong date format based on who would be considered to be the first major contributor as a viable long-term solution. We shouldn’t have to go look at edit histories and have editwarring in order to resolve this on a case-by-case basis. Keep it simple; with a subject-based guideline:

1. For articles on, or strongly associated with, the following countries and territories: The United States, American Samoa, Guam, Northern Mariana Islands, Puerto Rico, U.S. Virgin Islands, Wake Island, Republic of the Marshall Islands, Federated States of Micronesia, and Republic of Palau; editors should use the U.S.-style date format (“February 2, 2008”), otherwise, editors should use the international date format (“2 February 2008”) in articles.

In 99% the cases, a simple look at the subject title settles the issue and that’s that. If I was the first major contributor to the Ford Mustang article and used Euro-style dates, I could certainly handle sitting back and watching them all consistently changed to American-style dates. I really do believe that most editors here can do the same. Greg L (talk) 04:08, 1 December 2008 (UTC)
Indeed. I personally use YYYY-mm-dd, I use dd mmm YYYY when talking to, or writing to most people and on Wikipedia generally. I use mmm dd, YYYY when creating/editing articles covering a US-based/US-specific topic (eg. Clarian Health People Mover). Perhaps we could move to something really simple in the guidelines, such as:
  • Dates should be written as 1 January 1970, with no leading zero ('0').
  • Dates can also be written as 1970-01-01, such as in lists (see: ISO 8601 date format)
  • Articles specific to the United States and its dependent territories may use January 1, 1970.
  • Dates in sourced quotes should be left verbatim.
Or perhaps somebody can find an even simpler wording. —Sladen (talk) 14:48, 1 December 2008 (UTC)
Doesn't seem much simpler than what we've got already. And since the present wording was the result of a very lengthy, well-publicized and well-attended discussion just a few months ago, I suggest we leave it alone.--Kotniski (talk) 15:02, 1 December 2008 (UTC)
Yes, please. I think we're all suffering date fatigue here. Tony (talk) 15:04, 1 December 2008 (UTC)
All I've been arguing for. Both proposals in this section were considered then; let's stick with what we have. Septentrionalis PMAnderson 18:02, 1 December 2008 (UTC)
You seem to be completely ignoring 2008Olympian opening question here. The guide is worded to seemingly only apply to English-speaking countries. DoubleBlue (talk) 18:19, 1 December 2008 (UTC)
And that is how it was intended to be worded. That phrase is an exception to the general rule of stare decisis, to avoid the possible case of, say, Henry Temple, 3rd Viscount Palmerston being written by an American with American dates, when it is reasonable to suppose that it will be read and edited overwhelmingly by those used to the modern English system. This is guesswork even for Palmerston; no such supposition is warranted for, say, Jorge Luis Borges - for one thing, we expect Argentines to read es:Jorge Luis Borges. Septentrionalis PMAnderson 18:26, 1 December 2008 (UTC)
So the race is on then, if an American can edit an international topic first, it's in American date format. DoubleBlue (talk) 18:45, 1 December 2008 (UTC)
  • Well, I see that grandfathering past practices is the only realistic way to make peace. It was overly idealistic of me to push my *One True Way* (as Anderson described it), where there would be no grandfathering, so I’ll drop it. Besides, Anderson just used a Latin term used in legal circles to ennoble grandfathering: stare decisis. Since he’s so full of spunk today, I can think of better things to do today and the Real World calls. Our current MOSNUM guideline is good enough to cover fixed-text dates so that should be the end of it for a while. Greg L (talk) 18:45, 1 December 2008 (UTC)
    • At last Greg L has considered the real point here: peace. Much more important than the difference between 1 December and December 1, or the difference between AD and CE. If we let articles go their several ways, and grandfathering can be reversed by consensus (nothing here can prevent that), we may eventually find that Wikipedia has converged on one of these choices by the action of WP as a whole - or we may not. In the first case, we should then note that consensus here (and any exceptions it may have); in the second case, we should be silent. Septentrionalis PMAnderson 19:07, 1 December 2008 (UTC)
      • It does seem to be the grandfather clause that causes the problem. Unless the it's an Australian or British Isles related article (a small percentage), then the sequence "first major contributor"→"retaining original format" is the Ace card that trumps the whole of the rest of Wikipedia:MOSDATE (hmmm, that redirect is broken). If the first editor of a French *(song)/*(band)/*(album) writes "YYYY day month", technically the MOS allows that to stand. What the MOS might be better stating is in the inverse; if an article does not have a national connection, it should conform to dd mmm YYYY (or ISO). —Sladen (talk) 19:35, 1 December 2008 (UTC)
        • (ec) For those who may recall, there was a (mangled, in my opinion) RfC with about 5 tablulated 0-4 votes, and basically there was no consensus for anything in particular. I'm not sure when or if MOSNUM changed from "the most common date format of English-speaking people in the (relevant) country" to "the most common date format if associated with an English-speaking country", but this shouldn't be cause for edit wars outside of this MOS. Although the RfC mentioned above was mangled. Sladen's proposal was probably would have been the first one to be eliminated if it had been a "real" vote. — Arthur Rubin (talk) 19:48, 1 December 2008 (UTC)

Sladen's comment does not describe the current wording correctly; since there are generally only two acceptable formats (dd mmmm yyyy and mmmm dd, yyyy) only articles where the first major contributor used one of these formats are "protected" by the grandfather clause. Also, Sladen should read ISO 8601 (the standard, not the article, although a link to the standard is available in the article) before suggesting that ISO 8601 is a useful date format in Wikipedia. Use of the YYYY-MM-DD format in Wikipedia often violates the standard. --Gerry Ashton (talk) 19:56, 1 December 2008 (UTC)

  • I say, ‘let it lie’ until the RfCs are over. IMO, the winds on getting rid of grandfathering are blowing the correct way on this; it just takes time. Wikipedia if full of inertia. I subscribe to the “bull and his son” philosophy when it comes to getting anything done on MOSNUM. Check out the third-to-last quote at the top of my user page to see what I mean. Greg L (talk) 20:36, 1 December 2008 (UTC)
    • I'm sure Greg's one-man wind will be able to blow in the words he wants at some point, and then another wave of pointless edits "correcting MOS violations" will be made all over Wikipedia; that is, after all, what this page and its sisters exist for. The present wording isn't what I would have enacted if I were Jimbo, any more than if Greg were; nevertheless, I move to postpone until the Greek calends. Septentrionalis PMAnderson 21:40, 1 December 2008 (UTC)
Off-topic Gerry, thank you for your confidence! We currently use a sub-set of the GFDL as a license for Wikipedia. What aspects of a sub-set of ISO 8601 (eg. without truncations [which were removed], times and ranges and with hyphens) do you feel would not be suitable for Wikipedia's uses [in non-sentence situations] as a logical, big-endian unambiguous limited-range numerical date representation? —Sladen (talk) 22:24, 1 December 2008 (UTC)
  • Use of ISO for dates before 1582. The ISO standard requires a prior understanding before use of ISO in such contexts; it may imply (Gerry thinks so, I don't) that the understanding must be that the ISO represents the Gregorian calendar.
  • Use of forms readily misunderstood. Does 2008-12-01 mean the first of December, the twelfth of January, or Sunday in the twelfth week of the year? Whatever your opinion on the correct answer to that question, if we use ISO, we depend on all readers reaching the same answer. What are the odds?Septentrionalis PMAnderson 23:10, 1 December 2008 (UTC)
  • PMAnderson correctly describes my position, with one exception: ISO 8601 says in plain black and white text that dates that conform to that standard must always be in the Gregorian or proleptic Gregorian calendar; that's not opinion, that's high school reading. What is a matter of opinion is whether or not our readers have the impression that dates within Wikipedia in the YYYY-MM-DD format are intended to conform to ISO 8601 or not. --Gerry Ashton (talk) 16:38, 2 December 2008 (UTC)
  • If +8000/–500 years is not sufficient for the table in-hand, I suspect that the article is likely to require an in-depth discussion in the accompaning article anyway.
  • The problem which is a dramatically smaller one than 12/01/2004 vs. 01/12/2004 confusion, perhaps, almost non-existant: In YYYY-mm-dd:
    1. Only one form is legal. (There is only one right way and no edit-warring).
    2. Some people use it everyday (Far East Asians and programmers).
    3. Some people don't use it, and therefore won't insert it accidently.
Big-endian dates have a tendancy to get used where absolute clarity is required, such the bottom of your machine-readable passport. The standard was created to solve a series of problems (some of which overlap with Wikipedia's issues)—in {{cite}} templates, the use is remarkably consistent. on the whole ISO 8601 seems to have done remarkably well, with few problems. Much like the new-fangled invention of big-endian clock radios and digital watches. —Sladen (talk) 01:35, 2 December 2008 (UTC)

I personally believe that "ISO" or "ISO 8601" has bandied about sufficiently in Wikipedia that an indellible impression has been created that dates in the format YYYY-MM-DD conform to ISO 8601. Such dates must be expressed in the Gregorian calendar, or Proleptic Gregorian calendar. Furthermore, an agreement must be established among partners exchanging information before exchanging dates where the year is less than 1583 or greater than 9999. Wikipedia is in no position to establish such an agreement with our readers, so we fail to conform whenever we use dates outside that range. In particular, {{Cite book}} specifically mentions ISO 8601, so that format must not be used for non-Gregorian publication dates. --Gerry Ashton (talk) 01:59, 2 December 2008 (UTC)

This is a good point you bring up here, and it's one that I hadn't even considered. Luckily I generally don't do editing in such historical articles, so I don't think it's ever bitten me. I do like that people are bringing up ISO 8601 though. The section title phrases the debate as one having only two alternatives, both of which are inferior to yyyy-mm-dd for a number of reasons. --Cyde Weys 15:13, 2 December 2008 (UTC)
Actually, Wikipedia can establish an "agreement" with its readers. "Agreement" does not mean that it be negotiated in this context, it just means that there must be some way to convey information on how to interpret the date (i.e. that both sides agree on the meaning of the format). In other words, a simple indication linking to a help page is enough. However, with such an "agreement" in place, this agreement is not limited to the Gregorian calendar; there's nothing wrong with borrowing the ISO format for other calenders, e.g. as in "1703-01-02 (Julian Calendar; 1703-01-13 in the Gregorian Calendar)" or "4705-01-01 (Chinese Calendar; 2008-02-08 in the Gregorian Calendar)". -- 3247 (talk) 11:17, 6 December 2008 (UTC)
I agree that in principle, Wikipedia could create an agreement with its readers by giving them a clear notice about the meaning of the YYYY-MM-DD format. Such a notice could specify conformance with ISO 8601 together with years outside the range 1583 though 9999, or could disclaim conformance with that standard and state that the calendar must be deduced from context. However, to be effective, such a notice would have to be available in every article that uses the YYYY-MM-DD format, and I don't think that's going to happen. --Gerry Ashton (talk) 16:21, 6 December 2008 (UTC)

So far I have found three quasi-date articles that are worth reading and linking to: January 0, February 30, and (to a lesser degree) February 31. I believe bots should avoid delinking these "dates". --Gerry Ashton (talk) 21:23, 3 December 2008 (UTC)

Just because they aren't lists of trivia does not mean they merit links. February 30 and Febraury 31 would provide no context to reader from any circumstance (except for articles explicitly about dates). We aren't against linking to date articles because the articles themselves are "bad", it is because they are almost always irrelevant to the context from the article they are linked from. Dabomb87 (talk) 03:17, 4 December 2008 (UTC)
January 0 is a different matter, because it is not a relatively well-known "date"; it probably doesn't appear in that many articles either[citation needed]. Dabomb87 (talk) 03:19, 4 December 2008 (UTC)
indeed: what articles do these dates appear in, outside of calendar-item articles? Sssoul (talk) 10:44, 4 December 2008 (UTC)
It did appear in Patricia Jones until now thanks to an IP vandal's efforts.LeadSongDog (talk) 14:26, 4 December 2008 (UTC)

An article about anything that happened on February 30 might want to link that article so readers can understand why such an unusual date existed. January 0 is linked in the Ephemeris article, and might appear without a link in other astronomy articles. --Gerry Ashton (talk) 13:49, 4 December 2008 (UTC)

  • The only undisputed February 30 occured in Sweden in 1712. If anyone ever writes an article about something that happened on that day, the editor might want to link to the Febrary 30 article. Some disputed claims exist for February 30 in the Soviet Union or Roman calendar, so any article discussing those claims might link to the February 30 article.
The dates Jan. 0, Feb. 0,...Dec. 0 are used in astronomical calculations. See, for example, pages K2–K5 of the Astronomical Almanac for the Year 2003. Articles about astronomical calculations, or converting between the customary date formats and Julian Day Numbers might link to the January 0 article. --Gerry Ashton (talk) 16:38, 6 December 2008 (UTC)

Should we mark examples with quotation marks instead of italics?

There are some examples using quotation marks (e.g. those in "Dates of birth and death"), some aren't marked at all (as in the bulleted lists of "Scientific notation, engineering notation, and uncertainty"), and most ones are italicized. I think we'd better use a consistent format; I propose using quotation marks, as this would avoid italicizing unit symbols (which is incorrect) or using {{itunit}} (which would seriously bloat the page and make examples much harder to read when in source text).

What do you all think about this? -- Army1987 (t — c) 16:27, 6 December 2008 (UTC)

I think it's clear that the examples are examples, despite their formatting differences, and there are more important things to spend time on. There are plenty of articles that need this kind of copyediting; let's attend to them first. -- Unconventional (talk) 22:44, 6 December 2008 (UTC)
If your only concern is time, one could copy&paste the article into a text editor, use the Replace '' with " function, and spend 0.9 seconds for each instance deciding whether that needs to be changed. That would take less than five minutes. Also, I think that stating "Unit symbols are written in upright roman type, never in italics as they could be mistaken for dimensions, constants, or variables (e.g., write "10 m" or "29 kg", not "10 m" or "29 kg)." (quoted verbatim) and doing exactly that, in the same page, is somewhat, er..., confusing. -- Army1987 – Deeds, not words. 03:00, 7 December 2008 (UTC)
  • A much more common error is forgetting to put a space (preferably, a non-breaking space) between the numeric value and the unit symbol. For some reason, the computing industry often fails to do this, e.g. “2.4GHz”. I don’t know why.

    In an ideal, perfectly-SI-compliant world, unit symbols would never be italicized—even in all-italic text. However, in italicized text where an entire sentence or sentence fragment is italicized to denote that it is example text, I don’t think anyone is confused when a unit symbol goes along for the ride. As I recall, the BIPM states that if you have all-italicized text, one is supposed to un-italicize the unit symbols, e.g.

OK class, be sure to read the below instructions very carefully before writing your answers on the test. You may put your finished test sheets in the box, 15 m down the hall.

1) Greg L has twenty apples in a box. Thunderbird2 takes away twelve and declares they are oranges. How many apples still exist?

To me, the roman “m” looks quite odd. Even though the BIPM is, well, the BIPM, doesn’t mean they walk on water. They are physicists and scientists and, not surprisingly, they can be like irrepressible Oompa Loompas about having absolute logical consistency even if the results are queer and unnatural. The BIPM also requires that a space be inserted between the numeric value and the percent symbol (e.g. 75 %), but the world ignores them on this too. Sometimes you just gotta use common sense and not try to pound a square BIPM peg into a round real-world hole. Greg L (talk) 01:33, 8 December 2008 (UTC)
That's why I oppose the use of {{itunit}} (and, BTW, IIRC, they would also require the "15" to be upright). On the other hand, I think that the bullet point I've cited should stay, I have seen units italicized for no reason whatsoever (other than the fact that whoever wrote them didn't know how to use upright letters in TeX), and that's wrong. But then, saying that and them showing units in italics seems very inconsistent. OTOH, if the examples were surrounded by quotation marks rather than italics, there would be no doubt on whether to italicize units, as there would be one obviously correct answer. -- Army1987 – Deeds, not words. 02:01, 8 December 2008 (UTC)
  • A simple statement in MOSNUM for those with galactic-grade attention deficit disorder:
Unless there is a good typographical or communication-based reason otherwise, in numeric equivalencies, the unit symbol shall be in roman (non-italic) text. A non-breaking space (&nbsp;) almost always separates the value and the unit symbol (e.g., 2.4 GHz, 325 km, 25 °C). Exceptions are the degree, minute, and second for plane angle, °, ′, and ″, (e.g., 47° 38′ 8.8″), and the percent (%) symbol. Variables are always italicized, (e.g., T = 298 K, e = mc2).
I agree with you: I’m not so sure about {{itunit}}; it looks like a flawed solution (it drags in the numeric value) to a semi-imaginary problem. Just because the BIPM Oompa Loompas break into rhyme about absolute, across-the-board style consistency…
Oompa loompa, to hell with writing fads
unit symbols are roman or we’ll hang you by your ’nads
…doesn’t mean there is always really a problem. Editors need to take the basic principles of the BIPM and apply them with common sense. It’s all about minimizing confusion for the intended audience. Not everything in the world needs to be treated like it’s a ready-for-print scientific paper on quantum mechanics. If we followed what the BIPM said, they’d have many of us under the guillotine for delimiting big numbers with commas, like 2,947,000. Whereas delimiting with narrow spaces is allowed for scientific articles here, doing so—even though it makes the BIPM happy as a clam—is not always the way to best communicate to our readership.

Having said that, I doubt you’d get much support for revising or deleting the template. I’d just not use it myself. Greg L (talk) 03:14, 8 December 2008 (UTC)

Begins to sound somewhat like instruction creep. I would do this: Take the current wording "Unit symbols are written in upright roman type, never in italics as they could be mistaken for dimensions, constants, or variables (e.g., write "10 m" or "29 kg", not "10 m" or "29 kg)." and add a bloody " before the right parentheses (nobody would object to that, right?). Then, replace "are" with "should be", "never" with "not", add a comma after "italics", and replace "as" with "particularly when":

Unit symbols should be written in upright roman type, not in italics, particularly when they could be mistaken for dimensions, constants, or variables (e.g., write "10 m" or "29 kg", not "10 m" or "29 kg").

WP:IAR and common sense will handle rare cases such as "15 m down the hall". (How often do you use italics for emphasis on more than few words in scientific articles, and how often those few words contain unit symbols?) -- Army1987 – Deeds, not words. 12:07, 8 December 2008 (UTC)

The purpose of the BIPM practice is to avoid confusion between variables and unit symbols. I'd say that articles that contain both variables and unit symbols should rigorously follow the rule; it's less important for articles that contain no variables. --Gerry Ashton (talk) 04:04, 8 December 2008 (UTC)

  • P.S. Of course, you can see the lack of logic in making a tool such as {{itunit}}: What if you have *variables* (not unit symbols) in italicized text? You couldn’t technically *see* them. I can quote myself from above: Variables are always italicized, (e.g., T = 298 K, e= mc2)??? Thus, {{itunit}} is like a making a machine that can scratch your butt, but only one butt cheek and not the other; why bother? Anyone who has both unit symbols and variables (clearly scientific in nature), of course, has no business setting the text in italic style. Greg L (talk) 04:34, 8 December 2008 (UTC)
My right butt-cheek never itches. Tony (talk) 07:08, 8 December 2008 (UTC)
[Ahem.] I rarely join in discussion here these days, but I remember that all of this has been discussed at kalpa-like length before. More than once. All I would add is this (that has also been pointed out before): many style guides have all of their examples set off in new lines, or use a distinctive typeface, or both. Given the particular complexity of MOSNUM, and the overwhelming need for clarity and precision, it really ought to be managed like that. Shorter examples in running text but with a distinctive typeface; longer ones set off, but with that same distinctive typeface.
The same applies, only slightly less urgently, to MOS and indeed to all of the lesser MOS-type pages.
Meanwhile, I note with detached amusement that MOSNUM still uses both curly quotes and straight quotes, and both spaced en dash and unspaced em dash as the sentence-level dash. Doesn't anyone here really care about consistency? I thought the MOS-types pages were supposed to set an example. O well.
–⊥¡ɐɔıʇǝoNoetica!T– 07:42, 8 December 2008 (UTC)
  • SIR: I take the blame for that, SIR! Sir, you have awesome attention to detail, Sir! The three whole sets of typographers’ quotes (out of 42 sets of barbarian quotes) currently locked up here on MOSNUM were added by me a long, long time ago, Sir. Force of habit, Sir, as I come from a world where fine typography is required, Sir. Sir, shall I drop and give you twenty? Please don’t hesitate to stop by again to deliver another one of your scoldings over how the rest of we maggots can not rise to your standards, Sir. Greg L (talk) 18:26, 8 December 2008 (UTC)
  • P.S. “I note with detached amusement…” <deeply mocking tone>Oooooh.</deeply mocking tone> Methinks the exalted plane at which you must operate is exceeded only by your arrogance. Greg L (talk) 18:32, 8 December 2008 (UTC)
  • P.P.S. For those of you wondering where the hell that came from, the last time I recall Noetica weighing in here was a long time ago (here), and that time too was to give everyone a thorough tongue lashing (…this section is a total disgrace”) for not keeping convoluted and interwoven MOSNUM discussion threads well organized so he/she could wade in at the last moment, quickly understand what was going on, and vote on something. I’m seeing a pattern developing here…

    “[Ahem.] I rarely join in discussion here these days”: Splendid. If you can’t leave the bloated ego back in the palace in which you apparently reside, can you make that kalpa-like rarely? O well. Greg L (talk) 18:51, 8 December 2008 (UTC)

Bracing vehemence, Greg. But not once do you mention the content that I contribute above, {You are correct; I didn’t get much past that profound attitude, which I had seen in industrial-strength proportions before. Greg L (talk) 01:12, 9 December 2008 (UTC)} advocating a major reform: the use of distinctive typefaces and set-off lines for examples. Interesting, if indeed you "come from a world where fine typography is required". Why should you think my situation is any different, by the way? But here we are with a new kind of project where other priorities intrude, and we must leave our prejudices at the door. {“prejudices”?? Do explain. Is objecting to unbridled arrogance no longer politically correct? Don’t try to deflect legitimate observations about your attitude by hiding behind the apron strings of prejudice please. Greg L (talk) 01:19, 9 December 2008 (UTC)}
Thank you for linking to an earlier contribution I made here almost a year ago. I quote from it, since it still applies:

Everyone's so busy pushing particular detailed proposals, and very few editors are giving sustained attention to structural, procedural, and broader substantive matters for WP:MOS and its satellite pages. But without such effort, these innumerable smaller issues will never be reliably settled. Small factions of editors will wrestle energetically in various corners until they get bored or tired; others will either know nothing about the issue they address, or look the other way in dismay, or completely fail to grasp the issue in a forest of ill-managed verbiage.

Since content still comes a distant second and there is little prospect of its being addressed efficiently, I'll close with a tiny matter of process and form for you, Greg: please consider writing the rest of us maggots, next time. (Next time, if I have to, I will. Greg L (talk) 01:02, 9 December 2008 (UTC))
Have a nice kalpa! :)
–⊥¡ɐɔıʇǝoNoetica!T– 22:05, 8 December 2008 (UTC)
Greg, bluntly put, shut the hell up. Greg, less bluntly put, Noetica made good remarks and points to correct, and unlike plenty of users here who only yap and complain for the sake of complaining, gave suggestions for solutions. Our response should be to fix what has been pointed as inconsistent and wrong, not to scold him for pointing it out. "Don't bite the newcomer" should have a "And don't bite the oldcomer too!" section. Headbomb {ταλκκοντριβς – WP Physics} 22:14, 8 December 2008 (UTC)
  • “Shut the hell up”??? Like I’ve always said, the proper response to bad speech is better speech. So I applaud all your above above post except for the first sentence, Headbomb.

    So, Headbomb, go fix the quotes. Oops, you can’t; MOSNUM is all locked down. And, frankly, even though Noetica made some perfectly valid observations about relatively minor points, his or her SOP of trying to act like a damned prima donna (writing “I note with amusement…” wasn’t good enough; it had to be “I note with detached amusement…”). Talk about “workin’ it”; it’s tiresome and deserved to be called for what it is: acting like a *big-picture* sort of person who wastes no effort to drive that point home and diminish all the work others have put in here. Every single time Noetica does a drive-by and dishes out a big, hearty, whole-grain, vitamin-fortified bowl of that attitude, I’ll call it for what it is.

    There: I met your “better” speech and raised you. Greg L (talk) 00:55, 9 December 2008 (UTC)

OK. Now, moving right along, anyone care to take up the clearly stated substance of my post? It went like this (though I now add emphasis, and one capitalisation):

All I would add is this (that has also been pointed out before): Many style guides have all of their examples set off in new lines, or use a distinctive typeface, or both. Given the particular complexity of MOSNUM, and the overwhelming need for clarity and precision, it really ought to be managed like that. Shorter examples in running text but with a distinctive typeface; longer ones set off, but with that same distinctive typeface.

The same applies, only slightly less urgently, to MOS and indeed to all of the lesser MOS-type pages.

–⊥¡ɐɔıʇǝoNoetica!T– 02:46, 9 December 2008 (UTC)
Coming back to the issue of italics vs. roman, how about "Symbols for units of measurement are normally upright, and symbols for variables are normally italicized: for example, "2 m" means two metres, and "2m" usually means twice the mass."? It's simple, the normally makes clear that it's not an absolute prohibition, and I don't think anything more complicated is needed. -- Army1987 – Deeds, not words. 13:35, 9 December 2008 (UTC)

(outdent) I agree with Army. It might be nice if MOSNUM found a better way to quote text containing unit symbols (or variables for that matter). We could always, for instance, use a different color, but that violates an accessibility rule. I don’t see a problem with MOSNUM flouting its own advise when setting example text in italics; I doubt it is all that confusing.

Now, for those who really, really think that flouting our own guidelines is unacceptable, I personally don’t have a problem with using color for setting off example text on MOSNUM (notwithstanding the “accessibility” problem, that shouldn’t be an issue, as I will explain below). Using color liberates us to use quote marks as part of the example text and every other text style feature, including bolding and underlining.

I know a bit about color blindness. I worked with a color-blind engineer on fuel cells. One of his jobs was to look up at ceiling-mounted hydrogen sensors when they tripped a facility-wide hydrogen-safety system I had designed. There were a bunch of these sensors on the ceiling of the big, main testing room (as well as everywhere else in the building). For practical considerations, some of the sensors had to share a single channel on the control box. The sensors had a multi-color LED that went from green to red if it was the one that sensed the hydrogen. Like most color-blind individuals, this engineer had red/green blindness—most inconvenient. He had to ask for someone else’s assistance to look up and squint at LEDs twenty feet up. Once you knew which sensor went off, you knew which engineer’s experiment was leaky. (Don’t get me started about putting hydrogen-fueled, fuel cell-powered cars in the hands of the public.)

Anyway, my point is that setting aside a metric butt-load of political correctness (because a small, small percentage see no color whatsoever), and embrace a little bit of common sense, setting off example text in maroon (or some tweak of maroon that won’t be confused with red, and certainly not relying upon the use of both red and green to mean two, distinct things), should be fine. Even those with absolute color blindness will be able to set the bit depth and gamma on their monitors so that maroon text appears as a distinctly different gray. Thus, no one is left out in the cold.

Anyone who has seen my posts knows that, on occasion, I have employed maroon text to set off complicated quoted writings of others. For instance, Army 1987, above wrote …for example, "2 m" means two metres, and "2m" usually means twice the mass."? Whose question mark is that? Ownership is clear with this technique. There are no double-quotes within double-quotes. There is no converting someone’s double quotes into single quotes. Italicized emphasis and mathematic variables aren’t rendered invisible. Unit symbols aren’t technically converted into variables. There is zero ambiguity regardless of the nature of the example point or quotation. I find that this works well for me anyway. Greg L (talk) 21:55, 9 December 2008 (UTC)

Yes. I agree about colour, Greg. Perhaps the best solution is to combine what you and I propose: distinctive colour, but also distinctive typeface. Why not a belt-and-braces approach, after all? Nothing is lost, and it's not rocket science: we do have the technology. No problem with colour blindness, and no one is inconvenienced – once such a system is established.
Other alternatives for examples in running text:
  • Use bold [salient and distinctive; but improper for a minute number of situations, only at MOSNUM]
  • Use underlining [salient and very distinctive; out of fashion, but making a comeback in many UK publications that face problems similar to those we address here]
And then, no matter which of these options were chosen, it would be good to see more setting off of examples other than the very shortest.
–⊥¡ɐɔıʇǝoNoetica!T– 23:02, 9 December 2008 (UTC)

(outdent)

Typeface too works for me, Noetica, and (I think), it looks better yet. Army1987 wrote as follows: for example, "2 m" means two metres, and "2m" usually means twice the mass."?

And then this example (which is currently on MOSNUM with italicized example text):

  • Do not note a conversion as approximate where the initial quantity has already been noted as such; e.g., write as follows: Earth's radius is approximately 6,400 km (4,000 mi), not Earth's radius is approximately 6,400 km (approx. 4,000 mi).

It even handles quick changes to other fonts, like <code>, in the middle. Note this:

Greg L wrote, above, as follows: Unless there is a good typographical or communication-based reason otherwise, in numeric equivalencies, the unit symbol shall be in roman (non-italic) text. A non-breaking space (&nbsp;) almost always separates the value and the unit symbol (e.g., 2.4 GHz, 325 km, 25 °C). Exceptions are the degree, minute, and second for plane angle, °, ′, and ″, (e.g., 47° 38′ 8.8″), and the percent (%) symbol. Variables are always italicized, (e.g., T = 298 K, e = mc2). Yup, works for me. This is coded as follows: <font color=maroon face="times new roman" normal style="font-size: 107%;">Example text shown in the resultant style.</font> Greg L (talk) 00:13, 10 December 2008 (UTC)

Fine, Greg. I think that would be the way to go then: distinctive typeface and colour for examples. It could be refined to make it really easy in practice; but you have shown how to do it right now.
Another consideration against colour by itself: sometimes our text is to be cited in print, or online, where the local protocols exclude colour. Perhaps most people's personal printers for text, and most office printers, are monochrome; and even if they are not it is often expensive and inconvenient to print in colour. I use a colour laser printer often, but I normally set it to print monochrome to save colour toner, or because I simply prefer that output.
–⊥¡ɐɔıʇǝoNoetica!T– 00:58, 10 December 2008 (UTC)
  • Random832 and some others are good with templates. Maybe we could have a template that accomplishes the above and looks like {{hilight|Sample text here}}. How say you? Greg L (talk) 02:34, 10 December 2008 (UTC)
  • P.S. Do we really need to make it convenient sooner than later? It’s not like this markup is used throughout Wikipedia; it would be used only on MOSNUM. If it proves popular and other pages want it, then I’m sure that would encourage the making of a template. I see no reason to not go ahead and just copy the expression and paste it where needed on MOSNUM to replace the quotes that Army1987 objects to. I rather like the above look; I find it quite easy to read and quite attractive. Greg L (talk) 07:20, 10 December 2008 (UTC)
I'm all for action on this one, Greg. Let's roll. BUT... it really has huge advantages if it's implemented on all MOS-pages, so check in at WT:MOS soon, centralising discussion in one place (here, or preferably WT:MOS). MOS and MOSNUM are the big-league players, but the associated pages can be advised and brought on board too. The details will need fine-tuning; but I predict you'd rapidly get support in principle, and some pretty savvy assistance. Since, as you suggest, it is only a MOS-page matter, it doesn't have wide implications and can be done without a universal plebiscite, or any darn UN involvement.
–⊥¡ɐɔıʇǝoNoetica!T– 08:56, 10 December 2008 (UTC)

Parenthesis fix.

{{editprotected}}

The sentence

should be replaced by

Headbomb {ταλκκοντριβς – WP Physics} 09:18, 8 December 2008 (UTC)

 Done Ruslik (talk) 14:09, 8 December 2008 (UTC)
It adds a level of precision which is IMO, required to convey what exactly we're talking about. Readership is international, so by default we write with the most widely recognized and adopted units. These are, usually but not always, the BIPM units, and usefull links given so readers can see which units are those with international adoption. There's nothing lost if we leave it there, but there might, and probably will, be some confusion, if we remove it. So let's leave it there.Headbomb {ταλκκοντριβς – WP Physics} 22:01, 8 December 2008 (UTC)

"since age 6"

From a Wikipedia article:

He has been blind since age 6 due to glaucoma,

Conceivable alternative:

He has been blind since age six due to glaucoma,

Is this covered in this manual? (I feel inclined to leave it as a digit in this case.) Michael Hardy (talk) 22:14, 8 December 2008 (UTC)

Numbers under ten should be spelled out. Dabomb87 (talk) 22:18, 8 December 2008 (UTC)
Actually the whole sentence is grammatically questionable. It should read something like, "He has been blind from the age of six owing to glaucoma." Deb (talk) 17:26, 9 December 2008 (UTC)
True that, but I was just answering the question. Dabomb87 (talk) 22:12, 9 December 2008 (UTC)

There are exceptions to the rule that one-digit numbers should be spelled out, as you'll see if you look at this manual.

I disagree with the grammatical point. Michael Hardy (talk) 23:19, 9 December 2008 (UTC)

Try: "Due to glaucoma, he has been blind since age six." Dabomb87 (talk) 23:40, 9 December 2008 (UTC)
Which exception would this case fall under? Dabomb87 (talk) 23:42, 9 December 2008 (UTC)

I had in mind that this is somewhat similar to discussion of a number as a mathematical object. Thus:

3 is a prime number.

but

There are three examples.

Of course I did not have in mind some exception that's currently listed in this manual. I was asking whether it ought to be listed. Michael Hardy (talk) 23:59, 9 December 2008 (UTC)

Shouldn't the guidelines say "numbers greater than ten"? In the real world, ten (and to a lesser extent, twelve) is seldom rendered in digits in the middle of text as it is an extremely short word and there is no reason to convert it to a numeral to help readability. Kaldari (talk) 18:25, 10 December 2008 (UTC)

I think the brevity of the words does have something to do with it. Michael Hardy (talk) 23:31, 10 December 2008 (UTC)
Yes, imagine having to write out 1234 (one thousand two hundred thirty-four). Dabomb87 (talk) 01:26, 11 December 2008 (UTC)

Wikimedia Foundation to spend $890,000 to simplify MOSNUM

Not really. This press release [1] is about a project to make editing Wikipedia easier for non-geeks. "Wikipedia attracts writers who have a moderate-to-high level of technical understanding, but it excludes lots of smart, knowledgeable people who are less tech-centric," said Sue Gardner, Executive Director of the Wikimedia Foundation.

Some of the methods proposed here on MOSNUM expect new editors enter normal text using templates and knowing when to use nowiki to prevent text from being automatically formatted. Keep it simple. -- SWTPC6800 (talk) 04:06, 9 December 2008 (UTC)

Just because there are advanced methods of editing does not mean every editor needs to know how to use those advanced methods. For the absolute basics, text will suffice. Any editor unfamiliar with how to format text can mark it with {{wikify}} to request assistance. I'm all for simple, but not to the point that it makes advanced formatting impossible even for those who would be happy to help. —Locke Cole • t • c 04:28, 9 December 2008 (UTC)
  • I understand precisely where you are both coming from. MOSNUM is the product of a hundred chefs in the kitchen and has undergone some major revisions lately (with more to come). It could eventually use some tweaks where we more frequently use language along the lines of

Doing {this} is OK for novice editors, but doing {this advanced technique} is preferred.

More specifically, coding “&nbsp;” seems simple enough for us, but advising editors to do that can be quite intimidating for many. So something like

With rare exception (symbols for angles and the “%” symbol), a space separates the value and unit symbol. Using a non-breaking space (&nbsp;) is much preferred.

Greg L (talk) 19:44, 9 December 2008 (UTC)

Markup for the hard space: revisiting the proposal for ,,

[Since practically all that follows is about the proposal for markup for the hard space using ,, (two commas), prompted by talk of reforms in the section above, I boldly introduce a new heading.–⊥¡ɐɔıʇǝoNoetica!T– 02:04, 11 December 2008 (UTC)]

I coordinated a sustained campaign to get ,, (a pair of ordinary commas) as markup for the hard space, instead of &nbsp; and all those buggy templates. The matter is quite important, but conceptually elusive for most editors, writers, and wiki-mavens, even here at Wikipedia. A mere space after all! It hardly even exists, right?
In the end we found there was not enough will for change. It is exactly the sort of thing that should be looked at again, using a sliver of that $890,000. I hate to be pessimistic so early, but my first thought is that MOS editors will not be consulted as the highly qualified volunteer specialists that they are (many of them, anyway).
The finished proposal for ,, can be read here.
–⊥¡ɐɔıʇǝoNoetica!T– 01:11, 10 December 2008 (UTC)
Yes, it would have been a good move: why was it thwarted? Tony (talk) 01:19, 10 December 2008 (UTC)
What Tony said. Greg L (talk) 02:19, 10 December 2008 (UTC)
I support the idea, but why not double underscore instead (in terms of making the readability of wikicode even easier?) Not that double commas hurt or anything... --MASEM 02:23, 10 December 2008 (UTC)
A double comma to represent &nbsp;? Sorry, but yucky:
  • non-breaking spaces are rare compared to italics and bold formatting, so the argument for the use of repeated commas being supported by "but they did it for repeated single-quotes" doesn't translate well.
  • the use of &nbsp; is standard HTML coding, and does provide advantages: e.g external HTML editors do recognise it.
  • Non-breaking spaces are fairly rare (not even mentioned in the pop-up WP "Editing help" window), so "&nbsp;" does at least suggest what it does (you only need to understand it once and you'll never forget it). On the other hand,, it will be very easy for many editors (especially newbies) to miss the significance of double commas in text. (Did you honestly notice the "accidental" double comma in the previous sentence?)
  • I fear the "mistaken" edit of a double-comma to a single comma will be an all too frequent event.
  • "&nbsp;" has no chance of appearing in "normal" text, whereas repeated commas do. For example, this is a common way of reporting what happened in previous overs in cricket: "1,,,2,,w | ,,,,, | 6,,,,w,1". Two commas together indicated that nothing noteworthy happened on that delivery. Seeing that nomenclature disappear into a puff of hard-space doesn't quite have the same impact.
I'm really not surprised the "will" wasn't there. If an alternate coding was to be considered, perhaps double underscore would be better (but will reserve final opinion on that).  HWV 258  05:15, 10 December 2008 (UTC)
Tony and Greg:
The effort was not thwarted: it simply stopped, for the time being. An enormous amount of analysis went into the project, and bulletins were posted in this forum and, quite regularly, at WT:MOS. We solicited input from all interested editors, and many contributed. We did not start with the idea of ,, as the favoured markup, but arrived at it by the most exhaustive deliberation. The mechanisms were simply not there for us to advance the project any further; at least, I was not equipped to do so in the forums where such matters are more widely considered, and where decisions are made. No one has taken it up seriously since; but it's still there for the taking up! The baton was handed on to WT:NOWRAP, where it may still be retrieved.
HWV258:
In your edit summary you admit that yours is a knee-jerk response. I have seen many of those, and yes: yours is now added to the pile. I invite you to do this thought experiment, though: Suppose there were no such thing as &nbsp; and we needed to find a solution to the problem of inputting hard spaces: for ordinary, non-HTML types, I mean. Suppose then that someone came up with this solution: "Hey, let's make them all type in &nbsp;! That's really intuitive and easy, to input and edit! What could be more transparent than 17&nbsp;sq&nbsp;ft?" Your honest knee-jerk response, please...? I thought so.
Literally all of the points you make above (except about cricket!) were covered in minute and forensic detail, at User:Noetica/ActionMOSVP and its substantial archive. Your close review of that would be more valuable than the all-too-common reflex reaction. I will answer your points, though:
  1. Hard spaces are in fact useful far more often than people think. The main reason editors are sparing with hard spaces (assuming they know about them at all) is that they are a damned nuisance to input.
  2. External HTML editors know nothing about our wiki-markup for italics, bold, and a huge number of other conventions we live with every day.
  3. Same as for point 1; but you are mistaken: &nbsp; is there under the edit box; and yes, I immediately noticed the double comma you ask about; and for the rest, newbies have exactly the same adjustment to make with '' and ''', to which they adjust with remarkable resilience. Same for the slips that we sometimes make, given that ' and '' and ''' are all eminently confusible and confused in practice.
  4. How often is a '' seen as an error for ', and just how dire are the consequences of that calamity?
  5. In all my years in a cricket-playing country, I have never seen that use of multiple commas! At least that is something novel. But in the nanoscopically few times that this would be relevant, a simple <nowiki></nowiki> would fix things, right?
None of us is surprised that the proposal went into recess. We confronted so many scarcely considered responses like that! I don't mean to be rude, and I thank you for having a say, and thanks also to Masem; but perhaps it is rude not to consider in depth first. We certainly did!
–⊥¡ɐɔıʇǝoNoetica!T– 06:38, 10 December 2008 (UTC)
Actually I often see cases where '' should be ". That's difficult to notice in diffs unless you set the CSS to monospace (which in turn makes dash errors difficult to notice, ho-hum). — CharlotteWebb 22:07, 10 December 2008 (UTC)
  • HWV258, I can see why it’s so hard to get anything done on Wikipedia. Unless it was a way to turn straw into gold, most editors have widely divergent views on just about everything (unless it is something like de-linking dates, which—surprisingly—is a landslide). ;·)

    I’m not going to make a federal case out of any of this, HWV258, but I disagree with a couple of your premisses. Being that this is “Manual of Style: Dates and Numbers”, some of us tend to deal with numeric equivalencies—a numeric value and a unit symbol—quite frequently; ergo, I disagree with your observation of “Non-breaking spaces are fairly rare”. Perhaps for you they are rare; for others specializing in different kinds of articles, they are not. And none of us want to see text that reads like…

Lorem ipsum dolor sit amet, maecenas eligendi tincidunt aenean, sit et hac, then add 15
kg of sugar to makeum hendrerit massa, morbi maecenas nec vel auctor.

I also don’t see the point of your observation that “[the non-breaking space] is standard HTML coding”  The whole point is that whereas it may certainly be a “standard” and is no problem whatsoever for us experienced editors, we are seeking to make it more accessible to novice editors. I must have better memory of what it was like to be a wet-behind-the-ear Wikipedia doofus. From my point of view, anything that makes it easier for novices (and more convenient for experienced editors) is always good and should not be seen as the least bit controversial if properly implemented.

You nevertheless made some valuable points about how repeating commas can legitimately appear in code. That means we should seek alternative suggestions. But you observation regarding commas shouldn’t be interpreted as diminishing the suggestion that we should be looking for a convenient Wikipedia markup substitute for the numerical code to the non-breaking space. The task of finding the right equivalent should be straightforward.

So, HWV258, who is less-than-enthusiastic over the perceived need to bother with this, seems to at least second the motion for double-underscore as a markup substitute for the non-breaking space. Thoughts from any others on this? Greg L (talk)

P.S. HWV258: Our Cricket article does not have multiple ,, in it. Even though multiple commas might be a way of denoting cricket scores in the real wold, as you’ve no doubt seen, Wikipedia is not the real world. Can you show where they are used on Wikipedia? Two commas would be just as convenient as hell if there is no (or extremely little) edit conflict. If it is extremely little (like one or two articles), we can go fix those with a <nowiki>. Greg L (talk) 07:01, 10 December 2008 (UTC)
Put in actual non-breaking spaces—the character, not the HTML entity code. That solves all the issues. Kaldari (talk) 18:28, 10 December 2008 (UTC)

(unindent) Kaldari's suggestion should not be followed unless and until the Wikipedia edit box is updated to visually distinguish a nonbreaking space from a regular space. Otherwise it's just about impossible for other editors to properly edit text containing nonbreaking spaces. --Gerry Ashton (talk) 19:19, 10 December 2008 (UTC)

  • I agree with you Gerry. I use a Mac. Since 1984, all you’ve ever had to do on a Mac is type [option]-space to get a non-breaking space. If I thought it was wise to do this, I would have used this practice on Wikipedia because it is so damned convenient in real life. But Wikipedia isn’t real life; it is a collaborative writing environment and you must plan that others will jump in and edit after you did. First off; as I understand (I certainly could be in error on this one), using a non-breaking is not so obvious for those less-fortunate soles running Barbarian-OS.

    Much more important though, other editors wading in later can't tell that your space is a special one. It helps to "lead by example." Whenever I edit using a character that looks identical to the regular one (non-breaking space, non-breaking dash hyphen come to mind), I use either the “friendly code” (&nbsp; for the space) or the hex code (&#x2011; for the non-breaking hyphen). That way, when someone, for instance, goes into our F-22 article and goes to edit mode, they can see F&#x2011;22 and quickly understand that something is special about it: a clue to just copy and paste. Greg L (talk) 20:00, 10 December 2008 (UTC)

Once more I urge anyone interested to read our developed proposal here, before assuming that a few minutes' thought can issue in better recommendations than many weeks' work by a dedicated bunch of enthusiastic editors in close consultation.{I love it. Someone else who plain-speaks truth around here. Greg L (talk) 21:31, 10 December 2008 (UTC)} You might do better, and the more brains the better: but first thoughts may not be best thoughts. Kaldari's suggestion is an example. For further elaborate detail, check User:Noetica/ActionMOSVP and its archive.
Greg, I agree with what you say above. Just one small matter. You mean non-breaking hyphen both times, not non-breaking dash, right? Sorry: I am allergic to seeing dashes and hyphens mixed up, and over at WP:MOS we labour to maintain this salient distinction.
–⊥¡ɐɔıʇǝoNoetica!T– 20:37, 10 December 2008 (UTC)
  • Noetica, are you aware of any  use on Wikipedia of back-to-back commas (setting aside real-life uses such as “previous overs” in cricket scoring using little-finger-out queen’s rules)? Greg L (talk) 21:21, 10 December 2008 (UTC)

If you guys think "&nbsp;" is more "friendly" than a non-breaking space character, you've been drinking too much Kool-aid. I still stand by my position that using actual non-breaking space characters is a far better solution than anything else that has been proposed. Non-breaking spaces are spaces, therefore they should look like spaces, not like double-commas or HTML codes or template calls or any of the other random ideas that have been thrown out. It also amazes me that many editors feel compelled to substitute HTML codes and templates for en dashes and em dashes. Why do we have characters for these things if we aren't going to use them? Making the mark-up more convoluted is never a good idea. Kaldari (talk) 21:39, 10 December 2008 (UTC)

"the Unicode non-breaking space is visually indistinguishable from the ordinary space. This is unacceptable". Why? It seems perfectly acceptable to me. A space should look like a space. If you want to make sure it's a non-breaking space, delete it and type a non-breaking space in it's place. Problem solved. It's crazy for us to invent new mark-up for a single character. Kaldari (talk) 21:45, 10 December 2008 (UTC)

I'm not convinced that the use of non-breaking spaces is ever critical, but I may be jaded from seeing them abused for goofy indentation and piped links, e.g.

&nbsp;&nbsp;&nbsp;&nbsp;Once upon a time in [[Salt Lake City, 
Utah|Salt&nbsp;Lake&nbsp;City,&nbsp;Utah]]...

If we wanted that we would use a{ white-space:nowrap; } in the CSS. Personally I think that would create an ugly log-jam but at least it could over-ridden on the client side and it wouldn't make a mess of the edit box. As for things like 17&nbsp;sq&nbsp;ft (equally ugly) it would actually be clearer to set up a template like {{unit|17|sqft}} which would work just like {{convert}} but without actually converting. That is, it would add the all-important non-breaking spaces plus avoid inconsistent variants such as "sq ft", "sq. ft.", "square ft.", "ft.2", "ft²", etc. (I don't really care which one, but we should use the same format for all square-foot measurements unless part of a direct quote). — CharlotteWebb 22:07, 10 December 2008 (UTC)

Greg:
Many rebel spies died in the quest to find two adjacent commas at Wikipedia. They found none; but their memory is with us always. Some recherché mathematical constructs are theoretical possibilities (most of them would use special markup anyway); but then, so are unicorns. {Your proposal is simple, sensible, and (should be) uncontroversial. Yet, for reasons I can not yet fathom, there is controversy and opposition. You’ve flown in here like a big magnet dragging some nonsense-IEDs that I care not drive by any longer. I support you on this. But after reading some of the below, I quickly had an epiphany regarding what we’re dealing with. God-speed. ;·) Greg L (talk) 23:25, 10 December 2008 (UTC)}
Kaldari:
With respect, you have not thought long enough, and you have not read considered analyis by other editors before pontificating. The proposal is not "crazy". If anything, it is crazy to propose for the hard space an entity visually indistinguishable from an ordinary space in the edit box. What's more, it is an entity that only a tech-nerd has any notion of, let alone how to input the wretched thing. The case is quite different with hyphens, en dashes, and em dashes, all of which can plainly be distinguished in ordinary Wikipedia display. Do you seriously think that editors should – all of them, each time – alter invisible spaces to invisible hard spaces just because they might be ordinary soft spaces?
Go and read. Then think. Then respond.
Charlotte:
There are such templates, as you can see if you read our material, or simply look at WP:MOS. They are clunky and buggy, and never likely to be used by the average volunteer at Wikipedia. Please get up to speed with the issues before reiterating what has been covered thoroughly before.
–⊥¡ɐɔıʇǝoNoetica!T– 22:24, 10 December 2008 (UTC)
The average volunteer will also not know or care what the MOS says, much less know when, where, and why to use an nbsp. Could you point out the template you are talking about? I'd like to use it and find out how "buggy" it is. All I see in the MOS is {{nowrap|8 sq ft}} which I'm quite familiar with, but it isn't what I'm after because it does not standardize the symbols/abbreviations of units (like {{convert}} does). This would be aesthetically more important than the nbsp in most cases, and at least equal in others. — CharlotteWebb 17:13, 11 December 2008 (UTC)
⊥, I've been involved in this debate since you were in diapers. Back in the sixties, we spent 55 months debating whether or not non-breaking spaces should be used after en dashes on Wikipedia. It ended in mutual annihilation and Wikipedia was lost from the face of the earth for forty years. Basically, my point is that non-breaking spaces are not critical to Wikipedia. If non-breaking spaces didn't exist at all, no one would be any less enlightened by Wikipedia. Non-breaking spaces are a nicety. The fact that people want to bend over backwards to invent new mark-up and new esoteric templates in order to make sure that non-breaking spaces are always used wherever they can be used is a huge waste of time and effort. Worse, it makes our mark-up cumbersome and intimidating. Kaldari (talk) 22:34, 10 December 2008 (UTC)

(outdent). I am surprised that you are objecting to any of this Kaldari. I am flabbergasted that you object to it all. Non-breaking spaces are required for numerical equivalences that have a unit symbol. Thus, you statement “…my point is that non-breaking spaces are not critical to Wikipedia” makes no sense at all. Further, I don’t think you read a damned bit of what I wrote above, which explained perfectly well why one doesn’t use characters that are indistinguishable from their regular counterparts when in edit view; it makes it much more likely that later editors will just type the regular hyphen or regular space from the keyboard. Avoiding this saves other, more experienced editors and bot operators a bunch of clean-up work. All we’re talking about is adopting a wiki-markup that is even more convenient for experienced users and much easier for novices than typing out “&nbsp;”—a most uncontroversial proposal. Finally, when you wrote If you guys think "&nbsp;" is more "friendly" than a non-breaking space character…, that once again makes it abundantly clear you aren’t reading and remotely understanding what either of us wrote. Try reading about what “hex code”, “numerical code”, and “friendly code” means. Beyond these is another step of convenience: wiki-markup.

I don’t know what kind of emotional baggage you brought with you into this discussion from previous dealings, but your position is unsupportable and your writings make no sense and are full of more holes than a sponge. I will no longer respond to your utter nonsense and will only discuss this thoroughly reasonable proposal with more sensible editors. Goodbye. Greg L (talk) 23:08, 10 December 2008 (UTC)
Another $0.02...

  • Regarding "&nbsp; is there under the edit box", I didn't write that it wasn't under the edit box—rather that it isn't "mentioned in the pop-up WP "Editing help" window.
  • The thought experiment is nothing more than a blissfully extravagant use of twenty seconds. We do have an industry-accepted HTML-standard way of inserting non-breaking spaces—so such imaginings will always be divorced from reality's starting point. However, if you wish to consider a starting point in reality, the double comma is getting close to perhaps the least intuitive way of entering a non-breaking space I can imagine (should I wish to indulge in experimentation with thoughts). It simply appears as an inopportune symptomatic application of a tremor-related illness, or perhaps the unfortunate neglect of data-entry as a result of a memory loss-related affliction. (I make these whimsical observations on the basis that a comma is an extremely common character.)
  • The example of "15 kg" somehow suggests that I'm in favour of splitting the line as presented in the example. What an unusually leading argument. Please re-read "non-breaking spaces are rare compared to italics and bold formatting" and then wind back your extensions to be wholly contained within my written meaning.
  • If it is judged by others to be necessary to overload something, I would lean towards using the tilde character: ~ (as it is used in TeX), or perhaps something radical such as three of the Vertical bar or "pipe" characters: |||. There may be reasons against that triplet, but there is so little chance of that combination being contained in regular text as makes no difference. Sure, ||| isn't particularly intuitive either, but | is such a rare character that it implicitly draws the editor's attention to the use of something special (I don't believe a double comma does that).
  • I give WP editors more credit than (most) others. I agree with Greg L in that editors should "quickly understand that something is special about it" when they see something like &nbsp;. At least editors stand a chance of learning something that is accepted outside of WP.
  • I would favour a change in the WP edit box to allow a simple click to insert the &nbsp; character; but not by clicking on the current label of "&nbsp;". Rather, the editor should be able to click on a label of "non-breaking space".
  • Truth be told, I'm not in favour of '' and ''' coding to indicate bold and italics (or is it the other way around?). To this day, I always have to stop and think which is which combination (and the application of bold and italics to a piece of text simply looks ridiculous—in terms of the coding). On the other hand, once it is realised that <b></b> and <i></i> can be entered, there is never a confusion again.
  • If I'm really going to get onto a soap box, I fail to see why a decent RTF editor hasn't been implemented in WP by now. There are plenty of good ones commercially available and I'm sure WP could tailor one to meet its needs. (Of course some level of markup code would still be necessary.) A (close to) WYSIWYG editor would save all the tedious mucking around with "Show preview" in order to see if an edit has the desired effect. This is the 21st century and we are still expected to use 1980's technology (like ASCII text editing). No wonder so many people get worked-up regarding arguments on how to enter artificial codes.
  • Sorry, but the more I think about it (no longer a knee-jerk reaction), the less I like overloading the use of a common punctuation marker with a non-intuitive function.

 HWV 258  23:11, 10 December 2008 (UTC)

I think the WYSIWYG editor is what they'll actually spend the $800,000 on. So really, this whole debate will soon be moot. Kaldari (talk) 23:21, 10 December 2008 (UTC)
I would support spending the money for that purpose. I'm not sure that the average WYSIWYG editor allows the (simple) entry of non-breaking spaces (and other codes), so I'm sure there will be a fair amount of development needed for the WYSIWYG editor.  HWV 258  23:42, 10 December 2008 (UTC)
Kaldari and HWV:
Been there. Seen that. Heard that. Gave up. We're realistic enough to know when a proposal, mind-bogglingly reasonable though it may be, is psychologically too difficult for most people to assess dispassionately. This, despite all the finest efforts of rhetoric and rational exposition. Hence Wikipedia's need to spend the best part of a million dollars to workshop the obvious; and hinc illae lacrimae.
–⊥¡ɐɔıʇǝoNoetica!T– 02:04, 11 December 2008 (UTC)
A simplification of the issues involved. There is another explanation as to the perceived psychological difficulties for dispassionate assessment (despite fine efforts of rhetoric and rational exposition)—simply that the proposal is not mind-bogglingly reasonable.
Of course the "best part of a million dollars" should not be spent on a workshop of "the obvious" (however you define that). I'll stick to my belief that the money would be very well spent in implementing a good WYSIWYG editor. Instead of trying to "fix" a flawed system with more artificial codings, a proper WP WYSIWYG editor would address many of the underlying problems at the root. Do you (Noetica) understand WYSIWYG-editing and the way in which it addresses the underlying cause of your concerns? If it's done well, it's not even necessary for an editor to see the low-level text and codes. For example, great flexibility is provided by the RTF file format, and it is very easy to create RTF files using any number of software editors; however no one in their right mind would attempt to analyse the raw codings inside an RTF file. In other words, the Wikipedian should remain blissfully unaware of exactly which code (be it ,, or ||| or &nbsp; or ~ or ° or something else entirely) has been used to store the non-breaking space.
I don't feel like a non-"dispassionate" person in wanting to (strongly) resist the introduction of another "standard". However I am now passionate in not wanting to introduce another standard that overloads the use of a common punctuation marker.
 HWV 258  03:25, 11 December 2008 (UTC)
  • I see nothing wrong with the double comma. It's so simple, looks like nothing else (is unlike the roman numeral III), and does little damage in display-mode when accidentally inserted as a result of parkinsonism. HWV, intuitive mark-up is good if it's available, but this is not that case with nbspaces. If we could all agree on the double-comma, we could at least make a formal proposal to WikiMedia. Tony (talk) 12:34, 11 December 2008 (UTC)
  • I have to ask again because I don't see an answer, but why not use a double underscore in this case? The underscore is much much rarer in normal wikiprose than a comma, will look and, IMO, show the hard space concept better ("15__kg" vs "15,,kg"). The only technical problem may be the interpretation of magic words for the mediawiki software. In any case, something along these lines should be added, it just needs to be something that can be easily determined what's going on by looking at wikitext and the resulting marked up text. --MASEM 12:42, 11 December 2008 (UTC)
    I actually do not like WYSIWYG editors. I would prefer wikipedia to evolve to a more TeX-like formatting from the current HTML-like one. TeX is actually a professional standard for scientific writing. And I am accustomed to writing TeX code manually, which is more productive, in my opinion. A TeX based WYSIWYG editor may be helpful for new users, but if you want to write professionally you need to learn basic TeX eventually. Ruslik (talk) 12:54, 11 December 2008 (UTC) P.S. In TeX the sign for non-breaking space space is ~.
  • I agree with Ruslik in that TeX (or more likely a WP-implementation of LaTeX) should be given serious consideration—especially if a "TeX based WYSIWYG editor" is part of the package. Raw TeX could be frightening for newbies.  HWV 258  22:11, 11 December 2008 (UTC)
  • I suspected that was what was going on. I also think what is going on as that the opponents of Noetica’s proposal fear that merely having ,, be wikimark-up for the non-breaking space will somehow undermine other things they desire, like having a WYSIWYG editor. Irrational, IMO. Greg L (talk) 18:52, 11 December 2008 (UTC)
      • Preformatted text is allowed, and can be achieved by leaving one or more spaces at the beginning of the line(s). Such preformatted text may contain a long series of underscores for a variety of reasons, such as crude ASCII art. Treating double underscores as non-breaking spaces would disrupt such preformatted text. This would be especially unfortunate because it may be new editors, with the least ability to do clever markup, who resort to such preformatted text, and any advice about how to tag it to prevent double-underscore processing is apt to not be understood by the new editors. --Gerry Ashton (talk) 15:59, 11 December 2008 (UTC)
        • Granted about things like ASCII art, but you can also likely encounter that with double commas, and as with that situation, you just need to wrap the section of text to prevent the wiki engine from marking it up. However, I've yet to encounter a case of a newer editor using underscores as a means to do any well-meaning addition to an article, save for trying to evoke a horizontal rule. Nor would it be different for new editors learning what the double and triple single-quotes are for (all outlined in editing help); double commas would still also encounter the same learning curve problem. --MASEM 16:18, 11 December 2008 (UTC)

Variables with two underscores are used for obscure internal variables in many programming languages. It wouldn't be implausible for an page to contain example code like if(__foo > __bar) throw(__conniptionfit());. — CharlotteWebb 16:47, 11 December 2008 (UTC)

Again, granted, and another case that nowiki tags can be used for. (Double commas could happen to, eg "for(i=1,,i++){}" even though as noted above better formatted code would have a space between those. --MASEM 17:03, 11 December 2008 (UTC)
Charlotte:
You write: "The average volunteer will also not know or care what the MOS says, much less know when, where, and why to use an nbsp." Well:
  • I agree that it's like that now. We have to behave ourselves better and earn more respect in the wider community. In my opinion, we start by ourselves valuing the work of MOS, and respecting fellow MOS editors. See this recent MOStalk thread. All of us could do better!
  • The proposal is not strictly a MOS issue, any more than use of '' and ''' is. Use of hard spaces is a MOS issue, whichever way hard spaces are achieved.
You write: "Could you point out the template you are talking about? I'd like to use it and find out how 'buggy' it is. All I see in the MOS is {{nowrap|8 sq ft}} which I'm quite familiar with,...". Well:
  • You didn't say that you're familar with that. The other templates are presented at WP:NOWRAP. For all of these, bugs have to do with treatment of spaces at the start and end of the string in the template, as well as others discussed at that page. I have not followed recent developments, but last time I surveyed these there were problems. See also the talkpage for {{nowrap}} itself. Markup with ,, is far more robust, transparent, flexible, and usable than any template I have seen, or than any that is technically feasible – if the template-nerds are to be believed. And 17,,sq,,miles is much easier to parse (for editors or software) than this: He said it was "''Plato's'' idea, not ''Socrates'''" (yielding this, with its second hard-to-see apostrophe: He said it was "Plato's idea, not Socrates'"). Comes up often, but such complications for the ,, markup would arise extremely rarely. Editors could easily live with it.
HWV258:
You write: "Do you (Noetica) understand WYSIWYG-editing and the way in which it addresses the underlying cause of your concerns? If it's done well,...". Well:
  • Of course I understand! The big problem is the if that you continue with. In working on our proposal we found just how badly these things can be managed, if development is dominated by technical code-oriented experts. There are other sorts of experts; we have many of them working at the MOS-pages, and their point of view is not valued enough. How else to explain the strange selection and arrangement of the clickable markup under the edit box? What's worse, there is no publicly transparent dialogue between whoever it is that makes those decisions (affecting all editors, and of great relevance to the work of MOS) and anyone outside the clique. So it is, as always, more a matter of control than mere domination. Consultation is difficult and patchy, and likely to be thought an inconvenience when it concerns technical matters like the hard space: a topic whose implications for actual writing and editing are poorly understood by tech-nerds, as we continue to observe.
–⊥¡ɐɔıʇǝoNoetica!T– 21:39, 11 December 2008 (UTC)
Being an optimist, I still aim for the benefits of a better system—one that fundamentally avoids the problems now faced; so I therefore have no appetite for the introduction of more patches. I agree that better consultation (from different skill areas) would be very valuable, and I would be intensely interested in a dialogue over the introduction of a professional layout language (such as TeX).  HWV 258  23:16, 11 December 2008 (UTC)
  • To Charlotte: There already is {{val}} for things like 17 sq ft, but there also are othes cases when non-breaking spaces should be used, e.g. 2 + 2 = 4. This one (2&nbsp;+&nbsp;2&nbsp;=&nbsp;4) is awkward to read in source, {{nowrap|2 + 2 {{=}} 4}} needs that awful {{=}} kludge, and {{nowrap begin}}2 + 2 = 4{{nowrap end}} is very long.
  • To MASEM: It'd be for(i=1;;i++){}, with semicolons...
  • BTW, I think that even a single underscore would be OK for the non-breaking space. I've checked "Today's featured article" and the ones in the four days before, and all the underscores I found in their sources were in URLs, except for one or two of them, which were in template parameter names. Almost all underscores in text are likely to be in code, which should be marked up with <code> or <source> anyway; the other ones would be so few that using <nowiki> with them would be no problem. Also, considering that underscores are ignored in article titles, this would mean that [[Salt_Lake_City,_Utah]] would be completely equivalent to [[Salt Lake City, Utah|Salt Lake City, Utah]], and much less awkward.
  • Imagine. 2_+_2_=_4 would look like 2 + 2 = 4 (and like 2 + 2 = 4 would, if my browser didn't convert the hard spaces I'm inputting into normal spaces), but inputting the former would take one fourth of the time that inputting the latter takes, and would be lots easier to read in the edit box. -- Army1987 – Deeds, not words. 17:36, 12 December 2008 (UTC)
Ah thank you. {{val}} seems to be what I was looking for. For things containing an equals sign you could use <math>2 + 2 = 4</math> to get
Depending on user prefs this will appear as <span class="texhtml">2 + 2 = 4</span> or as a PNG image. In either case it will not line-wrap because we have this in MediaWiki:Common.css:
/* Stop HTML formulae breaking in silly places */
span.texhtml { white-space: nowrap; }
So that would easily be the best bet for this example. — CharlotteWebb 18:17, 12 December 2008 (UTC)
I know, it was me who asked to add that line in the stylesheet. (I don't like using TeX inline for very simple expressions like that one because they use serif type, and I don't like to mix typefaces on the same line if there's no good reason to do so; but maybe that's just me...)
But that was just an example. There are many examples where hard spaces make sense – Séamus Ó&nbsp;Grianna, 12&nbsp;December, {{lang|fr|''Qu'est que c'est&nbsp?''}}, yadda yadda yadda. Do we create a template for each possible class of usages of hard spaces? Wouldn't a simple way of entering non-breaking spaces (such as _ or __ or ,, or whatever) be more useful? -- Army1987 – Deeds, not words. 20:33, 12 December 2008 (UTC)
Just to be sure on this: are you suggesting nbsp's in people's names as general rule (ewwwww, personally) or just between "Ó" and "Grianna" because they are part of one surname semantically equivalent to "O'Grianna"? E.g. "Robert De Niro" maybe, but not "Arthur Conan Doyle" or "Mary Jo Kopechne" I'd hope? If French does put spaces before question marks (which seems to be what you are suggesting) I think they would appear rarely enough for the nbsp's not to be annoying. As for dates, might as well continue the thread below. — CharlotteWebb 15:10, 13 December 2008 (UTC)


Dates

The biggest need for an easier hard-space markup is in dates, now that they're being generally delinked — 12,,December, 2008, or whatever, would be much clearer to read and write than 12&nbsp;December, 2008.
—WWoods (talk) 18:20, 12 December 2008 (UTC)

Dates didn't use any kind of "hard spaces" before their hasty de-linking. Why would they need them now? I will admit that the lack of a link makes it less obvious that a number is part of a date, but I'd rather not start arguing about that again. Is it really necessary to add nbsp's for this? — CharlotteWebb 14:35, 13 December 2008 (UTC)

What about -- for en dashes and --- for em dashes?

While we're at it, what about making -- become an en dash (–) and --- an em dash (—), as TeX does? I've seen some use of -- as if it was a dash in articles, probably by naive users who didn't know how to input real dashes. The only other use of -- I can think of is the decrement operator in programming languages such as C (where it would only be found within <code> or <source> tags), and I can think of no other use for ---. This way, it would be easier to distinguish them from hyphens in the monospace font of the edit box. -- Army1987 – Deeds, not words. 20:33, 12 December 2008 (UTC)

I would also like to propose ++ for ampersands and ~~ for tildes ;) Kaldari (talk) 20:52, 12 December 2008 (UTC)
Army and Kaldari, have you read our proposal? We suggest that sort of extension. Have a look at the idea for en dash, in the reply to Objection 9. For convenience, here is the whole document transcluded:
–⊥¡ɐɔıʇǝoNoetica!T– 21:10, 12 December 2008 (UTC)
Kaldari, Sarcasm is really helpful. -- Army1987 – Deeds, not words. 21:30, 12 December 2008 (UTC)
Army, the only problem with that is that usually naive users use "--" unspaced, in place of an em-dash, not an en-dash. Auto-substituting as you propose would produce incorrect typography.--Srleffler (talk) 02:02, 13 December 2008 (UTC)
Not strictly true, Srleffler. More accurately, "--" is one traditional way of making a sentence-level dash (parenthetic, etc.) in a manuscript. It is prescribed for the very influential MLA style, for example. But such a dash would, outside of Wikipedia, be converted in typesetting (not addressed by MLA) to either an em dash (unspaced, or spaced in any of several possible ways) or a spaced en dash. Practice at Wikipedia is quite different, since our editors enter text directly, without any further typesetting stage. Editors directly enter either an unspaced em dash or a spaced en dash, consistently in an article. See WP:DASH for a discussion of these options. Since the em dash has been far more common in America as a realisation of the sentence dash, American style guides typically and insularly ignore the realisation as a spaced en dash, and therefore refer to the sentence-level dash simply as an em dash. See, however, the American-born Bringhurst's wonderful book, which champions the spaced en dash. More at Dash.
–⊥¡ɐɔıʇǝoNoetica!T– 02:47, 13 December 2008 (UTC)
I'm not sure if we're talking past one another here. On Wikipedia, WP:DASH prescribes either an unspaced em-dash or a spaced en-dash for parenthesis and "sharp breaks". These seem to be the situations where "--" is most commonly used by editors unfamiliar with Wikipedia's house style. Auto-replacing "--" with an unspaced en-dash would not comply with WP:DASH in these cases. --Srleffler (talk) 03:42, 13 December 2008 (UTC)
Neither would keeping the "--" intact, would it? -- Army1987 – Deeds, not words. 12:03, 13 December 2008 (UTC)
True, but at least if "--" is rendered as "--" it is easier for other editors to spot the mistake and fix it. If "--" is rendered incorrectly as "–" rather than "—" or " – ", it is harder to notice the error. If we were going to auto-substitute, it might make more sense to make "--" substitute to an em-dash. I suspect, though, that this would cause too many problems. "--" probably gets used now and then for other reasons, where it should not be substituted.--Srleffler (talk) 16:26, 13 December 2008 (UTC)
By the way, I support your ",," proposal above. Looks great. Contrary to the experience of some editors above, I need non-breaking spaces very frequently in the articles I edit. --Srleffler (talk) 03:42, 13 December 2008 (UTC)
Thanks Srleffler. I may not stay around. I am planning to withdraw once more from MOS-editing unless certain overarching issues are sorted out, so that my time is not wasted. See this thread at WT:MOS.
It took me a while to see what you meant, above. I have now added underlined glosses to my own earlier post. Do they help? I'll explain more if they do not.
Best wishes to you!–⊥¡ɐɔıʇǝoNoetica!T– 04:40, 13 December 2008 (UTC)

Making multiple hyphens into [some kind of] dash would be okay if the parser ignores text inside code/tt tags as well as pre/source tags. That in itself would be slightly confusing as similar markup (such as multiple apostrophes for bold/italic) is only ignored in the latter case. I'd argue that at least <code> should also have the effect of nowiki because it is used for the same purposes as pre/source when we want to keep everything in the same paragraph.

By the way, three hyphens is acceptable code at least in Javascript without raising any kind of ambiguity error/warning.

x = y --- z;

has the same effect as:

x = (y--) - z; or x = y - z; y--;

and not this:

x = y - (--z); or --z; x = y - z;

and obviously not this either:

x = y -(-(-z));

I realize it would be stupid to write this without at least a space between the second and third hyphen but it would be reasonable to find examples like this in an article about obfuscated code or operator precedence. We'd want to keep this in mind too when considering which markup to ignore. — CharlotteWebb 13:39, 13 December 2008 (UTC)

Due to the potential for false positives it might be best to consider this a temporary format fix and later do what MOS people refer to as an "audit". That is, get a database dump and replace all multiple hyphens by a literal "—" or "–", or nowiki them if neither dash is appropriate (shrug). — CharlotteWebb 13:46, 13 December 2008 (UTC)

Yes, it'd make sense to disable markup from within <code> tags, too. For example, '' can be used as an empty string in some languages. -- Army1987 – Deeds, not words. 16:49, 13 December 2008 (UTC)
Exactly. This would only make it more explicit that "<code>" is intended to mean "code other than enabled wikitext". An in-line version of the <source> tag (fancy syntax highlighting and all) would be great too. Perhaps the code tag can be made to also do that. — CharlotteWebb 17:13, 13 December 2008 (UTC)
Why "other than wikitext"? It is the tag which I use for examples like <span class="quux">{{foo|''bar''|'''baz'''}}</span>... -- Army1987 – Deeds, not words. 19:53, 13 December 2008 (UTC)
Yeah I phrased that wrongly. — CharlotteWebb 19:58, 13 December 2008 (UTC)

"$400,000" is more precise than "beautiful"?

In section 7 "Unnecessary vagueness", the following example is found:

Vague Precise
A beautiful little house in Malibu In 1974, a $400,000 residential property in the Malibu area

This example illustrates perfectly the following statement from The Little Prince:

If you were to say to the grown-ups: "I saw a beautiful house made of rosy brick, with geraniums in the windows and doves on the roof," they would not be able to get any idea of that house at all. You would have to say to them: "I saw a house that cost $20,000." Then they would exclaim: "Oh, what a pretty house that is!"

I think that I have remained a child in spirit (although being actually fully grown-up), since I do not find that "a $400,000 residential property" is more precise than "a beautiful little house". :-) (Yes, I am serious, I am really not used to measure size and beauty in dollars.) —83.176.40.177 (talk) 21:10, 11 December 2008 (UTC)

Also "in Malibu" is pretty obviously more precise that "in the Malibu area". Phil Bridger (talk) 22:04, 11 December 2008 (UTC)
I would agree that "beautiful little house" isn't exactly in encyclopedic tone and it'd better be avoided in articles (except in quotes), but I wouldn't call the problem with the former "vagueness". Also, do we need "residential property"? Wouldn't "In 1974, a $400,000 house in Malibu" be OK? -- Army1987 – Deeds, not words. 17:41, 12 December 2008 (UTC)
This is a poor example, but for other reasons. If I'm going to pay $400,000 for a house it had better not be "little". Also "residential property" is markedly less precise to be serious. An apartment building (closer to that 400k figure perhaps) or a trailer park or a lot which is completely vacant but zoned for residential use… any of these purchases would be residential property but not called a "house". — CharlotteWebb 17:46, 12 December 2008 (UTC)

New proposals

I have drawn up some new proposals for ammending the existing wording of the date linking policy. Which I hope may be an acceptable compromise for both sides of the dispute. They are currently in draft form at User:G-Man/works in progress.

I would appreciate it if someone could tell me how I could put this to a formal vote. G-Man ? 22:12, 11 December 2008 (UTC)

I don't see how this will help. The "mays" in "some situations where it may be acceptable to link dates, may include" are really indications that consensus is against linking any of these dates except in very few exceptional circumstances. There is no need to specifically cater for such exceptional circumstances in guidelines because, per WP:IAR, every guideline should be interpreted as allowing for exceptions where they are clearly for the benefit of the encyclopedia. Phil Bridger (talk) 22:40, 11 December 2008 (UTC)
I was merely attempting to clarify what reason to do so actually means in practice, based upon the feedback at the various RFC's. At the moment there is no definition of what this actually means, so can be interpreted in practically any way. I have changed the wording slightly. P.s you didn't answer my question. G-Man ? 23:12, 11 December 2008 (UTC)
The Manual of Style is merely a guideline, not a policy, even without invocation of WP:IAR. Therefore, no MOS statement would be binding, regardless of whether the statement uses should, could, must, shall, or may not. Various people have suggested to the MOS enforcers that they first attempt to make the MOS a policy. But, there is clearly no consensus for doing that. So, we are left with a highly charged debate over the MOS that doesn't make much difference anyway, particularly in view of the Wikipedia precedent that a consensus for a particular article prevails over a consensus that purports to cover all articles. Aside from these problems, the proposed amendment is vague and would not avoid protracted controversy, especially concerning the "have a reason for linking" requirement. Tennis expert (talk) 10:00, 12 December 2008 (UTC)
  • G-Man. I took a look at what you propose. Please carefully read the statements that accompany each vote in the two RfCs. I don’t think any reasonable interpretation of the general consensus would allow dates for births and deaths to be linked. Greg L (talk) 05:44, 12 December 2008 (UTC)
I agree with Greg entirely. Tony (talk) 09:39, 12 December 2008 (UTC)

If a running RFC is edited by the addition of a new clause, people have a different set of options with and without the new clause. That means the 'without new clause' voting has ended. Do we run the 'with new clause' voting for the same duration? Lightmouse (talk) 09:44, 12 December 2008 (UTC)

  • By all means put it to another RfC. I'm not sure if you were meaning to, but your poll shouldn't be tagged onto the existing one(s) under any circumstances. Nevertheless, I think it best if we left the interpretation of the RfC to the closing admin, because at the present time, I would agree with Phil Bridger that the consensus is that date articles should be linked to once in a blue moon. Ohconfucius (talk) 09:56, 12 December 2008 (UTC)

I agree. A running RFC should not be modified. Lightmouse (talk) 10:35, 12 December 2008 (UTC)

Okay then, I wasn't neccesarily proposing that it be tagged upon the present RFC. I was just wondering what process to follow for it to be put to a vote. In reply to Tennis expert, surely it is better to have a more clearly defined guide than an utterly vague one. In respnse to Greg L I have read the RFC comments and linking of birth date links or start/end dates kept coming up as a potential reason. So I was attempting to accomodate that view. I certainly fail to see how linking a handful of dates could actually be harmful. G-Man ? 23:01, 12 December 2008 (UTC)

  • It’s an emotional issue, G-Man, and a minority of editors who really, really like linked dates have been throwing their bodies onto the electrified barbed wire in a vain effort to breach the enemy positions. The majority is just sick to death of these links to articles that are essentially trivia that is not at all topical or germane to the articles containing the links. The feeling is that the rare exceptions where such a link makes sense, must be quite rare indeed, for those who want them banished haven’t yet found a suitable exception to the rule. Greg L (talk) 06:20, 13 December 2008 (UTC)
    • Clearly it is emotional; it inspires false claims like this. Only a handful want to link all dates, but at least half of the editors who have discussed it like linking some occasional dates; the other half can't imagine why they would like to. Another emotional handful really really want to delink all dates; three or four at most. It would be nice if both extreme groups found something else to do; but the impulse to Control All Wikipedia, even over something as trivial as this, is irresistably sweet to some minds. How is this misstatement is intended to convince G-Man, who has clearly read the RFC? Septentrionalis PMAnderson 20:49, 13 December 2008 (UTC)

As for the substance; there is no consensus to always delink; there is no consensus to link rarely (there is consensus against always linking). The only possible wording would be to acknowledge the disagreement and then say something like, those who support linking link for these reasons:. Septentrionalis PMAnderson 20:49, 13 December 2008 (UTC)

Greg, I have read the RFCs, and it seems apparent to me that there is a very large body of opinion which does agree with linking at least some dates, which is at least as large if not larger than the body of opinion which sees tham as the work of the devil. This fact may be inconvenient to you, but your claims about 'the vast majority' cannot be surported by the evidence. What we currently have, is a small gang of extremists who appear intent on bludgeoning everyone into accepting their extreme views by brute force. This is not acceptable or sustainable if we are to accept the notion that wikipedia operates by consensus rather than brute force. Ultimately, both sides will have to reach some sort of accomodation with each other, which will not involve either linking or delinking ALL dates. So this is what I was attempting with my proposals, a compromise which gives some consessions to both sides, and hopefully (ha!) most people could agree to at least live with. If you think you have a better idea for solving this, then by all means let me know what you think it is. At least my proposals are a step in the direction of sanity, even if they are not perfect. G-Man ? 00:16, 16 December 2008 (UTC)

Broken autoformatting e.g. [[April 11]], [[2005 in aviation|2005]]

moved from Lightmouse talk page: begin

I see you've removed the braking mechanism from Lightbot but I thought you had repaired it so things like this wouldn't happen any more. The strong consensus is to not strip the useful "(year) in radio" tags to just the bare year! It's clear from the diff that Lightbot is still doing it, even after reassurances that it would no longer do so. Please stop the bot until you can affirm that it will no longer strip tags of this sort of their contents. - Dravecky (talk) 16:54, 12 December 2008 (UTC)

The format:
  • [[April 11]], [[2005 in radio|2005]]
is broken. You are not unusual in being unaware of that, it is a popular misconception about date links. Lightmouse (talk) 17:03, 12 December 2008 (UTC)

I'm well aware of the autoformatting issue and, as has been discussed many times, the proper fix is to remove the brackets from the month-day pair, not to strip the useful link to the year in radio (or in sports, in music, in television, etc.) This has been discussed ad nauseum and the consensus has been quite clear. - Dravecky (talk) 17:18, 12 December 2008 (UTC)

Lightmouse, there was a long and detailed discussion only a month ago about this exact issue (see Wikipedia:Administrators' noticeboard/Archive176#Lightbot — it's the fourth discussion on that page, in case the section link doesn't work), during which you stated that you would no longer make this exact type of edit. Several users, Dravecky and myself included, consented to the closing and archiving of the discussion having taken you at your word on this. Mlaffs (talk) 17:23, 12 December 2008 (UTC)

I have no objection if you remove autoformatting. Lightmouse (talk) 17:30, 12 December 2008 (UTC)

I'm sorry, but I'm not sure what you're saying with that statement. This isn't about asking if you're okay if we remove autoformatting. The bot is fixing broken autoformatting, by removing the valid contextual link. Three issues - first, if autoformatting is deprecated, why does broken autoformatting need to be "fixed"? Second, why would you feel that the deprecated autoformatting should take precedence over the valid contextual link? Third, and most important, why is the bot making edits like these again when you said that it would no longer do so? Mlaffs (talk) 17:39, 12 December 2008 (UTC)

I will try to answer your questions one by one:

  • Autoformatting is indeed deprecated. It can be absent or it can be present. But it shouldn't be present *and* broken.
  • I am not running a test for precedence. I am fixing an error.
  • I said that I would stop fixing these errors because I got frustrated. I am no longer frustrated. I see these errors still exist so I decided to start fixing the errors again.

If you want to fix the errors in your own way, that is fine by me. These errors should not have been created. When you revert these edits you are recreating the error. I find it hard to be persuaded that errors should not be fixed. Lightmouse (talk) 17:51, 12 December 2008 (UTC)

moved from Lightmouse talk page: end Lightmouse (talk) 17:53, 12 December 2008 (UTC)

For what it's worth, I haven't reverted any edits that you've made today. I did revert quite a few edits that you did on November 10/11 when this issue first came up, but I did so only on the edits to infoboxes and I did so by removing the link to the day/month pair and reinstating the contextual "year-in-radio" link for the year. If you're going to start fixing these errors again, and I have no quarrel if that's your plan, then I'd suggest that this would be the approach that's both consistent with MOSNUM and unlikely to cause contention. Mlaffs (talk) 18:16, 12 December 2008 (UTC)
(edit conflict)Lightmouse, you said at ANI that you would no longer make these kinds of edits and, on that basis, the issue was put to rest and no further action was taken. So you're now saying that this was a temporary smokescreen while you were "frustrated" and now you're back to violating a strong consensus against removing contextual links in the guise of "fixing" autoformatting? Removing the brackets from the month-day pair fixes autoformatting while leaving the contextual link intact. If Lightbot were to take that tack, I doubt there would be an issue but the present course is unacceptable, especially based on your statements at ANI. (P.S. Your change of the section header when you moved this to MOSNUM is disingenuous, at best.) - Dravecky (talk) 18:19, 12 December 2008 (UTC)

Even if they didn't break date formatting, piping links like this would still be undesirable as it visually obscures any potential usefulness of the topic-specific year link. — CharlotteWebb 18:02, 12 December 2008 (UTC)

I'm happy to concede that it's not always the best way to handle links to "year-in" articles, and I certainly wouldn't add a link like that within the narrative portion of an article. But MOSNUM specifically envisions this as being an acceptable usage in infoboxes, tables, etc. That's what we're talking about here. Mlaffs (talk) 18:16, 12 December 2008 (UTC)
Still awkward as part of a full date, especially as we have no event index for April 11 in radio. — CharlotteWebb 18:28, 12 December 2008 (UTC)
True, which is why the date would/should appear as "April 11, 2005" with only the contextual link to the year present. - Dravecky (talk) 18:33, 12 December 2008 (UTC)
As Dravecky notes, it's 'year in radio' rather than 'date in radio' that's being removed. I hope there are no 'date in radio' articles - that would strike me as trivia or coincidence rather than context. Either way, even if 'year in radio' were awkward in this case (and I'm not conceding that it is), surely the solution to the problem is not to remove a valid contextual link without leaving in its place a different way to present that information? Isn't an awkward link to good information better than no link to it at all? Mlaffs (talk) 18:51, 12 December 2008 (UTC)
I really have to squint to see how one is more trivial than the other. Remind me to remind you of something to work on if you're bored in 2010. Maybe I can help. — CharlotteWebb 20:51, 12 December 2008 (UTC)

No, we are only discussing use within 'autoformatted' dates. I note that Special:Contributions/Dravecky is doing a mass rapid revert and recreation of those errors. Either fix the errors yourself or let me do it. But don't damage articles by putting a defect back. Lightmouse (talk) 18:21, 12 December 2008 (UTC)

Actually, I was doing a careful one-at-a-time revert to undo the damage caused by your bot. Restoring the contextual link is a lesser evil than potentially breaking the largely-invisible autoformatting problem, one which a properly configured bot could solve by removing the bracks from the month-day pair instead of stripping the contextual link of its context. - Dravecky (talk) 18:33, 12 December 2008 (UTC)
I don't agree and I believe there is a project consensus not to use Easter Eggs this way. If I am correct, Lightmouse's edits were right. I wonder which is worse, trying to improve the encyclopedia by fixing broken formatting, or mass-reverting someone else's edits to make a point. Hmmm. --John (talk) 19:44, 12 December 2008 (UTC)
Yes, see WP:EGG. — CharlotteWebb 20:51, 12 December 2008 (UTC)
I've read WP:EGG which is why I know it says "However, piped links may be useful in places where compact presentation is important (some tables, infoboxes and lists); and in the main prose of articles in which such links are used heavily, as is often the case with sports biographies that link to numerous season articles." Which is why it was improper, per WP:EGG to remove the contextual link from here, here, here, here, here, here, here, here, here, here, here, and, well, I could go on but I think you get the idea. - Dravecky (talk) 21:16, 12 December 2008 (UTC)
Dravecky did nothing wrong in correcting the errors made by Lightmouse, which appear to be flagrant and intentional. This is just the latest episode of major problems with his edits. Tennis expert (talk) 21:36, 12 December 2008 (UTC)
  • Of course they were intentional: broken autoformatting syntax, which this clearly is, needs to be rooted out. It was wrong to insert it in the first place. Lightmouse, please continue to fix up the lamentable state of WP's date formatting. Tony (talk) 00:15, 13 December 2008 (UTC)
  • I've no objection to fixing broken autoformatting. I do strongly object to removal of the contextual links against consensus, guidelines, and Lightmouse's promise at WP:ANI last month. The autoformatting can be fixed just as simply by removing the brackets from the month-day pair, leaving the contextual link intact. - Dravecky (talk) 00:47, 13 December 2008 (UTC)

Lightmouse, why isn't your bot changing [[April 11]], [[2005 in radio|2005]] to April 11, [[2005 in radio|2005]]? That would appear to have more consensus.--Srleffler (talk) 02:19, 13 December 2008 (UTC)

    • Please stop removing contextual date links that are piped in tables and infoboxes. That are permitted clearly under WP:EGG and the recent RfC on date links. You did agree to fix the bot/script so that it will not to do that anymore.--2008Olympianchitchat 02:23, 13 December 2008 (UTC)
      • Conversely, I wish people would stop piping these links so that our readers are highly likely to ignore them. Do them a service (using WPian expertise) of either working the link into the inline sentence grammatically (bluing the minimum, please) or listing the key ones in the "See also" section, with helpful advisory text. Tony (talk) 07:06, 13 December 2008 (UTC)
        • No, some of these are in infoboxes and tables where they are permitted to be piped. The bot needs to stop removing any piped links unless it can distinguish between those that are permitted and those that are not.--2008Olympianchitchat 00:51, 15 December 2008 (UTC)
== See also ==

*[[2005 in radio]]

[[Category:2005 in radio]]

{{2005-radio-stub}}

If you already have something like these there's no need to include "2005 in radio" with every exact date. If these are positioned too low for your liking you could set the infobox to a add a line with See also: [[{{{year}}} in {{{topic}}}]] based on the most important date in the article, such as the D.J.'s date of birth or the station's first broadcast, etc. Just try to make it more obvious to readers what they are clicking on, whenever possible. — CharlotteWebb 14:51, 13 December 2008 (UTC)

  • Combining a concealed link with autoformatting is wrong because it is a broken and invalid format.
  • It has always been wrong.
  • It is wrong if you like concealed links and it is wrong if you don't like concealed links.
  • It is wrong if you like autoformatting and it is wrong if you don't like autoformatting.
  • It was wrong before the RFC and it will be wrong after the RFC.
  • It has never been permitted in any location on any page.

Those editors that are most involved in the debate about date links, should know why it is invalid. Those editors that understand why it is invalid and broken should be able to explain to those that don't understand. It is not a matter of opinion and I am tired of having to explain the valid formats for a technology that I don't even like. I hope that helps. Lightmouse (talk) 13:30, 15 December 2008 (UTC)

    • Yes, yes you keep saying this. Yet multiple editors repeatedly ask you to remove the piped "year in x" links from the ambit of your bot/script (which I like and use beyond this). Is it just impossible for you to do so? I do not think that anyone is trying to set up links this way at the present time, but in the de-linking of dates no one wants to lose what are valid links. Why can t=it not just delink the month and day and leave the "year in x" link alone?--2008Olympianchitchat 06:15, 19 December 2008 (UTC)
Re 3rd point: Indeed, it actually breaks auto-formatting for those with yyyy-mm-dd dates set. Orderinchaos 10:52, 17 December 2008 (UTC)
That's why the proper solution is to de-link the month-day pair: it eliminates the broken autoformatting (which is the whole point, right?) while leaving the useful, explicitly permitted by the MoS contextual link alone. If this really about fixing broken autoformatting and following the MoS, it's the only possible solution. - Dravecky (talk) 14:58, 17 December 2008 (UTC)
Agreed, there's no reason to be delinking "year in X" links indiscriminately, given the examples that have already been shown of this messing with approved behavior of infoboxes. —Preceding unsigned comment added by Sukael (talk • contribs) 21:49, 19 December 2008 (UTC)

[[2001 in underwater basket-weaving|2001]]

Any idea how to obtain a complete list of templates which produce these type of links? I found a few —{{by}}, {{fy}} (potentially confusing as it is the language code for Frisian, cf. {{fy icon}}), {{ly}}—plus a few more but they do not seem to be grouped in any way. — CharlotteWebb 03:58, 15 December 2008 (UTC)

I don't know how to get a list of them all but I found:
Lightmouse (talk) 12:21, 15 December 2008 (UTC)

If the m.o.s. means anything these should probably be orphaned and deleted as found. — CharlotteWebb 19:05, 15 December 2008 (UTC)

Why, when their use in tables and infoboxes would be completely consistent with the MOS? Mlaffs (talk) 19:29, 15 December 2008 (UTC)
Indeed, the MoS is quite explicit that these links are entirely appropriate for use in tables, infoboxes, and in the prose of certain articles. - Dravecky (talk) 20:14, 16 December 2008 (UTC)

Charlotte, there are many tables and infoboxes that have multiple piped links in them,; see the table in List of Phoenix Suns head coaches or the infobox in Troy Aikman to see to what WP:EGG refers.--2008Olympianchitchat 06:15, 19 December 2008 (UTC)

Autolinking dates

Style Example
MMM, DD YYYY January 15, 2001
DD MMM YYYY 15 January 2001
YYYY MMM DD 2001 January 15
YYYY-MM-DD 2001-01-15

Per archived discussion the linking of dates in articles are now discouraged. That bothers me for two reasons

  1. First of there were only 10 support votes and 3 oppose votes. It doesn't strike me as a community wide discussion.
  2. The on-wiki method still uses linkage. For example [[2008-12-14]] usage yields 2008-12-14 which is by default 14 December 2008. If there is consensus behind this why has no one filed a buzilla that facilitated the real change.
    • I know not everyone likes the international format which is DD MMM YYYY. On your user setting you can configure it to any one of the other ways as demonstrated in the table to the right.

The ISO formating is widely used on lists where a date is present. Such lists are used on a wide variety of topics documenting chronologic events.

My stance:

  1. I really like the feature and feel it should stay.
  2. For people who dislike the feature an option should be added to the user settings.

-- Cat chi? 21:47, 14 December 2008 (UTC)

This is, indeed, the best solution. However a small group of editors here wish to force the rest of us to see articles as they see fit. It's pure arrogance and unbecoming on a wiki. —Locke Cole • t • c 22:05, 14 December 2008 (UTC)
Hey LC… RfCs close on December 25, which incidentally is… Christmas Day °<:D °<:D °<:D
So you better watch out, you better not cry,
Better not pout, I'm telling you why:
Santa Claus is comin' to town.
He's making a list and checking it twice,
Gonna find out who's naughty and nice,
Santa Claus is comin' to town.
--Goodmorningworld (talk) 20:48, 15 December 2008 (UTC)
The last time I checked, RFC2/Q2 seemed to show significant support for some autoformatting method. I don't see how you can say there consensus against some autoformatting. — Arthur Rubin (talk) 20:55, 15 December 2008 (UTC)
  • Finally, you’ve stated something I can agree with, PMAnderson. I think we just opened a rift in the space-time continuum. Indeed RfCs are not technically “votes”, it is “polling” in Wikipedia parlance. It may seem like it is purely an issue of semantics, but it goes deeper than that. The basic idea is that identifying a Wikipedia-style consensus requires rational and civil comments to accompany one’s up or down “vote” so other editors are influenced towards your way of thinking. In the end, it is a bit like the tribal council concluding that “Big Bear’s and Winter Eagle’s words are strong and we should do as they suggest.” “We also think Fire-In-His-Hair’s and PMAndeson’s words lack wisdom.” The following is from Wikipedia:Consensus#Participating_in_community_discussions:

Polls are structured discussions, not votes. Opinion has more weight when you provide a rationale during a poll, not just a vote. Convince others of your views, and give them a chance to convince you. Pure argumentativeness rarely convinces others.

The RfCs poll responses on date delinking are, for the most part, entirely in keeping with the required spirit for consensus building and any rational, unbiased interpretation of what that consensus is clearly shows that routinely linking dates such as births and deaths is no longer to be practiced. You are perfectly free to offer up all your nonsense interpretations of what it all means. We have ways of dealing with that sort of stuff, starting with not giving it much, if any weight; and, if you persist, outright ignoring you. Greg L (talk) 00:44, 15 December 2008 (UTC)
  • Personally, I can live with dates not being linked, but I don't like how it forces whatever date format is used on the user. Date formatting is restricted to only a few possible combinations. Developers should work on fixing the formatting in such a way that the preferences options work again on articles for whoever has it enabled. - Mgm|(talk) 18:32, 15 December 2008 (UTC)
  • <yawn> As one prominent WPian just told me: "auto-formatting is dead for me", and in some of these discussions, "We are watching the funerary procession walk by". Tony (talk) 00:22, 17 December 2008 (UTC)
  • Yeah Tony, you do. I know you dislike facts for whatever reason, and despite your claims of trying to "come together" with "wikilove" you seem absolutely intent on attempting to silence anything you disagree with, but the RFC leaves us with a clear mandate to work on auto formatting of dates. —Locke Cole • t • c 08:44, 17 December 2008 (UTC)
Ultimately the entire decision lies with the devs. Historically devs tend to make non-crutial but drama-ful modifications to the code optional.
To rephrase my stance "don't force me to use pounds/US dates/inches/miles and I won't force you to use grams/non-US dates/centimeters/kilometers". Leave it optional to make everyone happy.
  • One nice feature would be to make the default dynamic too. So for example if the person viewing the articles is in the US, he or she sees in US system else the non-US system. Of course people would have the ability to switch between systems.
-- Cat chi? 06:28, 21 December 2008 (UTC)
No. Many US military articles use international formatting. Canada, India, and a host of other countries use both. Geographical location of IP addresses is not gonna work. It is now established that dates are nothing special, like colour/or, travelling/ling, and ize/ise. WP's excellent principle of within-article consistency is fine, thanks. We don't need no stinkin' high-tech solutions to a non-problem. Tony (talk) 07:25, 21 December 2008 (UTC)
If you're not the one working on it I fail to see why you would be opposed to it. It makes Wikipedia better, even if you personally think the improvement is insignificant. —Locke Cole • t • c 09:40, 21 December 2008 (UTC)
I still have not seen a proposal for autoformatting that does not hide (some) inconsistencies from (some) editors, making them less likely to get fixed (same argument I gave here). -- Jao (talk) 14:52, 21 December 2008 (UTC)
How about something like "pounds (grams)" displaying in US and "grams (pounds)" displaying in non-US? I do not want to see an elite minority (number of USians in contrast to the rest of the planet) determine the date/measuring system. I also do not want to force USians either. My solution is intended to be a compromise making everyone happy. -- Cat chi? 15:28, 21 December 2008 (UTC)
Jao, the fixes/patches being proposed would also fix the issue of auto formatting for anonymous/unregistered editors. Then the actual internal date format would be irrelevant (since the underlying text would never be displayed raw). —Locke Cole • t • c 15:45, 21 December 2008 (UTC)
Did you actually read the arguments at the RFC page? To quote it, "With the linkless, defaulting system proposed, "was born on [[22 September]] [[1941]] and died on March 31, 1990" looks consistent for some (those with US-style preference set if the article defaults to international, and anyone without international preference set if the article defaults to US-style) but not for others.". -- Jao (talk) 15:59, 21 December 2008 (UTC)
Simple: mark up the date so it gets formatted correctly. —Locke Cole • t • c 16:04, 21 December 2008 (UTC)
Obviously that should be done, yes. But that's my entire point: if not everyone sees the problem, it's less likely that it actually gets done. -- Jao (talk) 17:21, 21 December 2008 (UTC)
Bots could probably handle this with ease, though. We could always highlight autoformatted dates as well (optionally, of course, since the "sea of blue" crowd would probably dislike anything of that sort). —Locke Cole • t • c 17:24, 21 December 2008 (UTC)

Delinking dates is being used as an excuse for improper format changes

Here is an example of an edit summary saying "de-link dates (to intl fmt(, script-assisted date/terms audit; see mosnum, wp:overlink)", which is used as a guise to cloak a change in date format.

I say that is improper. Right? Will anyone back me up in stopping this impropriety?

Or is that just the agenda behind the push to get rid of auto-linking? Gene Nygaard (talk) 07:46, 22 December 2008 (UTC)

Calm down, Gene: do you have evidence that there's some kind of anti-US-format agenda here? It's more likely to have been an error. I've posted on the user's talk page. Tony (talk) 09:11, 22 December 2008 (UTC)
Well, this might be one piece of evidence. And maybe others have similar evidence. If you are going to make the notion of unlinking dates fly, I'd suggest it is in the best interests of those supporting the delinking to make damn sure no editor is going around and making such changes in any edit implying that it is required by an MoS policy about de-linking dates. Gene Nygaard (talk) 13:41, 22 December 2008 (UTC)
I'd like to say that there is most certainly not an anti-US format agenda on my part. Taking the points Tony made on my talk page, I had it in my mind that most European related articles would be covered by point 3 - "Other anglophone countries: must be international". In other words, if not American or Canada, they should be set in international format. However, it may be that I've been misinterpreting that, and if that is the case, I apologise. If I'm reading this right, since countries like the Netherlands aren't English-speaking countries, their date formats in related articles should be left in the way they were started. I realise some standardisation is in place, but perhaps the guidelines need to be clearer so that I, and possibly other editors, don't make the same mistakes elsewhere. I don't want to cause any problems, and I apologise once again if this has caused some inconvenience. -TonyW (talk) 14:48, 22 December 2008 (UTC)
Keep in mind that Canada uses both, so Canadian articles that are already in international format (dmy) should not be converted to mdy. --Ckatzchatspy 21:55, 22 December 2008 (UTC)
This is true, and they should not be changed from one to the other. But in my experience, international-format Canada-related articles are very scarce—even Quebec-related articles. < 5%. Tony (talk) 03:10, 23 December 2008 (UTC)
I daresay it would be tough to find a country in the anglosphere that does not use both in varying degrees. News syndication and software distribution have gone a long way to homogenizing the language.LeadSongDog (talk) 22:25, 22 December 2008 (UTC)
TonyW is right; the guidelines need to be clearer. This is one of the many cases in the MoS and its myriad subpages where you cannot see the forest for the trees. This is a product of instruction creep and the insistence of a small group of editors on overspecificity in the guidance presented in this style guide.
Note further that there are a great many U.S. related articles on Wikipedia now using DD month YYYY format. I'll bitch just as loud if any of them are changed in the guise of accomplishing some MoS mandate to de-link dates.
More than that, too. In many of those cases in particular, I will oppose a change done separately from the de-linking of dates, notwithstanding the simplistic nonsense you find in the overspecific guidelines here. This page simply has no credibility any more. Gene Nygaard (talk) 02:31, 23 December 2008 (UTC)
  • Go and have your say at the RfC, then. A few months ago there was a big push to change the rules, but chaos ensued. I think it would be unwise to branch out with your own set of rules.Tony (talk) 03:11, 23 December 2008 (UTC)
  • Gene and Tony, I think you two are working cross-purpose here. Gene: Any eight-year-old reading the RfCs can tell that the clear consensus is that dates for births and deaths are to not be linked. Tony: Maarten Schmidt clearly gained his fame as a result of his work after emigrating to America so, though I am loath to use American dates (as an American, I use Euro-style dates on my own user page), Mr. Schmidt’s close association with American institutions like Caltech and Mt Palomar far outweigh the fame he achieved by being born in Denmark. Ergo, loose the links (a must), and keep the American-style dates. Greg L (talk) 06:58, 23 December 2008 (UTC)

Symbols for units of measure are never italicized

Several years after the first attempts to fix it here were adamantly refused and reverted, this page still improperly italicizes the symbols for units of measures, contrary to longstanding rules here and elsewhere in the Wikipedia guidelines.

It is time to start following the standard rules—and our own house rules. They are reasonably italicized, of course, in the examples of what not to do in explaining that rule. But nowhere else in this style manual. In that example, the what to do version has already been changed to upright type, but we have many other examples not following the rule and improperly italicizing the symbols for units. Gene Nygaard (talk) 11:33, 26 December 2008 (UTC)

template:convert defaulting to non-US spelling of "metre"

I'm moving this here because the original discussion has rapidly devolved into the kind of unproductive bickering and oneupmanship which is more appropriate for an MoS discussion, and it's largely not a technical matter at this point. The basic issue: the {{convert}} template defaults to the "metre" spelling for metric units. Some parties have argued that it should not. Which of the two spellings is a more appropriate default, bearing in mind that up until now there has been no option to use US spelling and thus all existing instances of this template use "metre"? Chris Cunningham (not at work) - talk 20:05, 16 December 2008 (UTC)

Chris, at the top of this page, I see "This talk page is for discussion of the page WP:Manual of Style (dates and numbers)." Are you suggesting that Wikipedia pages in American English be forced to use a spelling that is incorrect for American English (kilometre, metre, etc.)? If not, why did you move the discussion here? This isn't a question of style. No one but an extreme anti-American would suggest that American spellings be expurgated from Wikipedia. Right? The original question was a technical one: how do we make a template work in such a way that it encourages compliance with existing WP guidelines. Let's return the focus to making the template better. Samuel Webster (talk) 20:39, 16 December 2008 (UTC)
Since it's a unit used by most of the rest of the world and mainly ignored by the US, I think that "metre" is probably a better default spelling. Presumably the US spelling can be used if necessary? SHEFFIELDSTEELTALK 20:10, 16 December 2008 (UTC)
Note: use in the U.S. has been increasing. But that's irrelevant, since the question is how often the units are used in articles written in American English, and they are used very often (fortunately!). Note: Chris posed the wrong question. It's not which spelling should be the default. The suggestion was that no default be used (or that the default be the abbreviation). This way Wikipedia doesn't favor one dialect over another. Samuel Webster (talk) 21:01, 16 December 2008 (UTC)
Wikipedia:Manual_of_Style_(spelling) speaks to the subject. As well, consider that while meter is ambiguous, metre is not (except in the poet's sense of the word). This should probably join a list of recurring suggestions.LeadSongDog (talk) 20:18, 16 December 2008 (UTC)

A few corrections. First, the question posed by Chris Cunningham isn't quite correct. The question isn't which of the two spellings should be the default. The question is why the template has a default at all, given that Wikipedia should not promote one version of English over another. Next point: "metre" is not the spelling used by most people. Finally, "metre" is not unambigous in American English, it is, rather, incorrect. Please see the discussion at Template_talk:Convert for details. Thanks Samuel Webster (talk) 20:35, 16 December 2008 (UTC)

Metre may be relatively uncommon in the United States, but there is this assertion from an apparently reliable source that both the -er and the -re spellings are acceptable in the United States. I'm investigating, and if that does turn out to be the (appropriately supportable) case, then the outstanding questions in this matter will shrink in number and substance. —Scheinwerfermann T·C20:40, 16 December 2008 (UTC)
Metre is not an acceptable spelling in the U.S. You would never see it in any American publication. Note, the source you refer to is not "reliable." In it, is the claim: "Although Noah Webster was an active promoter of the 'er' spellings for some reason he made an exception for some words, such as 'acre'." Anyone who writes "for some reason" about Webster's reasons for preferring -re after "C" doesn't know what he's talking about. (I'm a linguist.) Samuel Webster (talk) 21:03, 16 December 2008 (UTC)
Claims of personal expertise don't usually lead to sources being viewed as unreliable. SHEFFIELDSTEELTALK 21:21, 16 December 2008 (UTC)
Steel: I was going to say something similar, but I think that you've phrased it particularly neatly! —Sladen (talk) 22:19, 16 December 2008 (UTC)

Indeed! But that wasn't the relevant claim. The relevant claim was my pointing to the astonishing ignorance manifest in the "for some reason" claim at the Web site. Best wishes, Samuel Webster (talk) 23:01, 16 December 2008 (UTC)

Although "meter" can be ambiguous, it isn't ambiguous in a convert template, becaue in the end it will be displayed alongside another unit of length, such as "18 meters (59 ft)".--Gerry Ashton (talk) 21:43, 16 December 2008 (UTC)
Samuel Webster, thanks for your comments. I've known and studied with many linguists, and that experience tells me your being one explains your ardence and strident passion on this issue. It does not, however, invalidate the potential reliability or veracity of the linked source. It may rankle your prescriptivist leanings, but the -re spellings are in non-marginal use in the United States to some degree. One example that springs readily to mind is a badge on the tail panel of every one of many, many Jeep vehicle manufactured between 1987 and 2006 with a particular engine. The badge reads 4.0 Litre. These are U.S.-designed, -engineered, and -built vehicles, sold primarily in the U.S., and marketed with advertising themes often designed to appeal to U.S. patriotism. There was no incentive for the Jeep people to try to dress themselves up as European (or anything but American), and there was every incentive for this badge to read 4.0 Liter, but it didn't and doesn't. In researching this assertion I've just made, I found unassailably reliable sources not only supporting it, but expanding it; U.S. companies American Motors and then Chrysler Corporation both used the litre spelling in badging and in sales, service, and parts literature in the U.S. at least as far back as 1984. I'm sure there are other examples, but this one at least demonstrates that the re spelling is to some degree accepted in the United States.
Also, please take a moment to review the talk page guidelines. We don't intersperse our comments with existing text, for that spoils the chronological order of the comments and makes the discussion very difficult to follow. I've moved your response into the correct chronological hierarchy (without touching the content, of course). Thanks! —Scheinwerfermann T·C23:17, 16 December 2008 (UTC)
Samuel, "never" is quite a strong word and fairly easy to disprove on my first try: site:time.com+metre. —Sladen (talk) 23:42, 16 December 2008 (UTC)
As I said in the original discussion, the template should default to some type of spelling and not a unit symbol. The template has the ability to switch kilometre, metre, and litre to the U.S. spelling (by adding |sp=us) or the unit symbol form (by adding |abbr=on). The template does not deny us Americans the ability to spell these words our way in articles of American subject matter. Then again how often are American articles going to have something like "General Sherman marched 480 kilometers (300 mi) to the sea"? Since American articles should almost always have a " xx miles (xx km) flow to them, the chances are slim. That being said, as an American, I have no problem with {{convert}} defaulting to the -re spelling. It just seems to make sense to me.
Here's something to think about: {{convert}} was created by a person from Dallas, Texas and defaults to -re spelling and {{km to mi}} was created by a person from Russia and defaults to -er spelling. —MJCdetroit (yak) 00:05, 17 December 2008 (UTC)
Just for starters, why don't you go and actually read WP:MOS#National varieties of English. American spellings are not limited to "American articles", whatever that might be. Gene Nygaard (talk) 06:44, 17 December 2008 (UTC)

What does the residence of the owner have to do with anything? Gene Nygaard (talk) 00:28, 17 December 2008 (UTC)

Nothing. It's just interesting because one would assume that given where they were raised they would have chosen the spelling style that they were taught in school. —MJCdetroit (yak) 00:59, 17 December 2008 (UTC)
I find the fact that some of you are assuming that we actually have such owners more interesting. That, of course, is one of the biggest problems here. This behemoth of a template, with thousands of subpages of subtemplates, is so complex that only one or two people could possibly edit it, even if it weren't protected. So, unless we can convince one of them to make the changes, it doesn't get changed. That's not right. Gene Nygaard (talk) 01:07, 17 December 2008 (UTC)
This forum-shopping nonsense has to stop. It is {{convert}} which is broken. The discussion belongs at Template talk:Convert, which is exactly where it started.
Then, to top it off, Chris mistates the problem, by claiming that one of those spellings must be the default. That is a patently false statement.
The only other reasonable option is at Wikipedia:Templates for deletion.
It certainly does not belong on this talk page. It isn't even a MOSNUM issue; it is a main page Wikipedia:Manual of Style issue: See National varieties of English there. Gene Nygaard (talk) 00:27, 17 December 2008 (UTC)
Note further that the problems with this template are not limited to misspellings of meter when users of the template don't know they need to jump through hoops to get proper spellings. It is also the fact that the template is so broken that there aren't even any hoops to jump through, when we use:
{{convert|22.5|t|lb}} → 22.5 tonnes (50,000 lb)
there is nothing we can do to get the proper U.S. spelling. Gene Nygaard (talk) 00:32, 17 December 2008 (UTC)

Are you referring to {{convert|1|LT|t|3}} and {{convert|1|ST|t|3}}; 1 long ton (1.016 t) and 1 short ton (0.907 t). —Sladen (talk) 00:44, 17 December 2008 (UTC)

No. More like {{convert|1|t|ST|3|sp=us}} which gives us the foreign spelling 1 metric ton (1.102 short tons) even if we try to get it right with the "sp=us" parameter. Gene Nygaard (talk) 00:49, 17 December 2008 (UTC)
Then, on top of it, just when we get used to the template often defaulting to a pretty reasonable precision, we get reminded with nonsense like this one of the need to specify the precision. Gene Nygaard (talk) 00:50, 17 December 2008 (UTC)
In the US, "a ton" is 907 kg. In the UK, "a ton" is 1,016 kg. In everywhere, "a tonne" is 1,000 kg. In everywhere "a metric ton" is 1,000 kg. The difference is fairly important if I believe I just purchased 10,000 metric tons (11,000 short tons) of grain. ({{convert|10000|MT|ST}}) —Sladen (talk) 01:03, 17 December 2008 (UTC)
The word tonne is far, far less common in U.S. usage than the metre and litre spellings are. It is most definitely not in accordance with American English usage. And nobody outside of Montana ever talks about a short ton of wheat; we don't have any ambiguity when American newspapers talk about "selling 10,000 tons of wheat to Algeria", as they often do—but one thing they never talk about is "selling 10,000 tonnes of wheat to Algeria"; sometimes they do say "selling 10,000 metric tons of wheat to Algeria", of course. At least there is not any real ambiguity to anyone familiar with that field of activity: it means the same with or without the modifier in this particular example. Gene Nygaard (talk) 01:12, 17 December 2008 (UTC)
Indeed, tonne vs ton is not a language issue, it's a SI vs imperial issue. Just as we're not about to start spelling metre "yard" any time soon. Orderinchaos 10:50, 17 December 2008 (UTC)
This "imperial" nonsense is a "language issue"; we do not use imperial in the United States.
The tonnes and tons are language issues on many different levels.
No "ton" or "tonne", however you spell it, is part of SI. If it is an SI issue, then let's stick to megagrams, gigagrams, teragrams, and the like.
The metric ton, in the spelling prescribed by the United States national standard agency NIST, is, as a unit of mass only (not as a unit of force or as a unit of energy as it is often used on Wikipedia), acceptable for use with SI, but it is not a part of the SI. Gene Nygaard (talk) 14:46, 17 December 2008 (UTC)
Furthermore, even despite its overwhelming complexity, {{convert}} won't even give us the proper conversion in that case: "selling 10,000 metric tons (370,000 bu) of wheat to Algeria". We still need to put that in by hand. Gene Nygaard (talk) 01:21, 17 December 2008 (UTC)
A bushel is a measure of volume, not mass. —Sladen (talk) 01:57, 17 December 2008 (UTC)

You have another guess coming. Gene Nygaard (talk) 02:09, 17 December 2008 (UTC)

Wikipedia is an encyclopedia read by more than just Americans writing for Americans. It is essential to avoid confusion. In this case write and use "metric ton" is that is the overlap between what is "acceptable" in the United States and what is unlikely to cause confusion to most other readers. —Sladen (talk) 01:57, 17 December 2008 (UTC)
How is that going to cause any confusion? In fact, it is the use of tonne, a word as ambiguous in the French language as "ton" is in English, which is likely to cause confusion. Gene Nygaard (talk) 02:09, 17 December 2008 (UTC)
Actually in the US a ton is 2,000 pounds. Vegaswikian (talk) 02:05, 17 December 2008 (UTC)
Not when someone talks about selling 10,000 tons of wheat to Algeria, it isn't. Gene Nygaard (talk) 02:09, 17 December 2008 (UTC)

It is when someone is claiming that it is 907kg. That's the comment I was responding to. Yes, ton can be ambiguous. But if you ask the average person in the US they will say 2,000 pounds. Vegaswikian (talk) 02:31, 17 December 2008 (UTC)

Both of you have just highlighted why, on Wikipedia, you need to use MT and ST concisely. —Sladen (talk) 02:38, 17 December 2008 (UTC)
<edit conflict> But as long as the template remains broken, I suggest we should also put everyone on notice, on the project page here and at the main MOS page, that the spellings inserted by the convert template should be totally ignored and of no meaning whatsoever in determining the existing variety of English used in an article.
<to Sladen> You can start with all the ship articles. Gene Nygaard (talk) 02:42, 17 December 2008 (UTC)
There's only one thing around here and over at {{convert}} that most of us "totally ignore" and it's not a template. —MJCdetroit (yak) 03:16, 17 December 2008 (UTC)

{{Convert}} is but one of many dozens ... hundreds ... thousands ... who knows ... of templates which default to some spelling or other. If it's inappropriate for this one template, it's inappropriate for all templates. So, this is an issue which goes not only beyond {{convert}} but beyond MOSNUM. JIMp talk·cont 10:30, 18 December 2008 (UTC)

Convert is the one where the problem has been pointed out on its talk page. It is in need of fixing. It doesn't matter if others are in need of fixing too, but if you'd like to point some out, then maybe we can deal with them, too.
It never was a MOSNUM issue; it is a main page MOS issue.
It should be easier anywhere else, where we don't have to deal with ownership issues. Gene Nygaard (talk) 14:24, 18 December 2008 (UTC)

The spelling problem only applies to metric origin units. If the origin units are non-metric it isn't a problem. Statistics would help this discussion if a default is being challenged on the basis of effort. Are metric origin units more common in USeng articles or more common elsewhere? Lightmouse (talk) 14:42, 18 December 2008 (UTC)

Based on my experience in the subject, let me say that:
  • The metric system (System International or SI) is defined in documents at the Bureau International des Poids et Mesures (BIPM) in Paris.
  • The official defining documents of System International are in French.
  • The French spelling of the units relevant to this discussion are mètre, litre, and tonne.
  • There is an official Engish translation of this document.
  • The BIPM translation spells them in English as metre, litre, and tonne
  • The United States doesn't like this spelling, so the U.S. National Institute of Science and Technology (NIST) translates them as meter, liter, and metric ton.
  • The U.S. is alone in this preference - all other English speaking countries use the BIPM translation.
  • For the purposes of international law, the U.S. is forced to recognize the international spelling as well as its own.
  • Other countries are not required to recognize U.S. spelling, but they might, depending on national preference.
The U.S. is the only country still officially using the imperial system, and is also the only one using non-international spellings for metric units. Americans shouldn't really expect everyone else to fall in line with their one-country standards, because nobody else really likes them.
Also, people have claimed here that the word "ton" always means short ton (2000 pounds) in the U.S. and "long ton" in the U.K. In my experience this is far from true:
  • In the U.S., coal is customarily weighed at the mine in long tons, and then sold to customers in short tons.
  • On the Great Lakes, coal and sand are shipped in short tons, while iron ore is shipped in long tons.
  • In the U.S., petroleum is normally shipped in long tons, and then sold in barrels (but not physically in barrels).
  • In measuring the capacity of U.S. ships, a "deadweight ton" is a long ton, but a "registry ton" is 100 cubic feet.
  • U.S. custom houses normally work in metric tons.
Thus, while "ton" usually means "short ton" in the U.S., it does not do so in all industries. Long tons and metric tons are also in common use, but companies don't usually explain that to industry outsiders.RockyMtnGuy (talk) 18:57, 18 December 2008 (UTC)
It isn't a matter of "forced" to do anything. The law doesn't require that; the law interprets what the parties meant. The courts being able to understand and interpret non-U.S. English words, or for that matter non-English words, has nothing whatsoever to do with what American English is.
And there is no international law which requires "metre" and "litre" spellings. In particular, the three international organizations established under the Treaty of the Meter of 1875 have established international symbols to be used to represent various units of measure; they have never prescribed any international spellings in any language.
And furthermore, they have no enforcement powers whatsoever with respect to the symbols, either. Gene Nygaard (talk) 20:37, 18 December 2008 (UTC)
No enforcement powers? US trade authorities are quite concerned because: After January 1, 2010, European Union (EU) members will no longer permit dual indications of measurement. U.S. exporters can no longer label or print inches, pounds, or any other non-metric measurement on shipments. This affects labels, packaging, advertising, catalogs, technical manuals, and instructions. Since the US Fair Packaging and Labeling Act requires the use of inches, pounds and other non-metric measures, this is a matter of some concern because US exporters would have to relabel all their products for export. No other country would have a problem because all other countries use metric units. For more information see the US Government Export Portal at http://www.export.gov/logistics/exp_001320.asp RockyMtnGuy (talk) 01:36, 19 December 2008 (UTC)
The General Conference on Weights and Measures (CGPM) and subsidiary organizations, which define SI, are distinct from the European Union. The latter has enforcement powers, CGPM does not. --Gerry Ashton (talk) 03:07, 19 December 2008 (UTC)

The EU gave up on forced metrication anyway. [2] —MJCdetroit (yak) 03:24, 19 December 2008 (UTC)

really? I heard that British beer-drinkers will soon lose the pint. Ohconfucius (talk) 04:17, 19 December 2008 (UTC)
I might not trust Sky News as a WP:RS either, but The Beeb seems to have said much the same thing 11 September 2007.LeadSongDog (talk) 04:37, 19 December 2008 (UTC)
Those news articles are over a year old. I only heard once again that the pint was under threat a week or so ago on TV5MONDE. Maybe it's those overzealous bureaucrats in the UK... Ohconfucius (talk) 05:36, 19 December 2008 (UTC)
No, it looks like the deal stuck. Too bad for the British brewers, they'll have to run two bottling lines while their competition runs justone.LeadSongDog (talk) 07:04, 19 December 2008 (UTC)
<sigh of relief> Ohconfucius (talk) 09:49, 19 December 2008 (UTC)
(still completely off-topic) Seeing as bottles aren't sold in pint measurements, I don't think that's the case. Bottled lagers have been labelled solely in millilitres for over a decade. Chris Cunningham (not at work) - talk 10:19, 19 December 2008 (UTC)

Beer bottle sizes aren't regulated in the UK and I don't know if they have ever been. Size restrictions only apply to draught beer. British pubs sell metric size bottles such as '330 ml', '500 ml' or whatever size the brewery wants. Incidentally, British laws on *size* are a different (although related) issue to laws on *labels*, as is the case in other countries. Lightmouse (talk) 10:48, 19 December 2008 (UTC)

No more inches, feet and yards in Europe. I guess that is the end of NFL football games in London [3] -- SWTPC6800 (talk) 17:10, 19 December 2008 (UTC)
Finally, a way to saw-off the CFL/NFL differences: Four downs to go ten metres on a hundred metre field, allowing the fourth down as either kick or play. Think it'll work?LeadSongDog (talk) 17:55, 19 December 2008 (UTC)
What do you need a fourth down for? If you cannot make ten metres in three downs, it's time to give up and let someone else play! :-) DoubleBlue (talk) 18:04, 19 December 2008 (UTC)
  • Let’s get something straight on the facts. The French spelling the BIPM uses is mètre. When they, like many Europeans, translate to English they translate to British/International English and it is spelled metre. In the US, it is not only practice to spell it “meter”, it officially is spelled meter. This is not an issue of *the proper SI spelling is metre*—it is strictly an issue of dialect. Arguments that it should be spelled metre are no more valid than suggesting that the *official* spelling is “realise” and “colour”. I’m not going to get my dander up and declare God-damned war over what amounts to yet another dialect war because I know the suggestion will, in the end, fly like a wet noodle. No, we won’t be having arrogant Euro-snots deciding that en.Wikipedia, which began in the US, must be completely taken over and Euro-spellings rammed down every American’s throat to save us from “inches”, hydrogenated oils, dioxin, President Bush, and our various other scourges and cowboy ways of life.

    Want a little dose of more fun? That silly Euro-style word for 1000 kg called “tonne”? According to the BIPM: SI Brochure: Section 4.1, Non-SI units accepted for use with the SI, and units based on fundamental constants: Table 6, in English speaking countries it is usually called “metric ton”. Oh yes… that, from the BIPM themselves. Since “tonne” confuses many Americans because they don’t know what it means and think it might be some sort of 1000 British pounds or something, and since “metric tons”, while not widely used in some dialects, confuses absolutely no English-speaking person, I think Wikipedia should clearly standardize on “metric ton” and deprecate all instances of “tonne.” Yes. Really.

    P.S. Don’t bother trying to hide behind the apron strings of policies like “failing to assume good faith” and other such B.S.; I said what I think, what I think is what I believe to be the truth, and the horseshit proposal speaks for itself without anyone’s protestations as to what they *really* intended (to “save the whales, feed the orphans”, yada yada). Greg L (talk) 17:32, 20 December 2008 (UTC)

  • I honestly don't understand the fuss here. Someone is claiming that a template has a POV? You just add the sp=us parameter to the convert template to make it output US spelling. Someone's proposed solution, if I read it correctly, is to make the template broken without specifying a sp? How is that a helpful improvement? Would they be sedated with flipping the default and adding sp=international? DoubleBlue (talk) 17:23, 20 December 2008 (UTC)
Boy, I'm glad Greg didn't get his dander up. If anything, the default output should be to the symbol. But in any case, that is off-topic here. It belongs at template talk:convert. What does belong here is the discussion of what output belongs in the rendered text the reader sees. LeadSongDog (talk) 19:26, 20 December 2008 (UTC)
You mean whether the default should be metre, meter, or
Error!
? I don't think that discussion belongs here either. DoubleBlue (talk) 21:05, 20 December 2008 (UTC)
I don't think there's any point in all this discussion. The current behavior is fine. There's no point in adding sp=international, sp=uk, sp=canadian, sp=australian, sp=new_zealand, sp=irish, sp=indian, sp=south_african, etc. parameters - all those countries use the same spelling. There are only two choices: the US spelling and everyone else's. If you want it spelled "meter", as is standard in the US, use sp=us, if you want it spelled "metre", as is standard in all the other countries mentioned, leave the parameter off.RockyMtnGuy (talk) 23:49, 20 December 2008 (UTC)
  • Don’t ralph-out that “there’s no point to discussing it” stuff; if you don’t think it is worth discussing, then don’t join in on the discussion. It doesn’t matter what the expressed reasoning is if the effect as a practical matter means that the default behavior of a template amounts to POV pushing on a dialect issue. We can’t have a situation where European and American editors rush to make templates that conveniently default to their dialect. I’ll ignore RockyMtnGuy’s argument (“ sp=international, sp=uk, sp=canadian, sp=australian, sp=new_zealand, sp=irish, sp=indian, sp=south_african”) as the preposterous exaggeration it is. Either that, or I will fault his list for leaving off Esperanto!!! Pure nonsense. We’re talking about a binary issue: US/International.

    Having said all that, I really don’t feel strongly about our keeping *existing* convert templates that POV-push on dialect by defaulting to Euro spelling and which require an extra argument to get US spelling; it’s just not worth starting WWIII over. I do have a problem with editors actually defending this practice. It should be clear that that all new templates should be dialect neutral and should require a dialect argument—no “default” behaviors that give convenience and preference to this or that editor’s personal preference; that is just so wrong.

    Finally, as others have pointed out above, this dispute vanishes if convert templates simply use the unit symbols, which Wikipedia is damned big on anyway (to a fault). Greg L (talk) 02:08, 21 December 2008 (UTC)

If using {{Convert}} causes you an inconvenience, please don't use it. If you would like to use it, you may get the short-form by using abbr=yes. If you start changing articles to be against WP:MOSNUM, editors are likely to get upset. —Sladen (talk) 03:17, 21 December 2008 (UTC)
  • That is a specious argument that draws attention from the crux of the issue. I don’t use the {{Convert}} template. This is about slyly providing poorly constructed, POV-pushing tools so less sophisticated editors can unwittingly spread a dialect. It is a nuisance when this happens in articles that properly use another dialect. That addresses the first part of your post.

    As to the second sentence, where you presume to warn me against editing against MOSNUM, please tell me where you are getting those mushrooms you apparently smoked; or was that too, just a specious argument to deflect attention? I will no longer respond to you Sladen. Greg L (talk) 03:32, 21 December 2008 (UTC)

I really find it hard to call a template that allows you the choice of spelling, even if there's a default, as being POV but if that's the case, how about two templates: convert and convert-us or convERt and convREt or something. It's also valid to say don't use a template that offends you. One can certainly type out the conversions without them. I also find it hard to take seriously as a MOSNUM issue. It's a template-talk issue certainly, a NPOV-board issue unlikely. DoubleBlue (talk) 03:46, 21 December 2008 (UTC)
  • That too is a good suggestion DoubleBlue. As I said above, I don’t really have a jones for revising {{convert}}. Why? Because it has already been made and is already in use. But we really should expect—and demand—that techniques like you suggested, (two versions, a no-default extra argument, etc.) will be implemented in future templates that generate words in a particular dialect when the other dialect is different. I’m sure some editors here wouldn’t be pleased if I made my {{color}} template where you can input a hex RGB color like 3A0000 and it generates a phrase like “a pink color” rather than “a pink colour”. Oh, now you get it. (I thought so). Greg L (talk) 04:40, 21 December 2008 (UTC)

I agree that 10 metres (33 ft) is more likely to be used in articles written in Commonwealth English (articles in US English would probably rather use 33 feet (10 m)). But how 'bout making {{convert|10|metre|ft}} output 10 metres (33 ft), {{convert|10|meter|ft}} output 10 meters (33 ft), and {{convert|10|m|ft}} output 10 m (33 ft)? -- Army1987 – Deeds, not words. 11:17, 22 December 2008 (UTC)

Army1987: Your level of intelligence may exceed what's permitted on Wikipedia, but I'll take your suggestion to the talk page for the template, and see what happens. Samuel Webster (talk) 10:03, 24 December 2008 (UTC)
  • Does it really matter how the word is spelled? Do we really think that our Wikipedia readers don't understand what the unit is just because the "r" and "e" might be reverse from what they are used to seeing? Let's remember that Wikipedia is for our readers ... and they are often smarter (and more flexible) than we give them credit. Truthanado (talk) 06:21, 27 December 2008 (UTC)
  • No, it doesn't really matter which spelling variant you use, metre or meter, since anybody can read either. I think the crux of the issue is that:
  1. The US has adopted variant spellings of metre, litre, and tonne in its official standards; to wit: meter, liter, and metric ton.
  2. No other country has seen fit to adopt the US standards.
  3. Some Americans think that they should get special treatment because the US is, after all, so big.
  4. Nobody else is willing to buy that argument.
So, the Americans are all bent out of shape about it and complaining vociferously. Everybody else just wishes they would keep quiet.RockyMtnGuy (talk) 17:45, 27 December 2008 (UTC)
I happened to stumble across a somewhat worn copy of the New Websterian 1912 Dictionary, which might be considered the definitive dictionary of American English. There, on pages 536–537, in plain view for everyone to see, are "meter" and "metre". So why are we having this discussion? Both spellings are acceptable. Truthanado (talk) 17:57, 27 December 2008 (UTC)
RMG, Don't lump all of us Americans together in your bias-rant against the way things are done in America. There were better ways of stating your opinion without your anti-American bias poisoning the discussion. And for the record, I am an American who is more than OK with convert staying as is (-re default spelling). —MJCdetroit (yak) 18:23, 27 December 2008 (UTC)
Quite right, MJC. RMG should have said "a few editors who seem to be Americans" or something of the sort. I suspect at least one of the "meter" advocates is speaking with his tongue firmly in his cheek. Otherwise, his arguments would imply an embarassingly low opinion of his compatriots intelligence. Of course, he might be an H.L. Mencken fan, but somehow I find that hard to credit. I'd prefer to believe he wishes to minimize the remaining barriers to adoption of SI in the US, even though we are not here to right great wrongs. LeadSongDog (talk) 19:58, 27 December 2008 (UTC)
Last I checked I was am American, and whether it's "metre" or "meter", it's about half my height (6'2" or 188cm). Truthanado (talk) 23:10, 27 December 2008 (UTC)
And may I point out that the United States officially adopted SI units in 1975 (see Metric Conversion Act), of which "metre" is the accepted spelling. So, maybe those Americans who insist on the "er" spellings should get with the rest of the world. Truthanado (talk) 23:19, 27 December 2008 (UTC)
The rest of the world often does not even use English (or French). For example, it's Meter and Liter in German (note that the capitalisation is different from American English). – 3247 (talk) 00:00, 28 December 2008 (UTC)
To Truthanado: First of all, your chronology is way off, and your understanding of both linguistics and the law is dismal. Actually, the United States was an original signer of the Treaty of the Meter of 1875, ratifying it in 1878. It was the international organizations established under this treaty, including of course the representatives on those bodies who were from the United States, who invented the International System of Units and introduced it in 1960. Furthermore, the Metric Conversion Act of 1975, a century later, doesn't define the meter or the liter.
But that treaty does not give any authority to determine spelling in English, nor in any other language. Furthermore, so such authority has even been attempted to be exercised.
The spelling in "official" documents of the CGPM, CIPM, and BIPM, of course, is neither "meter" nor "metre", but rather "mètre"; but that doesn't make it an "official spelling". In addition to 3247's point about German, it is "meter" in Dutch, Norwegian, Danish, etc. The English speakers in the "rest of the world", of course, include many in those countries who use the English spelling identical with their native language's spelling. Gene Nygaard (talk) 15:41, 28 December 2008 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers/Archive_116&oldid=1152168282"