This is an archive of past discussions about Wikipedia:Manual of Style. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Era style issues - I think deleting "reasons specific to the article" is a mistake
What I'm seeing now at Talk:Pontius Pilate#Lede picture is a discussion about the use of era styles in the UK and the US, whether a book was published in the UK or the US, etc. The deletion means we end up with people simply putting forth the same arguments that lesd to the old wording which focussed on what was more appropriate for that particular article. Maybe we need an RfC but I think this is going to continue to create problems in other articles. Doug Wellertalk09:12, 5 August 2019 (UTC)
We already have a clear policy, WP:ERA, which says in essence "do not change the era style first used in the article". The Pilate article began as BCE and should stay as BCE. To do otherwise is giving way to POV-pushing and where does that end. --John Maynard Friedman (talk) 10:46, 5 August 2019 (UTC)
A) It doesn't say that any more, which I presume is what Doug is referring to, and B) it never did say what you say - it was "do not change the era style first used in the article without a talk page consensus". If someone could dig out the changes & any discussion on them, I think I too would prefer to go back to the old version. I never actually saw serious arguments over this - more ips changing BC to BCE because everybody knows that's right or, less often, the other way. I've only ever seen a handful of actual talk page sections running a vote. Johnbod (talk) 13:12, 5 August 2019 (UTC)
Thinking about this a little more since this morning, I came back here to say that, since thus particular Roman Governor is only notable because of the Christian story, it does make a good example that sometimes convincing cases can be made for an exception to the rule. [It is not easy for me to check on mobile but I think the "special circumstances" exception is given at MOS:STYLEVAR ]. --John Maynard Friedman (talk) 13:40, 5 August 2019 (UTC)
I agree with your first comment. That particular pressure group had serious problems with its sources and dating in general! Best to avoid all their dating systems till they have sorted it out.ClemRutter (talk) 17:46, 5 August 2019 (UTC)
I've revised the section heading as I meant the change is specifically a mistake when applied to era styles. Not Pontius Pilate, that's an example of why I think the chnage was a mistake. Doug Wellertalk18:30, 5 August 2019 (UTC)
They discussion is a metadiscussion about era styles in general, while I think it should be about which style is most appropriate for the article. Doug Wellertalk18:12, 8 August 2019 (UTC)
Since this has sort of been revived, I'll just point out that at no point in that discussion does anybody propose actually changing the style of the article concerned. Johnbod (talk) 03:41, 20 August 2019 (UTC)
Era style cautions
I'm reverting this [1] partly because by default I prefer less verbiage in the guidelines (among other things, prescribing a word for the subhead is really overdoing it) but mostly because there's something wrong with it but I can't sort out how to fix it. Izno? EEng12:56, 19 August 2019 (UTC)
Do not change the established era style in an article unless there are reasons specific to its content. Seek consensus on the talk page before making the change. Open the discussion under a subhead that uses the word "era". Briefly state why the style is inappropriate for the article in question. A personal or categorical preference for one era style over the other is not justification for making a change.
OK, but a bullet or two above that there's already Apply Wikipedia:Manual of Style § Retaining existing styles with regard to changes from one era to the other so at the very least those need to be integrated.
I agree this is a special sore point, and more than just the usual pointer to RETAIN (or whatever) is needed. But not that much more. At least it should be its own bullet point, with a bit more to warn editors to tread carefully. EEng14:25, 19 August 2019 (UTC)
@Izno: I couldn't find any discussion about this. Sure, verbiage is to be avoided, but the important thing is to avoid editwarring or arguments that are in the end based on personal preference or more commonly religious orientation. It's not that different from how we handle in practice (at least in my experience) national variaties of English, except that there doesn't really seem to be a guideline on that. In any case I'm unhappy with such a change being made with what seems to have been no discussion other than edit summaries. I do get the ""When either of two styles are [sic] acceptable it is inappropriate for a Wikipedia editor to change from one style to another unless there is some substantial reason for the change." but that, as I've said, leave it too open for people to debate the styles themselves rather than their applicability to the article. Doug Wellertalk13:59, 19 August 2019 (UTC)
Doug Weller reinstated some original text that says (in a nutshell) 'leave the era [CE/AD] as you find it'. A while back, someone tidied this section on the basis that there are multiple cases (citation style, SI/Imperial) like this and the generic 'leave it alone' rule should suffice without needing to repeat it in every case. In a perfect world, that would be true. But experience has shown that there have been too many cases of fundamentalists (both types) changing the era because wp:IDONTLIKEIT. So we really do need to be able to give a quick, clear referral to WP:ERA to give the all relevant policies in one place. --John Maynard Friedman (talk) 14:18, 19 August 2019 (UTC)
I wrote the above without checking for an ongoing discussion, my apologies to all. I have decided to let it stand since the point seems to need restating a different way. --John Maynard Friedman (talk) 14:48, 19 August 2019 (UTC)
I think the section should be restored, as the general caution elsewhere is likely to be missed, but without "unless there are reasons specific to its content" which I think is likely to encourage rather than discourage disputes. There is "state why the style is inappropriate for the article in question" just below, which is enough to make clear discussions should be article-specific. Johnbod (talk) 15:00, 19 August 2019 (UTC)
How about
Wikipedia:Manual of Style § Retaining existing styles applies to era styles: before changing an article's era style seek consensus on the talk page, giving reasons – specific to the article's content, not merely a personal preference – that the current style is inappropriate.
Happy with that - maybe add "general or" before "personal preference" - most arguments in either direction tend to be "but everybody does it this way...". Johnbod (talk) 15:58, 19 August 2019 (UTC)
EEng's proposal sounds good to me. I wouldn't want to extend it per Johnbod's suggestion, not because I disagree but because it is too vague without the longer explanation. Let's just stick to this succinct wording: special circumstances and hard cases can be dealt with in the discussion as it arises. --John Maynard Friedman (talk) 17:11, 19 August 2019 (UTC)
Looking at it again I want to suggest removing not merely a personal preference because that actually lowers the bar -- implies that any argument better than a mere personal preference is an acceptable argument. Just specific to the article's content says exactly what's wanted. Thoughts? EEng17:46, 19 August 2019 (UTC)
Johnbod, was it intentional that your comment is indented so as to ok only my original draft, but not my later suggestion of dropping not merely a personal preference? Much hangs on a colon or two! EEng21:51, 19 August 2019 (UTC) Imagine if the Supreme Court used a wiki. Someone could get the chair because of an indenting error!
That aside, I have an issue with the extra text proposed above. A bad faith editor is going to change the text regardless of what the MOS says, wherever it says it. We deal with such users with WP:AN3 and similar. However, a good faith editor, if he should bother to check the MOS first, will see the link currently pointing to WP:STYLEVAR and will probably think to himself "yup, don't change that without consensus". My "depending on article context" in the sentence currently in WP:ERA immediately prior to "apply STYLEVAR" was trying to get at EEng's latest statement of the !rule we want. Now, I also object to forcing discussion first (per my logic above about good/bad faith users). EEng's formulation then reduces to something that's already quite similar to the text in the section at present. There might be some reasonable rejiggering in there if e.g. the order of the clauses/sentences isn't quite right, but a total rewrite or revert probably is not called for. I see the reminder to use STYLEVAR as nearly entirely sufficient when combined with some sense of what a "substantial reason for change" is in this context (article context/content). --Izno (talk) 02:49, 20 August 2019 (UTC)
Well, I'm pleading ignorance -- didn't realize the earlier thread was there. Personally I was happy with Izno's original change cutting the additional text [2], or that + a tiny bit more to make sure it's not missed; above I was just proposing a compromise to keep the peace. And we could use some peace around here nowadays. EEng03:37, 20 August 2019 (UTC)
It is not credible to refer disruptive editors to the entire MOS. I repeat my earlier statement: we need to be able to tell them the read wp:ERA and there they will find a short succinct statement. EEng's one liner exactly hits the spot. I don't understand why you find that objectionable. --John Maynard Friedman (talk) 16:52, 20 August 2019 (UTC)
This is not referring users to the entire MOS--that is an overexaggeration. This is one section that anyone who is interested in concerns of style should already know and care about, especially those making, or reverting, disruptive edits. As for his one-liner, my "one-liner" also hits all the critical points of interest--and I already said why I find his objectionable. Please engage with that rationale. --Izno (talk) 18:10, 20 August 2019 (UTC)
That's not relevant. You're welcome to point to where you have and then we can all review to see if your suggested reversion is reasonable/appropriate in the context of those discussions. --Izno (talk) 14:55, 20 August 2019 (UTC)
It is entirely relevant. At an early stage in this discussion, I acknowledged that in an ideal world the repetition would not be needed but in the real world it has proven to be needed. It is not a theoretical issue. --John Maynard Friedman (talk)
I am not disputing that the issue may be real. I am disputing that my experience with it is relevant. I distinctly invited specific instances for Doug (or anyone) to identify where the issue has occurred and where there is some reasonable belief that the current text is insufficient for having reverted those issues and/or initiation discussion. --Izno (talk) 18:10, 20 August 2019 (UTC)
at the end of the introductory paragraph of WP:ERA. "My" text above (and I repeat I was just trying to find a compromise -- I'm happy with the current text except that I'd set it off as it's own bullet).
But I just noticed something, Izno. "My" text (distilling more verbose text that was in the guideline for some time) does impose a somewhat higher bar for change than does STYLERET (i.e. Wikipedia:Manual of Style § Retaining existing styles), and that's not an accident, given the history of ERA disputes. Are you sure you don't see that as useful? I say that as the author of WP:NONEEDNORULE. EEng00:16, 21 August 2019 (UTC)
The current text worth quoting is
Either convention may be appropriate for use in Wikipedia articles depending on the article context. Apply Wikipedia:Manual of Style § Retaining existing styles with regard to changes from one era to the other.
which I think is pretty close to your current suggested text,
Wikipedia:Manual of Style § Retaining existing styles applies to era styles: before changing an article's era style seek consensus on the talk page, giving reasons – specific to the article's content – that the current style is inappropriate.,
less
before changing an article's era style seek consensus on the talk page,
which as I said is either useless for bad faith editors (because they're either driveby or can't be convinced by a !rule in the MOS) or unnecessary for good faith editors (because they'll already follow WP:STYLEVAR). I have already ceded that the article content (though I called it context) is an important protection in this context. The rest of the intent duplicates STYLEVAR almost entirely and so I see it as unnecessary. --Izno (talk) 00:30, 21 August 2019 (UTC)
I've juggled STYLERET a bit without, I think changing the meaning, but putting more emphasis on prior discussion [3]. Assuming those changes stick I think there Izno need for more than the current text, though I'd break it out onto its own bullet to add prominence. EEng01:01, 21 August 2019 (UTC)
Not all of it stuck :). The edit I had issue with in the set was this one. I am thinking about how best to look at what STYLEVAR says. Unless we have a reasonable belief that all spontaneous acceptable-style changes are controversial or likely to be controversial (I'm skeptical), then it's just about as bad as "problematic" was in the prior text. Of course, I might be seeing more intent than what is there.... --Izno (talk) 01:16, 21 August 2019 (UTC)
(The edit you didn't like is the one I called out as bold in my e.s., so you see everything was very carefully planned.) Yes, I considered changing the "problematic" part to something like "If you're not certain" or "In uncertain cases" or "Unless [something something] is clear" (not hitting on all cylinders right now, I'm sure I could come up with something better than those) but I didn't think it was OK to weaken what it says in any way. Anyway, the combination of your and my brilliant changes (result here [4]) still has the result that I think STYLEVAR now makes the case strongly enough that we don't need anything special at ERA, other than the separate bullet as already mentioned. I wonder what others think. EEng02:03, 21 August 2019 (UTC)
Like I suspect most people, I can't really keep up with you two nattering away, but we certainly need something very like what is there now. As an example just now, where the reverter has written his own explanation, you need to just be able to link to WP:ERA and know that the first-edit ip will rapidly find something that pretty fully explains the reversion. Johnbod (talk) 02:09, 21 August 2019 (UTC)
Man, you just can't please some people. EEng 03:50, 21 August 2019 (UTC) You know, the thought occurs to me, and it's just a thought, that maybe a short essay addressing the perennial ERA issue would help. You could link to that. It could be called WP:PLEASEGODNOTERASAGAIN. EEng03:50, 21 August 2019 (UTC)
Johnbod, saying you can't be bothered to participate here, while reverting to your preferred version (which no one else here advocates) is not cool. EEng05:51, 21 August 2019 (UTC)
I certainly am participating here, I just can't keep up with your usual endless filibuster (or Izno's). I'm certainly not seeing people here "advocate" any of the many versions you've put up on the page in the last few days, or removal, not that that ever discourages you. My version was improvised, reflecting the discussion(s) above, when you'd just completely removed the garbled version (thus "reverting to your preferred version (which no one else here advocates)". Let's be totally clear - there is support here, probably a consensus (Izno doesn't seem to have told us what he really wants yet), for a clear statement immediately at the end of a WP:ERA link. Johnbod (talk) 12:49, 21 August 2019 (UTC)
In my experience, the majority of era changes only change one or two instances, which are in close proximity, while ignoring other instances in the same article. So if you think such editors are worth communicating with, you have to allow for the fact that their attention span is at most 5 column-centimetres, and whatever you want to communicate with them should fit in that space. Jc3s5h (talk) 13:32, 21 August 2019 (UTC)
While I can't deny that happens, I also see editors changing multiple instances either with multiple edits or just one. I prefer User:Johnbod's version.[5] As I said, that avoids metadiscussion as to what is preferable overall and concentrates on the particular article, which I think is key. Doug Wellertalk13:29, 22 August 2019 (UTC)
Johnbod, were were doing very nicely with
Wikipedia:Manual of Style § Retaining existing styles applies to era styles: before changing an article's era style seek consensus on the talk page, giving reasons – not merely a personal preference – that the current style is inappropriate.
so why are you now advocating what is essentially the old text? Surely telling editors they need to use a special keyword in the thread heading is going overboard. EEng 13:42, 22 August 2019 (UTC)
Earth calling. EEng20:01, 25 August 2019 (UTC)
@EEng: I don't understand what sort of confusion led a new editor to make these changes from BCE to BC in an article that has been BCE since 2012[6] saying "noticed that the usage of calendar eras is highly inconsistent on this page. According to Wikipedia's Manual of Style/Dates and Numbers, an article should retain its guideline-defined style unless there is a good reason not to. The oldest major contributions to this page used the BC notation. Therefore, I have decided to change all other era-styles to this one in order to make the era usage consistent throughout the whole page." Mind you, there is a problem with consistency as there's a template, {{Near East Neolithic}} that is BC, so whenever that template is added to a BCE article people can say it's inconsistent. Doug Wellertalk06:49, 28 August 2019 (UTC)
Mothership to earth: could I poke my schnozola in here, to say that a keyword in the thread heading would be cumbersome. Tony(talk)12:51, 28 August 2019 (UTC)
The original instruction to apply RETAIN is entirely sufficient, since it means the same thing: by default, keep the existing style; don't change it without a good reason backed up by a consensus discussion as needed (and if consensus cannot be reached, default to the style used in the first non-stub version of the article). I cannot support reduplicating this in a blathery form on this sub-page, nor in suggesting that this particular dispute is somehow special. The edit summary "... this is an area that attracts a lot of emotion and is not the same as other style areas" is particularly amusing. Anyone with long MoS experience knows that every style matter is an overly emotionalized festival of WP:DRAMA, the more so the more trivial it is. (Cf. bike-shed effect.) It's one of the reasons MoS shepherds are so resistant to changes to the current guidelines. They work about as well as they can work, are the most hard-fought compromise on WP and in all of the world's style guides; meanwhile, virtually every demand for a change to them is blatantly subjective, frequently ignorant or willfully PoV-pushing, and almost dead-certain to displease others and thus perpetuate a dispute cycle. One of the main purposes of MoS is to curtail "style-warring" at articles, and it cannot do this if it's embroiled in "do it this way, no do it that way, wait I want it done this way" changes all the time. MoS's value is in its comparative simplicity (WP-editing focus) and its long-term stability. I also can't support making an extra-restrictive rule with regard to this particular topic. It's been my decade+ experience (under various usernames) that well-reasoned changes at an article (most often to CE/BCE dating in a topic with no connection to Christianity in particular or to Western to Middle Eastern history more broadly) go unreverted, while "activistic", opinionated ones attract editwarring and other controversy. WP:COMMONSENSE is perhaps our most important meta-policy, yet relied upon too infrequently. So, really this is a WP:CREEP and WP:BUREAUCRACY matter. We don't need another rule to thump here; we need informed and dispassionate application of reason, on a case-by-case basis. — AReaderOutThatawayt/c11:42, 22 October 2019 (UTC)
The current
An article's established era style should not be changed without reasons specific to its content; seek consensus on the talk page first (applying Wikipedia:Manual of Style § Retaining existing styles) by opening a discussion under a heading using the word era, and briefly stating why the style should be changed.
could be tweaked to
An article's established era style should not be changed without both consensus and reasons specific to its content. Apply Wikipedia:Manual of Style § Retaining existing styles by opening a discussion on the talk page under a heading using the word 'era', briefly stating why the style should be changed.
Not sure about that - a very good reason to "change" style is to confirm/clarify what the original style was or is, & it's not clear that would be covered. Johnbod (talk) 12:27, 10 November 2019 (UTC)
Ambiguity in MOS:ERA?
Currently it says "Do not change the established era style in an article unless there are reasons specific to its content. Seek consensus on the talk page first..." An editor is interpreting this as meaning that they can change the style without discussion if there is a reason specific to its content. See Talk:Self-praise of Shulgi (Shulgi D)#Eera. Doug Wellertalk15:36, 9 November 2019 (UTC)
With what I hope will be your kind permission, I have merged your post with an ongoing, if currently dormant, thread. I don't know what part of seek consensus on the talk page first this editor does not understand. EEng15:45, 9 November 2019 (UTC)
Without prejudice to the discussions above (which we really should resolve -- can't have all that effort go to waste) I've juggled the current bulletpoint a bit to make it unmistakable that talk-page consensus is called for before changing the era style. [7]EEng19:01, 9 November 2019 (UTC)
Can somebody point out which part of WP:ERA says BC/AD are only to be used on explicitly Christian articles and that most other articles should use BCE/CE. Thanks. Stepho talk23:49, 9 November 2019 (UTC)
It doesn't; it's quite vague as to what constitutes a reason for preferring one style over the other. Given that, we get precious little dispute over this except where an editor comes in on a RIGHTGREATWRONGS mission, as here. We write articles in language best understood by our readers, and that includes referring to months named for Roman gods and days of the week named for the Norse ones. I'm an atheist and I think Christianity, Islam, Judaism, Buddhism, Hinduism, Wicca, and all the rest are complete nonsense, yet the AD and March and Saturday bother me not one bit. EEng00:59, 10 November 2019 (UTC)
I already explain that my motives were based in neutrality. You are who is tring to enforce the policy cherrypicking the "first" word disregarding everything else stated there. If the "unless" part is redundant in both MOS:ERA and MOS:VAR then should be removed from them. People admited that the policy was ambigious but still they make assumpitions about my motives in a WP:FORUM fashion, that's not WP:GOODFAITH. Since Admins and the present users don't care about upholding WP:NEUTRALITY and using a a part of a policy to shut me down I lost all interest in be part of Wikipedia. Rupert Loup (talk) 16:52, 10 November 2019 (UTC)
Rupert, I'm not quite sure of the rational you are applying to change from BC/AD to BCE/CE. I see nothing in WP:ERA that mentions whether an article has to be explicitly Christian or not - hence I can see no unilateral basis for the change. I didn't see any prior discussion to your initial change (admittedly that point wasn't clear in the policy) but I also didn't see consensus after the discussion started (no clear consensus means return to previous state of the article). While I am not claiming that you are uncivil, I do think that you have misunderstood the policy. Or at least I am asking you to explain your interpretation to the rest of us. Thanks. Stepho talk09:31, 11 November 2019 (UTC)
It really should say that, though. Well, in better wording. Like "Avoid BC/AD dating except in topics primarily pertaining to Judeo-Christianity, including historical Christendom and its interactions with other societies." (E.g., Moses, Jerusalem, Nero, Holy Roman Empire, The Crusades, and Spanish conquest of the Aztec Empire are good articles for BC/AD dating, while Aristotle, Alexander the Great, Mohammed, Qin dynasty, Toltec, and Julius Caesar are not) This is just one of those things .... At this point, hardly anyone hasn't encountered BCE/CE dating by now, and we will (well, should) link to Common era on first occurrence anyway. Meanwhile, it just doesn't matter that lots of American and British publications still like to pepper everything with BC/AD dating. They do not have as broad a target audience as WP does, and simply care less whether they offend non-Christians. We can and should do better than this. — SMcCandlish☏¢ 😼 12:21, 2 January 2020 (UTC)
Or to put it another way, you have a preference and anybody who wants to use a different preference is pushed into a ghetto where you don't have to see them.
Or possibly those in your social circle don't use the term therefore nobody of importance uses the term. I come across plenty of people (of both religious and secular persuasions) who use AD/BC as the normal method of doing things and relatively few people using CE/BCE. Stepho talk06:46, 4 January 2020 (UTC)
Under WP:SEASON, does it make sense to avoid stating "holiday(s) 2020", given that not everyone celebrates that set of holidays at the end of December globally, and that this can be more marketing speak? (In other words should we add explicit mention of "holiday" as a seasonal term to avoid in most cases?) --Masem (t) 06:15, 4 January 2020 (UTC)
"holidays 2020" is an vague term. Which holiday? A religious holiday? A secular holiday? Chinese New Year? Australia Day? Ramadan? As defined by which religion or country? Presumably it's the American term for the Christmas holidays (ie December) but many parts of the world (such as my country of Australia) don't call it that. Stepho talk06:42, 4 January 2020 (UTC)
Anyone have scripts or bots which correctly "enforce" MOS:DATEUNIFY. The one I'm using has an option for body dates, but not specifically for citation |date=, ignoring |archive-date= and |access-date=. — Arthur Rubin(talk)00:10, 18 January 2020 (UTC)
If we want to be "correct", MOS allows for the reference dates to be different to the body dates - as long as the reference dates are consistent among themselves for that article. {{Use dmy dates}} and its brethren run over that principle - just like I predicted when they were proposed. Stepho talk00:52, 18 January 2020 (UTC)
The only reason we can't scriptify this is that it needs context to decide whether a terminating comma should be removed when going from mdy to dmy. All the best: RichFarmbrough (the apparently calm and reasonable) 10:32, 23 January 2020 (UTC).
Very occasionally I get bitten by someone who insists on having ISO dates in the refs, but dmy or mdy in the main text and infobox. More often I find the puzzling phenomenon of dmy in main text and infobox, and mdy in the refs (and vice versa). Why do people do that? I usually harmonise. Tony(talk)00:41, 25 January 2020 (UTC)
Yeah, I'm one of the YMD lovers. The OCD in me hates how 7:30am 20 January 2020 starts with hours, goes down to minutes and then starts rising again for the date. At least DMY is consistent when the time of day is not present. MD hh:mm is nice and consistent all the way. MDY is bad in that it rises and falls almost with phases of the moon and requires baroque rules for the comma - that's a red flag for us OCD types. But even I know that YMD in text is going to be rejected by the readers. We got away with it in references because most people don't care about the references and kind of expect them to have all sorts of weird codes anyway (DOI, Duey decimal, editions, volumes, issues, ISBN, ISSN, etc). Only the anoraks among us actually follow up the references and we don't mind dealing with codes - some even relish the decoding. As for DMY in the article and MDY in the references (or vice-versa), that's just evil for everyone.
Many, probably most readers cannot parse the ISO version—certainly among anglophones who aren't scientists or engineers. There's also a risk that readers (or editors) might mix up the meaning of each field, given that 6/7/12 means 7 June 2012 for some people, and 6 July for others ... or perhaps 7 December 2006. We do try to cater for non-specialist readers. Tony(talk)10:03, 25 January 2020 (UTC)
That's why MOS:BADDATE specifically bans dd/mm/yy, mm/dd/yy, dd/mm/yyyy and mm/dd/yyyy. MOS:DATEFORMAT only permits formats where the month is spelled out (7 June 2012 and June 7, 2012 [watch the comma or you'll be roasted]) and ISO with a four digit year. Martin of Sheffield (talk) 11:43, 25 January 2020 (UTC)
I figured out that it's referring to the links to sections of Year in each of the two preceding bullet points. I couldn't think of a clearer way to refer to them, so I revised the text to just repeat them. Largoplazo (talk) 11:09, 8 February 2020 (UTC)
In a discussion over era style, is it a correct interpretation that those supporting the status quo don't have to give a reason?
Because that's being said at Talk:Isaiah#Undiscussed change from BC to BCE where an editor correctly reverted a change from BC to BCE but then started a discussion about it.If that is the interpretation I don't think that's what we meant the last time it was discussed (above). Surely both sides need to discuss reasons. Doug Wellertalk14:30, 5 January 2020 (UTC)
Stability/precedent seems an adequate reason to me. As you may recall, I think there is a strong general accessibility argument in favour of BC, which is no doubt why the big museums still use it. This is an article with very broad appeal. But we don't want to have this argument every time. Johnbod (talk) 14:47, 5 January 2020 (UTC)
It is my understanding regarding something else, that the Smithsonian (US, sorry) has standards for museum exhibit terminology. They might have this one. Gah4 (talk) 20:20, 10 February 2020 (UTC)
Precedent is only an adequate reason to retain in the absence of a valid reason to change, otherwise it holds no weight. Of course, we should just be deprecating BC/AD in favor of BCE/CE (unless there's really some overriding reason not to use it in a specific case) and be done with it, but if we can't even get people to agree to stop using she for ships in favor of it, what hope is there for this? . –Deacon Vorbis (carbon • videos) 15:32, 5 January 2020 (UTC)
Lol. You make a good point. I don't know how to have a discussion with someone who just says "That's the way it's been, I don't need to give any other explanation." That's wrong is so many ways. @Johnbod: what arguments might be good reasons to change an article from BC to BCE? I'd really like your opinion. Doug Wellertalk15:38, 5 January 2020 (UTC)
Note – factual correction to User: Doug Weller’s post above: I added my comment on the Talk page of Isaiah at 23:58 on 3 January. This was because it looked as if an edit war was going on, and I thought the matter should, instead, be discussed on the Talk page. At 00:14 on 4 January another editor reverted a change back to the established style. I reverted this revert at 00:17 on 4 January (i.e. going back to the established style), with an edit summary referring to the Talk page. Sweet6970 (talk) 15:48, 5 January 2020 (UTC)
Certainly not - I see Deacon Vorbis uses American spelling, and is probably unaware how much BCE is an American thing, which has certainly gained some traction in academic circles globally, but is often just mystifying to a general readership. We shouldn't be ramming the current American PC style down people's throats, with an arrogant assumption that this is obviously the right, indeed the only, way to do things. I personally would usually choose BCE for East Asian articles & those on Jewish, Islamic or Pre-Columbian subjects. I used to prefer it for South Asian subjects until I noticed that most local editors from the region used BC. Next time I see a talk page query asking what CE is, Doug, I will send them your way. Where was that recent discussion where museum usage got analysed? Johnbod (talk) 17:36, 5 January 2020 (UTC)
Yes, that's correct, they don't have to give a reason. In discussions of style, there's no argument where you can point to policy. It's really a matter of aesthetic taste so it really comes down to headcount. If you can get a supermajority on a reasonable quorum (say, I dunno, 6-3 at a minimum) I guess you can make a change. But I mean even that is WP:LOCALCONSENSUS and can be resisted on that basis, so it's not really worth spending energy on. Otherwise, stare decicis and give the person who wrote the article the courtesy of deciding which to use, per WP:BLP.
My suggestion is for editors who want to see BC [or: BCE] used in more articles is, write some articles and use your preferred format in them. Herostratus (talk) 16:25, 5 January 2020 (UTC)
@Deacon Vorbis::Why should? The majority of the general population (at least from my vantage point in Australia) still uses AD/BC. Since both forms are in common use, it is merely a preference (depending on your social circles) for which is used. WP:RETAIN is a good example to follow.
@Doug Weller:, if convincing arguments can be made to go to CE/BCE then the AD/BC adherents need to also give arguments to stay. If neither side can convince the other side then the status quo remains in place. I can't see any arguments that give CE/BCE precedence over AD/BC (or vice versa) because both forms are merely a preference along the same lines as using British or American spelling. Stepho talk22:03, 5 January 2020 (UTC)
First, my comment was already resigned to this being a lost cause, and I don't want a side comment I made to get drawn out into a big thing, but since you asked: referring to a year as one of "our lord", or to Jesus as savior (via the christ suffix) is a gross violation of WP:NPOV. We deprecate usage of all sorts of honorific titles and phrases for similar reasons. There are other good reasons too, but from a WikiPolicy standpoint, this is probably the clincher. –Deacon Vorbis (carbon • videos) 22:20, 5 January 2020 (UTC)
Yeah, and the name Friday honors the goddess Frigg. So what? There's lots of stuff like that. Big deal. You want us to start writing First day, Second day, Third day, like Quakers? Of course, that would honor and favor Quakerism... EEng22:28, 5 January 2020 (UTC)
As EEng said, regardless of the origin, if it's in common use then it is valid and can't be thrown out due to your preferences. Should we also throw out January? - that's named after a god as well. Having 7 days in a week is also derived from Christianity, which picked it up from Judaism. Should we throw that out too? The argument to throw out something that is in common use due to your beliefs is POV itself. Stepho talk22:56, 5 January 2020 (UTC)
I agree. There are none so blind as those who will not see. This is not 'political correctness gone mad', it is simply a different perspective on the world. AD/BC is in common use among Christians, who are the majority among Anglophones. People of other faiths and none tolerate it but dislike it. The current solution to edit wars is to leave things as first written but it has to be possible if the subject matter demands it, for change to be made if a significant majority of subject editors believe it appropriate. This is not the same as Freya's Day and Saturn's day. --John Maynard Friedman (talk) 23:36, 5 January 2020 (UTC)
Yeah, actually, it is. And by the way, I have no faith (no faith in a sky god or other supernatural fairy tails, at any rate) yet I do not, as you say, "dislike" AD/BC. It's just an historical relic like so much else. There are real things in this world to get exercised about, and that isn't one of them. EEng16:23, 13 January 2020 (UTC)
My interpretation is that the default is to the status quo ante. So technically it's correct to say that the side that doesn't want it to change doesn't "have to give a reason", in the sense that, if neither side gives a convincing reason, then the style should remain what it was.
But this is only a default position. If the side that wants to change the style does give a convincing reason, then the other side would need to address it, I think. I'd qualify that by saying that a global preference for one style or another is not a good reason — the reason should be specific to the article topic in some way. I'm not sure what sort of reasons those would be, unless it's agreed that articles specific to Christianity should use BC/AD, which is a possible position to take but one I'd expect to attract some controversy. --Trovatore (talk) 01:22, 6 January 2020 (UTC)
Answering the original question is easy: if someone wants to change existing style, they need to have a very good reason to make the change. Someone wanting to follow WP:RETAIN is under no such obligation, although they would have to respond to claims a change would be helpful. If Wikipedia was a company with editors on the payroll, we would do what we were told after venting at a faux meeting. However, the only reasonable way for volunteers to handle style issues such as BC/BCE or mdy/dmy dates is to strongly favor RETAIN unless a compelling reason to change is available. Otherwise editors would waste undue time and energy arguing about side issues, with the winnings going to the person with the biggest emotional investment who is also prepared to slowly edit war to victory. Johnuniq (talk) 03:02, 6 January 2020 (UTC)
Perhaps we need to make it clear that arguments need to be engaged with. Otherwise it becomes just a vote count and that's something we shouldn't be doing on an issue that involves NPOV, which this does in a way that doesn't so clearly apply to other styles changes. Note that 'first written' isn't the automatic default. It wouldn't make sense to argue that for an article begun with one era style 15 years ago which was changed in the first month.As Johnuniq says, it's the existing style we are talking about, and that's about how long an article has been stable with one era style, and deciding that is a combination of length of time and how frequently the article has been edited. As for names of days and months, I'm sorry but that's a complete red herring at best and could be seen as insulting. I've seen books by believing theologians that use BCE but none that try to make up new names. The same for books in the fields of archaeology and history. I agree with User:Trovatore that global preferences aren't a good reason - sadly them used too often. I revert drive-by changes to BCE just I revert drive-by changes to BC. — Preceding unsigned comment added by Doug Weller (talk • contribs) 08:26, 6 January 2020 (UTC)
In order for arguments to be engaged with, they have first to be made. Saying, for instance, that articles connected to Christianity (whatever that means) should use BC/AD is not making an argument, it is stating a preference. The preference needs to be justified with reasons, before any counter-argument can be made. Sweet6970 (talk) 10:16, 6 January 2020 (UTC)
Combined reply to User:Doug Weller’s posts of 13 January on the Isaiah and MOS pages
(i) On the MOS page, you ask: ‘can you please give us a few examples of arguments you’d find acceptable?’. This sounds as if you are asking me to make your arguments for you. I don’t see that I have any obligation to do this. Also, I am not the only one you have to convince.
(ii) ‘If you think that the era style shouldn’t relate in any way to the religion in an article, could you please give some examples?’
Sorry – I don’t understand the question. Examples of what? My reasons are given at (v) below.
(iii) Re the word ‘substantial’- The guideline on retaining existing styles says: ‘Where either of two styles are acceptable, it is inappropriate for a Wikipedia editor to change from one to another unless there is some substantial reason for the change.’ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#Retaining_existing_styles
(iv) The guideline says that any reason given for change should be specific to the article. This means that any reason should not be a general argument for one era style versus the other. I cannot think of any argument, either way, which would be specific to any article. This has the beneficial result that I do not make proposals for changing the era style of any BCE article to BC, and much time and effort is saved.
(v) I get the impression that you consider that if the subject matter of an article relates to a religion, then that should determine the era style, as if the views of the adherents of that particular religion should determine the era style. I don’t agree. (a) Wikipedia articles should not be tailored to the views of any particular group of people, religious or otherwise. (b) In any event, Wikipedia articles are written for readers. I think that the most likely reader of a Wikipedia article on a religious topic is someone who doesn’t know much about it. So an article on Christianity, for instance, is more likely to be read by a non-Christian than by a Christian. A practising Christian is unlikely to come to Wikipedia for information about their religion. If they want to learn more about Christianity, I imagine they would go to a Christian source. Similarly for other religions. A religious person may come to a Wikipedia article to find out what Wikipedia is saying about their religion, and perhaps to complain about it. Perhaps you think these complainers should be placated. I don’t agree. I think they should be resisted.
Well, I can certainly think of a reason specific to the article: if the article has many quotations that use one or the other style, then it may make sense for the article text to follow suit. EEng20:42, 14 January 2020 (UTC)
To play Devil's advocate - if an article quotes many Japanese sources, should the date use the Japanese calendar with Japanese characters? Stepho talk10:41, 15 January 2020 (UTC)
I agree with the (implied) preference of Stepho-wrs (talk·contribs). The purpose of MOS (including MOSNUM) it to facilitate uniformity across WP and promote accessibility to WP readers, not compatibility with (often conflicting) external sources. Dondervogel 2 (talk) 13:14, 15 January 2020 (UTC)
The Japanese example is a straw man argument that has the beneficial side-effect of destroying its own argument. If we had such an article, yes we would certainly give dates in the Japanese calendar but we would also give their Gregorian equivalent – just as we do with Anno Mundi for articles about Judaism and Anno Hegirae for articles about Islam. The MOS recognises equal validity for both BCE and BC (and BP for that matter), and it is not acceptable to declare that the style you don't like to be haram/not koshher/sinful. --John Maynard Friedman (talk) 18:07, 15 January 2020 (UTC)
The Japanese example is certainly a straw man (by design) but how does it destroy its own argument? Many people say "follow the source". This is a good principle for facts but a lousy principle for style issues where the sources may differ wildly from what is appropriate. Which was all the example was highlighting. Given enough sources, a good researcher could find sources using BC/AD. A good researcher could likewise find sources using CE/BCE. Suitable cherry picking of sources could then "prove" that the sources use one or the other and then the article is locked in to that preference because the sources say so. Stepho talk20:59, 15 January 2020 (UTC)
If the preponderance of sources use a particular style and we can recognise that in a way that is consistent with our own Style Guide, we can and should do so. Thus, for the Japanese example and assuming(!) that the most respected RS were only in Japanese, we would give both the original Japanese regnal dates AND the Gregorian dates as mandated by our MOS. It seems to me that it is equally cherry picking to ignore the most respected sources in favour of an English language text, just because the former happen to be Japanese and the latter English.
The "preponderance of sources" argument is certainly a valid element of a case for change, though may not be enough. But where the existing notation seems to be as it is because some editor in the past preferred that style and thus falls under wp:I just like it and no other, then the defence of the status quo is merely an extension of that view.
No-one wants to see a weekly culture war over the era style in contentious articles, but it seems to me that we need to say something like "the era style in an article should not be changed without substantial consensus, based on strong supporting evidence, that the existing style is inappropriate". The preponderance of RSs is an example of strong supporting evidence. --John Maynard Friedman (talk) 15:25, 16 January 2020 (UTC)
(i) What does ‘substantial consensus’ mean?
(ii) As has been said, if the era style for the article is to be determined by the style of the majority of the sources, then this may result in editors cherry-picking the sources which use their preferred style. This could result in skewing the selection of sources, and could damage the quality of the encyclopaedia. Also, an unspoken dispute over the era style may be transformed into a dispute over sources. Sweet6970 (talk) 23:21, 16 January 2020 (UTC)
Do we have a WP:Wikipedia is not a law-book? This is suggested guidance, not the (unexpected) Spanish Inquisition.
(i) Consensus does not mean unanimity but by 'substantial' I hope to reduce the incidence of holiday-season flip-flopping. (I haven't seen much if any flipflopping but then I keep away from articles like Jerusalem – I don't even dare look at it, I bet it even has arguments about Julian v Gregorian). I am trying to provide a structure where well-meaning editors acting in good faith have a means to move forward. I am beginning to understand the frustration!
(ii) My suggestion is only that the custom and practice in respected sources is a factor that could be taken into account, not that it is decisive let alone a directive. --John Maynard Friedman (talk) 17:58, 17 January 2020 (UTC)
On large subjects (Roman Empire, Alexander the Great, whatever) for Wikipedians to attempt to assess the usage of "The preponderance of RSs" is madness. For more obscure topics, RS will normally use the version dictated by the matrix of date of source, originating country, academic vs general public as intended readership, with the religious history of the region concerned a poor last. Johnbod (talk) 18:25, 17 January 2020 (UTC)
I just want to point out that all I said is if the article has many quotations that use one or the other style, then it may make sense for the article text to follow suit. I didn't say anything about preponderance of RSs. EEng01:32, 18 January 2020 (UTC)
Well for that matter, I wasn't addressing you in particular. For heaven's sake, it's not all about you. You've certainly been dyspeptic lately. EEng03:53, 18 January 2020 (UTC)
If I had seen EEng's if the article has many quotations that use one or the other style, then it may make sense for the article text to follow suit earlier, I'd have said yes, that is exactly what I meant to say, then tip-toed quietly away before chairs start getting thrown at the mirrors behind the bar. But I will do so now: I agree with EEng, thank you and good night. --John Maynard Friedman (talk) 17:10, 18 January 2020 (UTC)
…may be used in any of the following cases: (1) two consecutive years; (2) infoboxes and tables where space is limited (using a single format consistently in any given table column); and (3) in certain topic areas if there is a very good reason, such as matching the established convention of reliable sources.
I would propose explicitly limiting this to iterations of some annually recurring cycle whose boundary happens to be offset from the calendar year, such as school years and sports seasons. This would exclude irregular periods of time which, by whatever good or bad fortune, begin in one year and end in the following year—and which may, in practice, be closer to zero years or two years than to one year (2 ≤ TOTAL_DAYS ≤ 731, in fact). For example, the end years of #3 and #4 below clearly should be spelled out:
dropped out during the 2003–04 school year
coached the Fake News Bears to 56 wins in 2016–17
also had one son, Kenneth (1995–96), who died in infancy
{| class="wikitable" ! Title !! Years active !! No. of episodes |- | Some Stupid Podcast || 2012–13 || 19 |}
My personal preference would be to abolish two-digit years even for "sports seasons, etc." and use unabbreviated years in all non-quoted contexts. But everybody agrees the "sports seasons, etc." usage does have established convention of reliable sources on its side, so I'll aim lower. I think the overall effect of this change would be similar to allowing two-digit end-years if the existing guideline's criteria (1)AND(3) are met, rather than the implied OR. Also, I don't believe criterion (2) is valid at all. If space in your infoboxes and tables is so limited that two more digits cause a problem, fix the underlying design flaw instead. So combining (1) and (3) into a single use case "two consecutive years, in accordance with the established convention of reliable sources, e.g. school years and sports seasons" and deleting (2) "cramped tables/infoboxes" would actually make this guideline simpler than the status quo. ―cobaltcigs11:24, 1 March 2020 (UTC)
Please note that school years in Australia are usually within the same calendar year. Starts in summer, ends in summer, but summer is 6 months different to the what northerners believe in. Probably the same for many other countries in the southern hemisphere. Stepho talk11:44, 1 March 2020 (UTC)
Any change in the direction of encouraging 4-digit years (i.e., discouraging 2-digit years after the year 99 AD) is a bad thing. Tony(talk)02:49, 5 March 2020 (UTC)
I agree #3 would look better written out as 1995–1996; I think #4 is OK. But the guideline merely says two digits "may" be used, so these are up to the editors of each page. I don't see any need to change the guideline. EEng13:49, 8 March 2020 (UTC)
I don't care what a Wikipedia contribution history looks like, and in a table (where horizontal width is precious) I wouldn't mind seeing 1998–02 in a column with many other entries, so that the meaning will be apparent. EEng17:46, 8 March 2020 (UTC)
It's not the contribution history that bothers me, but the inconsistency in the article names. I assumed the purpose of the history was to illustrate that inconsistency. Dondervogel 2 (talk) 17:50, 8 March 2020 (UTC)
While undesirable I don't see it as a big deal. I wonder... do we have some article titles that use AD and some that us CE? If so we've somehow been living with it. EEng17:59, 8 March 2020 (UTC)
Today, I tried to improve the wording of the year range section to spell out explicitly (and not in an easy to overlook footnote only) that 2-year abbreviations are not the preferred form (per RFC) by giving an additional (green) example of a consecutive 4-digit year range (which was missing so far) and explicitly mentioning one common cause for misinterpretation [9], but I was unfortunately reverted by EEng.
EEng is right that the yyyy-mm format is not among the allowed date formats in Wikipedia, but it nevertheless is among the formats used in the real world outside Wikipedia (and even a mandantory or preferred format in locales which have adopted ISO 8601) and thus abbreviated year ranges like yyyy-yy (for yy = 01..12) will be misinterpreted by many people regardless of Wikipedia conventions, and even outside the yy = 01..12 range will cause puzzlement because people are used to interpret this form as yyyy-mm in real life.
Therefore, per our general rule to avoid unnecessary or ambiguous abbreviations in Wikipedia, and per the 2016 RFC, I think the wording should be made clearer by explicitly stating that non-abbreviated years are the preferred form (and why, so that people think twice before using abbreviated years).
I thought I'd seen something in the MOS about formatting numbers in music/record charts (e.g. a Number One/No. 1/#1 hit) but couldn't find it here. After much searching I finally located it under MOS:HASH. Perhaps there should be some sort of cross-reference here to make it easier to find? Muzilon (talk) 07:37, 21 March 2020 (UTC)
What do people think about picking up MOS:NUMBERSIGN and MOS:COMMONMATH bodily and just moving them here? That main MOS is so overburdened and those have relatively limited applicability. If people here like the idea I'll bring it up at Talk:MOS. EEng12:53, 21 March 2020 (UTC)
MOS:NUM lacks a format for dual dates and years. I am referring to O.S - N.S. and Double dating issues. The critical case that should probably need a guideline in MOS:NUM is the format for dates between 1 January and 25 March. Spathaky gives "2nd March 1735/6" as an example. Is that fine or should it be "2 March 1735/36"? Some write the dual year "1735-6", but this should probably be discouraged as it might be misread as a period of time. With thanks Johannes Schade (talk) 09:38, 9 March 2020 (UTC)
Dear Martin of Sheffield. I started this section because User:Llammakey changed "Christopher (died 28 Feb. 1623/4)" to "Christopher (died 28 February 1623/24)" in the list of children of the article Theobald Dillon, 1st Viscount Dillon. We discussed this among us and agreed that we could not find a guideline specifying the correct format in MOS:NUM. I see now that MOS:NUM says "should be assumed to have begun 1st of January". I had been misled into indicating dual years by the last sentence in the section "Use of dated from historical documents ..." of the article Dual Dating, which I understood to encourage the use of dual years in Julian dates from January, February and March (before the 25th) in Wikipedia. I feel that silently assuming a year beginning on 1 January is dangerous and that indicating dual years clarifies the issue. With many thanks, Johannes Schade (talk) 16:53, 9 March 2020 (UTC)
Dual dates were used back in the day (300 years ago) when a reader might be genuinely uncertain as to what start-of-year convention was meant. Nowadays all readers will assume that January 1 is meant by default, so there's no need to bring the issue in (and to do so will confuse many). Obviously there are exceptions, as when there's been historical confusion about a date that's worth explicitly untangling. EEng17:23, 10 March 2020 (UTC)
@Martin of Sheffield:@EEng:. Sorry for the delay, I a was down with a bad flue. I see I went astray by using the dual year notation. MOS:OSNS clearly prescribes us to adjust all Julian dates to a start of year on the 1st of January. I will be a disciplined Wikipedian and correct all my dual dates according to the rule given in the MOS, even if I find that dual years would express the truth more clearly. It will take me a bit of time as there must be more than 100 occurrences to correct. Johannes Schade (talk) 21:08, 14 March 2020 (UTC)
Well we do want the truth expressed as clearly as possible, but I still don't see why the dual dating will do that (assuming you accept that, as I asserted, today's readers will 100% assume a Jan 1 start of the year without being told). EEng22:22, 14 March 2020 (UTC)
Surely not at a 100%; some know that for people living at the time the year started on 25 March. Those who know that will wonder whether "15 March 1610" means "15 March 1609/10" (ajusted for 1 Jan) or "15 March 1610/11" (truly O.S.). I do not think our readers consult MOS:OSNS; but never mind. I feel that the rule in force should be echoed by an example of a dual-years date in the very useful table of "Unacceptable date formats" that appears in the text of the MOS. I will not touch the MOS as they will hit me with "discretionary sanctions authorised". If somebody duly authorised could please effect this addition in the proper ways. With many thanks, humbly yours, Johannes Schade (talk) 09:18, 22 March 2020 (UTC)
Agreed. It's infuriating and illogical, but WP makes decisions based on consensus and the last seventeen debates on this have come down in favour of the BIPM-deprecated "binary-SI" prefixes (see the SI brochure, p143). Resurrecting the debate will only lead to a vast amount of heat and no light. Martin of Sheffield (talk) 10:39, 7 February 2020 (UTC)
Wikipedia has it's own Manual of Style (MoS), which takes precedence over guidance of the BIPM and similar bodies. You are in the right place to discuss the MoS. Please consider opening an account. There's no obligation to do this but in my experience your views are more likely to be taken seriously if you do. Dondervogel 2 (talk) 11:21, 7 February 2020 (UTC)
Many quantities have a natural (or not so natural) uncertainty. It doesn't help anyone to make claims more accurate than the physical )or non-physical) system. In the commercial world, most often one has to supply at least as much as stated on the package, but then you read the fine print. In the case of, for example, flash memory devices, there is some overhead such that even though the chips come in binary powers, the resultant devices hold less data. The usual SSD are rated at 240GB and 480GB, not what you might expect at 256GB and 512GB to allow for this overhead. I believe in the case of flash devices, there are bad blocks that are factory marked and never seen, but the result is uncertainty in the exact size. In many article, the precise difference between MB and MiB isn't needed, even if it is known. Gah4 (talk) 22:26, 7 February 2020 (UTC)
When I bought an 8GiB memory card a while back I would have been seriously annoyed if it arrived as "8GiB - well nearly and there are a few bits that don't work so we'll call it 8GB". Caveat emptor is all well and good, but the whole point of having standard units is avoid uncertainty. BTW, when you say "240GB", exactly what number are you meaning? Martin of Sheffield (talk) 22:37, 7 February 2020 (UTC)
The SSD on this MacbookAir has 233228928 1K blocks, for 238826422272 bytes. That seems to be what they mean by 240GB. Gah4 (talk) 01:05, 8 February 2020 (UTC)
Apple has been using powers of ten to properly show storage in macOS for over 10 years. Storage vendors normally use powers of ten too, so they are using the units correctly too. Linux will normally use binary binary units instead since 2010, as well as other programs. Microsoft is the laggard. 217.162.74.13 (talk) 04:40, 8 February 2020 (UTC)
The IEC invented these binary prefixes with good reasons. And the rest of the world gave a big yawn and ignored them. It is not Wikipedia's job to force the world to use them. Stepho talk23:04, 7 February 2020 (UTC)
The world has not ignored them, as shown above. Wikipedia should comply with international standards or it is a bad source of information. 217.162.74.13 (talk) 04:40, 8 February 2020 (UTC)
The anonymous user is correct. The world has not ignored the IEC prefixes. The question for us is not whether to disambiguate but how. There are way too many ambiguous WP articles. How do we fix them? Dondervogel 2 (talk) 09:00, 8 February 2020 (UTC)
A significant issue is the way that all other units are treated. The SI-enthusiasts insist that only the current SI units are used except for a few isolated cases in "non-scientific" articles. As MOS:UNITS says: "In all other articles, the primary units chosen will be SI units, non-SI units officially accepted for use with the SI, or such other units as are conventional in reliable-source discussions of the article topic". So why is there a special section (4.4.1) which flies in the face of this? WP:RF is not accepted as an excuse for any other units. We need to either accept that WP is wholey illogical about IEC units or prepare for a battle royal I fear. Martin of Sheffield (talk) 10:00, 8 February 2020 (UTC)
I stand corrected - the world has not ignored the IEC prefixes. Only a merely 99.99% of the world has ignored it. By the way, I'm a professional programmer. You'd think our engineer's love of accuracy would push us towards the IEC prefixes but we ignore them too. Hard drives, thumb drives, video file sizes, internet throughput, screen pixels are all routinely expressed in MB, GB, etc and very rarely in MiB, GiB, etc. It isn't necessarily the best way to do things but it is what it is. Stepho talk10:28, 8 February 2020 (UTC)
Not really relevant, but if it matters to you I've been programming computers since 1974 and have recently retired from running a supercomputer centre. Martin of Sheffield (talk) 10:51, 8 February 2020 (UTC)
I'm afraid that is impractical. Some editors will have abused the SI prefixes, some will have converted all or part to decimal and correctly used SI. That's the problem, by allowing this deprecated sloppy use for the last 10 years WP has built up a right old mess that only human inspection will be able to sort out. Martin of Sheffield (talk) 10:51, 8 February 2020 (UTC)
You can still avoid most of the manual work by only automatically correcting the cases when the number is an integer multiple of 2. And not attempt to correct "GB cache" which is likely flash. 217.162.74.13 (talk) 11:00, 8 February 2020 (UTC)
Possibly. Bear in mind that for some devices (floppy disks for example) the sizes are expressed in decimal multiples of a KiB: "1.44 MB" = 1.44 x 1000 x 1024 — yuk! Hence why I think a bot impractical.
But the integer check would take care of that. You would also correct things like "1 MB" in these contexts, but it's probably better to leave the rare other odd integer cases alone. 217.162.74.13 (talk) 11:30, 8 February 2020 (UTC)
Bot or human is not yet relevant. What matters is now is that the present mosnum guideline is untenable. A more practical method of disambiguation is needed. (I just wish I could think of one). Dondervogel 2 (talk) 16:37, 8 February 2020 (UTC)
Just follow the standards: binary for RAM, decimal for storage, communication. This is what the bot would do. It would not touch the latter. 217.162.74.13 (talk) 17:00, 8 February 2020 (UTC)
You are explaining to us how one might implement a change to the guidelines that has not yet been agreed. The guidelines recommend disambiguation (a good thing) and then deprecate the only disambiguation method in widespread use (a bad thing). That is just stoopid and has done lasting damage to thousands of articles. We can't fix the damage until we first agree on a more sensible disambiguation method than is presently required. Dondervogel 2 (talk) 10:45, 9 February 2020 (UTC)
There is no need for the change to happen quickly. It just needs to be in the right direction (for way too long we've been moving in the wrong direction). Dondervogel 2 (talk) 18:55, 9 February 2020 (UTC)
Let's not let this die. The existing mosnum guidelines claim to encourage disambiguation but then go out of their way to discourage this practice by putting unnecessary obstacles in editors' path. It's time we fixed this failure. My proposal is to acknowledge that use of IEC prefixes, though not the preferred form of disambiguation, is better than no disambiguation. Dondervogel 2 (talk) 12:11, 1 March 2020 (UTC)
In order this to be considered it should be absolutely clear how this disambiguation would work. Please give rules and examples of binary and decimal measures including disambiguation. &mninus;Woodstone (talk) 13:45, 1 March 2020 (UTC)
1. Many articles use MB and GB with two different meanings in the same article, often in the same sentence, as in (say) "The laptop had 1 GB of memory and a 500 GB hard drive." My aim is to discourage this practice.
2. This can be "improved" (disambiguated) very simply by writing instead "The laptop had 1 GiB of memory and a 500 GB hard drive."
3. The same sentence can be "improved" further (made more familiar) by writing "The laptop had 1 GB[1] of memory and a 500 GB[2] hard drive."
I put the word "improved" in quotes because the improvement in steps 2 and 3 is subjective, but I hope all will agree that #3 is better than #1, and #2 provides a simple stepping stone to get us there. Dondervogel 2 (talk) 14:42, 1 March 2020 (UTC)
(3) is not an improvement on (2). In example (2) it is clear that GiB and GB are different whereas in (3) you need to follow the note, then decide which definition to select. Would all readers realise that RAM was memory? Martin of Sheffield (talk) 17:00, 1 March 2020 (UTC)
The most important point of my post was to point out that the desired disambiguation is inhibited by the present explicit deprecation of IEC prefixes. Any objection to removing this deprecation? Dondervogel 2 (talk) 07:00, 3 March 2020 (UTC)
I searched the archives for "GiB" and found that the string occurs in archives 133, 135, 140, 143, 146, 148, 153, and 157. My recollection is that these prefixes have been extensively discussed. I therefore feel no change to the guidance should be made without a well-advertised RfC. Discussion under a subheading doesn't cut it. Jc3s5h (talk) 11:59, 3 March 2020 (UTC)
Replacing MB by MiB as "disambiguation" as proposed is likely to generate questions by readers not familiar with the unit MiB. As in the current state MB (etc) are the only mentioned units, it seems better to keep these as they are and follow them by an unambiguous measure, similar to what is done for conversions. When units are used in decimal meaning, it is generally not useful to convert to a binary unit. Therefore the simplicity of factors 1000 can be exploited to make clear what is meant. For example:
Encycolpeadia are meant to provoke questions as well as provide answers, that's why we have blue links. Your memory chip example is false though, 537 MB = 512 MiB and that's exactly the point – using decimal prefixes as if they were binary is incorrect as well as banned by the BIPM. Martin of Sheffield (talk) 09:14, 4 March 2020 (UTC)
That's exactly the point. Currently most of the relevant articles state measures like 512 MB, often without qualification, forced by the current state of the MOS. In WP MiB is banned, and MB as binary unit prescribed. As a cautious step towards improvement this really existing ambiguity could be resolved by adding in brackets an explicit disambiguation (512 MiB). −Woodstone (talk) 16:45, 4 March 2020 (UTC)
The only thing that matters is giving correct information to readers. The correct position: for values taken from sources, use the value that the source gives without alteration. If the source gives "100 MB" using MB as a power-of-two, give that, link "MB" to the power-of-two unit, and maybe specify that it's the binary unit in either a parenthetical note or footnote. Altering something that a source gives, to me, seems to be deception. It's not our place to decide that, when presenting information from another entity, that they did something "wrong" and so we should "correct" it without notice to the reader. In any other context this would be considered a big no-no. If we put a quote in an article like, "I saw a light in a third-floor window", but the speaker is talking about a building with only two floors, we don't silently "correct" the quote to read "second-floor window"; we print the quote and then note in prose that the speaker was presumably mistaken, with sourced information stating the building has two floors. When we offer our own conversions to aid the reader, use the standard units. Following standards is good, but not if it involves deceiving the reader. --47.146.63.87 (talk) 02:45, 5 March 2020 (UTC)
I fear you contradict yourself. The statements "giving correct information to readers" and "use the value that the source gives without alteration" are sometimes mutually incompatible. The problem is that whatever the source says, we are not allowed to use IEC prefixes. We don't adopt this position for measurements, if a source says that a widget is 2" long we express this as 51 millimetres (2 in) or the metric mafia will be after you. If a source says that a laptop has 8GB of memory telling the reader this is misleading because it is wrong. In a case like this we ought to use 8.6 GB or 8 GiB. The only real alternative is 8 GB [sic] which is ugly.
However, this level of detail is appropriate for individual cases, the discussion here is the ban on the use of IEC prefixes and the requirement to use SI prefixes in a way that competent bodies such as the IEC or BIPM deprecate. Martin of Sheffield (talk) 09:12, 5 March 2020 (UTC)
The average person doesn't pay attention to whether "GB" is binary or decimal, and unfortunately the world is not consistent, so the best I feel we can do is explicitly point out how a source is using it. We use customary units as primary in articles where the subject is usually discussed using said units. This is especially notable in historical topics that pre-date widespread SI adoption. There, things can get messy, since units were often not standardized and there can be multiple units with the same "common name", like all the different troy ounces, karats, and inches. We usually have to spell out the exact unit, such as French inch, at least the first time, and provide conversions to modern units. Something like that is probably the most satisfactory solution here as well. Yes, it may be a bit unwieldy, but unfortunately the world isn't neat and simple. --47.146.63.87 (talk) 00:22, 6 March 2020 (UTC)
^In this article, GB means 10243 bytes when referring to RAM.
^In this article, GB means 10003 bytes when referring to hard drives.
Proposed disambiguation method
As a comment above states, it would be preferable to keep the values and units given by the sources. However as a courtesy to the reader an explicit conversion should be added, not just a footnote or link to the unit. The appearance of a disambiguation shows that an editor has mede a conscious decision about the meaning. So these are the cases:
source
meaning
disambiguation
note
512 MB
binary
512 MiB
converting to the same term MB (decimal) would be confusing
500 MB
decimal
0.5 GB
repeating the same would be tautological, conversion to binary not useful
512 MiB
binary
537 MB
no conversion would deter a reader not familiar with MiB
512 MB
decimal
0.512 GB
disambiguation is necessary to avoid the impression that 512 MiB is intended
I've looked at {{convert}} but there is a dismissal of conversion routines at Prefixes for multiples of bits (bit) or bytes (B). Pity, since that would seem to be an obvious way forward. However the problem is not with ways forward, it is the ban in MOS. All the bots and conversion routines in the world will not stop a wikilawyer coming along and trashing any updates. Martin of Sheffield (talk) 12:06, 5 March 2020 (UTC)
The solution is simple, already existent, and embedded in the MOS. If the exact number of bytes is important, then specify the exact number of bytes. Headbomb {t · c · p · b}20:52, 5 March 2020 (UTC)
The solution embedded in the MOS is dysfunctional. It does not lead to the desired disambiguation because it is far from simple, so no one bothers to implement it. Dondervogel 2 (talk) 23:03, 5 March 2020 (UTC)
It is perfectly functional and straightforward. That "no one bothers to implement it" is a reflection that people already know that an 8GB stick of ram is 8×10243 bytes, and those that don't know it don't care because it is utterly unimportant to them. Headbomb {t · c · p · b}02:34, 6 March 2020 (UTC)
In general people don't know, and there are multi-million dollar law suits to prove that. And some people do care (the same law suits prove that too). The purpose of the MOS is to provide clarity. It fails dismally in this regard. Dondervogel 2 (talk) 07:03, 6 March 2020 (UTC)
Find me one lawsuit where someone purchased an 8GB stick of ram and sued someone because they got 8×10243 bytes of it instead of 8×10003 bytes of it. Those don't exist because no one expects this result, and no one cares. These lawsuits exist because some people expected a 1000 GB hard drive to contain 1000×10243 bytes and instead got 1000×10003 ≈ 931×10243 bytes. Headbomb {t · c · p · b}22:21, 6 March 2020 (UTC)
They exist because consumers buy an N-GB drive expecting it to contain N GiB. They are disappointed to receive only N GB and they sue. It doesn’t make any difference whether N is 8, 64, 256 or 1000. The logic is the same. Dondervogel 2 (talk) 23:36, 6 March 2020 (UTC)
So your solution is to report 1TB hard drives as 931 GiB, which no one does, or ram sticks as 8 GiB, which no one does? Nope, won't fly. Headbomb {t · c · p · b}23:38, 6 March 2020 (UTC)
My preference would be to report 256 GB as "256 GB" and 256 GiB as "256 GiB", but the proposal on the table (which is not my proposal, though I support it) is not about my preference. It is about how to succeed where the present guideline has failed so badly. Dondervogel 2 (talk) 00:18, 7 March 2020 (UTC)
It hasn't failed. There simply isn't a need for disambiguation in the vast majority of cases. And when there is one, you can do what the MOS recommends, clarify by writing the exact number of bytes. Headbomb {t · c · p · b}00:20, 7 March 2020 (UTC)
Here's a few lawsuits about advertised vs real drive sizes:
Most seem to have happened circa 2003-2006, and then the world forgot about it and went back to accepting fuzzy numbers as standard industry practice.
This reminds of how in the 1980s some home computers were sometimes advertised as 65kBytes (ie 65535 bytes). Whereas now we always say 64 kBytes (64 x 1024 bytes). Stepho talk00:35, 7 March 2020 (UTC)
No.
* The most such recent court case I am aware of occurred in January 2020. A summary of the court’s findings reads
This is a putative class action concerning the meaning of the term “GB” (or “gigabyte”) as it is used to denote the capacity of electronic storage devices. Defendant SanDisk LLC, a manufacturer of such devices, uses GB on its product packaging to mean one billion bytes. Many computer operating systems, however, use GB to mean 1,073,741,824 bytes. Plaintiffs therefore contend that Defendant’s use of GB is deceptive, causing the average consumer to believe that Defendant’s products contain more storage space than they actually do. The Court previously granted Defendant’s motion to dismiss the original complaint pursuant to Federal Rule of Civil Procedure 12(b)(6) for failure to state a claim, but allowed Plaintiffs to amend their complaint. Plaintiffs subsequently filed an amended complaint, which Defendant again moves to dismiss pursuant to Rule 12(b)(6). The Court held a hearing on the instant motion on December 19, 2019, and it is now ripe for decision. For the reasons discussed below, Defendant’s motion to dismiss is GRANTED WITHOUT LEAVE TO AMEND.
* According to MOSNUM we do not say "64 kBytes" to mean 64 KiB. Instead we say 64 KB (or possibly 65 KB - dunno, it's confusing and that's the whole point), but never 64 KiB.
The court cases prove that disambiguation is important to our readers. (Whether it is important enough to individual editors is irrelevant. Both plaintiff and defendant are potential readers of wikipedia). The present guidelines are discouraging that disambiguation by deprecating the relevant international standards. Dondervogel 2 (talk) 08:03, 7 March 2020 (UTC)
I got no dog in this fight, but the court dismissed the suit. How does that support the notion that the distinction matters so much? EEng10:04, 7 March 2020 (UTC)
The court dismissed the the action because the defendant had used GB to mean GB, whereas the plaintiff has assumed that GB meant GiB. Exactly the sort of confusion we are talking about. Martin of Sheffield (talk) 10:11, 7 March 2020 (UTC)
So a revised guideline might help unclog the federal courts by forestalling meritless thumb-drive suits? EEng10:31, 7 March 2020 (UTC)
A while back it was decided that nautical mile could only be expressed in official thoeretical BIPM terms and that NOAA and the Admiralty were unreliable sources which could not be mentioned because they disagreed with BIPM in the practical implementation. Now we have BIPM and IEC being ignored because some editors don't like the standards. "When I use a word," Humpty Dumpty said in rather a scornful tone, "it means just what I choose it to mean — neither more nor less." (Lewis Carroll: Through the Looking Glass) Martin of Sheffield (talk) 10:23, 7 March 2020 (UTC)
I don't understand the point of rows 3 & 4, but the overarching argument I wholeheartedly agree with: 1 kB means 1,000 B, and 1 KiB means 1,024 B, etc. There are no two ways about this. I don't understand why people here are essentially supporting deception. It's one thing to say, "I agree with you, but the problem is intractable at this point because it's happened for so long and many people don't care. So while I don't want to clean up the mess, I won't stop you from doing it." It's another thing entirely to say "I agree with you, but the problem is intractable at this point because it's happened for so long and many people don't care. So I don't want to clean up the mess, and I won't let you clean it up either." Clearly, there are many editors who want to clean it up (myself included). Currently, MOS prevents them from cleaning it up; this is what should change and is being proposed here. I don't know why anyone would oppose this. Getsnoopy (talk) 01:46, 16 March 2020 (UTC)
None of the above. There's no particular need for the article to point out the time interval. It was better before the addition. If you really need to add something like this, it should probably be "seven and a half ...". Your first option gives a false sense of precision. The second option isn't too bad, but you should use {{frac|7|1|2}} (7+1⁄2) instead. And the third option was missing the "a" in front of half. –Deacon Vorbis (carbon • videos) 15:44, 16 April 2020 (UTC)
I strongly agree that this isn't necessary; "They married on April 23, 1963, and on December 8 of that year their daughter Heather was born." seems sufficient --Izno (talk) 16:21, 16 April 2020 (UTC)
No matter how the interval was expressed, I would have deleted it as redundant, as it pretends to qualify something without actually qualifying it, as in "She was a young 14-year-old girl when ..."—as opposed to an old 14-year-old girl? (In fact, see my hundreds of edits where I removed "the tender age of" where it has appeared in front of somebody's age.)
But, besides that, representing a fraction in a form that implies greater precision than the unit itself does is silly. A month is already an imprecise unit, varying in length as it does. Even if it were days: if I say something like "I'll get there in two days", I'm obviously not giving a precise scientific measurement, and nobody will understand me to mean "I'll get there in 48 hours, 0 minutes, 0 seconds". I might say "in a day and a half", but to write it as "1.5 days" would be ridiculous. For any longer duration, even saying "and a half" is silly: "I'll get the nine and a half days from now"? No, I'd likely say "nine or ten days from now". Well, maybe I'd say "in a week and a half", but then, once again, it would be a casual quantification; I would never write "1.5 weeks". Largoplazo (talk) 17:51, 16 April 2020 (UTC)
Agree with all the foregoing comments plus: you seem to be trying to make a point about premarital conception (or premature birth?), and that's a no-no unless an appropriate source has commented on it, in which case we'd say, "As Bill Biographer noted, Jill's unexpected pregnancy prompted [etc etc]". Lacking such a source we just give the dates and let the reader wonder what he'll wonder. EEng18:17, 16 April 2020 (UTC)
Thanks, I totally agree with you. The edit wasn't mine, though. I just merely wanted to avoid any possible conflict since I couldn't find any guidelines about such formatting. Well, I'll just refer here should there be any objections. ;-) Cheers! Jayaguru-Shishya (talk) 20:02, 16 April 2020 (UTC)
To digress a little, another point to be made here is about writing style. The two events begin and end the sentence, the dates are sandwiched in between and the interval between them sits in the middle. Why not use the same order for both events?
They married on April 23, 1963, and their daughter Heather was born on December 8 of that year.
The example is of course only suitable for American subjects, owing to their idiosyncratic use of mixed-order dates. In international English it would read:
They married on 23 April 1963 and their daughter Heather was born on 8 December that year.
Looks like they were supposed to be there as pseudo headings and unneeded as that coashes with the bullet points. If boldface is still desired for those spots, just use the regular three apostrophe markup. oknazevad (talk) 11:44, 26 March 2020 (UTC)
I didn't look but I hope your revert summary wasn't "This has to stay because EEng wants it that way". There are some places where bolding is used instead of section syntax to reduce TOC clutter, though I don't care whether that's obtained via ; versus the usual bolding syntax versus some fancy-schmancy semantic markup. (I've sometimes wished for some version of the section syntax that allows suppression of entering that section in the TOC.) EEng14:07, 26 March 2020 (UTC)
For the record: TOC limit's a blunt tool. MOS being long and complex, we need to suppress TOC entries at different levels in different parts of it. EEng23:00, 31 March 2020 (UTC)
Are hyphenated parts of a number considered one word or two?
Re: this line in MOS:NUMERAL: "Integers greater than nine expressible in one or two words may be expressed either in numerals or in words":
Is a hyphenated part of a number considered one word or two? E.g., is "fifty-six thousand" two words or three? That bullet treats it as two, but was that ever established by consensus? And either way, should be make that more explicit? —swpbT • go beyond • bad idea17:05, 10 March 2020 (UTC)
Phonologically (in terms of stress), "fìfty-six thoúsand" is one word: a compound of a hyphenated compound (like long-term) and an open compound (like ice cream). The question is what MOS means by "word" in the line cited above. Doremo (talk) 04:05, 16 March 2020 (UTC)
I gave my idea of what the answer should be e.g. sixty-five is two words. But now I'm not so sure. Some years ago the example sixty-fivethousand (implying that sixty-five counts as only one word) was added three years ago [11], not by me but during a series of edits in which I was involved; I don't think I noticed the significance at the time. SMcCandlish, what say your many style books? EEng05:27, 16 March 2020 (UTC)
The Chicago Manual of Style uses the term "round multiples" rather than counting words: "In nontechnical contexts, Chicago advises spelling out whole numbers from zero to one hundred and certain round multiples of those numbers," and it offers the examples ninety-nine year lease, 103 years old, seven hundred spectators, more than two hundred thousand, forty-seven thousand persons, attendance ... was 47,122. Doremo (talk) 05:46, 16 March 2020 (UTC)
Chicago seems downright old-fashioned on this. However, New Hart's leans toward doing likewise (though stops at ninety-nine), which actually surprised me. In the current edition it then just waffles all over the place, though, as it does about nearly everything [I assume you've seen my scathing Amazon review of this and the current Fowler's], observing that others prefer using numerals from 11 onward, and others from 13 onward, and yadda yadda. Journalism style guides tend for the 10-and-under or 9-and-under style (they like to save space and get on with it, a habit I often criticize when it comes at the expense of clarity, but sometimes it does not, which is probably why this "get to the numerals faster" style has gotten more popular over the last couple of generations, even if there are some journalistic holdouts (I recall The New York Times being one, though I did not look up this partiuclar point in their latest edition, which I don't actually have on paper any longer.)
As long as our MoS examples are consistent and illustrative, I'm not sure it will matter. I don't see much evidence that people are regularly confused. I think we all know that "word" can have multiple definitions, yet people seem to get the meaning we intend here. Without digging into a bunch of them again, I know from previous reading that style guides usually instead just give a specific range, e.g. spell it out in words if 10 or under, or 12 or under, or 99 or under, or 100 or under. Sometimes only applicable to whole numbers, but sometimes also done with fractions (though not with decimals). They all make various exceptions for technical, sports, and other contexts. A flaw in these approaches is they treat everything above the "magic number" as the same; I think we used the "one or two words" language specifically to make it clear that it was permissible to write out "a thousand" or "two million" if you really wanted to. And it often does actually read better, though the hybrid style "2 million" is also popular and pretty clear. Maybe this is the sort of consideration Chicago is trying to get at with "and certain round multiples", except they go much further than we would and call for things like "forty-seven thousand persons" which to modern eyes seems rather ponderous and pedantic. I'm reminded of George Lucas's original script and novel-form write-up of Star Wars, where the droid characters were named See-Threepio and Artoo-Deetoo. It made for a really, really annoying read. Then again, if MoS actually does now have an example of what to do that read "fìfty-six thoúsand", then that is not what I remember the intent ever being (which was that "fìfty-six thoúsand" is composed of three words, in this sense of word). I don't treat my MoS watchlist as a daily routine any longer (and haven't since around 2016), and I've also taken long wikibreaks, so I easily could have missed discussions of this stuff. Myself, I would use "56,000", and in most cases "5,600", and "560", and "56". When it came to "500" versus "five hundred", it would be contextual: "500 MB", "five hundred Highlanders". — SMcCandlish☏¢ 😼 06:28, 16 March 2020 (UTC)
Ping to prevent archiving (I'm still reading SM's post -- might be a few more weeks before I get to the end). EEng00:06, 5 April 2020 (UTC)
Whole millions from one to nine
Are "eight million" and "8 million" both okay? The way the guideline's written, it isn't clear which point under Numbers as figures or words should apply. --Paul_012 (talk) 22:35, 13 March 2020 (UTC)
Addressed this a bit above. Part of the reason we wrote that section (and related ones, e.g. on abbreviations) the way we did was to "permit" 8 million, and eight million, and 8,000,000, and 8 mil, without legislating only one option, since styles are apt to vary by context especially when it comes to big round numbers. — SMcCandlish☏¢ 😼 06:32, 16 March 2020 (UTC)
Height and weight for European basketball players in the NBA
My edits on Danilo Gallinari were reverted because "he plays in America" and "all other foreign players playing in the US are listed under imperial units". In my opinion, he's Italian, the fact he currently plays in the US is irrelevant, thus metric units first. What do you think about?--Carnby (talk) 19:06, 16 April 2020 (UTC)
I suggest you'll be better off discussing this at Wikipedia:WikiProject Basketball. IMO this is a question of interpretation that can be argued either way (though should be consistently applied - an Italian playing in the US will use one system, an American playing in Italy will use the other). But the WikiProject is better placed to make the decision than we are. Kahastoktalk19:19, 16 April 2020 (UTC)
In all seriousness, since the context of his notability seems to be entirely American basketball, "American" units seems most appropriate as primary. EEng19:26, 16 April 2020 (UTC)
Yes, maybe in this case. But it's not difficult to imagine other cases - a similar player who had also played in the Olympics or in a major international tournament for Italy, for example - where the call would be closer. And this is likely be a wider problem. I've come across it before in other sports. But it's better off resolved at the WikiProject level. Kahastoktalk19:43, 16 April 2020 (UTC)
You all realize there's one scale in the locker room and everyone on the team is being weighed in the same units, right? So regardless of the nationalities of the players, their weights in those units are the primary data and their weights in the other units are calculation results. Largoplazo (talk) 21:02, 16 April 2020 (UTC)
Partly reiterating the discussion from Template talk:Coord#Spaces between measurements: When formatting the coordinates, there should be (non-breaking) spaces between the measurements, as per the SI and even the website/tool the coordinates link to. For example, {{coord|41|17|20|S|174|46|38|E}} produces 41°17′20″S 174°46′38″E instead of 41° 17′ 20″ S 174° 46′ 38″ E or 41° 17′ 20″ S, 174° 46′ 38″ E. Getsnoopy (talk) 22:57, 31 March 2020 (UTC)
Getsnoopy, I remember this being discussed way way way back in 2007 or something. I believe spaces are not used by the template because then they would occupy significantly more space in Infoboxes and people didn’t like that. But that’s a long time ago. —TheDJ (talk • contribs) 10:45, 12 April 2020 (UTC)
@TheDJ: Thank you for the context. I don't believe that's a convincing argument, however. The latitude/longitude fit in Infoboxes with or without spaces when they have only the degrees and minutes, and they wrap to a newline when the seconds are added, regardless of the spaces. Also, the same could be said about regular units, yet those are not allowed to be unspaced. I think we should change this to be consistent with not only the SI, but also with the rest of our style guide and with the tools the template links to. Getsnoopy (talk) 00:26, 18 April 2020 (UTC)
DATERET and disruptive editing
Hello, the user Blynid Eton recently appeared as a single-purpose account dedicated to changing MDY formats to DMY formats. The user has been warned that the drive-by edits are a violation of WP:DATERET. The user has implied that all topics connected with Europe are European Union topics, and therefore WP:DATERET should be ignored. I'd appreciate comments on the validity of WP:DATERET. Thanks. Doremo (talk) 04:15, 18 April 2020 (UTC)
As well as making sure that the EU project alter their MOS to make it clear that DATERET applies first. It is fine to seek out consensus to get articles with strong EU ties to dmy but we have DATERET for a reason. --Masem (t) 04:52, 18 April 2020 (UTC)
@Masem: With respect, I don't think wikiprojects should be encouraged to make up stylistic rules at their own whim. DATERET was developed so that an American editor who started the article on Hungary with mdy, say (or was the first to insert an mdy date format into the main text) shouldn't be undermined by an editor who wants to switch it (coz I like it). That's a recipe for endless edit-wars and talkpage tension. The rule is different for a select group of countries, which seems to boil down to those with majority anglophone populations: with the exception of Canada, they fall into mdy for the US (or US-related topics), and dmy for the rest. It keeps the peace. So allowing "EU ties" to override DATERET would ruin that system, as well as creating category problems (so Norway keeps DATERET, really? but not Denmark). Tony(talk)05:18, 18 April 2020 (UTC)
I agree, which is why I think the EU wikiproject needs to revamp their page to point to DATERET and remind its users to not go around changing dates like this willy-nilly. The way the language reads, it looks like it overrides DATERET which it should absolutely not. --Masem (t) 05:51, 18 April 2020 (UTC)
under WP:Units and British and early, can we make a note about a ton is a ton and there was never a nod to an American short ton ever ? so many notes and links to short tons and long tons, a ton is 2240lbs, pounds, stone, hundredweight, there is no short. Dave Rave (talk) 05:28, 28 April 2020 (UTC)
What do you mean by "and British and early"?
I knew a ton to be 2,000 pounds for years before I knew there were other weights called "ton"/"tonne", and now you're telling me there's no such thing? That is what we generally mean by "ton" in the U.S. and, by the way, I'm betting most people in the U.S. have no idea what a stone or a hundredweight is. Largoplazo (talk) 05:52, 28 April 2020 (UTC)
In the UK, an unqualified "ton" means 2,240 lb (1,016 kg)
In the US, an unqualified "ton" means 2,000 lb (907 kg)
How would a British person describe what US tons are? How would an American describe what British tons are?
At the risk of contributing to unnecessary MOSBLOAT, does it make sense to say something to the effect that unit-based names for measured quantities (that is really verbose but I don't know what else to call them) should not be used? I mean the likes of "acreage", "square footage", etc. since in these cases more prosaic terms like "area" would be more apt – they do not have ties to a specific set of units, and they do not presume familiarity with imperial/US units (since in practice, nobody talks about "kilometrage", "kilomometers", or "hectarage"). I can't readily think of a case when these words are the appropriate choice for communicating information. Archon 2488 (talk) 15:53, 21 May 2020 (UTC)
Acreage is a relatively normal English word and hectarage is not.[12] The word acreage is also often a synonym for cultivated land, and replacing it with area would often be awkward: "increased prices for corn led farmers to devote more acreage to corn"; "He obtained acreage on the mountain by paying for it in barrels of flour and meat"; "Irrigated acreage in the area is likely to increase." Doremo (talk) 16:18, 21 May 2020 (UTC)
I suppose my initial wording was too bold. But still, something like "the planted acreage increased from 100 to 200 hectares (250 to 490 acres)" strikes me as clunky at best. Archon 2488 (talk) 16:39, 21 May 2020 (UTC)
Strong oppose. The proposal appears to be to ban perfectly cromulent English words because they tend to be etymologically derived from non-SI units. Even metrication advocacy organisations tend not to go that far.
There's no evidence that these words actually cause any problems. OTOH, banning them would cause significant problems (clunky sentences, awkward circumlocutions), particularly in fields where such terms are standard. For example, at least one article would have to be moved from its WP:COMMONNAME as a result. Kahastoktalk17:09, 21 May 2020 (UTC)
Partial support While not disagreeing with Doremo I find it unencyclopaedic to say "an acreage of 5 acres". Conversions aside, it should always be "an area of 5 acres". Dondervogel 2 (talk) 22:53, 21 May 2020 (UTC)
This is a style manual, not a writing course. There's no limit to the ways people can write clunky prose. That's not a good reason to "ban" these words. --Trovatore (talk) 23:27, 21 May 2020 (UTC)
The problem is clunky prose of the sort that Dondervogel and I illustrate above. I do not, personally, think "an electric potential of ten volts" is an awkward circumlocution of "a voltage of ten volts"; the latter, at least, sounds more awkward to my ear. FWIW, since you mention it, I would also tend to describe "wattage" and "amperage" as bad style, where they are used in lieu of the perfectly usable (and to my mind more common) English words "power" and "current". And in this case, they do derive from SI units.
The point is that generalising from a unit name to the name of the dimension is bad practice and conceptually confused; units quantify a dimension, whereas the dimension is not constrained or defined in any sense by an arbitrary choice of measurement scale. Who the phoque knows what "chainage" is, who hasn't worked in surveying or for a railway? Who doesn't know what "distance" is? The overuse of these "-age" words (what are they called?) is jargon. "Area" is a plain English word that nobody can reasonably be expected to misunderstand. Archon 2488 (talk) 20:19, 22 May 2020 (UTC)
The article Electrical substation uses the word "voltage" 46 times. Most of those instances are nowhere near a measurement in volts. Replacing them all with "electrical potential difference" or "potential difference" is not going to make the article read better. Nor will it make the article more understandable or less jargon-filled.
And as others have noted, "acreage" has significant connotations beyond "area" that we may want to use. The distance between two stations may be very different from the chainage, and on appropriate articles we should make the distinction. We are writing in English and we can reasonably expect our readers to understand English words.
The way to deal with clunky sentences is to fix the clunky sentence in question. The way to resolve jargon on general-interest articles is to fix the jargon-filled sentence in question. Neither is served by arbitrarily getting rid of a class of words that you don't happen to like. Kahastoktalk20:47, 22 May 2020 (UTC)
But are those objectives served by getting rid of a class of words that mostly function as opaque, imperial-biased measurement jargon, and replacing them with something unambiguous? If you mean "cultivated area", say that. IMO, an encyclopedia should not rely on vague connotations; it should say what it means. Archon 2488 (talk) 22:00, 22 May 2020 (UTC)
No, the objective of avoiding clunky sentences and jargon is best served by avoiding clunky sentences and jargon. The words you seek to ban are no more ambiguous or vague than the words you seek to replace them with.
You want "something unambiguous"? At this level, unless you're planning on requiring that Wikipedia be rewritten in Ithkuil, you're not going to manage that. All human language has nuance and implication and ambiguity baked in. And that's a feature not a bug.
But the point comes out again - you object to these words as "imperial-biased". Even the metrication advocacy organisations don't go as far as you are going here. Kahastoktalk22:43, 22 May 2020 (UTC)
> The words you seek to ban are no more ambiguous or vague than the words you seek to replace them with.
I'm going to call you on this. How many people could tell you what "acreage" is, versus "square footage", versus "area"? What if you consulted people who are not native English speakers, or who live in countries (most of them) where acres and square feet are not normal units of measurement? I assert that the former are jargon and the latter is the common, plain-language name for the concept. And yes, these terms are biased against people who do not have a good understanding of the cultural contexts in which imperial units are used. You get brownie points for knowing about John Quijada, but I do not accept your analogy as being "cromulent". If an unambiguous term exists it makes sense to use it. Claiming that language is inherently ambiguous is frankly a crap excuse for not writing clearly. Sort of like Fred West getting caught with bodies under his patio and claiming that humans are inherently a bit shit. Yes, but that is not the point. Archon 2488 (talk) 23:18, 22 May 2020 (UT
It's deeply depressing I have to say anything like this, but for the avoidance of doubt I was not comparing you to Fred West. The meaning of the analogy (and I note with interest you neglect to reply to the substance of my comment) was that "language is inherently ambiguous" is very readily deployed (not, again lest you think the reason I edit WP is to assassinate your character, by you in particular, or as far as I am aware, at all) as a bad-faith excuse for poor and ambiguous prose, or overly jargon-laden prose.
FWIW, the comparison to a serial killer was quite obviously meant to be a humorously absurd escalation of how people can use logic like this to excuse problematic behaviour (it is sort of ironic that this happened in the context of a discussion about how language can have many possible shades of meaning and should not be taken literally, and I take it as read that the rules of the "this is a joke" language-game are not the same as those of the "this is a statement of literal fact" language-game, for reasons I hope are obvious). I regret that this was not apparent in the phrasing above.
My personal feeling – and I now appreciate that it is not shared, so I will not continue to advocate for it – was that terms such as I have described are often unnecessary and culturally biased jargon used in lieu of simpler and more neutral terms, which per guidance it makes sense to prefer. I do not, in good faith, think more people understand "chainage" than, say, "distance measured along the track". The fact that it references an obscure and obsolete unit unknown to, I would guess, well over 90% of our readers (in the context of UK units, WP bans kilometres with vastly less reason!) is another reason to proscribe its usage. Archon 2488 (talk) 11:59, 23 May 2020 (UTC)
I guess the slipshod editors of IEEE Transactions on Electrical Insulation slipped up in letting through such abominations as "A new concept for medium-voltage cables: improved voltage life of belt-type cables", "Determination of space charge distributions in polyethylene samples submitted to 120 kV DC voltage", "Prebreakdown currents of vacuum tubes with increased pressure stressed with AC voltage", "Improving the high-voltage quality of alumina insulators", "Prediction of Breakdown Voltages of Binary Gas Mixtures" and so on [13]. EEng20:56, 22 May 2020 (UTC) P.S. Fascinating followup from v24n2 (1989), W.F. Schmidt: "High voltages for particle acceleration from thunderstorms: A. Brasch and F. Lange": "An early experiment of two German physicists, A. Brasch and F. Lange (1930), who conceived the idea of harnessing the huge potential differences between charged clouds of thunderstorms and the earth, is briefly described ... The project was discontinued when a fatal accident claimed the life of a coworker of Brasch and Lange." Ouch!
The journal you refer to, I am assuming, prefers SI as policy (because IEEE does), which does not apply here. The point being that WP does not follow the usage of journals, and what's sauce for the goose is sauce for the gander. Archon 2488 (talk) 22:00, 22 May 2020 (UTC)
So that would be sauce-age. Actually, I have no idea what the point is of what you just said. EEng23:04, 22 May 2020 (UTC)
So by that logic, the fact that the journal is written in English presumably therefore means that Wikipedia is not allowed to be written in English? Kahastoktalk22:30, 22 May 2020 (UTC)
Strong oppose. As this is unrelated to the way we present dates and numbers in articles, I don't think this is an appropriate talkpage to discuss the banning of standard English words from Wiki's vocabulary. Doesn't MOS have a section on banned words that you could take this to? -- DeFacto (talk). 10:08, 22 May 2020 (UTC)
"present dates and numbers" – read sensu stricto, this does not define the entire scope of MOSNUM, as I understand it. Not least because it was about measured physical quantities and the appropriate terminology to use when describing them. I take it as read that my choice of "ban" was tongue-in-cheek. Archon 2488 (talk) 20:30, 22 May 2020 (UTC)
@Archon 2488: nevertheless, it comes across as wanting to discriminate against the use of certain standard English words (words that are in common enough usage to appear in the OED[14]), not in terms of how they are used in English today, but because there is an association with a non-metric unit of measure in their etymology. -- DeFacto (talk). 12:03, 23 May 2020 (UTC)
I did clarify above that my argument also applied to "wattage" over "power" for example, so this isn't fair. "A wattage of ten watts/horsepower" sounds frankly ridiculous, to my ear, whatever units of power you choose. Actually, the fact that "a wattage of ten horsepower" sounds so ridiculous is a great illustration of the problem with these words: they are insufficiently abstract, and they are based on naive generalisations about physical quantities that do not reflect a real understanding of them. Thus "mechanical power" and "electrical power" are implicitly treated as separate concepts: "wattage" can refer to the latter, but not as commonly to the former, whereas "horsepower", when used as a synecdoche – maybe that is the word I want – for "power", refers only to the former. This is just an unphysical confusion of concepts; a power is a power regardless of how it is generated or what is done with it. Anyhoo, my argument went down like a bucket of fetid camel diarrhoea, so I have abandoned it.
And "appears in OED" is meaningless as a criterion of common use, because the OED lists every word equally, however obscure or archaic it might be. Floccinaucinihilipilification appears in the OED; how widely is it used, except as a parody of long latinate words? Similarly for vulgar 90s slang. Its objective is to document every word in English usage, not to make any sort of prescriptive statement about what is common usage and therefore likely to be understood. Archon 2488 (talk) 12:23, 23 May 2020 (UTC)
Oppose Acreage is a perfectly useful and acceptable word. Guide for the Perplexed: EEng is joking, and Martinevans123 is trying to keep the jokeage going. Cullen328Let's discuss it07:22, 23 May 2020 (UTC)
Oppose Can we please just stop with all this? Does anyone really believe that anything useful is being accomplished here? Paul August☎15:41, 23 May 2020 (UTC)
(ec) @Paul August: Why should we stop? Archon 2488 made a serious and sensible proposal, which I would paraphrase as "write so you cannot be misunderstood". More specifically he suggests we should prefer "power" to "wattage" and "distance" to "footage". I agree with him. Dondervogel 2 (talk) 05:58, 24 May 2020 (UTC) [He might at one point have mentioned "acreage" too. It's too long ago to remember and irrelevant to the message.] Dondervogel 2 (talk) 06:02, 24 May 2020 (UTC)
@Dondervogel 2: First of all, I think you and Archon 2488 both misunderstand these words. Acreage is not a number of acres, at least not normally; it's an expanse of land. Footage is a sequence of film. These words do not ordinarily refer to measurements; they refer to the objects thus measured.
I agree that it's usually poor writing to use these words together with a number, but it's not within the remit of the MoS to identify everything that's usually poor writing. --Trovatore (talk) 16:43, 24 May 2020 (UTC)
To clarify, I was talking about "square footage" when it is (mis)used to mean "building floor area". The fact that nobody talks about "square meterage" is revealing. When "footage" is used to mean "recorded video", it is so divorced from its etymology that I think a lot of people would not recognise it as originally referring to reels of film measured in feet. Indeed, you might well read about "gigabytes of footage" these days, for exactly that reason. Archon 2488 (talk) 18:47, 24 May 2020 (UTC)
Semi-oppose. While I get where you're coming from and agree with a lot of your positions, this is not one of them. I don't think you're going to convince many people that acreage is not proper English in the sense that it's a word (just like percentage, footage, etc.). However, I think your argument would have much more mileage (no pun intended) if you said that these words (except for maybe percentage) are considered informal, and therefore should be avoided. But I don't think we need a policy outlining that, as we probably already have some sort of policy that says to use formal English rather than colloquial English (MOS:TIES comes to mind). Nevertheless, these kind of things are probably best resolved on a case-by-case basis. Getsnoopy (talk) 05:54, 24 May 2020 (UTC)
Actually, in many cases the words that would be banned here are more formal and less ambiguous than the alternatives offered. If there's a problem, it's with topic-specific jargon rather than informality.
We do tell people to make technical articles understandable and to avoid using too much technical language. But avoiding all jargon is neither possible nor desirable.[1] And if you want to reduce unnecessary jargon, the way to do it is to deal with specific instances of unnecessary jargon when they arise, not to ban whole classes of word based on their etymology. Kahastoktalk12:38, 24 May 2020 (UTC)
I was not talking about jargon. It's about vague (wattage) vs well defined (power). There's nothing vague about "proton" or "electron". Dondervogel 2 (talk) 13:31, 24 May 2020 (UTC)
This is not a proposed ban only of the word wattage. It is a proposed ban of all words of the type [unit name]+age. Therefore it applies equally to tonnage, voltage, chainage and other similar technical terms. It is not clear whether percentage is included as well.
That said, the word wattage is actually rather less vague than power. Power is any rate of transfer of energy. In most circumstances, wattage specificially refers to electrical power. Kahastoktalk17:34, 24 May 2020 (UTC)
That's a good point. It's also the first sensible argument I have seen against the proposal in this entire discussion. Dondervogel 2 (talk) 18:14, 24 May 2020 (UTC)
And "voltage" with "electrical potential difference", and "chainage" with "distance along a railway line", and "tonnage" with "cargo volume of a ship", and "footage" with "recorded material"? This is not a discussion about "wattage" alone. All words derived from [unit]+age would be affected. And on some articles we would move from aiming to inform the reader to an exercise in constrained writing.
We can reasonably expect readers of the English Wikipedia to understand ordinary English words in their ordinary English meaning. There is no reason to assume that words such as "wattage", "voltage", "footage" and "mileage" are somehow uniquely difficult to understand in a way that applies to literally no other word in the entire English language. To the point that our guideline on words to watch begins, "[t]here are no forbidden words or expressions on Wikipedia", a situation that this proposal seeks to change.
And don't forget that if a reader genuinely has difficulty with these ordinary English words given their ordinary English meaning, we do have simple.wiki available. Kahastoktalk19:47, 24 May 2020 (UTC)
And yet ordinary English words such as "metre" and "kilogram" – at least as common as "acreage", if not vastly more so – somehow apparently are uniquely difficult to understand, if some people here are to be believed. Archon 2488 (talk) 13:01, 25 May 2020 (UTC)
The proposal here was to ban the word "acreage", and similar words from Wikipedia.
On that basis, I assume that you will now cite the policy or guideline that bans the words "kilogram" and "metre" from Wikipedia, or even any proposal made to ban the words "kilogram" and "metre" from Wikipedia.
To avoid any doubt, as per your original proposal here, a "ban" means that there is no "case when these words are the appropriate choice for communicating information", and that therefore that they "should not be used" on Wikipedia, irrespective of context (since your original proposal did not limit the ban on these words based on context). Kahastoktalk13:21, 25 May 2020 (UTC)
MOSNUM, as it stands, de facto selectively bans these words based on hairsplitting distinctions (such as when they are used in the context of expressing the heights [but not girths?] of people of certain nationalities), and this policy is justified by occasional assertions that the words are not understood. Even though we're supposed to believe at the same time that they are understood on something like >95% of articles. Of course the sections I am referring to are not worded in that way, but that is their effect. I've long since learned that this doublethink is mandatory and practiced it appropriately, so no more of that.
I've said a few times here that "ban" was a stupid choice of word on my part. What I was really thinking about, before shelving the idea that the MOS should say anything explicit about this, was a recommendation that these words were, as you quote me, not the appropriate (best) choice for communicating information to readers. In any case, the MOS is not absolute, so a recommendation that they were not stylistically optimal would not preclude their use if there was a desperate need to do so. Nonetheless, I do not feel that words like "acreage", which make ambiguous reference to obsolete units of measurement, are the most appropriate in the vast majority of circumstances, but as you and others have pointed out, there are any number of ways in which editors can fail to make the best choice of words for communicating information, so the MOS cannot exhaustively catalogue them. Archon 2488 (talk) 14:03, 25 May 2020 (UTC)
So, in other words, there is no such ban in the MOS, or in any other policy or guideline, and no such ban has ever been proposed. And your claim to the contrary was entirely false. Kahastoktalk14:55, 25 May 2020 (UTC)
Entirely false? You mean there's not even a context-specific ban on kilograms? So you're happy with me, a UK passport holder, saying that I weigh 82 kilograms on Wikipedia? Wait, what's that? You're actually not? How interesting! Archon 2488 (talk) 15:31, 25 May 2020 (UTC)
You claimed that "metre" and "kilogram" were treated in the way that you sought to treat words like "acreage" and "tonnage". This was false. As you are well aware, all measurements such as you describe are required to be given in both imperial and metric systems.
However, given the vehemence with which you have repeatedly expressed your views on measurement systems, given the numerous personal attacks that you have directed toward me and other editors on this page because of this point and given the discretionary sanctions that you have been warned of, I would suggest that it would not be productive for you to pursue this further at this point. Kahastoktalk16:15, 25 May 2020 (UTC)
It's not going any further, because I've already abandoned the proposal. Because people explained to me why it wasn't a good or workable idea and why the MOS was not the appropriate instrument for giving such stylistic guidance; not because they threatened me. I would suggest that veiled threats of sanctions for making proposals you don't like isn't a good MO. If it's a bad proposal (and I now accept that this one was), then just explain why. Playing the victim when you are the one actively threatening an editor whose crime was to make a proposal you disagree with is a bit hard to accept. Even if it was a stupid proposal. Archon 2488 (talk) 17:23, 25 May 2020 (UTC)
References
^If anyone doubts that, I suggest they write a draft of isotope without using jargon words like "proton", "neutron", "electron", "nucleus" and "atom".
Reqeust I'm going to whip out my Swiss Army knife for these issues, WP:MOSBLOAT. Can we please see actual examples of actual disputes on actual articles that the contemplated guideline would address? So far it's all hypothetical. EEng15:07, 24 May 2020 (UTC)
I suspect that there are times when I have found it strange, but mostly I think we should leave it to editors to use what works best in context. Note that besides giving the quantity, it also suggests the unit desired. If one asks for acreage, the answer should not be in square feet or hectares. I do find amperage instead of current a little strange, but only a little. Voltage sounds much better than electromotive force, though possibly electrical potential difference could also be used. Square footage isn't unusual at all in English. Watt is supposed to be the SI unit for power, independent from electrical usage, but as above it often suggests electrical power. Note, for example, that power plants are often rated in GWe, that is electrical gigawatts, as opposed to the thermal power that is used to generate it, about three times more. On the other hand, wattage is mostly not used for power plants. Gah4 (talk) 19:49, 24 May 2020 (UTC)
It occurs to me that the word mileage is commonly used in the US for automobile fuel usage. That is, miles/gallon. So, the name isn't always the unit followed by ago. As well as I know, in metric countries they use litres/100km, so a reciprocal unit. I don't know what -age word is used there. Also, they might not be used along with a unit, so one might ask about a lamp wattage, or floor square footage. Gah4 (talk) 05:33, 25 May 2020 (UTC)
Not just the US, in the UK people use "mileage" for fuel consumption. As regards electrical terms: if you buy a light bulb or a kettle the current demand is marked in watts – therefore wattage, and fuses are marked in amps – therefore amperage. These terms are straightforward everyday usage that don't need technical knowledge. Let's just stop trying to ban things because WP:IDONTLIKEIT and let the particular instances speak for themselves. Martin of Sheffield (talk) 08:49, 25 May 2020 (UTC)
Comment To try to make a serious point, MOS:COMMONALITY applies to words like "acreage" (meaning area) and "mileage" (meaning fuel consumption). If there are significant differences in the usage of a particular word in different dialects of English, then we should try to avoid that word ("avoid" not "ban") when it can be done without impairing readability. There's an age issue too. As an officially elderly person (based on the UK Government's definition in relation to Covid-19), I'm happy with both "acreage" and "mileage" in the senses I gave above, but younger people outside the US may not be. If that is the case (or when it becomes the case), we should try to avoid such words. "Voltage", "wattage", etc. are totally different cases, since the units are universal, and the argument is about scientific precision, not ordinary language use, and this is not a purely scientific encyclopedia, but a general one. Peter coxhead (talk) 10:05, 25 May 2020 (UTC)
(edit conflict)I agree that "ban" was a stupid choice of word on my part. But I've changed my mind to favour editorial discretion over MOS mandates – as others have pointed out above, there are any number of ways in which editors can write bad prose, and it's not wise to try to anticipate all of them too closely. Not least because, as you say, there is a reasonable amount of contextual nuance here. Archon 2488 (talk) 13:01, 25 May 2020 (UTC)
I have some edits with the edit summary: sounds better. Some of the cases in this discussion I probably think should be changed, and others not. What is the wattage of that light bulb? makes sense even when it is turned off, where What is the power of that light bulb? doesn't seem quite right when it is off. The power is zero, but the wattage (rating) isn't. A circuit breaker has an amperage (rating) even when the current is zero. If I ask about the amperage of a circuit, I don't mean the current current, but how much might be safe, which might include more than the breaker rating. (It depends some on context, which isn't so easy to explain.) Depending on context, trip mileage might mean round trip distance or trip gas mileage. In a farm context acreage of corn might mean how much is currently planted with corn, where area of corn doesn't make sense. It might be that in some cases, it is too informal for an encyclopedia, but I don't believe enough to ban it outright. I had thought that no-one would say mileage per gallon, but a web search does show that some do use it. Gah4 (talk) 12:52, 25 May 2020 (UTC)
In the name of mercy please let us stop this. Someone should, perhaps, write an essay discussing the stylistic issues. And here I'll shamelessly plug my latest essay, WP:LOCATION. (I was going to call it WP:LOCATIONLOCATIONLOCATION but for some reason that's on the title blacklist.) EEng14:13, 25 May 2020 (UTC)
Oppose. I think it would be accurate to say that all of the English speaking countries have historically used US/imperial units and consequently, there is a linguistic legacy that persists to varying degrees in different varieties of English to varying extents. If anything, such usage (and avoidance of such terms) is already covered by WP:ENGVAR (MOS:COMMONALITY). To be more specific (ie particular terms) would be bloat/creep. Regards, Cinderella157 (talk) 01:17, 26 May 2020 (UTC)
Imperial vs Metric Body Measurements (UK)
As a young person in the UK, i find it strange that this guide recommends for imperial units to be used in British contexts. I don't know anyone, barring grandparents and over-60s, who still resort to imperial measurements for height and weight. This is an archaic and backwards viewpoint. I believe we should amend this to recommend metric measurements. — Preceding unsigned comment added by 2A00:23C8:7500:B901:6DAD:76AB:66BB:D4C9 (talk) 10:59, 3 April 2020 (UTC)
I suggest you re-read your comment and consider how you think about your seniors. In particular calling them "archaic and backwards" borders on the offensive. If you are lucky one day you will reach 60, most people these days expect to live into their 80s, so you are dismissing upwards of 20 million people as "backwards". You might care to check your grammar. "I", not "i" and "recommends for imperial units to be used" sounds more American, perhaps "recommends that imperial units be used" would be more natural English"? (Please remember to sign your posts on talk pages by typing four keyboard tildes like this: ~~~~. Or, you can use the [ reply ] button, which automatically signs posts.) Martin of Sheffield (talk) 11:41, 3 April 2020 (UTC)
Ignoring the grammatical lessons and moral viewpoints, I agree that this should change. Everyone I've interacted with has quoted their height and weight in metres and kilograms, respectively. Even British publications seldom use stone/pounds anymore, especially not ones which could be considered reliable. Getsnoopy (talk) 20:51, 4 April 2020 (UTC)
We always give imperial/US Customary and also metric. The only question is which comes first and which follows in parens. It's the most stupid issue to spend time on. Please let's not. EEng21:04, 4 April 2020 (UTC)
Actually we don't. Most personal weights of non-British people are converted between pounds and kilograms, ignoring stones completely. If an American or a metric-user looks at Peyton Manning, they will know how much he weighs. A Brit who uses stones won't have much clue unless they're particularly good at dividing by either 14 or 6.3. Kahastoktalk21:27, 4 April 2020 (UTC)
If it's never done in practice, this implies there's little to no demand for it in practice. A lesson worth learning? Any reader who cared could either a) add the flag to the convert template or b) learn how to use the metric system like an adult, if it bothered them that much. Past a certain point, the clutter of too many archaic units makes the article less accessible to everybody. Archon 2488 (talk) 16:31, 14 April 2020 (UTC)
The advice is based on the style guide of the UK's newspaper of record, chosen because it is trying to do what this advice does - reflect modern British usage across the board in a reasonably coherent manner. Proper documentation is a far more appropriate basis for our judgement of what is or is not common usage than some random Wikipedian's echo chamber.
The BBC style guide was not used because at the time it was not easily available. Now it is, and it too recommends imperial-first in UK-related contexts, and explicitly gives examples of personal weights in stones and pounds.
My own experience is quite the opposite of yours and the IP's. In my experience, stones and pounds and feet and inches remain the more common standard even among people who are both reasonably young and scientifically literate. They're not universal, but more common nonetheless.
Both local oncology units record weights and heights in both. The equipment has dual scales so it is trivial to read off both metric and imperial. I assume this is to accommodate all those backwards people! Martin of Sheffield (talk) 09:02, 5 April 2020 (UTC)
FWIW this is incorrect; standard practice in UK medicine is to use metric for virtually everything. Some (mostly older) analogue devices will show both metric and imperial measurements, but no correct clinical workflow will direct practitioners to record any patient measurements in imperial. Any such work instruction would be in contravention of NHS guidance on best practice and would need to be updated. Archon 2488 (talk) 11:25, 14 April 2020 (UTC)
I have absolutely no idea what workflows direct or what work instructions there are. All that happened was that the nurse read off the measurements in imperial and then metric. Something along the lines of "five foot 11 ... one point eight metres* ... fifteen stone ... ninety-five kilos*" followed by an admonition not to loose weight whilst on chemo (I'd lost half a stone). So, you may be correct in that the system only records metric, but the nurses certainly take note of both scales. (*IIRC, I didn't pay much attention to the metric versions) Martin of Sheffield (talk) 15:43, 14 April 2020 (UTC)
At the risk of contributing to the prolongation of this pointless thread: since the nurse wanted to encourage you to keep your weight up, it makes sense she'd tell you your current weight in both modes, to be sure you caught one or the other. That doesn't mean she put both in the record. As others have mentioned, that's almost inconceivable. As the adage goes, "A man with one watch knows what time it is. A man with two watches is never sure." EEng16:51, 14 April 2020 (UTC)
You're perfectly correct that young people (and I'm in my 30s, so not exactly a teenager) are totally excluded by guidelines that are based, for reasons of absurd historical accident, on a style guide for a newspaper run by a guy who makes Mussolini now look a bit like a cuddly centrist. Basically, the people who have political power in the UK, including here on WP, do not care what younger generations want. They will wilfully spread lies, if need be, that younger people are as clueless about the metric system as they are, purely to derail any argument that the population will inevitably become less and less familiar with archaic units as time goes on. Since I first brought this up in 2013, an appreciable demographic change has inevitably occurred, purely due to seven years of older generations being replaced by younger ones. Nobody can deny this is happening, and plenty of people have pointed out the ridiculousness of deferring to a newspaper on the question of how an encyclopedia should measure things. But until the people responsible for maintaining this nonsensical status quo are no longer here to tell younger people what they think, it will not change. Give it another seven years. Then another. Archon 2488 (talk) 11:25, 14 April 2020 (UTC)
In my experience, almost every person I know (who's from the UK) measures themselves in feet and inches, too the majority also use stone and pounds. It's not as if I only associate with 'grandparents and over-60s', as op said, since I'm a 20‐year‐old currently studying at university. Genuinely, the only young people I've heard complain about that are international students, and then it's more of a jokey "oh, look at the small differences between our two cultures" sort of comment. Currently, the use of imperial measure is commonplace within the 'clueless' younger generations. But, even if that wasn't the case, Wikipedia should always follow the consensus of society as a whole, not just one sub‐section nor should it try to lead it. For good or ill, from casual conversation to broadcast news or even police search appeals, it’s the de facto standard (for body measure) here in the UK. Personly, I don't see that changing any time soon. ‐‐Voellotalk14:06, 14 April 2020 (UTC)
I entirely agree. As a Briton in early middle age (neither a grandparent nor over 60), I'm not sure I've ever heard any British person of any age use metric measurements for their height and weight. My stepson, in his mid-20s, certainly gives his height in feet and inches. When I was a police officer we didn't use metric measurements for suspects' heights either. -- Necrothesp (talk) 15:52, 14 April 2020 (UTC)
For formal works of reference, i.e. the context we are actually working in, metric is standard. It is trivial to buy British reference books which give measurements exclusively in standard metric units – has been since long before Wikipedia was a thing. None of the other contexts you have mentioned, which are mostly informal, are relevant to encyclopedic usage. It's entirely common for works of reference to use a more formal register and adhere more strictly to formal academic/international standards. Even plenty of American reference publications do it (because nobody outside America or the 19th century would have a clue what they meant otherwise), and they normally insist on pretending that their collection of pre-imperial English units is actually a "system" that competes with SI, despite the fact that every vaguely educated person on Earth knows that's scientifically illiterate nonsense. Archon 2488 (talk) 16:08, 14 April 2020 (UTC)
We always give imperial/US Customary and also metric. The only question is which comes first and which follows in parens. It's the most stupid issue to spend time on.
I suggest we heed his advice and put this pointless thread out of its misery now, unless someone wants to make an actual proposal for changing the guidelines. Really. EEng15:37, 14 April 2020 (UTC)
I'm not sure that there's a problem at the moment because, even though the recommendation is to give imperial first, the metric equivalent should also follow for those who prefer that. Currently though, as Kahastok says above, imperial is still the preferred primary system for leading British publications. Also before we consider changing our recommendations, we need to be sure exactly what the current British practice is, rather than go by Wiki editor's own opinions. A YouGov poll from 2015[15], showed that 61% of British citizens (across all age groups) did not know their weight in kilograms. -- DeFacto (talk). 16:11, 14 April 2020 (UTC)
If "leading publications" means the tabloid press, maybe. I'd suggest that newspapers should not be the arbiters of what units we use – that it is inappropriate to use them as such, leaving aside their basically unethical nature, because they are the wrong type of literature. Reputable reference publications, such as you might want WP to aspire to be (hint, modelling it on Rupert Murdoch's style guide is not the way to do that), are generally pretty happy to use modern, standard international units. Typically without conversion. If there is a legitimate historical reason to use deprecated units, they'll do so, often with conversion. For a number of reasons – I don't think many 20-year-olds could explain to us what "300 acres" means, exactly, or how you'd relate that to an area in square miles. This is revealing, I think. Archon 2488 (talk) 16:22, 14 April 2020 (UTC)
I think the same way about people who use freedom units. A pity the legislature in my country can't or won't get it together. :^) Of course, cherry-picking comments from an entirely unrelated discussion is a sure way to be "a person with whom you should expect a rational debate on this". --Izno (talk) 22:03, 14 April 2020 (UTC)
If you're using the lazy definition of "rational" as "willing to pretend literally any perspective is equally plausible" then no I'm not, because I actually know something about the subject. And I think I'll be shredding my mail and checking my door locks from now on, seeing how readily you remember which posts from literally years ago on totally unrelated discussions you want to pick quotes from! Archon 2488 (talk) 22:55, 14 April 2020 (UTC)
It has to be said that that particular racist diatribe was especially memorable.
But we don't have to go there. In this discussion so far you've accused people of wilfully spreading lies and accused people who see a system about non-metric units of not even being "vaguely educated". You've made plain your views on newspaper owners "a guy who makes Mussolini now look a bit like a cuddly centrist" - how's that for neutrality?
We all know that you don't like imperial units. You've told us over and over again. You've told us in great detail on numerous occasions how deeply stupid you think people who use non-metric units are. You've made it clear repeatedly what terrible people you think the rest of us here are. We've done all this twenty times before. Can we move on? Kahastoktalk07:31, 15 April 2020 (UTC)
Just responding to the egregious misrepresentations:
Racist. Wow. I will observe only that a) it is impossible to be "racist against white people", in practice, because racism implies the existence of structural and systemic oppression, which is in reality not targeted against white people in our culture and b) similarly it is practically impossible for a critique of the British state to be racist. Ironically, the "anti-white racism" nonsense is a classic racist dog-whistle used exclusively to silence POC who speak about their experiences of oppression in ways that white people do not like; only white people who have had the luxury of never having to learn what racism is can afford to say such ignorant things.
wilfully spreading lies: the misrepresentations of the metric system (remember "kilofeet" and "kilodays"?) from apparently educated people are difficult to read, I confess. It's distressing. That the people saying these things are liars is a simple explanation, which I have maybe gravitated to because some of the alternatives are more upsetting. In any case, it is far easier for you to make your arguments about me rather than metric. I wonder why. You know perfectly well that, as braindead and morally bankrupt as this consensus is, I will not disregard it; you must also know that the anti-metric rubbish you are inexplicably keen to defend will go the way of phlogiston theory. It is purely a matter of time. Thig ar latha.
vaguely educated / deeply stupid: you know, and have not been able to deny, that education in practice implies education in metric. The corollary of this is that someone who claims not to be able to use it properly is to that extent uneducated, or a liar (for presumably political purposes). But in any case, you don't impress other people by telling them how much you don't understand, especially about something trivial and commonplace. That falls beneath the standard of numeracy that, I believe, a work of reference is entitled to assume of its readers.
how's that for neutrality – Rupert Murdoch is not owed, in me, a pandering sycophant, or even someone willing to overlook his evil behaviour. Sorry. The fault here lies with whoever introduced his rag's uneducated nonsense into an encyclopedia's style guide.
who use non-metric units – no. Using non-metric units, in a context where it is appropriate, is acceptable, provided there is a conversion into modern/standard metric units. You'll pretend I'm inventing my own bizarre standard here, free from evidence and used by nobody else, when in practice I'm describing what I have observed most professional, reputable works of reference (meaning, with somewhat more integrity than a newspaper) to do. Claiming not to understand standard, modern metric units is something entirely different, and I'd put it in the same category as someone pretending not to understand Arabic numerals and demanding editors be compelled to convert everything to Roman, as a pointless waste of time. We all know this in practice feeds into a political game; some right-wing xenophobic British people are so atrociously bigoted they cannot bring themselves to admit the French might ever have had a good idea (they are certainly too historically illiterate to realise that pounds and ounces are Roman rather than English), and so they will pretend to have never heard of kilograms and metres when it suits their purposes. My position is that even if this is genuine ignorance of metric, an encyclopedia cannot pander to every form of ignorance its readership displays.
"I don't like imperial units". You are correct. I also don't like flat earth theory. To imply I have no reason for opposing the promotion of either of these on WP beyond "I don't like it" – when I have explained in excruciating detail why it is unprofessional and inappropriate for something pretending to be a work of reference to place artificial barriers in the way of its editors using the metric system correctly, based on a desire to patronise or pander to its perceived readership – is absurd. Archon 2488 (talk) 18:12, 15 April 2020 (UTC)
It is impossible to be "racist against white people", in practice, because [insert justification] – that's just stupid, and can we stop this now? EEng19:53, 15 April 2020 (UTC)
Just stupid, and yet an entirely typical view of people who study racism and actively oppose it. Why do you not take such offence at bad-faith use of the term "racist" which serves only to cheapen it? Or do you think a tongue-in-cheek rant about backwards British people is actually comparable to systemic racism and the legacy of slavery? Archon 2488 (talk) 09:22, 16 April 2020 (UTC)
Anyone can be racist against anyone of a different ethnicity, nationality or identity, as is specifically recognised in British law. It is completely possible for someone to commit racially aggravated offences against white people. It is also perfectly possible for white people to commit racially aggravated offences against other white people (as has happened in Scotland, for instance, where people have been arrested for anti-English racism). Take that from an ex-police officer. So let's stop this ludicrous argument. -- Necrothesp (talk) 10:53, 16 April 2020 (UTC)
The Guardian style guide specifies metric first but always followed by conversion in brackets, for both height and weight, and has an interesting section on the metric system. As an over-60 maths graduate in the UK... I can never remember how tall or heavy I am in metric units but don't mind whether the metric appears first or second in Wikipedia (as long as the weight is in stones and pounds). PamD07:53, 15 April 2020 (UTC)
I think this is a substantial argument in the context of this discussion. Regarding @EEng's concerns about this discussion being stupid: somebody had this discussion previously, and concluded to display imperial units first before displaying metric ones parenthetically. And someone will likewise have to have this discussion at some point in the future when the UK will completely transition out of using imperial units; why not let that future point be now? If it wasn't a stupid discussion then, it isn't a stupid one now. If it's so trivial for having one order of units vs. the other, why not placate the people who prefer metric units (95% of the world) while still satisfying the people who prefer imperial units, rather than having this discussion over and over again? Getsnoopy (talk) 00:15, 18 April 2020 (UTC)
Again: with extremely rare exceptions the current guideline provides for both metric and US/imperial units to always be given, the only issue being which comes first and which follows in parens. And yet, as one observer put it:
This scarecrow of a debate has, over the course of time, become so complicated, that no man alive knows what it means. The editors most invovled understand it least; but it has been observed that no two editors can talk about it for five minutes without coming to a total disagreement as to all the premises. Innumerable children have been born into the cause; innumerable young people have married into it; innumerable old people have died out of it. Scores of editors have deliriously found themselves enmeshed without knowing how or why; whole families have inherited legendary hatreds because of it. Young boys, promised a new rocking-horse when the question should be settled, have grown up, possessed themselves of real horses, and trotted away into the other world; young girls have become mothers and grandmothers; a long procession of arbitrators has come in and gone out.
OK, that was actually Dickens. But (and I'm serious now) the question has spawned 372 Talk:MOS threads, scores of indefinite blocks, countless lesser blocks, three Arbcom cases, a suicide, several divorces, dozens of rage quits, a bomb scare, a fatwa, a fall of governement, three French hens, two turtle doves, and a partridge in a pear tree. All over which of kg or lbs gets pride of place and which goes in parens. Big fucking deal.
If it's so trivial for having one order of units vs. the other, why not placate the people who prefer metric units (95% of the world) while still satisfying the people who prefer imperial units – because no one will be placated and no one satisfied.
rather than having this discussion over and over again – We don't need to do something "rather than" have the discussion; we can just not have the discussion and leave things alone.
You're welcome. I always try to bring gentleness, love, delicacy, and complete sincerity to my posts. EEng00:29, 19 April 2020 (UTC)
@Getsnoopy: The stock argument you'll hear from the anti-SI old-guard, periodically trotted out for public display like the appalling old waxwork it is (h/t Prince Charles), is that this is a violation of Wikipedia's policy on neutrality. Regardless of the fact that it is very common for UK reference publications to give measurements in metric – exclusively in metric, which as EEng points out is not being proposed here – and this somehow results in a) literally nobody writing to the editors, frothing in rage, complaining they can't comprehend those goddamned French centimajiggles and kilowotsits and won't they please bring back furlongs, pecks, tanners, and corporal punishment in schools b) no meaningful violation of any sort of political neutrality on the part of the publication. We'll hear – another desiccated old corpse of an argument, disinterred, reanimated, slaughtered, butchered and microwaved, a dish served up with the inexplicable expectation that anyone other than its creator might find it vaguely appetising – that unless we have evidence of what appropriate UK unit usage is (meaning, say, some newspaper's style guide), we're just making it up and cherry-picking sources to suit our preferences. I've long since given up hope of the MOS consensus showing even a vague ambition not to be retrograde on this, but future editors will keep coming to this issue (as I did first in 2013), wondering why an internet encyclopedia in the 21st century is so utterly backwards, and getting no satisfactory answer. This is the reason why "just not having the discussion" is not a viable option – everything that can be said on the subject has been said, but not everyone has said it yet. The eventual and inevitable conclusion is denied by roughly nobody, as you observe. The rational solution is, as you propose, to make the date of transition now (or never to have needed to have one in the first place), but for political reasons this is unworkable. I can 100% guarantee you that anti-metric factionalists will torpedo any such proposal under cover of "won't somebody please think of the readers!" platitudes. Archon 2488 (talk) 09:41, 20 April 2020 (UTC)
everything that can be said on the subject has been said, but not everyone has said it yet – That's a very perceptive observation about a lot of WP controversies, come to thing of it. EEng06:06, 28 April 2020 (UTC)
In Favor The SI-system is the 'Lingua France' of the world if they want to speak about measurement. It is used by 97 % of world population. MajorValerian (talk) 15:35, 26 May 2020 (UTC)
Millions (m), billions (bn) & trillions (trn)
Hi there! Just wanted to check on this. I notice that on MOS:NUMERAL the policy states:
M (unspaced, capitalized) or bn (unspaced), respectively, may be used for "million" or "billion" after a number, when the word has been spelled out at the first occurrence (She received £70 million and her son £10M).
So, is there a reason that one cannot denote, say $100 million as $100m, instead of $100M? There was a little discussion over this back in 2011 but can't seem to find anything since. Is this a metre thing, e.g. 100 metres? If its denoting money I think the difference would be found in the currency sign (€) and the "m" right next to the number e.g. €40m instead of 40 m. Donna Spencertalk-to-me⛅02:23, 14 May 2020 (UTC)
Also the potential for confusion with thousand, perhaps? There are all sorts of ways that this gets abbreviated, e.g. M, m, mn. Arguably M is the most logical because it avoids confusion with the symbol for the metre and also ties in with the prefix "mega". In any case, the best thing to do is to pick one and stick with it, which is what the current guidance does as far as I can see. Archon 2488 (talk) 14:15, 14 May 2020 (UTC)
There are more recent discussions on this line here and here.
I'd note that if the "M" were intended to be the SI prefix mega-, as suggested by the 2011 discussion and as suggested here, then that directly contradicts the line directly afterward:
SI prefixes and symbols, such as mega- (M), giga- (G) and tera- (T), should be used only with units of measure as appropriate to the field, and not to express large quantities in other contexts
I'd question whether articles actually prefer "M" over "m"? I'd have thought "$100m" would be more common, and unambiguous in the vast majority of cases, but I'd be interested to see actual statistics if there are any. I think the idea that someone might take "$100m" to mean 100,000,000 millidollars or 100,000,000 dollar-metres is pretty far-fetched.
I think before adopting an abbreviation for "trillion" we need to establish a) that one is needed and b) that the proposed abbreviation is in actual use elsewhere.
And finally, I rather think the current guidance is flawed, and that we should only be abbreviating at all in contexts where there is limited space or where we have a long series of numbers in the millions or billions. In the example given by MOS:NUMERAL, I think She received £70 million and her son £10 million would probably be better. Kahastoktalk17:12, 14 May 2020 (UTC)
I don't see this as a contradiction because it isn't being (ab)used as an SI prefix. Not least because it's actually being used as a suffix, in the cases described here, like "$10M". By contrast, "10 MUSD" or "5 TGBP" (meaning something like megadollars or terapounds), would be misusing the SI prefixes in this way. My meaning was just that the uppercase M, to the casual eye, looks more obviously and unambiguously like "million", both because it's bigger and because it happens to look the same as the symbol for the SI prefix "mega". Using lowercase m seems to offer no advantage, and IMO it makes sense to pick a single unambiguous format and recommend that. Throwing in the rest of my 2d (1⁄6s; £1⁄120), it would probably make most sense to pick a set of one-letter or two-letter abbreviations, either {'M', 'B', 'T'} or {'mn', 'bn', 'tn'}.
The example of that's specifically marked as wrong is "In a population of 1.3G people". Change that to "1.3M people", and we say we should do it in one line and that we shouldn't do it in the next line. The only difference appears to be what's in your mind when you write it rather than what actually appears on screen. Kahastoktalk19:04, 14 May 2020 (UTC)
If "M" is approved as an abbreviation of "million" rather than as a contextually inappropriate use of the SI prefix for mega, then I see no problem here. The MOS does not, on my reading, tell editors to write about megapersons, or anything comparable to that. As illustrated by the fact that "1.3G people" is disallowed, as you observe. Touching on EEng's favourite point, I would want to see evidence that this advice has caused confusion in article-space before discussing it in any more detail here. Archon 2488 (talk) 22:03, 14 May 2020 (UTC)
To partially answer your note about m usage, I see it commonly used in business newspapers and can be sourced here as denotive of one million. The same goes for trn. I, too, agree that these notations should be used only "where there is limited space." @Archon 2488: I think you're right on the dot in your calls to standardize one-letter or two-letter abbreviations. That will make this type of guidance much more clear and effective. Donna Spencertalk-to-me⛅17:35, 14 May 2020 (UTC)
We can increase the number of letters in the abbreviation as an additional reminder of the power, in units of 103. Thus: m, bn, trn, qdrn, qntln, sextln. Archon 2488 (talk) 18:33, 14 May 2020 (UTC)
The section does actually define a trillion (as 1012, as opposed to 1018). But previous discussions (such as this one) have not accepted a standard abbreviation. Kahastoktalk21:00, 14 May 2020 (UTC)
Also, in the desperately sad eventuality that this was not immediately obvious to everyone, my suggestion was a piss-take. Archon 2488 (talk) 22:23, 14 May 2020 (UTC)
I've been hearing a lot about piss-taking recently and I'm moved to request that my fellow editors be a bit more circumspect in discussing their erotic fetishes. EEng23:44, 14 May 2020 (UTC)
A lot of the UK press use the abbreviations m for million and bn for billion, these include BBC News, The Guardian and The Telegraph newspapers. For trillion, tn is used by the BBC & The Guardian (the Telegraph doesn't use trillion, preferring "million million" instead). I do prefer these abbreviations as they're the ones I'm most familiar with. I do find it odd that Wikipedia requires M for million, I don't think I come across this anywhere else (except a few older sources where it is used to denote a thousand). As for whether we should use these abbreviations: infoboxes and tables – definitely, for article text I find the Guardian's guide is quite interesting, it allows the abbreviations for money and inanimate objects but not for people & animals (something doesn't look quite right with "2M people"). --Voellotalk20:13, 14 May 2020 (UTC)
I would observe that the use of "m" (mille) to mean "thousand" predates the distinction between upper- and lower-case in the Latin alphabet by centuries. In normal text, an abomination like "2M people" should never be allowed, as it should be spelled out in full. Tables and other such space-limited media may use such abbreviations if they need to, although in most cases there is likely a better alternative. Archon 2488 (talk) 22:50, 14 May 2020 (UTC)
No, that guide would say "2 million people would have over $3bn in student debt wiped out" or "the industry, which employes 1.5 million people worldwide, produces 600m tonnes of coal annually". Though of course, it would allow the fully spelt out versions too. --Voellotalk21:58, 14 May 2020 (UTC)
The context of "600m tonnes" is actually a pretty good illustration of why I specifically dislike the lower-case "m" as an abbreviation for "million". Using it in proximity to units of measurement is asking for, at worst, confusion, if not just unnecessarily ugly text. I would also note that the convert template does not use these abbreviations with its output, e.g. 600 million metres (2.0×109 ft) (standard form) or 600 million short tons (540 Mt) (SI prefixes). Units should use SI prefixes where appropriate (hence "600 Mt" rather than "600m tonnes" or similar). Archon 2488 (talk) 22:22, 14 May 2020 (UTC)
I agree that the SI prefixes are a better fit when brevity is needed; I was just paraphrasing one of their examples in their style guide. However, I would argue that "600M tonnes" would look more unwieldy, and could cause greater misunderstanding, as some may read it as a metric-prefix which had been incorrectly typeset. In general, I think the wider use of the lowercase version throughout print media would create less of a chance of misunderstanding, as more readers would be familiar with it. --Voellotalk00:25, 15 May 2020 (UTC)
It looks like the "and her son" example is something I shortened from an existing, longer example (check both sides of [16]). I agree that M and bn should be used primarily in tables, infoboxes, and maybe text containing a long series of figures. Yet, in tables/infoboxes there probably isn't room for the on-first-use-spell-out. So I think there's at least room for a better example [17] and maybe a refinement of the guideline itself (re infoboxes etc as just mentioned). EEng18:52, 14 May 2020 (UTC)
We've had a few suggestions here, none of which offers any obvious large advantage to my mind over keeping the MOS as it is. For the sake of (perhaps foolish) consistency, I would prefer picking a set of standard one- or two-letter abbreviations and sticking with it; including trillion isn't a terrible idea, but if the need to abbreviate it is rare enough that it doesn't need to be included in the MOS, fair enough. If, as I suspect, recommending "M" and "bn" (and saying nothing about larger numbers) hasn't caused disruption in article-space that cannot be resolved except by changing the MOS, then what is the benefit of changing the MOS at all? Especially considering that we would thereby be telling editors to change god-knows-how-many articles from one well-established style to another that offers at best a purely hypothetical advantage. Archon 2488 (talk) 11:45, 15 May 2020 (UTC)
I think there's broad support for only abbreviating where space is restricted or where "million" or "billion" becomes repetitious, rather than just the second time it's used in a sentences. Kahastoktalk15:56, 15 May 2020 (UTC)
I would also say there is broad support for standardizing where million, billion, and trillion become repetitious as well. However, I will say, my original post was asking for clarification rather than a MOS change. But that aside, I am not buying the "m" is too close to 'metre' argument. If there is a currency symbol in front of it, there's no way someone could mistake "swimming a $100m" – that is of course, unless someone is swimming in a 100 metre-pool filled with $100 million. Perhaps a distinction between currency & non-typeset numbers, e.g. $100m v. 100 m is warranted. @Voello: do correct me if I'm wrong but such a distinction exists in the sources you mentioned? Donna Spencertalk-to-me⛅17:12, 15 May 2020 (UTC)
Oh, sorry @DonSpencer1: just to clarify they don't have any distinction between the use of "m" for million or for metre. Interestingly, all three of the guides have even less of a distinction than there would be here on Wikipedia, as they do not stipulate the nbsp between the symbol and quantity unlike our MOS (e.g. 10m, not 10 m). However, I do think the distinction can easily be derived through context as to what the "m" stands for; and they don't make note of needing to change the structure or formatting of a sentence so they not be confused. --Voellotalk03:46, 28 May 2020 (UTC)
Perhaps its going here...
@Voello: Agreed, the context does indicate its meaning. I think it would be better to move from MOS:NUMERAL to MOS:CURRENCY#Formatting for this. The formatting section states: "million and billion should be abbreviated M or bn". If anything is to be changed, the formatting section should read "million, billion, and trillion should be spelled out on first use, and (optionally) abbreviated M, bn, and trn (all unspaced) thereafter". I think modifying that section instead would address the notation, brevity, and metre issues brought up for MOS:NUMERAL. Donna Spencertalk-to-me⛅13:57, 28 May 2020 (UTC)
Let me make sure I understand this. You're suggesting that this M and bn (and maybe trn) notation should be used only for monetary values? That's an interesting idea. Do we have any other realistic use case for these abbreviations? EEng
Exactly. So, I don't know if you're referring to its actual use on articles or in real life so I'll provide both. I could see it being very useful on articles like 2020 Russia–Saudi Arabia oil price war or larger articles like Economy of Spain. As Voello, Kahastok, and I pointed out, when coupled with a currency sign, it would be helpful repetitious notations of monetary amounts. I think just the proposed additions in green (above) will do IMO. Donna Spencertalk-to-me⛅18:59, 29 May 2020 (UTC)
No, I meant does anyone have realistic uses cases other than for money amounts i.e. can anyone show reasonable uses we'd be "outlawing" if MOS restricted use to money? EEng19:45, 29 May 2020 (UTC)
Population size is an obvious one, though I can't think of any examples in the wild. Googling finds a few, but once you strip out talk pages, source titles in citations and instances that don't follow MOSNUM already, you lose most of them. The trouble is you actually have to google a number becuase "m people" just finds the band.
(There is, incidentally, a case that could be made in this instance for "m" being too easy to confuse with "metre". The phrase "2m people" is theoretically ambiguous as it might be referring to people who are 2 metres (6 ft 7 in) tall. Though I still find it difficult to imagine a context in which it would be ambiguous in practice.) Kahastoktalk21:03, 29 May 2020 (UTC)
But if we were to just follow MOS:CURRENCY, couldn't we just add "trn" for trillion just as we have M and bn for million and billion, respectively? If its in the currency MOS then I don't think it would necessarily restrict other sections, e.g. MOS:NUMERAL, which is to say editors can use $2m to denote $2 million but not use 2m people for the reasons outlined by Kahastok above. In line with this I see 2 changes we could come to a conclusion on:
Motion 1: To add trn or tn as an abbreviation for trillion dollars
Motion 2: To standardize either (a) {mn, bn, tn} or (b) {M, bn, trn} or (c) {m, bn, trn}
This way we can further differentiate between 'm' as notation for metre or million because, as outlined, it can get confusing when a currency symbol is not in front of it. Donna Spencertalk-to-me⛅21:41, 29 May 2020 (UTC)
Let's not do motions just yet. For now let's just keep exploring. So far Kahastok's mentioned population size as a possible non-monetary application of M (I'm going to assume for now we're staying away from m) or (conceivably) bn, but he says he can't bring any examples to mind. Can anyone? What we need is examples in which the ability to use M (for populations, or anything non-monetary) is really, truly a benefit to the reader. EEng22:27, 29 May 2020 (UTC)
Dondervogel 2, let's argue the specific abbreviations later, if that's all right with you. What do you think about restricting their use to monetary amounts? If not, can you give us a few actual article examples of its use outside monetary amounts? EEng02:43, 30 May 2020 (UTC)
"Use figures at all times with currency signs and abbreviations: £1, $2. Abbreviate million to m and billion to bn in headlines.
In stories concerned mainly with money, company reports and City page references to bids and deals, use m and bn. In news stories as distinct from stories in the business section always write million and billion in full."
Adding "holiday" and other similar terms to WP:SEASON?
Can we add a line under WP:SEASON to avoid terms like "holiday" or other similar terms that are often used to reference to non-specific periods? (I'm not sure what others there might be beyond "holiday", but ...) --Masem (t) 15:10, 30 April 2020 (UTC)
I guess the question is how far we want this page to move away from astronomical concepts (winter, summer) to start dealing with cultural concepts ("holiday season", "school vacation"). EEng16:19, 4 May 2020 (UTC)
Perhaps maybe a separate section but within the main section on time factors dealing with culture concepts around time, which should be available to refer to approximate date periods, just to avoid conflating things then (as when I look at the subsection order, I do see the logical progression based on time unit sizes). I mean, I think there's general agreement we don't say "The film was released during the 2019 holiday season." but I can't readily point to a MOS page say why that's bad outside of "well, see SEASON? same reasons...." --Masem (t) 16:31, 4 May 2020 (UTC)
Right, and we also don't want articles to say, "The story got a lot of attention during the 2019 silly season", unless silly season is linked. Similarly, I guess, Hurricane season, hunting season. Maybe I'm getting stuck by the fact that all the examples so far involve the word season. Can we think of examples not using that word -- something something week for example? EEng17:23, 4 May 2020 (UTC)
Well there's like spring break, homecoming, and that gets into ideas of anything tied the vague "school year" concept. I'm lacking ideas from other cultural norms but am sure there's more examples. A few more examples to express the general idea would be good. As a note, I would not avoid using "hurricane season" if we're on a topic about hurricanes where we've likely defined what hurricane season is or are linking to that (as most hurricane articles do), but I wouldn't use is as a general time reference on an unrelated article. There are some times these terms are proper but only when in the right context. --Masem (t) 17:32, 4 May 2020 (UTC)
I was thinking about school-related stuff too. Of course spring break, summer school, fall semester are already covered by the main warning. Homecoming (or, say, prom season) is exactly the sort of cultural reference, far disconnected from astronomy, that I think we just have to rely on editors to realize need glossing or linking, without our treating it here. So I'm still unsure if there's enough left to be worth a bullet point. We need more examples. EEng01:40, 5 May 2020 (UTC)
FWIW, the standard for the international date format ISO 8601 was recently revised (2019) to include so called Extended Date Time Formats. This expands the form "yyyy-mm" by the following sub-year groupings for "mm": [18]
01: January
02: February
03: March
04: April
05: May
06: June
07: July
08: August
09: September
10: October
11: November
12: December
21: Spring (independent of location)
22: Summer (independent of location)
23: Autumn (independent of location)
24: Winter (independent of location)
25: Spring (Northern Hemisphere)
26: Summer (Northern Hemisphere)
27: Autumn (Northern Hemisphere)
28: Winter (Northern Hemisphere)
29: Spring (Southern Hemisphere)
30: Summer (Southern Hemisphere)
31: Autumn (Southern Hemisphere)
32: Winter (Southern Hemisphere)
33: Quarter 1 (3 months in duration)
34: Quarter 2 (3 months in duration)
35: Quarter 3 (3 months in duration)
36: Quarter 4 (3 months in duration)
37: Quadrimester 1 (4 months in duration)
38: Quadrimester 2 (4 months in duration)
39: Quadrimester 3 (4 months in duration)
40: Semestral 1 (6 months in duration)
41: Semestral 2 (6 months in duration)
While we do not support ISO 8601 dates per se (except for, in some areas, the "yyyy-mm-dd" form), this means that the "????-??" form has become even more ambiguous than it already was (Example: "2019-21" means "spring 2019", rather than "2019-2021").
It is quite likely that our citation templates will support these "extended month" values at some point in the future at least on wiki source code level to help unambiguously specifying some sub-year groupings in dates (but would probably display them as text only in citations).
So, whatever we do in regard to WP:SEASON, we might at least keep these particular sub-year groupings in mind as patterns that will likely be used more frequently in the future.
Yes, I can definitely foresee the prospect of people adding ISO encodings of quadrimesters to articles. I really think that may become popular. EEng19:25, 7 May 2020 (UTC)
Of course, you meant that with a tongue in cheek. ;-) To be honest, while I am happy that an official notation exists to note down such groupings numerically, they could have come up with more thoughtful numerical assignments which would follow some higher logic and have mnemonic value (and also cover a few more cases which would have more practical value than, perhaps, quadrimesters in particular). But now that it has been published the way they did, people will have to use their system or none at all.
In regard to WP:SEASON, my comment above was, of course, more referring to the lingual representations of these groupings than to their numerical assignments.
Well of course I speak with forked tongue; in this case only one fork was in cheek. I was thinking the same: the coding is absolutely stupid. It's like something you'd find in a COBOL program from 1965. EEng21:23, 7 May 2020 (UTC)
I love the ISO date format but if I'd seen a date like 2020-21 before I saw this chat then I would have been confused and would have instantly reverted it. If an ISO lover like me can be confused, then what hope does a layman have?
I am also against such terms like 'holiday season' because it is a term used mostly in N.America, the rest of us need to look it up and it is so easily replaced with neutral terms. But whether it should be banned here or be banned in another location is up for discussion. Stepho talk23:00, 7 May 2020 (UTC)
Since English is the Lingua Franca of the World which many people of different countries speak and learn we should make a change how we Group Digits.
Since we currently use 2 formats to group digits: comma (,) or narrow gap . It is confusing for viewers of different countries which use the comma (,) as a decimal seperator.
""We dont need to just use the narrow gap but we should give it priority when we do digit grouping. Like the italian Wikipedia already does.""
My proposal: When grouping of digits in groups of three, prioritise the narrow gap then the comma (,).
Ultimately this is the English Language WP. We follow English, not Italian, usage. Note that according to WP:DIGITS "Note that use of any space character as a separator in numbers, including non-breaking space, is problematic for screen readers", we would be trading effective use of the English WP for a confusing and unfamiliar style. Just as we assume that non-Anglophones have to learn English vocabulary, syntax and grammar to read sentences, is it unreasonable to assume the same for numbers? Martin of Sheffield (talk) 13:59, 26 May 2020 (UTC)
Italian usage was only an example. What else should the english wikipedia follow if not english... Why would it be an unfamiliar style? The space as a 3number seperator is the easiest to understand, one look any everybody understands what it means. (1000000 = 1 000 000) The average reader interprets these numbers as 1 million easily, dont assume hes stupid. Any new change will be unfamiliar at first, for everyone. But the space as a 3number seperator is already used since decades. yes of course non anglophones need to learn the english vocabulary, syntax and grammar, but Numbers and number seperation arent exclusevly english, it is its own internationally accepted language. A space as a 3number seperator is understood everywhere in the world and the standord of ISO and other organizations. Numbers and their seperation are universal in all languages no just english. Also an article which covers this nicely: http://themetricmaven.com/the-presentation-of-blank-space/MajorValerian (talk) 14:58, 26 May 2020 (UTC)
The style you describe is allowed in the contexts where it is used, mostly in the context of talking about SI units directly (since the SI style is to allow either the period or comma as decimal separator, but to mandate the thin non-breaking space as the digit separator) or the physical sciences. It's not widely used elsewhere. Formally, in SI, "100,000 m" means the same as "100 m" (neglecting the greater implied precision in the former). The issue isn't so much the supposed stupidity of our readership as wanting a simple and consistent style that matches what is widely used in the relevant English-language context IRL. Add that to the additional technical issues with the space-as-a-separator style, as mentioned above, and you have an unnecessary headache for the sake of recommending a style that is a trivial change to what we already have, in the process deprecating the style used on millions of articles. Archon 2488 (talk) 19:05, 26 May 2020 (UTC)
It would not hurt millions of articels. They would just get changed over time or some people do it willingly. But you made some good points, i agree with them. MajorValerian (talk) 00:06, 27 May 2020 (UTC)
I would love to have this as a policy, seeing as it's the official way to do it in SI/ISO contexts, but I doubt you'd get much support for it here with issues of "legacy" and "convention". This is also not to mention that it has nothing specifically to do with English, but with English as it's used in certain countries. South Africa uses the comma as the decimal separator, for example, in English. Add to this the issue of other languages using commas as well and the original motivation of the narrow-space over comma becomes increasingly clear. However, the point about screen readers is a valid issue, although I don't know about its prevalence now as compared to when the original policy has been considered. Getsnoopy (talk) 21:44, 26 May 2020 (UTC)
I support the use of a thin space as thousands separator. It solves the inherent ambiguity in 100,000 m. I also agree it does not need to happen overnight. It can (probably should) happen slowly so that the readers don't ever notice the difference. Dondervogel 2 (talk) 09:08, 1 June 2020 (UTC)
Date format for non-English countries
MOS:DATETIES states: Articles on topics with strong ties to a particular English-speaking country should generally use the date format most commonly used in that nation (my emphasis). Can anybody explain why this rule only applies to English-speaking countries? I edit a lot of articles with strong national ties to Denmark, which use the DMY format, and would therefore naturally use that format in those articles. An example: I would like to change the date format in Thorkild Grosbøll from MDY to DMY, but am (per MOS:DATERET) not allowed to do that. I understand that we do not wish to allow the YMD format that are used in e.g. China, but we could say that if an article have strong national ties to a country, and that country uses either DMY or MDY, then the article should follow the convention of that country (note: there is already a special rule for Israel, which speaks Hebrew). ― Hebsen (talk) 20:04, 11 May 2020 (UTC)
An interesting point. The reason stems in part from the preceding sentence: "For any given article, the choice of date format and the choice of national variety of English ...", Denmark does not have a national variety of English so there is no particular mandate to use English or American conventions. MOS:DATERET is aligned with MOS:RETAIN and MOS:DATERET and states that article should follow the conventions that they were first written in. Presumably the first significant editor for Thorkild Grosbøll was American and therefore American conventions apply. If Denmark want's to adopt a form of English as an official language then I'm sure we'll all be happy to change things! Martin of Sheffield (talk) 20:45, 11 May 2020 (UTC)
The sentence you are quoting ends with ... are independent issues. If they are independent issues, why would the date format be linked up on whether or not the country in question use English? Surely there is no national variety of English in Denmark (nor any preference between those that exists). But there is a national date format, and this can be directly transferred into English. ― Hebsen (talk) 21:25, 11 May 2020 (UTC)
Have a go at getting consensus for change on the talk page. I'd support you, but you may find a large American contingent who will dispute the change. Martin of Sheffield (talk) 22:14, 11 May 2020 (UTC)
My take on it is that RETAIN is the main thing and TIES is the exception to it. That is, optional styles should not generally be changed just because you prefer the other style. You need to get consensus on the talk page. TIES is an exception, meant to streamline the process in the case of really incongruous things (say, an article on an American building that mentions the use of "aluminium" in its construction), and it's limited to ties to English-speaking countries because that's where the sharp incongruity comes from. I don't really think it's so sharp in the case of Denmark.
That said, I personally prefer DMY even though I'm American, because it just makes more sense, and it's not at all unknown in the States (though it may tend to come across as "military"). --Trovatore (talk) 22:28, 11 May 2020 (UTC)
I tend to agree with Hebsen, and have interpreted MOS:DATETIES as such given that it says are independent issues. This has empirically been true in my experience as well; this article on Thorkild Grosbøll seems to be an exception. Either way, to clarify the language, we should remove the "English-speaking" part. In fact, it would probably be much easier to just say "For all articles that do not have strong ties to the United States, use DMY dates" similar to the MOS:UNITS policy. Getsnoopy (talk) 22:53, 11 May 2020 (UTC)
No, I don't agree with this. Non-English-speaking countries don't have "TIES privilges" on English Wikipedia, and I would be opposed to changing this. --Trovatore (talk) 00:14, 12 May 2020 (UTC)
I would read this as meaning that DMY vs MDY is not so much "UK vs US" as "US vs rest of the world", similar to the unit presentation formats. Which is a fair point; although I don't much care either way, it is arguably jarring to have an article for a generic, non-American-specific audience use a date format that is not widely used in most of the world, purely because the first tie-breaking contributor in that article's history did. Especially if it's about a country that does not use that format, a devil's advocate might say, similarly to how having distances in Germany expressed primarily in miles violates the principle of least astonishment. But unlike that latter case, I suspect the feeling will not be strong enough to change MOS guidance. Archon 2488 (talk) 15:58, 12 May 2020 (UTC)
Do remember: DATERET doesn't say you can't change dates, just that you should not change such dates without seeking consensus first. Ask on the talk page of that article "I'd like to use DYM than MDY here...". --Masem (t) 00:17, 12 May 2020 (UTC)
It seems very unsatisfactory to argue for a change in date format with the reason "strong national ties", when MOS:DATETIES does not apply. How on Earth should I make a policy-based argument? (nevertheless, for my example, I have started a discussion on Talk:Thorkild Grosbøll). ― Hebsen (talk) 13:30, 12 May 2020 (UTC)
I reject Hebsen's statement "Denmark, which use the DMY format". In the context of this guideline, "DMY format" is short for an integer between 1 and 31, followed by one of the words "January", "February", etc., followed by the numerical year. Since Denmark does not use English month names, it does not use the DMY format. Jc3s5h (talk) 01:23, 12 May 2020 (UTC)
This argument is like saying that Denmark does not prefer SI-unit because a second is named "sekund" in Danish. Danish dates (e.g. 12. maj 2020) can be directly translated into English (e.g. 12 May 2020), and will then keep the date-month-year order. ― Hebsen (talk) 13:30, 12 May 2020 (UTC)
How dates are written by writers of another language is one of the things you learn when studying another language. I'm a native US English speaker. When learning French I learned that January 1 is le 1er janvier and January 2 is le 2 janvier, with the first day of the month alone being expressed with an ordinal number. Also, the names of months aren't capitalized. So when I write in French, that's how I write. I don't write Janvier 1 and Janvier 2 just because I write "January 1" and "January 2" in English. Likewise, I presume that native Danish speakers, when writing in English, write dates according to an English (whether UK or US) style. How they write dates when they're writing English is what's relevant here, not how they write them when they're writing Danish. Largoplazo (talk) 13:45, 12 May 2020 (UTC)
I guess no rules without exceptions. The Copenhagen Post and The Local are primarily written by foreigners residing in Denmark, and are not really representative for how Danes write dates in English. Clicking around a little more on the Foreign Ministry's webpage, you will find that both DMY and MDY are used, but the former is prevailing. Similar trends can be observed on other high-profile Danish websites in English (like DMY is also used in the US). I would say that I find MD used a little more than expected, but still far for being equal to DM (I found almost no usage of DMY, presumably because it is when the year is added, that things becomes weird). It is righly relevant. You can only say it is irrelevant if you assume that the English Wikipedia is primarily for people speaking English natively, but that is not the case. ― Hebsen (talk) 14:14, 13 May 2020 (UTC)
Unless the aforementioned foreigners are both non-Danish and nonnative English speakers, that implies that the native English speakers (i.e., the more proficient ones) in Denmark are using MDY, and that the nonnative English speakers (i.e., the less-proficient ones) in Denmark are using DMY. Doremo (talk) 14:31, 13 May 2020 (UTC)
This would make sense only if Denmark didn't use the Gregorian calendar, e.g. if they used a calendar which did not have the exact concept of a month as expressed in the Gregorian calendar, such as a lunar calendar or the French Republican calendar. Since there's a direct mapping of a DMY date in the Gregorian calendar expressed in Danish onto one expressed in English, this analogy makes no sense. (Moreover, there's an obvious abstraction to "time units are ordered by smallest to largest denomination", which is independent of the choice of calendar.) Archon 2488 (talk) 16:02, 12 May 2020 (UTC)
I am sorry you do not wish to discuss things on the talk pages. Can you elaborate why you think it is dead on arrival? Yes, there have been many discussions about date formats, but not many about this issue in particular. Searching through the archives, the most recent serious discussion was in 2014 (please point me to a newer discussion, if one exist). There were support for changing it, but in never got farther than attempts to find a suitable wording. ― Hebsen (talk) 13:30, 12 May 2020 (UTC)
Your proposal seems to be to expand the scope of a MOS rule (from English-speaking countries to just plain countries) without any evidence that such an expansion is needed i.e. any evidence that there are chronic, recurring problems on individual articles that would forestalled by such an expansion. See WP:MOSBLOAT. EEng17:54, 12 May 2020 (UTC)
Indeed, so the point is that MOS doesn't need a rule narrowing the scope to English-speaking countries. That effectively reduces a rule, if minimalism is what we're after. Getsnoopy (talk) 03:30, 13 May 2020 (UTC)
Actually, the proposal would simplify the wording rather than making it more complicated. Also, while the English language is the transfer medium in the English Wikipedia, the project "as is" is international: We are writing for everyone, so it only makes sense to remove any bias from the wording.
You both misunderstand. The minimalism sought is limitation on the range of situations in which MOS prescribes what to do instead of leaving it to editor judgement. That generally means fewer rules, shorter rules, less verbiage (and those characteristics are desirable in and of themselves, of course). But one in a while, as here, a piece of additional verbiage acts to limit scope, and that's what's most important. The proposal is to remove two scope-limiting words, thus expanding the scope. EEng14:37, 13 May 2020 (UTC)
All that's being "misunderstood" is the application of a high-handed essay that you wrote and that no one is obligated to even read, let alone be mindful of, in order to productively participate. Primergrey (talk) 12:24, 15 May 2020 (UTC)
Well, they do need to read it before making a post purporting to respond to it. Now please go back to being your usual jolly self. EEng18:16, 15 May 2020 (UTC)
Mee-ow. But I do enjoy how much these increasingly tortuous acronyms make Wikipedia sound like Scientology. Let's see if we can up the cultish language: "MOS Board and Editingness"? Archon 2488 (talk) 13:04, 15 May 2020 (UTC)
I disagree with Matthiaspaul; the change would greatly complicate the rule.
First, although it might be fairly easy to determine what the predominant date format is for a country where predominant calendar is the Gregorian calendar and the language is related to English, for other countries such as Saudi Arabia or India, where different calendars and alphabets other than the Roman alphabet are used, determining the predominant date format is more difficult.
Second, since this is the English Wikipedia, most of the editors use English as their main language, and often read English-language sources, even if the topic of the article is something or someone connected with some other language. Therefore, many editors will not know what the predominant date format is in the language most closely associated with the topic of the article. Jc3s5h (talk) 14:04, 13 May 2020 (UTC)
I have found the contrary to be the case; most editors on topics related to specific countries seems to have ties to that country. Therefore they would know what date format to use. This is presumably also the reason that DMY is prevailing on articles on (for example) Danish topics. On your first point, we agree that the date format should not be the one they use in their own language, but rather the one they use when writing English (only if one is prevailing). ― Hebsen (talk) 14:29, 13 May 2020 (UTC)
Don't most countries have an official Gregorian date format anyway? In any case, like US Customary units, the MDY format is to the best of my knowledge confined largely to one country. Archon 2488 (talk) 18:15, 13 May 2020 (UTC)
And even then, only to its civilians. DMY is common in US military contexts, so it has a tendency to show up in articles on US military topics. —C.Fred (talk) 18:20, 13 May 2020 (UTC)
I can tell you definitively that India uses DMY dates. And in line with everyone else, it's true that DMY dates are common even in the US depending on the situation (e.g., the military, the MLA citation format, academia in general, etc.). And I see ambiguity as complexity, since different people doing as they please not only leads to inconsistency, but then arguments like these about what to do when and where. This is why I was proposing amending the rule to say "use DMY in every article except for US-related articles which are not about the US military", seeing as approximately 90% of the world uses DMY/YMD dates. This would radically simplify the wording, both in length and in complexity/ambiguity. Getsnoopy (talk) 23:21, 13 May 2020 (UTC)
Specific proposal
Thanks for the inputs everybody. It have been a good discussion with some excellent points from many. I understand (and largely agrees with) the philisophy behind EEng's position of limiting the scope of MOS. In this case, however, there is already a rule: WP:DATERET. This forces us to use a specific style, namely the one the first editor used. Sure, DATERET allows changing the date format by consensus on a case-by-case basis, but it is next to impossible to argue such cases with policy-based arguments. DATERET simply sets no standard for how to do it, and then any argument can reasonably be interpreted as WP:IDONTLIKEIT.
I have tried to formulate a possible extension to WP:DATETIES that really sums the issue I have with the current version:
For articles related to non-English-speaking countries, either format can be used. If one date format is predominantly used in that country (when writing in English), it is acceptable to change to that format (if it is among the acceptable date formats).
This is designed to have the least possible impact, while still solving the problem. All pages that today are compatible with MOS will remain being so, and no editor needs to change editing practices. It will not place any burden on editors to know the specific date format used in English in specific countries; instead this burden is placed on those who wish to change the date format. (If anybody is interested, here is my old (more intrusive) version.) ― Hebsen (talk) 21:29, 14 May 2020 (UTC)
This proposal sounds like it encourages those wishing to change the date format to engage in original research to determine what date format is used by residents of, say, Uzbekistan when they are writing English as a foreign language (to thus impose a change on text that may have been written by a native English speaker). Doremo (talk) 11:59, 15 May 2020 (UTC)
No, WP:OR only refers to material—such as facts, allegations, and ideas, not to style choices. We make style choices all the time, of different reasons. Using one date format instead of another is not OR. In addition, that policy does not apply to talk pages, where such discussions would be held. In discussions, of course, arguments backed by sources have naturally more weight that arguments without. ― Hebsen (talk) 18:40, 16 May 2020 (UTC)
Correct. But I still think it calls for something to be investigated and debated that is just as well handled by arbitrary choice. EEng20:55, 16 May 2020 (UTC)
Without implying that I want this text to be adopted, my reading is that it would apply only if the country has an official (English-language) standard. TBH this is a murky thing, as English is official in a lot of countries that are not traditionally considered Anglophone (not predominantly English-speaking), e.g. India. Whether text has been written by a native speaker is and should be, to my mind, irrelevant regarding whether it complies with the MOS. Archon 2488 (talk) 12:43, 15 May 2020 (UTC)
Oppose. In my experience, finding a reliable source that makes a statement similar to "XXX is the predominant usage in British English" are usually hard to find, although exceptions exist. For example, it's easy to find that the box that transports people between floors in a building is called a "lift" in Britain, but can you find a reliable source that tells us which variants of English predominantly use "BC" vs "BCE" for years 2020 years before the current year? If it's hard to resolve for countries that predominantly use English, it will be even harder for countries where other languages predominate. That's a big, unnecessary burden to impose on editors. Jc3s5h (talk) 20:29, 15 May 2020 (UTC)
I was thinking along the same lines. If articles on Brit subjects aren't in Brit English, it jars Brits. If articles on American subjects aren't in American English, it jars Americans. And so on for other English-speaking countries. But the amount of arguing that will ensue in trying to establish what kind of English is spoken in Lithuania just isn't worth it for avoidance of jarring what few Lithuanians might care, so we just go with the arbitrary tie-breaker that's worked well for so long i.e. he who gets there first gets to choose. EEng21:10, 15 May 2020 (UTC)
Although a rarity, I wholeheartedly agree with the points above. The goal should be to reduce unnecessary discussions like these, not increase them. If the proposal had been to just use (or be allowed to change to) DMY dates for every article that's not tied to the US, I would've absolutely been on board. But this proposal would make guidance like this more contentious than it already is. Getsnoopy (talk) 23:24, 15 May 2020 (UTC)
Question What is the most used style, by country and major international organisations? This might become the default style (DMY v MDY) where there is not a recognised national variety of English (more specifically, English is not recognised as a language of the country). Regards, Cinderella157 (talk) 10:04, 30 May 2020 (UTC)
I believe the Phillipines use both DMY and MDY (according to their article, but it is unsourced). Others might as well, but I don't really know. ― Hebsen (talk) 15:56, 30 May 2020 (UTC)
The only problem with this viewpoint is that Wikipedia is written in English and English is the native language of many of the inhabitants of the USA. To ignore their habits and usages in creating Wikipedia policy just because "Only Americans use MDY." misses the point: are we making a website for English-speaking Americans to use as well? Why do they have to compromise on the Wikipedia in their mother tongue in favor of practices among a minority of native speakers/second language learners? I would just see either usage as a normal part of English, equally acceptable. Geographyinitiative (talk) 10:28, 30 May 2020 (UTC)
Minority? You might want to check how many people in India speak English. I believe it's in the order of 400 million. Can I also suggest you have a read of Help:Edit summary, the fifth word of which is "brief". HiLo48 (talk) 10:35, 30 May 2020 (UTC)
Relative numbers of native English speakers in the major English-speaking countries The viewpoint is certainly problematic in that most native speakers of English (in the "first circle" countries, using Braj Kachru's term[25]) are American, and so a majoritarian perspective would imply that all English WP articles except those specific to the UK (etc.) should use MDY. Doremo (talk) 10:49, 30 May 2020 (UTC)
Native-speaker status is a good criterion for analyzing usage patterns because we assume it correlates well with being a competent language user (e.g., using proper subject-verb agreement, differentiating between subject pronouns and possessive adjectives, and following basic capitalization rules, to choose a few additional issues). Doremo (talk) 16:22, 30 May 2020 (UTC)
Please, please, please. Let's not turn this into a fight between L1 and L2 speakers of English. I have two observations:
1) It's not unheard of for a publication to adopt a certain style and require it to be used consistently (e.g. IEEE Spectrum using SI, which isn't common US practice), and I submit that it would not be inappropriate for an internationally oriented work of reference to do something similar, for example with date formats (or, perish the thought, with units of measurement – but that discussion will be ongoing at the time of the Second Coming, and the Third, and...) People will say that to do so would compromise NPOV; to which one need only ask, do these other publications abandon any claim to neutrality they might have by doing the same? Of course not.
2) A large number of people who use WP are, in point of fact, not native English speakers. Hence the pie chart is not, I submit, a useful contribution to this discussion. Maybe these editors and readers don't even come predominantly from countries where English is well-established as a lingua franca, although a small minority native language, like India or South Africa. This whole conversation seems to me like a relic of the pre-internet age; national borders are largely irrelevant (pace Chinese censorship, etc) in determining how people are able to communicate online. If, say, Dutch, Swedish, and French native speakers want to use the English WP as a means to communicate among each other in their second language (along with native English speakers in their L1), that is their right and prerogative. WP belongs to them as much as it does to Americans (and please, nobody respond with something as problematic/thinly veiled xenophobic as "they have their own Wikis"). The English language belongs to everyone who can use it; since you bring up competence, I'll only observe that it is not at all unusual to meet well-educated L2 speakers whose written English is superior to many natives. Archon 2488 (talk) 17:58, 30 May 2020 (UTC)
Agree with Archon 2488. Personally I disagree with the practice of keeping the original date format that some user chose at the beginning, and I think it goes against the principles of Wikipedia. In my opinion, unless specifically linked to the United States, all articles should use DMY. It is the format most widely used everywhere except in the US, and the vast majority of readers of the English Wikipedia are not Americans. --Ita140188 (talk) 12:43, 1 June 2020 (UTC)
I agree that the general rule should be that all articles should use DMY for dates, EXCEPT for articles specifically linked to the United States. However, if changing the format proved contentious in an article, the order could revert to MDY if that was the consensus of the editors of that article. Michael Glass (talk) 12:56, 2 June 2020 (UTC)
ISO 8601 YYYY-MM Calendar Date Format
I propose the ISO 8601 YYYY-MM calendar date format be added as an acceptable date format. YYYY-MM is the reduced accuracy version of the extended calendar date format. The format is not ambiguous, because ????-?? always means YYYY-MM. It never means YYYY-YY according to the standard. Readability should not be an issue, as Wikipedia already separates semantics and presentation by rendering Wikitext markup into formats intended to be more human readable. It's common for computers to store dates in ISO 8601 format and render them into whatever format the user desires. YYYY-MM-DD is already an acceptable format for citations, but YYYY-MM is not. One problem with this is that some sources provide only a month and year. In these cases, date formats can't kept consistent throughout the article when YYYY-MM-DD is used elsewhere, unless the YYYY-MM format is acceptable. Squideshi (talk) 00:53, 1 June 2020 (UTC)
Two problems to sort out for you:
I believe the ISO now has forms for 1st–4th quarter, 1st & 2nd half and other division of the year. This would need to be addressed by someone who has access to the most recent standard.
Many periodicals use <year>-01 for the first issue in the year, <year>-02 for the second and so forth.
If WP were to adopt this change then issues such as this need to be written up carefully so that the majority who have no access to standards are not constantly being told off for non-compliance! Martin of Sheffield (talk) 09:00, 1 June 2020 (UTC)
For quarters, we can use dates like 1999-Q4, 2020-Q1. Of course, different companies use quarter in different ways (eg, calendar year, US tax year, Australian tax year, arbitrary year) but I can't see any system surviving that one.
Periodicals using 2020-01, 2020-02, etc for successive issues during the year can use |year=2020 and |issue=1, |issue=2, etc. Stepho talk23:14, 1 June 2020 (UTC)
Response: Do you agree the first problem, and the problem of not having access to the standard, could both be resolved by instead adding, as an acceptable date format, the YYYY-MM "Year and month" format described in the "Date and Time Formats" NOTE made available by the W3 Consortium? That document defines a profile of ISO 8601, with the aim being "to simplify the use of ISO 8601 in World Wide Web-related standards, and to avoid the need for the developers and users of these standards to obtain copies of ISO 8601 itself."
In regard to the second problem, I agree many periodicals use the format you describe; and while this format certainly includes a date (in the form of a year) the format itself is not technically a date format--it's a combination of a date format and an issue number. The proposal specifically involves the addition of an acceptable date format. While the year component of the format you describe would certainly be relevant for a discussion about acceptable date formats, the format as a whole is out of scope for such a discussion, in my opinion. Please let me know if you disagree. Squideshi (talk) 07:37, 3 June 2020 (UTC)
Oppose: we write for readers. I suggest that the majority of readers are not familiar with ISO standards, and would interpret 2007-09 as "2007 to 2009" rather than "September 2007". That's why we don't use all-numerical dates, because 6/11/1989 can mean 6th of November or 11th of June, while 6 November 1989 and November 6, 1989 are both unambiguous. If your source only has a month and a year, spell it out: November 1989. Remember the readers. PamD09:10, 1 June 2020 (UTC)
Response: Do you agree it's fair to make a distinction between writers and readers, and it's reasonable to expect that writers be more familiar with the standards Wikipedia employs than readers? The Wikitext markup that writers contribute to Wikipedia is parsed and rendered into a format specifically intended for readers. There are many aspects of Wikitext likely to confuse the average reader, such as the HTML elements used in your signature; however, these elements are transformed prior to presentation to the reader. Date formats can be, and are, similarly transformed prior to presentation to Wikipedia readers. The primary goal of Wikitext should be to lend semantic meaning to the text, enabling various reader presentations that depend on local custom, defined preferences, and other defaults. Squideshi (talk) 07:37, 3 June 2020 (UTC)
We write for readers. What part of that don't you understand? Yes, being an editor does require some knowledge of markup for appearance, and that markup can get complicated for complex constructions. But in the end what the reader sees on the rendered page must look like plain English, not a computer database. ISO dates are meant for machine parsing, not plain text. oknazevad (talk) 15:49, 3 June 2020 (UTC)
Response: I don't think there's any part of that particular statement I don't understand, but I nonetheless welcome the opportunity to continue to discuss; and after exploring the implications, if you believe there remains a part I don't understand, then I will also welcome any attempt you may choose to make to help make it more clear to me. You appear to acknowledge there is a difference between what is written and what is rendered for display to readers. I don't remember disagreeing with you about display formats after content is rendered. This proposal was meant to propose a date format acceptable for use in Wikitext. Do you disagree there can be, and often is, a difference between formats used when writing Wikitext and formats subsequently displayed after rendering the same? Squideshi (talk) 06:57, 4 June 2020 (UTC)
Oppose: the current guidance is there for good reasons. YYYY-MM-DD is acceptable in certain contexts, because it is unambiguous. YYYY-MM and YYYY–YY can only be distinguished by the choice of hyphen or en-dash, which is hopeless for most of us. Peter coxhead (talk) 10:30, 1 June 2020 (UTC)
Response: I agree hyphen and en-dash are not easily distinguished visually; and therefore, these formats may be ambiguous when used as display formats. Do you accept that usage of such formats in Wikitext, or in templates, need not be displayed to readers in the same format; yet, both formats are easily distinguishable by machines, and may be easier to parse by bots, scripts, and in other code? Squideshi (talk) 07:37, 3 June 2020 (UTC)
Oppose: It is ambiguous and most user would not understand what is meant by it. There has to be clarity and use of different types of dash is not sufficient to show the meaning of the date. Most people do not know about the ISO standard and get the format of full dates wrong — YYYY-MM-DD is similarly ambiguous and probably should be ditched for clarity as well. Keith D (talk) 11:49, 1 June 2020 (UTC)
Response: Are you amenable to the idea that clarity is enhanced when all parties involved use a consistent, and agreed upon standard, rather than a variety of different, and sometimes conflicting, standards? Wikipedia employs many standards that most readers don't know about and would not understand. In the same way Wikipedia writers already agree the use of three apostrophes in Wikitext is not ambiguous with the desire to actually display three apostrophes to the reader, the date format becomes unambiguous when agreed upon as a standard by Wikipedia writers. Squideshi (talk) 07:37, 3 June 2020 (UTC)
We already have such a standard. The same ones used by English speakers and writers the world over. Yes, there's mdy and dmy forms, but both are readily understood by any reader and totally unambiguous because they don't use just numbers but spell out months. And, no, using a number for the month doesn't make it more widely understood. Maybe it means that people who don't read English can't read our articles. So what? This is the English Wikipedia, it isn't here to cater to those who can't read English! oknazevad (talk) 15:54, 3 June 2020 (UTC)
Response: You have claimed here that we have a standard and then immediately illustrated there are actually competing standards. I will supplement your illustration by adding there are even more than two competing date format standards. Among English speakers, not only is there variation in the order month and day are presented; but there is also variation regarding what characters, if any, are used between date components. Sometimes slashes are used, sometimes dashes are used, some times hyphens are used, and at other times periods are used. In addition, as you further point out, months can be represented as numbers, or not. Even if limiting focus to those that can read English, this is still a substantial amount of variation; and such variation implies a lack of a standard, by definition.
I also disagree with your unqualified claim that mdy and dmy forms are readily understood by any reader and totally unambiguous because they spell out months. Months are not always spelled out by English writers, and months and dates are indeed sometimes confused. Even if your claim was more narrowly meant to apply to Wikipedia only, or merely English Wikipedia, it would still be incorrect, because YYYY-MM-DD is clearly listed as an acceptable date format; and months are not spelled out when this format is used. Are you suggesting the Manual of Style is incorrect, or is your argument based upon a separate proposal that the Manual of Style be changed? Squideshi (talk) 06:57, 4 June 2020 (UTC)
Response: I sincerely intend no sarcasm, but please accept my apology that I'm not familiar with the approximately twenty years worth of discussion you mentioned. I made the proposal as a result of encountering a scenario where it was not possible to simultaneously comply with the guidance to use consistent date formats throughout an article when the accepted YYYY-MM-DD format is used elsewhere in the article and desiring to cite a source that provides only month and year. Do you know if this particular issue has already been addressed somewhere in the twenty year period you referenced? Squideshi (talk) 07:37, 3 June 2020 (UTC)
Oppose. As it is we should only be allowing YYYY-MM-DD in non-reader-facing technical applications, such as sort keys for tables where the ISO date is not reader-visible, and not even in visible references. YYYY-MM is ambiguous. Period. oknazevad (talk) 13:53, 1 June 2020 (UTC)
Response: Do you consider Wikitext markup to be reader-facing or non-reader-facing? Wikitext is a markup language. Wikipedia defines a markup language as "a system for annotating a document in a way that is syntactically distinguishable from the text." Based on that description, Wikitext does seem like a technical application. Squideshi (talk) 07:37, 3 June 2020 (UTC)
"Reader-facing" is understood to mean the rendered page as seen by readers, not the edit window. Anything involving the wiki text editor is by definition not reader facing. So, to rebut your non-sequitur of a response, I mean that we should not be using ISO dates for anything that appears to the reader. We're writing to be read in English. Sometimes that requires using a markup language behind the scenes, but, to emphasize, that's behind the scenes. What appears to the reader that never clicks on the edit tab is vastly more important than what appears on the edit window, and plainly put, the English language is not a database and does not use ISO dates as proper English. So we should never use ISO dates in rendered articles. oknazevad (talk) 15:34, 3 June 2020 (UTC)
Response: The proposal is meant to speak to what is used behind the scenes, in Wikitext entered into the edit window. The proposal is not meant to address what is displayed to readers after rendering that Wikitext. Please accept my apology if that was not clear in the original proposal. With that in mind, wouldn't you agree the reason stated for opposition was, in fact, the non-sequitur instead of the response to that statement? Squideshi (talk) 06:57, 4 June 2020 (UTC)
There is an unambiguous ISO 8601 form <YYYY>-<MM>-XX where the XX is a literal placeholder for unspecified digits (see Extended Date/Time Format (EDTF) Specification now part of the ISO 8601). At one time cs1|2 experimented with an early form of this (<YYYY>-<MM>-UU) as a way for automated processes (editors, bots, etc) to write month-precision dates in cs1|2 templates. That would let the template best decide how to render the date ({{use xxx dates}}, |df=). I would still like to see that implemented in some fashion.—Trappist the monk (talk) 14:35, 1 June 2020 (UTC)
Support. With the current system we have some article with references in the form yyyy-mm-dd. If we wish to add a reference to a magazine from May 2020 then we need to add 2020-05 to match the other references. But that's not allowed, so we add it as May 2020. But WP:DATEUNIFY says the references must all use the same format, so we change all references to d mmm yyyy or mmmm d, yyyy. But that breaks WP:DATERET and also rubs many editors up the wrong way. There is no win in the current system - only a choice of which policy/guide to break.
Many of the negative comments are about it being ambiguous with yyyy-yy. If a yyyy-mm date was presented in isolation then I could see the ambiguity. But these will be used among a whole pile of other yyyy-mm-dd dates in a whole pile of references. Do we think people are so stupid that after seeing 50 references to 2001-12-31, 1995-06-27, etc that they will suddenly think that the pattern changes? Granted, a few will be confused due to ingrained habits. Just like there are some people who will never believe that "colour" is a correct spelling. To mitigate against this, we can advocate replacing yyyy-yy with either yyyy-yyyy or at least yyyy-'yy. And in the end game, if somebody does get confused - does it really matter? The type of people that go chasing up references are usually smart enough to either figure it out or to try each of the various formats. The type of people that get confused are rarely the type that go chasing references. Stepho talk23:07, 1 June 2020 (UTC)
Response: You describe well the problem that convinced me to make the proposal. You also make an excellent point that the question of ambiguity should be considered in context. I don't agree with others that seem to have suggested the proposed format would be ambiguous after being adopted as an agreed upon standard. Even if it were ambiguous in a vacuum, it would not be when found alongside similar formats and considering the intended audience. Squideshi (talk) 07:37, 3 June 2020 (UTC)
Question: Is the YYYY-YY format based upon any international standard? If not, I agree the non-standard format should be deprecated in favor of a standard one. Squideshi (talk) 07:37, 3 June 2020 (UTC)
@Squideshi: The YYYY-YY format is not based on any international standard. It's just sloppy practice found all over wikipedia, resulting in unnecessary ambiguity. Time for it to go. Dondervogel 2 (talk) 08:51, 3 June 2020 (UTC)
Response: The YYYY-MM format is not only an international standard, but it's also an official national standard in thirty-nine separate countries, several of which are primarily English speaking. This suggests the format is used in at least some English text. How are you defining "normal" English text? Regarding your reference to the reasons discussed above, please see my responses in those discussions. Squideshi (talk) 07:37, 3 June 2020 (UTC)
Response: Do you propose only usual English construction is acceptable in Wikitext markup generated by Wikipedia writers, and how are you defining "usual" English construction? NonBreakingSpace character entity references are not a usual English construction, yet you included three here in the Wikitext just before your signature. Unlike YYYY-MM-DD, YYYY-YY is not currently listed as an acceptable date format. YYYY-MM seems more consistent with YYYY-MM-DD than YYYY-YY. Squideshi (talk) 07:37, 3 June 2020 (UTC)
Limited support – in a context where it will not cause confusion, this might be acceptable. For example, labelling the bins a histogram with year/month, where space is constrained and the benefit of using a terser notation is being able to use a larger and more legible font. Ambiguous nonsense like "2007–08" to mean "2007–2008" should be strongly deprecated, however. Archon 2488 (talk) 11:55, 2 June 2020 (UTC)
Response: The context which inspired this proposal is usage in citation templates. Such templates reference the acceptable date formats as formats they support and are able to parse. Squideshi (talk) 07:37, 3 June 2020 (UTC)
Oppose because - no matter what the ISO standard or MOSNUM says - for a large proportion of readers, "2011-12" is unambiguously in the format YYYY-YY. If space is limited we should use formats like "Jun 2020". Kahastoktalk16:19, 2 June 2020 (UTC)
Response: I'm not trying to be difficult by asking the question; but I would genuinely like to know, is it merely your belief this is true for a large proportion of readers, or are you able to point to evidence which supports that claim? I'm not suggesting your claim is false; however, your claim surprises me, so I would like some confirmation. Please also see my comments above regarding the distinction between writers, readers, Wikitext markup, and text ultimately rendered from Wikitext, which is targeted at readers. Regarding storage of information when space is limited, I argue that alongside the importance of not losing certainty as to the meaning of the data, the ease by which automation can be made to parse the information should also be considered. Squideshi (talk) 07:37, 3 June 2020 (UTC)
Oppose ISO. Not just ISO 8601; I oppose the entire International Standards Organization. They create standards, some of which are suitable for ordinary everyday people, except that they are sold at obscene prices that only corporations with massive R & D budgets can afford. Then they publish cute summaries on their website that don't mention the little gotchas that are only revealed in the outrageously expensive standards, thus turning Wikipedia volunteers into liars. Jc3s5h (talk) 17:07, 2 June 2020 (UTC)
It describes itself as a profile of ISO 8601, which presumably means that aspects of that standard which are not specifically disclaimed are incorporated, and thus hidden behind the overpriced paywall.
Presumably the ISO 8601 requirement to always use the Gregorian calendar applies, but is hidden.
Presumably the need to obtain consent from data exchange partners before using it for years before 1583 is in force, but concealed
Presumably the need to left-zero-pad years, so that AD 43 would be expressed 0043, would apply were it possible to obtain consent to use years before 1583, but this requirement is hidden.
Different versions of ISO 8601 used various methods to represent years before AD 1; there was a version that didn't allow such years, one that had −0001 precede 0001, and the most recent ones have 0000 preceed 0001. The "Date and Time Formats" NOTE does not specify what to do. Jc3s5h (talk) 14:35, 3 June 2020 (UTC)
Response: I find your responses to be well thought out, well stated, and compelling. Thank you very much for taking the time to make them.
The current version of ISO 8601 is broken into ISO 8601-1:2019 (Date and time — Representations for information interchange — Part 1: Basic rules) and ISO 8601-2:2019 (Date and time — Representations for information interchange — Part 2: Extensions). The term "profile" is defined in Section 3.1.2.3 of ISO 8601-2:2019. Per that definition, a profile is a "subset of features" described in the standard. The "Date and Time Formats" NOTE states, "This profile defines a restricted range of formats, all of which are valid ISO 8601 dates and times." For this reason, I agree with your analysis that aspects of IS0 1806 which are not specifically disclaimed are incorporated in the "Date and Time Formats" NOTE.
YYYY-MM-DD is already a Wikipedia acceptable date format. The Manual of Style includes a comment with this format that states, "Use yyyy-mm-dd format only with Gregorian dates from 1583 onward." The footnote for that comment states, "All-numeric yyyy-mm-dd dates might be assumed to follow the ISO 8601 standard, which mandates the Gregorian calendar. Also, technically all must be four-digit years, but Wikipedia is unlikely to ever need to format a far-future date beyond the year 9999." If a similar comment and footnote were included with the proposed YYYY-MM format, consistent with what has already been accepted, do you agree this would address the issues for all five bullet points you listed? Squideshi (talk) 06:57, 4 June 2020 (UTC)
Comment The lesson I take from the discussion above is that the style YYYY-nn (or YYYY–nn or even YYYY—nn) is hopelessly ambiguous and the MOS should clearly declare it deprecated, full stop. A bot should go round searching for it being used and tag it is {{clarification needed}}, reason=Is this notation intended to be a month or a range of years? Please spell out in full.. --John Maynard Friedman (talk) 10:47, 3 June 2020 (UTC)
Response: I accept there may be uses of these formats with potential to be ambiguous; however, I do not agree usage is ambiguous in all cases, nor hopelessly so. We should make a distinction between formats used in Wikitext versus formats used for display to readers. There are other conventions used by Wikipedia writers which would be ambiguous, were it not for the adoption of policies and guidelines that standardize the usage and meaning of such conventions. Do you believe this convention would differ, provided the same treatment; and if so, why? Squideshi (talk) 06:57, 4 June 2020 (UTC)
Comment Like a good sermon, three points and a conclusion:
The note is not from the W3C, it is from Reuters. W3C merely repoduce it "for discussion only. This indicates no endorsement of its content".
Stating that periodicals using a combined year/issue is "not technically a date" dodges the issue. It is confusing. Incidentally the same format is sometimes used for technical drawings, memos and notices to mariners, in other words, widely.
Kahastok is correct. 2011-12 looks far more like a range than an abbreviated date and John Maynard Friedman expresses it well, all forms are ambiguous.
The inevitable conclusion is therefore that YYYY-MM is ambiguous in normal use and should be restricted to data interchange between consenting parties only. Martin of Sheffield (talk) 15:35, 3 June 2020 (UTC)
Response: I agree W3C is not the author of the NOTE, nor has W3C endorsed the NOTE; however, neither of these were claims made. It was stated the NOTE is "made available by the W3 Consortium." In support of that statement, the first sentence in the NOTE states, "This document is a NOTE made available by the W3 Consortium for discussion only." Discussing it is what we are doing here.
I do not agree the claim an identifier consisting of a combination of a year and an issue number is not a date format dodges the issue. I believe this is an important distinction, because while date formats may be used as components of some identifiers, the proposal specifically seeks to add an acceptable date format--not an acceptable identifier format. The YYYY-## format, where ## is an issue number, is not an acceptable date format; and it should never be used in the same context as a date, because it is not possible to use this format to derive a date. Do you think it would be acceptable to indicate the second issue of a periodical published in 2015 has a "date" of 2015-02?
There are two components in the identifier. The first component is a date, and it tells us the year of publication; but the second component of the identifier provides us with no date related information. If we make some reasonable assumptions (such as the publisher does not use negative numbers, does not use decimals, does not use fractions or hyphenated issue numbers, and never reissues with the same issue number) then the second component still only advises us this was the second issue of the periodical in the year 2015. The second issue may have been published during any month in 2015. For example, the first issue may have been published on 2015-01-15 and the second issue on 2015-01-20; or the first may have been published on 2015-01-15 and the second issue on 2015-12-20. Because an identifier in the format YYYY-## can not be used in the same context as a date, in what cases could it reasonably be confused with a date format of YYYY-MM, assuming YYYY-MM has been adopted as acceptable date format in the manual of style? Squideshi (talk) 06:57, 4 June 2020 (UTC)
You are missing the point and are too involved in the minutia. If I mention in text or particularly in a table that an article was published in "Practical Widgets 1910-11" can you tell at first glance whether this is published to cover the season 1910 to 1911, was published in November 1910 or was the eleventh issue in 1910? If not, then let's not add to the confusion. Stating that only first and third are unacceptable in a perfect universe may be satisfying, but in the real world people don't always follow the rules. Even if you go through the whole of WP and ensure that only your perfect form exists, will the readers know this? Martin of Sheffield (talk) 09:43, 4 June 2020 (UTC)
Furthermore, probably the majority of editors contribute only occasionally to a narrow field of subjects. They certainly don't study the MOS to exhaustion, if at all. Given that ambiguous usage is typical in the real world (where disambiguation is provided by context), it is not realistic to expect them to write for Wikipedia differently than they do in other contexts, or that they see written elsewhere. Rather than add support for another YYYY-xx syntax, we should be removing any examples (of whatever intended meaning) that exist already. --John Maynard Friedman (talk) 10:08, 4 June 2020 (UTC)
Currency: country specific articles
For films that have only shown in one country (in this case, Nepal), the currencies are currently in the local currency.
I've been asked to do a GOCE look at the film article, which is mostly done, but I'm unsure on the currency side.
Should it be:
Left as is, as a country-specific article?
Changed to $US, as a non-country specific article?
Left as local, with a US equivalent provided for each use?
(Before I forget, the format for indicating e.g. 500 US dollars is US$500, not U$500 as you have it in that article.) MOS:CURRENCY says
Conversions of less-familiar currencies may be provided in terms of more familiar currencies – such as the US dollar, euro or pound sterling – using an appropriate rate (which is often not the current exchange rate).
But it's not required. Really, I think there's too much detail on revenue the first weekend, the second weekend, and so on, but if you want to keep all that stuff I'd just convert the first figure to $ or Euros or pounds (your choice), to give the reader an idea of scale, and leave the rest alone. If this succession of figures tells the reader anything it's something about the arc of a picture's popularity, maybe something about the effect of Covid, and these are apparent in the original figures without conversion. So complete conversions of everything are unnecessary and distracting. EEng19:06, 28 June 2020 (UTC) And P.S., watch for overprecision, both in the original figures and the converted ones. I've seen movie articles reporting revenues like $8,234,232 and that's stupid. Two significant figures (three if the leading figure is 1) is enough.
The local currency would be better if it used {{currency}}. Eg {{currency|28.4 million|NPR|passthrough=yes}} gives रू 28.4 million.
Conversion to a common currency (eg US$) is optional. Personally, I would not not convert. But if you do, then use {{USD}} and include the year and month of the conversion. Conversion rates fluctuate over time and somebody reading it in 2025 would not know if it is the 2020 or 2025 conversion rate. Stepho talk20:52, 28 June 2020 (UTC)
Cheers all (I'd not edited anything to do with the currencies yet, but I'd agree the current form should be slimmed down, probably to first weekend and most recent figure). Nosebagbear (talk) 21:23, 28 June 2020 (UTC)
No charge for coffee and soda, snacks and alcohol at reasonable prices. In the unlikely event of a loss of cabin pressure, oxygen masks will drop down in front of you for $3.00. EEng00:51, 6 July 2020 (UTC)
I don't see that we have any recommendations on when and how to use Roman numerals (or not to). There is an article talk subpage (Talk:Roman numerals/Rules) where they appear to be trying to achieve some local consensus about this, as well as this Rfc. Thanks, Mathglot (talk) 22:49, 25 July 2020 (UTC)
Just so people know, this doesn't appear to be a MOS matter. No one's suggesting using roman numerals in articles. I hope. EEng15:48, 1 August 2020 (UTC)
I was looking at Street Fighter characters' pages (made by Capcom, a Japanese company) and I found them quite messy about units of measurement. For example, Balrog is metric first, although he's American, while Blanka (Brazilian) Sagat (Thai) are Imperial/customary first. I couldn't find any policy about this topic. I noticed that the official Capcom website is metric, but other video games show character data in Imperial/customary. Does some video games companies want to imitate American-based professional boxing or martial arts data? I know it's a small problem, but a clear policy would be advisable.--Carnby (talk) 09:35, 30 August 2020 (UTC)
I'm going to suggest that this is the sort of thing that is best handled at WikiProject level - in this case WP:VG. MOSNUM cannot realistically provide tailored guidance to every single topic individually.
I would suggest, however, that there is no good reason to base the system of measure on the character's in-game nationality, unless there is some genuine connection to RW national differences (e.g. if the game used a different set of characters depending on market). Kahastoktalk09:56, 30 August 2020 (UTC)
Request for information/to add a currency format example
If it's in accordance with consensus, I'd like to added an example to those already in the section "Currencies and monetary values". Alternately I'd like someone to point out what I've missed or overlooked that already deals with this.
In the infoboxes of articles about companies, I keep running across what Microsoft Excel calls in part "accounting format": left aligned currency symbols with minus symbols to the right of them, immediately next to and to the left of the numerals. E.g., in General Electric and Bain Capital. Is this acceptable, and if there is an explicit exception to the general MOS, where might I find it?
Well I've had a quick look at the two articles mentioned. They are both long articles, it would have been nice if you had at least narrowed the issue down to a particular section or table. It would also have been friendly to give an example in your text. The top and bottom is that I couldn't find anything odd and if others can't then no-one will be able to assist or advise you. Martin of Sheffield (talk) 10:31, 8 August 2020 (UTC)
In the infoboxes (just like the OP said) for GE there are some financial figures :
The OP's concern seems to be the − sign. I don't think there's anything in MOS on this one way or another, and AFAICS that's the way it should be. Is there some dispute about it? See WP:MOSBLOAT. EEng13:39, 8 August 2020 (UTC)
Oops, yes. I scanned the articles themselves a couple of times each and couldn't see it. Now I'm looking in the right place I'd agree with EEng, it looks right for a list, but we probably don't MOS ammending. Martin of Sheffield (talk) 22:28, 8 August 2020 (UTC)
Both the spaced currency symbols (I'm sorry that I forgot to mention that explicitly) and the position of the minus sign are what I'm referring to.
It's the minus out front that's weird. Despite being the author of WP:MOSBLOAT, I sense this is something the guideline should address. Right now we've got:
Currency abbreviations preceding a numeric value are unspaced if they consist of a nonalphabetic symbol alone (£123 or €123), or end with a nonalphabetic symbol (R$123); but spaced if completely alphabetic (R123 or JD123).
My suggestion would be to add, as a sub-bullet right after that, the following:
For negative monetary values such as business losses, place the negative sign (−) between the currency symbol and the digits: Annual profits in the final two years were £123,000 and £−23,000 (or for an alphabetic currency symbol, with a space: R123,000 and R−23,000).
The CFA Institute Style Guide suggests placing the minus sign before the currency specifier.[27]
Microsoft Docs says that the formatting depends on the language and locale. For example, in Denmark, it would be kr−23,000, and in the Netherlands, € 23,000−. As far as English-speaking countries are concerned, it suggests −£23,000 for the United Kingdom and ($23,000) for the United States.[28]
THe European Commission's style guide for English suggests placing the minus sign before the currency specifier.[29]
The Chicago Manual of Style does not seem to address this issue, and just has comments on the forum preferring the same style as the CFA Institute and the European Commission.[30]
Hmmm. Looks like my usually unerring intuition may have erred. A confounding factor in all this is that data in regular text may have slightly different considerations from data in tabular form. For example, part of my objection to the example triplet (the one in the OP with the last entry in red) is that the minus pushes everything over and messes up the alignment. But then, if we were really doing things right there would be extra space in the nonnegative entries, so that when an entry does have a minus sign all will line up, like this:
That annoyance is an argument for minus-at-end, actually. And now my head hurts. Someone save me. Is there a Wikiproject Accountancy? <checks> Of course there is: Wikipedia:WikiProject_Business/Accounting_task_force. And one of their three FAs is Carucage ("a medieval English land tax enacted by King Richard I in 1194, based on the size—variously calculated—of the taxpayer's estate"); I was afraid to look at the other two. Someone please post a query on their talk page (with a balancing post here of course). EEng18:32, 17 August 2020 (UTC)
Another reason for an aspirin: I've also seen −US$1.271 billion (sometimes with a space before and/or after the "US$". That might actually be preferable, since it wouldn't interfere with decimal-aligned tabular data, and data that is more manually laid out can easily be kerned, for non-negative values, with a leading so the "US$" stuff remains more-or-less aligned. In the end, this may be one of those things were we just have to give up hope of perfection. PS: Another option could be using currency TLAs at the end, instead of leading currency symbols: −1.271 billion USD. — SMcCandlish☏¢ 😼 09:37, 2 September 2020 (UTC)
A good reason to prefer SMcC's proposal to use the TLA (ISO 4217, to be precise), is to cope with differing local conventions. In the UK and Ireland, for example, "100 euros" is written €100, whereas in most continental European countries it is 100€ or 100€ – but everywhere it is 100EUR. So the TLA style is culturally neutral as well as looking better in tables. --John Maynard Friedman (talk) 10:21, 2 September 2020 (UTC)
Date ranges: x–y, or y–x, years ago?
In Homo naledi, I came across the following in the first sentence of the lede: "Homo naledi ... [was] discovered in ... South Africa dating to the Middle Pleistocene 335,000–236,000 years ago." Isn't this range backwards? If not, why not? I understand 400 BCE – 300 BCE and 50 BCE – 20 CE. But this is not those.—Finell06:06, 3 August 2020 (UTC)
It's logical: the first time (335,000 years ago) is the oldest, and the second (236,000 years ago) occurred after that. Johnuniq (talk) 09:55, 3 August 2020 (UTC)
Linguistically (because this is a language question, not a math question), the smaller number first is more frequent. Google hits for "10 to 15 million years ago" are about seven times more frequent than for "15 to 10 million years ago". The order "20 to 30 million years ago" is about 14 times more frequent than the reverse. It probably works that way for all "X to Y years ago" combinations. Doremo (talk) 11:37, 3 August 2020 (UTC)
I agree with Doremo. People don't write (or say) "I bought my house 20 to 19 years ago". They write (or say) "I bought my house 19 to 20 years ago". The same logic applies to 236,000 to 335,000 years ago. Dondervogel 2 (talk) 12:19, 3 August 2020 (UTC)
There might be some cases where it makes sense to do this: like when values (years ago, or anything else) are being listed in decreasing order for some reason, so it really would make sense to put the larger value in a range first. But this doesn't really seem to be that case. The nnnn BCE examples work like this because you can treat the BCE suffix as a tag meaning "negative number" (never mind about year 0 silliness). But this isn't quite that case either. These are positive values describing a range in a particular direction. So unless "years ago" is really code for YBP (and it might be, but if so, it should be explicit), it might make most sense to write it the "normal" way. –Deacon Vorbis (carbon • videos) 12:41, 3 August 2020 (UTC)
There are many complications; before we can talk about style, we need to understand the underlying facts.
The abstract of the source cited states "By combining the US-ESR maximum age estimate obtained from the teeth, with the U-Th age for the oldest flowstone overlying Homo naledi fossils, we have constrained the depositional age of Homo naledi to a period between 236 ka and 335 ka." Since these ages are estimated by nuclear decay, each year is considered to be 365.25 days, and each day comprises 86,400 SIseconds. The years are counted from 1950.
If you want to look at reliable sources to see how they generally phrase such statements, you should confine your search to sources concerned with ages determined through radioactive decay; each field has their own way of phrasing things. Jc3s5h (talk) 12:48, 3 August 2020 (UTC)
I recently read several Scientific American articles on anthropology. They consistently use older to younger format: "200,000 to 50,000 years ago"; "between 200,000 and 50,000 years ago". It sounds weird to me (which is why I raised the question), but Scientific American still retains high editorial standards in this post-printing era.—Finell22:02, 15 August 2020 (UTC)
This is absolutely normal usage for anthropological (and paleontological, geological, and such) topics. We aren't looking backwards like the "I bought my house 19-20 years ago) example. We are discussing he period in question. "This species lived from 300 million to 290 million years ago" is really no different from "He lived from 1900 to 1975". The "years before present" construction might make it more clear to the general public. --Khajidha (talk) 12:45, 27 August 2020 (UTC)
Usage varies, is in flux, and in some fields has been the subject of a lot heated debate. I say that as someone with an anthro degree. Systems like "years ago" and "BP" (or "bp" if uncalibrated), and "Mya" are not actually entirely synonymous, but (regardless of differences between them within that class) how to deal with them as to numeric order doesn't align with the class of BC and BCE in all fields/styles/publishing, or between particular publishers, or even within one publication if it does not impose something specific in this regard on submitters of papers. There's a logical split here (actually more than one) between these two classes of dating expression. Exploring it in detail takes a long time.
Piles of deets:
"Years ago" (like "before the present") is a general-English expression meaning not a date range but a span/distance of time (subtle distinction), from actual now, the time of the utterance or writing, backward by an exact an exact or estimated prior time. (See below on distinctions from "Before Present" and "Million Years Ago", with capitals). "Years ago" is completely separate from any calendar system (other that one defines "year" differently enough that conversion is required if the variance isn't within a tolerable margin of error, as between the Western/Julian and Islamic calendars). "BP" is also a span/distance, but from an arbitrarily fixed pseudo-present of 1950-01-01 in the modern Western (Gregorian or NS) calendar. But that is the end of it's connection to that calendar system. It's the same if you use, say, the Islamic calendar. People don't like it because the name is misleading, and so "b2k" has been proposed, using 2000-01-01 in the modern Western calendar (I'm not sure if it also would use "B2k" to signify calibrated). None of this directly relates to BC/BCE reckoning. BC[E] are ranges of/between dates more narrowly (not just spans/measures of time), in a specifically backwards-order dating system which is keyed, in reverse, to the axis dividing 01-01-01 BC[E] and 01-01-01 CE/AD. Because they are not distances in time but specific dates [or approximations thereof] in a specific calendar system, they do not make much sense if you use some other system (e.g., they are ambiguous even if the Western system if the material is dependent on the Julian (OS), Alexandrian, Revised Julian, or other variants of the Western/Roman calendar system. The conversion necessity and the ambiguity is one of the reasons BP was developed and that journals have moved to using amounts/distances of time (from a known point) rather than point A to point B ranges. It's a bit like the difference between specifying a range of road between two mile markers (the numbering of which may go in either direction) while you are driving, versus specifying a distance in miles from the mile marker you are passing right this moment (without naming another mile marker by the number on it), or (to analogize BP's arbitrariness in choosing a fixed reference point in the recent-ish past) a distance from a mile marker you passed five minutes back before you pulled over, but the number of which you definitely remember.
Because of these differences, the statement '"This species lived from 300 million to 290 million years ago" is really no different from "He lived from 1900 to 1975"' is not true. They're very different, even if you make them both explicitly approximate so they are even more structurally similar (i.e. eliminate one variable). "This species lived from approximately 290 million to 300 million years ago" expresses a rough amount of time before either the real now or the pseudo-present of 1950 (depending on context, etc.), uses the logical and normal order for measurement-amount spans, and refines this with some quasi-specificity as to the approx. 10-million-year margin of error. "This species lived from 300 million to 290 million BP" is the same, except it is tethered to measuring back from 1950 for certain, and never means from the real-now of the writer/speaker (after 1950, anyway). Meanwhile, "He lived from c. 1900 to around 1975" is an (approximation-laden) point A and point B reckoning within a very specific calendar system (and on the positive, AD/CE side of its axis – it has an axis while other system does not); it is a date range (range between dates, i.e. points), not a measure of the distance in time that has passed (i.e., that is being spanned).
To complicate things more, though, the apparently disputed "MYA" (also written "Mya" or "mya", or sometimes even more confusingly re-rendered as "Myr ago" or "Myr BP"!) is another of the span/measure/distance systems, not a date range. Geologists have apparently been squabbling with astronomers (and both sectors have been among themselves) about this for at least 20+ years, though our article on these variants is a poorly written stub mostly lacking sources, so I don't trust it. Ma (our article on that is much better) is yet another, and is also inconsistent between fields and publishers, sometimes implying "Ma ago" (synonymous with "Mya") or only implying "million years" without an implied "ago", making it synonymous with "Myr", depending on context; in some uses of "Ma", only the latter sense is permitted, and if an "ago" is intended, then something else must be used, such as "Mya", or a switch to "BP" (or "bp"). And it may not be contextually clear whether all of these are tied to 1950 as the reference point, though they usually are. Probably the only reason various heads not asplode over all that mess is that these units are generally so approximate that the potential distinctions between them will be within the margin of error anyway, or at least not impede a general understanding. If one had to do careful math about them, one would have to really dig into what was intended by the writer and whether that had been affected (correctly?) by later editors normalizing to their house style sheet. Worse yet, the fact that "Mya" expands to "million years ago", and a "Ma" is sometimes also written out in words this way instead of as "mega[-]annum", conflicts with the everyday-English meaning of "years ago". While this is probably not brain-melting in a journal in which dates are consistently reckoned from 1950, the conflict apparently comes up often enough that in many cases they write it as "Million Years Ago" or "Million years ago" when not abbreviating, with this capitalization signifying a 1950 base (and possibly with the partial capitalization signifying the same but without a calibration; this is apt to vary). This is also part of why "BP" is usually rendered "Before Present" in full wording – it's capitalized and without an article, to distinguish it from casual-English "before the present" meaning the real present as of that moment.
To get back to "BC"/"BCE": There is an exact and inescapable numbering-sequence-within-the-particular-calendar-system rationale for backwards dating here: "lived from 84 to 22 BC[E]" order is logically and conventionally mandatory, for the same reason that "warmed from -30 to -17 degrees" is required below zero on a temperature scale. The only numbering (and thus point A to point B range-specifying) difference between them is that there's no year zero between BCE/BC and CE/AD, which has no consequence other than a necessity to avoid off-by-1 errors, and even that doesn't apply if the BC[E] and CE/AD boundary isn't crossed. This rationale for "from 84 to 22 BCE" order has no connection of any kind to indicating a span/measure/distance of time in a BP, Mya, and related systems, whether tied to 1950 as a reference point or not. There is no axis in these systems in which the numbering reverses. While it is fairly common in anthro/archaeo/paleo/geo/astro writing to give them in backwards order if they get back into time periods that would correspond to year-points on a BC[E] number line in the Western calendar, this is a form of hypercorrection, a bad habit that Wikipedia should not emulate. It has no logically sound basis, is outright confusing, is not consistently done in reliable sources, and I have yet to see any style guides that demand or recommend it. BC/BCE is simply different (though not unique; if you go before year 1 in the Islamic calendar, you're counting backward, and the same is true if you go earlier than year 0 in calendars that have one, like several Indic systems). To come full circle, writing "This species lived from 300 million to 290 million years ago" is an irrational numerical order that is trying hard to mimic BC[E] order for no reason at all. It would be even worse, though, to use "This species lived from 300 million years ago to 290 million years ago", using tedious redundancy to try to force an interpretation that the unit Mya is meant (and semi-presumably tied to 1950). Since Mya has no calendrical axis at which to flip, this still would not justify reversed numerical order in the measured/estimated time span. And the mental-gaming attempt fails also because the convention, to the extent there is one, is to capitalize at least "Million" and sometimes all of "Million Years Ago" when Mya is the meaning.
The summary is that BC[E] is part of a calendar system (Gregorian) with a systemically integrated axis at which the numbering system mandatorily flips, and this is not true of BP (or anything related to it, like Mya). "3200 BC[E]–2950 BC[E]" is a (probably approximated) 250-year date range, a point A to point B line on one side of an axis (the negative one; it's just conventional to not use − [minus] with them). It's a line without a zero point at the axis, and the "points" may actually be fuzzy if the dates are approximations. But "4900–5150 BP [or Mya]" is something completely different; it's a measurement span (a temporal distance) of approx. 5025 years, +/−125 years, from a fixed reference point, C, of 1950-01-01, and there is no axis in sight in this system (it's simply a count – it's positive-integer math). Thus there is no point at which these numbers would reverse counting for having gone negative. Saying/writing something like "lived 5150–4900 BP [or Mya]" is senseless. It's a confused and lazy/habitual hypercorrection that is failing to understand that this is a count of time measured in years, it's not a range between named (and negative-side-of-a-calendrical-axis) years like "lived 3200 BC[E]–2950 BC[E]". The fact that various academics in anthro/archaeo/paleo/geo/astro are much better at science than at writing clearly and at understanding why some things are written a particular way is not surprising, but it is not an excuse for Wikipedia to follow them into the error. In one sense, it's as confused/confusing as saying "I threw that rock at least 30 to 25 meters", and is not conceptually very far from the error of "Smith lost to Jones, 10–4" (in a sport where a higher score is better). More narrowly, though, this one is an error of confusing two systems (and the rationales for them and the style/order to use for them) simply because they use numbers and serve similar purposes and involve the same base unit (year, but in very different ways).
We can do a better job, and we need to. We have zillions of readers who could be confused if we don't, because they have not become habituated to mentally auto-translating the error into something sensible after years of encountering the same reasoning mistake among some of their colleagues. This is a form of MOS:JARGON issue in some senses, but also more importantly a "verifiability does not guarantee inclusion" one. We don't explicitly mention this policy in MoS discussions much (because it has more to do with adding claims to an article or creating a whole article around a claim), but it strongly infuses the entire consensus process here: The fact that a style can be attested, and even a showing of its frequency in some field or publishing sector, never forces Wikipedia to adopt it. We often reject geeky styles if they are potentially confusing, and also decline various mainstream but unencyclopedic usage, most commonly on grounds of ambiguity, inconsistent application, or other inclarity. Meanwhile, it is not plausible that, vice versa, any scientist in one of these fields who stops by our article will fail to understand what "lived 4900–5150 Mya" means, because they also regularly encounter this more sensible form, and as a class they've been arguing back and forth about it all for many years with their colleagues. — SMcCandlish☏¢ 😼 13:30, 2 September 2020 (UTC)
US non-metric units
In non-scientific articles with strong ties to the United States, the primary units are US customary (pounds, miles, feet, inches, etc.)
How can this be real? Are you condemning every non-American reader to this insufferable American system of non-metric units? Even in such articles of worldwide-fame as Boeing 777? How is this fair?--Adûnâi (talk) 22:13, 20 July 2020 (UTC)
@Adûnâi: There doesn't need to be a change to the MOS for en.wikipedia.org, but suggest consideration of an international en-int.wikipedia.org or similar, where only SI units or common metric derivatives are used. Consider 4.4% of world pop is (in theory) versed in USC units, approximately the same percentage speaks Hindi, and we wouldn't expect commonplace Hindi translations of words or concepts scattered throughout every article. As a metric person, USC *IS* another language to me. --Doctoralligator (talk) 01:48, 25 August 2020 (UTC)
@Doctoralligator: Roughly 2/3 of the world's English-as-a-first-language speakers are American, and this is the English-language Wikipedia. You really can't have an "international English" without 2/3 of the language's native speakers. --Trovatore (talk) 02:36, 25 August 2020 (UTC)
I don't know what they do over at Simple English Wikipedia, but it might not be a crazy idea for their articles to use metric-first. EEng13:34, 3 September 2020 (UTC)
@Adûnâi: It's fair because the metric equivalents are given in parentheses immediately after (if things are being done correctly). I know the mental anguish from being exposed to a different system must be great, but I have every confidence that with time and therapy, our non-American readers will be able to overcome this and lead healthy, productive lives. –Deacon Vorbis (carbon • videos) 22:40, 20 July 2020 (UTC)
(edit conflict) Calm down. It's perfectly fair, do you want to condemn Americans to learn about their own country in metric units which they may not understand? A balance has to be struck, neither side was ordained by God. Primary units of either complexion should be followed by a conversion into the other form. Is it really to hard to understand 33.25 ft (10.13 m) instead of 10.13 m (33.25 ft)? Martin of Sheffield (talk) 22:46, 20 July 2020 (UTC)
@Deacon Vorbis:@Martin of Sheffield: So, is Wikipedia an American encyclopaedia? I thought, it was an English one, an international one. Why do Americans hold special privileges? Is this some sort of gratitude for providing reliable sources and defeating Hitler?
(I'm half-joking, but truth be told, sources from the DPR of Korea cannot be cited about their own leader. Should we accommodate Juche Koreans? Only America-related articles use feet? - Only DPRK-related articles will use honourary epithets! Only Russia-related articles will use swearing. And so on.)
(On another note, the USA prides itself on being anti-racist and multicultural - from that, I could extrapolate that Americans should not impose the imperialism of their non-metric system upon others, but I won't.)--Adûnâi (talk) 03:35, 21 July 2020 (UTC)
Was considering weighing in to support you – the nonsense below about "metric imperialism" is cringey and stupid – then I saw you're a homophobic waste of oxygen. Cannot stress this enough: get to fuck. Archon 2488 (talk) 13:37, 3 August 2020 (UTC)
FYI, US customary units developed out of avoirdupois (aka "Imperial") units, and predate the metric system. If you want to abuse the term "imperialism", then it is the metric imperialists trying to impose change upon the existing system. Better by far to accept that there are several equally legitimate systems of measurement and use the appropriate one. As I said above, {{convert}} means that whatever the primary units, the converted ones are available for everyone to see. Martin of Sheffield (talk) 11:19, 21 July 2020 (UTC)
I would also add: A) This stuff is in transition; metric is used more and more in the US for various things, while the UK, Ireland, etc., still frequently used imperial units in various contexts. So, this is yet another false dichotomy argument of the kind that has gotten so tedious, both on- and off-site. B) The US is not actually the only country that doesn't [much] use the metric system. Neither do Liberia or Burma/Myanmar. The only real problem WP has is that various editors never provide conversions, leaving that to later cleanup by WP:GNOMEs who are these days too few to keep up. — SMcCandlish☏¢ 😼 02:05, 22 July 2020 (UTC)
FWIW this is obsolete information; Burma (and, to an ambiguous extent, Liberia) have since implemented metrication programs. Archon 2488 (talk) 13:32, 3 August 2020 (UTC)
Which does not mean they have succeeded yet. It can take many generations, or happen in a single generation, depending on how they go about it. — SMcCandlish☏¢ 😼 13:32, 2 September 2020 (UTC)
When I was in elementary school in 1957, around two weeks after the USSR launched Sputnik 1, our teacher taught us the metric system—and I do mean the metric system, not SI—because, she said, the US was about to adopt it. Sixty-three years later, still no joy. We are still stuck with the idiotic, math-hostile British system that the Brits had the good sense to ditch long ago.—Finell05:28, 3 August 2020 (UTC)
This is off-topic of course, but as a mathematics Ph.D. I feel someone may listen to me if I opine that there is nothing "math-hostile" about United States customary units. It is true that they are not based on the decimal system, but the decimal system is not more "mathematical" than any other.
Certain limited sorts of calculations are easier to perform in one's head using metric units, assuming one is doing arithmetic in base 10. That's about it. Once you get past really trivial stuff, you have to remember arbitrary constants to figure things out anyway (permittivity of free space, Avogadro's number, stuff like that) and at that point metric has no real advantage.
The other main advantage of metric is that you don't have lots of different units with the same name (United States quart, imperial quart, dry quart, etc). That is a genuine practical advantage. But it doesn't have much to do with mathematics. --Trovatore (talk) 05:49, 3 August 2020 (UTC)
As I read it, the point is not that SI is less hostile to physics (although, of course, it is); it is that even the vast majority of the defenders of medieval English units could not tell you whether 500 yards is greater or less than three-eighths of a mile (or, indeed, three furlongs), and if so, by how much. They don't like this to be brought up, because it undermines their (bizarre, repeated) assertions that old-school units are somehow easier and more intuitive. If these people were given long sheets of old-school British exercises (if coal costs two pounds fifteen shillings a hundredweight, how much does three long tons five hundredweight cost?) they would soon enough change their tune. Medieval English units are hostile to arithmetic intuition, not pure mathematics. Anyone opposing this is claiming to be better at doing calculations in an inscrutable mix of bases three, six, eight, twelve, fourteen, sixteen (and if we're masochistic, 1760 and 5280, and if we really want to twist the knife, 43560 and 63360) in their heads than in powers of ten. I do not believe them. Archon 2488 (talk) 13:32, 3 August 2020 (UTC)
You overstate your case somewhat. Since a furlong is 220ˣ it's pretty simple to see that three of them are 160ˣ longer than 500ˣ. I suspect that most WP editors can manage that subtraction in their heads. Even the coal example is a bit trivial: 65 x £2/15/- would only take a couple of lines. Name calling ("medieval units") is a little childish, do bear in mind that the original metric system was pretty arbitrary (the metre must be measured through Paris because Napoleon decreed it), the modern definitions are simply more precise ways of stating an approximation to the original. As I said, you overstate your case; put it more simply that we have all learnt to do arithmetic in powers of ten, so let's keep doing that and you have a good, solid point. Martin of Sheffield (talk) 13:51, 3 August 2020 (UTC)
There's also a straw man in it, in that claims that Imperial/American units are "easier" mathematically are actually rarely encountered if every made at all, yet the screed is almost entirely predicated upon such claims being the central argument. Rather, the actual argument commonly made is that the units that people have learned are more intuitive for them, regardless what those units are, and there is very little doubt this is actually true. — SMcCandlish☏¢ 😼 13:43, 2 September 2020 (UTC)
There is no realistic chance that a change to the MOS is going to come out of this discussion. The OP has been indeffed. Suggest it ends here per WP:NOTFORUM? Kahastoktalk17:01, 3 August 2020 (UTC)
It'll peter out on its own and get archived rapidly when it does. While there's lots of posturing, this has not been entirely off-topic, since it speaks to questions like why MoS should or should not favor one particular system entirely and discourage others, or favor one as the system to convert from in every case, or continue to leave it up to editorial judgement as to which to/from conversion order to use based on the context. — SMcCandlish☏¢ 😼 13:43, 2 September 2020 (UTC)
By default MOS stuff applies as equally to article titles as to content proper, and in fact I'm pretty sure a question just like yours was the genesis of the big discussion some years ago that led to a change in the two-digit–four-digit guideline. Pinging SMcCandlish to (a) answer your question and (b) review the changes made to the ranges provosions since the start of this calendar year, to be sure talk consensus was properly implemented and no inadvertent changes in meaning snuck in. EEng19:37, 1 September 2020 (UTC)
Yes, this applies to titles. MOS:DATERANGE even explicitly addresses titles. This particular sort of YYYY–YYYY versus YYYY–YY question has been fought over and re-fought so many times I've lost track. I had to go look it up at MOS:DATERANGE in detail to be certain it was as I remembered it (it mostly was). Here's the summary:
Use YYYY–YYYY unless there's one of three specific reasons to use YYYY–YY: for a span of two (not more than two) consecutive years; saving space in a cramped table (if done consistently in the date column) or infobox parameter; or "matching the established convention of reliable sources" [I think that meant "in" not "of"] pertaining to a particular topic (e.g. if underwater blindfolded billiards competition seasons are almost universally named in YYYY–YY form, then WP would likely follow that form for that sport's seasons).
There are counter-exceptions to those exceptions: Don't use YYYY–YY across a century boundary (even for consecutive years); don't use the shortened format for first-millennium years; and you can't "get away with" YYYY–YY format for a two-year span case if the same context is already using YYYY–YYYY dates (in particular, do not juxtapose YYYY–YYYY and YYYY–YY near each other in the same article text, nor use YYYY–YYYY for some article titles but YYYY–YY for others among a related cluster of articles).
Thus, Wales national football team results 1876–99 and everything else in its category should move to Wales national football team results 1876–1899, etc., because it is not a two-year span. Even if some articles in that set do cover two year spans, they should use YYYY–YYYY format for consistency with the rest of them. And "established convention of reliable sources" cannot apply here, because these are not named sports seasons (much less ones with a proven YYYY–YY convention), but are arbitrary ranges picked by WP editors for a WP:LONGLIST split for article-length reasons. In a similar category for a different sport that was all two-year spans, they would also need to use YYYY–YYYY in most cases, because they'd probably eventually cross a century boundary which requires YYYY–YYYY, which would then require the rest of them to be YYYY–YYYY to be consistent, and in most cases it would not be likely that a YYYY–YY convention could be proven in the first place. Anyway, titles consistency rules on this aren't even a MoS-originating factor, but derived from WP:CONSISTENT policy in WP:AT; MOSNUM is just sensibly agreeing with the policy and explaining how it applies to date ranges in titles.
In practical terms, we mostly just permit YYYY–YY for cramped tables. To the extent it's ever used for other reasons, it's apt to have to change, either for reasons like the ones just covered, or when (in-article) the text is edited later and now an old YYYY–YY has ended up in the same paragraph or so as some new YYYY–YYYY material that isn't eligible for YYYY–YY shortening. So, it's best to just use YYYY–YYYY from the start, even if it looks a little redundant in some particular case. This is a lot like MOS:US: While "U.S." is sometimes permissible, various rules like "use 'US' in the same context as 'UK', 'PRC', etc." make long-term survival of the optional variant essentially impossible.
PS: One weird thing is that one of the original and most powerful reasons for going with YYYY–YYYY by default was that YYYY–YY is indistinguishable from YYYY-MM ISO dates in many fonts, for any last-two digits from 01 to 12. That was in the guideline for a long time, as another exception-to-the-exceptions and needs to be restored, since it has much to do with the reason we ever decided this needed to be addressed in MOS:NUM in the first place. — SMcCandlish☏¢ 😼 08:02, 2 September 2020 (UTC)
At Feed-in tariff I came across "c€" as a unit of currency, apparently meaning hundredths of a Euro. I'm tempted to change all these to just "€" with the appropriate adjustment to the decimal point. But maybe it's a regional or cultural thing I'm not aware of? I don't want to insult anyone. GA-RT-22 (talk) 00:30, 9 August 2020 (UTC)
According to the Euro article, 'c' is used for the cent (€0.01). But this is confusing if an article also mentions USD, AUD, etc. There is no such currency symbol as 'c€'. In my opinion, your changes are correct. Stepho talk00:40, 9 August 2020 (UTC)
Actually, that article is exactly one of the places I think use of such a convention is justified, because it contains extensive examples of pricing of a commodity (electrical energy) which is priced in 20 or so US cents, or hundredths of a euro. Whether that particular symbol convention is the right one, I don't know. EEng02:02, 9 August 2020 (UTC)
If you need a way of distinguishing between one hundredth of a US dollar and one hundredth of a euro, the international standard symbols are cUSD for the former and cEUR for the latter. Dondervogel 2 (talk) 13:37, 9 August 2020 (UTC)
Yeah but (a) MOS wants us not to use the three-letter currency codes (at least for dollars and euros) and (b) by the time you say cUSD 5 you'd be better off saying $.05. I have to say that looks pretty good after all and I think the OP was right to think everything should be changed to that kind of format. EEng18:32, 9 August 2020 (UTC)
At first occurrence, though, we'd probably use US$0.05, unless the context made it abundantly clear already that the US dollar was the dollar under discussion. Dollar (and other currency) decimal-fractional amounts are usually given with a leading zero for clarity, since it's easy to miss the "." next to a currency symbol. — SMcCandlish☏¢ 😼 22:56, 25 August 2020 (UTC)
At first occurrence, though, we'd probably use US$0.05, unless the context made it abundantly clear – That's not true, actually. We assume the reader will interpret $ as US$ unless there's some reason to think there might be confusion for some reason. EEng05:30, 30 August 2020 (UTC)
Actually, I just checked and it looks like this assumption was added sometime in the last 7 years, but I don't know when or by whom. EEng05:19, 14 September 2020 (UTC)
It is said: "Generally, conversions to and from metric units and US or imperial units should be provided". What about long lists like List of highest mountains of Switzerland? A while ago it did not have unit conversions (see this version), and I think it was easier (or less hard) to read than now. Should we add an exception for such lists? Zach(Talk)
I know in very long lists (1000s of items) you can start to reach template limits in general, not just with conversion values (like date and reference templates). So at some point if the list isn't split you may have to drop the templates and hardcode valus or the like. --Masem (t) 18:35, 13 September 2020 (UTC)
Yes, the list should have unit conversions. But that article is not a good example of how to do it. I suggest that you look at options |disp=table and |disp=tablecen in {{convert}}, which will put the converted data into new columns. Kahastoktalk18:45, 13 September 2020 (UTC)
Just to note, to "hardcode" the conversions you don't have to manually type them in, or even copy-paste them from the rendered page; you can just WP:SUBST them. EEng01:50, 14 September 2020 (UTC)
Per MOS:NUMERAL, Integers greater than nine expressible in one or two words may be expressed either in numerals or in words (16 or sixteen, 84 or eighty-four, 200 or two hundred). Is this guideline still applicable? User:Scoop100 has made several changes from numerals to words yesterday/today, with "integers MoS" as the only explanation. See here for.several examples. As far as I can tell, there was no need to change any of these instances from numerals to words per the guidelines. Have I missed something? BilCat (talk) 05:35, 4 September 2020 (UTC)
The keyword is "may". Both forms are valid. Therefore, the original form was valid under MOS. When both forms are valid we generally refrain from flip-flopping between the 2 forms. SeeMOS:STYLERET. Stepho talk20:04, 4 September 2020 (UTC)
Yeah, but formulations such as They ordered 200 C57s that year are best reworded as two hundred C57s so in this case words and digits aren't really on the same footing. EEng20:21, 4 September 2020 (UTC)
That could go either way. Were that the only type of change they made, I wouldn't have reverted it, but it wasn't. BilCat (talk) 21:02, 4 September 2020 (UTC)
Also relevant to the matter of "numerals v. words" is the fact that, as a proper/common name, C-57 (singular) or C-57s (plural) should always have a hyphen.
That being the case, ...200 C-57s... will always be my preference. On an aesthetic level, I have no idea why anyone would consider the word form "best" to be best in such a context. But to each their own.
I apply flexibility (see EEng's example above). And I must admit to despising the general rule against numerals at the start of sentences. "A majority (62%) supported the motion." Yuck. Tony(talk)07:56, 20 September 2020 (UTC)
Because mdy and dmy are on equal standing in Wikipedia, for topics with no strong ties to any particular English-speaking country, either may be used, and whichever is used first is retained. Jc3s5h (talk) 10:52, 8 September 2020 (UTC)
The "first main contributor" rule applies as a default, but it is always possible to change the format later on if a consensus for this can be established on the talk page of the corresponding article. So, you would have to initiate your question there, not here. Given that the topic has no ties to the US, chances aren't bad that a request to change the format would be successful. --Matthiaspaul (talk) 14:06, 9 September 2020 (UTC)
Given that the topic has no ties to the UK, there seems to be no reason beyond personal preference (not a good reason) to change the date format from the first main contributor's MDY format, which is also the date format used by most native speakers of English. Doremo (talk) 14:31, 9 September 2020 (UTC)
Rearrange columns in "Unacceptable date formats" table
There is a table at MOS:DATESNO captioned Unacceptable date formats.... I propose to swap the first two columns, so that "Acceptable" will be the first column, and "Unacceptable" the second. My rationale is primarily that the comments (3rd column) appear to relate to the contents of the 1st column (at least, that's how the rows line up). I think it would be better to have the current 2nd column at the front and out of the way of the naughty couple, so that the comments and the "Unacceptable" examples can get to know each other better, order a couple of drinks, etc. Secondarily, my proposed change would put the "good" examples toward the front, where maybe they'll be seen "sooner". I could not find anything in the archive where this had been discussed before, but maybe we have good reasons for having the "Acceptable" in the middle maybe as a chaperone?.
While I understand the impulse to improve the moral character of errant formats by bringing them into contact with the better strata of society, I believe it's just another do-gooder liberal pie-in-the-sky piece of social engineering. This is the Unacceptable date formats table, so it starts by enumerating the various unacceptable formats, then (moving left to right) guides the errant editor from the bad format to the correct format, and explains why. Perfectly logical (and rather elegantly done in some problematic overlapping cases, if I do say so myself). To reverse the columns would turn the table's purpose on its head. EEng17:43, 18 September 2020 (UTC)
Thanks for your response, EEng. That it's a table of Unacceptables is an exceedingly good point, which I failed to realize. Then, what do you think about moving the "Acceptables" over to column 3 (not only to protect their virtue from association with the Unacceptables)? Or would that be just as hard to read, or illogical? — JohnFromPinckney (talk)20:12, 19 September 2020 (UTC)
The Units of Measurement section mandates US and U.K. usage where there are “strong ties” with those countries in non-scientific articles. No other countries are singled out in this way. The effect of this is that where there may be strong ties to a third country the US/UK connection trumps that. It seems anomalous. Surely it should be amended to refer to where the strongest ties are to the US/UK? A current example of where this is in issue is on the talk page of Battle of Crecy. DeCausa (talk) 10:03, 29 August 2020 (UTC)
This is not the intended reading of the guideline. The intended reading of the guideline is that an article with strong ties to the US but stronger ties to Australia would in most cases be expected to use SI units based on the ties to Australia.
My preferred solution would be to establish more clearly the general principle that the units to be used in any non-scientific article with strong ties to a country are the units used in that country, and then to clarify what that means for the US and UK, but I suspect it'll be hard to get consensus for that.
Failing that, something like this:
In all other articles, including articles with strong ties to other countries, the primary units chosen will be SI units...
might make it clearer that there is a balance to be struck through talk page consensus.
(Aside: in historical articles, there is some value in considering whether there is good reason to overrule the guideline per the standard rule that the MOS is to be treated with common sense and occasional exceptions. That goes particularly when considering the Victorian or early 20th century history of a Commonwealth country. Obviously this comes down to talk page consensus, and I'm not sure it's a case I'd make at Battle of Crecy.) Kahastoktalk10:37, 29 August 2020 (UTC)
OK. I've tried creating a proposal in my sandbox as to how it would look. I've deliberately aimed not to change the (intended) advice, only the structure of the section as described to make the intended advice clearer. What do you think? Kahastoktalk12:00, 29 August 2020 (UTC)
Please lay out here what exactly you're proposing to change, with old and new text or strikeout insert. EEng14:45, 29 August 2020 (UTC)
My original query above still stands. I don’t know whether Kahastok’s interpretation has consensus support or not - certainly most users at the talk page/FA of Battle of Crecy have’t taken that view. A further point is that the section begins “The choice of primary units depends on the circumstances, and should respect the principle of strong national ties“. That links through to a section that makes it clear it’s only referring to ties to English-speaking countries. Altogether WP:UNIT plus that seems to make it clear that where the UK or the US have a strong tie to a an article the strength of any tie, even if stronger, to a non-English speaking country is irrelevan tomunits of measurement. That makes sense in the context of variety of English to be used in the article (which was presumably what was in the mind of those who wrote the “strong national ties” principle) - but not to units of measurement, IMHO. DeCausa (talk) 20:41, 29 August 2020 (UTC)
If we use the word "strongest" then we will have editors arguing over whether a country has 1.1% ties to US and 1.2% ties to UK (which of course really means no strong ties to either). If there are ties to both the US and UK then either one of them is weak or both of them is weak. Eg. My country of Australia has very strong ties to the UK and weak ties to the US, so for most things we follow the UK. Stepho talk23:40, 29 August 2020 (UTC)
See also "One of Our 50 Is Missing" (this is 20 years or so of recent examples, following on from a book by this title published in the 1980s, itself based on an earlier column that ran for years). Back in the day, I used to have a joke "New Mexico Passport" because people were so often sure it wasn't part of the US. — SMcCandlish☏¢ 😼 09:28, 2 September 2020 (UTC)
Steph-wrs, that’s not the issue. The scenario is article with strong ties to the UK and, say, stronger ties to Italy. The way WP:UNIT works that equals miles not km. Ties to UK (or US) trumps a non English speaking country’s ties no matter how strong they are. Is that what’s intended? DeCausa (talk) 07:12, 30 August 2020 (UTC)
I noticed that all the battles happened in Italy during the Second World War are customary first, which seems weird to me since I've never read distances between Italian towns or cities in miles instead of kilometres.--Carnby (talk) 11:29, 30 August 2020 (UTC)
DeCausa: Yes, I know you are trying to choose between 2 strong ties. However, your proposal to replace "strong ties" with "strongest ties" will eventually be interpreted by somebody as also allowing them to choose which is the strongest of any 2 ties - including choosing between 2 weak ties. Human nature - it will happen. Also, if there are 2 "strong" ties then that really shows that neither really is a strong tie. If either tie was strong then it would dominate over the other and we would only have 1 strong tie. I would be more tempted to replace "strong tie" with "dominating tie". Stepho talk22:25, 31 August 2020 (UTC)
Wouldn't WP:RETAIN apply in cases where more than country has a claim to strong national ties? If so, there's no need to change the wording to "strongest", but rather emphasize that RETAIN applies. BilCat (talk) 22:32, 31 August 2020 (UTC)
Yep. So many times some "strong tie" claim can be made that contradicts another, and it would devolve into endless bickering over cherry-picked evidence, etc. There are really obvious cases, e.g. the US has had no colonies in Africa other than Liberia, while the UK has had little impact on Okinawa or Guam. But in innumerable cases, there will be competing claims based on length of historical contact, on post—Industrial Revolution influence on economy, on whether the governmental structure of the place is closer to the UK parliamentary or US congressional model, on which country had more influence on this third country's constitution, on the fine points of the dialectal English spoken there if it remains a minority language in the third country, on present-day diplomatic relations, etc., etc., etc. We have RETAIN for good reason. — SMcCandlish☏¢ 😼 09:28, 2 September 2020 (UTC)
Agreed. Whenever we think we have 2 competing strong ties - we really have 2 competing weak ties. A strong tie must totally dominate over other ties. Stepho talk21:26, 2 September 2020 (UTC)
I’m not entirely sure that the above posts are getting what my point was - but I could well be wrong. The point I’m making isn’t about US v UK. It’s really about querying whether it’s appropriate to see units of measurement as part of the whole ENGVAR thing, and therefore whether UK (or US) units of measurement should trump the usage in a more relevant non-English speaking third country. Putting it simply: (1) an article about a French, Italian, Russian etc topic should use km not miles (2) why should a French, Italian, or Russian topic be in miles because there also happens to be a “strong tie” with either the U.K. or US? WP:UNIT doesn’t allow for Siege of Orléans to be in km, for example - where WP:RETAIN doesn’t apply by the way because it uses km once and miles once! DeCausa (talk) 22:13, 2 September 2020 (UTC)
In all cases, metric measurements are provided. The "primary" units are simply the ones listed first. The reason for this is verifiability, because old sources often use old measurements, and the measurements can be compared with the source. In many cases, the sources use a mix of old an present-day measurements, and the "primary" is used for consistent presentation. Hawkeye7(discuss)04:20, 29 September 2020 (UTC)
The table on "General guidelines on use of units" is unclear to my gusto. Is the structure of the field wanted as it is ("For areas or volumes only, square or cubic may be used (before the unit being modified"), covering half of the green example ("ten metres per second squared") and a second green example ("tons per square mile"). Or is it a misalignment, and this guideline only refer to US units as in "sq or cu may be used with US customary or imperial units, but not with SI units."? --Gunnar (talk) 05:55, 28 September 2020 (UTC)
No, the boundaries of the cell do not support the message "For areas or volumes only, ..". This rule, which is an exception should only be in line with the relevant example (square mile). The other examples above are explaining "Or use squared or cubed (after the unit being modified)." But there is a mixup of guidelines and matching examples by inappropriate horizontal lines. --Gunnar (talk) 13:49, 30 September 2020 (UTC)
indicate a preferred option
"Indicate a product of unit names with either a space (preferred) or a hyphen", Reference: Thompson, Ambler; Taylor, Barry N. (2008). Guide for the Use of the International System of Units (SI). NIST Special Publication 811(PDF). Gaithersburg, MD: National Institute of Standards and Technology. p. 31. When the name of a derived unit formed from other units by multiplication is spelled out, a space, which is preferred by Ref. [6] and this Guide, or a hyphen is used to separate the names of the individual units. and ISO/IEC 80000-1:2009 Quantities and units — Part 1: General; Clause 7.2.4 English names of compound units: "In the English language, the name of the product of two units is the concatenation of the two names, separated by a space." --Gunnar (talk) 05:48, 25 September 2020 (UTC)
I don't see any reason for the MoS to explicitly prefer one style over another. The SI brochure allows both hyphen and space, with no preference indicated (section 5.3: "When the name of a derived unit is formed from the names of individual units by juxtaposition, either a space or a hyphen is used to separate the names of the individual units.").
Further, Wikipedia is written for a general audience and does not necessarily follow the practices of specialised publications, as outlined in MOS:FAQ ("Why doesn't the Manual of Style always follow specialized practice?"). If anything, a hyphen might make it easier for a non-technical reader to recognise a compound unit compared to a space, although I'm not suggesting it as a preferred style. The guideline regarding compound units seems fine as is. Indrek (talk) 06:40, 25 September 2020 (UTC)
The change the OP is proposing would require a full discussion, which I predict would be prolonged. See, for example, WT:Manual_of_Style/Dates_and_numbers/Archive_147#Kilowatt-hour (which concerns unit symbols instead of unit names -- names are what the OP's talking about). 07:13, 25 September 2020 (UTC) — Preceding unsigned comment added by EEng (talk • contribs)
A prolonged and full discussion is fine for me. This is nothing really urgent and we are not in an emergency room where patients may die if we don't act fast.
The addition of a "preferred" tag can be justified by the fact that indeed there is a preference by a few documents or institutions such as NIST, https://standards.ieee.org/standard/SI10-2002.html, ISO/IEC 80000 which are relevant in the scientific and technical world. And by the way, even though BIPM does not repeat the preference explicitly, the SI brochure does not use the hyphen but the space for forming a product of two units such as "newton meter" or "pascal second". Therefore we could analyse with statistical tests if this was purely coincidental or on purpose - I personally would rather bet on the second option. --Gunnar (talk) 14:50, 30 September 2020 (UTC)
use of modal verbs
I find it a little bit confusing that "should" indicates a requirement. This is a very soft verb. In standardization the 4 following modal verbs are used according to ISO/IEC Directives Part 2: Principles and rules for the structure and drafting of ISO and IEC documents, Clause 7 Verbal forms for expressions of provisions, p. 29ff.
@Izno: If "should" in the overleaf text is meant not as a requirement but a recommendation, we should say so. Many people misunderstand "should" as a polite but nevertheless hard rule. If the guidelines are meant to be non-negotiable, then it is clearer to mark them with a "shall". --Gunnar (talk) 06:03, 28 September 2020 (UTC)
"If I were you, I should stop interfering" [even when you are right :-) ]. I rewrote my comment too many times and should (sic) have omitted the 'and "should"' in the final version. Quote is Noel Coward, I think, certainly I doubt that anyone has used that construction without tongue in cheek since about 1950. --John Maynard Friedman (talk) 13:23, 28 September 2020 (UTC)
MUST, REQUIRED, SHALL, MUST NOT and SHALL NOT are all mandatory (see §§1–2).
SHOULD, RECOMMENDED, SHOULD NOT and NOT RECOMMENDED indicate that there may be valid reasons in particular circumstances to depart from the norm, but normally they should be followed (see §§3–4).
You should be aware that we are not the IETF nor any of a number of other standards-making/law-making/using organizations. Should is often used because there are often exceptions, and sometimes you can ignore everything. Very little on Wikipedia even requires the use of a must or shall in guideline or in policy. You probably need to get a bit more used to how policies and guidelines are written, worded, and used before pronouncing how these documents should be written if the only objection you have to the word should is that its use does not always jive with those other organizations.... --Izno (talk) 00:14, 29 September 2020 (UTC)
The ISO/IEC directives about the different modal verbs (clause 7) explain, why "must" is not used as a synonym for a requirement. Other synonyms for "shall" are used such as is to, is required to, it is required that, has to, only ... is permitted, it is necessary. For the purpose of clarity - even if the linguistic quality is getting monotone - people stick to the shall / should / may / can pattern. Must is considered as a requirement too, but these are external requirements that are not given by the document itself. A "must" states a matter of fact, as given in clause 7.6, page 32:
The verbal form shown in Table 7 shall be used to indicate constraints or obligations defined outside the document.
EXAMPLE 1 Particular conditions existing in a country: Because Japan is a seismically active country, all buildings must be earthquake-resistant.
EXAMPLE 2 A law of nature: All fish must maintain a balance of salt and water in their bodies to stay healthy.
Do not use "must" as an alternative for "shall". This avoids confusion between the requirements of a document and external constraints (see 7.2).
Regarding Izno's remark, I don't agree that Wikipedia is no standards-making organisation. Wikipedia has it own set of rules (standards) and there are also processes how to maintain and enforce these rules. I just wanted to make clear that there is a difference between requirements and recommendations and that both the readers and the writers of Wikipedia rules are aware of the difference. --Gunnar (talk) 15:36, 30 September 2020 (UTC)
examples
@EEng: Referring to comment: "unnecessary (the two miles/Miles examples are paired in the same cell) and one of your new examples is too wide and wraps, which is bad)" The structure of the table is as follows: first there is the guideline, then there is a good example followed by a bad example (including multiple examples in the same row). Therefore: the good example in the above case is missing (gallons), as well as the bad example (miles). There were two good examples for miles to show that the second sentence is fine (except: where any word would be capitalized) "He walked several miles. Miles of trenches were dug." The wrapping is only editorial - any ideas how to fix it? --Gunnar (talk) 05:09, 28 September 2020 (UTC)
As it happens I am the primary architect of the format, organization, and presentation (but not the guideline content) of pretty much the entire page, including most of the examples (and if memory serves, pretty much all the examples in the table to which you refer). So if I may speak with some authority, the structure of the table is not as you describe it. The structure of the table is: first there's a guideline, then there are illustrative examples arranged in whatever way best serves to illustrate the guideline (and occassionally to subtly inform or warn the reader on some other related point as well); examples often take the form of a "good" paired with a "bad", but not always. In the instant case, there two "good" examples using miles, one showing appropriate usage of Miles (capped) and one showing appropriate use of miles (uncapped), and they are (of course) both in the "good" column. I quite intentionally used different units (quarts/gallons) to illustrate bad usage, so as not to intrude on the mutual affinity of the miles examples. EEng11:51, 28 September 2020 (UTC)
I reformatted it in the same way two lines below ("Write unit names and symbols in upright (roman) type, except where emphasizing in context."): first two examples (green and brown each), and in a separate line the exception (which has no don't do example). --Gunnar (talk) 14:20, 30 September 2020 (UTC)
Maybe my eyes glazed over and I can't find it in the MOS, but how do we treat the presentation of thousands in prose in the following scenario:
The series received 104 thousand viewers on its premiere.
or
The series received 104k viewers on its premiere.
The instructions for millions seems to suggest we go: "The series received 104 million viewers on its premiere, and 99M for its second episode." So for thousands would it be:
The series received 104 thousand viewers on its premiere, and 99K for its second episode.
I think the allowance in MOS for M/bn (it's at MOS:BILLION) is primarily for currencies, and I wouldn't personally find 'k' to be any more formal and idiomatic outside that context... (unless in the context of SI and that's a different ballpark anyway). --Izno (talk) 21:58, 5 November 2020 (UTC)
(edit conflict) If I were doing it I'd avoid using "k" as shorthand for "thousand". It's journalistic shorthand and not really encyclopedic in tone. "M" is an abbreviation for "million" (not mega) so does make sense, but I'd still consider it poor style in running prose. Certainly though don't use "K". It's not official SI and worse is often used for kibi- so your 99 thousand looks like 101376! Martin of Sheffield (talk) 22:03, 5 November 2020 (UTC)
Request date format change for U.S. military related articles to the American format
I had some questions which can be seen in an article's discussion. It's a brief discussion, with only a few editors commenting so far, but the answers seem to be unsatisfactory as they all point back to some "consensus." However, from the links in the discussion, this guideline needs to be reviewed, updated, and hopefully changed. --Light show (talk) 23:35, 30 August 2020 (UTC)
Like it or not, that is one of the compromises Wikipedia lives with. If I were king, it would be different, but I'm not and I'm glad. SchreiberBike | ⌨ 00:58, 31 August 2020 (UTC)
The only relevant link that Bilcat pointed to was WP:MILFORMAT, basically a decision made by consensus, but seemingly without any rationale. If some rationale were made, one way or the other, it would most likely suggest the opposite of what the consensus decided. For instance, someone might simply ask why an American-founded publication, with its HQ and all relevant offices located in the U.S., and which is read mostly by Americans, should use a British date format rarely, if ever used, in U.S. publications.
In fact, even if, as is likely, most of those who voted to require the British date format for U.S. military-related articles, happened to be British, that would not be a rationale. If anything, it would imply a NPOV question. In any case, the current guideline seems to directly contradict Date and time notation in the United States, which states, "The United States military normally uses the "dd mmm yyyy" format for correspondence. The common month-day-year format is used when corresponding with civilians." That statement is even sourced. Since this is a general encyclopedia read by the general public, why insist on the U.S. military's internal communication system, which BTW is usually confidential?
Support. Despite pointing out the current guideline, I'm not a fan of it. Wikipedia is not a DOD publication, there's no reason to mimic DOD usage. Even military specialist publications like Stars and Stripes and Military Times, let alone general interest newspapers, don't copy the style. As Wikipedia is a general interest publication, we should write for a general audience in line with the general principles of WP:DATEVAR, not indulge in a special pleading. oknazevad (talk) 02:27, 31 August 2020 (UTC)
Until this one, it had been 182 days since the outbreak of the most recent dispute over date formats.
Oppose Can we PLEASE just leave this alone? Does it really matter? Isn't life short enough as it is? EEng02:55, 31 August 2020 (UTC)
Oppose less on principle, and more on the practical manners of having to overhaul literally every single U.S. military article on Wikipedia. I’m not sure the benefit outweighs the work it would cause. Garuda28 (talk) 04:30, 31 August 2020 (UTC)
Really, it's just so trivial. It's not like military articles are currently in a lunar calendar and no one knows that they're talking about. If we were starting from scratch I'd be totally behind having one less special case in the guidelines. But we're not starting from scratch and changing is just not worth the fuss. EEng04:38, 31 August 2020 (UTC)
Oppose Like EEng, if we were starting from scratch, I'd be behind one less special format in Wikipedia and insist on the "dd mmm yyyy" format everywhere. But it's too late now. Hawkeye7(discuss)05:55, 31 August 2020 (UTC)
I don't know whether I am supporting or opposing (what change is proposed?) but it's silly having a different date format for each eventuality. There should be just one date format that all articles would adhere too. Dondervogel 2 (talk) 08:25, 31 August 2020 (UTC)
LOL. That would set the cat among the pigeons. More seriously it would need to be either mmm dd, yyyy or dd mmm yyyy, because 99.9 % of readers can be assumed to be familiar with both. Why not just toss a coin? Dondervogel 2 (talk) 09:30, 1 September 2020 (UTC)
Oppose There is no good reason to expend the effort that would be required to implement this change in view of the benefit [sic] it would bestow. Given the fourth day before the Nones of September. --Lineagegeek (talk) 16:05, 1 September 2020 (UTC)
While we don't give much stock to effort-related arguments (WP:EFFORT and WP:NOEFFORT), something can be said against wasting volunteer time and attention on making a trivial change across zillions of pages without qualitatively and objectively improving the content; see WP:MEATBOT. Regardless, your effort-based argument applies equally well in the opposite direction: we shouldn't avoid making guideline-non-compliant pages compliant over time. We also have to remember that no editors are required to read and adhere to any of MoS or any other guideline before editing (see the WP:EDITING policy and related pages), and many of them do not. Consequently, many articles will be written and re-edited later using whatever style a particular editor is most familiar with. MoS (like all the content-focused rather than behavior-norms guidelines) exist primarily for WP:GNOMEs as reference material while doing post hoc cleanup, and for settling recurrent tedious arguments. The EDITING factor is also one of the reasons we have the otherwise-invisible "Use X English" and "Use Y dates" templates for the top of the wikicode, to try to gently steer editors into complying with an established style in the article from the get-go rather that making us have to go back and clean it up later. Obedience is not required though, as long as one is inserting actually encyclopedic material with proper sourcing. (It would be disruptive, though, to keep modifying extant material to make it non-compliant, and especially to use WP:POINTy reverting to thwart the efforts of others to make extant material guideline-compliant – regardless what the guideline is. People have actually been sanctioned for patterns of behavior like that (mostly for PoV-pushing variants of this, but sometimes also for just style axe-grinding). — SMcCandlish☏¢ 😼 09:12, 2 September 2020 (UTC)
I don't know what the second half of your screed means, but the fact that there is some work involved (I'm not sure how much, because there are many U.S. military articles that follow the DMY format already) shouldn't mean we can't make this change. Surely there was considerable work involved in removing commas before suffixes and many of the other trivialities I've seen you support over the years, but that didn't stop you then. And, as I mentioned below, the "it's too trivial" argument is amusing. If it is so trivial, why bother opposing it. -- Calidum15:05, 15 September 2020 (UTC)
Oppose change. I agree with SchreiberBike, EEng, Hawkeye7, et al. If I could magically have my way, I would (despite being American) impose "31 August 2020" site-wide as a unitary standard, for simplicity and because it's the dominant usage in English, globally. But that's just a fantasy. I've said many times that MoS is a very, very hard-won series of compromises, the value in which is the stability it provides in giving us a set of rules that we agree are the rules we're using (and this is more important the older WP becomes, the more articles we have, the thinner our editorial base is stretched, and the wider our readership grows). My sports metaphor is that if you've showed up to play football, you play by the rulebook even if you wish some of the rules were different. You don't decide you'd rather use some basketball rules on the football field. And the players do not stand around for hours on the pitch arguing about why some rules should change, they get on with the game or the audience boos them and goes home. In all of our guidelines and policies, 0% of the rules have support from 100% of editors, and 0% of editors believe that 100% of the rules are perfect. It is the nature of compromise that the result is "what we can live with", not what any particular one of us thinks is ideal. If this were a new site, there are at least 50 things I would seek to change in MoS, and they're the same things I would have changed 15 years ago when I first got here. After intuiting that MoS's value is in providing stability for readers (and, internally, for cleanup and for dispute resolution), not in which exact style nitpicks it favors, I've been strongly resistant to most "wouldn't it be better if ..." changes to MoS that are not addressing an actual problem that is worse that the problems the proposed change would cause. — SMcCandlish☏¢ 😼 09:12, 2 September 2020 (UTC)
Comment. Since WP is an encyclopedia, maybe a look at some other well-known encyclopedia might be useful. For example: (from the printed preface, page X)
This Eleventh Edition of the Encyclopedia Britannica is now, therefore, offered to the public by the University of Cambridge in the hope and belief that it will be found to be a trustworthy guide to sound learning, and an instrument of culture of world-wide influence.
Per WP:STRONGNAT, and the fact that none of the Opposers said that it should be changed, ignored, or was in fact wrong, it appears that it is still the guideline to follow. The military format is used for military correspondence, not for general readership, per source, "The common month-day-year format is used when corresponding with civilians." The Date format by country article also has m-d-y.
It also seems that none of the five Opposers actually opposed the American usage per the guidelines, but felt that it would be too much effort to fix, or that life is too short. However, a casual browsing of some articles noted above shows that it might be close to half for either format, so that rationale doesn't help fix the problem. The three Supporters all did have solid reasons. One editor was neutral, and SchreiberBike implied that the British format for the U.S. military was based on some unexplained "compromise," although he would change it if he were king.
While it's unlikely we'll ever be able to change all the American military articles to the American format, my suggestion is to allow anyone who wants to change the format based on Strongnat be allowed to do so since there is no reason to object. --Light show (talk) 03:29, 14 September 2020 (UTC)
Off topic, maybe, but my guess as to why the d-m-y format took hold, was because it was an abbreviated form of the common way dates were written, using prose format. Such as "The thirteenth day of September..." I looked back at a number of pre-American documents and handwritten letters and they all used that format. My guess is the new abbreviated form just removed the words "the" and "of." It does sound natural in speaking to say "the thirteenth of September." But saying the date as "thirteen September," sounds odd IMO. --Light show (talk) 03:48, 14 September 2020 (UTC)
When people on one side of a discussion start trying to claim things about the strength of the opposition and subsequently summarize the discussion as in favor of their side, they start looking like they've got a horse to beat. If you believe the practice of American military articles taking DMY should be changed, you can get a well-advertised RFC together. I can predict what the outcome will be. --Izno (talk) 03:50, 14 September 2020 (UTC)
@Light show: i would suggest we get someone neutral to evaluate the merits of those arguments, since I don’t think either of us are impartial in evaluating this manner. If this is really something you want to continue to press, I’d suggest starting an RfC. Otherwise, I don’t see any consensus or appetite for it and I’d expect this same debate will be seen on many article talk pages, with likely the same outcome.
I’d also like to note that WP:MILFORMAT which Wp:STRONGNAT references, supports the default position of DDMMYYYY for U.S. military articles. “ In some topic areas, the customary format differs from the usual national one: for example, articles on the modern US military, including US military biographical articles, use day-before-month, in accordance with US military usage.“ I wish I realized this earlier and brought it up. It could have saved us some of this debate. I’m also just relaxing @BilCat: did bring it up on the article page. Either way, to change that we’d need an RfC, which would likely go the way this did. Garuda28 (talk) 04:11, 14 September 2020 (UTC)
Understood. It was already mentioned up top that within the military there are two formats used: d-m-y for internal correspondence or m-d-y for civilian use. It seems BilCat wasn't aware of that when we discussed it. That's stated in Date and time notation in the United States, along with a cite to the Department of the Navy Correspondence Manual, which I just confirmed. It even includes typed examples. Since Strongnat was apparently only based on a consensus, but with no supporting rationale, I'm not sure what to ask with an RfC. Even the articles of military biographies and departments rely on citations using m-d-y. What kind of neutral question can be asked with an RfC under these circumstances?--Light show (talk) 05:27, 14 September 2020 (UTC)
It could be as simple as "Should WP:MILFORMAT, which links to the paragraph 'In some topic areas, the customary format differs from the usual national one: for example, articles on the modern US military, including US military biographical articles, use day-before-month, in accordance with US military usage.' be removed?" I'm not aware of any other "topic areas" where the format differs, but surely someone will enlighten me. SchreiberBike | ⌨ 05:40, 14 September 2020 (UTC)
Take typical non-bio articles like United States Space Force or Air Force Space Command. The sources use m-d-y. It's an article for the general public. In addition, when the date for a source was written, it was converted to d-m-y, which seems to go against guidelines. In any case, stating that "US military biographical articles, use day-before-month, in accordance with US military usage," is incorrect. --Light show (talk) 06:03, 14 September 2020 (UTC)
There is a strong rationale for favouring the d-m-y format, which is widely used throughout the world, including the United States, precisely why it is used by the US military. It is logical, and does not require the use commas. Less prone to transcription errors. It matches the sources, which means that no (error prone) mental effort is needed to convert from one format to another. It facilitates cutting and pasting from PD sources (how we got here in the first place) and copying (mainly references) within Wikipedia. There is no reason for ever using the archaic m-d-y format, except that it is too much effort to change now. Arguments in favour of it boil down to American exceptionalism and cultural imperialism. Hawkeye7(discuss)20:56, 14 September 2020 (UTC)
The m-d-y format persists because it is visually elegant and a lot less of a mouthful to read out loud. One can't read many d-m-y dates with a single breath, while a comma matches the natural pause after the day in m-d-y. There's also the issue of the more rigorous nature of primary and secondary education in the United States. Go watch a 2014 film called Whiplash to see the kind of perfectionism expected of American students. --Coolcaesar (talk) 18:57, 16 September 2020 (UTC)
I'm guessing that you grew up with the format, therefore it sounds/looks natural to you and other formats don't. Which is a form of WP:IJUSTLIKEIT. Personally, I find the comma in mdy an indication of the mind pausing due to an unnecessary gear change - when dates are in order then they flow better. Of course, my opinion is also just another case of WP:IJUSTLIKEIT, it's just a counterpoint to yours.
Having said that and long time readers knowing that I don't like mdy much, I think mdy is the better format for US military articles on WP. Since we like to follow the sources, the US military itself says correspondence with non-military people should be in mdy format. Our readership is mostly non-military, so following the lead of the US military and using the date familiar to most US readers makes sense when talking about a US specific topic (as per WP:TIES). Stepho talk22:45, 16 September 2020 (UTC)
That's the best reasoning for using mdy in US military articles that's been put forward so far, and I personally support it. However, as other users have mentioned here, changing it after nearly 20 years is more trouble than its worth. BilCat (talk) 23:01, 16 September 2020 (UTC)
Official histories all use the dmy format, so it does reflect our sources. But I agree with Bil. I won't change an article just to conform to the MOS. Hawkeye7(discuss)23:06, 16 September 2020 (UTC)
It was a serious question. Up until some part of the 19th century, the m-d-y was the standard format throughout England and Scotland. --Light show (talk) 23:52, 16 September 2020 (UTC)
I've never claimed to be an expert at anything. I'm looking at the London Times of Sept. 16, 1920, with the date in that m-d-y format. There are many others online. The Newcastle Courant for June 26, 1717, etc. Along with Manchester, London, Leeds, Glasgow. So I was simply asking what you meant by "official histories all use the dmy format." --Light show (talk) 00:07, 17 September 2020 (UTC)
If it's true that most, if not all, UK newspapers were using m-d-y as their format before sometime in the 20th century, then some might wonder why one of Australia's main newspapers would ask, "Why do Americans put the date the wrong way around?" After all, between 1831, when it began, and at least 1920, The Sydney Morning Herald was also using m-d-y. Which seems to imply that the American format may actually be the only one that is not actually wrong. And as noted, the Newcastle Courant had been using it 50 years before the American Revolution began, and 15 years before even George Washington was born. So why was America apparently the only country in the world to keep unchanged the original UK format? --Light show (talk) 01:45, 17 September 2020 (UTC)
As I've said many times before, the order is not important if the month is spelled out. The problem comes with all figure dates which can be ambiguous. 9/11/2001 is a date in November to most of the world (see 9/11, it even needs a hatnote). Both 9 September 2001 and September 9, 2001 are clear to all readers (anyone remember WP:RF?) and both forms have been used historically. I suspect that the logical form came to dominate with the increasing tendency of people to use all figure dates. It's the same reason some people use 9 ix 2001 for brevity with clarity. From gravestone inscriptions I've seen (mainly in Kent, England) I think the logical format predominated over the last 500 years, but you see all sorts including the more flowery style "the 9th day of September in the year of Our Lord 2001". Martin of Sheffield (talk) 08:04, 17 September 2020 (UTC)
For what its worth, practically every English newspaper uses mdy in the mast head. But most of the English newspapers outside of the Americas use dmy in the articles. Seems to be a tradition thing from days of yore. Like every village/town having a "Ye Olde Time" shop. Thou mileage dost may vary. Stepho talk10:13, 17 September 2020 (UTC)
In my frequent gnoming of date formats, I've learnt to leave US admiralty articles as I find them. I've endured screeching for changing dmy to mdy. It's something I can live with. Tony(talk)12:21, 14 September 2020 (UTC)
Proposed RfC as suggested above
Proposed simple RfC question, based on some settled facts:
1)MILFORMAT links back to the guideline Strong national ties to a topic.
2) That guideline states, "...articles on the modern US military, including US military biographical articles, use day-before-month, in accordance with US military usage."
3) There is no source given for that statement, apparently arrived at by consensus only;
First we should have an RfC on whether to have the RfC. This is a waste of time. These arguments over date formats are so obsessive and trivial and pointless. Of all the issues one could revive, is there any less worthwhile than this? EEng02:01, 15 September 2020 (UTC)
Agree with EEng. Provided the month is spelled out it matters not a whit which order is used. "September 15, 2020" and "15 September 2020" are both instantly obvious to all readers whether it is their preferred style or not. Remeber WP:IDONTLIKEIT and let's get back to building an encyclopedia. Martin of Sheffield (talk) 07:52, 15 September 2020 (UTC)
It's like I said before: it's not like military articles are currently in a lunar calendar and no one knows that they're talking about (except lunatics, I suppose). EEng11:30, 15 September 2020 (UTC)
I've always found the "this is so trivial, why change it" argument amusing. If it is so trivial, why do you care if it is changed? (In case it's not obvious, but I would support a formal RFC that is well advertised.) -- Calidum14:57, 15 September 2020 (UTC)
Some "trivial" changes have been monstrous. The one to switch from hyphens to ndashes (few readers can see the difference) caused enormous disruption. Hawkeye7(discuss)03:00, 16 September 2020 (UTC)
I did, then predicted to myself you'd bring it up. Yeah, two dates in Radford's infobox are MDY; the other 40 dates in the article are DMY, as called for in the guideline. That's not Ernest King and Arthur W. Radford using different formats, that's someone put two dates in wrong. You're gonna need to up your game; here at MOSDATE you're in the big leagues. EEng02:43, 16 September 2020 (UTC)
I wrote in my previous paragraph, "Arthur W. Radford, in office between those two, uses both formats, but mostly the British format." --Light show (talk) 02:50, 16 September 2020 (UTC)
I find it trivial. Anything that is clear to the reader is fine with me. But the people who do not find it trivial, people who find date formats to be an affront to their nationality, military service, or who knows what, would dominate a discussion which I am sure would be closed as no consensus. Why start something which will be ugly and accomplish nothing, but I'm a pessimist. Tilt at windmills if you want; I'll even help where I can. SchreiberBike | ⌨ 01:37, 16 September 2020 (UTC)
However, anyone who finds the "date formats to be an affront to their nationality, military service, or who knows what," would be going off-topic. The date format is encoded in U.S. military law. It isn't simply about some old-style yes or no debate, but whether the law itself is deciding. --Light show (talk) 02:41, 16 September 2020 (UTC)
Was he the one that said "Remember, remember the fifth of November / Gunpowder, treason and plot / I see not reason why gunpowder treason should ever be forgot"? Hawkeye7(discuss)04:55, 16 September 2020 (UTC)
The sources explain that that there are two formats: one for internal "memorandums" and the other for "civilians" (correspondences or letters,) which implies for the general public. There are other sources which also state that. Which is also why all of the sources for the bios or other public military matters use the "civilian" format, ie. U.S. Naval Institute or the U.S. Air Force Academy. --Light show (talk) 03:13, 16 September 2020 (UTC)
You are correct, public affairs releases follow most news style guides. Anything else follows d-m-y. None of that has any bearing on what we do at Wikipedia. Also USNI isn’t military. Garuda28 (talk) 03:42, 16 September 2020 (UTC)
What is meant by "anything else follows d-m-y?" As you can check, none of the U.S. citations in U.S. military articles use it. Per the WP guideline, the d-m-y format is a specific military exception to the common m-d-y format. However, the exception is strictly limited, and only pertains to internal memorandums, the kind that the public is not privy to. So the guideline has incorrectly included all military-related topics within that exception. It also directly contradicts Date and time notation in the United States which has sources. --Light show (talk) 04:42, 16 September 2020 (UTC)
That article has "citation required" tags. And I'm far from convinced of its contention that Americans always say "July four" and never "the fourth of July". Hawkeye7(discuss)04:55, 16 September 2020 (UTC)
That's an absurd argument. I've never anyone say "four July", anywhere. Almost everywhere one says "the fourth of July" (or sometimes "the fourth of July" "July the fourth"), which is written in the abbreviated form "4 July", followed by the year where appropriate. Dondervogel 2 (talk) 06:37, 16 September 2020 (UTC)
Well at least you had the integrity to drop it. Some people won't drop it AND they've got the wrong end. EEng19:31, 16 September 2020 (UTC)
Proposal: improved wording
Hanging my hat on the end of this discussion with a related point, I do think that this policy as currently drafted is badly written. It starts with a generality "in some topic areas...", from which the reader would anticipate some general principle, but then segways straight into the specificity of the US military, leaving whatever the general principle might be unstated. And then the policy is tagged "Milformat" as if it is particularly about the military. The United Nations HQ in New York is another example that uses DMY. Without intending to change the implied meaning, it would be clearer if it read: In topics where a date format that differs from the usual national one is customary usage, that format should be used in related articles: for example, articles on the modern US military, including US military biographical articles, should use day-before-month, in accordance with US military usage.MapReader (talk) 08:30, 19 November 2020 (UTC)
Over 800 views to the main page since I posted the above, a good many of which will have looked in here; I take it that my tweaked wording is uncontroversial? MapReader (talk) 15:34, 20 November 2020 (UTC)
Unicode ndash character in year ranges
In MOS:YEARRANGE it says "A simple year–year range is written using an en dash (– or {{ndash}})". Does this mean that the Unicode "–" (ndash) character is disallowed? I know of no other part of MOS that explicitly disallows direct use of Unicode characters. I have seen many MOS discussions on it but all petered out with no conclusions either way. I ask this because another editor (@ThePersecuted:) and I are having a disagreement over whether the Unicode character is allowed or if it is strictly prohibited.
My position is that the Unicode character is much clearer when reading the mark-up code of an article (especially for newcomers), that is easy to add (via the insert feature slightly below the summary line or via cut and paste from some nearby text) and that the – makes the mark-up much harder to read. I also note that in the similar Wikipedia:Manual of Style#To separate parts of an item in a list, it uses the Unicode character in its own examples.
I am not asking to disallow the –, only asking whether the Unicode character should also be one of the explicitly allowed forms. Stepho talk11:58, 5 November 2020 (UTC)
It reads to me that ThePersecuted is over-interpreting. The text reads "A simple year–year range is written using an en dash". The html and {{ndash}} are merely suggested ways to write it, since most keyboard settings don't include the glyph as standard. There is no such thing as a "Unicode character", only centuries-old characters that also have Unicode codepoints. Are we forbidden from using the latter A directly, because it has a three Unicode code points? (– is unambiguous whereas there are three types of A: Latin A, Greek Α, and Cyrillic А).
I disagree with Stepho-wrs. There are several characters that look like "–". There are many different fonts that a reader or editor might be looking at in any of the various skins, or any of the 548,215,345,215 different interfaces Wikipedia provides for editing text, or any of the thousands of different text editors editors might be using through cut-and-paste editing. Discerning what character a dash-like-mark really is is a pain in the ass. Jc3s5h (talk) 16:50, 5 November 2020 (UTC)
I agree that either – or {{ndash}} should be used. I do all editing in the source editor (and my proxy copying the code in Notepad++ to do some automated editing), and -, –, and — all look the same in a monospaced editor. This practice makes it make it less ambiguous of which dash is intended in the source. ThePersecuted (talk) 16:51, 6 November 2020 (UTC)
Within the MOS:YEARRANGE it states "A simple year–year range is written using an en dash (– or {{ndash}})", and lower down states "Markup: 1881{{ndash}}1882 or 1881–1882", so it comes across as the HTML code or the template should be used over the "Unicode" character. ThePersecuted (talk) 16:51, 6 November 2020 (UTC)
The – and {ndash} are just suggestions. Whether to insert one of them, or to insert a literal ndash character, in the source is a perennial debate. Obviously, reasonable people know that – and {ndash} make more sense because, as Jc3s5h points out, it is can be very difficult to tell if the right kind of dashy-hypheny-thingy is present if it's just stuck in there literally. EEng18:03, 5 November 2020 (UTC)
I prefer to see, and myself use, "–" for the en-dash, the character being easily inserted by option-hyphen (or option–(en-dash)hyphen?) on my Apple keyboard (Windows and other keyboards must have similarly easy-to-remember methods). I use wikEd to diagnose usage where it isn't apparent from seeing hyphens juxtaposed with en-dashes, if that's necessary (wikEd places tiny blue "en" and "em" labels on top of dashes). The template ({{ndash}}) is much preferable to the HTML code (–) in terms of readability in raw editing mode, if some sort of markup is what you must use. Dhtwiki (talk) 19:49, 5 November 2020 (UTC) (edited 19:54, 5 November 2020 (UTC))
Windows and other keyboards must have similarly easy-to-remember methods Sure. Just type left alt-0150 on the numeric keypad. How easy is that? Hawkeye7(discuss)23:45, 6 November 2020 (UTC)
I accuse Hawkeye7 of unfair discrimination against women and people with physical limitations. People with less ability to carry heavy loads that average adult males with no physical limitations may wish to carry lighter laptops, which do not have numerical keypads. Some of these don't even have a fiendishly-difficult-to-use alternative to the numerical keypad. Jc3s5h (talk) 12:29, 7 November 2020 (UTC)
If Persecuted is arguing that, because it's not listed, it's a forbidden alternative, then he is wikilawyering about this. That said, do consider preferring at least the HTML entity in most cases as it is clearer to all your intent. --Izno (talk) 21:50, 5 November 2020 (UTC)
I saw an edit yesterday where a gnome had done not much other than replace all the Unicode en dashes with template markup. I ground my teeth and moved on but MOS:DATERANGEdoes suggest that gnomes should continue this feverish work. Please add the Unicode symbol as the first of the options. Johnuniq (talk) 23:11, 6 November 2020 (UTC)
The gist of the above is that MOS:YEARRANGE does not mean to disallow the Unicode character, but that some editors (such as ThePersecuted) will take it at face value and believe that the Unicode is disallowed. Is it possible for one of you to either add the character to the list of examples or to add wording along the lines of "Examples include, but are not limited to, en dash (– or {{ndash}})". I also take it as granted that some don't like using the character but it should be made obvious if it is allowed or disallowed. Stepho talk23:26, 6 November 2020 (UTC)
Why, oh why, do editors use these clutterbugs? What is wrong with clicking on the en-dash button just below the edit box? Tony(talk)03:32, 7 November 2020 (UTC)
Because on many platforms it's difficult for later editors to tell that the right thingamajig is present. EEng03:45, 7 November 2020 (UTC)
I don't have any buttons either (probably due to Special:Preferences) but using an actual en dash is not compulsory. Anyone who cares about short horizontal lines knows how to enter them somehow, and how to distinguish them (if they can't distinguish them, they clearly have no reason to care). I simply don't want gnomes thinking they are saving the encyclopedia by using this guideline to systematically remove perfectly good characters. They particularly should not introduce confusing templates that bloat the output. Johnuniq (talk) 23:11, 7 November 2020 (UTC)
So, have we decided to explicitly list the Unicode character as allowed or to explicitly list it as disallowed? I have a discussion on another page that is waiting for this decision, so it wouldn't be proper for me to modify this MOS entry myself. Stepho talk22:15, 10 November 2020 (UTC)
Neither. As already mentioned, MOS doesn't try to spell out all markup options, and shouldn't try; and omission means nothing. If someone's lawyering about this, point me to the discussion and I'll squash them like a bug. Or, less lethally, point them to Wikipedia:How_to_make_dashes and tell them to get back to you when they've read it; that will take years, so your problem is pretty much solved. (Later: Actually, I was thinking of this earlier version [33] -- I think you see what I mean.) EEng23:51, 10 November 2020 (UTC)
Can we at least add "eg" to the start of the list? At present it looks like an exhaustive list rather than a partial list. Many people (including myself) would read it as though the Unicode character is disallowed but the above discussion says that the Unicode character is not disallowed. Adding "eg" to the start of the list would rule out that ambiguity. Stepho talk00:52, 21 November 2020 (UTC)
Centuries
How did we end up with this: “Treat...the 17th century as 1601–1700, and the second millennium as 1001–2000”. I understand that it is strictly logical, given the lack of a year zero. But no-one in the real world treats 1700 as the last year of the 17th century. And 2000 is universally seen as the first year of the 21st. Isn’t WP supposed to follow the sources? MapReader (talk) 21:41, 22 November 2020 (UTC)
Depends on the sources. Any source (media, historiography) that is about the events in those years will treat, for instance, 2000 as the 1st year of the 21st century. Any source that is specifically about chronological reckoning will say 2000 is in the 20th century eg thisDeCausa (talk) 23:33, 22 November 2020 (UTC)
That’s the nub of it. “Technically”, centuries and decades count up from year one but in practice, and general usage, they start at year zero. The MoS, surely, is about usage, as effectively our style guide? Under Century we have In general usage, centuries are built by grouping years based on their shared digits...For example, the 20th century is generally regarded as from 1900 to 1999, inclusive., yet on pages about specific centuries WP usage follows the existing MoS. For a reputable academic illustration of common usage beginning with ‘00 years, here[34] is an example from Yale University Library; click on the tabs and you can see that everything is arranged from ‘00 upwards. MapReader (talk) 07:28, 23 November 2020 (UTC)
This is one example of a perennial issue for Wikipedia. A magisterial written encyclopaedia will use formal English and expect to correct misapprehensions however popular they are. WP however often seeks to use the vernacular and merely reflect "general usage". We need to establish if WP is a quick look up of current fashion, or an accurate portrayal of precise technical definitions. Martin of Sheffield (talk) 12:55, 30 November 2020 (UTC)
Exception for SI Weight and Length
Just like 10 degrees Celsius should be written as 10°C per the template exception, I think another exception should be made for
meter, kilometer, gram, kilogram and kilometer per hour (Or m, km, g, kg, km/h). By using the abbreviation for these measures from first occurrence we achieve the following
Makes English texts just a lot more readable and in line with German and other language texts (Where kilometer is not introduced, just used as km, or km/h) — Preceding unsigned comment added by Frankk20168 (talk • contribs) 07:24, 30 November 2020 (UTC)
You're talking about the passage reading
In prose, unit names should be given in full if used only a few times, but symbols may be used when a unit (especially one with a long name) is used repeatedly, after spelling out the first use (e.g. Up to 15 kilograms of filler is used for a batch of 250kg).
Exception: Certain units are generally represented by their symbols (e.g. °C rather than degrees Celsius) even on first use, though their unit names may be used for emphasis or clarity (conversion of degrees Celsius to degrees Fahrenheit).
As it happens, there's a hidden note buried in the above, almost certainly added by me ten years ago: "perhaps identify these in table of specific units elsewhere on this page". It's clear from the phrasing "certain units" that the intent of the above is to include more than just °C, but I don't think we've ever grappled with coming up with a definitive list of these "certain units" -- if indeed a rigid list is desirable. Anyway, as things stand these certain units are uncertain. EEng07:33, 30 November 2020 (UTC)
A good post. No-one spells out units like metres any more; you simply find the instructions for whatever you are trying to do, and if it says 'm' you know it is in metres and if it says 'ft' in feet. MapReader (talk) 07:54, 30 November 2020 (UTC)
The "no-one spells out" assumption seems to be at odds with actual practice (see here and here) in published sources. (I added text to the search string to help elicit running text rather than a parenthetical.) Doremo (talk) 09:26, 30 November 2020 (UTC)
I wonder if it is a jump in US usage? "was 100m long,was 100 m long,was a hundred meters long,was a hundred metres long" gives even more extreme results with a very strong uptick in recent years of "meters" (sic). Perhaps Americans feel that there is a risk that '100 m' could be misread as 100 miles? In the rest of the world, where the ambiguity doesn't arise (or, as in the UK, is routinely pre-empted), it is superfluous to spell it out. Annoying! --John Maynard Friedman (talk) 12:24, 30 November 2020 (UTC)
I know Americans like driving, but still, if you saw somewhere “I went to collect my pizza from the store 100m from my house”, is any reader really going to be thinking “gee, two hours’ driving each way just to pick up a pizza!”?? MapReader (talk) 13:15, 30 November 2020 (UTC)
Confusion can occur: when I started on chartwork a light described as "DirWRG2s15m10M" (this example is the directional light into Falmouth docks as shown on the Admiralty chart) always had me guessing if it was a light 15 metres (49 ft) high shining for 10 nautical miles (19 km; 12 mi) or a light visible for 15 nautical miles (28 km; 17 mi) at a height of 10 metres (33 ft) above mean highwater (springs). It didn't help that sometimes the "M" was written as an "m". Martin of Sheffield (talk) 14:51, 30 November 2020 (UTC)
While I see some benefit in avoiding the ENGVAR issue, I don't see the other supposed advantages as significant. We're writing for English-speaking readers and we can assume that they can actually read English. And we have no special need to blindly follow ISO or NIST guidance.
OTOH, given that we are required to provide conversions in most circumstances, I think constructions like "2 km (1.2 miles)" or "20 km/h (12 miles per hour)" will generally look clumsy and should probably be avoided. Kahastoktalk17:35, 30 November 2020 (UTC)
Because of the culture wars in the UK, I try to remember always to use the abbr= parameter. So 30 miles per hour (48 kilometres per hour) at first use then 90 km/h (56 mph) thereafter. Tbh, the latter more often than the former since it looks so pedantic (as does the version when abbr is not used).--John Maynard Friedman (talk) 18:34, 30 November 2020 (UTC)
It seems that Americans understand the metric system nowadays (even if they still prefer using imperial units) so it seems pointless and clumsy to spell it out. As pointed out by Kahastok, the article should have measurement conversions. For the few cases where the symbols are ambiguous (m for metres or miles), the conversion itself makes it very obvious which is which. 'm' paired with 'ft' or 'in' obviously must mean metres. 'mi' is used for miles in conversions by {{convert}}, so the reverse case doesn't come up. For hand conversions, 'm' paired 'km' obviously means miles. Even more obvious when the article consistently uses metric first in conversions (or imperial first if the article is about an American topic). Stepho talk23:48, 30 November 2020 (UTC)
@John Maynard Friedman: There is no point in using 30 miles per hour (48 kilometres per hour), when 30 miles per hour (48 km/h) is perfectly adequate. That's because we include the conversion for those readers who are not familiar with the imperial unit, but are familiar with the metric unit: if they are familiar with the metric unit, they don't need the full name and the unit symbol will suffice. Using the unit name (perhaps linked) for the first value is sufficient to cater for readers who are completely unfamiliar with the unit. --RexxS (talk) 23:21, 1 December 2020 (UTC)
And that is the same flawed analysis I got the last time I raised it. If I abbreviate one style and give the other in full, I am making a POV choice of emphasis between systems. In the rest of the world I'm sure people are thinking "eh? what???" but there is a continuing culture war in the UK that spills into articles about UK topics, so one has to be scrupulously neutral and thus either extend both or abbreviate both. Even then a regular disruptive edit is when an IP changes for example 100 km/h (62 mph) to 62 mph (100 km/h) (or even 60 mph (97 km/h) !) The converse also happens but not so often. Familiarity is not the issue, the SI system has been the only one taught in schools for decades, it is an article of faith. Martin of Sheffield, would you agree? (and I still consider the default mix of styles pedantic at best). --John Maynard Friedman (talk) 00:04, 2 December 2020 (UTC)
I think that is overstating things. What is true is that the UK is moving towards a mix of measures, with those imperials that are in daily use (such as miles for driving or pints for beer and milk) enduring but, otherwise, the metric system taking over for distance, weight and volume - for example in activities like cooking, DIY, or sending stuff through the post. Celsius/centigrade replaced F for temperatures years back now. Anyone of working age will have been taught the metric system at school, and knows it is easier to use; if you go to a home store or the supermarket pretty much everything you buy will be in metric. The older, now retired, generation that wasn’t taught metric tends to cling to some of the other imperial measures, but that will pass with the passage of time. Miles will endure, and pints probably will, but otherwise the remaining imperial measures will fade away. MapReader (talk) 06:27, 2 December 2020 (UTC)
I'm not sure I would agree that it is "an article of faith". I would agree that "the SI system has been the only one taught in schools for decades". @MapReader: Whilst in general I agree with your point (tempus fugit), please don't overstate your case. Some of us still of working age were taught the imperial system for everyday life, SI was reserved for the lab. I drive in miles, navigate in nautical miles, drink in pints, weigh in stones, cook in pounds and do my DIY in whichever unit seems most appropriate at the time (thou, vulgar fractions or occasionally metric screws). When I read history, all the units are imperial except where some pedant has altered the original: "..ran for about 10 miles" -> ".. ran for about 16.1 km". TBH, in daily life I just halve the weight, distance or volume (kg, km or l) to get a meaningful quantity. However those who do share John Maynard Friedman's faith really ought to remove the beam from their own eyes before tending to others' motes. Time after time we see the old metric measures that the BIPM has deprecated from the SI being used. Take the litre for example. It's never been part of the SI yet has had to be kept from the old cgs system. Seriously: "the volume of one kilogram of pure water at maximum density (+4 °C) and standard pressure" or 1.000028 dm3! Yet again; the use of decimal prefixes as an approximation to binary prefixes has been condemned and prohibited by the BIPM for decades, yet their use continues. Getting back to the point though, RexxS hit the nail firmly on the head. Conversions are a courtesy to the reader (anyone remember WP:RF?) by supplying an equivalent to the original measurement. We really ought to follow the source precisely, then provide conversions as appropriate. For instance report of the Royal Commission into the Clifton Hall Colliery disaster (Morley, 1885) it was reported that Davy lamps would ignite firedamp "in a current of 6 feet per second (1.8 m/s)". Martin of Sheffield (talk) 10:35, 2 December 2020 (UTC)
If I gave the impression of insisting on SI irrespective of context, it was unintentional. I support MOS:RETAIN and being true to sources: in the example Martin gives, I would do exactly the same. It was this sort of intervention, Talk:High Speed 2/Archive 4#Put speeds in MPH first?, that I had in mind. Anyway, we are going off topic: all I wanted to say is that unequal treatment of outputs from {{convert}} are considered by some to be making a WP:POINT or WP:ADVOCACY but this side discussion risks diverting attention away from Frankk20168's proposal so best we draw a line under it at this point. --John Maynard Friedman (talk) 15:52, 2 December 2020 (UTC)
Depends what you mean by "follow the source precisely". You provide a direct quote, that's one thing. But factors like consistency are also important.
It is also worth adding that we have had editors in the past who have gone through articles by the thousand, placing superior sources with inferior sources because the inferior sources used metric units. They then argued (directly and knowingly in defiance of this guideline) that because the source was metric the measure should be switched from imperial to metric. The only reason that isn't happening now is because we have active community sanctions in the area. Kahastoktalk17:20, 2 December 2020 (UTC)
Typo or confusion?
In the AD/CE section it says "or 100 BCE to 200 CE if that is what is meant". I assume it means from 450 BCE to 200 CE? Didn't want to change it though, in case I misunderstood. Ovinus (talk) 17:53, 6 December 2020 (UTC)
The correct quote is "from 100 BCE to 200 CE if that is what is meant". I believe "450 BCE to 200 BCE" and "from 100 BCE to 200 CE" are meant to be two different examples of correct usage; a template is used to mark them both as correct usage.
Suppose the passage were edited to read
Do not write from 450 BCE to 200 but rather from 450 to 200 BCE or from 450 BCE to 200 BCE (or from 450 BCE to 200 CE if that is what is meant).
That might be understood to mean that "from 450 BCE to 200" and "from 450 to 200 BCE" were both wrong because "from 450 BCE to 200 CE" was really intended, so the first two examples should be red, not green.
I think the basic problem with this passage is it's trying to pack a lot of meaning into a few words, and a reader is going to have to stop for a couple of minutes to unpack it. Maybe it should be expanded into more bullet points. Jc3s5h (talk) 18:08, 6 December 2020 (UTC)
Agreed, maybe something like
If needed, the era should come directly after (or before, with AD) the end year, and optionally with the start year. Do not write from 450 BCE to 200; write from 450 to 200 BCE or from 450 BCE to 200 BCE.
For a range spanning both eras, write from 200 BC to AD 100; from 200 BCE to 100 CE.
There is certainly no year zero when using the notation BC/AD or BCE/CE. It does exist in Astronomical year numbering which is seldom used in Wikipedia. It also exists in some editions of ISO 8601 but that is not allowed in Wikipedia for dates before 1583. Jc3s5h (talk) 18:47, 6 December 2020 (UTC)
Yeah sorry I forgot about that annoyance. I didn't know how else to word going across the boundary between 1 BCE and 1 CE. Ovinus (talk) 19:51, 6 December 2020 (UTC)
I have been bold and made an edit to the main page. “For a range spanning both eras” is obviously unhelpful, since it would leave a range intended to be within the BCE era still in a format that is potentially misleading. The key point is that ranges that start in BCE need to specify the era of the end of the range - which is what I have endeavoured to edit into the MoS. MapReader (talk) 20:03, 6 December 2020 (UTC)
The meaning is changed with your edit, I think, in that it no longer prohibits 500 AD to 750. I guess that would be unambiguous but probably bad style. Ovinus (talk) 20:14, 6 December 2020 (UTC)
I flagged it as a bold edit, so anyone is free to revert it. But by my reading of the original text (which I agree is confused) it was never intended to deal with your issue. As you say, your hypothetical formulation is badly drafted, but isn’t ambiguous in that no-one would assume the second date isn’t AD/CE. In practice I reckon most editors would stick the AD after the second date, anyhow. Edit/ A valid challenge, however, is whether this wording would be better moved down and integrated into the section on ‘Ranges’; it doesn’t sit happily within “Era style”. MapReader (talk) 20:18, 6 December 2020 (UTC)
Oh shit. Well, apparently I was confused by my recent edit as well. I assure you there was something sensible I was trying to do. I'll revert then look again later. EEng15:06, 7 December 2020 (UTC)
The (original)problem is already resolved, except that I feel the whole block of wording would sit better in the Ranges section further down the page. MapReader (talk) 15:59, 7 December 2020 (UTC)
Ordinal date numbers omitting month?
When discussing multiple dates in the same month, listing full short dates for all of them quickly becomes repetitive: "A happened on 2 September 2020. Then B took place on 7 September, and C on 14 September. On 20 September, D occurred, followed by E on 25 September." The guideline doesn't at all mention using ordinal dates without months when the context is clear, i.e. "Then B took place on the 7th." What is the default status for a practice neither listed acceptable nor unacceptable? --Paul_012 (talk) 12:45, 8 December 2020 (UTC)
I have no answer to the question. But since this is related to style, I will state my objection to saying that 7th is an ordinal date while 7 September isn't. Both rely on the date in question being something that can be ordered; it lies between 6 September and 8 September. This differs from a tradesman estimating that a home repair will take 7 work days, with an undetermined start date and not necessarily consecutive.
If this thread leads to an edit to the manual, I would not want to see the word "ordinal" in the changed version. Jc3s5h (talk) 14:49, 8 December 2020 (UTC)
I could swear there was something in the guideline contemplating consgructions such as Payment was due by the fifth of each month but hell if I can find it. Re the status for something neither listed acceptable nor unacceptable, the answer is that common sense should be used by the editors of the article concerned. Personally, I don't think it would be bad to write The message was received September 1, opened September 5, confirmed September 6, and announced on September 9. EEng15:10, 8 December 2020 (UTC)
Well thank you! But the discussion you just linked was about a different use case i.e. when there's no particular month in play: "Rent is due on the 1st of each month" (or "1st day of the each month" or "first of each month" or "first day of each month"). The OP is asking about the case of a series of dates in a particular, stated month. EEng00:26, 9 December 2020 (UTC)
if appropriate
A recent edit removed (if appropriate) in the case of dimensions of things measured in length–width–height and similar dimensions. It would not be appropriate for things that don't have units. I don't know how many examples are needed, but matrices are commonly used in mathematics (and other sciences), commonly described in dimensions which might be width and height (but in any case are similar dimensions) but don't commonly have units. They are commonly written with either a multiplication sign or the word by, as indicated. It might also be used in the case of quantized physical objects, such as boxes in a warehouse. In the latter case, I suppose a unit of boxes could be given, but is normally obvious from context. I don't see a reason that units would be more needed for objects that come in arrays with length, width, and/or height than anything else. Gah4 (talk) 09:25, 12 December 2020 (UTC)
All true. But the section in question is about units of measure. The examples you cite are outside its scope. EEng12:57, 12 December 2020 (UTC)
MOS:ERA style
A Colossus Mark 2 computer being operated by Wrens. The slanted control panel on the left was used to set the "pin" (or "cam") patterns of the Lorenz. The "bedstead" paper tape transport is on the right.
Why do we use the {{Xtn}} template in the WP:ERA section to show notations like BCE, CE, BC and AD? It gives the misleading impression that a special font should be used for those terms. I say this after noticing a case of special font removal in this edit. Debresser (talk) 16:35, 9 December 2020 (UTC)
I understand that {{xt}} and {{!xt}} are to show examples in green and red, and {{xtn}} is probably for uncolored "neutral" examples. But, as I said, it gives the impression as though a special font should be used, so I have removed them. Debresser (talk) 15:50, 14 December 2020 (UTC)
Am I correct that it is intended only for uncertain or approximate years and/or dates, and not for uncertain numbers of all types? The latter usage seems unnatural to me, but I'm not sure if it's actually incorrect. (The article for Maldon, Essex, uses it to state the population.) I was about to shorten it in accordance with MOS:CIRCA, when I began to wonder if "circa" is even appropriate in that context. I didn't want to make an edit without something more definitive than my own opinion behind it. Thanks! 1980fast (talk) 00:51, 29 December 2020 (UTC)
A more general question is what is the reason to use this Latin word (mispronounced by most English speakers) in English texts instead of proper English words "around" and "about"... — Mikhail Ryazanov (talk) 18:13, 31 December 2020 (UTC)
Numbers in parentheses
For the most part, MOS:NUMERAL advises editors to spell out integers from 1 to 10 when used in sentences within the body of an article; for example, "two people came to the party" is preferred to "2 people came to the party", except perhaps in some limited cases. I can't, however, find any guidance regarding the use of a combination of prose (i.e. numbers being spelt out) followed by Arabic numerals in parenthesis [40]; for example, "two people came to the party" being written as "two (2) people came to the party". I am aware that the latter approach is sometimes adopted in technical or legal writing when clarification might be needed or the fear of being misunderstood be a real concern, but I'm wondering if it's something which is considered to be suitable for Wikipedia articles since it kind of has a WP:JARGONish kind of writing style feel to it and also seems to be not really recommended for general writing. Is anyone aware of any guidance regarding this type of thing when it comes to Wikipedia? -- Marchjuly (talk) 05:14, 1 January 2021 (UTC)
I have come across this format the other way around - with the quantity in digits followed by being spelled out in words within brackets - for example in a legal or financial context where it is critical to be absolutely clear as to what a large quantity is, and to safeguard against a typing error. But I don’t really see the point of your example where an unambiguous quantity is spelled out and then followed by brackets containing the digits? In any event, this is an encyclopaedia famous for being open to editing by all, and we don’t have any numbers that are that important. If you think about WHY we have the existing rule, preferring words to digits for smaller numbers, it is to make things easier for the reader - a sentence containing all words is easier read. Your formulation is the most difficult to read of all, since the brackets and change of format prompt the reader to pause mid-sentence, and hence would be discouraged by implication of the existing policy IMO MapReader (talk) 06:15, 1 January 2021 (UTC)
@MapReader and EEng: I asked about this because it was something I came across recently being done by another editor in articles about Filipino chess players such as Mark Paragua. I removed these parentheticals a few times from some articles because I personally didn't think they were necessary, but then started wondering whether it might be an MOS:ENGVAR type of thing or some sort of recent trend in writing because they kept being added. I wasn't asking because I wanted to to do such a thing myself and the examples I provided above were just some generic ones I made up. In hindsight, it would've just been better to provide a link the article in question instead; so, I apologize if that was confusing. -- Marchjuly (talk) 07:43, 1 January 2021 (UTC)
Hello, MOS:UNITSYMBOLS specifies "Format exponents using <sup>, not special characters", eg "km2(markup: km<sup>2</sup>)" not "km² (km²)", but Unicode subscripts and superscripts states the W3C and the Unicode Consortium recommend using superscript and subscript characters instead of markup: when super and sub-scripts are to reflect semantic distinctions, it is easier to work with these meanings encoded in text rather than markup. Unicode ² instead of <sup>2</sup> is easier to read for editors.--Marc Lacoste (talk) 05:36, 12 December 2020 (UTC)
Not just DATESANDNUMBERS, but MOS in general, has long gone out of its way to deprecate special characters for fractions, exponents, and other such stuff. I suspect it's because of uncertainties about whether all platforms will render them properly, and (as so often) screen reader issues. EEng01:28, 13 December 2020 (UTC)
This should be the viewer's responsibility, not ours. Our responsibility should be to be the most accurate, not to be afraid of some poor user-end implementation.--Marc Lacoste (talk) 17:58, 15 December 2020 (UTC)
Unicode exponents and fractions can all go to hell.
A(2q + 1)
is better than
A⁽²q ⁺ ¹⁾
And the same applies to simpler expressions like 25 km2. We likewise use regular characters for something like "The Planck constant h..." instead of its dedicated unicode character "The Planck constant ℎ". Headbomb {t · c · p · b}18:21, 15 December 2020 (UTC)
The link make sense and it is sane. It just doesn't say what you think it does.
The confusion here is over the meaning of the word "semantic". Per your original post, that Unicode superscripts should be used when super and sub-scripts are to reflect semantic distinctions.
The question is, does the superscript character mean a fundamentally different thing from the ordinary character.
In the case we're discussing, the answer is no. The text 2j + 1 in (2j + 1)a means the same thing as the text 2j + 1 in a(2j + 1). In both cases, it means two lots of j, plus one. That one is used as a factor and the other as an exponent does not change that fact.
But this is not the only case in all typography where superscripts and subscripts occur. In phonetics, an ordinary j indicates a Voiced palatal approximant, while a superscript ʲ indicates palatalisation of another consonant. These are semantically entirely different. The ʲ isn't a different kind of j, it's a completely different symbol meaning a completely different thing.
The link tells us that these characters exist so that they can be used in phonetic notation. The reason for no superscript q is because superscript q is not used as a symbol in phonetic notation. And Wikipedia does already use Unicode superscripts as anticipated in phonetic notation.
You seem to be suggesting that the number 2 is not involved in any way in squaring. That the act of raising something to an exponent has nothing to do with the value of the exponent.
So then the 2 in 2x is different from the 2 in ln 2? How about in log2x and x1+x2? How about in x2i and xi2 and xi2? Are these all different twos for which we should have a variety of special characters? And what about the ies (i's)? A bunch of different ones of those as well? And in eiπ – is that exponent π different from the regular π in sin nπ? Or, wait, is that a regular π or a special multiplier π? In fact, is there a regular anything, or does everything have all kinds of special versions depending on how it's used? EEng15:03, 29 December 2020 (UTC)
There is certainly a difference between π and π. The former is a constant, approximately equal 3.14159. The latter is a variable can can take any value, real or complex. Dondervogel 2 (talk) 20:12, 29 December 2020 (UTC)
Only real or complex? Why not vector-valued? Let's drop the faux sophistication. My pi's were all the circle constant, just used in different ways, just as all the 2's were the integer successor to 1, just used in different ways. The question remains whether we're supposed to have a plethora of 2's or pi's, one for each different role. EEng23:18, 29 December 2020 (UTC)
This has been a bugbear for years. Some editors want to go against the guideline on date formats by insisting on dmy. One of them has raised a query at an article talkpage. Could I please have opinions on this? Tony(talk)00:44, 27 December 2020 (UTC)
In topics where a date format that differs from the usual national one is in customary usage, that format should be used for related articles: for example, articles on the modern US military, including US military biographical articles, should use day-before-month, in accordance with US military usage.
Concur. The US mil style has been in place on Wikipedia for well over 15 years, and shouldn't be ignored simply because a few editors are unaware, or dismissive, of the existing guidelines. BilCat (talk) 01:43, 27 December 2020 (UTC)
I honestly think we could get consensus to ditch DATEVAR and go all DMY (or ISO) everywhere. But then, maybe that's a pipe dream. :) --Izno (talk) 20:07, 27 December 2020 (UTC)
I invite Izno to purchase all the ISO standards dealing with dates, and figure out which one is intended in the previous comment. After reading the standards, Izno will realize that the one most often discussed in this talk page, ISO 8601, is completely unsuitable for Wikipedia articles. However, Izno will be unable to strike out the comment above because, after paying ISO's exorbitant prices, Izno won't be able to pay his/her internet bill. Jc3s5h (talk) 20:14, 27 December 2020 (UTC)
1) Please don't be uselessly pedantic. In the context of dates on Wikipedia, the only ISO standard we have ever cared about was 8601. 2) We already allow use of 8601 in certain cases, and it should be obvious that my parenthetical was intended to indicate its lesser significance (for those cases). --Izno (talk) 20:16, 27 December 2020 (UTC)
Seriously, indeed. I have never heard the phrase "useful pedantry" before, but it strikes me as wonderfully fit for much of the best works of humankind, as well as all my work as a WP:WikiGnome. We should dedicate a whole article on Useful pedantry. --A D Monroe III(talk)21:48, 28 December 2020 (UTC)
"I honestly think we could get consensus to ditch DATEVAR and go all DMY". I've been feeling that way too, but I love my pipe dreams. (I should have better dreams.) SchreiberBike | ⌨ 23:29, 27 December 2020 (UTC)
I agree with both of you, and as a global encyclopaedia it would be a defensible position. But one that would run into opposition from Americans determined to defend their uniquely weird way of plucking the month out from the middle, sticking it first, and then having to drop in an extra comma to keep the date and year apart. A more achievable first step ISTM would be to aim for DMY as default for all articles other than those with national ties to the US. MapReader (talk) 15:25, 28 December 2020 (UTC)
I mean, I'm an American and I'm the one who suggested it might be plausible. Is that not the default today for non-US articles? --Izno (talk) 20:51, 28 December 2020 (UTC)
Not quite. Currently, MOS says says you should generally use the date format most commonly used in that nation. This gives some latitude. I would certainly support the proposed change to make it more prescriptive. It adds a specific exception for topics where a date format that differs from the usual national one is in customary usage. The main exception cited is US military, but we also use DMY in spaceflight articles because NASA uses it. Over the last few years the Americans have gotten more combative and less inclined to be good global citizens. Hawkeye7(discuss)21:21, 28 December 2020 (UTC)
We Americans are good global citizens -- the best global citizens, in fact. It's all those non-Americans that are the problem; they should just go and move somewhere else. --A D Monroe III(talk)22:01, 28 December 2020 (UTC)
I know that I would really hate it if WP outlawed my country's use of DMY. I assume Americans would have a similar problem with outlawing MDY. While consistency is often a good goal, WP aims to be inclusive of the major English dialects. Excluding a major dialect would alienate a large number of readers. Stepho talk15:07, 30 December 2020 (UTC)
Those of you unfamiliar with American English should understand just how firmly entrenched MDY is in the U.S. A typical American would never use DMY in written English and the vast majority would view DMY as strictly a foreign format, not just an alternate one. To me, MDY is the same as referring to "Chapter 12" in a book. The larger volume (month) comes first, followed by a more specific descriptor (day). This may not appear logical to those in other countries but it explains how we Americans view MDY as a logical format. Gcjnst (talk) 17:26, 6 January 2021 (UTC)
That question doesn't make sense. An earlier link to the WP:MILFORMAT redirect to the specific section in MOSNUM was provided. --Izno (talk) 06:45, 28 December 2020 (UTC)
I'm so sorry, everyone: finally I read the guideline on this, overleaf. I wasn't aware that the US military exception had been added. Tony(talk)00:51, 4 January 2021 (UTC)
Comma following year
In the "Chronological items" section, it mentions that "A comma follows the year unless followed by other punctuation that replaces the comma: The weather on March 12, 2005, was clear and warm." How is this grammatically acceptable? "The weather on March 12, 2005" is the noun and "was" is the verb. Since when do we inject commas between nouns and verbs? It's like saying "The weather yesterday, was clear and warm." It seems as though the comma may be the culprit causing this bizarre recommendation, but it should be ignored in this context. You wouldn't write "The weather on 12 March 2005, was clear and warm." The comma within the MDY format is not a functional part of the sentence structure; it only exists within the MDY as a formatting device. Someone please tell me what I'm missing here. Gcjnst (talk) 17:38, 6 January 2021 (UTC)
WP:ENGVAR? The text as it stands should certainly have an example of DMY usage, where a comma is definitely wrong. The weather on 12 March 2005 was clear and warm. not The weather on 12 March 2005, was clear and warm. --John Maynard Friedman (talk) 17:56, 6 January 2021 (UTC)
English has many idiosyncrasies. When few or no dictionaries or style manuals address what the grammar and punctuation should be in a situation, it's fine to use your own reasoning. But since this is well-settled in relevant style manuals, your reasoning is irrelevant. Jc3s5h (talk) 18:52, 6 January 2021 (UTC)
I've been hearing this for years, and it's silly. If that were true then we'd do the same in DMY: The weather on 12 March, 2005, was [etc]. It's just a convention, period. (Or maybe I should say: It's just a convention, comma.) EEng19:28, 6 January 2021 (UTC)
Julian and Gregorian calendars in England and the Colonies
I find the MOS is ambiguous here and I'd like to seek some clarification. The MOS states:
Dates of events in countries using the Gregorian calendar at that time are given in the Gregorian calendar. This includes some of the Continent of Europe from 1582, the British Empire from 14 September 1752 ...
Dates before 15 October 1582 (when the Gregorian calendar was first adopted in some places) are normally given in the Julian calendar.
Does that mean that between 15 October 1582 and 14 September 1752 for articles about English history, we should use the Gregorian, the Julian or base our choice on what reliable sources use? NHSavage (talk) 16:11, 28 December 2020 (UTC)
And just to make it a bit more entertaining, for events that fell between 1 January and 24 March inclusive, contemporary sources gave the number of the year that began on the previous 25 March but modern writers typically 'correct' that to the "year begins on 1 January. [To give an example, next Monday is 4 January. In the historical method, it is 4 January 2020 but of course it is 'really' 4 January 2021.) Oh and by the way, Scotland changed the date of New Years' Day (to 1 January) wef 31 December 1599. --John Maynard Friedman (talk) 16:33, 28 December 2020 (UTC)
Thanks. Should I make that explicit in the MOS do you think? I was aware of the year issue as well, that seems clearer though in the MOS ("At some places and times, the new year began on a date other than 1 January. In writing about historical events, however, years should be assumed to have begun on 1 January ") - this is consistent with my best reference, although it does muck this up at least once, forgetting to "correct" it from contemporary sources...NHSavage (talk) 16:46, 28 December 2020 (UTC)
I definitely advise that you don't leap in to correct the MOS without securing consensus first. But it would certainly be useful to offer a draft revision here, please.
(PS, sorry, didn't intend to teach you to suck eggs. My 'more entertaining' note and the {{main}} addition was for others who may not be so aware that here be dragons.) --John Maynard Friedman (talk)
Draft revised text (new bullet in bold). This partially duplicates a sentence from below so more reworking may be desirable.
Current events are dated using the Gregorian calendar.
Dates before 15October 1582 (when the Gregorian calendar was first adopted in some places) are normally given in the Julian calendar. The Julian day and month should not be converted to the Gregorian calendar, but the start of the Julian year should be assumed to be 1January (see below for more details).
For dates of events after 15October 1582 in countries which had not adopted the Gregorian calendar at the time, follow the dating method used by reliable secondary sources (or if reliable sources disagree, that used most commonly, with an explanatory footnote). If in doubt give both Greogrian and Julian dates.
Dates for Roman history before 45BC are given in the Roman calendar, which was neither Julian nor Gregorian. When (rarely) the Julian equivalent is certain, it may be included.
For dates in early Egyptian and Mesopotamian history, Julian or Gregorian equivalents are often uncertain. Follow the consensus of reliable sources, or indicate their divergence.
Looks good to me. The only thing I might change is your last sentence, so that it reads Where misunderstanding may arise, give both Gregorian and Julian dates.Where misunderstanding may arise, specify explicitly the calendar in use or give both Gregorian and Julian dates.--John Maynard Friedman (talk) 17:46, 28 December 2020 (UTC)
First, the reliable sources I'm familiar with, including American National Biography, Oxford Dictionary of National Biography, and Encyclopædia Britannica follow the advice in MOSNUM; Oxford and Julian are used when and where they were in force, and January 1 is always treated as the beginning of the year. American National Biography states this explicitly in the front matter; the others can be verified by looking up some famous people and events who's dates are well known. Since the MOSNUM guidance is already based on reliable sources, we should not send editors back to the reliable sources to rediscover this for themselves.
Second, John Maynard Friedman wrote "My own tupppence worth is that we should always follow the reliable source". I think this should be an encyclopedia-wide guideline, just as using "." rather than "," as the decimal point is. We shouldn't base the guidance on which source(s) happen(s) to be cited in a particular article on a particular day. There can be different results in different articles, but that would be based on the subject matter and location covered in the article. For example, Battle of Cartagena de Indias could go either way, since one navy used Julian and the other use Gregorian. Jc3s5h (talk) 21:05, 28 December 2020 (UTC)
I suggest the following changes, where strikeout means removal, underline means addition, and italics means moving a statement to an new place. I'm putting nowiki tags around the explanatory footnote because I don't know how to make that display properly on a talk page.
Dates before 15October 1582 (when the Gregorian calendar was first adopted in some places) are normally given in the Julian calendar. The Julian day and month should not be converted to the Gregorian calendar, but t
An article that concerns dates on or after 15October 1582 and a place where the Julian calendar was observed should use the Julian calendar. This follows the usage of reliable sources such as American National Biography,[1]Oxford Dictionary of National Biography, and Encyclopædia Britannica{{efn|1=The calendar practices of ''Oxford Dictionary of National Biography'' and ''Encyclopædia Britannica'' can be inferred by looking up the birth and death dates of famous, well-documented individuals.}}
The start of the Julian year should be assumed to be 1January (see below for more details).
I defer to your far more extensive knowledge and certainly don't disagree with what you say. My concern is more for visitors who don't appreciate the niceties - wp:think of the reader. So I do think that it is helpful to pre-empt misunderstandings when giving a date to expose the calendar in use. Otherwise we get weirdness like William of Orange seeming to have arrived in England before he left the Netherlands. But I suppose it would be reasonable to assume that editors don't really need to be told to be explicit when the context demands it. And, to pick up your concern about sources that disagree with your rule, again I would hope that editors would make clear why their text differs from the source, if only in the <ref> text.
^Garraty, John A.; Carnes, Mark C., eds. (1999). "Editorial note". American National Biography. Oxford University Press. pp. xxi–xxii.
The articles I find credible as far as dates go add a footnote to the first date in the article, explaining the calendar situation. I think that is a good practice. There is already a statement about adding a footnote:
If there is a need to mention Old or New Style dates in an article (as in the Glorious Revolution), a footnote should be provided on the first usage, stating whether the New Style refers to a start of year adjustment or to the Gregorian calendar (it can mean either).
Probably this sentence should be revised to state that any article that uses the Julian calendar in whole or in part, and covers any date after 4 October 1582, should contain a footnote describing the calendar convention followed. Probably the sentence needs to be repositioned too. Jc3s5h (talk) 02:51, 29 December 2020 (UTC)
I have no objection. Indeed, it would remind people that the birth records of some people alive today have Julian calendar dates. Jc3s5h (talk) 02:58, 1 January 2021 (UTC)
No, the Soviet revolution article is called that, it is not a redirect. The GR isn't given a specific date, though it is true that William left the Netherlands in November and arrived in England in October. --John Maynard Friedman (talk) 14:25, 1 January 2021 (UTC)
Percentages in a table - what to do when the sum of the rounded percentages doesn't equal 100.0%?
I became aware of this issue with articles on elections where there are more than two candidates, but it could apply in other areas also.
Consider a hypothetical election between Alice, Brenda, and Claire, where each of them get roughly one-third of the vote. We could summarize that in a table thus:
Candidate
Votes
Percentage
Alice
3,006
33.3%
Brenda
3,004
33.3%
Claire
3,004
33.3%
The problem is, if we add the percentages, it totals to 99.9%. However, the sum of all results is, by definition, 100.0% of the results. How do we deal with this? Do we accept that percentages don't add up neatly? Or do we tick Alice up the extra tenth to fudge the percentages and make the total be exactly 100.0%? —C.Fred (talk) 18:57, 22 January 2021 (UTC)
Since this is a hypothetical election, I'll go along with your statement "the sum of all results is, by definition, 100.0% of the results." In a case where all the listed items must, by the nature of things, add to 100%, I wouldn't do anything. Everyone who has given the matter a fair amount of though understands that roundoff error is inevitable.
In a real election, there will be other ballots that must be accounted for. There will be write-in votes for people who get one or two votes each. There will be undervotes (that is, ballots where no vote was cast for the race involving Alice, Brenda, and Claire. There will overvotes (that is, two votes were cast in a race where the voter is only allowed to vote for one person, so both votes are invalid). And so on. So the table must be designed to allow for all the contingencies. Jc3s5h (talk) 19:37, 22 January 2021 (UTC)
As far as I know, this is not unusual, and that the usual solution is to put a note, something like "Due to rounding, the totals may not be 100%." It seems that this is more of a problem when a table has multiple columns, many of which are not percentages, that need totaling. The other way is to just leave it out. I suspect that there is a statisticians rule on this. Gah4 (talk) 20:36, 22 January 2021 (UTC)
A Google search gets 297 million hits. This is not rare, and the note is commonly given. As well as I remember from recent elections, they would stop at "99% reporting", as there could be otherwise still uncounted votes. (Still in the mail?). In that case, it was less surprising. Gah4 (talk) 20:40, 22 January 2021 (UTC)
Grammar for date example
The date example was recently changed to "This occurred July 20, 1969". To my Australia ears this is definitely wrong and I therefore changed it to "This occurred on July 20, 1969" (ie, inserted "on"). This was reverted with the comment "Previous example fine, as far as grammar, as far as I can tell". I'll have to take it on faith good faith that it is correct for his dialect of English - which I assume is US. However, why not use the form with "on" that is correct for all dialects for English? Stepho talk21:26, 5 February 2021 (UTC)
Omission of on is perfectly acceptable, but to avoid yet another long, tiresome debate, I've reverted to the longstanding example which avoids the question. [42]EEng03:52, 6 February 2021 (UTC)
Top 10: What is the correct variation to use?
I've seen top 10, top ten, top-ten, and even top-10, in song/album articles. And even though I've read the documentation a few times I still have difficulty determining which is the correct one to use. Can someone tell me? I don't like being inconsistent when I edit. -- Carlobunnie (talk) 00:40, 6 February 2021 (UTC)
I'd hyphenate in those cases. When "top 10" is acting as one adjective modifying another word, hyphenate. Like "20th-century painting", but not in "a painting from the 20th century". And as Dondervogel 2 said "I find "top ten" and "top 10" equally acceptable", just be consistent within an article. SchreiberBike | ⌨ 07:42, 6 February 2021 (UTC)
examples for digital storage sizes is five to eight years out of date
I edited the examples for digital memory sizes to more up-to-date sizes. Video card memory, 64 MB to 4 GB; hard drive from 100 MB to 2 TB and 4 TB. The third pair of examples I left alone. If we want to be taken seriously we should make our examples reflect fairly recent common industry storage sizes. Please discuss here if you think examples using quantities should not be kept up to date. I think this is good practice if the original purpose is still met. Especially in a field where sizes increase at such a fist geometric rate. — Neonorange (Phil) 09:23, 21 January 2021 (UTC)
That entire section is ill-considered and needs a complete rewrite. For as long as that does not happen, best to not touch with a barge pole. My 2c. Dondervogel 2 (talk) 19:34, 21 January 2021 (UTC)
"Out of date" is nonsense when the essential part is providing an example and getting an understanding from it. It is a bit ironic to update the examples twice and have the units wrong. – The Grid (talk) 04:32, 28 January 2021 (UTC)
MOS:NUMRANGE for pages
MOS:NUMRANGE currently says: "Forms such as ... 342–9 may be used ... where a citation style formally requires it." Could anybody clarify which citation styles do have this formal requirements. I could only find that in the Vancouver system, "NLM elides ending page numbers and uses a hyphen as the range indicating character (184-5). Some journals do likewise, whereas others expand the ending page numbers in full (184-185), use an en dash instead of a hyphen (184–5), or both (184–185)." So this is not even a requirements of that style, but merely local quirks (their use of hyphens instead of dashes aggravates this foolishness, as some publications have pages numbered as <part>-<page>, so "184-5" would mean "5th page of 184th part"; MOS:RANGE even has an example "pages 5-7 – 5-9"). If there are no such formal requirements, I suggest forbidding this practice in WP and replace "may be used" by "always use full page numbers" to be internally consistent with the rest of WP:MOS. Otherwise, it would be very helpful to list these styles in MOS:NUMRANGE, such that editors not familiar with all the citation styles could get some idea what not to "correct". And do we also want to make an additional exception to allow "using a hyphen as the range indicating character" for such styles? — Mikhail Ryazanov (talk) 14:22, 28 December 2020 (UTC)
I don’t see any harm in using this within citations, where p. 184-5 is a lot more straightforward than typing both numbers in full. MapReader (talk) 14:34, 28 December 2020 (UTC)
However, it can be confusing, because many electronic only publications (increasingly common) use formats like "NNN-N" to indicate a whole item rather than a page range. The repetition in "184–185" clarifies the meaning. Peter coxhead (talk) 14:55, 28 December 2020 (UTC)
I was taught to cite page numbers this way in MLA. I do not recall if it was required or recommended practice. --Izno (talk) 17:51, 28 December 2020 (UTC)
Thanks for the info! I've looked in the MLA Handbook (7th and 8th editions), and it does not discuss this explicitly in the citations format, but in a preceding chapter about numbers it says:
In a range of numbers, give the second number in full for numbers up to ninety-nine.
2-3
21-48
10-12
89-99
For larger numbers, give only the last two digits of the second number, unless more are necessary for clarity.
96-101
923-1,003
103-04
1,003-05
395-401
1,608-774
So this seems to be their questionable house style for numbers in general (contradicting our WP:MOS on dashes and full values) rather than a requirement of the "MLA citation style". Some secondary sources (for example, BibMe) use full ranges when explaining the MLA style, so we probably can keep our style regarding ranges too? — Mikhail Ryazanov (talk) 20:05, 28 December 2020 (UTC)
I though about attracting attention of the crowd dealing with citations, but that page does not discuss formatting issues. Maybe you can advertise this topic on that talk page, and we will continue the discussion here together with all interested editors? — Mikhail Ryazanov (talk) 00:39, 29 December 2020 (UTC)
No, it should be discussed at Wikipedia talk:Citing sources. The section "Variation in citation methods" addresses formats by saying any consistent format may be used. There is one format exception: "Although nearly any consistent style may be used, avoid all-numeric date formats other than YYYY-MM-DD, because of the ambiguity concerning which number is the month and which the day."
If you want to impose an additional restriction against using any consistent format in citations, it will need to be added to "Citing sources" and the corresponding talk page is where it should be discussed. Jc3s5h (talk) 02:44, 29 December 2020 (UTC)
I support Mikhail's proposal as well. These abbreviated page ranges only cause confusion as they are not understood by most readers. They also cause metadata output issued by CS1/CS2 to be inconsistent and more difficult to reuse by third-parties. The size argument in tables is a weak one as well, as they typically save only 1 or 2 characters - if a viewport is so narrow that saving one or two characters makes a difference, the problem will almost certainly also be triggered by other contents, so this is an issue that needs to be solved elsewhere. Our WP:ABBR guideline clearly advises against using abbreviations not universally understood. Removing that exception by removing the sentence or even explicitly forbidding abbreviated page ranges would simplify the guideline (less exceptions), improve consistency and readability. --Matthiaspaul (talk) 23:10, 8 January 2021 (UTC)
I just want to point out that some editors participating in this discussion have been using HYPHENS for ranges instead of ENDASHES which REALLY REALLY MATTERS and while I'm not naming names now if this keeps up THERE WILL BE CONSEQUENCES. EEng04:02, 6 February 2021 (UTC)
Currencies: Missing specification against use of both the name and symbol for an amount ?
Over at Tesla Model S we briefly had a dollar amount both prefixed with the symbol and followed by the currency name. While it may seem obvious to most that this is undesired, maybe the MOS should expressly state that? (I looked but could not find that). Thanks. Lklundin (talk) 07:44, 27 February 2021 (UTC)
AFAICS this is an isolated boo-boo that got fixed without controversy. Is there any evidence this is a widespread problem that editors have been wasting their time arguing about? If not, no rule is needed. EEng14:39, 27 February 2021 (UTC)
More than/less than/at least status
We used to have a guideline that said if a news type source says "over 52,000 killed", there's no point writing that as "at least 52,000" or "more than 52,000", because literally, the source could be technically correct whether the true number is 52,001, 60,000, or 278,000. So the recommendation was to say "52,000", without distracting the reader about speculations about the true number.
A related recommendation was that if the source says "hundreds marched", then we conservatively interpret that as 200.
I can't find these in the guidelines/MOS now and couldn't find them in the archives. Does someone know if this was debated and a new policy decided? Boud (talk) 23:46, 17 February 2021 (UTC)
I've been intimately involved with this page for seven years and have never seen anything like what you're describing, nor can I imagine there ever being such a thing. The closest thing we have is The reader may be assumed to interpret large round numbers (100,000 troops) as approximations. Writing a quantity in words (one hundred thousand troops) can further emphasize its approximate nature. That's a far cry from turning a source's statement "hundreds" into "200". EEng12:49, 21 February 2021 (UTC)
Non-breaking space between number and month in dates
Dear MOS editors. I have read and searched through this excellent text several time and have not found an instructions that should clearly be there: something like "use a non-breaking space between the month and the day in dates". Perhaps it IS there but too well hidden or I am too stupid.
I think it is important to have this rule in "MOS/Dates and numbers" where it should be explicit, easy to find, and citeable with some shortcut like MOS:SOMETHING. It has happened to me that non-breaking spaces that I added according to this rule were removed by other editors who found them awkward. I should then be able to point them to the MOS. With many thanks, Johannes Schade (talk) 13:01, 18 January 2021 (UTC)
What bothers me about sprinking non-breaking-space syntax all over the text is that it really does mess up the edit-mode appearance. This is a bit daunting for anons and new editors. How often do dates split across lines? Tony(talk)03:24, 19 January 2021 (UTC)
And how confusing is a date number by itself? I don't find it confusing when reading Wikipedia or anywhere else. I think the tradeoff of more wiki code in the editing window is not worth the small improvement in readability. SchreiberBike | ⌨ 04:30, 19 January 2021 (UTC)
Watch it, Tony. Maybe he really has only two fingers. Did you ever think of that? Huh? HUH? You need to be more sensitive to editors with special needs [43]. EEng15:00, 22 January 2021 (UTC)
Johannes Schade In my opinion using non-breaking code does not "mess up" the edit-mode appearance and that shouldn't matter anyway. If you're reading WP on a phone's screen (which is how it's mostly read these days) the text will break very differently than it would on a laptop. I use it sparingly for dates and currency $1 million. It's "well-established" in my mind and I will continue to use it. I have no problem working with text that contains it. The idea is to make it easier for users of Wikipedia to read text. I would say use it or not as you see fit. That being said I do NOT agree with the code being removed by another editor who comes upon it once that choice has been made. Cheers Twofingered Typist (talk) 12:54, 19 January 2021 (UTC)
I agree with you (and I think J. Schade was agreeing with you too). And your point about phone screens, which is what most of our readers are looking at, is important. On days I travel, with my phone my only screen, I'm often struck by how many times in a single day I see born on November 5, 1965, in England or hurricane damage totaling $850 million or other such stuff. It's just amateurish. EEng15:00, 22 January 2021 (UTC)
I have to agree with the non-nbsp crowd, which I'm actually pleasantly surprised...exists. I'm skeptical that suppressing line breaks clarifies the text for readers; the same symbols are still presented in the same order. Yeah, there's a pause while the eyes move back to the beginning of the next line, but almost any partially parsed phrase won't make sense or have the same meaning. Like "as usual, liberals criticized the President...of France" or "advocated killing a hundred python...code bugs" for which we'd never use a nbsp, don't seem less intelligible than "moved the car 5...cm". With narrow text displays like a mobile phone or a narrow browser window or high zoom level, letting lines break on spaces is a more efficient use of space, reducing scrolling. Back in the days of print newspapers and full justification of narrow columns, we'd not only never insert a non-breaking space, but we'd break words in half on syllable boundaries just to reduce the variation in whitespace on each line. (Which is rather extreme given the modern tolerance for ragged edges in web publishing.) Having non-breaking spaces in wikitext does indeed make it harder to read and edit, as HTML entities and templates are not WYSIWYG and do not resemble normal English spacing and punctuation. In the process of doing a site-wide spell check, I've found that attempts to use non-breaking spaces sometimes cause errors, the tiniest being extra space, and the worst being instead of a space readers will see something like " " or "&ndsp;". -- Beland (talk) 07:04, 14 February 2021 (UTC)
more efficient use of space, reducing scrolling – The most generous interpretation I can give this is that you're joking. (Less generous interpretations on request.)
Back in the days of print newspapers – Old-timey newspaper typesetting was quite consciously of low quality for reasons that surely need not be explained. We reach higher.
Having non-breaking spaces in wikitext does indeed make it harder to read and edit – What the reader sees trumps editor convenience.
I've found that attempts to use non-breaking spaces sometimes cause errors – So does everything else that raises our articles above a raw .txt in Courier New. But we rest easy knowing you're on the job.
"You must be joking" is not a argument; it's proof by intimidation that does not require refutation. We certainly did not intentionally make low-quality newspaper layout. If you have reasons why the line-breaking practices of the time are undesirable, I do not know what they are beyond what I've already mentioned.-- Beland (talk) 19:29, 20 February 2021 (UTC)
I happened to grab a print copy of MIT Technology Review just now. Their magazine pages still do this, in both ragged-right 3-column and fully justified 2-column layouts on a 8.5 x 11 page. Long words get hyphenated, and short symbols get split. (Like "$10" and "billion" are on separate lines.) -- Beland (talk) 20:27, 20 February 2021 (UTC)
"You must be joking" is not a argument – It's not meant to be an argument, rather a gentle way of saying, "Might want to drop that line of reasoning before you make a fool of yourself." You said that avoiding NBSPs makes more efficient use of space, reducing scrolling Even the densest conceivable slathering of nbsp can induce at most a trivial increase in the vertical size of page's text. In the unlikely case that you – a self-described computer scientist, IIRC – don't see that, I experimentally removed all 188 NBSPs from Phineas Gage, and the reduction in the total number of lines was: zero. Would you like one of the less generous interpretations I've been holding in reserve?
We certainly did not intentionally make low-quality newspaper layout – Not sure who you mean by "we", and you misquoted me. I didn't say old-timey newspapers typesetting was intentionally low-quality (as if the low quality was affirmatively desired) but rather that it was consciously low-quality (in that newspapers knew their typesetting was often of low quality, but accepted that in light of schedule and other pressures). No idea what you mean by the rest of what you said about newspapers.
I happened to grab a print copy of MIT Technology Review just now – I happened to grab a copy of Harvard Magazine just now, and their typesetting is beautiful, including full justification of both two- and three-column pages, and no breaks along the lines of budget was $10 billion. But then, Harvard is Harvard and MIT is, well, MIT.[1]
Long words get hyphenated – Ideally long words should be (soft) hyphenated, but since it's a manual process here at WP it's rarely done. (I myself do take the trouble in narrow contexts such as captions.) But hyphenation has nothing to do with nbsp, and I have no idea why you seem to think it does.
"Might want to drop that line of reasoning before you make a fool of yourself" sounds like an ad hominem which implies the other person is foolish, and is merely insulting without making a coherent counterargument. Feel free to disagree with me, but please stop being insulting. I'm giving you the courtesy of replying to your comments without insulting your intelligence, no matter what my opinion of it might be.
Yes, I'm well aware the impact of removing non-breaking spaces in prose is typically negligible, especially on desktop browsers, which is why I was talking above about narrow contexts. In an infobox or table header, a poorly placed non-breaking space which would be harmless in prose can cause unwanted horizontal scrolling, or starve a neighboring column of width and force a lot more vertical table scrolling. Generally, I prefer not to think about this and let the browser use the space in the most efficient fashion.
The use of non-breaking spaces is at the high end of the raggedness spectrum and the use of hyphenation is at the low end of the raggedness spectrum, with the use of neither in the middle. Given that some modern, professional monthly publications choose to be at the low end, I'm skeptical of the argument that Wikipedia needs to be at the high end in order to avoid looking "amateurish". I mean, that's a perfectly fine adjective if you want to dismiss the aesthetics of someone's work - some modern art looks to me like it could be done by a 2nd grader - but it's not apt in the sense that this is sometimes an intentional design choice of skilled typesetters. -- Beland (talk) 03:23, 21 February 2021 (UTC)
without making a coherent counterargument – No, I made the counterargument by describing the experiment (which was indeed done on a phone – I should have made that clear) along with the warning to not look foolish. You're not taking the warning.
I prefer not to think about this – Others of us prefer to think.
use of non-breaking spaces is at the high end of the raggedness spectrum and the use of hyphenation is at the low end – False dichotomy: you could use both, which (I guess in your simplistic one-dimensional analysis) would bring us back to the middle. No one's suggesting raggedness is a virtue, just that occasional slight additional raggedness is acceptable in order to avoid worse stuff like $10 billion.
I'm happy to discuss this further, but not if you're going to refer to your conversational partners as foolish in every message. -- Beland (talk) 19:37, 21 February 2021 (UTC)
Footnote c of MOS:DATE refers to ISO 8601 for the formatting of numeric dates. Since ISO 8601 is not freely available and can only be purchased from the ISO in two volumes each with triple-digit prices (whether in CHF, USD, or Euro), I question whether this is an appropriate standard to require Wikipedia editors to use. Is there some other more free standard we can replace it with? The footnote is only for a minor point (the interpretation of numerical dates) but I think the principle that editors should be able to read the standards we set for them is important. —David Eppstein (talk) 07:09, 12 March 2021 (UTC)
If we're going to refer people to a standard, the Wikipedia article's description of the standard is a poor substitute. It is not a standard and it is not written as a standard. If we're merely going to tell people to use numeric dates only in 4-2-2 format and only for Gregorian dates, we can do that without pointing them anywhere else. —David Eppstein (talk) 18:51, 13 March 2021 (UTC)
WP uses the relatively straight forward parts of ISO 8601. For the purposes of use within WP, the ISO 8601 article covers everything we need to know. Do you know of something in the standard that we use but don't cover in the article ? Stepho talk22:57, 13 March 2021 (UTC)
Stepho-wrs, I'll mention one small point. In articles Wikipedia uses dates in the YYYY-MM-DD format in a somewhat hazy way. The time zone or time scale are usually not explicitly stated, and must be inferred from context. That's perfectly OK and consistent with ISO 8601. But a person who does not have access to ISO 8601 may be wondering if the standard is really that lenient, and have no affordable, reliable, way to check. (By the way, I had access to an older version but not the current version.) Jc3s5h (talk) 23:28, 13 March 2021 (UTC)
I wonder if we are muddling two issues here?
The MOS sets Wikipedia's style: unlike normal articles, there is no obligation to cite any external authority. So the justification for using any style of date should be to the en.wiki MOS and nowhere else.
Quite independently, if an article in main space needs to cite an ISO standard, the editor should not have to defend that choice: many articles cite books that are extremely expensive or even unobtainable outside national reference libraries. In these cases, we should assume good faith: it is sufficient that the citation is verifiable, not that every reader has to do so. Certainly it would be better to cite an accessible source rather than an inaccessible one, if that choice is available, but access difficulty is not a good reason not to use the best (most authoritative) citation possible.
We are not talking about what we cite in mainspace as a reference for content. Those need only be published and reliable, not online or easily available. We are talking about what we point editors to when we tell them that dates must be formatted in a certain way. I think that it is out of keeping with the philosophy of the project to use paywalled non-open standards for that. —David Eppstein (talk) 00:35, 14 March 2021 (UTC)
We do not tell editors to follow ISO 8601. The editor using the MOS is able to format dates entirely correctly without any access to ISO 8601 at all.
It is sometimes useful, however, to explain to the editor why certain rules are in place. This applies particularly in a document that "is best treated with common sense" and where "occasional exceptions may apply". If the editor does not know why the rule is in place, they do not have the information they need to determine if an exception ought to be made.
For YYYY-MM-DD, we add specific limits that do not apply to any other format (i.e. Gregorian calendar, no earlier than 1583). These limits are in place because readers might interpret YYYY-MM-DD dates as conforming to ISO 8601. This reasoning is not self-evident, and we cannot sensibly explain it without mentioning ISO 8601. Kahastoktalk09:29, 14 March 2021 (UTC)
So why must we assume good faith everywhere else when a citation is given, but not here? The citation is amenable to verification at a good reference library if anyone really doubts its veracity. That only leaves ideological objections in the way. --John Maynard Friedman (talk) 11:02, 14 March 2021 (UTC)
I don't disagree, except to point out that it isn't really even a citation. The point of this footnote is to explain a restriction on use of YYYY-MM-DD dates that is not otherwise obvious. We aren't citing ISO 8601, we're mentioning it.
So in that context, David Eppstein's question becomes, can we explain why we disallow YYYY-MM-DD for non-Gregorian dates and dates before 1583, without mentioning any paywalled non-open standards? Well, the reason for the restriction is that the reader might think we're using ISO 8601, even though we are not. It'll be tricky to explain that without mentioning ISO 8601. Kahastoktalk12:08, 14 March 2021 (UTC)
No we can't, nor must we. The evidence is capable of verification, just not from the safety and comfort of our favourite armchairs. It is still a wp:reliable source and that is the only criterion we really must satisfy. --John Maynard Friedman (talk) 17:16, 14 March 2021 (UTC)
Correct; the ISO is indeed more reliable and reputable than such horrific unethical rags as The Times (et hoc genus omne), which have stained this MOS with their cretinous nonsense, but yet perhaps not less unethical, given the use of practices such as paywalling, which are little more than legalised criminality. But FWIW I would note that anyone computer-literate enough to edit WP markup is readily able to negotiate such trivial hurdles as these paywalls, and as (for example) people who have to access academic journals know, in the real world, the inaccessible is hardly so inaccessible. Archon 2488 (talk) 23:01, 19 March 2021 (UTC)
User:Jc3s5h, are we talking standards or double standards here? Are you telling me that a reference such 2021-03-14 requires a time zone and/or timescale but references like 14 March 2021 or March 14, 2021 do not? Stepho talk02:25, 14 March 2021 (UTC)
If 2021-03-14 is given as a publication date and the publication is The New York Times, there is no need to mention the time zone. But if an editor was under the misapprehension that we had to give the UTC date of publication, it would require access to expensive publications to reliably learn that ISO 8601 imposes no such requirement. Jc3s5h (talk) 17:34, 14 March 2021 (UTC)
If 2021-03-14 is given as a publication date and the publication is The New York Times, there is no need to mention the time zone No? In any scheme where one believes that the ISO version of the date must have a time zone, then one is likely under a similar misapprehension about all other dates. So, I agree, seems like a double standard. --Izno (talk) 20:54, 14 March 2021 (UTC)
An editor who knows ISO 8601 well enough to know that it can have time zones also knows it well enough to know that time zones are optional and that 2021-03-12 means an unspecified time zone (ie exactly equivalent to 12 March 2021 or March 21, 2021). The naïve editor who doesn't know much about ISO 8601 will also assume that 2021-03-12 is exactly equivalent to 12 March 2021 or March 21, 2021. Therefore, there is no conflict - everybody is happy! Stepho talk21:58, 14 March 2021 (UTC)
Could we add long ISO date support? They currently generate errors in citation templates, because those accept only the formats specified here. — kwami (talk) 23:42, 16 March 2021 (UTC)
By long I assume you mean including hours and minutes and possibly time zone. I wouldn't. The reference date is to give the reader a feel for the general time that something happened (eg last month or middle of 2013) and to help relocate references when the website owner shuffles the pages around (linkrot). The exact time of day isn't very important and brings in complications like time zone (some websites make it real hard to find which country they are from because they are pushing for a global presence). So, too hard for little gain. Stepho talk22:38, 17 March 2021 (UTC)
Yes, it does. Example: 2021-03-12 can be interpreted as two different dates to "the naïve editor that knows nothing about ISO 8601: as March 12, 2021 or as 3 December 2021. Using 2021 Mar 12 eliminates any possibility of March 12 being confused for 3 December. Firejuggler86 (talk) 10:24, 31 March 2021 (UTC)
Can you show any example in real life where 2021-03-12 is used to mean 3 December 2021? In other words, where would a reader get such an idea? And even if that worries you, why not use the 3 Mar 2012 format we already have? EEng11:29, 31 March 2021 (UTC)
I request that kwami strike out his post made at 23:42, 16 March 2021 (UTC) and start over, on the grounds that there is no standard published by the International Organization for Standardization that would write today's date as 2021 Mar 31. (Or, kwami could provide a link to the standard that does suggest such a format.) Jc3s5h (talk) 16:10, 31 March 2021 (UTC)
The reader might well not have seen YYYY-MM-DD either. Many of our readers are not software developers - or even technical specialists - and it's not reasonable to assume an intimate knowledge of technical data formats.
And it's not necessarily obvious without having seen any XXXX-XX-XX format that the first XX is month and the second one the day. Particularly when you come from a country where XX-XX normally means DD-MM. Kahastoktalk17:48, 31 March 2021 (UTC)
Yes, most people use dmy, so if unfamiliar with ymd might very well interpret it as ydm. ISO is of limited use on en.WP. Tony(talk)13:12, 1 April 2021 (UTC)
Which is why it's best to spell out the month. ISO order is superior when ordering events that span centuries chronologically. — kwami (talk) 18:58, 31 March 2021 (UTC)
ANY DATE EITHER OBEYS SOME RELEVANT ISO STANDARD OR DOES NOT. SPELLING OUT MONTHS, OR USE A THREE-LETTER ABBREVIATION FOR A MONTH, VIOLATES ISO 8604 AND IT IS UNTRUTHFUL TO STATE OTHERWISE!Jc3s5h (talk) 21:50, 31 March 2021 (UTC)
@Jc3s5h, ISO 8604 Plastics – Prepregs – Definitions of terms and symbols for designations ? I assume you mean 8601.
@Firejuggler86, @Kahastok on the plus side, 2021 April 1 is non-ambiguous but offers no benefits over the 1 April 2021 or April 1, 2021 (except avoiding comma issues). On the negative side, it is not used by any country or standard that I know of. 2021-04-01 is non-ambiguous (there is only 1 date order that starts with 4 digits, nobody uses yyyy-dd-mm). If people are used to other date orders and have difficulty, then seeing the many other dates in the table or references that have dates like 2020-12-31 will correct their thinking. 2021-04-01 also takes up less space - hence its use in tables and other similar space constrained uses. Spelling out the month robs it of a major use (space wise), is not used by anybody and has no other benefits not provided by the other formats. Stepho talk23:09, 31 March 2021 (UTC)
The user should not need to do detective work in order to parse a date.
The space saved by preferring "2021-04-01" over "1 Apr 2021" or "Apr 1, 2021" is marginal at most, and does not come close to outweighing the cost in intelligibility. Kahastoktalk07:30, 1 April 2021 (UTC)
Only about the same level of "detective work" that an American needs to see that "colour" is not a misspelling or a Brit needs to see that "color" is also not a misspelling. Probably less because there are multiple date examples on the page in front of the reader. I think you over-estimate how dumb our readers are. And generally the ones that have trouble reading date formats are unlikely to care about the reference dates anyway. Stepho talk06:16, 3 April 2021 (UTC)
Forgive me for not WP:SHOUTING back at you in my reply. If you insist on yelling at us, at least make sure you do it about something relevant to the discussion. ISO 8604 is about plastics, and I see no connection between the writing of month names and that topic. — JohnFromPinckney (talk)23:14, 31 March 2021 (UTC)
So as this MOS page notes, the lowercase letter "l" is easily confused with the number "1" or the uppercase letter "I" or the pipe symbol "I", depending on the font. The uppercase letter "L" does not have this problem. Consider the difference between these two lines:
100 L (22 imp gal; 26 US gal)
100 L (22 imp gal; 26 US gal)
When I learned the metric system in high school, for this reason we were taught to use only "L" for liter, and I'm told that's also why this standard has been adopted by some chemistry journals. Doing some Wikipedia-wide spellcheck work recently, I did find "l" being used for liter, and it is indeed not all that easy to read whether in the edit window or final display style. To improve clarity for editors and for users of Wikipedia content (which includes but goes beyond this web site and its default settings), I would like to propose changing the MOS guideline so that only "L" is recommended for liters, including constructed units like "mL". I can't think of any upside for using "l", though perhaps someone else can point some out. -- Beland (talk) 04:28, 14 February 2021 (UTC)
Context readily makes this clear. The pronoun "I" is equally easily confused with the number "1" or the lowercase letter "l" or the pipe symbol "I", depending on the font, but does not create any difficulty in the post above. 100 l is equally clear above. Doremo (talk) 04:47, 14 February 2021 (UTC)
I do not find it particularly clear; the reader can be left wondering what unit of measure is being represented by "I", especially in the U.S. where the metric system is not in common use. -- Beland (talk) 20:18, 15 February 2021 (UTC)
Just because it's been discussed before does not invalidate the argument presented. MOSNUM can, if it chooses, adopt a uniform symbol for use across Wikipedia, and a single uniform symbol makes articles easier to follow. Dondervogel 2 (talk) 09:53, 14 February 2021 (UTC)
Sure, but it's a mark of courtesy (one might even say civility) to respect the time of one's fellow editors by reviewing past discussions first. "Ell can be confused with other stuff, and L can't, so always use L" has been suggested already, with much discussion, so if one wants to move things forward one should build on what has come before – not drag everyone back to the starting line. As the great J.S. Mill put it
Thank you for the link to the previous discussion; reading it was very helpful. I'd be happy to discuss the general problem of connecting current policy to previous discussions if we can do that in a collegial and non-snarky way.
In this case, it looks like the previous discussion got derailed and didn't come to any particular orderly conclusion, though it was a good brainstorm. Based on the preferences expressed, I think there were two options likely to get supermajority consensus support in an RFC. Before jumping into that, why don't I run those past people here:
All cases - To avoid confusion with "1" and "I" and "|", "L" should be used in all cases, whether isolated like "L" or with a prefix like "mL".
Limited cases - To avoid confusion with "1" and "I" and "|", "L" is prefered when used without a prefix ("L"), or with a prefix ("mL") if "L" is used elsewhere in the same article ("1000 mL is 1 L", "5 mL/L"). Otherwise, lowercase may be used with a prefix ("ml").
I was thinking of asking folks if they support neither, one, or both of these, and if they have a preference between them. Does that make sense? -- Beland (talk) 00:03, 19 February 2021 (UTC)
Absolutely not. When I taught in a secondary school we explained the the litre was a derived SI unit, it was a way of expressing 1 dm³. It is not derived from a persons name, like Joule or Pascal so must be written like metre, tonnes, or gram with a lowercase initial letter. It is not the Wikipedia way to take a POV, and canvas to have it established through polling users, and on the strength of that make a global change. The Wikipedia way is to reference an authoritative source. Nearest at hand was the Style Guide. THe Economist. 2005. p. 200. ISBN1861979169. Petrol and all liquid capacity is measured in litres- and bottled beer in UK in 500ml bottles and is not legal unless marked that way.
Delving deeper, I find this explanation.
The litre, and the symbol lower-case l, were adopted by the CIPM in 1879 (PV, 1879, 41). The alternative symbol, capital L, was adopted by the 16th CGPM (1979, Resolution 6; CR, 101 and Metrologia, 1980, 16, 56-57) in order to avoid the risk of confusion between the letter l (el) and the numeral 1 (one).
So you youngsters may believe that uc L is an acceptable alternative, but anyone I have taught won't accept it, or us wrinklies. If the lc l could be confused, then write it out in full or use cubic decimeters instead. Please revisit this in 2161 but keep on smiling. ClemRutter (talk) 01:48, 19 February 2021 (UTC)
As you stated, "The alternative symbol, capital L, was adopted by the 16th CGPM (1979, Resolution 6; CR, 101 and Metrologia, 1980, 16, 56-57) in order to avoid the risk of confusion between the letter l (el) and the numeral 1 (one)." Given that it is after 1979, using "L" is a perfectly acceptable alternative. Thanks for finding the loophole. BilCat (talk) 02:11, 19 February 2021 (UTC)
There is a manifest a priori need for project-wide consistency (e.g. "professional look" issues such as consistent typography, layout, etc. – things which, if inconsistent, would be significantly distracting, annoying, or confusing to many readers); or
Editor time has been, and continues to be, spent litigating the same issue over and over on numerous articles, either:
with generally the same result (so we might as well just memorialize that result, and save all the future arguing), or
with different results in different cases, but with reason to believe the differences are arbitrary, and not worth all the arguing – a final decision on one arbitrary choice, though an intrusion on the general principle that decisions on each article should be made on the Talk page of that article, is worth making in light of the large amount of editor time saved.
So if I may, before we proceed I'd like to ask for evidence supporting either (1) or (2) i.e. evidence that the merely suggestive (not prescriptive) language we have now ...
The symbol l (lowercase "el") in isolation (i.e. outside forms as ml) is easily mistaken for the digit 1 or the capital letter I ("eye").
For as long as people use ml/L it's inadequate. Mosnum should at least make clear that the same symbol for litre should be used throughout any one article. Dondervogel 2 (talk) 08:57, 19 February 2021 (UTC)
It was discussed by MOSNUM editors in the link you posted, where it was stated that "ml/L" was perfectly acceptable. I will take it up at the article if and only if we agree here that such ridiculous and confusing notation is unacceptable. Dondervogel 2 (talk) 10:02, 19 February 2021 (UTC)
For reasons explained in the essay I linked a bit ago, it's highly useful for discussion to start in the context of actual articles. In my experience useful arguments are often uncovered that way which would otherwise go unthought in abstract discussions here. EEng10:24, 19 February 2021 (UTC)
I understand the argument. I'm just giving notice that I do not intend to fight the nonsense without consensus here that it IS nonsense. Life is too short Dondervogel 2 (talk) 11:26, 19 February 2021 (UTC)
So you'd rather argue it in the abstract than hear from editors who are likely to be familiar with actual sources and actual usage in the real world. Noted.[Sorry, that last bit was snarky. My apologies.]EEng02:31, 28 February 2021 (UTC)
Your post lacks your usual sharp reasoning:
1. There is no need for the discussion here to be abstract. It just helps holding it at one central location.
2. You imply I am unfamiliar with sources. I know from my own experience that some use "l" while others use "L". No serious science editor (in the real world) would sanction a mixture. We should not either.
The doctors took away all my sharp reasoning for fear I'll harm myself. Look, I'll just say it again. I don't think anyone here would care if you took 30 articles with ml/L and changed them to mL/L. Then if you wait a few days, you might get 5 inquisitive editors of those articles engaging you about it. Maybe all of them will see it your way, and you can go on changing another 50 articles, and so on, with no shots fired. Or maybe one or two object, and even have some reason you haven't heard of or thought of, or a reputable source that really does that. Talk to them about it. Maybe they'll come around. Or not. Then come here, and bring them with you. Those are the people we need in this discussion. EEng12:41, 28 February 2021 (UTC)
So I wasn't really asking for people to give their opinions on the answer to the question, just on how the question should be asked. But given there was support for the "written out" option and it's mentioned as a common solution on Litre#Symbol, I added that. "ℓ" is also mentioned there, so I'm throwing that in as well. So how about this: (Beland (talk) 20:19, 20 February 2021 (UTC))
Options
(EDITED BASED ON SUGGESTIONS BELOW)
The Manual of Style currently allows the use of "litre", "liter", "l", or "L", with a note that says: The symbol l (lowercase "el") in isolation (i.e. outside forms as ml) is easily mistaken for the digit 1 or the capital letter I ("eye").
How would you rank the following options?
Option A - No change.
Option B - Always use "L", including with ("mL") and without ("L") prefixes, to reduce confusion.
Option C - Use "L" without a prefix to reduce confusion. Never mix "l" and "L", with or without prefix, in the same article. For example write mL/L and 1000 mL is 1 L instead of ml/L and 1000 ml is 1 L. E.g. "ml" is OK if "L" does not appear in the same article.
Option D - Write out "liter" or "litre" to avoid confusion, where "l" would otherwise be used without a prefix. Follow WP:ENGVAR.
Option E - Use "ℓ" to avoid confusion where "l" would otherwise be used without a prefix.
Option F - Always use "l", including with ("ml") and without ("l") prefixes.
Discussion
For litres (not millilitres) {{convert}} seems to be used with "L" over "l" only about 56% to 44% in the February 1 database dump, but in free text just looking at well-spaced contexts, it's 6% "l" to 94% "L". Given that the warning has arguably dissuaded some but not all use of "l", whether it is adequate depends on how acceptable you find "l" in various contexts. -- Beland (talk) 20:19, 20 February 2021 (UTC)
Any option that discourages a mix is OK by me. In particular, either of B and C from this list would be an improvement on what we have now. Option C can be improved further by also discouraging mL/l. Option E would make things worse because only the symbols L and l are accepted by the BIPM. Dondervogel 2 (talk) 00:02, 21 February 2021 (UTC)
B - Use 'L' always. It is allowed by BIPM and is not mistaken for the number one or lowercase ell. Option A is putting our head in the sand. Option C (mix of ml and 'l') is yet another convoluted rule to remember - why bother? Option D often turns into an edit war if the article doesn't have any other instances of litre/liter, metre/meter, colour/color to base WP:ENGVAR on (I'm thinking of Japanese car articles). Option E is just so damn hard for the majority of editors to enter that it will never work in practice (technically it is just a font choice of the BIPM sanctioned lowercase ell, so it gets a lot of use on supermarket product labels). Stepho talk00:59, 21 February 2021 (UTC)
Once again, I wasn't asking people to answer the question yet, just making sure the question was phrased coherently before advertising the RFC. -- Beland (talk) 03:32, 21 February 2021 (UTC)
The question can be improved: I'd like to see an option like B, but for lower case only (plain l, not that silly curly font); and option C does not rule out mL/l, but IMO it needs to. Dondervogel 2 (talk) 09:34, 21 February 2021 (UTC)
C was intended to be the same as C2; I've unified them with more examples. Hopefully I didn't mess up the meaning? -- Beland (talk) 19:46, 21 February 2021 (UTC)
It seems to me that there is a missing option G, which is to say explicitly that mixing L and ml is OK, as long as it's done consistently in an article. That would be my preference. In the absence of that, I suppose I'd pick A, no change. --Trovatore (talk) 07:48, 28 February 2021 (UTC)
Plus, by adding G we would open ourselves to the entire spectrum of musical notes–based ABCDEFG wordsmithing, with words like BAGGAGE, CABBAGE, FEEDBAG, and many more possible. (Handy words for traveling and dining, those are.) Or, restricting ourselves to rankings (with each option appearing at most once), people can select from DECAF, CAGED, FAG (sorry), FACED, BEAD, AGED, and (my favorite) EGAD. EEng21:51, 28 February 2021 (UTC)
Sorry I'm late to the party. Having read through this discussion and the RfC below I'm left wondering why use of the {{litre}} template hasn't been suggested. It would be pretty straightforward to add to the fonts it uses, such as Noto Sans JP, Source Sans Pro, PT Sans, Ubuntu or Nunito, etc., assuming that a simple @import tag can be implemented in the WP stylesheet. It may also be possible to amend the template so that screen readers read out the word litre in full, although I'm not sure how that works. nagualdesign02:52, 4 April 2021 (UTC)
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
Of the six options presented, options C E and F can be immediately rejected. Option E (script "ℓ") received no support, Option F is clearly less popular than either A or B, and while there is support for avoiding mixed usage, the specific rule in Option C did not find support. Option D (to always write out "liter/litre") had some support, but consensus is that this is not reasonable in equations and tables where display space is limited. It is noted that nothing in the proposal requires the use of an abbreviation where spelling out a unit makes more sense editorially. A follow-up proposal for always writing out liter/litre in running text could be made.
As Option A is the status quo, this leaves Option B as the potential change to assess. The numerical vote is roughly 12-8 in favor of B (with two votes for option D and one vote for option C). The argument for B is primarily that it will avoid confusion with uppercase "I" and number "1". The arguments against B are threefold. The first is an argument against MoS guidances at all. The second is an ENGVAR argument. The third is that while "l" for litre should be discouraged, other abbreviations such as ml should be used. Regarding ENGVAR, capital L is not just an "Americanism", but is permissible everywhere and widely used outside of Europe; furthermore editors can still spell out litre in running text. As the third argument notes that lowercase "l" is confusing (as well as the voters for C and D), I find there is consensus to stop using a standalone "l" for litres.
Regarding the use of "ml", opinion is more evenly split. The specific construction "ml/L" (milliliters per liter) has both explicit support and strong objections. I do not see consensus to prohibit all uses of "ml" (or other derivative units) here. User:力 (power~enwiki, π, ν) 18:43, 3 April 2021 (UTC)
Should English Wikipedia stop using "l" to abbreviate litres in some or all cases? -- 04:14, 25 February 2021 (UTC)
The Manual of Style currently allows the use of "litre", "liter", "l", or "L", with a note that says: The symbol l (lowercase "el") in isolation (i.e. outside forms as ml) is easily mistaken for the digit 1 or the capital letter I ("eye").
How would you rank the following options?
Option A - No change.
Option B - Always use "L", including with ("mL") and without ("L") prefixes, to reduce confusion.
Option C - Use "L" without a prefix to reduce confusion. Never mix "l" and "L", with or without prefix, in the same article. For example write mL/L and 1000 mL is 1 L instead of ml/L and 1000 ml is 1 L. E.g. "ml" is OK if "L" does not appear in the same article.
Option D - Write out "liter" or "litre" to avoid confusion, where "l" would otherwise be used without a prefix. Follow WP:ENGVAR.
Option E - Use "ℓ" to avoid confusion where "l" would otherwise be used without a prefix.
Option F - Always use "l", including with ("ml") and without ("l") prefixes.
Prefer B; C is OK. D is too cumbersome when space is limited, but would be better than A. E and F would make things worse by being non-ASCII and more confusing, respectively.
"L" was added in 1979 to the SI system by the CIPM precisely because of these typographical issues. (See Liter#Symbol.) Some major institutions already use "L" exclusively, including NIST and some international scientific journals. CIPM may in the future deprecate "l".
Confusion of "l" does happen in practice. Wikipedia's use of a sans-serif font by default makes "l" after a number look like a one, especially if there is no space before the "l". With a space, it can still look like a one after a decimal space or implied multiplication or a typo. "l" is also indistinguishable from "I", which is used to represent electrical current, dynamic action, sound intensity, and moment of inertia.
While readers can usually figure out the meaning from context, it impedes Wikipedia's mission to be unclear and inconsistent and create a speedbump puzzle for students and people unfamiliar with the metric system.
A blanket rule to use "L" in all cases removes all the guesswork and is easy to enforce in a semi-automated fashion.
What's the downside? Some people say "mL" looks weird, but others say "ml" looks weird, and I think it just depends on what you saw more growing up. English Wikpedia readers from all countries currently encounter both in articles without restriction to any particular national variety of English. If Wikipedia consistently uses "L" and "mL", in the long term maybe that will begin to "look normal" to everyone, but much more importantly fewer readers will be confused by "l".
This doesn't make the Manual of Style longer; it's actually streamlining by changing a warning we have to think about in each case, to a guideline we just have to implement.
Prefer B. Lowercase l looks too much like a 1 in too many likely font choices. (In the ones I use, they are very different in preview, but I still can't tell I from l from | in preview, and I can't tell l from 1 in the edit source window.) If it's an official part of SI then it's an acceptable choice, and for typographic reasons the lowercase versions are not. —David Eppstein (talk) 05:11, 25 February 2021 (UTC)
Prefer A, followed by F and D. The context almost always makes this clear, and it can be written out when needed. Doremo (talk) 05:24, 25 February 2021 (UTC)
I can live with B, C or F. All other options are poor. Between these, I prefer to adopt a single WP-wide symbol for the litre, so my preferred options are B and F, with a preference between these for B for the reasons stated by others. My third choice is C because it deprecates bizarre combinations like “ml/L", thus improving on the present guidance. A is unacceptable because it permits "ml/L"; D is impractical because there are times when a unit symbol is needed (eg, in an equation). I guess that leaves E as just acceptable. On these grounds it becomes a (poor) fourth choice. To summarise
1. B
2. F
3. C
3. C (or Option A if modified to exclude mixture of l and L in the same article)
Per my recent exchange with Peter coxhead, I would find Option A acceptable if it were modified to exclude a mixture of l and L in the same article. This would rank equally alongside Option C. Dondervogel 2 (talk) 09:52, 28 February 2021 (UTC)
Option A – None of the others are acceptable to me. I'm not confused by 'ml' and 'L' used together (although 'ml' and 'mL' together probably should be deprecated), and I don't expect others to be confused. Besides, if you really want to make your meaning clear, you employ wiki-links or "convert" templates. Dhtwiki (talk) 09:40, 25 February 2021 (UTC)
Option B as unambiguous. If we must have A, then the existing rubric needs extending so that it says The symbol l (lowercase "el") in isolation (i.e. outside forms as ml) is easily mistaken for the digit 1 or the capital letter I ("eye") and consequently should never be used. --John Maynard Friedman (talk) 11:20, 25 February 2021 (UTC)
I'm still waiting for evidence that editors aren't working out this issue (if an issue it is) for themselves on article talk pages, or that such discussions are wasting time that would be saved by adding to the guidance here. Editors actually working on articles where the question arises are the best people to comment on such issues, and there are none such present here, AFAICS. EEng19:49, 25 February 2021 (UTC)
Well, if I went ahead and systematically changed all instances of "l" to "L" because I think that's universally clearer, I'm confident a bunch of editors would object (either in general or for the articles they are watching) and ask me to get consensus for such a change first. It would be a bit disruptive and potentially a waste of time to change a bunch of articles only to potentially change them back, for the sole purpose of proving there's a dispute. While a manual of style may be useful for settling disputes between employees (or in this case volunteers), in professional publishing they are also used to ensure visual consistency of arbitrary choices and to document best practices that copy editors should enforce. Here I'm not trying to settle active disputes, I'm trying to increase clarity; but first I need agreement that lack of clarity is actually a problem and that this is an acceptable solution. Option B doesn't "add" guidance in the sense of making the MOS longer; it would actually make it shorter. -- Beland (talk) 09:05, 7 March 2021 (UTC)
Option B doesn't "add" guidance in the sense of making the MOS longer – No, but it adds guidance in the sense of telling editors what to do instead of letting them decide among themselves on particular articles. EEng10:34, 7 March 2021 (UTC)
And did you engage those editors in a discussion to elicit their reasons for preferring a particular style? That might be useful information to have here in this discussion. EEng10:34, 7 March 2021 (UTC)
I believe the editor concerned preferred to follow the sources that use ml (disregarding those that follow mL?), and was willing to sacrifice uniformity to achieve that. There are plenty of editors already here arguing precisely that, so adding one more would not change things. Dondervogel 2 (talk) 11:19, 7 March 2021 (UTC)
That particular editor was one who would resort to bullying, sometimes in alliance with a known sockmaster, to get his way. Not someone we'd want contributing to a civil discourse. Dondervogel 2 (talk) 12:25, 7 March 2021 (UTC)
I recall a discussion here. Many years ago. Before the one you mentioned. I wouldn't know how to find it though. How about pinging the editors in the discussion you found? Dondervogel 2 (talk) 20:44, 7 March 2021 (UTC)
Option A - to leave it alone - is far preferable to all alternatives. Per Litre#Symbol, this is a case where usage genuinely varies between countries. That means, if we have to have a firmer rule, then we need to go down an WP:ENGVAR-type route. If we mandate obscure Unicode characters as in E, we'll be ignored. There will always be cases where a symbol is needed (i.e. where space is limited) so D is inappropriate. The others inappropriately mandate uniformity. Kahastoktalk20:34, 25 February 2021 (UTC)
Option A Requiring B will never work with the many people used to lower case—this is a collaborative community of volunteers, not a bunch of paid hacks who take orders from on high. Encouraging Engvar wars is not useful. Johnuniq (talk) 23:04, 25 February 2021 (UTC)
@Johnuniq: Engvar does not permit constructions like "The honor of modelling aluminum behaviour", and for good reason. Option A permits writing ml/L for millitre per litre. Why is mixing OK for the litre but not for Engvar? Dondervogel 2 (talk) 23:16, 25 February 2021 (UTC)
We do lots of things that some people aren't used to and never write, like straight ' and ". It's not a problem for a second editor to come along and make a contribution MOS-compliant (and there are volunteers willing to do that), as long as the first editor doesn't change it back. I'm not sure if that's what you're saying will happen, or that people just won't bother to write MOS-compliant text up front? -- Beland (talk) 02:03, 26 February 2021 (UTC)
@Beland: If they were non-compliant I would fix them myself. The problem is they comply. My purpose is to encourage a change to MOSNUM to make them non-compliant. Dondervogel 2 (talk) 09:00, 26 February 2021 (UTC)
Prefer B+D, ie use 'L', 'litre' or 'liter' but never 'l'. Option A has too much scope for ambiguity. Option B is legal everywhere (even for those countries like mine that were taught to use little ell back in the 1970s - if we can understand colour/color, litre/liter, autumn/fall then this is nothing). Option C is too complicated for many of our editors (which is a sad commentary but true). Option D should be allowed as an alternative to B (WP:ENGVAR works like it has done for years) . Option E is good for reading but the average editor still struggles with entering hyphens, let alone other symbols. Option F has too much scope for ambiguity. Stepho talk07:26, 27 February 2021 (UTC)
@Dondervogel 2: the status quo allows the use of "l" without a prefix so long as it's clear; Option C does not. Text like Its volume is about 6.7 L (1.5 imp gal; 1.8 US gal) is perfectly clear and hence acceptable in my view. Peter coxhead (talk) 09:38, 28 February 2021 (UTC)
Thank you for explaining. I agree that consistent use of "l" throughout an article is acceptable, which is why I am also OK with option F. Perhaps the option you favour (explicitly ruling out the mixture) should be added to the list. Dondervogel 2 (talk) 09:49, 28 February 2021 (UTC)
Option B – if "L" is acceptable per SI, and results in less confusion, which seems really clear to me because I frequently struggle with glyphs that look similar, like - (hyphen-minus) − (minus sign) – (en-dash) — (em-dash), then let's standardize on the least confusing acceptable option. —Joeyconnick (talk) 18:44, 6 March 2021 (UTC)
Option B When comparing "1 l" with "1 L" out of context, the lowercase "l" can lead to confusion with the numeral "1" for certain fonts, and so the capital letter "L" is used. To keep things consistent, adding a prefix, such as "milli", should not change the unit symbol. The SI Brochure (9th edition) shows that both "l" and "L" are accepted.[1] The unit symbols are lowercase letters unless they are derived from a proper name, but an exception for "L" was made by the CGPM in 1979.[1] However, in the United States, the use of "mL" is preferred by NIST[2][3] and the FDA.[4] It seems like the CIPM's recommendation of using SI units rather than liters may explain their indifference between "l" and "L". Somerandomuser (talk) 03:16, 7 March 2021 (UTC)
Units and measurements on Wikipedia are very rarely - if ever - provided without context. MOS:UNITNAMES says that the first few instances of measurements in litres in prose should be spelt out in prose. We also mandate that a non-breaking space be used between a number and the unit symbol. Plus, in our default font used by the vast majority of our readers, the "l" and "1" are pretty easily distinguishable. The likelihood of genuine confusion is minimal.
Meanwhile, upper-case "L" and "mL" are unusual enough to look jarring in significant parts of the English-speaking world. Arguing for NIST is not convincing in areas outside the United States where it is just another foreign national standards body. Kahastoktalk12:02, 7 March 2021 (UTC)
I've already posted these examples in the other section below, but I would like some opinions on some interesting cases used in medicine. These units can be found in charts as well. The units for measuring human chorionic gonadotrophin (hCG) levels, thyroid-stimulating hormone (TSH) levels, or other hormone levels: mIU/ml or mIU/mL (milli-international units per milliliter). See also IU/l or IU/L and mU/ml or mU/mL. The units for measuring blood mean platelet volume: fl or fL (femtoliters). The "fl" is also used as "fluid" in "fl oz". What should be done for these cases? Somerandomuser (talk) 06:20, 15 March 2021 (UTC)
Option B, although I think 'liter' is acceptable too. I just think we should get rid of "l" since it can be confused with I, I guess that would make D acceptable too. Eccekevin (talk) 03:40, 9 March 2021 (UTC)
Option D - per making Wikipedia more accessible to our visually impaired readers and editors. Screen readers (at least mine) do not recognize the letter L, upper or lowercase, as an abbreviation for liter. Other abbreviations like ml. kg. km. etc. are recognized by a screen reader, but only if the period is included, otherwise it just reads as letters.Isaidnoway(talk)19:12, 12 March 2021 (UTC)
I'm sorry, but this makes no sense at all. I'm sighted, and my browser doesn't recognize the letter L, upper or lowercase, as an abbreviation for liter. All I see is the naked letter, and I have to know that it means liter. So you're on exactly the same footing as everyone else. EEng20:02, 12 March 2021 (UTC)
I think the point is that "500 l" or "500 ml" exist in real life text. So, if you're in a place where those symbols are used, you'll interpret them easily because you're used to seeing them in that context. The problem for a person with a screen reader is that basically nobody ever refers to "500 litres" in speech as "five hundred ell". Kahastoktalk20:29, 12 March 2021 (UTC)
A screen reader isn't supposed to be imitating speech; it's supposed to read out what's on the screen. EEng05:47, 13 March 2021 (UTC)
Ideally, it should read out the screen in a way that is readily understandable to the user. That is inevitably going to imitate speech. Otherwise, why not just have it spell out all the words? Don't get me wrong, I accept the argument that says that writing out literally every instance of the unit is unworkable in practice. But it's worth bearing in mind that our guidance already says to write out the unit in most situations. Kahastoktalk11:26, 13 March 2021 (UTC)
Spelling them out in full each time is ok for text but gets unwieldy in tables and infoboxes. This would make the each entry in the {{{engines}}} field in {{infobox automobile}} overflow to 2 lines in many car articles. Stepho talk22:29, 12 March 2021 (UTC)
Option D. I would prefer to see most, if not all, units spelled out. Avoiding any potential confusion is well worth the extra characters it takes to do so. -- Calidum19:43, 12 March 2021 (UTC)
Option B. There's a reason why it was added to the official standards and why most scientific contexts have adopted it exclusively. And this is not some recent change. The 70s were half a century ago. Heck, even the bottle of Coca-Cola sitting next to me uses "500 mL". The use of lowercase for liters is properly considered archaic. The idea of using a script lowercase l is also objectionable on lack of ease of input, and again, the modern standards call for an uppercase L; the cursive lowercase is even more archaic. As for spelling out, it seems good in theory, except the whole ENGVAR thing and the principle of WP:COMMONALITY. Why introduce additional places where there can be spelling issues, especially for a unit so common that even Americans use it daily (see, again, Coca-Cola or any hard liquor, the one area that has been fully metricized). Nah, just keep it simple. Use the modern standard: L for liter. oknazevad (talk) 11:01, 13 March 2021 (UTC)
Which suggests that you're based in North America or Australia. Coke bottles and other drinks bottles in Britain and Ireland say "500 ml", with a lower case l. This isn't "archaic" any more than it's "archaic" to spell it as "litre". It's just different standards in different places. Kahastoktalk11:26, 13 March 2021 (UTC)
Option C, which resolves the central matter of avoiding a single ‘l’ whilst not forcing unnecessary article change in the many uses of cl, ml, etc. in lower case, which remains standard usage in much of the world. Minimising the extent of change to resolve the key concern should be a criterion when considering any change to the MoS. I don’t give too much weight to concern about understanding, since if that were the criterion then the MoS would say next to nothing about punctuation. The important thing is that whatever we write is as clear as possible, so that it is understood when cited. Incidentally, if we can turn the clock back, the mistake was using a single letter; it would have been better if litre(s) were lt. MapReader (talk) 06:54, 15 March 2021 (UTC)
Of the proposed options, I'd agree most with B, as WP is (within reason) entitled to choose to standardise on formats based on its need to communicate information unambiguously. We're not proposing any innovation or deviation from the relevant international standards; indeed, standardising on one symbol for the litre is perfectly compatible with BIPM guidance, and it is entirely representative of the practice of reputable reference publications – I'd argue more so than allowing a hodgepodge mixture of "l" and "L", which is unnecessary and IMHO unprofessional. I see ENGVAR as irrelevant, since we are discussing international mathematical symbols that do not form part of any natural human language, let alone specifically English, let alone specific dialects of English. Some sort of de facto rule amounting to "use l and L according to the relative frequency of their use" (i.e. the situation we are in without standardising) is needlessly overcomplicated and sacrifices unambiguity to a chimerical notion of neutrality. I do not think that compromise is warranted. Archon 2488 (talk) 11:08, 22 March 2021 (UTC)
You need an exceptionally narrow definition of "natural language" to argue that the word or symbol for litre is not natural language. People in metric-using countries speak and write them all the time, including dialect-specific features like pronouncing "ml" as "mill". User:GKFXtalk15:47, 27 March 2021 (UTC)
Prefer A Per NIST,[2] "both l and L are internationally accepted symbols for the liter, to avoid [the ambiguity] the preferred symbol for use in the United States is L." As such enforcing the capital L would be an Americanism, and the whole point of WP:ENGVAR is that all common forms of English are permissible. Consistency within each article is good, but the aim for consistency is again something covered by ENGVAR (and common sense). I oppose E, F on respectively the NIST guidance cited and the same argument as above that UK English should not be favoured either. User:GKFXtalk15:47, 27 March 2021 (UTC)
If the use of capital L was purely a stylistic thing then, yes, it would be an Americanism. But it serves a very real purpose of avoiding a point of ambiguity for all readers and hence is not an Americanism at all. Note: I'm not American and usually argue against Americanisms. Stepho talk16:04, 27 March 2021 (UTC)
Option A does not require consistency. There are MOS-compliant articles that mix l and L in the same article and others that mix them in the same unit symbol (ml/L). This makes Option A unacceptable to me. I can accept it if it is modified to require consistent use of l or L within an article. Dondervogel 2 (talk) 16:13, 27 March 2021 (UTC)
Option A. Why reduce flexibility? It could be tightened, as Dondervogel 2 suggests, but I see no advantage to forcing everyone to use "L" and "mL" in all circumstances. In "ml", what can the "l" possibly be confused with? Is there an "m1" (em-one) that has meaning to someone? Option B would prohibit the use of the word "litre"/"liter" after a numeral, which would be a bizarre restriction. EddieHugh (talk) 15:20, 2 April 2021 (UTC)
Two points:
Option A permits mixing l and L in the same article, which is undesirable. (Example: "during the experiment, 500 ml of water were poured into the bottle (capacity 1000 mL), thus half filling it").
The RFC is about which symbol to use if a symbol is used, not whether to use a symbol. None of the options would prohibit spelling out the unit name in full.
Your first point: that's why I supported your proposal (also made by others above) to require consistency within an article. Your second point: that doesn't appear to be how several people here are interpreting it (hence the suggestion to have a B-D combination, and 'Always use "L"' in the description of B supports the idea that using the word would not be permitted). EddieHugh (talk) 17:30, 2 April 2021 (UTC)
The table states that "long ton" should be written "long ton"; "carat" should be written "carat", etc.... Anyway, let's move on. EddieHugh (talk) 21:53, 2 April 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Litre abbreviation examples
Dondervogel 2 provided some interesting examples where l and L are mixed: Bigeye tuna • Murashige and Skoog medium • Sea toad • Wastewater discharge standards in Latin America • Blue cod. I had been confident that mixing was obviously wrong but now I'm very unsure. From the first link, compare "oxygen content is below 1.5 ml/L" with "oxygen content is below 1.5 ml/l" or "oxygen content is below 1.5 mL/L". In the second link, changing the subheadings to "Major salts (macronutrients)/ 1l" gives an awful result but "1,650 mg/l" is correct for many people. On reflection, I would leave these for editors maintaining the articles to manage (although the Blue cod example needs a simple consistency fix). The standards body probably allows l or L for reasons similar to Wikipedia's ENGVAR pragmatism. In medicine, it is essential that doses be unambiguous and I believe L is often used for that. Yet a large number of people trained in other science areas are used to lower case and consistency should give way to the reality of a volunteer community. I'm posting here to invite opinions on these specific examples. Johnuniq (talk) 02:32, 26 February 2021 (UTC)
BIPM originally preferred "l" because (like the metre (m) and unlike the newton (N)) the litre is not named after a person. When people complained that "l" could be confused with "I" an exception was made to permit "L" for this one unit. Aberrations like "ml/L" were never intended.
I fixed example two by spelling out "per litre" in full
It stands to reason. The CIPM is driven by a desire to remove ambiguity. This is why there is one and only one symbol for 99 % of units (I know of just 2 exceptions). Permitting a mixture would result in some readers thinking that the symbols "l" and "L" represent different units. Who would benefit from that? And if the font in use does not distinguish between "l" and "1", it also would not distinguish between "ml" and "m1".
Having said this, regardless of the CIPM's intentions, using "L" only (Option B) is clearly permitted, as is using "l" only (Option F). These remain my first and second preferences, with C a close third.
Sure it stands to reason. And since it's clear that lots ofapparently at least some high-quality sources apparently use ml/L, that apparently stands to reason too. Do you have any actual sources for the statement that ml/L was not "intended"? EEng21:05, 27 February 2021 (UTC)
I know of no sources that state "ml/L" was not intended. I also know of no sources that use that combination, and I'm surprised to learn that you do. What sources are they? Dondervogel 2 (talk) 21:16, 27 February 2021 (UTC)
I was inferring from the discussion that the use we see in articles followed sources, and I should have made that clear; I've modified my post. EEng02:31, 28 February 2021 (UTC)
Examples are listed of articles in which "l" and "L" are mixed, or in which a (bare) lower case "l" is used as a symbol for litre. Feel free to add your own examples.
Why parade these items without explaining them in situ? In other words, why not specifically link to the sections that mention them instead of the vague "in some sections below"?
I added that [46] back in the day when I realized that (a) there were a lot of places were nbsp/nobr should probably be discussed but weren't and (b) it was going to be a big job to fix that and (c) in the meantime I didn't want people mistakenly concluding that presence some places meant absence elsewhere is significant. EEng04:54, 28 April 2021 (UTC)
@EEng: Regarding this revert: The raw Unicode character "×" appears in the 2021-04-20 database dump 1,298,705 times. The HTML entity × appears only 7701 times, in 3112 articles. (Except for a few articles that use <math>...</math> markup, which I haven't touched because sometimes math editors like to be able to search on words that represent characters in LaTeXish syntax.) I just finished a weeks-long process of converting all these HTML entities to characters. There have been a few thank-yous, but as far as I know no objections or reverts. Given that these are now essentially unused, it didn't seem right to keep recommending them. Does that make sense? -- Beland (talk) 04:05, 4 May 2021 (UTC)
Agreed, as long as there is no obligation to use them, since they are hard to enter. Any editor should be allowed to type ×. An interested other editor or a bot might replace them with the character code. −Woodstone (talk) 06:40, 4 May 2021 (UTC)
That sounds like an argument for keeping the mention of the HTML entity here, then? I'm sure people and bots will continue to add them, just as we continue to get submissions like é for which there is strong consensus to change. And yeah, I just clean those up without complaining at whoever added them. -- Beland (talk) 21:26, 4 May 2021 (UTC)
No it does not make sense. You went around changing symbolics to literals all over the place and now you want the guidance changed because the symbolics are now essentially unused? That's a joke, right? (Unfortunately we don't have a picture of a cat with feathers bristling from its mouth that I can post here.)We just went through this on WT:Manual_of_Style#Proposal:_replace_usage_of_template_character_combinations_such_as_–_with_"what_you_see_if_what_you_get"_such_as_"–". You should not be overriding the choices of those actually improving articles, and roiling the watchlists of actually productive editors for no reason, by mass-changing stuff like this according to your personal preferences or some fetish for mindless consistency. EEng07:42, 4 May 2021 (UTC)
I'm not going to respond to this because it is either mocking or doubting the sincerity of another editor, rather than sticking to the merits of the question. -- Beland (talk) 17:33, 4 May 2021 (UTC)
But the real reason, of course, is that you can't explain why you're wasting time (yours and others') doing something with no discernable benefit. I note you haven't been able to cook up a reason to not respond to David Eppstein (below).I don't question your sincerity, but rather your competence and judgment. Since you have not, and apparently will not, explain the benefit of what you're doing, we are left to conclude that your motive is mere personal preference. Disabuse us if that's incorrect. EEng00:47, 5 May 2021 (UTC)
Regrettably, I cannot respond to this either, since it has doubled down on incivility and become explicitly insulting. -- Beland (talk) 01:27, 5 May 2021 (UTC)
No, it does not make sense. Editors should continue to feel free to add them, and you should find something more productive to do with your wiki-editing time than making pointless cosmetic changes. —David Eppstein (talk) 15:54, 4 May 2021 (UTC)
The changes are not cosmetic in the sense of WP:COSMETICBOT, because they address search mismatch problems, as noted below, which I find worthwhile. I'm certainly happy to have editors input content in whatever format they like. -- Beland (talk) 06:24, 5 May 2021 (UTC)
You have just made it harder for the average editor to know whether you actually meant "×" or "x". This is NOT helpful. You are NOT improving the encyclopedia. --Khajidha (talk) 16:20, 4 May 2021 (UTC)
For a long time I was also pondering whether the visual similarity justified using the HTML entity. But after I discovered we use "×" 1.2 million times, I took that as an indication that the vast majority of editors either have no problem seeing the difference or don't care about the distinction. (Otherwise, that would be an argument for replacing all 1.2 million instances with an HTML entity, but I expect that would generate complaints, given that going in the other direction did not.) After working with the character a bit, it actually doesn't seem all that hard to check whether or not it hits the baseline or is vertically centered, so in the end it's probably not much harder to distinguish than say, capital "V" from lowercase "v". It's also generally clear from context which character should be there, though putting the wrong character wouldn't make a semantic difference to readers anyway. Having a mix of "×" and "×" also creates a problem searching for this character when editing, since one would have to search twice. All else being equal, the vast majority of editors aren't familiar with HTML entity syntax, so converting them should make it easier for most editors to understand the wikitext. (Lots of these symbols seem to occur in articles about music, species, ships, and sports, with STEM articles being a minority.) -- Beland (talk) 17:33, 4 May 2021 (UTC)
When editing in desktop mode there's a link/button to place the Unicode character but on mobile you have to use the html entity. Just out of interest, how do you manage to type the Unicode character in the search box? If I was searching the code to find "2 [times] 2" I'd just search for a 2. nagualdesign17:51, 4 May 2021 (UTC)
Well, my Android phone's default keyboard has "×" on it, right between "+" and "÷" on the punctuation page. All the entries on that page also appear in small type on the main QWERTY page, so if I want, I can easily enter "×" just by holding "w" for a few seconds. All operating systems have a means of entering characters that don't appear on the keyboard (see Unicode input) but for Wikipedia it's probably easier just to copy-and-paste into the search box from the edit widget or from any page where the character appears, such as multiplication sign. -- Beland (talk) 18:29, 4 May 2021 (UTC)
I guess my phone's too old. Holding the W only gives me a 2, and the only multiplication symbol I can produce is a *. nagualdesign18:36, 4 May 2021 (UTC)
If you edit articles with non-ASCII characters, you may find it easier if you use a different keyboard (assuming you are talking about a software-defined one). Personally, I sometimes just tell my phone to edit in Desktop mode, which gives me access to all the special-character editing widgets without having to go copy-and-paste from somewhere else. -- Beland (talk) 21:26, 4 May 2021 (UTC)
But, Beland, you seem to be working from the premise that it has to be one or the other, which isn't true. The sole persuasive argument in your response above is the potential difficulty of mixed usage on a page. Are you saying that all your conversions from × were on pages which already had × somewhere? — JohnFromPinckney (talk)20:13, 4 May 2021 (UTC)
Well, wikitext doesn't have to be easy to understand and re-use in other contexts, but I think it helps editor retention and productivity and knowledge dissemination if it is. I did not check whether or not the articles that used the HTML entity already had the Unicode character. Some of them definitely did, but I expect most did not. If both representations are in widespread use, it would be hard to know whether an article is using a mix or only one, without doing at least two searches, e.g. if one is making a change to all such instances. Search mismatches can also be a problem when one is searching across all articles (depending on the search engine and how one is specifying the query), on a small number of pages where "×" actually appears in the title, and on every page that uses HTML entities (because searching on the strings that appear when viewing the article does not work when editing the article). -- Beland (talk) 21:26, 4 May 2021 (UTC)
Who says literal characters are easier to understand than templates or html? When the existing text has either of the latter two, a novice editor can see immediately how to insert the character using a standard keyboard. When the existing text has only literal characters, he or she may be stymied as to how to insert one using dropdowns and special keyboards and so on. This is just your surmise. EEng00:47, 5 May 2021 (UTC)
That's certainly a reasonable theory, among many others. In practice, I don't see how the idea that the HTML entity is easier to enter is compatible with the fact that the Unicode character apparently has been entered roughly 168 times as often. -- Beland (talk) 01:23, 5 May 2021 (UTC)
I didn't say HTML was easier to enter. I said that it may be that it's easier for a novice editor. For all we know all the literals all over the place have been stymying and discourage novices left and right. Do you have a breakdown of how often HTML/template vs literal has been used by novice editors? Also, do you have statistics on how many potential novice editors did not edit an article with HTML or template, vs. how many didn't edit an article using literals? That's the data you need to support your thesis. EEng03:13, 5 May 2021 (UTC)
Followup: Could you direct me to the BAG approval under which your bot-like 7k+ edits are authorized? Same for your edits re sdot (discussed elsewhere). EEng05:34, 5 May 2021 (UTC)
I did not require WP:BAG approval; I was not using a bot. I manually and lovingly inspected every edit. The scale of changes was too small to justify writing a bot, and doing it manually allowed me to deal with weird circumstances and improve some surrounding text (like unconverted units). As I said, other editors thanked me for doing this.
I don't see how a novice editor would know how to enter an HTML entity from scratch, since novices are by definition not expected to be familiar with wikitext, and only a small minority of people are already familiar with HTML entity syntax outside of Wikipedia. Those who did see an existing HTML entity would have to figure out that several characters are converted into a single character, which is feasible since they have both the input and output available, but that seems like more thinking required than if the input and output are the same. In comparison, the pull-down menu is discoverable and usable by novices, and I expect its presence explains why there are not a ton of questions asking how to input this and similar characters. If you want to fund a usability study and put novices in front of a web browser and look at their success rate, I'm sure the Wikimedia Foundation would be interested to know where people are having trouble, and perhaps it would give us insight into the HTML entity question in general. That would be the best way to get the "gold standard" sort of proof you are asking for. Personally, I'm not going to put that much effort into researching this question, because I find the answer fairly obvious given the data we already have, because the already-implemented solution seems to have been supported by the community, and because problems like search mismatches are also important.
I've shared the data that motivated my change and answered the edit summary question "says who?". It seems everyone agrees that editors should be allowed to input wikitext in either style. Having now been fully informed, it seems folks aren't clamoring to hide the HTML entity syntax from this page, and I don't have a problem letting the revert that started this thread stand. -- Beland (talk) 06:24, 5 May 2021 (UTC)
You need to go further than merely not continuing to push for MOS approval of your bad edits, and stop making those bad edits. —David Eppstein (talk) 07:05, 5 May 2021 (UTC)
Proposal: use 0o123 format for octal in a computing context
The following is a proposed Wikipedia policy, guideline, or process. The proposal may still be in development, under discussion, or in the process of gathering consensus for adoption.
Newer languages have been abandoning the prefix 0, as decimal numbers are often represented with leading zeroes [...] The prefix 0o [...] is supported by Haskell, OCaml, Python as of version 3.0, Raku, Ruby, Tcl as of version 9, PHP as of version 8.1 and it is intended to be supported by ECMAScript 6."
The leading zero notation "0123" has always been problematic, as any reasonable person would assume it means 123, but in fact it means 83. (It's also a source of fun bugs...[47]) If major programming languages are switching to "0o123" we probably should too. (For context, we are already using 0xFF and 0b11111111 notation.) The exception unless there is a strong reason to use some other notation would continue to apply. User:GKFXtalk08:56, 12 April 2021 (UTC)
I'm a developer, but also an author. In my opinion, we should not necessarily follow notations used in programming languages (except for in programming examples in articles dealing with those programming languages), but instead follow more general notations as used in mathematics and normal prose. I always considered it extremely poor writing style (not only here, but also in independent publications) to use artifacts of programming languages in prose. It comes over as nerdy and as if the author could not express himself/herself in proper language. As we are an encyclopedia for everyone, not only for software developers, we cannot assume that the average reader is familiar with programming languages.
Agreeing with Matthiaspaul, we shouldn't use the convention of a particular language (except within an article on that language) but use the standard mathematical notation. {{octal}} displays it well, taking a decimal input and displays it as octal with the subscript 8. {{octal|10}} gives 128. So perhaps a new template to display a given number with a given subscript. Something like {{base|10|8}} to display 108 . Stepho talk23:48, 14 April 2021 (UTC)
I also agree with Matthiaspaul that the standard subscript notation is preferable to programming-language hacks that are not likely to be readable to non-programmers. —David Eppstein (talk) 01:33, 15 April 2021 (UTC)
I agree 50% with Matthiaspaul, because I've never seen the likes of 123o or FFh and find them hard to parse, and because the upper-case subscripts feel like an assault. I recommend the suffix approach, preferring 8310 because that convention extends to any base discussed anywhere, not just the ones associated with computing, but 83dec is clear enough too. Largoplazo (talk) 01:57, 15 April 2021 (UTC)
My answer to the main question is yes: we shouldn't use 0123 to specify octal numbers. 1238 is the clearest, but there's benefit to a format like 0o123 that doesn't involve subscripts. User:力 (power~enwiki, π, ν) 02:07, 15 April 2021 (UTC)
However, 0o123 is unhelpful in a general encyclopedia because every instance would need an explanation. Using "octal 123" would be better. Johnuniq (talk) 02:48, 15 April 2021 (UTC)
Just thought of another use. {{base|F900|hex}} yields F900hex and {{base|123|octal}} yields 123octal . Although I prefer the 16 and 8 usage. Stepho talk11:57, 15 April 2021 (UTC)
In my opinion, the benefit to avoiding subscripts is small in a medium where subscripts are easy to create and used routinely for the likes of H2SO4. Largoplazo (talk) 11:05, 15 April 2021 (UTC)
GKFX, would you happen to know of any nontrivial examples of computer-related articles where the currently prescribed notation is used? i was hoping to see how the format was currently used in wikipedia, but i could only find minimal instances of its usage, mostly as examples of how the notation is used in the relevant computer languages, although my search was admittedly not very thorough. dying (talk) 10:17, 14 May 2021 (UTC)
I couldn't actually find any so it may be that the guidance was just wrong. In any case I've updated the guidance based on the discussion. User:GKFXtalk11:27, 14 May 2021 (UTC)
GKFX, i actually didn't think the previous guidance was incorrect, but simply not often used, assuming that it was necessary in the first place. i had been hoping that you could provide instances where your proposal would have changed the text of an article, since you were the one proposing the change.admittedly, i think the changes you have made actually invite further confusion, since "computer-related articles" and "computer code samples" are not the same thing, and stating without qualification that one should "Avoid 0123 notation for octal" appears to be contrary to what one would assume would be best practice when referencing octal numbers in the context of languages that use that notation.i may easily be wrong about this, but my interpretation of the discussion above led me to believe that there was no strong opinion on whether or not the guideline should change, since the discussion (or at least my understanding of it) did not really focus on "computer-related articles", which was a qualification that the previous guidance had on the usage of the prefix "0" for octal. also, i would have considered the attempt of providing proper computer code for a language that used "0o" to denote octals to be "a strong reason to use some [notation other than the '0' prefix]", so the previous guidance did not appear to preclude usage of "0o" in those instances anyway.would you happen to know of any nontrivial examples of either computer code in article space or computer-related articles that currently use either the "0" notation or the "0o" notation for octal numbers? dying (talk) 13:33, 14 May 2021 (UTC)
Do we really need this little subsection?
Days of the week
Days of the week are capitalized (Sunday, Wednesday).
Where space is limited (tables, infoboxes, etc.) an en dash may be used for a range (Monday–Thursday).
I've been wondering about that for years. Capitalization is general English, which we don't teach at MOS unless there's been a chronic problem. That ndash can be used for ranges is straightforward and I can't see that belaboring it here is worth any evil averted. I did add something about abbreviations. [48]EEng12:42, 14 May 2021 (UTC)
I'd lean towards advocating deletion of this because, as others have observed, we don't need to spell out every basic common English typographical convention (e.g. proper nouns are normally capitalized, and English treats day names as proper nouns, which everyone who can write English at a level appropriate to be editing WP presumably already knows). It's also not clear to me why we specifically need to tell editors that they may use an en dash here (when they can also use it to denote a range in pretty much any other context). Archon 2488 (talk) 15:52, 7 June 2021 (UTC)
Historic unit name, usage
I noticed an editor changed WMGM-FM (New York City), an article about an FM radio station of the 1940s–1950s, to use megacycles instead of megahertz. I was always taught that the modern name of the unit should generally be used (since the CGPM adopted "hertz" in 1960; Broadcasting magazine adopted megahertz broadly in 1970). Which is correct? Sammi Brie (she/her • t • c) 08:10, 22 May 2021 (UTC)
MMessine19 is extremely active in articles on defunct stations, so there might be a good chunk of them. Sammi Brie (she/her • t • c) 17:55, 22 May 2021 (UTC)
@Johnuniq: I just realized something. Some of these, pre-1945, are going to rightly use "megacycles". Then, the FM band was from 42 to 50 megacycles. Megahertz wasn't a thing yet. It wouldn't be until Edwin Armstrong created it in 1941, it was adopted by the FCC in 1945, and the 88.1 to 105.9 FM band came about, they would later add 106.1 to 107.9 as the frequencies filled in. That was technically Megahertz. But pre-1945, the 42 to 50 frequency bandwidth was megacycles.
Now, I have no issues changing others like this, it was just outright incorrect. But some, I would have to leave them alone like like KYW (4th paragraph, 3rd sentence, "Also in 1942, KYW added an FM station at 45.7 megacycles, W57PH."). That, technically, is correct. Would these be an issue? It might take longer? - Neutralhomer • Talk • 03:42, 23 May 2021 (UTC)
@Neutralhomer: Hmm, no idea. Hey EEng, in 1942, did KYW_(AM) add an FM station at 45.7 megacycles (because "megahertz" would be anachronistic), or was it at 45.7 megahertz although in 1942 people weren't aware of that term? I would think that, since we are writing for a modern reader, we would use the modern name. Johnuniq (talk) 03:50, 23 May 2021 (UTC)
(I hope you're not mistaking me for some kind of Talmudic scholar because you're definitely on the wrong track there. But I'll do my best nonetheless ...) It was 45.7 megacycles. Also, it was 45.7 megahertz. Both are true statements, but only one uses the terminology we at WP use (and everyone else today uses), so that's they way our articles should talk. In quotations, you might want to change megacycles to a bracketed [megahertz]. It's probably a good idea to get some appropriate Wikiproject on board before going on a change spree, but that's not to say their local opinion should be deferred to -- we don't want another "she for ships" for radio stations -- see [49] and (shamelessly plugging my own essay) WP:YOURMAJESTYYOURSLIPISSHOWING. EEng05:26, 23 May 2021 (UTC)
Just as US readers in the mid-1940s would have had trouble understanding the newly introduced megahertz, wouldn't modern readers have (slight) trouble understanding ye olde time megacycles? Or like grandpa Simpson, should we continue using "forty rods to the hogshead"? After all, it's unlikely that US citizens from the mid-1940s will be reading Wikipedia. Stepho talk03:59, 23 May 2021 (UTC)
Yes. Actually, this should be asked at a suitable wikiproject. Their word might not be final, but it should be raised there to give people an opportunity to engage. Johnuniq (talk) 04:00, 23 May 2021 (UTC)
I like Dondervogel 2's idea. Putting a WikiLink to hertz where one finds megacycles. The group for radio stations is WP:WPRS, so post that over at, of course, WT:WPRS. :) Would you all mind if I pinged in a couple of our long-time members for more opinion? You all already have Sammi. :) - Neutralhomer • Talk • 22:43, 23 May 2021 (UTC)
I'm just waiting for a definitive answer and what WPRS wants before I get going. I still intend to help, it just seems this is still unanswered and/or waiting for answers from WPRS and others here at MoS....unless I misunderstand. - Neutralhomer • Talk • 16:56, 25 May 2021 (UTC)
I don't know who's done what where, but there seem to be only about 10 articles left that give radio station frequencies in megacycles (not counting quotations). NebY (talk) 17:31, 25 May 2021 (UTC)
"Megacycles" should not be used, except in direct quotes. To use "megacycles" in articles about old radio stations would confuse readers, making them think that back then, frequency was measured with a different unit. It's not a different unit, just a different name for the same unit. Jc3s5h (talk) 18:52, 25 May 2021 (UTC)
WP:MILFORMAT question
Hmm I have a small question here about this sentence: "In topics where a date format that differs from the usual national one is in customary usage, that format should be used for related articles: for example, articles on the modern US military, including biographical articles related to the modern US military, should use day-before-month, in accordance with US military usage.". It's a little bit vague here to me. What's considered the modern US military? Is it possible to add a year or so when this rule has started within the US Army? I see a lot of biographical articles from WWII or the early Cold War which use MM/DD and to a lesser extends DD/MM. Cheers. CPA-5 (talk) 11:25, 23 May 2021 (UTC)
Huh, sounds like a weird rule. You'd think that the assumption would be that you'd use the regular national format. Most of our readers are not soldiers, they want to know when something happened and not how a soldier would describe it to another soldiers. Military organizations do a lot of things for their own purposes that don't necessarily have anything to do with what we're trying to do here. We don't call soldiers "warfighters" (as the Pentagon sometimes does) and so on. We also don't usually follow sources for formatting issues when it contradicts our MOS -- if a source has "October 8th" or the organization we're writing about uses that format, we still say "October 8" here. Not sure why the US Army gets special deference (altho there may be a good reason).
Sounds like a dumb rule to me. Well, right at the top of this page it says it's a "generally accepted standard that editors should attempt to follow, though it is best treated with common sense, and occasional exceptions may apply." Sounds like this'd be one of those occasional exceptions per common sense, so I'd just ignore that part of the rule (which who know when it was put in, why, by whom, and with what consensus or logical explanation). Herostratus (talk) 12:44, 23 May 2021 (UTC)
The format became standard during World War II. Since then most US government agencies have adopted it too. For our purposes, we define "modern US military" as the 20th and 21st centuries. Most of our readers use the DMY format all the time. US military people are generally dismissive of civilians who want to use the month first format. Now that the Make America Great Again movement is over and done with, we could consider making day-first the standard Wikipedia-wide. Hawkeye7(discuss)13:11, 23 May 2021 (UTC)
" Most of our readers use the DMY format all the time", sorry but I stopped reading after that. Guess we'll have to agree to disagree, probably on whatever else you wrote also. Herostratus (talk) 15:59, 23 May 2021 (UTC)
Sounds like an uncontroversial statement to me (or at least it would be if rephrased to say "... most of the time"). What is your reason for questioning it? Dondervogel 2 (talk) 16:23, 23 May 2021 (UTC)
It's an opinion, and as such it does not need a citation. There are approximately 2 billion English speakers, of which about 300 million are Americans. It is rare to encounter MDY outside the US, so it is reasonable to assume most English speakers use DMY. I accept that the proportion of en.Wikipedia readers is larger in the US than in (say) Bangladesh, so it is still possible there are more en.Wikipedia readers who are MDY users than DMY, but it does not seem likely. My point is that Hawkeye7's opinion is a reasonable one to hold. Dondervogel 2 (talk) 21:10, 23 May 2021 (UTC)
And of course, as generally the more comprehensive, the English WP will also be read by many with English as a second or other language, as well. MapReader (talk) 21:22, 23 May 2021 (UTC)
Let's please not re-litigate the whole idea behind ENGVAR. Any rationale that points at devaluing American English compared to Commonwealth English is not going to fly. The case of dates is somewhat separate because of the "logical" weirdness of MDY, which is neither big-endian nor little-endian but "middle-endian" as it were. My guess at the reason for MDY is that it becomes big-endian if you omit the year, and the year is often optional because it's clear from context. It feels a little weird to start a date with an optional piece of information, so we put it at the end. The "most logical" format in some sense would be YMD, but few find it appealing outside of computer-ish applicatons. --Trovatore (talk) 18:58, 8 June 2021 (UTC)
The reason for the widespread adoption of the day first format is that it reduced errors, especially those caused by missing or misplaced commas. That's a good, practical reason, and why day-first would be adopted if we had to standardise on one format; but its not an overwhelming one. As EEng has pointed out in the past, it's not like people cannot read both forms when they are properly formatted (and we have banned ambiguous date formats). On Wikipedia we recognise that article writers have to do some cross-braining when sources are in one format and they are writing in another; hence the acceptance of the use of different formats in different contexts. What we don't accept is people edit warring to enforce their personal preferences. Hawkeye7(discuss)22:24, 23 May 2021 (UTC)
Hey Hawkeye do you know which year the US military has adopted this usage in WWII? And if let's say the year is 1942 right, does that mean every notable American soldier who dies before that year has to be used the old system or does the US military also convert them into the current system? Another question here is, which system should every American soldier's article who started before the adoption and dies after the adoption use? The old, the new ones, or both of them with the same system like Old/New Styles? Thus the old system is used until the adoption. I don't know what the US military's policy is if it's talking about these. Cheers. CPA-5 (talk) 13:05, 25 May 2021 (UTC)
Which is correct, and why? When embedded in a sentence, "nine minutes and 29 seconds" or "9 minutes and 29 seconds". Thanks, WWGB (talk) 22:57, 13 April 2021 (UTC)
To my surprise there's nothing on this. Boldly added [50], subject to the approval of my esteemed fellow editors. EEng02:27, 14 April 2021 (UTC)
Totally off-topic (also WP:NOTFORUM yadda yadda) but yesterday I was enquiring about some surgery I could do with and was told, "The cost of a consultation is £220.00 and surgery starting from £2,3080.00." (sic) So I wrote back, "Can you please confirm the cost of surgery? £23k seems excessive! Perhaps you meant £230.80?" To which she replied, "That is 2,3080.00 not 23k? Two thousand three hundred and eighty". Honestly, you just can't get the staff these days. nagualdesign04:34, 15 April 2021 (UTC)
Bringing it on-topic: I reject any proposal that we write two thousand three hundred eighty as 2,3080 on Wikipedia. Largoplazo (talk) 11:08, 15 April 2021 (UTC)
nagualdesign, is it possible that the person in question grew up in a culture that grouped digits differently? although i think someone dealing with monetary transactions should probably be expected to have a good grasp of numbers, i admittedly also have trouble working with large numbers in systems i am not adept in, even though i like to think i am mathematically inclined. i wonder what she would have written if you had asked her to write out "twenty-three thousand eighty" in numerals. dying (talk) 10:47, 26 May 2021 (UTC)
The digit grouping wasn't the problem, it was the extra zero in the middle. I'm not aware of any cultures that insert extra digits into decimal notation. Although I don't think her misunderstanding of how to write numbers was unique either. I guess twenty-three thousand and eighty would be "23,0080". nagualdesign17:47, 26 May 2021 (UTC)
i believe you are correct; i am also unaware of any cultures that insert extra digits into decimal notation, aside from leading or trailing zeros. i was merely wondering if it was a temporary cognitive issue related to how we parse numbers, which seemed far more interesting than a simple incompetence issue with copying numerals. my conjecture was that she had mentally stored that number as 2.3x+80, where x was 1000 when she first encountered it, but 10000 when she wrote it down for you. this would also explain why she had said the cost was "[t]wo thousand" and not "23k", with "thousand" and "k" standing in for x when numerals were not being used. her error seems fascinating to me, as understanding why we make cognitive errors allows us to understand how the brain works in the first place.in any case, we are now wildly off-topic, so i apologize for the distraction. dying (talk) 22:16, 16 June 2021 (UTC)
WWGB, i'm assuming that this is a reference to how long derek chauvin knelt on george floyd's neck, correct?at one point, there was heated debate over the title of the article Eight minutes 46 seconds, the length of time chauvin was originally believed to have knelt on floyd's neck. unfortunately, it looks like this title now violates the new guideline. (note that the word "and" is not present in the article's title, although i am not sure if this had any impact on whether the numbers were spelt out. my conjecture is that it is merely a dialectal idiosyncracy.)personally, i preferred not having a guideline addressing this situation, as i can easily see situations where i would prefer spelling out one number and using numerals for the other, situations where i would prefer spelling out both numbers, and situations where i would prefer using numerals for both. in practice, there seems to be a lot of variance on this issue, so i don't know if establishing a standard here would overall have a positive effect.do you think having a guideline on this issue is a good thing? if so, is this a proper guideline to have? dying (talk) 10:47, 26 May 2021 (UTC)
There was a discussion here in 2017. You participated, but it still didn't reach any conclusion, so there was an RFC at the article in dispute but the only thing everyone could agree on was that we shouldn't express every time in an article in both systems eg 3.00pm (15:00). That article now uses 24-hour times in the three instances I saw (which you might not want to double-check, it's a grim article about a terror attack). NebY (talk) 20:35, 2 May 2021 (UTC)
It might have been good to have an ENGVAR type rule. "An article on a topic that has strong ties to the English language, an English-speaking nation, or the Anglosphere generally should use the 12 hour clock, otherwise the 24 hour clock". But that's not likely to happen. A lot of Wikipedia editors are from Europe or whatever, or if from the Anglosphere are educated, and they don't really believe that many Americans have no idea what "the explosion was at 14:47" means. It's true, but try telling that to a Wikipedia editor. So forget it, it's not in the cards.
I don't if Europeans etc. scratch their heads at "2:47pm". If they do, we should have a conversion program as we do for meters/feet. If they don't, the best we hope for is stare decisis: let the originating editor decide. Hopefully people are leaving articles as they found them; going around changing 12 hour time to 24 or vice versa (unless it's to make the article self-consistent) is pointless and should be rolled back on principle. Herostratus (talk) 23:50, 3 May 2021 (UTC)
I was born in England and have lived there for nearly 30 years, but I struggle to understand "12:15 am". I don't know whether it means 00:15 or 12:15. Any time between 12:00 and 12:59 (whether am or pm) would need to be disambiguated with its 24-h equivalent, regardless of subject matter. Dondervogel 2 (talk) 00:04, 4 May 2021 (UTC)
No need to struggle with 12.15 am. The “am” is an abbreviation for “ante meridian” (“before noon”) so it can only be 15 minutes after midnight. The only nonsense uses of am and pm are 12.00 am and 12.00 pm, which mean different things to different people. WWGB (talk) 02:54, 4 May 2021 (UTC)
Happy to oblige. But if you order doughnuts at 12:01 pm, don't be surprised to be served at one minute after midnight. Dondervogel 2 (talk) 06:03, 6 May 2021 (UTC)
If it really is true that some people really do struggle with "2:15am" while others struggle with "14:15", then we really should have a conversion function. The code should be pretty easy. "The Wikipedia editor flung his laptop against the wall at 14:15 (2:14 am in freedom time)" and like that. Herostratus (talk) 18:20, 4 May 2021 (UTC)
As an American who prefers and uses 24 hour time, I am CONSTANTLY dealing with people who do not understand it. I once had someone tell me that they didn't like 24 hour time because they couldn't tell if 14:00 was a.m. or p.m. .... I mean, that's kind of the entire point of 24 hour time, that you don't have to figure that out. --Khajidha (talk) 18:29, 4 May 2021 (UTC)
@WWGB: I see every reason to be confused. Time does not stop at 11:59 and magically resume 2 min later at 12:01. My entire primary and secondary educations were delivered at British schools. I was first taught the 12-hour clock and accepted it for what it was (that's just how grown-ups do things). Then I was taught the 24-hour clock, at which point I realised not all grown-ups are alike. Some care about making themselves clear and some do not. Dondervogel 2 (talk) 06:25, 6 May 2021 (UTC)
It looks like Tony1 inserted the "context determines" language 14 years ago. To be honest, unless someone can point to trouble that there's been (on actual articles) that a more specific guideline might have avoided, I suggest we just leave things be -- see WP:MOSBLOAT. EEng00:22, 22 June 2021 (UTC)
Is there a consensus as to whether BCE and CE (or BC and AD) should be wikilinked on first use (and if so, should it be stated here)? Dave.Dunford (talk) 17:27, 8 June 2021 (UTC)
I would hope everyone would agree that they should not be wikilinked, and I don't think it's necessary to mention it here, unless we see it happening a lot. Should be covered by WP:OVERLINKING. --Trovatore (talk) 17:48, 8 June 2021 (UTC)
I disagree. CE and BCE are utterly obscure to most members of the public – our readers – and should be linked on first use. Sweet6970 (talk) 11:58, 9 June 2021 (UTC)
@MapReader: I’ve declared on my Userpage that I’m a grumpy old woman. Old people are allowed to read Wikipedia. But in fact, my experience is that CE and BCE are only known to people who have recently studied ancient history. This is not our audience. Sweet6970 (talk) 13:29, 9 June 2021 (UTC)
There are already about 6,500 direct or indirect links to Common Era, but there may be five to eight times as many articles using BCE.[51][52] (The count of links and the other two searches include some uses on talk or project pages, while the latter counts include other uses of "BCE" but exclude use of "CE" in dates. Still, they give some idea of the magnitude.) So I don't think there is a working consensus on wikilinking them. NebY (talk) 14:26, 9 June 2021 (UTC)
It makes sense to use BCE and CE for all history that isn't focused on Christian populations, and I encountered it routinely in my classroom texts on Jewish history 50 years ago. So I'm surprised by conceptions I'm seeing here that only young people studying recent histories are likely to be familiar with it or that it's specific to Greeks and Romans. These implied restrictions on the likelihood that a reader has encountered this convention before are invalid. Nevertheless, it's a given that they're less known and, for that reason, a link doesn't hurt. In particular, I think it's a good idea because it might reduce the frequency with which readers think they're a mistake and try to fix them. Still, in the guidelines, I'd present it as a recommended practice. Largoplazo (talk) 15:55, 9 June 2021 (UTC)
I think that's not what links are primarily for. The purpose of a wikilink is to give interested readers an easy way of delving in more detail into a subject mentioned in the text. They should appear in parts of the text where it's a natural place to want to know more about that thing.
The first occurrence of a date is not usually a natural place to want to go and learn more about dating systems.
Links that are there, not because it's a good place to go and learn more, but simply because we think readers might not know what a word or abbreviation means, are usually bad. I'd say even mildly insulting. There are cases where I can see practicalities overriding that general principle, but I don't think this is one of them. This is a serious encyclopedia, and readers can be expected to know what BCE means. --Trovatore (talk) 20:01, 9 June 2021 (UTC)
Indulging myself in a further observation here — when there is a genuine concern that an article isn't readable without defining a term, a wikilink is not sufficient. The term must be glossed inline. Remember that articles can be printed, and then you don't see links. --Trovatore (talk) 20:08, 9 June 2021 (UTC)
No, it doesn't "defeat the purpose of links". Definition is not the purpose of links, as I was at some pains to explain above. Links should be put in natural places to go explore a topic, not because readers might not know what the word means. If they might not know what the word means, you should say something inline. --Trovatore (talk) 21:39, 9 June 2021 (UTC) (But "might not know" doesn't just mean "some hypothetical reader may not know", but only "even a reasonably educated reader can't follow without it".) --Trovatore (talk) 21:42, 9 June 2021 (UTC)
MOS:UNDERLINK says it is okay to link "Articles explaining words of technical terms, jargon or slang expressions or phrases—but you could also provide a concise definition instead of or in addition to a link. If there is no appropriate Wikipedia article, an interwikimedia link to Wiktionary could be used."
MOS:OVERLINK says it is better to not link "Everyday words understood by most readers in context (e.g., education, violence, aircraft, river)".
CE and BCE are still mostly used by historians and are still largely unknown by the general population. Maybe they will become more wide spread or maybe they will disappear as a fad. So currently they should be considered as jargon words that can be linked on first usage. I agree that inline explanations clutter up the article and take my mind away from the main topic. If I don't know a term I prefer to chase it down in a time of my choosing (probably by following the link immediately). But if I already know the term then I don't want to pedantically plough through an explanation. Stepho talk22:20, 9 June 2021 (UTC)
I think we need to understand "everyday" in a bit of an elevated sense here; otherwise the encyclopedia risks losing a scholarly tone. Not words you'd necessarily use every day in a supermarket, but ones you might expect to encounter every day if you're taking a university class, say. I don't think it's true that CE and BCE are "largely unknown by the general population", at least the educated population. --Trovatore (talk)
"Everyday" means what the common person would understand. Not necessarily baby talk but requiring our readers to be at least as good as university students isn't helpful. May as well write it in Shakespearean or Chaucerian English. Stepho talk11:12, 10 June 2021 (UTC)
‘readers can be expected to know what BCE means.’; ‘reasonably educated reader’; ‘taking a university class’; ‘the educated population’Trovatore seems to want to exclude people from reading Wikipedia unless they match his arbitrary standard for being “educated”. This is against the whole purpose of Wikipedia.Sweet6970 (talk) 11:24, 10 June 2021 (UTC)
Not at all. Wikipedia's for everyone. But it should be pitched fairly high — think Brittanica, not World Book. So some readers might have to put in some extra effort. Doesn't mean they're not welcome; just we're not going to hold their hands. --Trovatore (talk) 17:25, 10 June 2021 (UTC)
It's a point I've made several times before, and in several contexts. An encyclopedia is a formal work of reference written for literate adults, without presuming any detailed domain knowledge on the part of its readership. Thus we should not presume our readers, in an aviation-related article, would know what KTAS means, because it's never used in other contexts. An understanding of standard terminology for expressing dates and times should be taken for granted, however. We cannot practicably cater to everything every reader might not know, and we also have reasons to avoid wikilinkitis.
I would very strongly dispute that CE/BCE are "obscure"; in many non-Christian-focussed works of history, they are standard terminology. I was aware of them before WP was a thing (I was quite possibly taught them in school), so I do not think, two decades later, WP is committing a sin by presuming readers are likely to know what they mean, or by introducing them to unfamiliar terminology. FWIW, there are actually people out there who will try to ban the use of terminology they dislike by claiming that doing either of these things – typically with completely and uncontroversially standard terms like "kilogram" – amounts to original research or pushing a point of view. And I wish I was joking. Archon 2488 (talk) 09:53, 14 June 2021 (UTC)
It is unreasonable to assume that the general public know what BCE and CE mean, when several editors have said otherwise. Whether it is a sin to be unreasonable is a matter of opinion. But the original question was about linking. If we are to link the terms BCE and CE, then we would be introducing them to unfamiliar terminology, which presumably Archon 2488 would be in favour of (?) Sweet6970 (talk) 10:46, 14 June 2021 (UTC)
I specifically meant introducing without glossing, i.e. editors writing the articles taking it as read that their readership would be familiar with the terminology used, only to end up "introducing" them to new terminology inadvertently. We have, however, heard that introducing people to new terminology (q.v. IEC binary prefixes, "promoting" metric units, any number of other interminable MOSNUM discussions) is not a legitimate goal of WP; perhaps not, but I'd argue that it is an inevitable side-effect, as not every reader will be familiar with even every piece of standard non-jargon terminology.
Editors have also, very incorrectly, implied that CE/BCE might be a "fad" which will disappear. Given that the terminology is four centuries old and shows no sign of becoming less common, one would presume not. FWIW I have come across people arguing in the past that consistent use of 24-hour time formats is asking too much of our readership, which does start to raise the question of what reading age we are actually writing for. But I'd argue that this question can be resolved in a fairly NPOV way: what is the practice of reputable historical reference works IRL? If they feel the need to avoid CE/BCE (and IMHO they don't), or if they feel compelled to gloss them on first use (I am less certain of this, but I am doubtful), then fair enough. However, I don't see a compelling reason why WP editors should be forced to adopt a practice that does not exist in other comparable reference sources. Archon 2488 (talk) 10:59, 14 June 2021 (UTC)
I don't think any of us is suggesting WP should stop using CE/BCE notation, just that some of us (myself included) do not understand it because at school they were taught AD/BC (or in some cases, perhaps AC/DC). So, continue to use it and link on first use. Dondervogel 2 (talk) 11:12, 14 June 2021 (UTC)
I guess my final opinion is that (B)CE is standard notation in relevant English-language media and it is non-domain-specific – as opposed to AH and AUC, which you would gloss when used in appropriate contexts (Islamic and Roman history), and provide a conversion – which you don't need to do here, because CE/BCE are exact equivalents of AD/BC. Moreover, they're pretty unambiguous. If we say that Kennedy was shot in 1963 CE, who is really gonna think "wow, America had presidents during Egypt's Twelfth Dynasty"? Archon 2488 (talk) 11:41, 14 June 2021 (UTC)
Archon 2488 (talk·contribs), unfortunately it's neither obscure, nor common but is in that grey area where some know and some don't.
BCE/CE may not be a fad, but over four centuries is an awfully long time for it to not gain dominance.
Also, it's not a Christian vs non-Christian thing. I did some courses at Bible College circa 2000 and they taught all the history courses using BCE/CE. But the typical man-in-the-street still uses BC/AD and you can see their eyes glaze over a little as they try to process BEE-SEE-EE. A bit like when the hospital says your friend is ambulatory - not an obscure term but still not an everyday term. It's a historian vs common usage thing. Stepho talk11:21, 14 June 2021 (UTC)
I know it's not specifically "a Christian thing", not least because the terminology was invented by Christian scholars in 17th Century Europe. It is however widely used as a more "neutral" alternative, because it doesn't have overt religious connotations, and merely acknowledges that the Christian calendar (for a slew of historical reasons) has become the de facto international standard for reporting dates. As for standard medical terminology – would WP not use this in appropriate contexts, such as where it'd typically be used IRL? Archon 2488 (talk) 11:41, 14 June 2021 (UTC)
Link CE and BCE, but probably not BC and AD. To say "It makes sense to use BCE and CE for all history that isn't focused on Christian populations" is wrong - for example BC and AD are what general Indian readers are used to, and most don't understand CE and BCE. I only use BCE/CE in articles with a strong Islamic or Jewish connection, and maybe Chinese. Read Common Era for an understanding on where the world (as opposed to the post-graduate common room) stands on this. Johnbod (talk) 22:54, 9 June 2021 (UTC)
The MoS is clear in BC/AD vs BCE/CE and it has nothing to do with what religion is being discussed. Its all about retaining styles. In other words, if the original author used CE/BCE, it stays. If the original author used BC/AD, it stays unless there is substantial reason to change it. Oh, and no mixing styles. Masterhatch (talk) 15:22, 14 June 2021 (UTC)
Indeed, but, as shown above and very often elsewhere, many editors think 'not being about a Christian topic' is a "substantial reason". I don't agree, with some exceptions I give above, but this is a widely held view (as is 'my professor says everybody does this now'). Johnbod (talk) 03:23, 20 June 2021 (UTC)
I think that can be handled by the editors of the specific article. As a general principle, RETAIN doesn't mean you have to show one of some particular set of reasons to change something; it just means, with some enumerated exceptions, you shouldn't change it without consensus. To put it another way, "no consensus" defaults to the status quo ante.
If your reason for wanting to change the era style is not one that we'd want to codify once and for all as good enough to change it, but you can get consensus at that particular article to change it, then fine. --Trovatore (talk) 06:04, 20 June 2021 (UTC)
Not really, as that would lead to endless "era-wars" with roving bands of partisans. As it is, most regulars stick firmly to "first use" to avoid this, with moderate success. I'm not seeing too many editors here who regularly edit "ancient world" stuff; experience of the actual state of play may be lacking. Johnbod (talk) 15:48, 22 June 2021 (UTC)
I think it's extremely unlikely that "roving bands of partisans" would ever achieve alternating consensuses at a given article. It's very hard to get consensus to make such a change for non-enumerated reasons even once. The only case I can think of is cheque, where it was argued that the Commonwealth spelling should be preferred because it was unambiguous, whereas check has lots of other meanings. I didn't agree (or wouldn't have, if I'd been there for the argument), but I thought it was a valid exercise of editorial discretion in the Wikipedian adhocracy. --Trovatore (talk) 06:19, 23 June 2021 (UTC)
Ok, you clearly don't have much experience of "ancient world" stuff, which has tens of thousands of articles by now-vanished authors & with few if any watchers; main topical articles in that area aren't aren't much better. You wouldn't need a big band. Johnbod (talk) 01:27, 24 June 2021 (UTC)
Just re-read my post and to clarify, original authour means original creater of the article, not author of the material being sourced. Masterhatch (talk) 15:42, 14 June 2021 (UTC)
BCE, CE, BC, and AD should definitely not be linked. If someone doesn't know what they mean (really?), they can type two or three characters into the box. We should not be a dictionary for seven-year-old users. Tony(talk)07:42, 23 June 2021 (UTC)
I wonder – do you ever watch the BBC’s programmes on archaeology and ancient history? Do you ever read the Guardian? Do you ever look anything up on the British Museum’s website? You will find that these organisations all use BC and AD. This is not because they think that their viewers/readers are ignorant – it’s because BC and AD are standard usage, and BCE and CE are largely unknown to the general public. So BCE and CE should be linked on first usage. And since some Wikipedia editors claim that BCE and CE are now standard, it would also be a good idea to link BC and AD. Sweet6970 (talk) 10:22, 23 June 2021 (UTC)
In my view this comment perfectly encapsulates everything that is wrong with this proposal (no offence to you) – it is a prescription for wikilinking without end. I accept that BC/AD are more common terminology (though in a good deal of academic history literature – with the caveat that I am not an historian – I can imagine that [B]CE is the predominant usage, and WP should probably reflect that), but if this discussion has reached the point where we are being suggested to link even this, what constrains when we link such terminology? Archon 2488 (talk) 10:34, 23 June 2021 (UTC)
Basically, I agree with Tony. I feel the threat of devolving into Wikilinkitis outweighs what I see as the very marginal benefits of being told to link yet one more term; we cannot cater to everything a reader might not know, which is an absurdly long list of things. Same principle as why we don't link common units of measurement; >99.99% of readers on an article about physical geography will not need to look up the definition of the kilometre. Sometimes you just have to expect an adult to do some work for themselves; there isn't an unlimited right to editorial hand-holding, as editors have TBQH more productive ways to spend their time.
And I suspect any decision made here will have little effect in practice, because most editors will not even think to check the MoS as to whether they are in principle supposed to link such a common notation (and I see little evidence of this actually being problematic in article-space). And again, we are not proposing (have never proposed AFAIK) using (B)CE in contexts where it isn't already established terminology off-wiki. Archon 2488 (talk) 10:30, 23 June 2021 (UTC)
Agreed, both about the Wikilinkitis and the comparative ineffectuality of the MOS on this. Worst case would be to change the MOS to require wikilinking and see enthusiastic consequent disruption across the 'pedia. It's not even as if BCE pops up a quick tooltip or converter. NebY (talk) 19:41, 23 June 2021 (UTC)
Yes, User:Tony1, really! I'm trying to imagine the world you live in, where everybody knows what "CE" means. Very different from the Australia one sees in media, for sure. One editor a while back did a survey of his well-educated family for a similar discussion - predicably, many didn't know. Go to India, & not understanding the term is very widespread indeed, as the media never use it. Next time someone asks on a talk page I'll send them your way. Johnbod (talk) 01:26, 24 June 2021 (UTC)
Intent is to create an overt reference that W–L (or W–L–T) team records in sports, such as for a specific team or a head coach, use {{ndash}} rather than a hyphen as the delimiter between the numbers. Agreed, this specific section may not be the correct or ideal location.
Existing text:
Sport scores and vote tallies should be given as figures, even if in the zero-to-nine range (a 25–7 victory; and passed with 7 ayes, 2 nays, and 1 abstention).
Proposed text
Sport scores, sports won-loss records, and vote tallies should be given as figures, even if in the zero-to-nine range (a 25–7 victory, a 16–0 season, and passed with 7 ayes, 2 nays, and 1 abstention).
This convention is without controversy and already in near-universal use such as the Infobox:
En dash guidance should be added at MOS:ENBETWEEN, which currently reads:
a 51–30 win; a 22–17 majority vote; but prefer spelling out when using words instead of numerals: a six-to-two majority decision, not with the awkward six–two; avoid confusingly reversed order: a 17–22 majority vote[a]
I don't know if I've ever seen a sports record spelled out as opposed to with en dash, aside from occasionally a seven game (or fewer) series, e.g. "won the series four games to three", in which case the numbers are always <=9 and spelled out.—Bagumba (talk) 04:41, 1 July 2021 (UTC)
I wonder about the use of older units, when references use such units. In the current case, I am wondering about Mc/s (or more commonly just Mc with implied /s) for early articles on radio. Since radio was developed before the Hz unit, the older references don't use Hz. It seems to look nice using the appropriate unit to match the reference, and since the number doesn't change, it doesn't make it harder to read. But also, I didn't see anything mentioning older units here. Gah4 (talk) 23:33, 9 July 2021 (UTC)
Thanks. That seems to be for radio stations, where the articles I was looking at are on actual radio history. That is, more technical, and also readers are more likely to go read the old references. Also, I suspect less likely to be confused by the notation. In any case, thanks for the link. Gah4 (talk) 00:17, 11 July 2021 (UTC)
Fair point about being radio history. But in the same way that articles on ancient Rome don't do measurements in stadia, I would still keep to megahertz instead of megacycles. Perhaps a single mention near the top that says megacycles is the old equivalent terminology for megahertz. The type of people that follow up the old references are the type of people that can translate the terminology. Likewise, the type of people that have trouble translating also typically do not follow up the references. Stepho talk00:33, 11 July 2021 (UTC)
Absolutely stick to megahertz only, including substituting [megahertz] in quotations. To confuse the reader with cycles would be like saying the Declaration of Independence promises the Purfuit of Happinefs. EEng00:52, 11 July 2021 (UTC)
Metric tonne
Comments are requested at User talk:Mitch Ames#Metric tonnes to help resolve a disagreement as to whether "metric tonne(s)" should be replaced by "tonne(s)". Mitch Ames (talk) 09:33, 18 July 2021 (UTC) Cite error: There are <ref group=lower-alpha> tags or {{efn}} templates on this page, but the references will not show without a {{reflist|group=lower-alpha}} template or {{notelist}} template (see the help page).
. –Deacon Vorbis (carbon • videos) 15:32, 5 January 2020 (UTC)
Facepalm –Deacon Vorbis (carbon • videos) 23:06, 5 January 2020 (UTC)
. TIA - DVdm (talk) 11:39, 26 March 2020 (UTC)
. –Deacon Vorbis (carbon • videos) 13:24, 3 August 2020 (UTC)
: Yes, I know you are trying to choose between 2 strong ties. However, your proposal to replace "strong ties" with "strongest ties" will eventually be interpreted by somebody as also allowing them to choose which is the strongest of any 2 ties - including choosing between 2 weak ties. Human nature - it will happen. Also, if there are 2 "strong" ties then that really shows that neither really is a strong tie. If either tie was strong then it would dominate over the other and we would only have 1 strong tie. I would be more tempted to replace "strong tie" with "dominating tie". Stepho talk 22:25, 31 August 2020 (UTC)
.jpg)
. A thing of beauty, really. EEng 17:14, 14 December 2020 (UTC)
You are invited to join the discussion at Wikipedia talk:WikiProject Higher education § How to refer to semesters?. {{u|Sdkb}} talk 07:24, 21 December 2020 (UTC)
A discussion is taking place to address the redirect MOS:×. The discussion will occur at Wikipedia:Redirects for discussion/Log/2021 March 23#MOS:× until a consensus is reached, and readers of this page are welcome to contribute to the discussion. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 (𝗍𝗮𝘭𝙠) 12:08, 23 March 2021 (UTC)
