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

Archive 155

←

Archive 160

Archive 161

Archive 162

Archive 163

Decimals when quoting time periods?

There is a debate here about whether it's acceptable to use decimals when discussing a timeframe in a person's life, e.g. "he was a prisoner for 39.5 years". Personally I think this the sort of thing you'd expect to see in a science article, not a person's biography. However, the MOS here doesn't seem to cover this circumstance. Thoughts? Muzilon (talk) 09:01, 13 January 2023 (UTC)

To include the voices from that article's talk page: Dondervogel 2 (talk · contribs) and I agree that decimalized years in prose are a "normal practice in English" (the specific charge by Muzilon). I originally wrote the body to say He was instead held prisoner in North Korea for 39.51 years; Dondervogel 2 and I concur that rounding that to the tenth is better. — Fourthords | =Λ= | 14:41, 14 January 2023 (UTC)

You have not included all the voices from that article's talk page. To repeat (with a slight addition thus), expressing a period of time in a person's life in decimal years, and to the nearest 0.01 years at that, is not normal practice in English. The source's phrasing is common practice when wishing to add emphasis and drama, and the tone of that paragraph (and the entire report) is dramatic: For 39 years, six months and four days, he was trapped in a bizarre Stalinist state — hungry, suffering, told by the government how to live, what to read, and even when to have sex. Never before has an American lived among the secretive North Koreans so long and escaped to tell the tale. We don't use such a tone in our encyclopedia, nor do we use phrasing which would be natural in speech ("thirty-nine and a half a years"), nor do we treat a period of someone's life as a measurement (unlike "completed in 39.51 seconds"). Instead, and especially in a brief summary such as a Wikipedia:LEAD as well as in the body of the article, "over 39 years" and "nearly 40 years" are both good English and both communicate quite enough to the reader without tripping them up. NebY (talk) 15:01, 14 January 2023 (UTC)

I am so sorry! In my quick look, I thought only myself, Muzilon, and Dondervogel 2 were participating. Hell, I even assumed Muzilon—in their zeal— was the original editor who'd changed the text: IACOBVS (talk · contribs). I promise that was unintentional. In the moment, I absolutely thought there were only three voices.

expressing a period of time in a person's life in decimal years, and to the nearest 0.01 years at that, is not normal practice in English. As for that, I can't help but assume that you are the authority for "normal English", and that others' contradictory experiences are invalid. 'over 39 years' and 'nearly 40 years' are both good English and both communicate quite enough to the reader without tripping them up. Using the phrase "over 39 years" includes both 40 and 400 years, and suggests that the specific amount of time is actually unknown. Whose interpretation of "nearly 40 years" equals "six months less than"; could it be interpreted by readers to mean 38 years or 43 years (and again it suggests that the specific amount of time is actually unknown)? Also, I don't understand how one "trips up" a reader with specific decimalized years in prose; can you elaborate on that (is it related to MOS:ACCESS)? — Fourthords | =Λ= | 15:29, 14 January 2023 (UTC)

I absolutely thought there were only three voices? Really. Yesterday you replied to me, saying My admittedly-amateur-yet-extensive experience with "normal practice" in the English language doesn't jive with yours.[1]

The ordinary reader is not going to understand "over 39 years" as 400 years, or nearly 40 as 38 or 43. You of course are free to try to misread it that way, but that's not who we write for.

We trip the reader up when we phrase things in ways that the reader has to stop and decode. NebY (talk) 16:20, 14 January 2023 (UTC)

I agree with NebY, it is not normal to express periods in a person's life in decimal years. The only exception I can imagine is if one is doing some kind of calculation involving several such periods. Jc3s5h (talk) 19:07, 14 January 2023 (UTC)

Really. Yeah, and I appreciate your continued assumption of good faith. — Fourthords | =Λ= | 15:42, 15 January 2023 (UTC)

A cursory search of Wikipedia turns up sentences like:

• "It took him about 1.5 years to license the rights."
• "He denied 92% of all clemency requests during his 10.5 years as governor."
• "He wrote and edited the community's newsletter for 16.5 years."

As I suggested in the original discussion, perhaps this is a feature of certain dialects of English (or languages other than English), but I'm not familiar with it. Much less using two decimal places for life events. Muzilon (talk) 22:36, 14 January 2023 (UTC)

You must be mistaken. Such uses would be abnormal English, would inappropriately treat a period of someone's life as a measurement, and would trip up anyone who tried to read it. If they're actually at these articles to be found by the public, should these three instances of vandalism be reported? — Fourthords | =Λ= | 15:42, 15 January 2023 (UTC)

I wouldn't know what national variety of English you speak, but I note that at least one of those articles is written in Indian English. Maybe this usage is acceptable in some English dialects, but not in others. Muzilon (talk) 06:26, 17 January 2023 (UTC)

This conversation is becoming more and more bizarre. It is not even remotely unusual to express a period of someone's life as N.5 years, with N an integer. It is very easy to find multiple examples of this in mainstream news media such as BBC (647,000 hits for "2.5 years" alone) or CNN (683,000). Here's just one example, from the BBC, describing the periods 9.1 years, 1.5 years and 2.5 years. Dondervogel 2 (talk) 15:56, 15 January 2023 (UTC)

9.1 years, 1.5 years and 2.5 years aren't continuous periods akin to 39 years, six months and four days ... trapped in a bizarre Stalinist state, they're total times spent watching TV, in the bathroom and cooking in some "average" life. NebY (talk) 21:12, 15 January 2023 (UTC)

I don't see why the continuity matters. Still, it was just one example. It's not hard to find more:

1. Children aged up to 2.5 years are assessed for healthy weight and nutrition during universal visits
2. police officer Thomas Lane sentenced to 2.5 years in prison
3. scam mastermind sentenced to 3.5 years
4. Alexei Navalny sentenced to 3.5 years in prison
5. Held by Somali Pirates for 4.5 years
6. Rodrigo Rato gets 4.5 years for embezzlement
7. it takes on average 6.5 years for men to receive a diagnosis and 8.8 years for women

How many more do you need? Dondervogel 2 (talk) 21:44, 15 January 2023 (UTC)

I suspect that those examples really ought to be 2+1⁄2 ({{frac|2|1|2}}) years and are only written as "2.5" to avoid using "2½". Martin of Sheffield (talk) 21:52, 15 January 2023 (UTC)

That works for 2+1⁄2 (and for 39+1⁄2 while we're at it), but I've never seen 9+1⁄10 years or 8+4⁄5 years. That would be weird. Dondervogel 2 (talk) 21:58, 15 January 2023 (UTC)

Exactly. All except the last examples above are "... and a half". It would also be sensible for "... and a quarter". (2+1⁄4 for example.) Anything else should normally be expressed in with months/weeks/days and reserve the decimals only for mathematical and statistical use. Martin of Sheffield (talk) 22:14, 15 January 2023 (UTC)

@Martin of Sheffield: All of the examples are "... and a half" ... except for the ones that are not (9.1 years, 8.8 years). How would you write those? Dondervogel 2 (talk) 23:02, 16 January 2023 (UTC)

Oops, yes I did miss the 8.8 years, I just saw the 6.5 years for men (the 9.1 wasn't on your list though). Your last example is noticably different from the preceding six. They are all fixed preriods of time whereas the seventh is the result of a statistical calculation. You might note the phrase "and reserve the decimals only for mathematical and statistical use" above. Martin of Sheffield (talk) 09:31, 17 January 2023 (UTC)

In that case I think you and I agree. In the original context I have no objection to replacing "39.51 years" with "39+1⁄2 years". (The 9.1 years was from a previous link to a BBC article, also about statistics). Dondervogel 2 (talk) 11:38, 17 January 2023 (UTC)

The first and last of Dondervogel 2's seven examples are the result of statistical calculations, so really aren't the same as using a decimal fraction to refer to one period in the life of one individual. Jc3s5h (talk) 22:25, 15 January 2023 (UTC)

I assume everyone here would agree that decimalized years are commonly used when dealing with science, demographics, and statistics. And yes, newspaper headlines use it for prison sentences – but see WP:NEWSSTYLE. The specific debate here is whether it's appropriate to use it in biographical prose dealing with events in an individual's life. In my dialect of (Commonwealth) English, it's not standard to write "Jenkins lived as a prisoner in North Korea for 39.5 years" (let alone 39.51). (Per MOS:TIES, the Jenkins biography should probably adhere to US English in the event of a dispute over WP:ENGVAR.) Muzilon (talk) 00:19, 16 January 2023 (UTC)

Just my native speaker of American English intuition (who just happens to have a PhD in Linguistics), but I find "39+1⁄2 years", "more than 39 years", and "almost 40 years" much more natural in the given context than "39.5 years". Even "39 years and 6 months" is better than "39.5 years", although I like it less than the first three choices. - Donald Albury 14:40, 16 January 2023 (UTC)

Count me as another who thinks expressing years in decimals is a strange and unnatural sounding practice for anything outside of a statistical analysis or other similar mathematical or scientific use. It's just not how people discuss years because years aren't divided in to easy decimal divisions. They're divided into 12 months, not 10. And while "and a half" and "and a quarter" are used because 12 divides into halves and quarters easily, that has a certain informality in writing that may not be appropriate for an encyclopedia. Plus there's fact that it's over-precise to attempt to express that period as a decimal. Frankly, there's zero reason anyone would unless they have a poor grasp of the language. oknazevad (talk) 18:20, 16 January 2023 (UTC)

There're a lot of claims here as to what's normal, common practice, unencyclopedic, professional, tripping, the average reader's understanding, sensible, and intiutive. However, as we're all editors of the English Wikipedia: do we have any reliable sources? A lot of our MOS rules have been derived from preexisting standards; should we not cite similar when writing (or arguing about) new MOS guidance regarding decimalized years in biographies? (For what it's worth, I don't have a preference—except to lean towards precision when we have it; I disputed being told my experiences, exposure, and use of the English language are abnormal and not to be duplicated, especially in the absense of an MOS consensus.) — Fourthords | =Λ= | 22:40, 16 January 2023 (UTC)

As the editor who first used "39.51 years"[2] and reinstated it,[3] can you cite a pre-existing standard supporting such usage? NebY (talk) 13:33, 17 January 2023 (UTC)

I don't understand the question. Are you asking if I have that for which I, myself, am asking? If so, I don't: that's why I asked. — Fourthords | =Λ= | 13:59, 17 January 2023 (UTC)

The consensus thus far seems to be that decimalized years - especially with two decimal places - are not standard in biographical prose and should be limited to a statistical/mathematical context. Can you, as a minority voice, produce something from the Chicago Manual of Style (or similar) to refute the majority position? Muzilon (talk) 04:00, 18 January 2023 (UTC)

I agree with this as the consensus position, but I wouldn't want it as a policy I think. Johnbod (talk) 05:02, 18 January 2023 (UTC)

Yes, so far there's been no convincing evidence that this needs to be settled by the MoS. If the folks tracking the Jenkins bio can work it out among themselves, that would be great; otherwise they should try dispute resolution. If the issue starts to come up repeatedly in multiple articles, then it might be worth discussing what to do in the MoS. --Trovatore (talk) 05:44, 18 January 2023 (UTC)

Yes, and if it comes up again in one or two other articles, reference to this discussion might help resolve matters without needing to add a section to the MoS. NebY (talk) 14:50, 18 January 2023 (UTC)

That's where it was being discussed, where I asked about a recent edit. I'm not sure why Muzilon (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) moved it here; I just followed them. — Fourthords | =Λ= | 15:13, 18 January 2023 (UTC)

I don't agree this is the consensus. On my part I see nothing wrong with writing "39.5 years". Just nothing. It's clear, concise, unambiguous, and widely used outside Wikipedia. I also see nothing wrong with "39 1/2 years". That's my position. Dondervogel 2 (talk) 07:37, 18 January 2023 (UTC)

You and Fourthords appear to be the only two editors here arguing for that position (so far). May I suggest you create an RfC if you want wider input. Muzilon (talk) 07:49, 18 January 2023 (UTC)

I see no need for an RfC because I'm not arguing for a change. I am merely stating my opinion, which is that I do not recognise your description of consensus. Dondervogel 2 (talk) 11:02, 18 January 2023 (UTC)

I'm uninterested in adding a site-wide consensus where none already exists on the matter. I was just asking why the Jenkins article warranted vagueness of time when the sources provided specificity. You moved the conversation here, but this discussion hasn't addressed my inciting inquiry. — Fourthords | =Λ= | 15:13, 18 January 2023 (UTC)

It should be apparent that I raised the issue here because it does concern MOS:NUMBERS. (Even if Fourthords just intended to ask a more general question about "vagueness of time" elsewhere.) And as I pointed out above, I've located at least 3 other articles where contributors have used decimal years for biographical prose - something most editors here seem to agree is a non-standard usage. Muzilon (talk) 23:25, 18 January 2023 (UTC)

RfC on changes to currency names

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

---

Do you favour the addition of the following text at Wikipedia:Manual of Style/Dates and numbers#Currencies and monetary values, under the "Currency names" section?

1. Option A: Currency names and symbols should not be changed unless there is consensus to the contrary.
2. Option B: Currency names and symbols should not be changed unless there is consensus or reliable sources to the contrary.
3. Option C: Currency names and symbols should not be changed unless there is consensus or reliable sources to the contrary. Widespread changes to currency names should have consensus before they are changed.
4. Option D: (Status quo, add nothing)

NotReallySoroka (talk) 08:44, 23 December 2022 (UTC)

• Option C as proposer. I have been involved with an editor (TheCurrencyGuy) who performed mass changes involving currency names and symbols, and I wrote several RMs and RfCs to seek consensus before I reverted them. One such RfC, located at Talk:Ruble#Request for comment, has an emerging consensus that "ruble" v. "rouble" is "an engvar problem [which] should be solved according to our pre-existing rules regarding English variants. I propose broadening this notion to currency names and symbols. I added the section on widespread changes to counter a potential loophole where a person feels that mass changes because they (thought they) found a reliable source, when there could be other sources that used another orthography for the same currency. Thanks, NotReallySoroka (talk) 08:44, 23 December 2022 (UTC)

  I intentionally based my wordings on the spirit of WP:RETAIN. NotReallySoroka (talk) 08:46, 23 December 2022 (UTC)

• D because I'm sick and tired of people opening RfCs precipitously, with no attempt to work first with others to frame the issue, and in this case no indication whatsoever of what problem is being solved. EEng 14:40, 23 December 2022 (UTC)
• Option D. Where is the link to prior discussion? Why would new text be necessary? Where would it be placed? Why would we need to say that this sort of text, specifically, should not be changed without consensus or reliable sources? Why does this section have a generic header name? – Jonesey95 (talk) 14:58, 23 December 2022 (UTC)

  @Jonesey95: I propose adding "this sort of text" on currency nomenclature because TCG has done mass changes to them. NotReallySoroka (talk) 21:52, 23 December 2022 (UTC)

  Thank you for the response. It is not a good idea to add to a guideline because of a single editor's misunderstanding or malfeasance. I suggest that you withdraw this RFC, now that you have gotten a sense of how it will end. Doing so will avoid wasting the time of editors at this page. – Jonesey95 (talk) 22:59, 23 December 2022 (UTC)

  @Jonesey95: But then editors' time is also wasted on en masse changes of currency spellings and notations sans consensus. I shouldn't have to start a single discussion on currency names and notations; conversely, TCG should have started a few RfC and RMs before they made their mass edits.

  It is what it is, though; I will snow close this RfC very soon in favour of D. Thank you for your participation in this RfC. NotReallySoroka (talk) 09:47, 31 December 2022 (UTC)

• D per EEng, and because Wikipedia policy and guidelines are already quite sufficient, and because no evidence has been presented that our use of currency names and symbols is in an exalted state of grace, and because this seems to be a totally superfluous attempt to shut down the work of an editor who has already been indefinitely blocked and rage-quit, and in amazement that this sudden RFC follows the proposer's creation of a "law" in project space Wikipedia:NotReallySoroka's Law, and per Jonesey95. NebY (talk) 15:08, 23 December 2022 (UTC)

  Completely agree, though in fairness it should be said that TCG wasted a lot of editor time pushing his intransigent ideas about currency names and so on, so I can understand the OP's desire to dampen such activity. But see, as always, WP:MOSBLOAT. EEng 15:45, 23 December 2022 (UTC)

  Indeed, even when they had consensus they ... well anyway, yes, WP:MOSBLOAT. NebY (talk) 16:38, 23 December 2022 (UTC)

  @NebY: But then WP:TenPoundHammer's Law and WP:Shirt58's Law also exist, although they aren't subject to RfCs. I don't intend for my "law" to be more powerful than TPH's or Shirt's law barring consensus to the contrary. NotReallySoroka (talk) 21:50, 23 December 2022 (UTC)

• Option D: this is already covered by existing policy, as it would be if you substitute "currency names and symbols" for quite a lot of different things. This would be instruction creep and is a bad reaction to some concrete behavioural conduct issue. — Bilorv (talk) 19:19, 23 December 2022 (UTC)

Comment: I would probably snow-close in favour of D after my later replies have been replied to. Thanks, NotReallySoroka (talk) 21:53, 23 December 2022 (UTC)

Comment (in my personal capacity): While I will soon snow this mess of an RfC in favour of D (no changes), I would like to state in a personal capacity that MOS:VAR and WP:RETAIN might be more generic guidelines regarding currency names; after all, currency notations are styles too. I should have based my contentions more on these two notions instead of bloating the MoS to right a wrong.

Specifically, to NebY, I would like to argue that my attempt to revert TheCurrencyGuy's engvar changes should not be deemed "superfluous"; after all, 4000 edits call for desperate measures. Additionally, I also hope that you don't consider the "NRS law" as that big of a point of contention; as I stated, there are other on-wiki "laws" named after Wikipedians who have created them, and the fact that my "law" is an essays means that it isn't a policy or guideline that we need to follow.

I will post a formal closing summary of this RfC very soon, as the consensus is so clear that "even an editor involved may close the discussion" in favour of D. Sincerely, NotReallySoroka (talk) 09:45, 31 December 2022 (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.

MOS:DOB

currently redirects here, specifically to:

Wikipedia:Manual of Style/Dates and numbers#Dates of birth and death

The problem is that nowhere on this page is Dates of birth and death directly discussed. Yes, the section/anchor redirected to discusses date ranges but 1) a policy on "Dates of birth and death" is expected to discuss much more than how to express the range. 2) what to do when the range isn't a range (because the person is still living) is snuck into here, which I feel is out of place.

I suggest MOS:DOB is redirected to a comprehensive policy on how to express people's births and deaths.

For example, I got here because someone made an edit saying effectively "per MOS:DOB we don't specify the PLACE of birth".

But this policy says nothing on that topic. This makes me guess it used to redirect to a much more comprehensive discussion, covering all aspects of the topic "how to express info relating to the birth and death of a person": how to express dates, date ranges, place of death and other details.

It should not be scattered and/or incomplete, but currently, it is. CapnZapp (talk) 11:40, 24 January 2023 (UTC)

@CapnZapp, this is covered in Wikipedia:Manual_of_Style/Biography#Birth_date_and_place JeffUK 13:58, 8 February 2023 (UTC)

User:JeffUK: I have questions. CapnZapp (talk) 19:59, 8 February 2023 (UTC)

Why is MOS:DOB redirecting here instead of there?

And why does "there" say

Further information: WP:Manual of Style/Dates and numbers § Dates of birth and death

What "further" information? It is when MOS:DOB lands you here, you need "there" for the further information! If "there" is the one place where all pertinent information is given, why not focus on "there" as the MOS:DOB destination? CapnZapp (talk) 20:01, 8 February 2023 (UTC)

There's no expectation that there is one place that holds all the information you may be looking for at this particular time. Dates and Numbers covers lots of things you need to know about dates and numbers (including birth and death dates) Biography covers lots of things you need to know about the style of biographical articles, including birth and death dates. I think your question really is 'Why did an editor send me to the wrong one to read about whether or not to include a birth location' the answer to that is that they got it wrong. JeffUK 21:39, 8 February 2023 (UTC)

Sorry but yes there is. At least, I assume that the "DOB" in MOS:DOB stands for dates of births (and deaths). If this is correct, then yes, obviously a reader would expect that this shortcut leads them to a comprehensive overview, or in your own words, "one place that holds all the information [they] may be looking for at this particular time." Furthermore, the editor that sent me here only operated on the (very reasonable) assumption that a shortcut that expands to "Wikipedia:Manual of Style/Dates and numbers#Dates of birth and death" would indeed be my one-stop shop in all matters regarding dates of birth and deaths. Wouldn't you agree? CapnZapp (talk) 18:12, 9 February 2023 (UTC)

I don't think we have a 'persistently recurring style issue' that actually requires any additions to any part of the MOS. Maybe you could draft the section you're proposing to make it clearer what you think is actually missing? JeffUK 10:13, 10 February 2023 (UTC)

all aspects of the topic "how to express info relating to the birth and death of a person": how to express dates, date ranges, places of birth and death and other details that may or may not be considered pertinent in various cases, for bio subjects that are alive, and for bio subjects that are dead. The presence of MOS:DOB suggests the target offers all of this, but it doesn't. CapnZapp (talk) 11:31, 10 February 2023 (UTC)

"all aspects of the topic" and "other details that may or may not be considered pertinent" just begs the question, what do you think is missing? The only thing you mentioned that isn't already here is 'place of birth' which no-one would expect to find under 'Date of Birth'. JeffUK 12:23, 10 February 2023 (UTC)

Era: Use of Common Era as preferable to Anno Domini?

This is NOT an RfC... yet. I am doing the pre-work of determining if we could finally come down on one side or the other in most cases, if not all, and use the Common Era dating system which makes use of CE and BCE as preferable to AD and BC? I believe that in academia today, CE/BCE is seen as more neutral, and is pretty widely used and seems to me to be used more by the day in the english speaking world at least when it comes to non-Christian material. I would love to seek community input, and if there seems to be a clear enough consensus, to then more forward to a formal RfC, and then from there, the policy recommendation to be implemented in the MOS. TY — Moops ^⋠T⋡ 22:34, 16 January 2023 (UTC)

No, this won't happen. You should have realized this by now from the various attempts you've made to change individual articles. Johnbod (talk) 22:39, 16 January 2023 (UTC)

We have come down on a consensus. You're not really interested in "community input", there's been plenty of that. When I read "I would love to seek community input, and if there seems to be a clear enough consensus..." I hear "Please support me I want to push this through to fit my personal preference". BTW, the language is "English", not "english". Martin of Sheffield (talk) 22:56, 16 January 2023 (UTC)

Assuming you are unaware of the history of this discussion, I recommend using the search function to learn what has transpired in the past on this page. In short, we have a consensus that perhaps no one likes very much, but too many people have too strong opinions to come to a new consensus. It's not worth the time or bother of bringing this up again, unless something dramatic like the Second Coming has happened to change views (and eras). SchreiberBike | ⌨  23:19, 16 January 2023 (UTC)

Of course in my opinion CE is the better system, not merely for secularism reasons but also because Christ seems to have been born several years "Before Christ". Even so, there is no conclusive policy argument one way or another - and not only is there no consensus to mandate CE, even if there were it would undoubtedly cause a kerfuffle of great magnitude on and off Wikipedia, get dragged into the culture wars, interpreted as an attack on religion, etc. We can simply not get into it and it will save time and energy to work on articles.

Perhaps the time to standardise on CE will come some decades hence if it gains broad cultural acceptance over the AD system - who knows? But for now this is probably as it should be. CharredShorthand (talk) 12:10, 17 January 2023 (UTC)

It has gained such acceptance in academia as well as in the English speaking world with two notable exceptions, Brits (oddly cling to old customs maybe?), as well as Christians. — Moops ^⋠T⋡ 18:29, 12 February 2023 (UTC)

Really? I see it as the flip side of that. BCE/CE has gained some traction in academia but very limited use in general society. Strangely, it is use in both Christian and non-Christian academia. But ask random people off the street what BCE/CE means and you will get a blank stare. So, it's not just a Brit thing and not just a Christian thing.  Stepho  talk  11:28, 13 February 2023 (UTC)

Not my experience in the United States. — Moops ^⋠T⋡ 17:44, 21 February 2023 (UTC)

That's ok, every country does things differently. Experiences also change depending on which social circles you move in (eg academia vs rednecks vs engineers vs hairdressers, etc).  Stepho  talk  23:24, 21 February 2023 (UTC)

At Talk:Ancient Roman units of measurement#Era, I suggested you look at the now archived Wikipedia talk:Manual of Style/Dates and numbers/Archive 161#Article titles for years: BC/AD or BCE/CE as a recent example of the strength of feeling around this subject. What in that WT:MOSNUM discussion makes you think we could finally come down on one side or the other and would do so in favour of your preferred usage? NebY (talk) 12:42, 17 January 2023 (UTC)

I completely support you Moops. The BC/AD nomenclature is clearly Christian and should not be used for any dates on Wikipedia. It is not our place to use Christian terminology in what we are trying to make an unbiased encyclopedia. The argument that BC/AD is "known by more people" is ignoring the fact that Wikipedia is global-not US or Euro-centric. Millions of people all over the world read English Wikipedia (among other language of course). For example-in Kenya, English Wikipedia is more widely read than any other language Wikipedia. Anyone who is arguing that BC/AD should be kept because it's some kind of status quo is arguing from a biased standpoint. Religious dating systems should be kept out of Wikipedia unless they are germane to the topic being written about. Eupnevma (talk) 19:46, 7 February 2023 (UTC)

BCE/CE just relabels the Christian era and calls it "common", which it is not ("convenient era" or "Christian era" might have been more appropriate, as it might have gotten rid of the somewhat mystifying "anno domini", although scientists, who seem to favor the change, use latinate words so much that they shouldn't mind). The relabeling might seem appropriate for Roman history, except that so much still valid historical literature uses the old system, as well as Christianity having been born of the religious instincts of the Roman world. The example of Kenya seems inappropriate as that country is 85% Christian, according to religious demographics at its page. Another reason for not changing is that non-native speakers of English would like to be given as-simple-as-possible rules of usage, which BCE/CE just complicates. Dhtwiki (talk) 05:00, 8 February 2023 (UTC) (edited 05:02, 8 February 2023 (UTC) and 07:06, 8 February 2023 (UTC))

Indeed. I used to start new Indian articles using BCE/CE, until I realized that except for a small, very expensively educated minority, most of our huge numbers of South Asian readers were used to BC/AD, as generally used in their schools & media, and many did not understand CE at all. Time to close this thread. Johnbod (talk) 05:12, 8 February 2023 (UTC)

The BC/AD nomenclature is clearly Christian and should not be used for any dates on Wikipedia. The BCE/CE era style is clearly Christian, so according to this argument this era style should also not be used on Wikipedia. So there are various alternatives, including a dating system based on the presumed date of the foundation of Rome. The Maya also had a dating system…..

The argument that BC/AD is "known by more people" is ignoring the fact that Wikipedia is global-not US or Euro-centric. In my experience as a Brit, Wikipedia is US-centric and the desire to change to BCE/CE is an example of US-centricity.

Sweet6970 (talk) 11:52, 8 February 2023 (UTC)

• Please, God, not this shit again. EEng 05:15, 8 February 2023 (UTC)

  Perhaps we could add it to Wikipedia:Perennial proposals Hawkeye7 (discuss) 00:09, 9 February 2023 (UTC)

• Yes please. Tony (talk) 12:01, 8 February 2023 (UTC)

  Thanks Tony. I'd love to see this happen. Even if it takes a long time. :) — Moops ^⋠T⋡ 18:30, 12 February 2023 (UTC)

• If no one has a proposal which stands a chance of being approved (and I'm sure no one does), let's not waste time and energy on this. SchreiberBike | ⌨  23:25, 8 February 2023 (UTC)

Clarifying exceptions

In the section Numbers as figures or words, we have:

• Integers from zero to nine are spelled out in words.
• Integers greater than nine expressible in one or two words may be expressed either in numerals or in words...

The exception to this is listed farther down, in the middle of "Notes and exceptions":

• Comparable values nearby one another should be all spelled out or all in figures, even if one of the numbers would normally be written differently...

Can this be moved up closer to the main text? This exception is too far down the page, and it's being missed by editors who haven't read the long exceptions section carefully enough. Thanks. BilCat (talk) 19:20, 23 March 2023 (UTC)

• Juggled some stuff. EEng 05:14, 27 March 2023 (UTC)

  Thanks. BilCat (talk) 16:30, 28 March 2023 (UTC)

Petition to have dates start with the month, followed by the day

This discussion has been closed. Please do not modify it.
This is not happening and there's no point in wasting more of our time discussing why it won't happen. —David Eppstein (talk) 23:39, 2 March 2023 (UTC)
It has come to my attention that some don’t agree with having a month before the day (I.e. March 1, 2023) and would rather have it like this (1 March, 2023). Personally I think that is ridiculous, and we normally would have it the other way around. Is there any way to start a petition here on the wiki to allow these kinds of changes. Marino13 (talk) 18:56, 2 March 2023 (UTC) You keernaart be serious. Dondervogel 2 (talk) 19:38, 2 March 2023 (UTC) I’ll let more knowledgeable editors give a fuller answer, but this has been one of the longest-lived (and most contentious) wrangles on Wikipedia, since the American dating system (what you suggest) differs from that of other countries (e.g. Britain), and for that matter, the system used by the U.S. military. The convention that was reached that was articles that principally involve the United States or her people (e.g. New York City, George Washington) should follow the American convention (Month, Day, Year, or MDY), while articles principally about the UK and some other countries using her conventions (e.g., Queen Victoria, Trafalgar Square) should follow the British convention of day-month--year (or DMY). When there is no particularly or unique connection to either country (e.g. War of 1812), editors should follow the convention used by the first substantial contributor. Much more (and probably more clearly) at [4] —— Shakescene (talk) 19:46, 2 March 2023 (UTC) Wikipedia goes by consensus, not by American exceptionalism. See MOS:ENGVAR and MOS:DATEFORMAT. Muzilon (talk) 20:02, 2 March 2023 (UTC) What I'm hearing is that an American is insisting we do it the American way and screw the majority of the English speaking world that does it differently. As an Australian, I find the American date format ridiculous. It starts with the month, then goes into the more detailed day, then jumps back up to the less detailed year. Up-down-up-down-up-down - make up your mind. The D-M-Y system of consistently going from fine detail to the broad makes far more sense. The Chinese system of Y-M-D makes even more sense because their system flows into hours-minutes-seconds as well. And the M-D-Y system requires commas that the other systems don't need. So what you find natural is kind of unnatural to the rest of us and vice versa. In the past we had Americans "correct" the date format . Then a non-American would "correct" it back. And back and forth many times with much aggrevation. So eventually we made the WP:DATEVAR policy that says articles with strong ties to a predominantly English speaking country should use that country's date format. For all other articles (including those with only weak ties or ties to multiple countries) we keep the first date format that the article used when it was created. Ie, Wikipedia is an international effort and we respect that our fellow editors come from other countries that use different date formats. Or put it another way - how would you, as an American, like it if we said that all articles must use British dates, British spelling, British grammar.  Stepho  talk  21:07, 2 March 2023 (UTC) Wanders in innocently whistling But isn't it the English Wikipedia, so shouln't we use English spelling and grammar? Exits rapidly avoiding brickbats, dead dogs and insults from just about the whole globe ;-) Martin of Sheffield (talk) 22:34, 2 March 2023 (UTC) WP:SNOWCLOSE --𝕁𝕄𝔽 (talk) 23:26, 2 March 2023 (UTC)

Well, that answers that 🤦‍♂️.— Preceding unsigned comment added by Marino13 (talk • contribs) 08:33, 3 March 2023 (UTC)

Dates, months, and years / Formats

Why is the YYYY-MM-DD date format not allowed? What's wrong about saying The event occurred on 2004 October 30? :3 F4U (they/it) 22:44, 26 March 2023 (UTC)

There are no professionally edited English publications that use that format ("2004 October 30"), so the format will confuse readers. Our goal is to provide an encyclopedia to our readers without quirkiness that hinders understanding. Indefatigable (talk) 23:17, 26 March 2023 (UTC)

(edit conflict) @Freedom4U: There's nothing wrong with it; it's as valid as any other choice, but Wikipedia has made style choices to be as readable as possible and accessible around the world. That's meant that we've compromised and use both mdy and dmy (MOS:DATEVAR). If I were emperor, we'd all use YYYY-MM-DD (2004-10-30) and we'd all get used to it and go on and be a little more logical, but thankfully I am not. There are many compromises in an international encyclopedia and sticking with just two date styles (with a few exceptions) is one of them. SchreiberBike | ⌨  23:28, 26 March 2023 (UTC)

I wasn't asking because yyyy-mm-dd is "more logical" or anything like that, but because it just feels awkward reading DMY or MDY formatted dates when the article has clear national ties to Korea or China or Japan. With MDY, there's at least the month and day lining up, but the year still throws me off. :3 F4U (they/it) 23:44, 26 March 2023 (UTC)

I understand where you're coming from. I lived in China for a few years and I edit a lot of articles about Japanese cars. I love YMD. I'm also one of the most vocal supporters of yyyy-mm-dd being used in references. But even I stop at using it in English prose. It's simply not an English language format and it would be a distraction for the majority of international readers. There will also be many edit wars when Brits or Yanks "correct" it back to DMY or MDY.  Stepho  talk  02:30, 27 March 2023 (UTC)

MOS:£

Sockpuppet contribution and subsequent discussion  · --𝕁𝕄𝔽 (talk) 17:00, 26 April 2023 (UTC)
The following discussion has been closed. Please do not modify it.
I have some proposals to clean up some ambiguous/poorly worded language relating to MOS:£. For Britain's currency, sterling, use the £ symbol (U+00A3 £ POUND SIGN). Do not use U+20A4 ₤ LIRA SIGN, which is a legacy code point for a series of HP printers (Whether a pound sign has one or two bars is purely a typeface (font) choice: the code point is always U+00A3, irrespective of appearance.) Because of the "LIRA SIGN" code point some have taken it to mean that "£" and "₤" are entirely different characters, I feel it needs to be made more clear that the only reason for "₤" having a separate code point at all is because of the Roman-8 character set. At present it also entirely breaks with discussion of the pound sign mid-way through to go on a tangent about the abbreviation "stg" then reverts for some reason, when it would have been more appropriate to mention it in the section below; my draft of which is here: An unqualified £ sign always means sterling on Wikipedia. Abbreviations such as £stg or £ stg are best avoided. Do not use GB£. "Best avoided" is far too ambiguous a phrase for "GB£", because this construction is not found in any WP:RELIABLE SOURCES. "£stg" and "£ stg" do exist in reliable sources, but are not enormously common post about 1980. Thus I propose advising against "£stg" and explicitly prohibiting "GB£". Non-sterling currency units named pound or lira should use the fully disambiguating abbreviation specific to that currency. (e.g. £SA for the South African pound).[5] On this final point the original sentence was badly worded and did not even give any examples for editors. 92.12.140.56 (talk) 15:23, 25 April 2023 (UTC) The existing text was arrived at after extensive discussion just a few months ago: I see no reason other than wp:IDONTLIKEIT to reopen the question. The one-bar v two-bar allographs issue is fully explained at pound sign#Double bar style: there is no need to have a wp:CFORK of it in the MOS. --𝕁𝕄𝔽 (talk) 18:38, 25 April 2023 (UTC) Could you link to that recent discussion? JMF you make a mistake, no (bad) FORK at hand. An article must describe what is used, for example by the Bank of England. However, the MOS must describe what we at enwiki use. Out of MOS interest, it is important we prescribe a non-ambiguous and non-variant writing throughout this wiki. What sign a source uses for GBP is irrelevant for our article tekst. (Apply single MOS option ie £). I still don't get why MOS-forbidding £stg &tc. ever is an issue. A variation that never helps or is needed. Also, simply rule out U+20A4 lira sign — solved. (Incidentally, if and when a font has a double-barred sign for U+00A3: so be it). Of course, MOS-rules are overboard when the sign is the topic itself (in Pound sign etc). — Preceding unsigned comment added by DePiep (talk • contribs) 18:59, 25 April 2023 (UTC) DePiep is quite right, I'm not talking about articles per se, just how the manual should advise editors. I am not taking issue with the spirit of the guidelines, but the exact wording, which is currently very oddly written and poorly explained; for example it gives no examples of other currency units for contrast. I think it ought to be msde completely clear in the manual that £ alone indicates sterling only with no need for any other abbreviations or resorting to ISO codes, and that editors should clearly denote any other pound/lira unit with a different fully disambiguating abbreviation (e.g. LL for the Lebanese pound, £NZ for the New Zealand pound and so on), leaving a simple £ without qualification to mark sterling, much as € marks amounts in euros. 89.240.244.177 (talk) 22:05, 25 April 2023 (UTC) @DePiep: see Talk:Pound sterling/Archive 3#Second request for comment (currency symbols) (which was a reprise of Template talk:GBP#Semi-protected edit request on 12 June 2022). To quote User:Redrose64 there, Ah crap, not this again. Enough already. Exactly. --𝕁𝕄𝔽 (talk) 22:49, 25 April 2023 (UTC) wlink corrected --10:50, 26 April 2023 (UTC) I am not trying to contradict anything there, merely reword and tighten up the style guide. The guidelines offered at present are a bit all over the place and not particularly well written. Not far below it already states Exceptions may occur in tables and infoboxes where space is limited e.g. Currencies accepted: US$, SFr, £, €. It may be appropriate to wikilink such uses, or add an explanatory note. using £ on its own to represent sterling. I do not see my proposal as a change per se, merely a cleanup of poor structuring and grammar. 89.240.244.177 (talk) 23:21, 25 April 2023 (UTC) I have now added my suggested edits. I hope they are an effective cleanup. 89.240.244.177 (talk) 00:12, 26 April 2023 (UTC) Which edits? You edited the MOS text? -DePiep (talk) 04:36, 26 April 2023 (UTC) Probably this. -DePiep (talk) 05:05, 26 April 2023 (UTC) Minor rewording done (it's UK not Britain; distinction "unit" vs. "currency"). Article pound sterling describes RL very well; MOS should not & now does not contradict it IMO. Basically MOS:£ says: "Use £" for unit of sterling, exceptions specified. -DePiep (talk) 05:22, 26 April 2023 (UTC) That particular error was already there in the MOS. I did consider changing Britain to United Kingdom, but I didn't want to edit the wording except where absolutely essential. 89.240.244.177 (talk) 11:36, 26 April 2023 (UTC) Section not found. Nor in {{Section link}}: required section parameter(s) missing (=all archives). Multiple sections on this. -DePiep (talk) 05:00, 26 April 2023 (UTC) <expletive deleted> Sorry, user:DePiep, fighting with the mobile interface and made a typo. Correct link is Talk:Pound sterling/Archive 3#Second request for comment (currency symbols) (I have also corrected my original post above.) --𝕁𝕄𝔽 (talk) 10:50, 26 April 2023 (UTC) Time to stop tiptoeing around. I call out the IP as a WP:sock of banned editor user:TheCurrencyGuy. Same obsessions, three edits then straight to open a talk:MOS discussion. Then changes the MOS. WP:Banned means banned. I intend to revert their edit as soon as I can get to a desktop. --𝕁𝕄𝔽 (talk) 06:10, 26 April 2023 (UTC) All fine, but I object to the reverting. DePiep (talk) 07:34, 26 April 2023 (UTC) John Maynard Friedman JMF, could you initiate the WP:SPI? If results are bad, we can close this thread & throw it away. (We can initiate a new one if concerns remain about this MOS). -DePiep (talk) 08:49, 26 April 2023 (UTC) Done. --𝕁𝕄𝔽 (talk) 10:42, 26 April 2023 (UTC) It is not possible to SPI an IP address, but TCG appears to have admitted block evasion at Wikipedia:Sockpuppet investigations/TheCurrencyGuy#Comments by other users. So this discussion is closed. I have rewritten the text at MOS:£ to not quite revert to status quo ante, because DePiep's contribution was worth retaining. --𝕁𝕄𝔽 (talk) 17:00, 26 April 2023 (UTC)

MOS:DATEUNIFY and MOS:DATEVAR should be more explicit about template parameters

There are various editors running around changing all of the «YYYY-MM-DD» date formats in citation template parameters to e.g. «D Month YYYY» format (e.g. using the script User:Ohconfucius/script/MOSNUM dates). At best, this is in my opinion a pointless waste of attention, because these templates already have logic to render dates into whatever desired human-readable format, so these edits do not affect the output seen by article readers in any way, but only change the source markup.

But in my opinion these changes are actively harmful, because the whole point of these templates is to be a structured format which is accessible to both human readers and to automated tools. The clear, concise, lexicographically sortable, unambiguous, standardized «YYYY-MM-DD» format is an international standard (ISO 8601) for machine-readable metadata for good reasons. Many existing bots emit this format in these template parameters, the same or similar formats is widely adopted outside Wikipedia (for example, the Internet Archive's Wayback Machine has dates in «YYYYMMDD» format as part of archive URLs, making it trivial to copy-paste into the "archive-date" parameter and just add hyphens) and anyone trying to do anything with the template markup, either manually or using a computer program, benefits from having a numeric «YYYY-MM-DD» format, which is much easier to work with than alternatives when dealing with many dates at a time as metadata per se.

At the very least, the MOS should directly state that «YYYY-MM-DD» dates in template parameters should not be changed by script to the same format as plain-text dates in article body copy / plain wiki-markup dates in citations. In my opinion it would even better to explicitly nudge editors to change other date formats to «YYYY-MM-DD» format in the context of template parameters; but I don’t care strongly enough about this to try to make any kind of site-wide policy about it. –jacobolus (t) 18:01, 3 April 2023 (UTC)

Seconding this. While other formats can be allowed if they are in line with the article's format, YYYY-MM-DD should be listed as the preferred format, and scripts should not change this.

These edits (eg, changing date=2023-04-03 to date=3 April 2023) actively harm translation efforts by making it more difficult to translate citations. Wracking ^💬 18:20, 3 April 2023 (UTC)

Dates in the YYYY-MM-DD format may be false for dates earlier than 1923; the further back, the greater the likelihood of a falsehood. Jc3s5h (talk) 18:53, 3 April 2023 (UTC)

(edit conflict)This should be a non-discussion, MOS already specifically permits YYYY-MM-DD:

* Access and archive dates in an article's citations should all use the same format, which may be:

• • the format used for publication dates in the article (see above);
  • the format expected in the citation style adopted in the article; or
  • yyyy-mm-dd

— and it is really annoying when a fly-by bot changes date formats and triggers a watchlist entry just for an unnecessary date change. Martin of Sheffield (talk) 20:28, 3 April 2023 (UTC)

Why wouldn't this equally apply to any other date format? –jacobolus (t) 21:22, 3 April 2023 (UTC)

I'm fine with articles that consistently use either MDY or DMY in prose and consistently use YYYYMMDD in the references. I don't think I've ever come across such an article, and the fact that RefToolbar, the default source editing citation tool, defaults to DMY means that many articles are inconsistent. When faced with an inconsistent article, I think using the available script to unite the style across the prose and references is an improvement. Editors are already discouraged from doing so in a bot-like manner if the changes are only cosmetic (i.e. only to the references). Firefangledfeathers (talk / contribs) 20:39, 3 April 2023 (UTC)

I am extremely annoyed by editors who use the date unification script to change numeric dates to spelled-out dates in articles that use the |cs1-dates= parameter of the date format template to specify that the dates should be numeric. The script to unify these dates is broken, because it cannot handle this standard numeric format even when the article explicitly specifies it as the format. But despite years of complaining about the script being broken, editors persist in using it and riding roughshod over WP:DATEVAR. I don't care whether you think it is an improvement. Unless this long-broken script can be properly fixed, it needs to stop. —David Eppstein (talk) 21:11, 3 April 2023 (UTC)

You and I are not talking about the same cases. I also would oppose the changes you're talking about. Firefangledfeathers (talk / contribs) 21:20, 3 April 2023 (UTC)

What cases are you talking about? I'm a bit confused. Wracking ^💬 21:42, 3 April 2023 (UTC)

I provided an example below in reply to jacobolus. Firefangledfeathers (talk / contribs) 22:45, 3 April 2023 (UTC)

Examples of four different users incorrectly changing consistently-formatted numeric access dates into spelled-out dates using a script: Special:Diff/947500508 (2020), Special:Diff/1032832144 (2021), Special:Diff/1117477199 (2022), Special:Diff/1145374634 (2023). I'm not sure these are all using the same broken script but at least some of them are Wikipedia:MOSNUMscript, exactly the same broken script that you (Firefangledfeathers) have linked to in your own recent script-date-change edit summaries. The script talk page indicates that the developer has refused to fix the script when this issue is raised and instead thinks of it as a user error. —David Eppstein (talk) 21:46, 3 April 2023 (UTC)

I looked at your first diff. First, it was not tagged with the cs1-dates parameter, so it doesn't seem aligned with your use case. Second, since no "use XXX dates" template was present, the page was displaying different formats for the date= and accessdate= parameters. I don't see that as a good thing, and it wouldn't have occurred to me that the date style was consistent. If there's a reason to stick with that sort of consistent inconsistency, I'd be glad to know about it and will change my practice moving forward. Firefangledfeathers (talk / contribs) 22:45, 3 April 2023 (UTC)

The "first diff" in question here could have limited itself to only adding {{Use mdy dates}} at the top of the page and the effect for readers would have been identical; changing numerical dates to spelled out «Month D, YYYY» format was unnecessary. –jacobolus (t) 23:04, 3 April 2023 (UTC)

Perhaps the MOS should directly recommend that all pages include a "use XXX dates" template with cs1 parameter set on it, to be added any time someone wants to make a significant modification to date formatting. I doubt anyone would have a problem with an edit setting |cs1-dates=XX on a page where the templates are currently rendering dates inconsistently. –jacobolus (t) 22:58, 3 April 2023 (UTC)

When I created the auto-date formatting for cs1|2, it was my intention that there would not be a need for a script to fiddle with date formats in cs1|2 templates because those templates would follow the format specified in the {{use xxx dates|cs1-dates=<format>}} templates. If I recall correctly, for a time, the script did not fiddle with cs1|2 dates; it reformatted dates in the prose and left the cs1|2 date formatting to cs1|2. Editors did not like that so now we have the situation where the script ignores |cs1-dates=.

—Trappist the monk (talk) 23:25, 3 April 2023 (UTC)

The second and fourth examples are definitely bad edits. In both cases the {{use xxx dates}} templates had valid |cs1-dates=ly parameters indicating that the correct formats for cs1|2 templates in those articles is long-form format for publication dates and YYYY-MM-DD format for access and archive dates as allowed by MOS:DATEUNIFY. The script should not be ignoring |cs1-dates= when it has a value so I concur: for these edits the script is broken. The other two examples are correct edits in that a {{use xxx dates}} was not present before the script edited the articles so the script could not know to preserve YYYY-MM-DD access and archive dates unless the script operator instructed it to do so; I don't know if the script has the ability to accept that sort of instruction from the operator; if it doesn't, it should.

—Trappist the monk (talk) 23:25, 3 April 2023 (UTC)

All four are bad edits, and the script should be fixed to not make edits of this type. –jacobolus (t) 07:04, 4 April 2023 (UTC)

@Firefangledfeathers: Re "the page was displaying different formats for the date= and accessdate= parameters": YES. DELIBERATELY. THAT IS A CONSISTENT DATE FORMAT. It is a date format explicitly allowed in MOS:DATE. It is exactly the date format described by cs1-dates=ly. It should not have been changed.

Re: "not tagged with the cs1-dates parameter": this makes no difference to the script's behavior. And it should not be necessary to tag an article that is in a consistent date format, in order for it to be recognized as consistent and left unchanged. In fact this diff was one of several things that convinced me that was necessary to tag every article I created. There are two reasons, only one of which is the misbehavior of editors like you who run this broken script and then, just like you above, insist that it was merely making things consistent, ignoring the fact that they were already consistent before. The other reason is that that these editors, and maybe some others, will then tag the article with a use-dates template that omits the cs1-dates= parameter, and this omission causes all the citation templates to convert the numeric dates to spelled-out dates in the same way. By starting all new articles with a use-dates template with a cs1-dates parameter, I can preempt the editors who think that this template should somehow be mandatory but fail to match it to the consistent date format already in place. But the template should not be mandatory, it should not be needed to stop the broken script from converting one consistent format to another, and in fact it is not sufficient to stop the broken script from converting one consistent format to another. —David Eppstein (talk) 06:05, 5 April 2023 (UTC)

👍 Firefangledfeathers (talk / contribs) 11:15, 5 April 2023 (UTC)

What advantage specifically do you see in having the template markup for a citation say e.g. … |archive-date=2 September 2022 |… instead of … |archive-date=2022-09-02 |…, assuming that the reader is going to see "2 September 2022" either way? Why is this an improvement? –jacobolus (t) 21:30, 3 April 2023 (UTC)

I don't see any advantage to that change. One where I do: assume the article is tagged with Template:Use mdy dates. The first ref has ...title=ref1 |archive-date=2 September 2022 ... . The second ref has ... |title=ref2 |archive-date=September 10, 2022 .... I would favor a change to unify the date styles, just for the very minor benefit of code readability. Since it's a cosmetic change, I wouldn't make the edit unless bundled with an edit that actually changes the displayed page for readers. Firefangledfeathers (talk / contribs) 22:45, 3 April 2023 (UTC)

If the article has {{use mdy dates}} at the top, then this change will not affect readers, because the template will already standardize the output. But to make the markup most legible/useful I would personally recommend switching these to … |archive-date=2022-09-02 |… and … |archive-date=2022-09-10 |… , respectively. –jacobolus (t) 23:09, 3 April 2023 (UTC)

• When the book or website being cited has a date on it, should this not be the format used for |date=? OK, I'll accept a conversion from Roman numerals to Arabic, but otherwise it should be copied as is. Access and archive dates on the other hand are subject to the Access and archive dates section of MOS, quoted above. Martin of Sheffield (talk) 07:37, 4 April 2023 (UTC)

  I'm sorry, but that's silly. A date is information, not a form of expression (as text is), and while we are unavoidably forced to choose a date format for any particular article, the whole reason for doing so is so that the information in the article's various dates will be presented in a way that's as unobtrusive as possible, and that means not varying the format willy-nilly. EEng 13:37, 4 April 2023 (UTC)

Crore

MOS:CRORE currently provides this advice (emphasis added):

• Provide a conversion to Western numbers for the first instance of each quantity (the templates {{lakh}} and {{crore}} may be used for this purpose), and provide conversions for subsequent instances if they do not overwhelm the content of the article. For example, write three crore (thirty million). When converting a currency amount, use the exchange rate that applied at the time being written about; the {{INRConvert}} template can be used for this purpose.

But WP:ICTF#Films says that there is consensus that {{INRConvert}} should not be used in list-type articles or in infoboxes (at least for Indian film-related articles).

Monetary conversion templates such as INRConvert should not generally be used in list type articles or infoboxes per this consensus and this discussion. The prevailing attitude was: 1) Converting to US dollars is arbitrary. 2) Default conversion templates create problems with inflation, Ex: where the gross from a 2008 film is converted to the present year's US$ rate. 3) The inflation adjustment option in the template results in infobox clutter.

I had started using {{INRConvert}} in Indian film articles based on MOS:CRORE. It wasn't until later that I saw WP:ICTF#Films and realized what I was doing was counterproductive.

So, I wonder we should add something to the current writeup at MOS:CRORE to acknowledge or note this "consensus" about avoiding {{INRConvert}} in list-type articles and infoboxes?  — Archer1234 (t·c) 16:01, 30 March 2023 (UTC)

Strictly speaking, the provisions at MOS:CRORE override the WikiProject consensus, per WP:CONLEVEL. It might be possible to alleviate the infobox clutter concern (number 3) by footnoting the conversion, and the problems with inflation concern (number 2) is already addressed by MOS:CRORE where it says use the exchange rate that applied at the time being written about.

That just leaves concern number 1, which MOS:CURRENCY leaves open to lower-level consensus: in non-country-specific articles, such as Wealth, use US dollars (US$123 on first use, generally $123 thereafter), euros (€123), or pounds sterling (£123). XAM2175 ^(T) 01:41, 31 March 2023 (UTC)

One of the main concerns I have about using INRConvert in the infobox is the clutter, but not just in the infobox. The conversion would be in the infobox and in the article lead, toward the bottom, which generally is quite close to where the conversion in the infobox will be. That feels like content overload for the reader. Keeping a fairly clean infobox presents relevant information to the reader, with easy access to the conversion in the lead mitigates that without giving an undue burden. Ravensfire (talk) 03:06, 7 April 2023 (UTC)

Don't use crore in those circumstances; MOS:CRORE and MOS:COMMONALITY both discourage it, and it makes the article less accessible. BilledMammal (talk) 05:10, 7 April 2023 (UTC)

MOS:DATED proposal "a recent study"

I think MOS:DATED (and perhaps also MOS:RELTIME) should include a note about adjectives such as recent in phrases such as a recent study, which I see all the time. Case in point: I changed A recent synthesis gives to A synthesis by Harper (2017) gave. MOS:DATED is focused on adverbs such as recently and currently, but also has present, upcoming and ongoing that could be used both adverbially and adjectively, and already features the adjective example she is the current director. I think we should add a sentence about replacing a phrase like a recent study with example solutions such as a 2017 study or a study by Foo (2017).

I think we should also add an extra alternative to the example of she is the current director, namely one with the formulation has been (or plural have been), which is already commonly applied, e.g. she has been director since 1 January 2023. This is to cover ongoing situations that have a known starting date, but an unknown ending date, which may or may not have already passed. Terms and tenures of certain offices or positions such as director are typical examples of that. They may not have set end-dates (e.g. directors of companies or organisations which they (co-)founded themselves can often remain director indefinitely until they pass the position to someone else at some point at their pleasure), and even positions with fixed terms may be extended (due to re-election or reappointment for another term) or cut short (due to resignation, removal from office, death, or otherwise).
Situations in which a sportsperson or tallest building or whatever is the current (world) record holder are similar: it is uncertain how long they will remain the current record holder. Apart from formulations such as She set a world record in fooing in 2023 or Foo is the tallest building in Fooland as of 2023, a has/have been formulation can be useful, especially in articles that are not frequently updated. So the formulation has/have been is a good solution to indicating when a tenure began without necessarily saying it is still ongoing (or has already ended) whenever that is unknown, or whenever it can in fact be known from reliable sources, but hasn't been updated yet. (Once it is known, it can always been changed to had been, if that makes narrative and grammatical sense). Cheers, Nederlandse Leeuw (talk) 10:08, 4 April 2023 (UTC)

You're quite right about "recent" and I would even avoid she has been director since 1 January 2023, preferring she became director on 1 January 2023 (was appointed, was promoted to, ...). Some editors may be happy using {{As of}} eg {{as of|2023|01|01|lc=on}} as of 1 January 2023 or even {{as of|2023|01|01|lc=on|since=y}} since 1 January 2023, but even that's less durable. NebY (talk) 18:19, 4 April 2023 (UTC)

I agree. Nederlandse Leeuw (talk) 11:51, 5 April 2023 (UTC)

Like the above, I prefer simple past to any perfect tenses, as things like the present perfect still imply conditions which may or may not be true any longer. "She became such and such" is much better than "She has been such and such since" because that still implies we have knowledge of the present condition, which the article may not. --Jayron32 13:25, 5 April 2023 (UTC)

I very much agree with NebY and Jayron32. Whenever I see "since" or "has been", I think to myself "as of when?" or "until what date?", and sometimes even check the refs (if any, hah) when I'm in pure reader mode, to see (guesstimate) how out of date the statement might be. — JohnFromPinckney (talk / edits) 14:25, 6 April 2023 (UTC)

There are other, equally damnable, words and phrases. Not very long ago, I had to correct an article that said (my emphasis) "the couple currently live in Anytown with their teenage children". The statement was add in (and cited to cited to a source dated) 2014.

Also, every January, it pays to do a search for "this year", "last year" and "next year". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:12, 10 April 2023 (UTC)

MOS:DECADE vs MOS:CENTURY

Over at List of fatal crowd crushes, the format of the article is confusing regarding the year 2000. Events from 2000 are included in the sub-heading "The 2000s", which is under the heading "The 21st century". This pretty clearly goes against MOS:CENTURY, which proscribes that the year 2000 belongs to the 20th century.

We could try using only one system in the article, but neither result seems satisfactory. If we removed "2000s/2010s/etc", we end up with awkward 10-year groupings like "2001-2010" and "2011-2020", which are completely unnatural. We could remove "17th/18th/etc century", and instead write "1600-1699" and the like, but that seems esoteric, and also a bit unnatural... Is there an elegant solution here I'm not seeing? Are all or most list articles like this? PhotogenicScientist (talk) 22:00, 18 April 2023 (UTC)

PhotogenicScientist, this is a good question. what if, under the table for "20th century", an entry was placed at the bottom that stated "for the year 2000, see § 2000s"? better yet, the entries for the year 2000 could be moved to the table for "20th century" instead, and an entry at the top of the table for "2000s" could state "for the year 2000, see § 20th century", because the year 2000 is in the 20th century and not the 21st century. to avoid sorting issues, code like the following could be used.

colspan="6" align="center" data-sort-value="" | ''for the year 2000, see {{section link||20th century}}''

different lists seem to have tackled the issue differently. the list of floods mentions a flood in the year 2000 under the 19th (!) century heading, does not have a 20th century heading, and completely ignores the 2000 flood under the 2000s heading. (it also mentions a 1900 flood under the 19th century heading, and an 1800 flood under the 18th century heading.) the list of building or structure fires mentions all the relevant fires of 2000 under the 2000s heading and completely ignores them under the 20th century heading, but it also mentions all the relevant fires of 1900 under the 20th century heading.

by the way, i think you mean "prescribes" rather than "proscribes". they are pretty much antonyms, but people often confuse the two, so the mistake is understandable. dying (talk) 23:30, 18 April 2023 (UTC)

Wow, that floods article is ridiculous lol. I made what quick corrections I could there.

Thanks for bringing up those two examples - they give me some ideas. Personally, I think it makes sense to include years ending in '00 in the century with the years after it. That's how we celebrate, after all - January 1 2000 marked the start of the 21st century, and the new millennium, to pretty much the whole world. And that just makes sense - the number in the hundreds place changes, so it feels like a new century. But apparently, this is some grand academic debate, spawning because there was no year 0 AD, and so the "first century" or first group of 100 years was necessarily 1-100 AD...

Anyways, I suppose that means I'd be in favor of amending MOS:CENTURY, as above. (also, thank you - I'll stop using proscribes wrongly :))PhotogenicScientist (talk) 13:39, 19 April 2023 (UTC)

No it didn't. The year 2000 was the last year of the 20C, the 21C started on 1 January 2001. It's not really "some grand academic debate"; count your fingers: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. You don't say you have two-and-a-fifth hands now, do you? For years, the first decade was 1-10, the first century 1-100 (otherwise it wouldn't be a century) and take it from there. Martin of Sheffield (talk) 13:52, 19 April 2023 (UTC)

That's how we celebrate, after all - January 1 2000 marked the start of the 21st century, and the new millennium, to pretty much the whole world. And that just makes sense - the hundreds number changes, so it feels like a new century. So, did you just miss this part? Or did you purposefully ignore it? Because I feel I demonstrated that I can count in 10s and 100s by acknowledging the source of the issue.

I don't know if you were alive at the time, but pretty much everyone everywhere on Jan 1 2000 was celebrating the turn of the millennium (and the century). PhotogenicScientist (talk) 14:04, 19 April 2023 (UTC)

Not only alive at the time, but I'd been warning about and mitigating against, Y2K at work since the 1980. New Year is a nice excuse for a booze-up whatever the numbers, and I joined in the Y2K celebrations, but never referred to it as the start of the new millennium. That's simply mathematically and logically wrong. there really isn't any need for discussion, you can use whatever personal definitions of a millenium you want, but it is correctly a period of 1,000 years, not 999. Martin of Sheffield (talk) 14:17, 19 April 2023 (UTC)

That's simply mathematically and logically wrong. Correct. But is it Wikipedia's calling to be "exactly, logically correct" or "approachably, familiarly correct," in cases like these where there is conflict, perhaps outright contradiction, between the two?

You can say that you yourself never referred to 2000 as the start of the new millennium, but I imagine you're in scant company there. I imagine there are others, like you and me, who have different opinions on how the year 2000 should be treated. Which is why I disagree that there really isn't any need for discussion. PhotogenicScientist (talk) 14:26, 19 April 2023 (UTC)

I suggest changing the heading 19th century to 1800-1899, 21st century to 2000–present, etc. That being disposed of, I have a question, PhotogenicScientist: are you by chance scientist/supermodel Symmetra [6]? EEng 15:10, 19 April 2023 (UTC)

I appreciate the input. That being said, no, that person is not me - but I did have a sensible chuckle at that mailing. PhotogenicScientist (talk) 15:49, 19 April 2023 (UTC)

(edit conflict) I doubt that we're ever going to agree, but in response to your (possibly rhetorical) question: 'is it Wikipedia's calling to be "exactly, logically correct" or "approachable, familiarly correct,"' then I would say the former. There are plenty of cuddly social sites where accuracy is secondary, but Wikipedia strives to be an encyclopaedia where precision and truth are fundamental. All IMHO of course. EEng who has just edit conflicted with me, has the correct answer. Martin of Sheffield (talk) 15:14, 19 April 2023 (UTC)

That's quite alright - my intention isn't to convince people to agree with me. Only to start a discussion and see where the opinions of others lie.

A minor quibble, though, with Wikipedia strives to be an encyclopaedia where precision and truth are fundamental: Wikipedia is a compendium of that which is verifiable in reliable sources, and not necessarily of that which is true. If there's a preponderance of reliable sources asserting something to be true, then Wikipedia follows. This may at times be at odds with what could be considered the "absolute truth" of a matter.

As that pertains here, "the public at large" might not be considered a reliable source to base our content on. But what about basing our practices/formatting? The public at large is our primary customer - the reason WP exists is to share knowledge with them. If our formatting could change to improve the transfer of knowledge to readers, that would be a benefit worth considering. PhotogenicScientist (talk) 15:59, 19 April 2023 (UTC)

The problem that no one wants to address is that "the 1900s" way of naming a century and "the 20th century" way of naming a century do not have the same years. If we call our centuries "the 1800s" or "the 1900s" we're delineating our centuries based on the left-most two digits of the number. If we're calling it "The 20th century", we're delineating it based on counting from "year 1", where "years 1-100" were "the first century". You'll note that this means that "the 1900s" is close to, but not identical to "the 20th century". Notably, this means that the year "2000" is in "the 2000s century" AND in the "21st century". If you categorization scheme doesn't take this into account, you're going to need to make adjustments. In this case, it may be best to just remove all mentions of the "Ordinal" century and use "1900s" and "2000s" and don't use the terms "20th century" or "19th century", because it's actually impossible to mix the systems and be accurate. --Jayron32 15:31, 19 April 2023 (UTC)

I went source-hunting, and have collected those that seemed the most reputable and reliable. In short, it seems the mathematicians and pedants have an iron grip on the press - reliable sources, by and large, strictly adhere to notion that year 2000 belongs to "the 20th century."

• Library of Congress
  • Contains my favorite quote, which very succinctly sums up my thoughts: "When does the century end? This simple question has such a simple answer that the very existence of a dispute is puzzling... Yet many find the truth of the matter so unacceptable that the resulting controversy has generated a considerable literature."
• USN Astronomy department
• Scientific American
• LA Times article from 1988
• timeanddate.com

I find myself leaning toward using "Xth century" nomenclature less, due to its inherent incompatibility with decade nomenclature...

Should we amend WP:CENTURY to recommend that preference in writing? PhotogenicScientist (talk) 20:59, 19 April 2023 (UTC)

How many years are there in a century? When, in your opinion, did the first century CE begin and end? Are the answers compatible? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:52, 20 April 2023 (UTC)

What's "CE"? EEng 14:35, 20 April 2023 (UTC)

@Chatul: 100. The CE/AD system has no Year Zero, so the first century ran from 1 CE to 100 CE. The first decade ran from 1 to 10, the second from 11 to 20 and the 20s ran from 20 to 29. Of course the answers aren't compatible. --𝕁𝕄𝔽 (talk) 15:22, 20 April 2023 (UTC)

The CE nomenclature is intended to match the year numbers of the AD nomenclature while reducing the religious friction with the term "Anno Domini". The AD system was invented by Christians before the Orthodox Christians and the Protestants split away from the Roman Catholic Christians, so it belongs to all Christians, with the possible exception of denominations that split away before 525 CE, when the AD system was invented. Since these Christians do not have a mechanism to resolve differences today, there is no answer. Jc3s5h (talk) 16:00, 20 April 2023 (UTC)

Getting back to the original point and ignoring (for now) the PC issue. It's important to remember that year, decade, century and millennium numbers are ordinal numbers, not cardinal. We use cardinal numbers for complete years. Consider a child born at 00:00 on 1 January 2000. For the whole of 2000 he is in his first year, but aged 0. During 2001 he is in his second year, aged 1. During 2009 he is now in his tenth year, but is a 9 year old. As I write he is well into his 24th year, as befits a 23 year old. When his parents talk about 1999 it would be the first year before he was born.

A very old-fashioned way of talking about years (common prior to maybe 1800) would be to describe the year 2000 as "in this the 2000th year of Our Lord", and not as "Jesus is 2000 years old" (ignoring totally that the date of Jesus' birth was not 1 January 1 AD). There is no need for a "year 0". We went from the first year before Jesus' birth to the first year after Jesus' birth. To assign a year 0 would imply it was neither before nor after the birth, and if that had have lasted a full year I think it would have been mentioned! Martin of Sheffield (talk) 21:35, 20 April 2023 (UTC)

Actually, ordinal numbers start with 0. Anyone who gets that wrong is probably a Fortran programmer. See picket-fence problem and off-by-one error. --Trovatore (talk) 23:23, 20 April 2023 (UTC)

ordinal number is real in Fortran. Hawkeye7 (discuss) 00:22, 21 April 2023 (UTC)

Let me see: PL/1, BASIC, FORTRAN, COBOL, Z80 assembly, VAX Macro, Macro-64, C, C++, PHP, Perl, Python ... Hmm, I must fit your description! Martin of Sheffield (talk) 07:17, 21 April 2023 (UTC)

PL/I? PL/I is perfectly capable of doing 0-based indexing. DECLARE FOO(0:BAR) FIXED BIN; -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:20, 21 April 2023 (UTC)

I think Martin is saying that he's used a lot of languages, including Fortran. Fair enough, but you'd think that much experience would have convinced him that 0-based is superior. --Trovatore (talk) 16:48, 21 April 2023 (UTC)

Exactly. But language capabilities are not really relevant which is why the discussion is in small type. Martin of Sheffield (talk) 20:21, 21 April 2023 (UTC)

But what is relevant, to the point you yourself brought up, is that ordinals start with 0. --Trovatore (talk) 20:22, 21 April 2023 (UTC)

See Ordinal numeral Martin of Sheffield (talk) 20:25, 21 April 2023 (UTC)

... and zeroth. You're emphasizing the difference between ordinals and cardinals, but using a linguistic convention for ordinals that evolved before the idea of zero was well understood. That's not terribly convincing. Or rather, it's fine, if your point is that it all comes down to language -- but you could have just said that; it's not clear what the ordinal/cardinal distinction adds to the point. --Trovatore (talk) 20:29, 21 April 2023 (UTC)

Right let's simplify this.

1. A cardinal number is a simple number which reports the number of items. It has a zero. Consider: "how many eggs do you have?", "six". If you give six away you have zero eggs.
2. An ordinal number represents an order. It does not have a zero. Consider: "where did you finish in the race?" "first". No-one came in before the first runner.
3. When recording an age or similar you use cardinal numbers to record the number of complete years: "He was 21 last birthday".
4. When recording dates (days, months or years) you use ordinal numbers to record the position of the date: the 1st of January, the fourth month, the 100th year.

Clearer? Martin of Sheffield (talk) 20:59, 21 April 2023 (UTC)

Your point 2 is incorrect. Or more precisely, it's specific to the way language has developed, and has nothing to do with numbers. If the notion of zero had been developed in time, we would say that the winner finishes zeroth. --Trovatore (talk) 21:05, 21 April 2023 (UTC)

Right - even the section they linked for ordinal number lists "zeroth" first among "common ordinals".

This is not a problem caused by math - it's a problem caused by language. PhotogenicScientist (talk) 21:19, 21 April 2023 (UTC)

"It's specific to the way language has developed" – well of course, it is after all linguistics which describes the language! It's not a problem, it is simple English usage, as taught at secondary school. As regards the link, "Zeroth only has a meaning when counting starts with zero, which happens in a mathematical or computer science context. Ordinal numbers predate the invention of zero and positional notation." BTW Who else linked this?Martin of Sheffield (talk) 21:28, 21 April 2023 (UTC)

If you're saying it's about language, you could just have said that directly. By focusing on ordinals vs cardinals, it seemed like you were trying to make it about numbers. Numbers are a priori; language is contingent. --Trovatore (talk) 23:05, 21 April 2023 (UTC)

I disagree that ordinal numbers always exclude 0. Ordinal numbers are numbers that can be meaningfully ordered. The year 1 undoubtedly comes after the year 0, so there is a definite order. Cardinal numbers, on the other had, are used to count indistinguishable things such as the number of eggs in a carton. (But there is no year 0 in the AD/BC or CE/BCE system.) Jc3s5h (talk) 05:55, 21 April 2023 (UTC)

In fact, from the perspective of set theory, all cardinals are ordinals, and that include 0 (null set). -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:20, 21 April 2023 (UTC)

ITYM empty set. --Trovatore (talk) 20:26, 21 April 2023 (UTC)

Had I written a null set, you would be correct. Despite some comments on wiki, the use of the null set in set theory was not created by the K-12 set; see, e.g., Dugundji, James (1966). "1 Sets". Topology. Allyn and Bacon, Inc. p. 2. ISBN 0-205-00271-4. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:36, 23 April 2023 (UTC)

That usage is essentially nonexistent in research mathematics. If you want to be understood you must say "empty set". --Trovatore (talk) 18:20, 23 April 2023 (UTC)

It is important to remember that a century hass 100 years, including the first century. Unless you want to decree that the first century CE only has 99 years, you're pretty much forced to accept that xx00 is the last year of a calendar century, not the first. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:20, 21 April 2023 (UTC)

That was Steven Jay Gould's reasoning for saying the 21st century began with the year 2000, but as much as I admired him, he was wrong on that. Donald Albury 12:13, 21 April 2023 (UTC)

Not so much "decree" but rather "acclaim world wide by having massive parties and celebrations beginning December 31, 1999." Jc3s5h (talk) 13:34, 21 April 2023 (UTC)

ENGVAR controls big L or little L for litres/liters?

The one-l lama, He's a priest; The two-l llama, He's a beast. -- Ogden Nash

Right now our units table's got:

Group	Unit name	Unit symbol	Comment
Volume, flow	litre liter (US)	L (not l or ℓ)	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 should not be used.
	millilitre milliliter (US)	ml or mL	Derivative units of the litre may use l (lowercase "el") as guided by WP:ENGVAR.

The "don't use lowercase ell in isolation" and as guided by ENGVAR bits both originate with this edit [7], which came on the heels of WT:Manual of Style/Dates and numbers/Archive 160#Litre abbreviation RFC. However, I don't see where the closer (who hasn't edited in a year) got the ENGVAR part -- nor do I know what it means.

I believe we should just drop the text as guided by ENGVAR. Thoughts? EEng 05:44, 27 March 2023 (UTC)

• Agreed - drop.  Stepho  talk  05:53, 27 March 2023 (UTC)
• Long ago in the mists of time the US National Institute of Standards and Technology had officially recommended that people in the US should use L rather than l as the symbol for liter. According to the most recent version of Special Publication 811, page 8, Table 6, footnote b, the General Conference on Weights and Measures (CGPM) has adopted L as an alternative symbol for the liter to avoid confusion with the digit 1. So I would say it used to be an ENGVAR issue, because the guidance to use L came from the US, but now that the main international organization, CGPM, endorses L, it is no longer an ENGVAR issue.
  I could go further and suggest that the English Wikipedia adopt L as the preferred symbol. Jc3s5h (talk) 16:04, 27 March 2023 (UTC)

  That's already what the first row of the table (above) says -- for the symbol standing alone i.e. without (for example) an m for milli. The question is the second row: what forms should be used for milliliter: ml or mL or it-depends-on-ENGVAR? AFAICS the outcome of the RfC I linked didn't support an ENGVAR angle -- I don't see where the closer got that -- so we should drop the text as guided by ENGVAR. If you want L to be used in all cases -- L and mL -- you'll need a new RfC, but please in the name of Jesus do not do that, at least not now. For now I'd really like to just get this odd bit of text dropped. EEng 17:17, 27 March 2023 (UTC)

• I also see no relevance of WP:ENGVAR. The closing 4 words (if engvar counts as a word) add nothing. Dondervogel 2 (talk) 17:50, 27 March 2023 (UTC)
• Go straight to "L". Drop the ENGVAR bit. — JohnFromPinckney (talk / edits) 18:42, 27 March 2023 (UTC)
• The Australian style manual says that either is acceptable but the capital L is preferred to avoid confusion. So I support dropping the ENGVAR bit. Hawkeye7 (discuss) 19:33, 27 March 2023 (UTC)

Now that I've had my coffee, I realize that (I think) we have (A) a solution that then leads to (B) a new problem. The solution (A) is to change

Derivative units of the litre may use l (lowercase "el") as guided by WP:ENGVAR.

to

Derivative units of the litre may use l or L (lowercase or uppercase "el"), with in-article consistency.

Are we all together on this?

But then here's the other problem: (B) Is "milliliters per liter" ml/L? or ml/l? -- or are both acceptable? (And now that I think about it, mL/L is a possibility too. But mL/l makes no sense at all, obviously.) I'm just previewing this (B) thing. Can we all agree on (A) above before we start debating (B)? EEng 02:09, 28 March 2023 (UTC)

• Let's just go for L everywhere (including derived units). Removes the complications altogether.  Stepho  talk  02:40, 28 March 2023 (UTC)

  Please, please, please, pretty please, let's just start by agreeing on (A). You can raise the idea of "L everywhere" later. EEng 03:38, 28 March 2023 (UTC)

  Yep - already agreed to (A) dropping mention of ENGVAR.  Stepho  talk  03:44, 28 March 2023 (UTC)

  Agreed. Support A. And "in-article consistency" rules out ml/L. Somebody please keep EEng away from the coffee before we get to "Y for Gaw'd sake" Hawkeye7 (discuss) 03:10, 28 March 2023 (UTC)

• No, the WP:ENGVAR text should not be removed, because there is a real-world WP:ENGVAR component to this. In Europe, including the UK and Ireland, the lower case l is the standard symbol for the litre. Having a capital L on UK- and Ireland-focussed articles would be almost as jarring as insisting on spelling it "liter". Kahastok talk 07:14, 28 March 2023 (UTC)

  'as jarring as insisting on spelling it "liter"' -- no, the opposite. "litre/liter" remains guided by ENGVAR. Undisputed here. The point & proposal is, that l/L has no ENGVAR base. Your "standard" claim is missing a link. DePiep (talk) 09:06, 17 April 2023 (UTC)

• Support (A) dropping the ENGVAR wording for the millilitre. Support (B), use consistently within article. Support eventual (C), explicitly standardise on only using the upper-case symbol L as the symbol for litres and all derived units (mL, cL, dL, ML, GL, and so on). The fact that the upper-case symbol was explicitly approved by the CGPM for the reason of avoiding ambiguity is sufficiently compelling for me to overlook the ENGVAR issue, especially given that this has already been done in the MOS for the litre itself. XAM2175 ^(T) 11:03, 28 March 2023 (UTC)
• No; I would agree with Kahastok that since there is an Engvar angle to the variations in usage, then the reference should stay. Having in-article consistency sounds fine (and is of course also achieved by Engvar) until we end up with a big argument over an article that has American or British usage but the opposite usage for the measurements within the article. That doesn’t sound particularly sensible, and simply sows seeds for unnecessary in-article misunderstanding and debate in the future. If the reason for supporting a change from ml to mL is simply because editors from the US are more familiar with the latter, then it’s clearly an Engvar issue and the sort of thing that WP:ENGVAR is intended to avoid or resolve. MapReader (talk) 12:02, 28 March 2023 (UTC)

  At the moment, however, we don't have consistency – the MOS mandates "L" regardless of ENGVAR, meaning that articles using both litres and millilitres can end up using "L" alongside "ml". As to "[if] the reason for supporting a change from ml to mL is simply because editors from the US are more familiar with the latter"; that rationale appears to be entirely absent from the discussion so far. XAM2175 ^(T) 12:11, 28 March 2023 (UTC)

  Not entirely absent, I’d suggest. However, more pertinently, on my visits to the US I haven’t seen any evidence that the litre/liter or measurements derived from it such as centilitres or millilitres are in common usage, or even understood, with food packaging and recipes referring to ounces and cups. As the WP article on the metric system says, “the United States is the only industrialised country where commercial and standards activities do not predominantly use the metric system”. Whereas ordinary people in other English-speaking countries are used to seeing metric measurements written on the things we buy from the supermarket and in recipes and countless other commonplace settings. Why would US editors want to impose onto the wider English-speaking world their own format for abbreviations of measurements that most of them never use? MapReader (talk) 12:35, 28 March 2023 (UTC)

  You're swinging a very broad brush with US editors, very broad indeed. Of the editors who have !voted in support and given their location in their user pages, one is in the US, one is in Scotland, and two are in Australia. Hawkeye7 has already noted that the Australian Government Style Manual explicitly prefers upper-case L for millilitres. I further note that the Canadian Government does as well. Even the UK Metric Association do, though I recognise that they're a campaign group rather than an official body. XAM2175 ^(T) 13:05, 28 March 2023 (UTC)

  • ml/L is completely unacceptable; ml/l is acceptable in principle but violates the principle of the close.
  • I support EEng's proposed edit.

  Dondervogel 2 (talk) 18:32, 28 March 2023 (UTC)

  The close definitely does not support the claim that "ml/L is completely unacceptable", and I sharply disagree with that claim. --Trovatore (talk) 22:29, 28 March 2023 (UTC)

  I was not referring to the close. It is unacceptable because it is against the spirit of the MOS, the aim of which is to "promote clarity, cohesion, and consistency". Use of ml/L achieves the opposite of that. Dondervogel 2 (talk) 06:30, 29 March 2023 (UTC)

  "Use of ml/L" is explicitly not part of the topic here. Will not be concluded upon. DePiep (talk) 09:09, 17 April 2023 (UTC)

• Since the idea of English Wikipedia preferring "L" in all cases, including with prefixes, is getting more attention than I expected, I will quote The International System of Units (V2.01, December 2022, Bureau International des Poids et Mesures, pdf with English text), page 145, Table 8, footnote d

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).

Jc3s5h (talk) 12:54, 28 March 2023 (UTC)

• No, it is an ENGVAR issue. For example, UK consumer packaging continues to use "ml" and "cl", in accordance with UK regulations (which remain aligned with European regulations).
  This proposal springs from a request at Template talk:Convert#Liter that {{Convert}} default to "L" rather than "l", which raised concerns that {{Convert}} would be in conflict with MOSNUM. NebY (talk) 13:35, 28 March 2023 (UTC)

  NebY and Kahastok, the UK law is that both ml and ML are allowed. Same for the other derivatives of litre. See https://www.legislation.gov.uk/uksi/1987/1538/made . Bizarrely, that official document says that "1 or L" are allowed for the litre - they use the number one instead of the letter lowercase letter el. However, I do recognise that all their examples and general usage in Britain use "ml", so this is a bit like Commonwealth English strongly preferring "realise" but allowing "realize".  Stepho  talk  15:33, 28 March 2023 (UTC)

  Just so. "mL" would be in accord with UK regulations - see also The Weights and Measures (Packaged Goods) Regulations 2006 - but "ml" is too and is the norm. NebY (talk) 16:58, 28 March 2023 (UTC)

  Exactly. And my point is that seeing these abbreviations in lower case is commonplace in Europe, including the UK, whereas for Americans it is mostly of academic (both literally and figuratively) interest how they are abbreviated, since outside the narrow scientific community no-one there uses them. MapReader (talk) 17:56, 28 March 2023 (UTC)

  In America most groceries are labelled in metric by law. You may well find some items labelled only in metric. Hawkeye7 (discuss) 19:54, 28 March 2023 (UTC)

  Soft drinks/sodas (1 and 2 liter bottles are very common) and alcoholic beverages (using both 'ml' and 'ML'), off the top of my head. Donald Albury 20:12, 28 March 2023 (UTC)

  I have a British education, have lived all my life in Europe, and was taught to spell "litre" (never "liter") and "metre" (except for the measuring instrument, a "meter"), and that "L" and "l" (and by implication "mL" and "ml") are equally valid alternative symbols. Engvar is a red herring. Dondervogel 2 (talk) 18:29, 28 March 2023 (UTC)

  This is the case in Australia and New Zealand too. "L (lower case l is permitted but is better to avoid)" [8] Hawkeye7 (discuss) 19:54, 28 March 2023 (UTC)

• Comment IRL masters matters preclude substantive participation on this matter, though I delight in having managed to spark a lively debate. What I suggest y'all do is start by reviewing the RfC I l linked above, to decide (1) whether the close was faithful to the discussion, and (2) whether the edit made to the guideline was faithful to the close. After making any corrections there, THEN start debating new ideas like "let's all go to L". Just my thoughts. EEng 14:41, 28 March 2023 (UTC)

  You're studying for a(nother) master's? But seriously, this is not a good way to challenge or overturn the close of an RFC. A recent close can be challenged by discussion with the closer or at WP:AN per Wikipedia:Closing discussions. Two years later? Launch a new RFC. NebY (talk) 16:55, 28 March 2023 (UTC)

  Before getting all formal, let's see if we can agree on what happened. To some extent the question is whether the close was flawed, but as much or more is the question of whether the edit reflected the close. I don't see at all where the ENGVAR text comes from. (But I've been run ragged recently so maybe I'm just not seeing it.) Fixing that wouldn't be challenging the close, just implementing it properly. EEng 17:12, 28 March 2023 (UTC)

  It's a good implementation that follows the reasoning of the close (which was good too) by applying the second of the three arguments against B analysed and assessed by the closer, the first having been rejected outright and the third being inapplicable given that there's no consensus re "ml". NebY (talk) 18:05, 28 March 2023 (UTC)

  Here's the actual text that you seem to be talking about in the close:

  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.

  As I read this, the first two rationales are rejected, and only the third is partially affirmed. I don't see any support in the close for mentioning ENGVAR in the guidance. --Trovatore (talk) 23:28, 28 March 2023 (UTC)

  Right. That's my reading as well. Somewhere between making the close and doing the edit, the closer seems to have swept ENGVAR into the mix accidentally. I'm hoping we can all recognize that and get rid of the EMGVAR big, after which the floor is open for further refinement, and hopefully a final settlement of this accursed matter. (That further refinement might even include someone proposing that there should be an ENGVAR angle after all, but to repeat, that doesn't seem to have been any part of the outcome of the original RfC, so it's only fair to return to that base before opening the floor to new change proposals.) EEng 05:49, 29 March 2023 (UTC)

  Followup: My conjecture is that the closer was working on that row of the table, his eye fell on the left cell reading millitre / milliliter (US), and the idea popped into head that there's an ENGVAR issue (which there's not, because that row is about unit symbols, not unit names). EEng 16:58, 29 March 2023 (UTC)

• Yes, if all we are doing here is debating A, then I still support it. I am not convinced by the ENGVAR arguments of Kahastok and MapReader. In an extremely non-rigorous (or non-rigourous), non-scientific study, I painstakingly entered "irish liquid containers" und scanned through the images listed as a result. Of those large containers on which I could actually read the label, the very first was this one, which uses "2.5Ltr". I must confess I was confused momentarily by the "tr"; I was looking for "L", found it, and guessed "tr" meant something Irish. Guess I need coffee, too. I found no other large containers with this search. Small containers invariably use small "el", as in "70cl" or "450ml". But on I forged, with "british liquid containers": This sales image also uses 25L, although that's not exactly an RS. This wasn't scientific or extensive, but I'm not cherry-picking; I actually found few readable large-container labels. My findings are nevertheless that British and Irish usage probably tends toward writing out litres, or using "Ltr", but I'm not convinced the use of "L" would be "jarring", so I support A without mention of ENGVAR. The B part might be trickier. — JohnFromPinckney (talk / edits) 09:13, 29 March 2023 (UTC)

  As an aside, your gesture (or non-rigourous) is appreciated, but not actually necessary – Commonwealth and US spellings have come to align where the "-ous" suffix is concerned; thus it's acceptable that rigour becomes rigorous, valour becomes valorous, etc etc. Separated by a common language indeed! XAM2175 ^(T) 10:39, 29 March 2023 (UTC)

  As I mentioned above, there is no consistency in the US. Looking at an assortment of wine, liquor, and liqueur bottles, those of less than a liter use either "ml" or "ML", while those of one liter or more use "LITER(S)", either on the label or molded on the bottle. Both domestic and imported brands use either "ml" or "ML", but the labels, and often the bottles, of imported brands are produced in the US. Of the two bottles I have that were purchased in Europe (both with labels printed in English), the one from Greece uses "ml", while the one from Denmark uses "ML". There certainly is no consistent form in commercial use in the US. Donald Albury 15:56, 29 March 2023 (UTC)

  For the avoidance of doubt here Donald, ML, as opposed to mL, is the symbol for the megalitre; 1 ML = 1,000,000 L (264,172 US gal). A rather significant difference!

  (The discussion here would suggest that a British megalitre would have the symbol Ml, which I confess to my eyes looks exceptionally odd.) XAM2175 ^(T) 16:21, 29 March 2023 (UTC)

  Wow, one slip of the shift key and suddenly ... [9]. EEng 16:55, 29 March 2023 (UTC)<>/del>

  Yes, it is a shame that merchants and customers don't pay attention to official definitions. Should I sue the distributor because the bottle of wine says 750 ML on the label, but only holds 750 ml? I wonder if I could find a court that would allow me to pursue that case. Donald Albury 18:11, 29 March 2023 (UTC)

  I once saw a pharmacist in the US label a prescription in "Mg" rather than "mg"... XAM2175 ^(T) 18:16, 29 March 2023 (UTC)

  @Donald Albury: Be sure to check the settlement is paid in MUSD, not mUSD. Dondervogel 2 (talk) 19:26, 3 April 2023 (UTC)

  Note that the text in discussion is specifically about derivative units of the litre, particularly the millilitre. As such, the only piece of evidence you cite that is actually relevant to this discussion is Small containers invariably use small "el", as in "70cl" or "450ml". i.e. confirming the preference for lower-case ml and cl in Britain and Ireland, a preference that is not shared elsewhere. Hence, an WP:ENGVAR issue. Kahastok talk 18:21, 29 March 2023 (UTC)

  From my (American) perspective, mL comes off as a bit pedantic, though it does seem to be used in a majority of the bottles I checked around the house. I also found ml and ML. On the other hand L is pretty much obligatory, not for any nationalistic reasons, but because of the original sin of Wikipedia, namely choosing a sans-serif typeface as the default. --Trovatore (talk) 20:42, 29 March 2023 (UTC)

  Update on the last point: I tried editing my CSS to default to a serif font, and it turns out that lowercase ell still strikes me as looking too much like a numeral one to be usable for "liters". --Trovatore (talk) 20:48, 30 March 2023 (UTC)

  "l" and "L" for litre are not language or cultural at all (i.e., what ENGVAR is about). They are symbols, not words not even 'abbreviations', both defined per SI (without SI stating a preference). As editors we (wiki) are free to choose one. "Habits" do not tie us. Especially not when (1) oficially none is prescribed (UK, eg) and (2) when the issue is legibility not cultural.

  Sidetest: given the UK gov link here, "the" ENGVAR-UK form is not even defined. DePiep (talk) 09:26, 17 April 2023 (UTC)

• Coming a bit late to this, but FWIW my !vote is to support the proposal to drop the ENGVAR reference (I am not sure whether mathematical symbols can even be considered part of English, or any natural human language) as it seems pedantic and unnecessary. There's no reason we can't be consistent in recommending the use of "L", which (as pointed out above) is what most standards orgs do in any case. I don't recall seeing any authoritative body prescribing the use of "l" over "L", come to think of it. Moreover, it is not unreasonable to expect an editor coming to MOSNUM for advice on such usage to find it a bit confusing that they are instead referred to ENGVAR, which does not discuss anything related to units of measurement (nor should it). Archon 2488 (talk) 14:31, 3 April 2023 (UTC)

  For the record, I also support deprecation of the lower case "l". That would promote increased coherence within and between articles. I am not advocating a mass change from "ml" to "mL" in existing articles, but suggesting that a change in the other direction would be discouraged. Evolution, not revolution. Dondervogel 2 (talk) 21:57, 3 April 2023 (UTC)

• Given that IEC allows both, I would go with upper case, since it is easier to distinguish "L" from "1". --Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:49, 3 April 2023 (UTC)

  We're not talking about L vs l now. EEng 01:30, 4 April 2023 (UTC)

---

OK, just to count heads: Unless I'm missing something, only NebY objects to the proposal on the table -- which (to repeat) is to replace

Derivative units of the litre may use l (lowercase "el") as guided by WP:ENGVAR.

to

Derivative units of the litre may use l or L (lowercase or uppercase "el"), with in-article consistency.

NebY: before I unleash the mob to pummel you into submission, is there any possibility that Trovatore's response to you above (see #anchor) has convinced you to go along? And anyone who does object, but I missed, please speak up now (after considering, as mentioned, the above). EEng 01:30, 4 April 2023 (UTC)

Needless violent language here, EEng. DePiep (talk) 08:27, 21 April 2023 (UTC)

Needless comment born of your misreading of social cues three weeks after the fact, DePiep. EEng 12:37, 21 April 2023 (UTC)

You wrote it. It's agressive. If you mean something else, write something else. -DePiep (talk) 15:20, 21 April 2023 (UTC)

DePiep, you've been asked over and over to stop trying to referee the interactions of other editors, because you lack sufficient awareness of social cues to understand what's going on. I meant what I wrote, and I'm not going to use kindergarten baby-talk just because that's what you need in order to understand what everyone else readily gets. Really, just butt the fuck out of others' conversations -- see (among many examples) WP:Administrators'_noticeboard/IncidentArchive1018#EEng_agression. EEng 22:38, 25 April 2023 (UTC)

@EEng: agressive and condescent language here, again. Usage not motivated, no opening for discussion. Civility is a pillar. "Request" denied. My question stands: EEng, please avoid agressive language. DePiep (talk) 04:50, 26 April 2023 (UTC)

Too bad cluelessness and unintelligibility aren't pillars -- you'd be the undisputed God King Emperor of Wikipedia. EEng 10:49, 26 April 2023 (UTC)

DePiep, if I may interject: EEng's post was colloquial in nature. It employs a form of jocular hyperbole frequent – and almost universally accepted – in casual English. It was not meant as a threat, and I cannot imagine anybody seriously interpreting it as a credible threat, or thinking that it is egregiously uncivil. If you, or any other person, do genuinely feel that this is offensive, you are welcome to report it at AN/I. Further discussion here will be completely unproductive. XAM2175 ^(T) 09:20, 26 April 2023 (UTC)

Hang around DePiep a while and you'll find your powers of imagination greatly enhanced. My link above is just one of a dozen times he's been told -- at ANI! -- that he doesn't know what he's talking about. But like a bad penny he just keeps coming back. EEng 10:49, 26 April 2023 (UTC)

I see Kahastok and MapReader both arguing that it's an ENGVAR matter, and arguments that Ireland or Australia use "L" don't detract from that; ENGVAR has never been about a binary choice between AmEng and all the rest, and it should surprise no-one that sometimes BrEng differs from AusEng or IrEng. EEng, when you opened this discussion it was in terms that you weren't trying to overthrow the close of an RFC that's only two years old, merely its implementation, as if the two were separate and the implementation was by someone who misunderstood the close. I at least failed at first to appreciate that the closing statement and the implementation were by the same respected and experienced editor at the same time. Far from one editor misunderstanding another, what we have is User:力 being thorough and performing a close in two parts, a statement and an implementation. Together they make the totality of the close. You don't like the close of an RFC and it's too late to question the closer or take it to WP:AN for review? Ask a question directly in another RFC. NebY (talk) 17:59, 4 April 2023 (UTC)

I agree with this, both on the substantive point and the procedural point. Kahastok talk 19:04, 4 April 2023 (UTC)

The Australian manual of style given above says that L is preferable but that both L and l are acceptable, so that takes Australian out of the ENGVAR argument.

I didn't see an explicit Ireland reference above but I gave a UK (including Northern Ireland) reference that uses lots of lowercase examples but says both L and l are acceptable (technically it used the number 1 instead of lowercase el but that was probably a typo and not repeated in ml, etc). So the UK is also out of the ENGVAR argument.  Stepho  talk  22:22, 4 April 2023 (UTC)

I reiterate my strong opposition to classifying unit symbols, or any other mathematical symbols, in any context, for any reason whatever, as part of any variety of English or any other natural language. To anyone who objects, please explain to me what variety of English, or any other natural language, the statement "e^πi + 1 = 0" is written in.

And for emphasis: I oppose any attempt to push any MOS-level advice on the appropriate use of unit symbols to any part of the MOS other than MOSNUM. I would also note that no RS deprecating the usage of the symbol "L" in UK/IE (or any other, AFAICS) contexts have been cited, and at present we have nothing but the POV of a couple of editors against its usage. Archon 2488 (talk) 21:55, 4 April 2023 (UTC)

• I apologize for overlooking Kahastok and MapReader. I'm really distracted IRL and not hitting on all cylinders:
• As already stated, it's not that I "don't like the close", just I think the closer may have had a brain fart between the close per se and the edit meant to implement it. Tell me again where in the close per se there's anything about recognizing an ENGVAR issue?

EEng 04:05, 5 April 2023 (UTC)

I boldly implemented EEng's suggestion. My reason? The argument that ENGVAR is remotely connected with the choice of symbol is patently absurd, per Archon 2488. The whole point of international standard unit symbols is that they are international standard symbols. It does not matter whether one is writing in Spanish, French, Italian or any other language using a Latin alphabet. Beyond the alphabet, language is irrelevant. Dondervogel 2 (talk) 13:40, 5 April 2023 (UTC)

Not even confined to the Latin alphabet, actually! Archon 2488 (talk) 13:58, 5 April 2023 (UTC)

• Support. That's drop the text "as guided by ENGVAR" per OP. Also per proposal, this change should not decide on some preferred usage of "l" vs. "L". Just remove the text. ("consistent l or L in article" is trivial here, and should not be metioned). -DePiep (talk) 08:37, 17 April 2023 (UTC)
• Comment The wording of the close may have been a bit awkward. The intent appears to have come through clear: there was consensus to disallow "l", but no consensus to disallow "ml". (I personally agree that "ml/L" together is bad, but there wasn't consensus to establish even that as policy from the discussion. If you don't like that, you should start a new RFC.) Why would one choose "ml" or "mL"? A lot of the arguments were "we should do it the way it is done in the US/UK", so the existing policy guiding usage was WP:ENGVAR. Re-wording the MOS page to be clearer would not need a new RFC. 力 (π, ν) 174.213.160.140 (talk) 19:03, 30 April 2023 (UTC)

My changes to MOS:£

I have made several changes to clean up the section; please also see my edit summaries for the individual edits. Thank you. NotReallySoroka (talk) 03:44, 30 April 2023 (UTC)

I approve. This is clearer than my version (which preceded it) and much clearer that what went before. --𝕁𝕄𝔽 (talk) 19:23, 30 April 2023 (UTC)

Question about formatting

I was wondering if formatting like this is allowed: On September 12^th, 2001... I just saw an article use it; I pointed to MOS:DATE and changed the superscript, but I can't actually find a specific rule prohibiting it. Cessaune [talk] 18:38, 17 May 2023 (UTC)

@Cessaune MOS:DATESNO is where the advice against using ordinals is, which would include ordinals with superscripts. —C.Fred (talk) 20:56, 17 May 2023 (UTC)

No th, nd, or st. Tony (talk) 03:01, 23 May 2023 (UTC)

Yep. Cessaune, see also MOS:SUPERSCRIPT#Dates and numbers.  — SMcCandlish ☏ ¢ 😼  10:59, 24 May 2023 (UTC)

Editor insisting on dmy for US-designed and -made sailboat

Seafarer 31 Mark II. I've been twice reverted by AHunt. Can someone talk to this person? "The Seafarer 31 Mark II is an American sailboat ... The design was built by Seafarer Yachts in the United States, starting in 1974, ..." Tony (talk) 03:05, 23 May 2023 (UTC)

Please don't irritate article writers by insisting they change the style they used to write an article. MOS is a guideline and according to the most recent edit summary by Ahunt, it is a widely exported consumer product, it does not has "strong ties to a particular English-speaking country". If you really want to waste time, you could start a discussion and then an RfC on article talk. Johnuniq (talk) 04:34, 23 May 2023 (UTC)

Are you accusing me of edit warring? You'd better not be. I reverted once, with good reason; AHunt has reverted twice. Be careful whom you accuse. I'm refraining from stating that you irritate people by not knowing what MOSNUM says on this matter—particularly the use of "unless" (see green text below). Tony (talk) 12:31, 23 May 2023 (UTC)

If it was made in some non-English speaking country then I would agree.

But being designed, raced (prototype), manufactured and sold from the US, it has close ties to the US. Therefore, in my opinion, WP:DATETIES overrides WP:DATERET. Even though I personally think the US date format sucks eggs.

I do agree that this would have been better solved by discussion on the article's talk page instead of a revert war (as per WP:BRD) and then running here.

Has anybody informed AHunt of this discussion or mentioned this talk on the article's talk page? Or are we doing things behind editor's backs?  Stepho  talk  05:46, 23 May 2023 (UTC)

I was sort of notified by the poster on his talk page, but no link provided. It was User:Johnuniq who pinged me to come here, so thank you for that.

Boats are typical mass-produced consumer products that are widely exported. They are the same as any other consumer product, like coat hangars or laptop computers and do not have "strong ties to a particular English-speaking country" like say the government's constitution, elections or armed forces do. There is no need to impose nationalistic promotion goals here. MOS:DATERET is pretty clear on this:

* If an article has evolved using predominantly one date format, this format should be used throughout the article, unless there are reasons for changing it based on strong national ties to the topic or consensus on the article's talk page.

* The date format chosen in the first major contribution in the early stages of an article (i.e., the first non-stub version) should continue to be used, unless there is reason to change it based on strong national ties to the topic or consensus on the article's talk page.

* Where an article has shown no clear sign of which format is used, the first person to insert a date is equivalent to "the first major contributor".

WP:DATETIES essentially says the same thing, there is no contradiction there. I carefully adhered to what both of these says in writing the boat articles that I started. I am not sure anyone would be arguing that "this coat hanger or computer was made in China, therefore we must use Chinese date styles". It would seem like an attempt by an editor to impose some odd sense of nationalism where none is warranted or supported by the MOS. - Ahunt (talk) 12:20, 23 May 2023 (UTC)

OK, so the whole thrust of date-formatting guidelines has changed. If a bio of an American uses dmy, you're not allowed to change it to may. Is that what people are saying? If so, this aspect of MOSNUM has to be rewritten. Tony (talk) 12:29, 23 May 2023 (UTC)

I think you are convoluting things here. A person is not a consumer product. That said I think articles on biographies would have to be considered on a case-by-case basis. A US citizen who lived in the country their whole life and grew up to be a war hero or president might be argued to have "strong national ties", but an American citizen who moved to the UK at young age and became a famous author in Britain, later lived in Paris and so on, would obviously not. But that is not what we are talking about here. - Ahunt (talk) 12:36, 23 May 2023 (UTC)

Looking at the article, I'd agree that strong ties to the United States is a reasonable conclusion, and a more relevant criterion than whether the original creator of the article may feel irritated. Let's follow guidelines. Dicklyon (talk) 16:35, 23 May 2023 (UTC)

And as for discussing on the article talk page, that's seldom a useful way to attract input on style and guidelines, unless there's a place to list the discussion more centrally, as we have for example at WT:MOSCAPS. Dicklyon (talk) 16:41, 23 May 2023 (UTC)

I think the important thing here is that this is a small thing and not worth worrying about much. I'm happy to let other people "win" on small issues. It makes me feel like the better person and inflates my ego (so in my mind, I win). If this article is about to become a featured article, then by all means start a discussion on the article's talk page and work out a good solution using Wikipedia's dispute revolution methods, but until then, chill. SchreiberBike | ⌨  14:14, 23 May 2023 (UTC)

• I don't feel it's a big deal either, but to argue that it should be dmy strikes me as being counter-intuitive. I must say, though that I wouldn't mind if all articles were in dmy. Let me explain how the guideline is usually applied: to my mind, MOS:DATERET would arguably apply if the article was a generic or undifferentiated consumer good, such as for example telephone, car or refrigerator, as it's impossible or unreasonable to argue that WP:TIES must apply. In such a case, the "first major contribution rule" applies as it would not be appropriate to change the date format.

  However, "consumer goods" such as the F16 follows the convention adopted by the US military; Bentley Continental GT is formatted in dmy – its manufacturer is British; the iPhone 14 is in mdy – it is manufactured by a US company. By the same token, Andre Geim is naturalised British, so dmy is used in his article. And if they were not, a strong case can be made to them per WP:TIES, and WP:RETAIN can be overruled. According to the information in the article: The design was built by Seafarer Yachts in the United States, starting in 1974. It's not as if the article is about MS Queen Victoria, which ought to be in dmy by my reckoning irrespective of where it was built. To conclude, therefore, I believe that Seafarer 31 Mark II ought to use mdy dates. -- Ohc ^{revolution of our times} 18:25, 23 May 2023 (UTC)

  I would object vociferously if all articles were in dmy. If there is ever a universal wiki style for dates, it should be ISO 8601, not one of the parochial conventions used Today. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:54, 23 May 2023 (UTC)

  I don't think it was a serious suggestion. XAM2175 ^(T) 20:00, 23 May 2023 (UTC)

  The reason we have an MoS at all is that style matters shouldn't be a big deal but inevitably turn into drawn-out shitshows. MoS exists to nip such disputes in the bud. This dispute should not have arisen in the first place. This is clearly a US-designed, -manufactured, and -marketed product, and the article is written in American English (fiberglass not fibreglass), so it should be using the US date format. MOS:TIES. There is no "I got here first, so my way or the highway" principle. (People sometimes get confused about this because of MOS:RETAIN. But it does not give early arrivers special rights. Rather, we revert to whatever what used in the first non-stub version of an article, if and only if discussion cannot produce a consensus. I don't think there's any risk of discussion not producing a US-English consensus in this case.)  — SMcCandlish ☏ ¢ 😼  21:41, 23 May 2023 (UTC)

  Agree {{u|Sdkb}} ^talk 04:12, 31 May 2023 (UTC)

• Oh, and for the record I don't like US mdy formatting either. But I follow the rules as best I can. Tony (talk) 07:46, 25 May 2023 (UTC)
• Seems to me that the only dates currently being used on the Seafarer 31 Mark II article are only in citations templates, not directly in the article prose or the infobox. Thus WP:CITESTYLE applies, and the YYYY-MM-DD format could be used instead for all those citations. I will concede that this would only be a temporary compromise until a DMY or MDY date is actually added to the article prose or the infobox. Zzyzx11 (talk) 12:12, 25 May 2023 (UTC)

  Well that really is the irony here in this rather long and involved debate, that all the actual dates in the article are contained in reference templates and so subject to the page's templated formatting. So for either outcome here it is really a matter of swapping two letters or not: {{Use dmy dates|date=May 2023}} or {{Use mdy dates|date=May 2023}}. That is it. - Ahunt (talk) 17:21, 25 May 2023 (UTC)

• However the date thing turns out, be sure to refer to boats as "she". See Wikipedia:Queen Elizabeth slipped majestically into the water. EEng 02:43, 31 May 2023 (UTC)

Line wrapping and units

Is there a sound reason why we require that "...a normal space is used between a number and a unit name" and not a non-breaking space? To me, it looks wrong (doubly so where the figure is a single digit), and I strongly suspect it hinders readability. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:03, 10 April 2023 (UTC)

It seems a bit odd, yes. It's also inconsistent with how the MOS treats constructions like "21 million", where MOS:NUMERAL holds that a non-breaking space should be used. XAM2175 ^(T) 12:38, 10 April 2023 (UTC)

I find all linebreaks between a numeral and any following term ugly, jarring, and confusing but the discussionshave always gone against me.--User:Khajidha (talk) (contributions) 04:36, 12 May 2023 (UTC)

For a decade I've been meaning to bring order out of the linebreak chaos, but it's a daunting task. EEng 06:11, 12 May 2023 (UTC)

Proposal: Allow use of % for percentages in non-technical articles

MOS:PERCENT currently has the following to say:

• In the body of non-scientific/non-technical articles, percent (American English) or per cent (British English) are commonly used: 10 percent; ten percent; 4.5 per cent. Ranges are written ten to twelve per cent or ten to twelve percent, not ten–twelve per cent.
• In the body of scientific/​technical articles, and in tables and infoboxes of any article, the symbol % (unspaced) is more common: 3%, not 3 % or three %. Ranges: 10–12%, not 10%–12% or 10 to 12%.

This seems a bit dated to me, as the percent symbol is ubiquitous these days and easily understood not just in technical spaces. Reflecting this, the AP Stylebook changed its advice in 2019 to start advising Use the % sign when paired with a number, with no space, in most cases.

References

I propose that we modify the section to read:

• In the body of scientific/​technical articles, and in tables and infoboxes of any article, the symbol % (unspaced) is generally preferred: 3%, not 3 % or three %. Ranges: 10–12%, not 10%–12% or 10 to 12%.
• In the body of non-scientific/non-technical articles, either the symbol or wording may be used. When using words, use percent (American English) or per cent (British English): 10 percent; ten percent; 4.5 per cent. Ranges are written ten to twelve per cent or ten to twelve percent, not ten–twelve per cent.

Thoughts? {{u|Sdkb}} ^talk 21:24, 14 May 2023 (UTC)^{Edited 22:26, 14 May 2023 (UTC) per Hawkeye's suggestion below.}

• Seems like a sensible relaxation of the MOS to me. pburka (talk) 22:00, 14 May 2023 (UTC)
• Some thoughts:
  1. "Writing out" seems an odd wording to me. I think what is meant is "using words"
  2. I advocate that we explicitly state that "three %" is no good and that the % sign is only used with numbers.
  3. Is mixing forms okay? In particular, we have the case of avoiding starting a sentence with a number.
  4. The Australian Style Guide has more restrictions on their use [10] which could be considered
  5. Also, what about the per mille (‰)? Does this apply to it too?
• Hawkeye7 (discuss) 22:06, 14 May 2023 (UTC)

  Good questions, Hawkeye7. Re (1), yes; I've modified to the proposal to use those words. Re (2), I agree. three % is already in red, so is that covered? Re (3), WP:NUMNOTES elsewhere in the guideline covers not starting sentences with figures, so it would follow to me that any percentages starting a sentence would need to use words, even if the article elsewhere uses figures. Beyond that exception, I'd think we'd want to encourage consistency within an article per MOS:CONSISTENT. Re (4), good to know, but that doesn't change my overall perspective; I wouldn't be surprised to see the Australian Style Guide update their guidance in the near future. Re (5), golly no! That symbol is infinitely less recognizable than %, so very different considerations apply, as we'd need to make sure it's introduced/explained to readers before we'd want to use it. {{u|Sdkb}} ^talk 22:26, 14 May 2023 (UTC)

  Re (2): three % is already in red, but only for scientific and technical articles. Hawkeye7 (discuss) 22:48, 14 May 2023 (UTC)

  If you can find a way to state that "three %" should never be used anywhere while keeping the section concise, I'll be happy to consider it a friendly amendment. {{u|Sdkb}} ^talk 22:56, 14 May 2023 (UTC)

I have no objection to "3%" being used for non-technical articles, but for technical articles, "3 %" should be preferred. International standards describing the International System of Quantities (ISO 80000) require a space between the numerical value ("3") and the unit symbol ("%") in technical writing. Dondervogel 2 (talk) 22:28, 14 May 2023 (UTC)

Whether to have a space or not is something that varies between style guides, it seems, but it's been a longstanding convention on Wikipedia to not have the space. Changing it would require modifying a ton of articles; you could try proposing it separately (this proposal is just about percent/per cent vs. %), but I don't see a compelling case to switch that would justify the disruption. {{u|Sdkb}} ^talk 22:38, 14 May 2023 (UTC)

ISO80000 can go to hell. Percents are unspaced, always. Headbomb {t · c · p · b} 22:40, 14 May 2023 (UTC)

I think you meant to say 100% of the time. —Locke Cole • t • c 23:18, 14 May 2023 (UTC)

ISO 8000: The symbol of the unit shall be placed after the numerical value in the expression for a quantity, leaving a space between the numerical value and the unit symbol. It should be noted that this rule also applies to the units per cent, % and per mil, ‰. [11] Hawkeye7 (discuss) 00:13, 15 May 2023 (UTC)

My attempt at humor failed. For what it's worth, I agree with the general proposal. —Locke Cole • t • c 00:31, 15 May 2023 (UTC)

Better leave the humor to the professionals. EEng 02:44, 31 May 2023 (UTC)

@Sdkb: One can permit (without requiring) "3 %" in technical articles without causing an iota of disruption. The compelling case is that the present wording unnecessarily requires editors to depart from ISO 80000. Dondervogel 2 (talk) 23:15, 14 May 2023 (UTC)

I propose that we refactor the section to read:

• In the body of scientific/​technical articles, and in tables and infoboxes of any article, the symbol % (unspaced) is generally preferred.
• In the body of non-scientific/non-technical articles, either the symbol or wording may be used.
• When using words, use percent (American English) or per cent (British English): 10 percent; ten percent; 4.5 per cent. Ranges are written 10–12%, ten to twelve per cent or ten to twelve percent, not ten–twelve per cent, 10%–12% or 10 to 12%. Use numbers and not words with the percentage sign three percent or 3% not three %.

Hawkeye7 (discuss) 00:05, 15 May 2023 (UTC)

I'm happy to allow the symbol % in any article (technical or not), as long as the symbol goes with digits and percent always goes with written out numbers and that the article is consistent (exception allowed for digits and % always acceptable in tables and infoboxes). Don't care about space vs non-space (I'm Australian but that style guide is for Australians writing to Australians and therefore is not binding to a worldwide audience). Likewise, following ISO is nice (and even preferred) but it will not confuse people. I suspect general readers will probably think the per mille (‰) is a weird per cent symbol and get it wrong - avoid !  Stepho  talk  00:36, 15 May 2023 (UTC)

I agree we should allow non-technical articles to use %. I am fine with either Sdkb's or Hawkeye7's wording. (‰, if anyone wants to use it, should be a separate discussion; it's much less used AFAICT.) -sche (talk) 20:53, 17 May 2023 (UTC)

• Implemented the change, as we seem to have broad agreement here. I made a few further tweaks to the wording, as I think it's nice to put examples right beside the associated rule when possible, but nothing that changes the substance. Feel free to adjust it further if you can improve it. {{u|Sdkb}} ^talk 21:14, 17 May 2023 (UTC)

$x USD/£x GBP

A few articles employ a notation where a currency sign and a corresponding ISO 3-letter code both appear in the same figure. Should it be explicitly disallowed? DeeDeeEn (talk) 05:30, 11 June 2023 (UTC)

Can you show us some examples? Dondervogel 2 (talk) 05:39, 11 June 2023 (UTC)

This diff has me specifically editing an instance of the notation. This section involves two currencies in such format. DeeDeeEn (talk) 05:54, 11 June 2023 (UTC)

The D in USD stands for dollar and the P in GBP stands for pound. Which makes $50 USD stand for 50 dollars United States dollars and £50 GBP stand for 50 pounds Great Britain pounds. In both examples this is duplicitous and should be avoided. We can use the symbol or the 3 letter code but not both.

A good way to avoid the problem is to use one of the {{USD}}, {{GBP}} or {{currency}} templates.  Stepho  talk  06:05, 11 June 2023 (UTC)

I have no objections. However, I am proposing that this problem be explicitly addressed in the Manual of Style. DeeDeeEn (talk) 06:51, 11 June 2023 (UTC)

FYO stylemanual.gov.au, Imperial College London, regards, Govvy (talk) 08:30, 11 June 2023 (UTC)

The latter site doesn't seem to mention the topic at hand at all. Good to know that there is one style manual explicitly mentioning this though. DeeDeeEn (talk) 08:38, 11 June 2023 (UTC)

These codes do not infact stand for anything, they aren't abbreviations. "USD" only resembles an abbreviation, whereas "GBP" isn't an abbreviation of any term at all ("Great Britain pound" is a backronym). Personally I think that "$" and "£" on their own with no additions are widely enough understood to refer to US dollars and sterling that the ISO codes are unnecessary in the vast majority of circumstances. 92.12.143.145 (talk) 22:58, 11 June 2023 (UTC) Ban-evasion by WP:Sockpuppet investigations/TheCurrencyGuy 74.73.224.126 (talk) 00:45, 14 June 2023 (UTC)

That can be said for the pound sterling. However, the MoS has already stated how "$" does not just stand for the US dollar.

Additionally, this topic isn't about which of the two to use; it's whether the use of both should be mentioned in the MoS. DeeDeeEn (talk) 01:02, 12 June 2023 (UTC)

@DeeDeeEn: that's an LTA who, as the master accounts username suggests, is obsessed with currency and also The Troubles for some reason. ISP is usually TalkTalk and he's previously left disruptive messages here from that same /21 range here (see archived discussion). Some other TalkTalk ranges involved include 92.21.248.0/21 and 92.9.0.0/21. Given the broadness of the mobile ranges available more is likely forthcoming. Just revert, collapse, or strike posts as appropriate, but otherwise ignore and don't engage. 74.73.224.126 (talk) 00:45, 14 June 2023 (UTC)

I did not have prior information about the long-term abuser. I therefore treated the IP user without taking any of the above into account. Thank you for taking the time to mention me, however. DeeDeeEn (talk) 01:17, 14 June 2023 (UTC)

No worries, I was just letting you know for the next time it happens. 74.73.224.126 (talk) 01:18, 14 June 2023 (UTC)

MOS:CURRENCY gives explicitly our style guidance for these currencies. As with the rest of the MOS, we don't tend to list all of the ways that people can get it wrong. So no need to add yet another rule, just remove the error as you would any kind of spelling or grammatical error. --𝕁𝕄𝔽 (talk) 11:15, 11 June 2023 (UTC)

I mean, $x USD is, though established to be incorrect, widely commonplace. I couldn't see a point where I would be forbidden to repeat the currency name; however, thank you for your reminder. DeeDeeEn (talk) 12:15, 11 June 2023 (UTC)

I have never seen it but I assume you have done, enough to make for you to feel justified in raising here. If your edits to correct it are being reverted on the basis that the MOS doesn't deprecate it, then yes, we need to say so. Has anybody else seen it? (Google won't use it as a search argument.) 𝕁𝕄𝔽 (talk) 13:34, 11 June 2023 (UTC)

I, fortunately, have never been reverted due to a style problem regarding this notation. However, it is used frequent enough that I believe proposing this is a fair idea.

I still await others' comments. DeeDeeEn (talk) 14:00, 11 June 2023 (UTC)

You have unanimous agreement here (including mine) that writing the dollar sign followed by USD (or the pound sign followed by GBP) is incorrect. I suggest you edit with that unanimous agreement in mind. If you find others revert you (after you have referred them to this discussion) I would support a change to the MoS. Dondervogel 2 (talk) 14:22, 11 June 2023 (UTC)

Thank you for clarifying. This would render syntaxes like $x USD, USD $x or USD$x unacceptable.

I shall follow this up with an update the next time someone contests my edits. DeeDeeEn (talk) 14:30, 11 June 2023 (UTC)

That sounds reasonable. Thank you for checking in. Dondervogel 2 (talk) 14:57, 11 June 2023 (UTC)

MOS:CENTURY-related discussion at VPP

Please see Wikipedia:Village pump (policy)#Without looking it up, what year and day were the ends of the 6th century BC? Firefangledfeathers (talk / contribs) 20:10, 24 July 2023 (UTC)

Semi-automated changes to YYYY-MM-DD in templates

Edits like this made with the MOSNUM dates script provide no benefit to the reader, as dates already render as intended. They do, however, make translating citations more difficult as I explain here. YYYY-MM-DD is allowed in citation templates per MOS:DATEUNIFY—there is no MOS reason to change this formatting, but because these changes are not explicitly prohibited, the script continues to be used in this way.

Relevant discussions I am aware of:

• In June 2019 an editor notified the script creator that date formatting in citation templates was no longer necessary, and advised that edits which solely make this change should not be completed.
• In March 2023, discussion was raised at the script's talk page. Editors deferred the conversation to this page.
• In April 2023, discussion was taken here (WT:DATE), but it fizzled out and ultimately no action was taken.
• In May 2023, I raised the issue again. There were well-intentioned, but convoluted, suggestions on how I could personally fix the issue.

I find this specific use case of the script incredibly frustrating and demotivating. With the script, this change takes a few seconds to perform and doesn't seem to provide any benefit, but causes extra work for others. I can individually reach out to the editors making these semi-automated edits (and I have), but I'm just one person. Maybe an RfC is the correct next step here? Thanks. Wracking ^talk! 19:45, 12 July 2023 (UTC)

• We need an end to this bullshit, which has been going on for years and years and years, to no purpose but causing much wasted editor time. The script is broken and should not be used. Either the script itself should be banned (WP:BAG?) or Giant Snowman, who seems unable to learn how to use it without causing regular disruption, should be banned from using it. Paging David Eppstein. EEng 22:16, 12 July 2023 (UTC)

  To add to "the script is broken": it does not know how to handle cs1-dates=ly format (that is, spelled-out publication dates and numerical access dates for references), which is one of the standard MOS-approved styles, and will break that format when applied to articles using that style. I have complained about this for years, with the typical response from the script writer being WONTFIX and the typical response from the script users being "that's just how the script works, I can't change it and I'm not going to stop using it". I'm too lazy to look for diffs for all that right now.

  Giant Snowman is only one of multiple editors doing this. For a long time I even thought Giant Snowman and The Rambling Man might be socks for the same editor because they were behaving the same way with respect to this script, but I encountered others later and now think that it's just the existence of the script that caused them to behave similarly.

  It's also mostly cosmetic, in the sense that it does not affect the readers at all: in any article using citation templates and properly tagged for its date style, the dates are reformatted by the templates and rearranging them beforehand is pointless. —David Eppstein (talk) 22:33, 12 July 2023 (UTC)

  As a minor procedural note, since this is users individually choosing to run a script on a page it does not fall within the purview of WP:BAG any more than use of twinkle does. 74.73.224.126 (talk) 01:07, 13 July 2023 (UTC)

  Whether it's BAG, ANI, or firing squad, I don't care. EEng 02:28, 13 July 2023 (UTC)

  I think the issue is about the script's task of changing YYYY-MM-DD to MDY or DMY in reference templates. The issue isn't that certain people are using the script in this way, but that the script is able to be used in this way (and it's the default!). Based on WP:BOTAPPEAL, I think WP:BOTN may be the place to go, with a clear and concise explanation of the issue and why it is fundamental to the script, not an issue of individual operator action. Wracking ^talk! 21:34, 14 July 2023 (UTC)

  If a script is broken, then either fix the script or delete it. The only thing remotely BOT-related here is if there's WP:MEATBOT behaviour, and WP:MEATBOT gives admins all the leeway they need to act here. BAG has no special purview over scripts. Headbomb {t · c · p · b} 21:49, 14 July 2023 (UTC)

  I think the issue is that, while some editors think the script is broken and have asked for this functionality to be removed or restricted, others (such as some script users and the original developer) disagree, saying the script is not broken and is working as intended. This (YYYY-MM-DD to DMY or MDY in ref templates) is a default functionality of the script, to my understanding. (Meaning I would not define it as an issue of individual script-users.) Wracking ^talk! 03:18, 15 July 2023 (UTC)

  I have to agree with Wracking that the function of the script is not indisputably broken. As the CS1 templates work today, the presentation to the users can easily be made to comply with whichever format the editors of the article form a consensus for. We have no unequivocal principle of style or citation that says the wikitext must obey any particular style (with a few exceptions for especially confusing usages). We are not like a software shop where if your code doesn't follow the company style, you'll be in trouble with the boss.

  The strongest ground to attack the script, in my opinion, is that it my experiments suggest it doesn't behave the way the documentation says it behaves; I would have thought if you put a particular value in the cs1-style parameter, the script would obey it. But so far as I can determine, that parameter is ignored. Jc3s5h (talk) 10:20, 15 July 2023 (UTC)

Wracking, was my suggestion too convoluted? Copying again: "is it possible to copy-and-paste the English versions into your sandbox, run this tool to change to either YYYY-MM-DD or DD-MM-YYYY, and then translate?" Separate from whether that works for you or not, I'm in agreement that the issue DE brings up needs to be addressed. Either the script needs to recognize and respect cs1-dates parameters, or users need to be warned when they're using it erroneously. Even if the tag isn't present, moving away from an acceptable date style without discussion is misuse of the tool. I've likely made this mistake in the past, and I wouldn't have known about it without the last discussion. Firefangledfeathers (talk / contribs) 04:01, 13 July 2023 (UTC)

@Firefangledfeathers, maybe "convoluted" isn't the right word—I truly did appreciate your suggestion, and may try it in my next translation. (I have taken a bit of a break from translating but am hoping to start a new project soon!)

I find that learning new plug-ins/scripts for Wikipedia takes me a while, and always longer than I hope. I've never used the MOSNUM dates script, so maybe it would be easy to enact your suggestion. My issue, though, is that it's hard to disseminate that tip to translators (besides me). (And, we have an issue of well-cited content being translated... but refs being left out. So I highly encourage anything we can do to make the translation process easier.)

For English→Spanish translations, I prefer using Content Translation as it's an easy interface—I could look into using a sandbox as the source text. I can only speak from one perspective, that of an English/Spanish speaker. I don't know if there are other Wikipedias that use other date formats or have less support, in which this poses an even greater problem.

(also, as a correction to my previous comments, I think I was thinking of some of the other painfully tedious translation I've done, haha. I actually did not translate the refdates in my initial translation of es:Ice Spice, but a bot did it for me about 2 weeks later. I don't know if a bot like that exists on English Wikipedia, or other Wikipedias that translate from English Wikipedia.) Wracking ^talk! 21:22, 14 July 2023 (UTC)

@Wracking: I've only started using the script yesterday (and will stop until this is resolved), but it seems to me to be a problem with the Content Translation tool rather than this script. It's entirely reasonable, per MOS:DATEUNIFY, that all the dates be mdyfied or dmyfied uniformly, ref or no. The ISO date is, for a lack of a better word, ugly. It's a buncha numbers that you have to decipher in your mind. That's why the month is written out in full, for readability's sake. dmy and mdy are perfectly machine-readable, or the script wouldn't be able to operate on them in the first place. I don't think it's reasonable to condemn the script for doing its actual job, which is standardizing date formats across the article. What you need is a better translation tool (or a new feature therein), certainly not imposing an inconsistent style on all articles just for the sake of a hypothetical, one-time future translation effort. 〜 Festucalex • talk 11:04, 20 July 2023 (UTC)

@Wracking: In addition, you have another problem. The script isn't the only thing causing dmy and mdy formatting inside refs. Normal users are, too. Let me tell you, I have never, and I mean never, written the date and archive-date in YYYY-MM-DD before, ever. I usually write in mdy manually. So, even without the script, you still have your translation troubles. That's why I think it's not the script's fault, but the fault of your translation method. 〜 Festucalex • talk 11:12, 20 July 2023 (UTC)

I will support that. I have never used YYYY-MM-DD in creating or modifying a citation, but use mdy or dmy, as seems appropriate for the article. Donald Albury 17:39, 20 July 2023 (UTC)

@Festucalex, I understand MOS:DATEUNIFY. I (and others) think that editors should not be doing fly-by semi-automated edits that remove "ugly" (but MOS-accepted) formatting, when those edits serve no benefit to the reader.

It's fine that you don't use YYYY-MM-DD. I explicitly said that I'm not asking editors to change their behavior, besides that related to the script. I have no intentions related to imposing an inconsistent style on all articles. Wracking ^talk! 18:36, 20 July 2023 (UTC)

@Wracking: Would you, then, be fine with editors manually changing YYYY-MM-DD to mdy in reference templates? 〜 Festucalex • talk 18:41, 20 July 2023 (UTC)

@Festucalex, I’m talking about the script. Wracking ^talk! 03:14, 21 July 2023 (UTC)

• The mdy format is, for want of a better word, ugly, impractical and illogical. Beauty is in the eye of the beholder, but the reason mdy is accepted is not one of beauty or elegance, but of convention. It is a convention followed by a minority of readers of English Wikipedia, and respected for that reason.
• By contrast, yyyy-mm-dd is practical and logical, but such considerations carry no weight when it comes to date format. However, yyyy-mm-dd, just like mdy, is followed by a minority of readers of English Wikipedia, and should be respected for the same reason. As pointed out by Wracking (talk · contribs), it's unwise to remove stuff just because you find it ugly.

Dondervogel 2 (talk) 18:54, 20 July 2023 (UTC)

@Dondervogel 2: Rather than debate subjective aesthetics, I'll point out that YYYY-MM-DD never occurs in the body of an article, and thus could never fulfill MOS:DATEUNIFY. There's no reason to defend it so vehemently against a very useful script ("BAG, ANI, or firing squad"!), since its practicality is a matter of question. 〜 Festucalex • talk 19:01, 20 July 2023 (UTC)

You need to carefully read Wikipedia:Manual_of_Style/Dates_and_numbers#Consistency, especially the bullet on Access and archive dates. If an article's established citation format uses YYYY-MM-DD for access and archive dates, you must not change that unilaterally, even if this stupid script invites you to do so. The fact that this script has over and over tempted editors to do what they must not do, apparently without warning them about it, is the reason it needs to be either fixed (immediately) or trashed (immediately). EEng 19:42, 20 July 2023 (UTC)

An editor could avoid breaking the consistency rule by using the script, and also inspecting the cs1-dates parameter in the use xxx dates template and insuring the value is correct; in the scenario mentioned by EEng a parameter value of ly would be suitable. Jc3s5h (talk) 20:04, 20 July 2023 (UTC)

Incorrect. They could avoid breaking the consistency rule by NOT using the script on articles that are formatted in this way. The script is incapable of behaving correctly on articles with this formatting. It will always spell out the dates even when the article is tagged as using numeric access dates. And it is not always the case that articles in this format are tagged with the parameter stating that they are in this format. —David Eppstein (talk) 20:32, 20 July 2023 (UTC)

MOSNUM only applies to the rendered result, not the wikitext. Prove otherwise. Jc3s5h (talk) 23:30, 20 July 2023 (UTC)

Scripts that make only unseen changes to articles are generally forbidden, by WP:COSMETICBOT. —David Eppstein (talk) 23:57, 20 July 2023 (UTC)

WP:COSMETICBOT only applies to bots. The script is not a bot. Jc3s5h (talk) 13:55, 21 July 2023 (UTC)

COSMETICBOT also applies to bot-like editing from users, meaning (as I understand it) wide-ranging or rapid-fire changes done manually or with semi-automated tools. This would apply to users who use the script repeatedly and rapidly, but not, I think, to users who just run it on pages they're working on anyway. Even though I don't tend to use the script rapidly, I do still try and avoid making cosmetic-only edits while using it. I make a few copyedits rather than publish an edit that doesn't affect the rendered page. Firefangledfeathers (talk / contribs) 14:39, 21 July 2023 (UTC)

These are not unseen changes, though. GiantSnowman 07:19, 22 July 2023 (UTC)

To an extent, they are, and that was part of the earlier discussions. For example, here's one of your script-assisted edits that was purely cosmetic. FYI, I had to go back sixteen edits on this list to find it. Firefangledfeathers (talk / contribs) 01:00, 25 July 2023 (UTC)

I've stopped using the script because it disturbs a few users. That's unfortunate because although our guidelines specifically allow YYYY-MM-DD dates in citations, I think they cause more trouble than they solve. Also, though this script is annoying for some, it does a lot of good quickly (making an article use a consistent date format takes a lot of time). If I were king, I'd say all dates should be in YYYY-MM-DD format; there would be some distress but everyone would quickly figure it out (I'd go metric/SI too). Luckily I'm not king and we use a less logical, less beautiful, but perfectly adequate system of sometimes MDY and sometimes DMY, always with the month spelled out. Many people see 2023-07-20 as equaling 1996. They just can't figure out that the string of numbers in an unfamiliar format is a date. That applies to editors as well as readers. Seeing what some people see as computer code in the wikitext turns off potential editors. If there's to be an RfC, I'd vote to stop allowing YYYY-MM-DD.  SchreiberBike | ⌨  19:41, 20 July 2023 (UTC)

@SchreiberBike: I'd vote for that as well. Article-wide consistency, readability, and a convenient method for standardization are more important than an arbitrary carveout for that specific date format. 〜 Festucalex • talk 20:03, 20 July 2023 (UTC)

It is wrong to say that YYYY-MM-DD dates may be universally used for publication dates. Julian calendar publication dates must not be used in Citation Style 1 because doing so emits false metadata. When such a publication date is encountered, the entire citation should be written by hand, with no use of Citation Style 1. Whether all the citations in the article should be rewritten in an non-CS1 format, or if it is acceptable to hand-write a citation that imitates the output of CS1 is unclear. Jc3s5h (talk) 20:09, 20 July 2023 (UTC)

I agree with Scheiber. My worry is that many readers find YYYY-MM-DD confusing—especially whether the middle or final position is a month. Our readers can't be assumed to be experts. Tony (talk) 03:07, 21 July 2023 (UTC)

Readers do not see the YYYY-MM-DD text. For refs, it is translated into MDY or DMY format depending on the article. Wracking ^talk! 03:12, 21 July 2023 (UTC)

User:Wracking, technical question: why do I so often see US-related articles with the correct mdy in the article text, but dmy in the refs. It's plain weird. Tony (talk) 12:35, 21 July 2023 (UTC)

I have seen various formats but what questions me is if there's a history of this with MOSNUM, no one has made a fork that would fix it? I mean I still have issues with the built in citoid with grabbing titles (and the MOSNUM date choice not doing anything) and there's at least a documented page by BrownHairedGirl about it. – The Grid (talk) 14:29, 21 July 2023 (UTC)

Tony1, possibly because some users will remember to be consistent when writing the text, but then use the cite facility in the editing toolbar to automatically do the ref which has their personalised choice of date format, or because both were done incorrectly and someone corrected the text but didn’t notice the date. - SchroCat (talk) 09:46, 22 July 2023 (UTC)

SchroCat—Got any suggestions for fixing it? I'm not very technical. Tony (talk) 10:16, 22 July 2023 (UTC)

Tony1 Me neither! Ideally they should pick up on an existing “Use mdy dates” template present on the page, which would be preferable to the current set up, but I have no idea idea if that technically possible. - SchroCat (talk) 11:24, 22 July 2023 (UTC)

Wracking, readers do see YYYY-MM-DD text when the cs1-dates parameter is set for that format. Tony, I think the main culprit for dmy in US English articles is the RefToolbar, which automatically scrapes website for dates and defaults to DMY. If Template:Use MDY dates is present, these wikitext DMY dates display as MDY for readers. Firefangledfeathers (talk / contribs) 14:42, 21 July 2023 (UTC)

It's hardly satisfactory, the default. Tony (talk) 02:29, 22 July 2023 (UTC)

It is only 'translated' if the article as a DMY or MDY tag - which is what the script adds... GiantSnowman 07:20, 22 July 2023 (UTC)

Julian calendar publication dates must not be used in Citation Style 1 because doing so emits false metadata. Not true. The metadata for a Julian calendar date is truncated to year-only when |date= is written using either of the dmy or mdy formats. Writing a Julian calendar date in YYYY-MM-DD format is not supported in cs1|2 because MOS:DATEFORMAT; attempting to do so causes a Check date values error.

—Trappist the monk (talk) 13:23, 21 July 2023 (UTC)

At what point was somebody going to notify me about this discussion, given you (@EEng and David Eppstein:) are, respectfully, slagging me off and trying to impose some kind of ban on me? GiantSnowman 07:13, 22 July 2023 (UTC)

• We're not saying anything about you that you haven't heard us say 100 times: using this script you regularly mess up dates in articles, and won't stop. EEng 08:09, 22 July 2023 (UTC)

  and always respectfully Dondervogel 2 (talk) 08:36, 22 July 2023 (UTC)

  That is nonsense and you know it. GiantSnowman 08:58, 22 July 2023 (UTC)

  Humor impairment strikes again. EEng 09:05, 22 July 2023 (UTC)

  Actually, wait... what are you saying is nonsense? The always respectfully bit? The We're not saying anything about you that you haven't heard us say 100 times bit? Or the you regularly mess up dates in article bit? EEng 09:07, 22 July 2023 (UTC)

  All of it. GiantSnowman 09:10, 22 July 2023 (UTC)

  Then we're back to humor impairment strikes again. EEng 09:19, 22 July 2023 (UTC)

  Are the personal insults necessary or appropriate here? -- Pemilligan (talk) 11:38, 22 July 2023 (UTC)

Talking of notification, Ohconfucius has finally been alerted to the discussion (in another context). David Brooks (talk) 14:40, 22 July 2023 (UTC)

There may be some misunderstanding about how my script works in conjunction with MOSNUM so I'll try and discuss what my operating considerations are:

firstable, the script was and is intended to convert or unify formats throughout any given article. It still does the job pretty well, with very few false negatives or false positives. There is no reason not to use the script. The controversy seems more to be related to the political choice of editors.

According to strict interpretation of guidelines, once autoformatting began, there is no reason for any ref dates to be changed; users are to rely on parameters within the {{use xxx dates}} templates. By that same token, editors should use the parameters if they want ref dates to display in yyyy-mm-dd form.; the script ought to stop acting on dates within references. So although we have been ordered not to care any more about the underlying dates and focus on the rendered output, I have not modified the script to stop their conversion because I found to not do so sometimes gives rise to unsatisfactory results: especially where the references pre-exist without citation templates, in which case the automatic rendering ordered by the "use" templates fail. There is no solution to this in any event.

Secondly, most existing articles started life with either dmy or mdy dates; yyyy-mm-dd dates are a relative latecomer and few were inserted by human editors. To decide which format should prevail, we defer to WP:RETAIN in disputes. But precious few editors check what original format the "first major contributor" used.

We see some editors preferring yyyy-mm-dd ref dates increasingly up in arms, but there is no reason to be, for the reasons already stated above – we only care about the rendered output. Bearing the above in mind, I certainly don't see the need to rewrite the script so that it allows conversion of ref dates to yyyy-mm-dd form. All editors need to do is to confirm that the very first date is indeed in yyyy-mm-dd form, and then apply the parameter as in {{use xxx dates|ls}}. There should also be no more discussing "ugliness" of one date format over another, nor for chastising fellow editors for the inconsequential removal of yyyy-mm-dd dates lest forget the goal of having consistent date formats in any given article. -- Ohc ^{revolution of our times} 22:46, 24 July 2023 (UTC)

Ohconfucius, don't you think an edit like this one is troublesome? Prior to the script-assisted edit, the article had no Use XXX dates tag, but was fully consistent in its use of a MOS-accepted style. The script changed from one acceptable style to another, which we urge editors not to do without discussion. Firefangledfeathers (talk / contribs) 01:00, 25 July 2023 (UTC)

I think I've already said what needed to be said. It's a political editorial choice and my script is but a tool to that end. The only issue I have with the edit is that the editor neglected to add the |cs1-dates= parameter, and appeared to edit war over the format. The insertion of {{use mdy dates}} is useful and necessary, and correct application of the parameter at the outset may well have avoided the conflict. Although the script doesn't add the parameter, it doesn't overwrite it.  Ohc ^{revolution of our times} 18:29, 25 July 2023 (UTC)

Why do you keep saying things are "political"? What in the world are you talking about? EEng 19:09, 25 July 2023 (UTC)

I mean it's editorial choice based on interpretation of policies.  Ohc ^{revolution of our times} 19:20, 25 July 2023 (UTC)

Clarification (and/or change) requested re "Uncertain, incomplete, or approximate dates"

I'm unclear on how to handle this situation: we have a person who we definitely know was alive (and an adult or teen) in 1651, and was still alive in 1658 (a seven-year range), and that is all we know. I'm not sure how this should be handled in the parenthesized vital-dates at the beginning of the article:

1. Nanker Phelge (fl. 1651 – 1658) was...
2. Nanker Phelge (before 1651 – after 1658) was...
3. Nanker Phelge c. 1651 – c. 1658 was... [using {{circa}}]
4. Nanker Phelge (fl. 17th century) was...

Or something else? (FWIW this came up at Pasqua Rosée and the discussion started at Talk:Pasqua Rosée#Use of "fl." at opening is wrong I think?). And FWIW it looks like MOS:APPROXDATE recommends both #1 and #2 (and possibly #3, not sure) but not (I think) not #4), so I think we should consider clarifying this if possible? (For my part, whatever best serves the reader is what counts, everything else is mostly noise.) Herostratus (talk) 17:29, 16 July 2023 (UTC)

Herostratus, "fl." is used to denote when a person was considered active. exact dates can be used with "fl.", even when the subject's years of birth and death are not known with certainty, because floruit does not assert that the dates mentioned are actually the subject's years of birth and death.

"fl. x–y" effectively states that a subject was born on or before x, died on or after y, and was active between x and y inclusive, so option 1 actually says a bit more than option 2. also, option 2 asserts that phelge (or rosée) was alive in 1659, which may be an inappropriate assertion given that there are no known surviving records for rosée after 1658. (i don't know anything about phelge, though.) i think using option 3 would be misleading because it suggests that we know with some degree of certainty that the subject was born around 1651 and died around 1658. the use of specific years in option 3 also suggests that the actual years of birth and death are likely within a few years of the stated estimates, while we are (or, at least, i am) fairly certain that rosée was not a toddler when he began serving edwards his daily coffee. option 4 seems valid, but it asserts far less than option 1, so i am not sure why that option would be preferred.

by the way, "fl." does not normally take a spaced en dash if it is used with a simple year–year range, so technically, option 1 is formatted incorrectly. i can easily understand why the error was made, though, as the mos had actually contradicted itself on this point until 2021. i see nothing wrong with how the range is currently presented in the article on rosée. dying (talk) 18:46, 16 July 2023 (UTC)

In the interests of making consensus visible, I'd second everything said here. UndercoverClassicist (talk) 19:09, 16 July 2023 (UTC)

Alright, but assuming that we want to use WP:APPROXDATE with as few changes a possible, I mean at bullet point 3 it says

Where birth/death limits have been inferred from known dates of activity: [eg] Offa of Mercia (before 734 – 26 July 796)..."

but then right below it at bullet point 4 it says

When birth and death dates are unknown, but the person is known to have been active ("flourishing") during certain years, fl., fl., or fl. may be used, [eg] Jacobus Flori (fl. 1571–1588)

Seems confusing... first it says use "before (and/or after)" then it says to use "fl". The only difference between the two, that I can see, based on the examples, is that the first (before and/or after) is used when the span of years is considerable -- enough to possibly cover the lifespan of an accomplished person (the example shown covers 66 years, and the other examples are similar), while the second (fl.) covers 17 years, which would usually not be the full lifespan of an accomplished person (and the other examples are similar). But it could be, and might well be if the person is notable for being a royal heir, say (and the article in question, Pasqua Rosée has "(fl. 1651–1658)" which is just 8 years).

So, is that the difference? "Before and/or after" is used for long spans, and "fl." is used for short spans? If not, what are the circumstances that leads one to chose one over the other? Should we not explicitly give them, or if there are not any, say "use either, depending on your inclination, but stay consistent within articles"? Or else just erase one of the proscriptions, either "Before and/or after" or "fl."?

User:Dying (and User:UndercoverClassicist, you say

"'fl." is used to denote when a person was considered active. exact dates can be used with "fl.", even when the subject's years of birth and death are not known with certainty, because floruit does not assert that the dates mentioned are actually the subject's years of birth and death...."fl. x–y" effectively states that a subject was born on or before x, died on or after y, and was active between x and y inclusive

Well but that's didactic and how is the editor to know this?. Maybe you've been to school and learned it there, but I haven't, and hella other editors haven't either. Herostratus (talk) 19:03, 24 July 2023 (UTC)

It's not a matter of the length of the span; it's about what's known and what impression we want to give the reader about it (or avoid giving). For Offa, we have a date of death and we know something about when he was born. For Florii and Rosée, we know some dates in their lives but those dates don't indicate when they were born or died. It would be technically true to say they were born before the first known dates and died after the last, but also banal and even potentially misleading, as many readers who saw "before YYYY" might think we wished to imply that was a good indicator of when they were born. That's when we use fl. with the years we do know.

TL:DR: first apply test #3: are meaningful limits for birth or death dates inferrable? If not, proceed to #4: do we know when they were active? For Nanker Phelge, #3 = definitely not and #4 = yes, so fl. 1963–1965. NebY (talk) 19:22, 25 July 2023 (UTC)

Alright. But how is a person supposed to know this -- editor person or reader person? I would think that some simulacrum of what you wrote above should go into the instructions? But for one thing it the differences seem subtle, and, remember, every time we burden an editor with extra text, God kills a kitten. And then, what about the poor reader, how is she going to know what is meant?

Maybe some other people have some worthwhile points and ideas, and/or you have more cogent commentary. So its worthwhile to keep this section up maybe, but simultaneously I'm going to open a subthread (below) about a different approach to the problem. — Preceding unsigned comment added by Herostratus (talk • contribs)

The larger picture

Executive summary: The best answer is "Nanker Phelge (lived 17th century) was..". None of the above!

---

Ok, so a main purpose of rules and suggestions is to serve the reader. It's not the only purpose, but it's important. So, to refresh, the question is how best to serve the reader in this case.

So, for me, I don't care much about what what professors of history write out of ancient habit going back to the Romans I guess. I do care about puzzling or annoying the reader. Things outré, like if we decided to call all thespians "actrons" would do that. But getting rid of "fl." would not, except maybe some snobs.

I"fl."... what does that even mean? I'm a high school dropout farmworker in Winterset. I'm an ESL dockworker in Wroclaw. A policeman in Ikot Ekpene, a 7th grade student in Schooner Gulch, a restaurant owner in Molenbeek, a division manager at Exxon-Mobile (After all, a whole honken lot educated folks don't read anything much but novels or news or technical materials in their specialty.)

Sure, a whole lot of our readers have been graduated from private universities, or are widely read, or are just quick to pick up things, and so on. And yes, we can't much accommodate ESL or illiterate or unread folks at the cost of accommodating our main readership.

So, hella people don't know what "fl." means. Does using "flourished" instead disaccommodate people who do? I'm not seeing it. ("Floruit" is straight out, we don't require our readers to know Latin.)

(And then, the primary meaning of "flourished" is "thrived". But some of our subjects didn't thrive. Domna Anisimova (td. 19th century) was blind, illiterate, and lived in an obscure village in the backwaters of Imperial Russia. Maybe she didn't flourish. "Flourished" is an OK word but a little fancy in this context, and a little off. What's wrong with "lived"? "Nanker Phelge (lived 17th century)"... it doesn't grate, it's really easy to understand. Is it so horrible. Is it not the best way to serve the reader.

OK. So, on the dates thing. Vital statistics are traditional to give, and important to people, and we give them. "Notary Sojac (April 17, 1933 - November 12, 1989)". Lot of times we just give the year, and put the actual day in the body text, and birth and death. I usually do, cos it places the person in temporal context, which the actual dates are noise to most people. I think there's a rule somewhere about that, don't know or care.

But for Phelge, 1651 and 1658 aren't part of his vital statistics. They're not the date (or even year) and place of birth and death place. The United Nations defines vital statistics as "vital events (live births, deaths, fetal deaths, marriages, and divorces)". Nothing about "first time mentioned in somebody's diary or whatever, that we know of."

1651 and 1658 are just dates when he signed an invoice and when he got a writeup in the local paper, or whatever. The belong at the very top of the article, yes. Not right after the name.

"Lived 17th century" puts the person in context, it a good start for understanding the subject. Rando dates when he wrote a letter to his brother or whatever don't do much for that. The reader has to figure out what the numbers mean and convert that to the subjects era. Why make the reader do extra work. Herostratus (talk) 22:53, 26 July 2023 (UTC)

Herostratus, have you read our article on "floruit" yet? dying (talk) 00:34, 27 July 2023 (UTC)

As Floruit says, "active" is an alternative, that is easier to understand. Putting "Lived 17th century" is a sure way to attract tags etc, and not helpful to the reader. What does "Lived 20th century" tell you? Kurt Cobain, or someone killed in WWI. You asked the question, & were given the answer. Don't whine, or at least not at such length. Johnbod (talk) 01:08, 27 July 2023 (UTC)

See current discussion on clarifying or abolishing centuries at Wikipedia:Village pump (policy)#Without looking it up, what year and day were the ends of the 6th century BC?. But remember every time we burden an editor our fellow editors with extra text long diatribes and unrealistic proposals, God kills a kitten all the kittens. NebY (talk) 10:11, 27 July 2023 (UTC)

b2k dates

Over at Megalonyx there has been a dispute between me and another user regarding the use of Before Present or b2k dates. The other user is asserting that since b2k is preferred by the International Commission on Stratigraphy, it should be preferred by Wikipedia too. However, as far as I can tell, BP remains a much more common dating system in scientific literature. I tried searching and cannot find any other examples of b2k dates being used on Wikipedia. Hemiauchenia (talk) 14:14, 29 July 2023 (UTC)

b2k seems more transparent than BP, especially for lay readers, but we should at least have a linkable article on it if we're going to use it. Yes, we would want to be confident that it's won formal acceptance and become broadly at least as common as BP in new scientific literature; is there any prospect of the IUGS, the parent body of the ICS, approving it soon? Perhaps more trivially, I'm confused by "11,235 BP, which corresponds to 11,255 B2K" in this edit comment; is there not a 50-year difference between BP (1950) and b2k (2000)? NebY (talk) 14:57, 29 July 2023 (UTC)

I'll guess that the confusion arises from the assumption (which I've been making) that BP dates meant before today's date, not knowing that standard practice is to use 1 January 1950 (as stated at Before Present). How many casual readers actually know that? -- Pemilligan (talk) 15:23, 29 July 2023 (UTC)

To be honest, for the dates that BP is appropriate to user over BC (generally 10,000 years ago or greater in my opinion), 50 years is a relatively insignificant amount of time to the point that it doesn't really matter, and the confidence interval for such dates are often in the hundreds of years anyway. Hemiauchenia (talk) 15:45, 29 July 2023 (UTC)

Many more casual readers will know that than have any idea what a "b2k" date is! Many are still thrown by BCE, especially outside North America. The world isn't ready for this, no matter what the International Commission on Stratigraphy say. He should come back in 20 years. Johnbod (talk) 17:49, 29 July 2023 (UTC)

Or at least when search results for "b2k dating" are less about Lil Fizz and Omarion. NebY (talk) 18:14, 29 July 2023 (UTC)

Well, in the interim, someone who cares and who has good journal access should write up a WP article b2k dates.  — SMcCandlish ☏ ¢ 😼  18:36, 29 July 2023 (UTC)

what is narrow gap?

the page contains the word narrow gap, and {{val}} and {{gaps}} for it. what character or construct does it produce in the final html? ThurnerRupert (talk) 06:46, 1 August 2023 (UTC)

As mentioned at Template talk:Convert, {{convert|1234567|m|ft|comma=gaps}} shows gaps that do not copy. That is done with CSS and the grisly details can be seen by pasting the example convert into Special:ExpandTemplates. Johnuniq (talk) 07:38, 1 August 2023 (UTC)

12- or 24-hour time for military history articles?

User:Iseult has started an RfC at Wikipedia talk:WikiProject Military history#RfC: Use of 12 or 24-hour time. Please discuss there. Jc3s5h (talk) 23:00, 7 August 2023 (UTC)

Fractions in category names

MOS:FRAC says we shouldn't use the character ⅞ for seven eights because it doesn't work with many screen readers. However, it appears in category names like Category:4 ft 10⅞ in gauge railways, where we can't use templates like {{frac}}. What is the preferred resolution?

• Continue to use the character in category names, but follow the existing guideline (e.g. {{frac}}) for article text
• Continue to use the character in category names, and the same character in article text, for consistency
• Use ASCII representation in category names (like "Category:4 ft 10 7/8 in gauge railway")
• Something else

Thanks! -- Beland (talk) 01:55, 10 August 2023 (UTC)

There have been previous discussions, going back many years. For example, Wikipedia talk:WikiProject Trains/Archive: 2010, 2#Narrow gauge categories, Talk:List of track gauges/Archive 1 and most of the archives of Template talk:Track gauge. And elsewhere. --Redrose64 🌹 (talk) 21:40, 11 August 2023 (UTC)

@Redrose64: I skimmed through those discussions, and I don't see anything relevant to the question of {{frac}} vs. Unicode precomposed fractions in category names. There is some controversy over metric vs. US system...are you saying that some categories that are currently using fractional inches lack consensus to do so and we could at least partly solve this problem by converting to metric? -- Beland (talk) 19:48, 12 August 2023 (UTC)

I've left notes at a bunch of relevant talk pages directing people here. --Redrose64 🌹 (talk) 20:48, 12 August 2023 (UTC)

@Beland: See Wikipedia:Categories for discussion/Log/2021 March 3#Category:10¼ in gauge railways in England. --Redrose64 🌹 (talk) 00:00, 13 August 2023 (UTC)

@Redrose64: Yes, MOS:FRAC reflects the result of that, in the sense we've decided ½, ¼, and ¾ are OK in article text and category names. But there's still a conflict for the five category names containing ⅜, ⅝, and ⅞, and depending how that conflict is resolved, I also need to know how to handle the article text for articles in those categories. -- Beland (talk) 00:35, 13 August 2023 (UTC)

Reading over MOS:FRAC I think the only two gauges that pose a problem are Category:4 ft 10⅞ in gauge railways and Category:12⅝ in gauge railways. The former could be renamed Category:Toronto-gauge railways; the latter is a category of one and probably doesn't need to exist. Mackensen (talk) 21:01, 12 August 2023 (UTC)

There are lots of small categories in category:Miniature railways by size but it seems to be a comprehensive scheme, so rather than delete one entry of the set and rename another to be completely different to its peers it would be much better to evaluate the scheme as a whole. Thryduulf (talk) 22:46, 12 August 2023 (UTC)

Thank you, I wasn't aware of those. 7 1/4 in gauge railway may suggest a way forward. Mackensen (talk) 23:18, 12 August 2023 (UTC)

But is it "7 1/4" or "7-1/4"? There are two common ways of writing out fractions like this, and MOSNUM doesn't address this at all because it recommends the fraction template instead.  — SMcCandlish ☏ ¢ 😼  23:41, 12 August 2023 (UTC)

I feel like the spaced version is somewhat more common, so I'd lean toward that if the context is non-numeric. I worry the "-" could be confused with a subtraction operator, though it does neatly group things. -- Beland (talk) 00:49, 13 August 2023 (UTC)

A very rough scan of the last English Wikipedia database dump shows non-compliance instances favor "1 1/2" over "1-1/2" by about a 2:1 ratio, so I'll try that direction. -- Beland (talk) 01:35, 15 August 2023 (UTC)

1 1/2 is incomprehensible to sighted readers,

1-1/2(=1) is , even worse. Can screenreaders handle {{sfrac}}? So 1.5 is rendered as 1⁠1/2⁠, 10.875 as 10⁠7/8⁠ 𝕁𝕄𝔽 (talk) 16:36, 15 August 2023 (UTC)

I don't know whether screenreaders can handle {{sfrac}} but category names cannot so the question isn't relevant. Thryduulf (talk) 17:24, 15 August 2023 (UTC)

There is a specific mention of rail gauges in MOS:FRAC - Do not use precomposed fraction characters such as ½ (deprecated markup: ½ or ½).[j]

Except: If ¼, ½, and ¾[k] are the only fractions needed, they may be used in an article body, or category name, maintaining typographical consistency within an article where possible. (Examples: Floppy disk, Ranma ½, chess notation, Category:4 ft 6½ in gauge railways‎.).

The only change we need to make is to allow the use of any other relevant fractions. Mjroots (talk) 04:04, 14 August 2023 (UTC)

@Mjroots: The other fractions aren't allowed because they cause accessibility problems, so presumably allowing them would mean leaving the category names partly inaccessible. Is the ASCII representation of fractions acceptable to you, given screen readers should be able to handle it? -- Beland (talk) 07:04, 14 August 2023 (UTC)

If the use of fractions such as ⅞ causes accessibility problems, the answer is a technical fix to solve the accessibility problems. If screen readers can read ASCII representation of fractions, that is acceptable. Mjroots (talk) 07:20, 14 August 2023 (UTC)

@Mjroots: A technical fix for all screenreaders would be broadly welcomed, but given that third-party software is out of our control and may take years to improve. Mine at least works with the ASCII representation, so I'll try that. -- Beland (talk) 01:35, 15 August 2023 (UTC)

For those screenreaders that don't cope with precomposed fraction characters, what do they do instead (silence where the unknown character is? read out the character code? error? silence for the whole string?) and are the categories still accessible (i.e. can someone using a screenreader access the category page for e.g. Category:4 ft 10⅞ in gauge railways? If it's clear that it's just a single character that the reader doesn't know, and the category can still be accessed, I think a workaround of requiring the category to have a compliant description would be an acceptable tradeoff for what is a very rare scenario to be encountered. If the screen readers just ignore the existence of categories with an unknown character in them then that's a very different scenario. Thryduulf (talk) 14:48, 15 August 2023 (UTC)

I would imagine that screenreaders won't be silent for the whole string, but just for the unrecognised character. Graham87 is the expert for this. --Redrose64 🌹 (talk) 16:13, 15 August 2023 (UTC)

Indeed, they're just silent for the unrecognised character or read it like a question mark. Graham87 17:10, 15 August 2023 (UTC)

Screen reader capabilities may have moved on since the guidance in MOS:FRAC was written.

I just tried using NVDA (one of the most popular screen readers) to read the title of this category, and it read ⅞ successfully (the "in" in the title seemed the more problematic part, as it gets read as "in" instead of "inch").

Template:track gauge renders something that looks (via CSS) like "4 ft 10⅞", but which is actually the string "4 ft 10+7⁄8", the latter part of which gets read by NVDA as "seven divided by eight". So, at least NVDA users may be better served by using the precomposed unicode character ⅞.

It would be helpful if a user of a modern version of JAWS could test to see if that also now understands ⅞. Barnards.tar.gz (talk) 13:50, 21 August 2023 (UTC)

Kelvins

@Dondervogel 2: Kelvin#Orthography now has several sources documenting the preference for "kelvins" in plural contexts like "four kelvins". Is it OK to revert this revert now? -- Beland (talk) 18:31, 21 August 2023 (UTC)

To be honest, "four kelvin" sounds more natural to me than "four kelvins", but that's a poor reason on its own to object to NIST or CERN guidance. I suggest first seeking the views of others. If there are no objections after 3 days to "four kelvins", I would not object either. Dondervogel 2 (talk) 21:19, 21 August 2023 (UTC)

Just guessing, but this might have to do with temperature vs temperature difference: "Hydrogen boils at 23 kelvin" vs "Over the next minute the temperature increased 42 kelvins". To repeat: just guessing. EEng 21:44, 21 August 2023 (UTC)

That's not how NIST approaches it; instead, they have For example, “mercury loses all electrical resistance at a temperature of 4.2 kelvins.”[12] I guess it may seem odd because we often skip the "degrees" from "degrees Celsius" or "degrees Fahrenheit" and talk of 68 Fahrenheit not 68 Fahrenheits; or because until 1967 the SI term was "degrees kelvin"; or because we so very rarely do talk of temperature in kelvins at all. NebY (talk) 22:10, 21 August 2023 (UTC)

I guess it's a good thing I kept repeating that I was just guessing. Also, I was just guessing. EEng 23:55, 21 August 2023 (UTC)

Dates in citations

I was recently pointed to MOS:NUM in an edit which only changed all ISO8601 dates in citations to plain text. However I didn't see anything of the sort on this page... Is there a reason for such changes? IMO we should put ISO8601 in citations as the templates auto-convert them to the appropriate format specified by one of the "use" templates which makes it easier if the article is ever put under a different date format. Aaron Liu (talk) 20:57, 22 August 2023 (UTC)

Some publication dates are in the Julian calendar. According to Wikipedia:Manual of Style/Dates and numbers, for the YYYY‐MM‐DD format,

Use yyyy-mm-dd format only with Gregorian dates from 1583 onward.

Jc3s5h (talk) 22:15, 22 August 2023 (UTC)

Sure, but none of the dates in that article were before 1583. Aaron Liu (talk) 22:18, 22 August 2023 (UTC)

Do you promise to never edit an article which cites material published before 1 March 1923, or which cites anything published by an Orthodox church, or publisher affiliated with an Orthodox church? Jc3s5h (talk) 22:39, 22 August 2023 (UTC)

And dost thou renounce Satan? and all his works? and all his pomps? (But not his pumps -- see File:Satan In High Heels - 1962 - Poster.jpg.) EEng 22:55, 22 August 2023 (UTC)

What? Sorry, I've lost you. What does this have to do with 1923 or the Orthodox? What do articles that can't use ISO8601 in infoboxes (which is where you might use mdy exposed) have to do with citation templates which have their dates auto-converted to the suitable general use format? Aaron Liu (talk) 22:53, 22 August 2023 (UTC)

You said you want to use ISO 8601 dates. ISO 8601 requires that dates be in the Gregorian calendar. If you use ISO 8601 format but it's really a Julian calendar date, it's a lie. Also, some branches of the Orthodox churches still use the Julian calendar. The Greek government didn't switch from Julian to Gregorian until 1923. Jc3s5h (talk) 23:39, 22 August 2023 (UTC)

It's preferred but nothing's going to go wrong if you use an old style date. It's not like the article's going to automatically convert the date as if it was Gregorian. How would it be a lie? Aaron Liu (talk) 23:45, 22 August 2023 (UTC)

If somebody removes the use xxx template it becomes a clear lie. Jc3s5h (talk) 23:57, 22 August 2023 (UTC)

44-03-15 BC is exactly the same as 15 March 44 BC. How is it a "clear lie"? Aaron Liu (talk) 00:00, 23 August 2023 (UTC)

"44-03-15 BC" is nonsense and doesn't mean anything. If 15 March 44 BC is a Julian proleptic calendar date, then in ISO 8601 it would be written −0043‐03‐13, which is in the Gregorian proleptic calendar. Also, it would be contrary to the guidance in WP:MOSNUM to use "−0043‐03‐13" in a Wikipedia article because that format is not to be used for dates before 1583. Jc3s5h (talk) 00:13, 23 August 2023 (UTC)

Just put proper English-language dates in there and stop looking for "magical" shortcuts that are apt to cause more trouble than they prevent. I've been replacing ISO dates in citations with ones that match the DMY or MDY standard of the article, for years, and no one has ever reverted me. It's clearly the preferential thing to do. The fact that some templates are making attempts at date auto-formatting doesn't mean we have to trust them, especially when we already know the have failure points and what some of those are (not to mention there was a huge fight across the project over a decade ago, that concluded against auto-processing of dates anyway).  — SMcCandlish ☏ ¢ 😼  00:46, 23 August 2023 (UTC)

Since this discussion is nominally about cs1|2 (the only citation templates that I know of that auto-convert [dates] to the appropriate format specified by one of the "use" templates), can you give examples that show these failure points you mention? If cs1|2 is broken, it should be fixed, but I'm not aware of any conversion failures.

—Trappist the monk (talk) 01:04, 23 August 2023 (UTC)

In England, Ireland, Wales, and the 13 colonies of the UK in America, 29 February 1699 was a leap day. Presumably newspapers were published bearing that date. A historian would ignore the fact that those territories observed March 25 as new year's day, and write the date 29 February 1700. Citation templates emit a message for 29 February 1700, "Check date values in: |date" and will not reformat the date. Jc3s5h (talk) 01:18, 23 August 2023 (UTC)

I'm not sure why 1699 would be a leap year; I could not find anything online either. Aaron Liu (talk) 02:07, 23 August 2023 (UTC)

The rule for Julian calendar leap years is a year is a leap year if it is evenly divisible by 4. Since 1700 is evenly divisible by 4, it is a leap year. However, that rule only applies if we treat 1 January as new year's day. Until 1753 in England, Ireland, Wales, and the 13 colonies of the UK in America, new year's day was March 25. So on the leap day in question, the year hadn't changed yet, it was still 1699. This can be seen on a page of the London Gazette. Jc3s5h (talk) 03:32, 23 August 2023 (UTC)

Huh. 1700 shouldn’t be a leap year as it isn’t divisible by 400 (which is also a rule for years divisible by 100). I get the point though as similar things might happen in 1999 and three that newspaper does say 29. Aaron Liu (talk) 12:29, 23 August 2023 (UTC)

In the Julian calendar, for a calendar where new year's day is 1 January, every AD year divisible by 4 is a leap year. Period. The rule that years divisible by 100 are not leap years, unless they are also divisible by 400, is the difference between the Julian and Gregorian calendars.

By 1999, all the countries I'm aware of started the year on 1 January. So nobody I know of observed 29 February 1999. Jc3s5h (talk) 13:05, 23 August 2023 (UTC)

Ah, I confused the two calendars. Thanks for clarifying. Aaron Liu (talk) 13:12, 23 August 2023 (UTC)

And just see the above discussion, Trappist. If the article doesn't have one of the "Use [whatever] dates" templates, or it gets removed, but someone has inserted ISO dates (as some editors really, really habitually do), the conversion fails and they remain in ISO format in the reader-facing text.  — SMcCandlish ☏ ¢ 😼  01:46, 23 August 2023 (UTC)

It's just the default format for both ProveIt and TemplateWizard. I don't see why we should worry about such templates getting removed, can't we just add a template back to fix it? Aaron Liu (talk) 02:03, 23 August 2023 (UTC)

It has always been true that templates and modules cannot change wikitext. To do that requires a human editor or a bot. So, Module:Citation/CS1 can only reformat dates for presentation when a {{use xxx dates}} template is present in the wikitext to tell the module which date format(s) to present for the templates that it renders. In the absence of a {{use dmy dates}} template in the wikitext, the module cannot know that you want all YYYY-MM-DD dates to be rendered in dmy format. There are scripts out there that routinely modify wikitext according to the presence of a {{use xxx dates}} template – the one I'm thinking about is flawed in that it ignores the {{use xxx dates}} |cs1-dates= parameter.

If any date in a cs1|2 template is invalid, none of the dates in the template are reformatted because the module only knows that the input format is invalid so can't know how to reformat the date into a valid date and format.

Module:Citation/CS1 does not distinguish between calendars except for the detection of leap days (29 February) in years evenly divisible by 100 – 29 February 1500 (Julian calendar; valid cs1|2 date) is a leap day but 29 February 1700 (Gregorian calendar; invalid cs1|2 date) is not a leap day. The module does not know about geographical variation in the determinations of leap years, does not know about 25 March as the start of the new year. No doubt there are other calenrical calendrical peculiarities that the module does not know about.

The module is not intended to know all there is to know about calendars because the templates are general purpose templates which are designed to be sufficient for most citation needs. If you need to cite the 29 February 1699 London Gazette issue, you would be better served to hand-craft the citation for that special case.

—Trappist the monk (talk) 15:36, 23 August 2023 (UTC) Fix spelling 16:00, 23 August 2023 (UTC)

Calenrical isn't a word but I feel like it ought to be. EEng 15:51, 23 August 2023 (UTC)

• Reingold, Edward M.; Dershowitz, Nachum (2018). Calendrical Calculations: The Ultimate Edition (4th ed.). Cambridge University Press. ISBN 978-1-107-68316-7.

Jc3s5h (talk) 16:14, 23 August 2023 (UTC)

Unit conversion missing some stuff

Our section on unit conversion says to do it when there's a dialectal split, but mentions nothing about converting units that are likely to be unfamiliar to the average reader (cubits, ells, etc.), which we routinely do. When conversion is done, we would want it to be done consistently, following the general MoS principle to be consistent within the same article, but the section does not actually say that and it probably should. I.e., we don't want someone to do a conversion at the first mention of a unit then never do another conversion in the article.  — SMcCandlish ☏ ¢ 😼  19:01, 29 July 2023 (UTC)

Sometimes it may be sufficient to give a conversion only the first time a unit is mentioned, so the reader will have a general idea of the magnitude of the unit. It really depends on the subject matter. Jc3s5h (talk) 19:27, 29 July 2023 (UTC)

MoS does not require such absolute consistency - see MOS:OLINK or our guidance on dates, with examples such as She fell ill on 25 June 2005 and died on 28 June. Repeated conversions can make an article less readable, so we do say In some topic areas (for example maritime subjects where nautical miles are the primary units, or American football where yards are primary) it can be excessive to provide a conversion for every quantity. In such cases consider noting that the article will use a particular unit – possibly giving the conversion factor to other, familiar units in a parenthetical note or a footnote – and link the first occurrence of each unit but not give a conversion every time it occurs. Applying this principle may require editorial discretion; for example, in scientific articles the expected level of reader sophistication should be taken into account. NebY (talk) 19:46, 29 July 2023 (UTC)

Well, it should still address conversion of units unfamiliar to most readers like cubits and ells, which don't have anything to do with ENGVAR stuff.  — SMcCandlish ☏ ¢ 😼  01:23, 1 August 2023 (UTC)

Converting cubits and ells is a problem, as the length of each is dependent on the country and era being referenced, and even then can be fuzzy. I have encountered a similar problem in working on articles whose sources give distances in leagues; I just link to League (unit) and leave it at that. Donald Albury 18:50, 1 August 2023 (UTC)

To be clear, I thought is pretty obvious that I mean convert them when the particular version of the unit is actually known (e.g. the Scottish ell being used in a particular source, etc.). It is not actually possible to convert from an unknown to a known unit, after all, so your objection doesn't make much sense except in the unusual case that the source used the unit without defining which version was meant.  — SMcCandlish ☏ ¢ 😼  14:14, 8 August 2023 (UTC)

Maybe I don't understand what you are proposing, but it seems to me that the proper place to propose adding a Scottish ell (~equivalent to an English 37 inch ell) and, perhaps, English ells of 40 and 45 inches, to the list of units for the conversion template would be at Template talk:Convert. Donald Albury 14:47, 8 August 2023 (UTC)

I'm not sure how I can be clearer that what I'm proposing is that our MoS section on unit conversion say to also convert units that are likely to be unfamiliar to readers, such as ells and cubits. If you want to tack on a redundant "when the unit is known for certain" or whatever, then okay, but I think someone else would remove that as unnecessary later.  — SMcCandlish ☏ ¢ 😼  14:53, 8 August 2023 (UTC)

Good catch. I've been doing a lot of conversions (recently a lot of Fahrenheit and furlongs) and use this section a lot, and I hadn't even noticed this directive was not made explicit. I support adding something that encourages conversions of each mention of unfamiliar units, except where this would become excessive. We already assume Americans have learned the metric system in science class, and don't do conversions in science articles, so I think it would be fine to only require conversion to SI units. Converting to both SI and American customary would make the conversions take up twice as much space as the original measurement, and starts to be a bit much in running prose. I don't object to a dual conversion on initial mention of an unusual unit, for editors who want to do that, but personally when I'm running around adding conversions as long as there are metric units I consider my job done. Maybe something like the below?

• For units of measure that are obsolete, obscure, or otherwise not part of the SI or US customary systems (e.g. furlong, zlotnik), supply a parenthetical conversion into at least SI units. Convert each mention, unless this would be excessive given the context. Take care to distinguish between different definitions of the same unit if it has changed over time or differs geographical (e.g. cubit, batman). An approximate or range conversion is acceptable if the exact historical value is uncertain (e.g. stadion).

-- Beland (talk) 02:30, 10 August 2023 (UTC)

A furlong is a US customary unit. Hawkeye7 (discuss) 03:06, 10 August 2023 (UTC)

And in South Asia, unlike the US & UK, it is not essentially confined to horse racing, but still a common unit when eg giving street directions. Johnbod (talk) 14:17, 10 August 2023 (UTC)

Yes, furlongs are part of the American system, but for Americans, they are obscure, and the text above intentionally encompasses both. Furlongs are not taught in school, and if you stop people on the street, I'm sure over 95% of people will not be able to tell you how long one is. The existing MOS:UNITS says primary units in South Asia are metric, so they would already need to be converted if used in articles about that region. Would it help to say "obscure from an global perspective" instead of just "obscure"? It's not particularly helpful to have unconverted units that are only familiar to people in a specific geography. -- Beland (talk) 16:38, 10 August 2023 (UTC)

99.9%. EEng 21:41, 10 August 2023 (UTC)

@SMcCandlish: Now, I understand. Sorry for my confusion, I was looking at the whole thing wrong. - Donald Albury 16:59, 10 August 2023 (UTC)

Well, I tweaked the text to respond to the above points and added it to the project page. -- Beland (talk) 20:14, 24 August 2023 (UTC)

Currency codes, symbols, and abbreviations: a possible answer in simplification?

Abandoned proposal by blocked editor
The following discussion has been closed. Please do not modify it.
While checking the manuals of style of a number of publications for intel on a different issue I noticed that most style guides recommend using signs for very familiar currencies the reader is likely to understand on first glance (usually €, $, ¥, and £, sometimes also SFr) and use the figure followed by the currency name for all others: for example 1 million tenge instead of such things as KZT 1 million or ₸1 million. Wikipedia however seems to have a very heavy reliance on ISO codes, signs, and abbreviations for currencies when writing prose. To the ordinary reader "KZT" and "₸" are unlikely to be immediately recognizable. Using 1 million Kazakh tenge and 1 million tenge thereafter makes much more sense, to me at least. We are writing for a general audience, not for experts in numismatics or economics. This really is not my field of expertise, so I am not talking about infoboxes or graphs and so on; just prose text for the time being. My proposal is basically this; when writing prose use a sign (not a code or abbreviation) for the most well known currencies and use words (not codes, signs, or abbreviations) for less familiar ones, especially those ones which may share a sign with the most established ones: Well known currencies: For amounts in US dollars: $1 million, not 1 million USD For amounts in euros: €1 million, not 1 million EUR For amounts in pounds sterling: £1 million, not 1 million GBP For amounts in yen: ¥1 million, not 1 million JPY Examples of type for less familiar currencies: For amounts in Emirati dirhams: 1 million Emirati dirhams, not Dhs 1 million or 1 million AED For amounts in Thai baht: 1 million Thai baht, not ฿1 million or 1 million THB For amounts in renminbi yuan: 1 million yuan, not ¥1 million, 1 million RMB, or 1 million CNY For amounts in Jamaican dollars: 1 million Jamaican dollars, not J$1 million or 1 million JMD For amounts in Egyptian pounds: 1 million Egyptian pounds, not £1 million or 1 million EGP It is not a topic I feel particularly qualified to act upon immediately, it isn't a strong interest of mine; just something I feel may be a bit confusing to the reader and was certainly confusing to me, so I would like to see what others have to say before doing anything. 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 19:57, 19 August 2023 (UTC) One of the things we have in Wikipedia that those other style guides generally do not is the ability to link to articles about the currencies. I think it is fine to use the proper symbol for a currency, as long as we link to the article for that symbol. Donald Albury 20:38, 19 August 2023 (UTC) That is true, but I am still thinking in terms of the reader: seeing something like, say, "100 GEL" instead of "100 Georgian lari" is jarring, especially if one is just perusing a specific article and doesn't have time or doesn't want to check all the linked articles. Chances are better than not that an English-speaking reader will readily identify $, €, £, and ¥ but will have trouble if non-word codes or symbols are used for more obscure currency units. 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 20:57, 19 August 2023 (UTC) I would also like to add that many editors forget (or may not know) that only Registered Users (a very small percentage of all readers) can see an explanatory pop-up when they mouse-over a Blue link. So an outside reader would have to actually open up the blue link (and learn all about the Japanese yen or Chinese yuan) instead of continuing to read the article he or she had been reading. ¶ Incidentally, clicking $ opens Dollar sign rather than any dollar or the United States dollar. Clicking £ leads to Pound sign and not the Pound sterling. Clicking € leads to Euro sign and not the Euro. @Stolitz:—— Shakescene (talk) 00:04, 24 August 2023 (UTC) This is why to do "US$", etc., at first occurrence (in a context in which it's not already entirely clear what currency is meant).  — SMcCandlish ☏ ¢ 😼  17:42, 24 August 2023 (UTC) For some articles, this wouldn't be suitable. If a currency is the main currency in that article (eg one concerning the UAE, Thailand, China etc) and appears often in it, the reader won't want to keep reading the currency name in full. Many of our articles are now about local areas or matters that are primarily of interest to the people of one country; constantly spelling out currency names in full would be like always converting American football dimensions to metric. If many currencies appear in a table, usually each row will specify the country and the reader will assume any unfamiliar symbol or code is for that country's currency; restating Emirati, Thai etc would clutter the table and make it wider. Perhaps that does leave some articles where it would be helpful if the first use showed country and currency name in full, maybe along with the symbol so that the symbol could be used subsequently. Can you give us some examples? NebY (talk) 21:25, 19 August 2023 (UTC) I was specifically talking about prose, not tables or infoboxes and such. A good example is TSD09, where "¥x RMB" is used constantly for the renminbi yuan: In February 2002, a contract between the railway company and Tangshan locomotive for cooperation was signed, for the delivery of two 5-car DMU by the end of 2003 for a total contractual value of ¥98,800,000 RMB. According to the contract, ¥40,000,000 RMB was paid upfront, while the entire process of the development would occur under the guidance of the ministry. Not once was the currency linked in any way. The ¥ sign is most familiar to Western readers as the symbol for the Japanese yen. I would rewrite this passage to read: In February 2002, a contract between the railway company and Tangshan locomotive for cooperation was signed, for the delivery of two 5-car DMU by the end of 2003 for a total contractual value of 98.8 million yuan. According to the contract, 40 million yuan was paid upfront, while the entire process of the development would occur under the guidance of the ministry. I do not think constantly restating the nationality of the currency unit would be necessary if it is used multiple times in the same article. An article about Thailand could use, say, "10 million baht", and then continue using the currency name without a link. 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 21:36, 19 August 2023 (UTC) Hmm. Would you rewrite the other four instances in that article too? NebY (talk) 21:43, 19 August 2023 (UTC) Yes, to read "yuan". The renminbi yuan is the only currency unit in existence at the moment called "yuan", so there cannot be any confusion, but "¥" would make readers think of the Japanese yen and "CNY" and "RMB" are a bit esoteric for general purposes; possibly they would be suitable in tables and infoboxes, just not in prose text. 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 21:48, 19 August 2023 (UTC) You appear to be conflating 2 issues. One is the official guideline MOS:CURRENCY and the other is what many editors do mistakenly. Editors do not always follow the guideline properly. "¥98,800,000 RMB" is definitely wrong, we should never mix the symbol and the ISO code together. In many cases this is solved by the use of the {{currency}} template. Eg CN¥ 98,800,000. First use of a rare currency within an article should be linked (as per the guideline). For each currency we generally display what the wikiproject for that country prefers (eg when I wrote software for bus ticketing systems in Sweden, I was told to always display "SEK", not "kr", because Swedes are comfortable with both forms but surrounding countries use "kr" for their own currencies). Raise the issue at {{currency}} (talk) with a notice at the appropriate country's wiki project to change a particular currency display (eg CNY vs RMB vs ¥ vs CN¥ vs yuan vs 元, etc). Note also that {{currency}} has a |first= option if you want to use the long form (first use within an article only), although linking often gives the same benefit to novices but is much nicer to read for those already familiar with the currency.  Stepho  talk  23:18, 19 August 2023 (UTC) Furthermore, off-site paper style guides are not of much help or relevance here on a question like this. Their are aimed at writing on paper, but WP:NOT#PAPER. The reason WP prefers the concision of codes and symbols is that we can and should link the currency on first occurrence. PS: And we should not use just "$" at first occurence; there are lots of dollars and many of them use that symbol. At first occurrence, use US$.  — SMcCandlish ☏ ¢ 😼  23:20, 19 August 2023 (UTC) You do know, don't you, that MOS:CURRENCY says that, in US-related articles, we should just say $ from the start and never link, explain, or qualify that. EEng 00:57, 20 August 2023 (UTC) Sure, if the context is already all-US. In a broader article, it's necessary to specify the currency more completely, and just a bare "$" by itself doesn't do that.  — SMcCandlish ☏ ¢ 😼  02:23, 20 August 2023 (UTC) I do understand difference in medium, but as I said earlier; if one is just having a brief read-through of a specific article unfamiliar symbols or codes in prose are likely to be distracting rather than helpful. I admit I am revealing my bias here; as someone who is not fully immersed in the topic I prefer to see rare currencies represented in words than symbology. While it is possible it could be advantageous on dedicated currency/economic articles I am more talking about the sorts of articles I am interested in editing; history (general, not specifically economic history), geography, biology, culture, engineering and such. An example of this is French history articles; it is seemingly already an unwritten rule to use my proposal. Beast of Gévaudan includes this line: "The encounter eventually came to the attention of Louis XV, who awarded 300 livres to Portefaix and another 350 livres to be shared among his companions." instead of using £ or ₶. 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 05:49, 20 August 2023 (UTC) Surely the question is just one of clarity and uniqueness. "Yuan" is unique, so is CNY; ¥ is not. (RMB is a journalistic pseudocode like BTC and STG, it has no status and should be deleted in sight.) As for your main question, MOS:CURRENCY says to use the common name (dollar, pound, lat, franc or whatever) provided that you disambiguate and hyperlink at first use. --𝕁𝕄𝔽 (talk) 07:39, 20 August 2023 (UTC) "CNY" is also not particularly helpful in the way "yuan" would be to someone not familiar with the subject, which I am guessing would be most readers. I am probably showing my biases, but "CNY" reads like a stock ticker code for the Canadian National Railway (the NYSE code is "CNI"). Stock ticker codes are probably the best comparison here: Wikipedia does not typically use them in prose when mentioning an organization except in specialized circumstances. Essentially I am proposing adding some text to the MOS advising that in prose text one should not use codes or abbreviations; use very familiar signs for the well known currencies, use names for less common ones. 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 08:02, 20 August 2023 (UTC) A list of exchange rates for various base currencies given by a money changer in Thailand, with the Thailand Baht as the counter (or quote) currency. Note the Korean currency code should be KRW. "CNY" is the ISO 4217 code as used by every official international currency exchange house (it is also where USD, GBP, AUD, SEK, etc come from). Not much used by the average person though. "RMB" (short for RenMinBi, which means "people's money") is used throughout China and is commonly known to almost everybody in China, its neighbours and anybody who does anything with China - it is as well known in Asia as USD is in the west. "¥" is also well known in China but is also used for many other currencies in Asia. Even Hong Kong street vendors use it for signs in Chinese even though Hong Kong has a dollar currency. Likewise, "yuan" and "元" (yuan in Chinese script) is used in multiple countries (including Hong Kong and China). Note: Japanese yen and Korea Won are actually derived from the Chinese word yuan. All this is to say that if we use {{currency}} to display (with |first= on first usage to spell it out in long form and links to the corresponding currency article) then most of our problems disappear. Then it is just a case of agreeing on the {{currency}} talk page which particular short/long forms to use for that particular currency. And if we form a consensus to change which forms to display then we update the template and it will update every article automatically. For fun, I once heard a news report on Hong Kong TV about a US company spending $XXX in Taiwan - all 3 countries used the dollar but at different exchange rates, so I had no idea what the actual value was, even ignoring my native Australian dollar.  Stepho  talk  09:09, 20 August 2023 (UTC) RMB certainly is well known in Asia, though Westerners, who are the majority of English Wikipedia's readership, are less likely to recognize it. Out of the four options: "yuan", "¥", "CNY" and "RMB", I believe "yuan" is the least bad; in word form the yuan is widely recognized as China's currency whereas the sign ¥ is most associated with the Japanese yen and RMB is not commonly used in the West. While ISO codes do have their place, using them in prose format (as opposed to just infoboxes and tables) just doesn't seem much more helpful than using a sign or abbreviation. I would be happy to take part in a discussaion at {{currency}}. Here are some sample style guide recommendations I have seen. From BBC News' style guide: The names of all currencies are written out in full at first reference - with the exception of the pound sterling, the euro and the US dollar, which are always £, € and $. If we do spell out euro, the plural is euros. Otherwise, abbreviations to be used after first reference are: SFr (Swiss francs); HK$ (Hong Kong dollars); A$ (Australian dollars). From the Guardian's style guide: for most currencies – for example yen, yuan, afghani – we spell out the full name rather than use a symbol or abbreviation, eg 100 yuan, 100,000 yen. Exceptions are the pound, the euro and dollars. For currencies we habitually refer to with their nationality, such as Swiss francs, you don’t need to keep repeating the nationality or, indeed, to state it at all if it is clear from the context whose currency you are referring to – just say 100 francs. Whenever the whole word for a currency is used it is lc: euro, pound, sterling, dong, etc. Abbreviate dollars like this: $50 (US dollars); A$50 (Australian dollars); HK$50 (Hong Kong dollars); C$50 (Canadian dollars). In stories where there may be confusion between US dollars and the local dollar, say US$ for clarity. Convert all foreign amounts to sterling in brackets at first mention, but use common sense – there is no need to put £500,000 in brackets after the phrase “I feel like a million dollars.” Take care when converting old money to new: some of our attempts have been meaningless, in that they have ignored the relative value of sums involved. We said in an obituary, for example, that Ronnie Barker was paid £1 9s (£1.45) a week for his first job in 1947 – a comparison of average earnings would convert that to around £113 today. Similarly, in converting the price of a “four shilling dish of rice and vegetables” in 1967 to 20p in today’s money we forgot to allow for its relative value; taking into account changes in the retail price index it would now be worth £2.23. Imperial College London's style manual is also quite interesting, listing abbreviations that can be used and where they should not. 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 10:18, 20 August 2023 (UTC) I think I am ready to make my official proposal: In the case of well-known currencies such as the US dollar, euro, pound sterling, and Japanese yen, use a simple currency sign when writing prose text (€123, £123, $123, ¥123) do not use ISO codes in prose (123 USD, 123 EUR, 123 GBP, 123 JPY). ISO codes may be appropriate in infoboxes and tables, but use the signs if possible. For lesser known currencies, spell out the name in full instead of using a symbol or abbreviation using the national signifier on first use (123 Turkmen manats) do not abbreviate or use ISO codes in prose (m123 or 123 TMT) Familiar currencies that use the $ symbol U+0024 $ DOLLAR SIGN may be denoted with disambiguating marks ($A, $NZ, Can$) more obscure ones should be spelled out in words, using the national signifier on first use (123 Mexican pesos). If comparison with the US dollar is necessary in context, use US$ to denote US currency. Do not append £ with abbreviations or codes (£123 STG, £123 GBP), in the vast majority of circumstances a simple pound sign alone will suffice to denote sterling. In those cases where disambiguation is absolutely necessary (for example if comparing with the historical Irish or South African pounds) qualify with the full word "sterling" (£123 sterling) Do not use £ for modern-day currencies other than those at par with sterling (£123). Other currencies with a unit named pound or similar should use words, using the national signifier on first use (123 Egyptian pounds) instead of symbols or codes (£E 123 or 123 EGP) There is currently a discussion ongoing about ¥ at {{currency}} that I am not knowledgeable enough to contribute to, so I stuck to proposing about £ and $. 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 21:00, 20 August 2023 (UTC) All dollars are equal, but some dollars are more equal than others. Dondervogel 2 (talk) 23:40, 20 August 2023 (UTC) (edit conflict) That all seems generally reasonable, except that the part on $ specificity is wildly inconsistent, in general advice, in order of the parts, and in using then not using standard country codes. We don't need to specify Unicode detailia for common symbols. I would rewrite this as: Currencies named "dollar" that use the $ symbol should be denoted with disambiguating country codes if the context does not already make it clear which country is intended or when comparing currencies, and may be linked at first occurrence: (US$, AU$, NZ$, CA$). Another option is to use the {{abbr}} template at first occurrence (NZ$, etc.) Other currencies that use this symbol should be spelled out in words, using the national signifier on first use (123 Mexican pesos). Also "do not use ISO codes in prose" and "do not abbreviate or use ISO codes in prose" should both read "... ISO currency codes ..."; there are lots of different kinds of ISO codes, and the two-letter ones used before currency symbols (NZ$, etc.) are also ISO codes.  — SMcCandlish ☏ ¢ 😼  23:44, 20 August 2023 (UTC) I'm afraid that I'm struggling to understand what it is about the current text re symbols that needs to change? MOS:CURRENCY has two relevant sections: #Currency names and #Currency symbols. When 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 started this discussion, it was primarily about editors' disinclination to use the "normal" [my word] name of a currency rather than its ISO code or familiar abbreviation. So surely any proposals for change should be directed at the #Names section? It seems to me right now that the #Symbols section is fine and we don't need to get into deeper prescription (but if we must, then SMcC's version is preferable). Stolitz, I can't see any suggested update to the #Names section in your proposal? --𝕁𝕄𝔽 (talk) 10:22, 21 August 2023 (UTC) Surely it is pertinent to the #Symbols section because it advises editors when not to use them. 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 13:18, 21 August 2023 (UTC) This makes sense to me, although I am not sure if "AU$" enjoys wide use; I have seen "A$" and "$A", but not "AU$". Granted my level of familiarity is not high; being British I am most familiar with issues around the £ sign. But in general I support this wording. 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 13:02, 21 August 2023 (UTC) Context on yuan vs. RMB: apparently only "yuan" is correct when referring to a specific quantity "7 yuan", but renminbi is the name for an unquantified amount. So "7 renminbi" is incorrect in the same way "7 silver" is incorrect but "7 pounds of silver" is correct: [13][14] I do agree that the MOS should be updated to encourage something like "X Chinese yuan" on first mention for currencies other than US dollars, euros, British pounds, and yen. English speakers are likely to be unaware which country a given currency denomination actually goes with, so saying the name of the country is educational. Some may infer this from context, but having converted a bunch of ₤ to £, I have to say that context is not 100% reliable, as many transactions are international or the value of things is described by foreign writers. Wikipedia is also sometimes printed, so we shouldn't rely on people being able to click through for comprehension. (Any many people who could click through won't, because it's disruptive to the flow of reading and takes time and some minimum amount of curiosity...many people would simply remain in the dark.) -- Beland (talk) 17:43, 21 August 2023 (UTC) That is correct viz "renminbi" vs "yuan". When describing sums of British currency one may drop "pound" when it is clear from the context that the amount does not refer to pence or shillings (e.g. "15 million sterling"), saying "x million sterling" also makes it clear one is not referring to lbs or some other currency. However I don't think this applies to renminbi; there are no other contexts in which the word "yuan" appears in English use. 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 18:09, 21 August 2023 (UTC) yuan who else thinks there are no other contexts? (i'm sorry.) dying (talk) 21:13, 25 August 2023 (UTC) I have amended the "symbols" section to include my suggested edits. I am very much interested in feedback on how it looks. @SMcCandlish, @JMF, @Beland, @Stepho-wrs 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 22:06, 21 August 2023 (UTC) I have restored the previous guidance on obsolete currencies and on inflation-adjusted equivalents.[15] Merging them left us saying that obsolete currencies should be both converted and adjusted for inflation, but providing no guidance on inflation adjustment of extant currencies. Neither change was good, nor was either discussed. NebY (talk) 22:29, 21 August 2023 (UTC) Apologies; I thought it was an uncontroversial cleanup, but I will leave it be. 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 22:43, 21 August 2023 (UTC) We now have For lesser-known currencies, spell out the name in full instead of using a symbol or abbreviation using the national signifier on first use. I hope this means For lesser-known currencies, on first use spell out the name in full using the national signifier instead of using a symbol or abbreviation, allowing the use of a symbol thereafter. Of course, if a symbol is to be used on subsequent instances, it's helpful to the reader to indicate that symbol on the first use, eg parenthetically. The article that was first given as an example, TSD09, can now be seen as intended before TCG made the currency template more obscure. It's clear and easily scanned, more so than in its new version with the currency spelt out, "million" used repeatedly, and no symbols, and that spelling out would be even more tedious if it had more than only 6 instances. We shouldn't specify that currency names are alwats spelt out, and we should be wary of bringing the MoS into conflict with common usage. NebY (talk) 22:53, 21 August 2023 (UTC) My intention is to help the reader by not using less-familiar symbols, in the old version of TSD09 there were not even any links. I used "million" rather than solely numerical digits because I often find entirely numerical amounts over 1,000,000 eye-straining. 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 23:08, 21 August 2023 (UTC) I have reverted the changes made by Stolitz to the MOS (at 22:04 UTC) and thus NebY's consequent/subsequent attempts to mitigate them. There is no evidence whatever of any consensus being reached and the changes should not have been made while debate was still in progress. Stolitz, it is critical for your continued participation in Wikipedia that you read and understand WP:CONSENSUS. You should not make significant changes to high profile pages like the Manual of Style without being certain that the discussion has reached a conclusion and a wording agreed. --𝕁𝕄𝔽 (talk) 23:11, 21 August 2023 (UTC) @SMcCandlish did say "That all seems generally reasonable, except that the part on $...", I took their suggested revision into account. What issues do you have with my suggestions? I am trying to make the site easier to read; masses of obscure codes and symbols are not exactly navigable to the lay person. I have made the same statement before, but which of the following statements do you find easier to read? Imagine you are a lay person, skimming an article for information on something. "The project was estimated at 100 million lev, but went overbudget by 20 million lev. "The project was estimated at 100,000,000 BGN, but went overbudget by 20,000,000 BGN 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 23:20, 21 August 2023 (UTC) Support from one editor is not consensus and SmCcandlish did not represent their statement as a closing summary of the discussion. Your desire to remove all but a few currency symbols from Wikipedia does not have consensus here and there's no indication that it's shared by the wider community. NebY (talk) 12:23, 22 August 2023 (UTC) Would it possibly be advantageous to advise against symbols for less-familiar currencies unless an article has particularly strong national ties? Treating it like ENGVAR? 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 12:55, 22 August 2023 (UTC) First, how often do we use symbols for less-familiar currencies in articles that do not have particularly strong national ties? Second, within such articles do we often use that currency only once? NebY (talk) 13:35, 22 August 2023 (UTC) My opinion is that if an article does not have strong national ties to the currency used in it then it should be mentioned using words instead of symbols. Hypothetically if an article about a French architect mentions a fee denominated in Peruvian soles then I think it ought to say "he received a fee of 50 million soles" instead of "he received a fee of S/.50,000,000" or "a fee of PEN 50,000,000". 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 15:09, 22 August 2023 (UTC) We try not to clutter the MoS with guidance on issues which aren't occurring, or which don't need MoS guidance to be resolved. NebY (talk) 15:16, 22 August 2023 (UTC) If the reader doesn't know anything about Peruvian currency then giving the name in full or the symbol are equally confusing. It's the linking that helps them, not the spelling. If the reader does know about Peruvian currency (or doesn't care) then the symbol is far less intrusive and the linking can be ignored.  Stepho  talk  15:18, 22 August 2023 (UTC) As mentioned earlier by @Beland "Wikipedia is also sometimes printed, so we shouldn't rely on people being able to click through for comprehension. (An[d] many people who could click through won't, because it's disruptive to the flow of reading and takes time and some minimum amount of curiosity...many people would simply remain in the dark.) " If the contract was from a Peruvian company which is explicitly identified as such than one can infer that the sol is Peru's currency just from the context given in the article without having to click away or open a new tab. If the context is a little more vague then one could write "50 million Peruvian soles". "S/." or "PEN" are not particularly helpful as it is a fairly obscure currency to the average English speaker. 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 15:47, 22 August 2023 (UTC) So now we're talking about a hypothetical printed copy of a hypothetical article, or hypothetical readers who are so averse to the very advantages of a hyperlinked encyclopedia that they won't follow links even though they wish to know to what currency we're referring. Let's instead respect their lack of interest or curiosity, and not force information on them to the detriment of readers of the live online encyclopedia - the vast majority - who have a free choice whether to seek further detail or simply read on. NebY (talk) 18:52, 22 August 2023 (UTC) @NebY: Writing articles that require the majority of readers to click through to background material before they are fully comprehensible seems like the opposite of good writing, not to mention guidelines like Wikipedia:Make technical articles understandable. The fact that some readers don't put in time or effort to overcome dense or jargony writing isn't an indication that they wouldn't be enlightened or better informed by a well-written article that they can understand on the first pass. I'm sure they would be much happier with that outcome, and be more likely to read more encyclopedia articles in the future. Including a few clarifying words here or there in an article does not negatively impact people who would click through for clarification—in fact, it saves them time and is less emotionally draining. Nor is it an impediment to understanding for people who are already familiar with the subject matter. -- Beland (talk) 23:17, 23 August 2023 (UTC) Writing (the process of copying information from a person's thoughts onto a permanent medium) articles that require the majority (at least 50%, some consider to require at least 70%) of readers to click through to background material (material not directly about the current topic but may be considered useful for explaining the context). Yeah, that reads better - not! Explanatory notes are a nice idea but they also distract the reader from what the article is saying. Better to use links (or sometimes footnotes) instead. Readers who already know the background can read through the text much faster without the explanations. Inquisitive readers will follow the links. Unknowledgeable but uninquisitive readers don't really care. Thrusting long winded explanations down their throats while also annoying the knowledgeable readers doesn't seem such a great idea.  Stepho  talk  22:44, 24 August 2023 (UTC) Agreed. If using parenthetical explanations was our norm, we wouldn't have footnote templates and would use links far less, meanwhile our articles would be bloated with parentheticals all over the place.  — SMcCandlish ☏ ¢ 😼  16:26, 25 August 2023 (UTC) Revised proposal For editor convenience and as this begins a new discussioon, I have inserted a section break and de-indented 𝔖𝔱𝔬𝔩𝔦𝔱𝔷's contribution. --𝕁𝕄𝔽 (talk) 18:36, 22 August 2023 (UTC) I think the best course of action is probably to handle each of my suggestions in isolation where possible. From the reception my proposal received, I think this is the least controversial, so I would like feedback on it. For currencies which use a unit named "pound" or similar: Use the £ symbol (U+00A3 £ POUND SIGN) for sterling, the currency of the United Kingdom. Avoid the U+20A4 ₤ LIRA SIGN. Do not append £ with abbreviations or codes (£123 STG or £123 GBP), in the vast majority of circumstances a simple pound sign alone will suffice to denote sterling. In those cases where disambiguation is absolutely necessary (for example if comparing with the historical Irish or South African pounds) qualify with the full word "sterling" (£123 sterling) Only use £ for modern-day currencies at par with sterling (£123). Other contemporary currencies with a unit named pound or similar should use words, using the national signifier on first use (123 Egyptian pounds) instead of symbols or codes (£E 123 or 123 EGP) This is generally keeping with the spirit of the existing guidelines with some re-wording to read more clearly (such as "the currency of the United Kingdom" instead of "the United Kingdom's currency"), and with tighter advice on how to disambiguate. Doing some searching there are some quite bizarre mongrel mixtures in evidence, until recently the article Irish pound used "GBP" in the context of the early 18th century, before the United Kingdom or even the Kingdom of Great Britain existed, while simultaneously using the pound sign for Irish currency.[16]. This has fortunately since been corrected, but the style guide does not give satisfactory advice on how to do this. I hope my tightening up of it will be of use in this regard. Whether the last part, about modern-day currency units named "pound", is included in whole as is or has modifications made will be dependent on how we decide to proceed with representing "less-familiar currencies"; however I do think it is important to reserve £ for sterling and currencies directly at par with it (i.e. the Jersey, Guernsey, Gibraltar, Manx, Falkland, and Saint Helena currencies). 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 18:15, 22 August 2023 (UTC) The UK pound is certainly the best known world wide and at least first among equals but I disagree strongly with the implication that it is the only one worth bothering about. The current text of bullet one reads Use the £ symbol (U+00A3 £ POUND SIGN) for unambiguous referrals to sterling, the United Kingdom's currency. Avoid the U+20A4 ₤ LIRA SIGN. Stolitz has deleted "unambiguous referrals". Yes, I agree that those words are redundant and indeed in my view it could be stronger: for example, as The £ symbol (U+00A3 £ POUND SIGN) may be used without qualification to refer to sterling, Others may disagree, of course. The second line was established by this February 2023 RfC and thus another RFC would be required to change it. So for now, I oppose changing this line. I would anticipate a frosty reception to another RFC on the same line in less than six months. The "currencies on par with Sterling" are tiny British Dependent Territories and thus well below the horizon for the MOS. The population of Egypt is 50% greater than that of the UK and should not be dismissed so lightly. The current text reads For currencies other than sterling, use the symbol or abbreviation conventionally employed for that currency, if any. which reads NPOV to me and thus I oppose the proposed change. --𝕁𝕄𝔽 (talk) 19:05, 22 August 2023 (UTC) £ does not appear to be widely used for the Egyptian pound, or indeed any other "pound" currency (e.g. Syrian, Lebanese, Sudanese) in reliable sources (checking the sources used at the page Egyptian pound, the source asserting £ as the common symbol is a currency comparison website, not anything remotely official), so I think advice against using £ for these currencies is a good idea. 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 19:19, 22 August 2023 (UTC) @JMF, I have been told the policy can be overturned here since it is a MOS issue rather than specifically related directly to the content of the pound sterling article. 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 23:05, 22 August 2023 (UTC) And now I do not know what is going on..... I... this was supposed to just be a brief discussion on toning down overuse of obscure symbols and now I'm just confused.... 𝔖𝔱𝔬𝔩𝔦𝔱𝔷 (talk) 23:34, 22 August 2023 (UTC) Notes Side note: a previous disruptive edit to a template provided the weak foundation for this debate Hard cases make bad law. It may be too late to say this now, but I had better do so in case it is still relevant. I had a feeling that the example quoted at the start of this discussion, TSD09 (since revised), had the hoofprints of banned editor TheCurrencyGuy all over it. Sure enough, that's what happened. He changed {{CNY}} so that, instead of outputting CN¥nnnn, it produced ¥nnnn RMB. Gross! I have reverted it. --𝕁𝕄𝔽 (talk) 07:43, 21 August 2023 (UTC) Discussion has become moot User:Stolitz has been deemed to be a sock of TheCurrencyGuy and is now blocked. Consequently, this discussion would appear to have run into the sand. If anybody really considers it to worth pursuing, they had best start a new topic. --𝕁𝕄𝔽 (talk) 21:49, 25 August 2023 (UTC)

Coordinates duplicated in the lead (both inside and outside infobox)

MOS:COORDS says: "This template may also be placed within an infobox, instead of at the bottom of the article." I've seen multiple pages (e.g., British Library, German Museum of Technology) having two sets of coordinates: one at the top right corner (at the same level as "From Wikipedia, the free encyclopedia") and another one inside the infobox (just below the picture). The duplication seems intentional, as per invocation parameters {{coord|display=title,inline}} inside the infobox. I'd like to propose discouraging the duplication, as a single set of coordinates should suffice. So, the original text would be rewritten as follows:

"Instead of at the bottom of the article, this template may be placed within an infobox; in that case, one should avoid duplicating the coordinate display, using either {{coord|display=title}} or {{coord|display=inline}}."

fgnievinski (talk) 03:16, 13 August 2023 (UTC)

(Edit: I've notified Wikipedia talk:Manual of Style/Lead section, Wikipedia talk:WikiProject Geographical coordinates, and Template talk:Coord. fgnievinski (talk) 21:48, 13 August 2023 (UTC))

My attitude is that infoboxes should summarize articles, not replace their content. Everything within an infobox should be duplicated in the actual article. That includes coordinates. —David Eppstein (talk) 03:46, 13 August 2023 (UTC)

I remove lead duplication whenever I come across it...... as do many many others. Not sure why we would need this twice in the lead. Moxy- 03:53, 13 August 2023 (UTC)

Because it should be possible to ignore the infobox as pointless clutter and still get the same information from the actual article. Having infoboxes take up all that screen space is bad enough, but their existence shouldn't actually make the actual content of the article worse. —David Eppstein (talk) 07:11, 13 August 2023 (UTC)

I have to concur with David Eppstein here; we have no control over WP:REUSE of our content, and that includes automated stripping of infoboxes and nav templates. See also MOS:INFOBOX#Infoboxes and user style: users can entirely hide infoboxes, and they are designed with CSS to make this possible, on purpose. These are among the reasons that MOS:INFOBOX is clear about "the purpose of an infobox: to summarize (and not supplant) key facts that appear in the article (an article should remain complete with its summary infobox ignored, with exceptions noted below)", and coords aren't an exception. The real question to my mind (for a very long time now) is whether the very top of the page is really a good location for coordinates, which are not of use to most readers and which are not Wikipedia meta-data about the page. I think it would make more sense to have this template be used in a geography section and put its content at the top of that section. Or even just do inline display so it can be used in a sentence, like "The coordinates of the center of the city are: [template here]." But that's something to probably propose at the template talk page, or even at WP:VPPRO since it would affect so many articles.  — SMcCandlish ☏ ¢ 😼  08:05, 13 August 2023 (UTC)

When coords are displayed at the top of the article, by means of |display=title or |display=inline,title, that establishes them as the primary coordinates for the article, and can be searched for and extracted by means of external tools.

When coords are used in the infobox, the infobox code can extract them in order to provide a pushpin map.

In some situations it is therefore desirable to show the coords twice, but the {{coord}} template only needs to be used once. --Redrose64 🌹 (talk) 15:50, 13 August 2023 (UTC)

Geo coordinates are such a niche need they ought to be displayed at the page footer, near the authority control box for desktop users. In mobile view, the coordinates in the header, near the title, are already intentionally hidden. The lead should be tested as prime space, so it shouldn't display informat twice. Also notice the display of coordinates only in the lead (title and/or infobox), while not elsewhere in the article, infringes on MOS:LEADNO/MOS:INTRO. fgnievinski (talk) 16:27, 13 August 2023 (UTC)

Yes, I strongly agree with this. It's pointless and distracting having them at the top.  — SMcCandlish ☏ ¢ 😼  21:20, 13 August 2023 (UTC)

I disagree with you. When I go to an article about a place, one of the things I'm most interested in seeing is a map (usually a Google Map or OpenStreetMap, but sometimes a topo map) showing where the place is in relation to other places I might know about. Having the coordinates, linking to a GeoHack page, at the top is definitely useful. Deor (talk) 22:06, 13 August 2023 (UTC)

Apples and oranges. Having a map at the top of the article is certainly helpful, but a) has nothing to do with coordinates appearing in the very top of the page as if it's article metadata, and b) doesn't even have anything to do with infoboxes directly displaying the same geeky information.  — SMcCandlish ☏ ¢ 😼  23:03, 13 August 2023 (UTC)

I just realized infobox images obviously are not duplicated in the lead; so, no, not all information in the infobox needs to be found elsewhere in the article. fgnievinski (talk) 02:00, 16 August 2023 (UTC)

Don't engage in petty and pedantic wikilawyering. I think you understand perfectly well that what was meant was textual information (and – just to forestall another round of wikilawyering – it necessarily means textual information that is not exempted by MOS:INFOBOXPURPOSE; e.g., "the ISO 639 and similar codes in {{Infobox language}} and most of the parameters in {{Chembox}}" need not appear in the main body text).  — SMcCandlish ☏ ¢ 😼  23:51, 20 August 2023 (UTC)

Don't engage in petty and pedantic wikilawyering – Are you crazy? Here at MOSDATE, petty and pedantic wikilawyering is our stock-in-trade. 00:23, 21 August 2023 (UTC)

I found your language intimidating. I still think geographic coordinates fits very well in the exception quoted, where it says: "As with any guideline, there will be exceptions where a piece of key specialised information is difficult to integrate into the body text, but where that information may be placed in the infobox." Hence the original proposal, to avoid displaying geo coordinates twice in the lead; displaying them only in the infobox would be permitted by MOS:INFOBOXPURPOSE. fgnievinski (talk) 06:08, 21 August 2023 (UTC)

Being disagreed with and called on your gamesmanship doesn't make you a victim. And you're just engaging in more gamesmanship here, completely changing your argument which was in favor of infobox images, to now being about infobox coordinate text, after I pointed out exceptions apply regarding the latter.  — SMcCandlish ☏ ¢ 😼  16:21, 21 August 2023 (UTC)

A while ago you were "strongly agreeing" with my assessment about why having geo coordinates at the top of a page is a bad idea. Then I responded to someone else about the possibility of having content only in the infobox, giving images as an example. You've responded actually quoting other supporting examples of information which can shown only in infoboxes, such as ISO 639 codes and chemical parameters. Geo coordinates are just numbers in a special format, there is no sentence of text. So, coords could reasonably be considered an instance of "key specialised information" -- maybe an RFC would be justified to gather consensus. My proposal since the beginning has been avoiding the duplication of geo coordinates in the page header, including the lead proper, infobox and the title line. While I consider the page footer the best place for geo coords, I'd take the infobox as the second best unique place. fgnievinski (talk) 03:45, 22 August 2023 (UTC)

Yes, I'll go along with all of that. (Sorry for being argumentative myself because I thought you were being pointlessly argumentative.)  — SMcCandlish ☏ ¢ 😼  15:14, 22 August 2023 (UTC)

Agree with David Eppstein: the infobox is a summary of the article, not a replacement for it. The reader should be able to choose whether to look at a box or to read prose, particularly the intro (varying accessibility issues being among the reasons). However, I do not consider the top of the page, the default result of "inline", to be part of the intro. We do not consider hatnotes, which appear in closer proximity to the intro text and centered, to be part of the intro. I therefore think there is a false premise here. (I also disagree with the proposal to relegate the "inline" display to the bottom of the article or to a specific section of text; I frequently consult articles on settlements specifically in order to use that link to go to a map, most recently to find the location of a wildfire. This must be a common use case for our articles on places. Yngvadottir (talk) 01:39, 22 August 2023 (UTC)

Duplication of content between infobox and the rest of the article is the general rule, but there are important exceptions sanctioned in MOS:INFOBOXEXCEPTIONS, which seem amenable to covering geo coordinates as well. fgnievinski (talk) 03:49, 22 August 2023 (UTC)

@Yngvadottir: You appear to have it backwards. With the {{coord}} template, using |display=inline puts the displayed coords at the same point that the template occurs: {{coord|51.5|0|display=inline}} → 51.5°N 0°E / 51.5; 0; using |display=title puts the displayed coords at the top of the page (top left in Cologne Blue, top right in other skins). --Redrose64 🌹 (talk) 16:25, 22 August 2023 (UTC)

Yes, you're right, I forgot which was which, sorry (remembering template parameters turns my brain to mush). BTW, thanks for confirming that Vector displays them in the same place; there's always a worry at the back of my mind that readers and newer editors may be seeing something very different from what I see in Monobook. Yngvadottir (talk) 21:07, 22 August 2023 (UTC)

If there is only one {{coord}} template with the parameter |display=inline,title, it's still a single coord template, so I don't think it counts as duplication. Sure, the same info is going to be displayed in two places, but I do not see this as a bad thing as long as the same coordinates are shown in the title and the infobox. After all, infoboxes duplicate info that is already in the body, and (in many cases) the lead also summarizes info that is in the body. I would be far more concerned if the infobox had one set of coordinates, and if there was a different set of coordinates displayed just below the page title.

By the way, I oppose moving coordinates down to the footer. It doesn't really solve anything and, in the case of geographical locations, actually makes it much harder to see that location on a map (there is a little drop-down map next to the globe icon of the {{coord}} template if the coordinates are displayed in the title). Further, it's quite pointless. – Epicgenius (talk) 14:18, 25 August 2023 (UTC)

While "geographiles" love the coordinates upfront, the average reader likely find it's just clutter. fgnievinski (talk) 23:43, 25 August 2023 (UTC)

Suggested shortcuts

Suggested for § Scientific and engineering notation: MOS:SCNOT, MOS:SCINOT, MOS:ENGNOT. Was surprised there was no shortcut to that section.

Also more "out-there" but might be easier for some to remember: MOS:TENTOTHE, MOS:10TOTHE. Meaning of course "ten to the power of x".

WP:AFC/R template barfs on cross-namespace redirs because it's designed to catch newbies who don't know what they're doing. Figured I'd just put the suggestions here instead. Plus that lets people provide input into what they consider redir-worthy. Go ahead and create if you like. Just trying to be helpful (for myself in the future even). Have a fine day. --47.155.41.104 (talk) 04:51, 25 August 2023 (UTC)

"FOONOT" tends to be used for notability guidelines, but I guess with "MOS:" on the front of it there would be less likelihood of confusion. If no one's got objections, I can handle this; I think I created about half the MoS shortcuts. :-)  — SMcCandlish ☏ ¢ 😼  16:49, 25 August 2023 (UTC)

"NOT" does make me think of negatives. MOS:EXPO? NebY (talk) 17:16, 25 August 2023 (UTC)

How about MOS:SCIENTIFICNOTATION? I don't see it getting a 2 x 10^3 lb of use. EEng 17:38, 25 August 2023 (UTC)

That's short measure, try 2.24 x 10^3 lb. ;-) Martin of Sheffield (talk) 19:49, 25 August 2023 (UTC)

i agree that "NOT" suggests a negative, as seen in "MOS:NOTUSA" and "WP:NOTSTUPID". (i think notability is more associated with "N", as seen in "WP:GNG" and "WP:NSPORT", though i just realized that the "NOT" in "WP:TRUMPNOT" might be referring to notability.) "MOS:EXPO" admittedly suggests to me that we have a style guideline about large international exhibitions.

how about "MOS:SCIENG", or alternatively "MOS:SCIENGNOTATION", if additional clarification seems necessary? for the "out-there" variants, i would suggest "MOS:10EX" or "MOS:10^X". dying (talk) 21:13, 25 August 2023 (UTC)

MOS:SCIENG might been too vague (lots of MoS, especially MOS:NUM, has something to do with science. MOS:SCIENGNOTATION should work. MOS:10^X should also work well.  — SMcCandlish ☏ ¢ 😼  22:10, 25 August 2023 (UTC)

I like those. Just interested in something shorter to punch in if in a hurry. 47.155.41.104 (talk) 23:25, 25 August 2023 (UTC)

It's more important that your fellow editors be able to recognize the shortcut without clicking through than that you be able to type it quickly. EEng 16:34, 27 August 2023 (UTC)

Especially when it comes to the shortcuts we "advertise" in the page itself, which is what this discussion is really about. Anyone can create any shortcut they want (within reason; if you create crap ones, then WP:RFD will nuke them, of course). But we should only present one or two really good shortcuts as the "advertised" ones here. (Some MoS sections have 20+ shortcuts, but we only list one to a handful of them).  — SMcCandlish ☏ ¢ 😼  17:25, 27 August 2023 (UTC)

Yeah, fine with me. Right now that section has no shortcuts. I have no sentimental attachment to my suggestion—just wouldn't mind one or two for that section. 47.155.41.104 (talk) 01:56, 28 August 2023 (UTC)

seeing support for (and no opposition to) "MOS:SCIENGNOTATION" and "MOS:10^X", i have gone ahead and boldly created those two redirects. i will let others decide whether they should be the advertised shortcuts; adding them to the manual myself seemed somewhat self-promotional.

by the way, i recently realized that the mos:num shortcut was apparently changed about a year ago to point to a specific section of the guidelines. is this desirable? dying (talk) 20:23, 1 September 2023 (UTC)

Added them for you. Also fixed the MOS:NUM redirect, which is what Wikipedia:Manual of Style/Dates and numbers advertises as it main page-top shortcut. If we wanted it to go to the #Numbers section, and pick a new page-top shortcut, that would be a consensus discussion to have.  — SMcCandlish ☏ ¢ 😼  21:05, 1 September 2023 (UTC)

Fractions containing expressions??

A recent https://en.wiki.x.io/w/index.php?title=Hard_disk_drive&oldid=1173248891 edit to Hard disk drive changed 68 x 12 x 12 x 12 divided by 2.1 to 68 × 12 × 12 × 12 ÷ 2.1. MOS:FRAC does not discuss the case where the numerator or the denominator is an expression. Is the use of ÷ in such cases appropriate? If not, is it appropriate to use / or to use the {{frac}} template, e.g., 68 × 12 × 12 × 12⁄2.1? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:59, 1 September 2023 (UTC)

Well in Norway, ÷ is not a division sign, it's a subtraction sign. See Division sign:

The division sign (÷) is a symbol consisting of a short horizontal line with a dot above and another dot below, used in Anglophone countries to indicate mathematical division. However, this usage, though widespread in some countries, is not universal; it is used for other purposes in other countries and its use to denote division is not recommended in the ISO 80000-2 standard for mathematical notation.

Does Help:Displaying a formula have any advice? --𝕁𝕄𝔽 (talk) 19:47, 1 September 2023 (UTC)

I recommend {{sfrac}} in this instance: ⁠68 × 12 × 12 × 12/2.1⁠. Indefatigable (talk) 20:34, 1 September 2023 (UTC)

or $68\times 12\times 12\times 12\times {\frac {1}{2.1}}$. CapitalSasha ~ talk 23:08, 1 September 2023 (UTC)

Err, The division sign ... used in Anglophone countries.... What's the problem? This is the English Language WP, so Anglophone usage ought to be sufficient. Martin of Sheffield (talk) 08:50, 2 September 2023 (UTC)

Because en.wikipedia is read by a worldwide audience, whose grasp of English may be good enough to read most articles but who may not be familiar with every obscure detail, such as a symbol that is only used in primary schools. --𝕁𝕄𝔽 (talk) 15:44, 3 September 2023 (UTC)

Unless there's specific reason to draw attention to the reciprocal, and certainly in that particular article where there are several such expressions in the footnotes, I'd rather read Indefatigable's less obtrusive {{sfrac}} - and not 68 x 12 x 12 x 12 x 2.1^-1 either :) NebY (talk) 17:53, 2 September 2023 (UTC)

You can eliminate the decimal point in the denominator by multiplying top and bottom by 10, $68\times 12\times 12\times 12\times {\frac {10}{21}}$ which of course simplifies to $68\times 12\times 12\times 4\times {\frac {10}{7}}$. --Redrose64 🌹 (talk) 22:59, 2 September 2023 (UTC)

You could but you probably shouldn't. The "2.1" here is in units of cubic inches, which doesn't make a nice unit by multiplying or dividing by 10. It is needed in this context to connect to the sourced claim that a certain device has that volume, and therefore to explain how the calculation relates to the result that it calculates. And as a physical measure, it is an imprecise number, not an integer, a distinction that would be lost by the change you suggest. —David Eppstein (talk) 23:05, 2 September 2023 (UTC)

Grouping of digits with commas is not allowed for numbers in the SI

The Wikipedia:Manual_of_Style#Numbers currently states that commas should be used for grouping of digits. It also links to MOS:DIGITS where the use of narrow gaps is given as an alternative. On both pages there are examples of numbers in SI units, but using the comma as the grouping digit.

It happens that the use of commas for the grouping of digits of numbers is not allowed in the SI since 1948, when the CGPM decided in its Resolution 7, and reaffirmed by resolution 10 of the 22nd CGPM, 2003: "Numbers may be divided in groups of three in order to facilitate reading; neither dots nor commas are ever inserted in the spaces between groups."

As many countries (including English speaking such as South Africa, and many non-English speaking) and international organizations use the comma as the decimal separator symbol, there is a real risk for English Wikipedia readers to misinterpret the numbers stated on an article if the comma is used as a grouping digit.

While it is necessary to stop using commas as grouping digits in quantities expressed in SI units, it is simpler and more consistent to apply that narrow spaces style to all other numbers as well, which would avoid interpretation mistakes by the readers for all quantities.

Therefore I propose to use narrow spaces instead of commas as grouping of digits in Wikipedia:Manual_of_Style and remove the allowance for them in MOS:DIGITS.

This would follow the recommendations from the BIPM,, ISO, NIST, IUPAC, the American Medical Association's widely followed AMA Manual of Style, among others.

Nativeblue (talk) 15:47, 27 August 2023 (UTC)

• Not going to happen. They can put me in BIPM-ISO-NIST jail if they want. EEng 16:39, 27 August 2023 (UTC)

  Yeah, WP is not written to SI's style guide (or ISO's or BIPM's, etc.). We're happy to accept their advice when it doesn't conflict with normal English usage, when there's a "clearly improves the encyclopedia" reason to do so, and especially when the particular point has made its way into major general style guides (e.g. much of WP:MOSNUM is derived from Scientific Style and Format, which is essentially a collation of the most useful and consistent style points promulgated by such organizations and by academic journal publishers). A side point: The South African government officially uses "1 234 567,890" style, but WP is not written in bureaucratese/officialese, and I can't find any evidence that South African readers have any trouble interpreting "1,234,567.890" format, which is otherwise used nearly universally in the English-speaking world, and is also built into many programming languages, user interfaces, etc. (regardless of language). I have a strong suspicion that even non-native users of English today have no difficulty with this format at all because of its modern ubiquity. However, there is probably some kind of Javascript "gadget" approach that could be built to convert between these formats on-the-fly, on the user side. I know that the citation templates are doing complex date-format translation, so this is clearly technically possible.  — SMcCandlish ☏ ¢ 😼  17:41, 27 August 2023 (UTC)

  I oppose a Wikimedia Foundation approved method for users to reformat numbers according to their preference. The next thing you know, the users of the system would demand we go in and apply special markup to numbers that are, for some reason, incompatible with the system. Jc3s5h (talk) 19:31, 27 August 2023 (UTC)

  You may remember when Wikipedia tried across-the board date autoformating, or maybe you've happily blanked it, in which case there's an overview here. That's a nicely circumscribed problem compared to rendering all numbers. Rendering all numbers held within {{val}}-like templates would be a bit easier, but then we'd have to persuade all editors to template numbers and to put up with the source text being even harder for human readers to parse, plus many of the other problems in that overview. NebY (talk) 18:20, 28 August 2023 (UTC)

• I would support a change along the lines of the one proposed by Nativeblue (talk · contribs). Using thin spaces instead of commas makes lists of numbers easier to read and eliminates the risk of the comma being misinterpreted as a decimal separator. Dondervogel 2 (talk) 17:52, 27 August 2023 (UTC)

  Clarification: I don't think anyone wants a blanket ban on use of the comma as thousands separator, and I would not support that either. It has been mentioned that some subject areas (e.g., finance) would not benefit from thin spaces, and that's reasonable. I just think that Wikipedia as a whole would benefit from wider use of thin space separators where there is no good reason to insist on a comma. Dondervogel 2 (talk) 20:26, 29 August 2023 (UTC)

• I'm a techie; I happily read numbers separated by thin spaces and sometimes use them within and outside Wikipedia. Most of our readers aren't, and most websites, newspapers, books and magazines don't use thin spaces. Most of our editors don't either, and many will complain about or revert them. Switching to thin spaces across Wikipedia, for mentions of monetary values, distances, demographics, and all the other quantities in the encyclopedia, would require broad support and clear consensus among active editors. It would not be possible to impose it by consensus among the few regulars at WT:MOSNUM; that would only result in MOSNUM guidance being revereted. Instead it would require techies and non-techies alike to agree it in a massive centralised discussion, and that would be dominated by the question of what actually happens in the world we describe - a world which has largely metricated (or metrificated), mainly implementing SI, with this one glaring exception. NebY (talk) 18:25, 27 August 2023 (UTC)
• Just no this is not how the majority of English-speaking countries render numbers in educational or business prose. Given that this is the English Wikipedia, we go with the common English-language style. TonyBallioni (talk) 18:50, 27 August 2023 (UTC)
• This is already dead in the water, but I'll add my opposition. – John M Wolfson (talk • contribs) 19:16, 27 August 2023 (UTC)
• Sorry this sounds like a terrible idea. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:40, 27 August 2023 (UTC)
• I'm not against it - although not wildly for it either. But how would it be implemented? Editors are not going to type in the Unicode for thin space - we have enough trouble getting them to use various dashes (note my incorrect but common use of "-"). Also, cutting and pasting those numbers to other programs or web pages may have those Unicode characters in them that may confuse that other program. They would have to wrap every number over 999 (or 9999) in something like {{val}}, which uses clever CSS tricks to copy only the digits. But wrapping them is a huge inconvenience to the editors and makes the wiki mark-up clumsy and hard to read and the majority of editors simply won't even realise that it should be done at all.  Stepho  talk  22:46, 27 August 2023 (UTC)
• Clearly a non-starter, for the numerous pragmatic reasons already discussed above, and more besides. This is an encyclopedia, not a technical resource. As such, its content is formatted and stylized in a fashion calculated to make it as easily digestible to the average reader of English, and consistent with broadest conventions employed within the most commonly used written idiolects. The principle of least astonishment should definitely be employed here, not for prescriptive reasons, but simply to make the content as accessible as possible to the average user likely to be reading our content. The proposal would replace that calculus for an effort to reach towards a more regularized and universal standard. But putting aside that my experience suggests to that the standard itself is not nearly as universally adopted in technical spheres and in global populations as the OP seems to think, it's just clearly not practical for encyclopedic form in the relevant language here. SnowRise ^{let's rap} 22:59, 27 August 2023 (UTC)

  "principle of least astonishment" Lol. Thank you for that addition to my mental furniture. Elinruby (talk) 03:14, 28 August 2023 (UTC)

  @Elinruby: See also WP:ASTONISH, and Principle of least astonishment.  — SMcCandlish ☏ ¢ 😼  05:13, 28 August 2023 (UTC)

  thanks. surprised I had not previously encountered that Elinruby (talk) 05:53, 28 August 2023 (UTC)

  And don't forget WP:Principle of Some Astonishment. EEng 06:03, 28 August 2023 (UTC)

• I like narrow spaces for grouping digits. I use them whenever I'm writing something where I have free choice over that element of style. But the Wikipedia editor is not the easiest for adding symbols that aren't on the keyboard, and editing on mobile phones is even harder. Also, readers use different browsers and different screen sizes, and sometimes numbers with spaces end up breaking across multiple lines (this might only be if the wrong sort of space was used, but I'm afraid that seems inevitable). So while I might like this to be the Wikipedia style, I don't think it's practical for a collaborative project with so many people using different systems to read and edit. Mgp28 (talk) 23:45, 27 August 2023 (UTC)
• Opposed - perhaps it’s because I am getting old… but I have difficulty deciphering large numbers without commas. Substituting spaces for the commas in large numbers would actually make reading Wikipedia harder for me.Blueboar (talk) 01:32, 28 August 2023 (UTC)
• Opposed - What Blueboar said. I have no particular objection to internationalizing a number of conventions, but not this one. - Donald Albury 01:46, 28 August 2023 (UTC)
• Oppose; There is, I think, (and as I assume several of the other editors know) a reason for the ISO style [converted into a Standard] — there are other languages (notably French) where the traditional convention is the exact opposite of English convention, e.g. the number 1,234,567.89 in Anglo-American style was often rendered as 1.234.567,89 ; i.e. separating thousands with periods/full stops (points) and whole numbers from fractions with commas (virgules). But what might be necessary for trans-national scientific exchange is problematic for the common, familiar Anglo-American conventions with which far more than 90% of our readers are used to seeing. And thin spaces, as others have argued more eloquently above, present their own problems such as absence from the QWERTY keyboard, unfamiliarity, and being less effective than commas in showing divisions between thousands. I don't know how the ISO separates wholes from fractions: commas, periods (full stops) or something else. And I can imagine that this might complicate what Anglo-Americans already don't grasp at first sight: the Indian system of lakhs and crores. —— Shakescene (talk) 02:25, 28 August 2023 (UTC)
• Oppose: translator here. I routinely convert number formats but on the whole I don't see what problem we are trying to fix that would justify such a massive find-and-replace. I would have no issue with 2 300 versus 2,300 but thin space is...not something I am going to learn how to do. Meanwhile, maybe I am just not seeing the problem but imho 3,4 is easily understood as 3.4, is it not? There might conceivably be an issue with a number that has many significant digits after the decimal, i.e 346.782 vs 346,782. But surely there's a conversion template for such edge cases? Elinruby (talk) 04:36, 28 August 2023 (UTC)

  @Elinruby: Which of these two lists do you find easier to read:

  • 10, 100, 1,000, 10,000, and 100,000

  or

  • 10, 100, 1000, 10000, and 100000?

  Dondervogel 2 (talk) 12:46, 28 August 2023 (UTC)

  @Dondervogel2: How often do I see this type of list is a better question. And can there not be another delimiter? As it happens, we just finished Black market in wartime France, an economics article that involved many numbers, and I think there was a single instance of readability demanding a comma after a number in the thousands, and I reworded in the copyedit phase. I think there are better uses for bot time.Elinruby (talk) 20:51, 28 August 2023 (UTC)

  I'd separate them by semicolons, especially after a colon: 10; 100; 1,000; 10,000 and 100,000. (Oxford semicolon optional.) Certes (talk) 22:16, 28 August 2023 (UTC)

  I'd be fine with that. What sort of article does this crop up in? It looks like some thing that wants to be a table but isn't. Looked into this a bit, and am wondering if the formatnum template would solve the perceived problem? I am getting a glimpse of the issue as it seems thar one of the editors really wants commas vs spaces. Maybe I was being too glib when I didn't take the question seriously Elinruby (talk) 20:12, 29 August 2023 (UTC)

  It seems rare. Examples include Asymptote#Introduction, Austro-Hungarian krone infobox and Arizona Outlaws#1984 Oklahoma Outlaws (huge section; search for "decent"). Certes (talk) 21:42, 29 August 2023 (UTC)

• Oppose, I know this has a snowball's chance in hell of being implemented, but it would generally be a complete non-starter for screen reader users like me, as the guideline already notes (also see an earlier discussion on this topic). Graham87 10:34, 28 August 2023 (UTC)
• Support: easier to read, avoids confusion. But what is "narrow spaces style". Is this not it: 10 526 241? Edward-Woodrow :) _[talk] 12:18, 28 August 2023 (UTC)

  I think this is: 10526241 ({{val|10526241}}) - I think those should be non-breaking spaces and should still be interpretted as a single number by a screen-reader (rather than as ten, five hundred and twenty six, etc.). Mgp28 (talk) 12:36, 28 August 2023 (UTC)

• Support: but provide {{SI number}} template to separate groups of digits with nonbreaking spaces. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:32, 28 August 2023 (UTC)

  Do you mean like this?

  • 10526241

  Dondervogel 2 (talk) 12:35, 28 August 2023 (UTC)

   Done but called {{val}}. Of course it only works if we enclose all numbers in {{val}}. NebY (talk) 17:46, 28 August 2023 (UTC)

  Exactly, as long as the gaps are nonbreaking. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:35, 30 August 2023 (UTC)

• Oppose. We are not a solely scientific publication. The proposal would also massively increase accessibility problems, and this thread shows that even people who care about (and have presumably just read) the MOS are likely to misunderstand the guidance for the narrow spaces style. Firefangledfeathers (talk / contribs) 12:41, 28 August 2023 (UTC)
• Oppose. ISO needs a format which works for scientists and engineers across languages. MOS needs a format which works for readers of English prose. Those two problems have different solutions. We can't expect new editors to type 123<thin space>456 consistently, let alone {{some template|123,456}}. However, some sort of gadget to identify numbers and convert them into the user's preferred format, whether that's ISO, French or Indian, might be useful. (Beware of dates, ISBNs and other fake integers.) Certes (talk) 14:59, 28 August 2023 (UTC)

  Would (e.g.) the year A.D. 1776 [C.E.] be rendered by some 'bot or template as 1 776 or 1,776 ? —— Shakescene (talk) 18:50, 28 August 2023 (UTC)

  Deliberately? I'm not aware of any culture that prefers 1 776 or 1,776 to 1776, but it's possible. Accidentally? Almost certainly. It's hard for sofware reading that Football F.C. fielded "their 2023 players" to know that this refers to the year rather than extreme cheating. Certes (talk) 19:38, 28 August 2023 (UTC)

  I would narrow the application of thin spaces. Thin space are sometimes used by, or on behalf of, scientists and engineers when they are writing journal articles and similar formal publications. They are seldom if ever used in personal notes and calculations that lead up to the final publications, because it's just too much of a burden. Do we really want to force Wikipedia editors to use a style that even scientists and engineers won't use except to publish papers so they can look good to their employers and put food on the table? Jc3s5h (talk) 20:24, 28 August 2023 (UTC)

  In short "hell no".  — SMcCandlish ☏ ¢ 😼  21:57, 28 August 2023 (UTC)

• Oppose, solution in search of a problem. Stifle (talk) 12:34, 29 August 2023 (UTC)
• Never going to happen. Instead, Use magic word formatnum – that will output it in the correct format for whatever wiki the page is in. It might be possible to override that just for your own pleasure with appropriate adjustments to your common.css, but I'm not certain about that. Mathglot (talk) 05:06, 2 September 2023 (UTC)

  The idea is nice but now we have to convince editors to write "in 2021 they sold {{formatnum:12345}} copies" instead of the far simpler "in 2021 they sold 12,345 copies". Considering how hard it has been trying to convince editors to use ndash "–" or mdash "—" instead of the "-" character, this is unlikely to succeed.  Stepho  talk  08:14, 2 September 2023 (UTC)

  This is not a valid objection. What happens in practice is that the vast majority of editors (including myself) use "-" for everything because they don't know better. Then a more informed editor (or a bot?) comes along and tidies up the initial text, and everyone is happy. In the same way, the vast majority of editors will type "12,345". There's nothing wrong with that, and nothing to stop a more informed editor to replace it with {{formatnum:12345}} or {{val|12345}}, or whatever template is preferred. Dondervogel 2 (talk) 09:27, 2 September 2023 (UTC)

  Sure, the wikignomes are underworked, they'll be so glad for more burden - whip us harder, we love it!. We're not talking a few instances per article, we're talking many, many instances for every single article. And each new edit potentially adds another one, which we have to fix without confusing them with 4 digit years or anything that goes into a template - eg {{convert}}.  Stepho  talk  09:47, 2 September 2023 (UTC)

  That's a good point, and a reason for careful consideration. LOL. Dondervogel 2 (talk) 10:33, 2 September 2023 (UTC)

• No, this won't do. The subject is way more complicated and needs a lot more thinking about. I understand the Manual of Style to be saying that we format Pi as 3.141,592,654... Is that really intended? And do we really intend to use American high school rules in articles within the scope of WikiProject Mathematics? Because if I use one of Wikipedia's several competing versions of proper math formatting, I get $3.141592654...$ or 3.141592654.... I should get $3.141,592,654$ or 3.141,592,654, should I? Because that looks way off to my eye. And the non-breaking spaces don't always work at all. I mean, I can render 3.141 592 654 using {{math}} but <math> won't render a non-breaking space. I think whatever we decide here is going to need fixes to the way math syntax works. I also don't think it's right to to insist on American high school number style for articles covered by WikiProject Mathematics, WikiProject Astronomy, and other hard science for grown ups, and I feel we need a sort of WP:ENGVAR-style "don't alter the original author's formatting" rule.—S Marshall T/C 13:37, 2 September 2023 (UTC)

  I don't think anyone is considering grouping with commas after the decimal point. I haven't read the whole discussion so I can't be sure, but I'd be fairly shocked. I would remove such commas on sight, and I think most people would, without needing anything said about them in the MoS. Commas before the decimal point are what I think we're discussing. --Trovatore (talk) 16:19, 2 September 2023 (UTC)

  Yeah, I don't know what S Marshall's going on about. Nothing in either the main MOS or MOSNUM suggests these weird things. EEng 17:24, 2 September 2023 (UTC)

  It startled me too. But it's possible to take In general, digits should be grouped and separated either by commas or by narrow gaps to mean that commas may be used as separators after the decimal point, with an exception for numbers greater than 999, When commas are used left of the decimal point, digits right of the decimal point are not grouped (i.e. should be given as an unbroken string). NebY (talk) 17:43, 2 September 2023 (UTC)

  If anyone seriously suggests doing that we'll just have them killed. I know people who will do it for nothing as a public service. EEng 18:38, 2 September 2023 (UTC)

  We should probably mention that. NebY (talk) 18:42, 2 September 2023 (UTC)

  What, and spoil the fun? Dondervogel 2 (talk) 19:05, 2 September 2023 (UTC)

• If it means don't group numbers after the decimal then it should say so. And my other point remains: we still need to make exceptions to the commas rule for people using {{math}} and <math> so the articles about serious maths can use serious maths formatting.—S Marshall T/C 21:48, 2 September 2023 (UTC)

  Please say the exact change to the guideline text you want. I can't tell what the problem is. EEng 23:52, 2 September 2023 (UTC)

  The rule is "always use commas for large numbers". I want exceptions to that rule, firstly for articles within the scope of WikiProject Mathematics, and secondly, for all editors using {{math}} or <math> rather than typed out numbers.—S Marshall T/C 01:04, 3 September 2023 (UTC)

  By "the exact change" I mean something of the form: "Add blah blah blah as a new bullet point to the Foo list" or "Change the text lorem ipsum to mickey mouse". EEng 07:31, 3 September 2023 (UTC)

  Playing Devil's advocate, if I was editing an article about how many of a particular car were sold in 2020 and I didn't want to use commas, then according to your proposal I could wrap the sales figures in {{math}} or <math>.  Stepho  talk  01:11, 3 September 2023 (UTC)

  The rule given at WP:MOS#Numbers is "In general, use a comma in numbers with five or more digits to the left of the decimal point." I think that's generally good guidance. It links to MOS:DIGITS for the specifics, and DIGITS gives us "[grouping with narrow gaps] is especially recommended for articles related to science, technology, engineering or mathematics". I think the status quo is not far off from what you're looking for, but I may be misunderstanding your view. Firefangledfeathers (talk / contribs) 01:16, 3 September 2023 (UTC)

  For example, binaries. The decimal number 100 should be rendered in binary as 1100100 and not 1,100,100. Our article on binary number, if you check it, actually uses commas to separate numbers in a list of numbers rather than to group digits. It's a pretty decent article and trying to make it comply with this MOS rule would break it.—S Marshall T/C 01:22, 3 September 2023 (UTC)

  No one in their right mind would understand the guideline to mean you should do that. EEng 07:31, 3 September 2023 (UTC)

  My experience with editors who're MOS focused is very different from yours, then.

  Humour me, Eeng. Utterly needless though these clarifications are, let me put them in.—S Marshall T/C 08:46, 3 September 2023 (UTC)

  For, like, the third or fourth time, say exactly what change you want, or just put it in the guideline directly so we can all see it, or do something else tangible. You keep saying you want something added but never say quite what. EEng 19:59, 3 September 2023 (UTC)

For Christ's sake, Eeng, seriously?—S Marshall T/C 23:42, 3 September 2023 (UTC)

S Marshall's proposed revisions to Wikipedia:Manual_of_Style#Numbers. Additions in red, deletions in strikethrough

Integers from zero to nine are spelled out in words. Integers greater than nine expressible in one or two words may be expressed either in numerals or in words. Other numbers are given in numerals or in forms such as 21 million. See MOS:NUM § Numbers as figures or words. In general, use a comma commas in numbers with five or more digits to the left of the decimal point. Numbers with four digits are at the editor's discretion: 12,345, but either 1,000 or 1000. See MOS:NUM § Grouping of digits. Don't use commas after the decimal point, and don't use commas in numbers that aren't in base 10. Don't apply Wikipedia:Manual_of_Style#Numbers to articles within the scope of WikiProject Mathematics, or to text formatted with {{math}} or <math>. In these cases apply MOS:DIGITS instead. In general, use decimals rather than fractions for measurements, but fractions are sometimes used with imperial and U.S. customary units. Keep articles internally consistent. Scientific notation (e.g., 5.8×107 kg) is preferred in scientific contexts. Markup: {{val|5.8|e=7|u=kg}}. Write out "million" and "billion" on the first use. After that, unspaced "M" can be used for millions and "bn" for billions: 70M and 25bn. See MOS:NUM § Numbers as figures or words for similar words. Write 3%, three percent, or three per cent, but not 3 % (with a space) or three %. "Percent" is American usage, and "per cent" is British usage (see § National varieties of English). In ranges of percentages written with an en dash, write only a single percent sign: 3–14%. Indicate uncertainties as e.g., (1.534±0.35)×1023 m. Markup: {{val|1.534|0.35|e=23|u=m}}. See MOS:NUM § Uncertainty and rounding for other formats.

• Grouping of digits (whether by commas or spaces) is never done after the point, only before it. Our {{formatnum:}} magic word knows that too: {{formatnum:1234567.9876543}} → 1,234,567.9876543 - I'm pretty sure that there's an ISO doc on the matter, but I don't have the appropriate subscription. --Redrose64 🌹 (talk) 17:56, 3 September 2023 (UTC)

  The magic word formatnum, according to the documentation, changes its behaviour depending on the language setting of the page. That makes it more complicated than I want to think about.

  In contexts where thin spaces are being used to group digits, the grouping should be done on both sides of the decimal point. So says the National Institute of Standards and Technology (¶ 10.5.3). Jc3s5h (talk) 18:33, 3 September 2023 (UTC)

  The print Kaye and Laby separated groups of three digits with thin spaces when there were more than four digits after the point. The archive of NPL's online version also has three-digit grouping (with rather wide spaces)[17] except that mathematical constants have five-digit grouping there[18] (unlike the print edition). The SI Brochure has spaced three-digit grouping after the point, as do various ISO standards; as you say, there probably is one on the subject, or at least on the format for ISO standards. NebY (talk) 18:49, 3 September 2023 (UTC)

• NebY (talk · contribs) is correct. From p150 of the SI Brochure, 9th edition,

  Following the 9th CGPM (1948, Resolution 7) and the 22nd CGPM (2003, Resolution 10), for numbers with many digits the digits may be divided into groups of three by a space, in order to facilitate reading. Neither dots nor commas are inserted in the spaces between groups of three. However, when there are only four digits before or after the decimal marker, it is customary not to use a space to isolate a single digit. The practice of grouping digits in this way is a matter of choice; it is not always followed in certain specialized applications such as engineering drawings, financial statements and scripts to be read by a computer.

Examples given are "43279.16829 but not 43,279.168,29" and "either 3279.1683 or 3 279.168 3". Dondervogel 2 (talk) 19:49, 3 September 2023 (UTC)

The scope of my proposal was understood way beyond what I intended. My focus is on measures in SI units.

Take the example which is currently on the MOS:DIGIT as a "good" example: 255,200 km. A reader which understandably uses the SI rule to interpret it will believe the number means the same as 255.200 km, which is one thousandth of the value intended. This problem does not happen with the already allowed alternative 255200 km.

How current MOS digit grouping alternatives get interpreted

Ungrouped	MOS Groupings	Meaning on SI	Meaning on countries with decimal comma
123456	123,456	123.456	123.456
123456	123456	123456	123456
12345	12,345	12.345	12.345
12345	12345	12345	12345
1234	1,234	1.234	1.234
1234	1234	1234	1234
123456.7	123,456.7	invalid	123.4567
123456.7	123456.7	123456.7	123456.7
12345.6	12,345.6	invalid	12.3456
12345.6	12345.6	12345.6	12345.6
1234.5	1,234.5	invalid	1.2345
1234.5	1234.5	1234.5	1234.5
1.2345	1.234,5	invalid	1234.5
1.2345	1.2345	1.234	1234

Luckily not all cases are ambiguous, but any ambiguous examples of SI units in the MOS need to either be fixed by using {{val}} or be marked "bad". Nativeblue (talk) 21:32, 3 September 2023 (UTC)

Eh? Whats wrong with 1.234,5? I suppose that could be borderline (4 digits only), but consider 0.123,456,789 - the alternative 0.123456789 is a nightmare. Martin of Sheffield (talk) 21:53, 3 September 2023 (UTC)

The problem with 1.234,5 is the ambiguity (it can mean a number a little of over 1.2, or a number a little of over 1234). And the alternative to the abomination 0.123,456,789 is 0.123456789. Dondervogel 2 (talk) 22:05, 3 September 2023 (UTC)

The 1.234,5 format isn't widely used or understood. I'd probably assume it was a European version of the number I'd write as 1,234.5. 0.123456789 is indeed a nightmare; the best alternative is 0.123 456 789. I don't think anyone is seriously proposing using commas after the decimal point. If the proposed wording could be misinterpreted as implying that, it should be clarified. Certes (talk) 22:10, 3 September 2023 (UTC)

Why assume a European interpretation in an English WP? If writing on the French or German WP I'd use their formats. As for "isn't widely used or understood" you suprise me. It's how we were taught in the 1960s and how I've always written long fractions right through school exams, uni and life for the last half century. Is this some new millenial thing? Martin of Sheffield (talk) 09:47, 4 September 2023 (UTC)

• I was at school in the 1960s and 1970s (O levels in 1976; A levels in 1978). I would be perfectly comfortably with "1.2345" to mean a number a little over 1.2. No ambiguity there.
• If I encountered "1.234,5" in an English text, I would be mystified. Using British English conventions I find it impossible to parse, so, like Certes I would most likely interpret as 1234.5 (though relatively rare, it's not hard to find examples of this use [19][20][21] on English Wikipedia), but I would feel I was missing something. It's not a format we should be using or advocating on MOSNUM.

Dondervogel 2 (talk) 11:44, 4 September 2023 (UTC)

Those three examples are clearly European style. For example, $3.000,00 is obviously three thousand dollars and no cents rather than three dollars shown to the nearest thousandth of a cent. Certes (talk) 12:45, 4 September 2023 (UTC)

If you were educated in the United States, you would be repeating 5th grade for the 60th time. Jc3s5h (talk) 11:48, 4 September 2023 (UTC)

I don't think it's millennial (I'm certainly not), but commas after the point are not a format I encounter often enough to recognise it instantly. The websites I just checked describe it as unusual, though they do look like personal blogs rather than reliable sources. Certes (talk) 11:48, 4 September 2023 (UTC)

Your proposal was understood the first time and WP:SNOW-opposed. We're not going to try to forbid the current use of commas as thousands-separators. (Suggesting that we have different rules for numbers with SI units and other numbers is not realistic either.) The discussion's moved on. We're now talking about whether or not to go into detail about some other matters, such as the use of <math> formatting, binary numbers, and the use of commas as separators after the decimal point. NebY (talk) 22:21, 3 September 2023 (UTC)

• The proposal was mis-interpreted as a blanket ban on the comma as thousands separator. That blanket ban, though never intended, was indeed, snow-opposed.
• I believe the intended proposal was an adjustment to one of two different rules that already exist, one for mathematical and scientific articles (thin space separators) and one for most other articles (comma separators). It might help if the proposer would suggest a specific text change (for scientific articles). The misunderstanding might then be resolved.

Dondervogel 2 (talk) 22:42, 3 September 2023 (UTC)

Hopefully the following modification clarifies it (additions in red, deletions in strikethrough):

• In general, digits should be grouped and separated either by commas or by narrow gaps (never a period/full point).
  • Grouping with commas
    • Left of the decimal point, five or more digits are grouped into threes separated by commas (e.g. 12,200; 255,200 km; 8,274,527th; 1⁄86,400).
    • Numbers with exactly four digits left of the decimal point may optionally be grouped (either 1,250 or 1250), consistently within any given article.
    • Don't use commas to the right of the decimal point, or with numbers not in base 10.
    • Avoid having a comma in whole numbers with SI units because this is ambiguous. Instead, use a larger prefix, scientific or engineering notation or format with {{val}}. (e.g. 13.8 kV; 13.8×10³ V; 1.38×10⁴ V; 13800 V; but not 13,800 V)
    • Markup: {{formatnum:}} produces this formatting.
  • Grouping with narrow gaps
    • Digits are grouped both sides of the decimal point (e.g. 6543210.123456; 255200 km; 520.01234 °C; ⁠101325/760⁠).

(...) Nativeblue (talk) 20:33, 10 September 2023 (UTC)

The proposal at 20:33, 10 September 2023 (UTC) claims that 13,000 V is ambiguous. But making such a claim contradicts the requirement elsewhere in the guideline "use a period/full point (.) as the decimal separator, never a comma: 6.57, not 6,57." If using a comma as a decimal is forbidden, then "13,000 V" can never mean 13 V ± 0.001 V. I dispute the whole notion that the allowance in the SI Brochure of either "." or "," means that either must be allowed in any context. In the context of Wikipedia the only allowable decimal point is ".". — Preceding unsigned comment added by Jc3s5h (talk • contribs) 21:17, 10 September 2023 (UTC)

Yes; en.WP isn't written for non-English-speaking Europeans who use commas as decimal indicators.  — SMcCandlish ☏ ¢ 😼  21:22, 10 September 2023 (UTC)

English Wikipedia is read by people from all over the world, being English an official language in their countries or not. This includes people from places which use the decimal comma.

It is very unlikely that they would know that only the dot is allowed as the decimal separator, specially if they don't edit en.WP themselves, which most people don't.

Take for example an analogy with the date formats. Both mm/dd/yyyy and dd/mm/yyyy are disallowed in en.WP, but this fact does not make either of those formats unambiguous. That is why the subset of accepted formats needs to be more restrictive. Nativeblue (talk) 22:03, 10 September 2023 (UTC)

This argument is not specific to quantities expressed in SI units so does not support a requirement that only applies to such quantities. Jc3s5h (talk) 22:44, 10 September 2023 (UTC)

I would be okay with explicitly stating that commas are not used in binary and other numbering systems ("The decimal number 100 should be rendered in binary as 1100100 and not 1,100,100", etc.). But we have no need to say anything about math markup in here than we already do, because MOS:DIGITS already makes the desired exception. As Stepho-wrs points out, drawing more prominent attention to an exception for that markup may have the WP:BEANS consequence of encouraging comma haters to unnecessarily convert to such markup in inappropriate contexts just to avoid comma usage. And we don't need to say the same thing twice anyway, even for WP:SUMMARY purposes, because MOS:DIGITS is already part of the same guideline page.  — SMcCandlish ☏ ¢ 😼  01:34, 5 September 2023 (UTC)

References

full, unambiguous signifier for CNY

What would be a "full, unambiguous signifier" for CNY? My guess would be CN¥? I've seen all kinds of things including CNY, RMB, RMB¥, and I would like to tidy those up. And do we/could we have a document anywhere where we list all of them? Danielt998 (talk) 21:43, 7 September 2023 (UTC)

Seems reasonable to me, like "US$" and "UK£" (or GB£ if you prefer). The problem with the ISO codes like CNY (and USD and GBP), and "traditional" financial industry abbreviations like RMB which sometimes completely differ from the ISO ones) is that they are ambiguous with a lot of other acronyms. I know there are fans here and there of "just do everything ISO does and make it some kind of mandatory policy to follow ISO in everything" (we even have a few people who want to impose ISO dates in running text, LOL). But I think there are other, more reader-facing concerns to keep in mind. WP isn't a banking and currency-trading institutional publication, and is not in any way bound to follow the house-style ideas of publishers in that niche.  — SMcCandlish ☏ ¢ 😼  03:43, 26 September 2023 (UTC)

What is "the body of an article"?

I recently encountered Wikipedia talk:Manual of Style/Dates and numbers/Archive 162#Proposal: Allow use of % for percentages in non-technical articles, which changed the ambiguous "technical" terminology, but retained the "body of an article" terminology. Around the same time as that conversation, I was in a dispute about the use of % in an article where I was reverted when restoring to a long-standing use of %, because my interlocutor interpreted "body" as meaning "the part of the article that is not the lead". I left it standing at the time because MOS arguments are not a hobby of mine and I have really mixed feelings on that article these days anyway, but given that all terminology in MOS:% now uses "body" as opposed to "tables/infoboxen", I'm not sure if this is...the intended reading. What's the intended reading? Vaticidalprophet 02:37, 26 September 2023 (UTC)

The body is the main text of the article. It doesn't include references, see also, illustrations and their captions, the table of contents, the title, the short description, etc. Bubba73 ^{You talkin' to me?} 02:49, 26 September 2023 (UTC)

Yes, but does it include the lead? That's the specific contention in this case. Vaticidalprophet 03:05, 26 September 2023 (UTC)

I'm not sure. Bubba73 ^{You talkin' to me?} 03:14, 26 September 2023 (UTC)

Yes, it includes the lead in a context like this: we do not write lead prose differently from after-lead prose, or readers would get quickly confused, since it would seem like the content was written by two different organizations. (There may be a handful of references in MoS somewhere to "body" meaning "after the lead", but those will be clearly in their context contrasting the lead specifically from the rest of the article. Leads do have different "information architecture" requirements from the rest of the article, but are not written in a different style of writing, including "%" versus "per[ ]cent"). Anyway, it was clear from reading the MOS:% text what the issue was and a couple of edits should resolve the problem (combined diff: [22] – someone may want to tweak it further). Anyway, the point is that person you refer to who thinks "body" in this case means "only after the lead" is completely mistaken (probably just honestly confused, no wiki-lawyering inappropriately). The new footnote should fix the confusion, and has probably been needed for a long time because MoS pages should not use "wiki-terms" in ambiguous ways without being very clear what the meaning really is in that particular instance.  — SMcCandlish ☏ ¢ 😼  03:38, 26 September 2023 (UTC)

• I confess that I sometimes use "article body" to mean the part after the lead. At other times I say "the article proper". Neither is self-explanatory. Just lazy I guess. EEng 04:38, 26 September 2023 (UTC)

  There are some times when the lead is different from the rest. You are not supposed to put references in the lead. Bubba73 ^{You talkin' to me?} 05:01, 26 September 2023 (UTC)

  Not always true; we put references in the lead for claims readers are apt to find controversial, and references go in the lead on short stubs because they only consist of a lead. And that's not a style matter anyway, but a content matter, which is why WP:CITE is not "MOS:CITE".  — SMcCandlish ☏ ¢ 😼  05:30, 26 September 2023 (UTC)

  "I confess that I sometimes use 'article body' to mean the part after the lead." Sure, it can make sense when the context is clear enough, which is why MOS:LEAD uses it that way. We just had a problem here where we meant something completely different, as Bubba73 laid out above, and hopefully my footnoting and other text tweaks will resolve the confusion without any issue.  — SMcCandlish ☏ ¢ 😼  05:33, 26 September 2023 (UTC)

Commas in numbers?

Does the MOS have any suggestions on adding commas in numbers? For example, 1000 vs 1,000. I tend to add commas to differentiate between years, for example 2,023 vs 2023, but I haven't been able to find a recommendation on commas in general. Does this exist? —Panamitsu (talk) 23:21, 7 October 2023 (UTC)

Try MOS:DIGITS. ―Mandruss ☎ 23:27, 7 October 2023 (UTC)

RfC on season and episode numbering

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia talk:Manual of Style/Television#Number format within TV articles - request for views. This is an RfC on "season 3, episode 7" versus "season three, episode seven" styles (and probably also "seventh season" vs. "7th season", etc.).  — SMcCandlish ☏ ¢ 😼  19:14, 11 October 2023 (UTC)

Overlining a problem

MOS:DECIMAL currently has Indicate repeating digits with an overbar e.g. 14.31{{overline|28}} gives 14.3128. (Consider explaining this notation on first use.) An IP editor at Inch is persistently changing eg 0.333 for ⁠1/3⁠ to 0.3, claiming correctness. Not only may many readers fail to fully grasp that, but also Graham87 reports that screen readers "don't read out the attributes generated by the overline template". This particular IP editor doesn't claim to be relying on MOS:DECIMAL but others may and produce similar problems. Can we improve it? NebY (talk) 20:41, 11 October 2023 (UTC)

0.333 does indeed seem somewhat strange. If the overline is used it seems reasonable to start it as early as possible. The alternative would be to use rounding and say 0.333, without overline. Gawaon (talk) 20:58, 11 October 2023 (UTC)

That's a good point about rounding, and might well resolve that particular case of conversion values from Inch to palms, feet and yards. NebY (talk) 10:14, 12 October 2023 (UTC)

Yeah I've just tested it in both Chrome and Firefox on the two most common Windows screen readers, JAWS and NVDA, neither of which indicate the overline while reading text. If you focus on the character with the overline on it in Chrome and press JAWS key+F to get its font information, JAWS sometimes (but not always) says it has no font and has a 0-point font size, which distinguishes it from the surrounding text in a really bizarre way (screen readers are weird, m'kay?). Otherwise neither screen reader shows any indication at all. Graham87 (talk) 05:27, 12 October 2023 (UTC)

Which would seem to suggest that something that reads as 0.333 (overline being indecipherable) is going to be more useful and suggestive to unsighted readers than a simple 0.3. Of course the decimal notation of 1⁄3 is well known so this is a trivial example; more complex cases present "challenges". If we were to change the guidance, we would have to advise inclusion of at least two instances of the repeated digits (thus, for example, 14.312828). Is that realistic? --𝕁𝕄𝔽 (talk) 09:55, 12 October 2023 (UTC)

Good question, and while you're here, as another UK editor, can you say anything about the UK use of overdots? It seems[23] they may still be part of the maths curriculum, rather than the overline. NebY (talk) 10:23, 12 October 2023 (UTC)

As a UK reader I've seen both. IIRC we were taught dots at school, but that was nearly half a century ago (and I know that in WP terms that is archaic and not worth bothering with). At degree level and at work I think the overbar came to prominence, but that may simply be an artefact of international publishing. Martin of Sheffield (talk) 10:33, 12 October 2023 (UTC)

The suggested change to require at least two instances of the repeated digits sounds good to me. Graham87 (talk) 12:28, 12 October 2023 (UTC)

I wouldn't change the MoS at this time. Currently it's silent about how exactly the overline is to be used, and that's probably the best course of action. In math contexts, repeating the digits twice would probably be confusing, and outside of math contexts, the overline is likely very rarely used anyway. The Inch use case seems a bit special and I don't think we should try to derive a general rule from it. The screen reader issue is surely annoying, but the best course of action may be to complain to the vendors about it. The overline is standard mathematical notation; if they don't support it, that's their fault, not ours. Gawaon (talk) 12:58, 12 October 2023 (UTC)

A resolution by screen reader vendors/makers would be years or even decades away. The overline is implemented as a CSS style and most of those are rightly ignored by screen readers unless the user tells them otherwise. Also see the "Screen readers do not update overnight" section (and others) from this blog post which is about memes but has some relevant points here. Graham87 (talk) 17:15, 12 October 2023 (UTC)

As the nutshell of Wikipedia:Manual of Style/Accessibility says, Wikipedia pages should be easy to navigate and read for people with disabilities. Managing accessibility isn't a matter of who we can blame, and it's not WP policy to leave the users of screen readers stranded between the shortcomings of the technology and a lack of understanding by editors.

There are other uses of {{overline}} such as for crystal classes in mineralogy, and some of the 2036 transclusions are in maths articles, but some are in more general articles such as other units of measurement, or coins. One Half farthing is stated in the infobox to be worth £0.00052083 (ie with a final overlined 3); I do wonder how many general readers recognise that at once not to mention whether WP:ENGVAR requires the use of a dot instead. I don't imagine we could give an all-encompassing rule, but we might in MOS:DECIMAL

• inform editors that users of screen readers won't hear any indication of an overline
• suggest truncating at reasonable resolution instead, outside of maths contexts, and/or
• suggest showing initial repeats, outside of maths contexts.

NebY (talk) 18:51, 12 October 2023 (UTC)

Sounds reasonable, I'm not opposed. Gawaon (talk) 07:33, 13 October 2023 (UTC)

I strongly support requiring rounding to sensible precision. In the example, the precision given is a schoolboy error when describing a real-world item. £1⁄1920 is "about £00052". 𝕁𝕄𝔽 (talk) 08:36, 13 October 2023 (UTC)

Thanks, all. I've edited MOS:DECIMAL accordingly, using the above examples. I've put it mildly (overbars may be used but consider rounding etc) but we could be stronger (eg saying rounding is preferred or making it imperative), and I expect the phrasing can be improved in other ways. NebY (talk) 16:36, 14 October 2023 (UTC)

Does this article assume that "the year 2023" contains a four-digit number?

"Numbers with exactly four digits left of the decimal point may optionally be grouped (either 1,250 or 1250), consistently within any given article."

The above quote from the article might be intended to imply that if an article contains "2023" for any reason, including because it means "the year 2023", all other four-digit numbers should be written without a comma. Full disclosure: I would like that because I think four-digit numbers should never be written with a comma.

Whether or not that is the case, I think the article should be clearer on this point. Does, according to this article, "the year 2023" contain a four-digit number? Polar Apposite (talk) 19:25, 21 October 2023 (UTC)

From MOS:DIGITS (last bullet point): "Four-digit page numbers and four-digit calendar years should never be grouped ...". So you can have 2,023 articles in a bag, but this year is always 2023. Martin of Sheffield (talk) 19:39, 21 October 2023 (UTC)

And it was kind of a silly question to begin with, since no one anywhere (including anywhere on WP) writes the current year as "2,023". Any time someone is looking for some kind of "Ah HA!" loophole in a guideline, that no one is actually exploiting, they are probably making a mistake. Iff someone is exploiting a wording loophole in a repetitively disruptive manner then, yes, it should be patched. But a style guide like MoS is not intended to cover every imaginable eventuality, the way a huge style guide like Chicago Manual of Style does, or ours would be just as enormous. It only exists to address recurrent, real style issues faced by editors. And "the year 2,023" isn't one. People editwarring to write "$1250" instead of "$1,250" or vice versa was such a problem and has been addressed. The fact that our OP here was (aside from being confused that the guideline is an article) actively looking for a loophole to exploit to get rid of all commas in 4-digit numbers everywhere is troubling.  — SMcCandlish ☏ ¢ 😼  13:42, 24 October 2023 (UTC)

Style: specifying units after defining variables?

I have a difference of opinion with someone who has contributed heavily to the article on Magnetic sail technology. The article frequently defines variables for use in equations, like ion mass and density, followed by a specification of units like "(kg)" or "(kg/m3)" etc. I find this misleading and inappropriate, as it suggests (to me) that the measured values must be measured in these units and no others. The other author says he is just announcing which units will be used in later examples using the variables, but that is not what "(kg)" necessarily means by itself; it seems very ambiguous and misleading when set next to the definition of a term. Indeed, this even is done in contexts quite distant from any examples, as in a listing of parameters, i.e., relevant factors, for defining a plasma, which include "the number of ions...per unit volume (m-3), the average mass of each ion type accounting for isotopes (kg)..." This seems odd to me, as the mere statement that the number of particles/ions per volume is relevant doesn't require the use of any particular units. The density is relevant whether the unit volume is m-3 or cm-3 or something else, as long as it's a volume denominator. Again, particular uses of this variable must use particular units, but the units used are irrelevant to a general discussion of what factors characterize a plasma.

It feels to me like talking about Newton's laws, and saying "F = ma where m is mass (kg) and a is acceleration (m/s2)". Now of course, if you're going to use an example, you must give specific units, and be consistent with their use. If you're saying the earth's force of gravity produces an acceleration of 9.8, you must follow this with m/s2; if you're talking about a specific apple's or asteroid's weight, you must specify this as X grams or Y trillion kg or whatever, and if this is used in a formula the other terms must be expressed in the same units, or one must be converted into the other.

But it does not seem appropriate to constantly say "(kg)" after, e.g., each mention of a new variable (for ion mass, for electron mass, for mass per unit volume, payload mass, etc.) This seems to both take up extra room and potentially mislead the reader.

I do not immediately see this issue addressed in the present article, but perhaps I am missing something. What do others think about this issue? Any particular instance of this may be relatively minor, but it seems like a strange style choice, one not made by most other articles using physics terms and formulas, and I would like to seek greater consistency on this.23:37, 13 October 2023 (UTC) ScottForschler (talk) 23:37, 13 October 2023 (UTC)

If the variable is defined apart from any example or equation, I don't think it is necessary to give units. You already agree for the need to give units if there is an example. I believe it is also necessary when an equation is given. Using F=ma as an example, this would be false if F were pounds force, m was pounds mass, and a was miles / (hour·second). Instead of giving units, one could state a coherent system of units must be used. But that introduces a level of abstraction that I don't think is ideal for a generalist publication like Wikipedia. Jc3s5h (talk) 00:00, 14 October 2023 (UTC) (Unit fixed per later discussion on 24 October 2023.)

"Instead of giving units, one could state a coherent system of units must be used. But that introduces a level of abstraction that I don't think is ideal for a generalist publication like Wikipedia."

I agree. I have found dozens of errors in equations in books and papers that do not give units along with the equation. Having the units stated (somewhere) enables dimensional analysis of the terms on both sides of an equation and helps identify and prevent such errors.

This also places an additional burden on the reader to determine what is a "coherent system of units." It is more straightforward to simply just state the units - without parentheses. Dmcdysan (talk) 04:35, 16 October 2023 (UTC)

I disagree; determining and sticking with a "coherent system of units" is not a burden to anyone with the most minimal competence in physics. If a reader doesn't know what a coherent system of units is, no short statement of units will be used is going to enlighten them, and an exhaustive explanation on every article mentioning a physics equation is "an undue level of abstraction" placing great burdens on both authors, and competent readers who have to wade through this ad nauseum. But I also don't see what's wrong with using parentheses around units to indicate that these are the ones to be used in general in a certain context, I only object to the idea that this indication is needed when no such general use follows immediately.ScottForschler (talk) 19:01, 16 October 2023 (UTC)

Sorry, I'm not following you. How would you explain to a person without a most minimal competence in physics a "coherent system of units?" Please use the F = m a equation as an example.

"I only object to the idea that this indication is needed when no such general use follows" I think we may be approaching agreement on this - I think that the current article has excessive and unnecessary replications of units. I recall proposing on our private Talk on this subject that units need only be mentioned once per article, section, (group) of equations, figure or table. Would this address your above comment?

Usage of parentheses raised a number of objections on this thread. I think the same thing can be done without parentheses.

An equation in general physics, and other mathematically based disciplines is inherently unitless. I don't see this as an inconsistency, just a different usage of mathematics. I will try to explain later with an example from the IEEE guidelines. Dmcdysan (talk) 00:45, 17 October 2023 (UTC)

I looked up Coherence (units of measurement)#List of coherent units) and all units there are listed in parentheses.

I had proposed that somewhere early in the magnetic sail that a statement indicating that coherent or derived SI units are used where defined and conversion from cgs units may be necessary for certain cited references.

I also proposed that units need only be mentioned once per article, section, (group) of equations, figure or table. This would drastically reduce the number of instances that units need be stated.

At some point, having the text mention the name(s) used in the article, section, equation (group) unit name; for example in the magnetic sail context:

Drag is a force Newtons (N).

Plasma mass density ρ (kg/m³)

A number of units in magnetic sail appear to not be defined in SI units. or have several options, and the following are widely used in magnetic sail cited references

Proton mass m_p Kilograms(kg)

ion mass m_i Kilograms(kg) for an ion with Atomic number Z_i

ion number density n_i (ions/m³)

Spitzer resistivity η_p Weber metre (W m)

The MOS style guide clearly states that units are to be used without parentheses when following numbers; however, it also states that "Units unfamiliar to general readers should be presented as a name–symbol pair on first use, linking the unit name (Energies rose from 2.3 megaelectronvolts (MeV) to 6 MeV)." puts general(units) in parentheses, using a similar style to that of the SI units given above. Is that acceptable to the experts on this thread?

I want to have a clear consensus before going through the article and making changes, and I believe that the usage of parentheses is allowed when the units do not follow numbers. How does a consensus process work here? What is the range of time needed? This is not an urgent issue, but I will not start any major editing until I get feedback. I also plan to study the MOS and make other necessary changes as I progress through each section.

I also have two other formatting issues suggested by another editor that appear appropriate to discuss here that I will place in a separate topic. I would like to have consensus on all of these subjects before doing an editing pass through the entire article, where I also plan to also add some clarifying text to make the article more accessible to readers without having to understand the equations.

Questions, comments?

Thank you in advance for your support in making Wikipedia a consistently formatted encyclopedia! Dmcdysan (talk) 20:43, 18 October 2023 (UTC)

Don't forget coherent. EEng 22:27, 18 October 2023 (UTC)

Not sure I understand your comment - does the following proposed wording address it? If not, please clarify.

"proposed somewhere early in the magnetic sail (article) that a statement indicating that coherent or derived SI units are used where defined and conversion from cgs units may be necessary for certain cited references." Dmcdysan (talk) 23:25, 18 October 2023 (UTC)

"If the variable is defined apart from any example or equation, I don't think it is necessary to give units." I agree with this as well. I still have a question of whether units should be used when referring to a figure or table.

For example, If the axes in a Figure are F and an and m is a parameter for multiple curves in the Figure (for which no dimension is given to not clutter up the graph.) Which would be the preferred style:

"Figure foo plots force F N versus acceleration a m/s^2 with mass m kg as a parameter for the multiple curves."

OR

"Figure foo plots force F versus acceleration a with mass m kg as a parameter for the multiple curves." Since units for F and a are given on the Figure axes. Dmcdysan (talk) 04:39, 16 October 2023 (UTC)

Of course units should be given for tables with specific numbers therein, or graphs for that matter, that was never any part of my objection. I'm not sure I quite grasp your two options as listed--the grammar of your explanation and offered options seems confusing to me. But I don't see why it matters much where the units are mentioned, as long as they are either on or near the figure.ScottForschler (talk) 19:09, 16 October 2023 (UTC)

This is a minor formatting question. If the units are on the figure/table should they be repeated in the associated text, or left out of the text. I prefer repeating them in the text in the first example

"Figure foo plots force F N versus acceleration a m/s^2 with mass m kg as a parameter for the multiple curves."

The second example removed the bold faced units. Dmcdysan (talk) 00:51, 17 October 2023 (UTC)

I just took a look at the article. The use of units in brackets adds unnecessary clutter and distracts the reader's attention away from what matters (the concept or the equation). There might be some rare exceptions, but in general the unit belongs with numerical examples only. Dondervogel 2 (talk) 06:52, 14 October 2023 (UTC)

It's not merely superfluous to provide units for the variables when all the values employed are not merely in coherent units but specifically in SI units, their provision in brackets makes formulae and expressions ambiguous puzzles ("$M_{c}(min)$") - are these variables in the formula or units extraneous to it? It is also emphatically wrong to provide values with units in parentheses ("has a mass density of 3,500 (kg/m3)", "$J_{e}$=10¹¹ (A/m²), $r_{sc}$= 5 mm, $\rho _{sc}$=6,500 (kg/m³)"), whether done consistently or in this case, wildly inconsistently; see MOS:UNITS, the SI brochure , or any textbooks, standards, or publications of NIST, IEEE, etc. NebY (talk) 09:57, 14 October 2023 (UTC)

In the formula M_c(min) the "min" indicates the minimum valued is not a unit. I agree with removing parentheses around units when used with numerical values, this is not done consistently in the article. Dmcdysan (talk) 23:30, 15 October 2023 (UTC)

I was not aware of the MOS:units link and I will modify the Magnetic sail article to match this style (i.e., remove all parentheses and fix other style conventions in one pass. Thank you!

A few more related questions:

For an equation for M_c(min) that you said was ambiguous, where the subscript c already has other meaning so that min can't be used as a subscript and without defining another variable. Would the notation _minM_c be preferable? I could not find this in Wikipedia:Manual of Style/Mathematics

When a variable B_u and units T (Tesla, not in the MOS:Units guide) on as axis title in a Figure, should this be done with or without parentheses, For example "B_a T" versus "B_a (T)." I did not find this in MOS:Units or Wikipedia:Manual of Style/Mathematics.

Similar questions for units in Table column headers: "The values for the equation R_a B_a = R_u B_u are shown in the Table foo." The Table column headers without parentheses would be "|R_a m | B_a T | R_u m | B_u T|" which looks odd to me. "|R_a (m) | B_a (T) | R_u (m) | B_u (T)|"

Many technical papers put the units for Figures axis titles and Table column headers in parentheses. If there is a style guide for this, I could not find it and if one exists if you could help me find it that would be much appreciated. If there is not a style guide covering this, then I suggest there should be. Dmcdysan (talk) 02:33, 16 October 2023 (UTC)

"It's not merely superfluous to provide units for the variables when all the values employed are not merely in coherent units"

How are the "coherent units" communicated to the reader?

Many publications have a Table with the variable names, a brief description and units as columns, which in my opinion is acceptable, but I prefer the units spelled out upon first use in an equation if they are used consistently in an entire article, sections, or subsequent equations, a plot in a Figure, or Table. Dmcdysan (talk) 04:53, 16 October 2023 (UTC)

From https://mentor.ieee.org/myproject/Public/mytools/draft/styleman.pdf

15.1 Letter symbols and units

Letter symbols defined in applicable IEEE standards (see Clause 2) should be used in preparing mathematical expressions. (See 14.4 for a discussion of letter symbols.)

All terms shall be defined, including both quantities and units, in a tabulation following the equation [see Equation (1)]. The list should be preceded by the word where, followed by the list of variables and corresponding definitions. See 4.5 in Annex B for an example.

The Dipole#Field of a static magnetic dipole equation format is an example of following this standard.

Instead of inventing a new style for Wikipedia, I suggest that an existing technical document standard, such as IEEE be used.

I didn't see answers to my questions regarding Figure and Tables in this document. Dmcdysan (talk) 06:01, 16 October 2023 (UTC)

I see that you deleted all units in parentheses, that saves me from having to do it, but loses some information. At least the plasma specific variables need units on first use using the NRL formulary. I interpret your comment that further copy editing is needed to add formatting from MOS as mentioned on this thread; specifically only mention units with the spelled out SI (or NRL) unit name (as described in MOS) and the abbreviation in the minimum number of places, preferable only once. Here is an example where I did this requiring changing the unit name to align with SI units (it was ambiguous), giving the spelled unit name (and abbreviation) only once for the entire article. A similar change would help clarify the H magnetic field strength and others terms there.

https://en.wiki.x.io/w/index.php?title=Biot%E2%80%93Savart_law&diff=1181066530&oldid=1180834647

I think a similar style can be used for much of the magnetic sail article only mention the unit name as a wikilink and (abbreviation) only once. Will see if there is any feedback there before proceeding on magnetic sail.

BTW, I like the way your formatted units to a separate column in the table and that addresses one of my questions.

In the Biot-Savart article is also a style suggested by constant314 for referencing a specific chapter, section, equation for a citation in a more compact way than done in magnetic sail, and I plan to use that in my editing pass that also should reduce clutter. Dmcdysan (talk) 17:12, 20 October 2023 (UTC)

I see you've reinserted many of the improperly placed units that I'd removed, then tagged the article as under construction so as to make yourself the only one editing the article, and have edited the article and the talk page using two accounts, Dmcdysan and Sumlif2. You do not have consensus for the placing of those units, you're ignoring what multiple editors are telling you here, and you're giving the impression that you have support for your stances. Have you read WP:IDHT, WP:OWN and WP:SOCK? NebY (talk) 18:35, 22 October 2023 (UTC)

Aloha Neby,

It was not my intent to disguise my edits, I wanted to anonymize dmcdysan and that is why I created the Sumlif2 account and sometimes I was logged into both. dmcdysan is the only account making these edits now, so I am complying with the WP:SOCK and WP:IDHT policies.

I disagree with your assertion "then tagged the article as under construction so as to make yourself the only one editing the article,"

If you read the Template:Under construction and the displayed notice "You are welcome to assist in its construction by editing it as well."

In response to a discussion with ScottForschler I am doing a major reorganization and addition of higher level summary material and have consistently inserted and removed the In Use template at the beginning and end of an extended editing session. I do not believe that I am violating the WP:OWN policy. Several times during an editing session I have received a server conflict error, possibly due to an editing conflict and I had to reenter information. Please do not edit while the inuse message is displayed to avoid this.

I disagree with your assertion: "I see you've reinserted many of the improperly placed units that I'd removed,"

I have cited several passages from the MOS guide that contradict your statement that the unit usage is improper - have your read them?

Also, not all editors agreed with your assertion and you have not provided an IEEE guideline to support your position. I provided one that contradicts your statement and described how a number of reliable sources use units in this way and in order to comply with Wikipedia:NOR policy of verifiability and summarizing the units usage of the reliable source is appropriate and supported on

I agreed with deleting all units in parentheses and thanked you for doing that. I also stated that I liked your Table formatting.

I cited the following example from Wikipedia MOS, Units of measurement

• "Units unfamiliar to general readers should be presented as a name–symbol pair on first use, linking the unit name (Energies were originally 2.3 megaelectronvolts (MeV), but were eventually 6 MeV)."

I claim that the formatting method you and several others advocated is in conflict with this guideline.

Using this MOS guidleine I reinserted items only when it is giving a name, with URL if available, for a specific SI unit and its (abbreviation) upon first use. As I go through the article, I am deleting some of those instances I reinserted to be consistent with this guideline.

As an example, I made a change to the Biot-Savart law article following this guidleline

https://en.wiki.x.io/w/index.php?title=Biot%E2%80%93Savart_law&diff=1181066530&oldid=1180834647

The name "magnetic field" is ambiguous and not an SI unit name and I applied the above MOS policy.

I believe some of what you did conflict with this policy. Please stop making changes to avoid Wikipedia:Disruptive editing which for the reasons stated above I believe that I am not doing. In that spirit, have you read my posts? If not, please do so in order to be constructive.

Thank you. Dmcdysan (talk) 19:42, 22 October 2023 (UTC)

Here's another example where parentheses are used. I am currently editing and using the Wikipedia MOS, Units of measurement style. Note that this article uses the IEEE equation style I quoted, which I believe makes the article longer than necessary. I prefer the in-line style, and could not find a mention of this in the MOS. IMHO that would be a useful addition. Dmcdysan (talk) 20:40, 22 October 2023 (UTC)

Regarding https://en.wiki.x.io/w/index.php?title=Wikipedia_talk:Manual_of_Style/Dates_and_numbers&diff=prev&oldid=1181382683

I don't follow your reply "Dmcdysan, you're not listening." Have you read my prior reply? I responded to each of your points and I read and replied to your original post. Please be specific as to what I am "not listening" to. It appears to me that you are not following WP:LISTEN while I believe that I have demonstrated that I am.

I believe the substantive comment relates to Wikipedia MOS, Units of measurement, and your proposal and that of several others are in contradiction with that. It appears that you disagree with the quoted MOS guideline. Please be specific in your response, because I believe this is an objective, constructive way to address this issue.

"If the variable is defined apart from any example or equation, I don't think it is necessary to give units. You already agree for the need to give units if there is an example. I believe it is also necessary when an equation is given. Using F=ma as an example, this would be false if F were pounds force, m was pounds mass, and a was miles per hour. Instead of giving units, one could state a coherent system of units must be used. But that introduces a level of abstraction that I don't think is ideal for a generalist publication like Wikipedia. Jc3s5h (talk) 00:00, 14 October 2023 (UTC)[reply]"

expressed an opinion that differs from your proposal.

In a private Talk with ScottForschler he also agreed with Jc3s5h, but other matters may keep him from responding soon.

When you respond, please follow the guidelines in Wikipedia:Civility. While doing other editing I found a few instances of parentheses that I deleted and also removed more units that were not necessary since a first instance had occurred per Wikipedia MOS, Units of measurement. Dmcdysan (talk) 21:53, 22 October 2023 (UTC)

From User talk:ScottForschler/Archive 1

IN ANSWER TO YOUR QUESTION in Wikipedia talk:Manual of Style/Dates and numbers

"The article frequently defines variables for use in equations, like ion mass and density, followed by a specification of units like "(kg)" or "(kg/m3)" etc"

USING THE FOLLOWING GUIDANCE.

"If the variable is defined apart from any example or equation, I don't think it is necessary to give units.You already agree for the need to give units if there is an example. I believe it is also necessary when an equation is given. Using F=ma as an example, this would be false if F were pounds force, m was pounds mass, and a was miles per hour. Instead of giving units, one could state a coherent system of units must be used. But that introduces a level of abstraction that I don't think is ideal for a generalist publication like Wikipedia. Jc3s5h (talk) 00:00, 14 October 2023 (UTC)"[reply]

I agree with this, do you?

Would this address your concern if there is consensus in the Manual of Style Talk thread? Dmcdysan (talk) 00:24, 16 October 2023 (UTC)[reply]

"[...] Jc3s5h (talk) 00:00, 14 October 2023 (UTC)"

I agree with this, do you?

Of course.ScottForschler (talk) 20:30, 16 October 2023 (UTC) The"[...]" was entered by ScottForschler to only capture text relevant to this point.

By my count two additional people agree with Jc3s5h (Dmcdysan and ScottForschler) while only one additional person agrees with the NebY (talk) 09:57, 14 October 2023 (UTC) position ((Dondervogel 2 (talk) 06:52, 14 October 2023 (UTC). I don't interpret this as consensus.

ScottForschler and I successfully used the Wikipedia:BOLD, revert, discuss cycle to resolve several contentious issues, and I believe have now agreed to work together cooperatively.

I believe we are in the discuss part of the BRD cycle. I am open to using an alternative before trying Wikipedia:Dispute resolution as described there. Please read these recommendations and let us know how you wish to proceed. Dmcdysan (talk) 15:47, 23 October 2023 (UTC)

From NebY (talk) 09:57, 14 October 2023 (UTC)

"provision in brackets makes formulae and expressions ambiguous puzzles ("$M_{c}(min)$") - are these variables in the formula or units extraneous to it?"

From Dmcdysan (talk) 04:53, 16 October 2023 (UTC)

For an equation for M_c(min) that you said was ambiguous, where the subscript c already has other meaning so that min can't be used as a subscript and without defining another variable. Would the notation _minM_c be preferable? I could not find this in Wikipedia:Manual of Style/Mathematics

In order to advance the BRD discussion, I made the above change to the Magnetic sail#Coil mass and current (CMC) section where I had previously accepted most(if not all) of your edits and applied the Wikipedia:Manual of Style#Units of measurement in one instance and other MOS guidance.

How does this look to people on this thread? Dmcdysan (talk) 16:32, 23 October 2023 (UTC)

Another style commonly used is an example such as the following:

Dipole#Field of a static magnetic dipole

The far-field strength, B, of a dipole magnetic field is given by

$B(m,r,\lambda )={\frac {\mu _{0}}{4\pi }}{\frac {m}{r^{3}}}{\sqrt {1+3\sin ^{2}(\lambda )}}\,,$

where

B is the strength of the field, measured in teslas

r is the distance from the center, measured in metres

λ is the magnetic latitude (equal to 90° − θ) where θ is the magnetic colatitude, measured in radians or degrees from the dipole axis

m is the dipole moment, measured in ampere-square metres or joules per tesla

μ₀ is the permeability of free space, measured in henries per metre.

In my opinion, this more readable than a table. It avoids ambiguity. If the article just gave the equation and names of the variables and sited that coherent SI units are to be used, then how does the reader determine the appropriate units? Dmcdysan (talk) 05:10, 16 October 2023 (UTC)

Here is another way that units are used specific to magnetic sail:

https://en.wiki.x.io/wiki/Plasma_parameters

and the NRL plasma formulary https://library.psfc.mit.edu/catalog/online_pubs/NRL_FORMULARY_19.pdf

which gives units for individual variables, conversions between unit systems (e.g., could be used to convert the Wikipedia article from cgs to SI).

It also has theoretical plasma physics equations, which like other theoretical physics equations, are unitless because the functions are just mathematical abstractions that do not have a direct physical interpretation. To assign numbers to theoretical (plasma) physics equations requires specification of units and then assignment of values according to the units to give the equation physical meaning.

A principal goal of the magnetic sail article is to assign numbers to theoretical equations and hence specification of units is necessary. I believe this is true in general. Dmcdysan (talk) 08:28, 16 October 2023 (UTC)

Jc3s5h (talk) 00:00, 14 October 2023 (UTC) wrote "You already agree for the need to give units if there is an example. I believe it is also necessary when an equation is given."

I agree.

I would state the example relevant to the specific point made by ScottForschler (talk) 23:37, 13 October 2023 (UTC) as follows: "When Force F is expressed in Newtons (N), as done in most references cited in this article, then in the formula F = m a, a consistent set of (units) are m is mass (kg) and a is acceleration (m/s^2).

This need only be stated at the beginning of an article (as in the above example), section, (group) of equations, a figure or table.

This would avoid repetition of units in *many) other places as in the current Magnetic sail article. In the above style I believe the phrasing (units) pairs with the parenthesized (unit expression), or the parentheses could be removed. I have seen both styles used in technical papers, I prefer the parentheses but will conform to whatever consensus is reached regarding the Manual of Style. Dmcdysan (talk) 23:49, 15 October 2023 (UTC)

This increases my suspicion that you were in fact modeling the units style after that used in technical papers. But these have very different, and much narrower, purposes than a general encyclopedia article does. I am glad we are coming closer to agreement on this.ScottForschler (talk) 19:14, 16 October 2023 (UTC)

Yes, I interpret Using Sources below to include the use of units for variables or equations as used in the source or required by the reliable source publisher. I believe this has precedence over a formatting style as discussed here. However, I plan to go through the article and use the style guide and our discussion to remove excessive usage of (units), as well as parentheses and only introduce units as little as needed, as I understand your comments. I believe keeping a small subset of the equations helps verifiability, but I plan to pay close attention to those that you found confusing and either add or clarify additional text, and possibly remove some equations. However, renumbering and changing the cross references is a manually intensive process with the current state of Wikipedia technology and that disincentivizes me from doing this. The cited references have many equations and the summarization reflects the same style.

"Wikipedia is fundamentally built on research that has been collected and organized from reliable sources, as described in content policies such as this one. If no reliable independent sources can be found on a topic, Wikipedia should not have an article about it. If you discover something new, Wikipedia is not the place to announce such a discovery.

The best practice is to research the most reliable sources on the topic and summarize what they say in your own words, with each statement in the article being verifiable in a source that makes that statement explicitly. Source material should be carefully summarized or rephrased without changing its meaning or implication. Take care not to go beyond what the sources express or to use them in ways inconsistent with the intention of the source, such as using material out of context. In short, stick to the sources." Dmcdysan (talk) 01:32, 17 October 2023 (UTC)

This seems pretty simple to me: Don't specify units when giving a principle that is actually unit-agnostic, since doing so confuses the reader about whether the principle is unit-agnostic. Do specify units when providing examples, if the unit is likely to help the reader understand the example (which is probably going to be the case with most examples).  — SMcCandlish ☏ ¢ 😼  23:08, 23 October 2023 (UTC)

By "principle" do you mean "equation?" What is being discussed here is whether variables in equations should have units associated with them.

Please further describe "unit agnostic." Use the equation F = m a as an example as described by the originator of this thread. Dmcdysan (talk) 06:19, 24 October 2023 (UTC)

A statement of principle certainly might be an equation (but could also be written out in words), while an equation (with specific values in place of variables) might also be used in an example. I'm not sure I see any point in being terminologically reductive about this, when my entire point is to apply common sense generally. F = ma is a simple equation that provides the principle (which could also be provided in words such as "force equals mass times acceleration"), and needs no units; it is unit-agnostic, and adding units to it would be confusing. It is not an example with values substituted in for variables and thus probably needing units to make sense to the average reader, e.g F = (20 kg)(5 m/s²) or whatever. Cf. Trovatore below: "units should not appear with variables, because the variables denote physical quantities that can be expressed in different units". Maybe try to approach this less from a "mathematician with jargon preferences" viewpoint, and more from a "what should readers experience and what should editors do" viewpoint.  — SMcCandlish ☏ ¢ 😼  12:41, 24 October 2023 (UTC)

It's not the mathematicians who want to put inappropriate specific units in general equations; "F = ma where m is mass (kg) and a is acceleration (m/s2)." is something no mathematician would write, and I doubt that many physicsts would either. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:17, 24 October 2023 (UTC)

Indeed. Instead, in Magnetic sail, on which Dmcdysan has been working intensively, we have for example A plasma environment has fundamental parameters, and if a cited reference uses cgs units these should be converted to SI units as defined in the NRL plasma formulary, which this article uses as a reference for plasma parameter units not defined in SI units. Symbolically, the major parameters for plasma mass density are: the number of ions of type $i$: $n_{i}$ per cubic metre (m^-3), the mass of each ion type accounting for isotopes $m_{i}$ kilogram (kg), and the number of electrons $n_{e}$ m^-3 each with electron mass $m_{e}$ kg. An average plasma mass density per unit volume for charged particles in a plasma environment $pe$ ($sw$ for stellar wind, $pi$ for planetary ionosphere, $im$ for interstellar medium) is given by the following to be specific about the meaning of an averaged mass density for charged particles $\textstyle \rho _{pe}=n_{e}m_{e}+\sum _{i}n_{i}m_{i}$ kilogram per cubic metre (kg/m³), which this article also uses for conversion of other units to the SI units. NebY (talk) 15:33, 24 October 2023 (UTC)

I cited the following example from Wikipedia MOS, Units of measurement

• "Units unfamiliar to general readers should be presented as a name–symbol pair on first use, linking the unit name (Energies were originally 2.3 megaelectronvolts (MeV), but were eventually 6 MeV)."

I have been following this consistently and only doing it upon first instance as suggested above. I have been creating numerical examples in line instead of mentioning the units next to a variable again in the article. I carefully went through the article and then only used the abbreviation following a number. I believe that it should be left to the editor's choice where to first insert the guidance from Wikipedia MOS, Units of measurement in order to best make the summary verifiable to a reliable source per Wikipedia:NOR

Here is another example that shows another Wikipedia page using units with variables Magnetic moment#Units. I believe this conforms to the MOS bullet I mentioned above. How does this usage look to everyone?

If this looks OK, I can rewrite the above from magnetic sail to match that style. I believe this would also resolve the number of comments relating to usage of coherent and derived SI unitsas well as the usage of "Named unit derived from SI base units" from SI derived unit, which the magnetic moment article section named above does cover. Dmcdysan (talk) 16:07, 24 October 2023 (UTC)

Does this change address your concern?

https://en.wiki.x.io/w/index.php?title=Magnetic_sail&diff=1181715942&oldid=1181699144 Dmcdysan (talk) 19:53, 24 October 2023 (UTC)

Here is a counter example of usage of units with variables Magnetic moment#Units. This is an article to which the Magnetic sail article links. Many other Wikipedia pages that I have mentioned on this thread use a similar style. Dmcdysan (talk) 16:10, 24 October 2023 (UTC)

"is something no mathematician would write" - Yeah, it does seem unhelpful and weirdly specific. Would make much more sense to give the general equation followed by an example with values and units.  — SMcCandlish ☏ ¢ 😼  01:44, 25 October 2023 (UTC)

I haven't read the above in detail, but I think there's a fundamental misunderstanding on one side of it. Here is the point: A physical quantity has dimensions. It does not have units. For example, if a certain rod is 1 meter long, then its length is a physical quantity, and it has dimensions of length.

But the quantity itself, the thing represented by a variable, does not intrinsically have units. It is equal to 1 meter, and it is also equal to ${\frac {1}{0.0254}}$ inches, and those are just two different ways of representing the same quantity.

The bottom line is that units should not appear with variables, because the variables denote physical quantities that can be expressed in different units. The units should appear only when you express the quantity with a number technically numeral, but I'm already over my pedant quota for this post. --Trovatore (talk) 00:05, 24 October 2023 (UTC)

Do you mean this by dimensions? If so, your statements "A physical quantity has dimensions" and "dimensions of length" are inconsistent with this definition. Did you mean something else? I cannot comment without further clarification. Also, please provide a definition of "physical quantity" and how it has "dimensions," using the Wikipedia definition linked above. Without these clarifications I cannot comment on your example.

Your point appears similar to the original poster that different units can be used for variables in an equation, which differs from your conclusion that "units should never appear with variables," which I cannot verify because your definitions are not clear.

Use the equation F = m a, as an example as described by the originator of this thread and several other posts, in particular the following:

"If the variable is defined apart from any example or equation, I don't think it is necessary to give units. You already agree for the need to give units if there is an example. I believe it is also necessary when an equation is given. Using F=ma as an example, this would be false if F were pounds force, m was pounds mass, and a was miles per hour. Instead of giving units, one could state a coherent system of units must be used. But that introduces a level of abstraction that I don't think is ideal for a generalist publication like Wikipedia. Jc3s5h (talk) 00:00, 14 October 2023 (UTC)"

I agree with the above, except for the first sentence. I provided a number of examples where a variable is defined apart from an equation as evidenced by usage in reliable sources of an IEEE requirement to state units for all variables in an equation, technical journals that require inclusion of a table mapping variable name to descriptive name to units, the common practice by many text books to include an table of this form., and the NRL plasma formulary. Dmcdysan (talk) 06:34, 24 October 2023 (UTC)

No, I mean dimensions in the sense of dimensional analysis. Length is a dimension; the meter and the inch and the furlong and the Roman league are units of length. Mass is a dimension; the kilogram and the Troy ounce are units of mass. A particular spherical nugget of gold has a diameter, which has dimensions of length, and a mass, which has dimensions of mass, but neither of these has any intrinsic units.

The diameter and the mass of a nugget are the sorts of things you would put variables for, and these variables represent physical quantities, which have dimensions but not inherent units.

Finally, let's take Jc3s5h's remark above. I'm going to assume Jc3s5h meant something other than "miles per hour" for a, because that's not a unit of acceleration — let's make it miles per hour per second, which is something in human experience (if I go from zero to sixty in 5 seconds, my average acceleration was 12 miles per hour per second).

In fact $F=ma$, contrary to Jc3s5h's assertion, is still true with these units. Because F and m and a are not numbers; they are non-dimensionless physical quantities, which are numbers times units, and when you put those in it all works out. If my car weighs 2000 lbm, and I accelerate it at 12 miles per hour per second, that means that a net force of 24000 lbm·miles/(hours·seconds) is acting on it. That's a quantity that has dimensions of mass times length over time², so it's a perfectly valid force, which means it's a possible value for F. Now, it's true that that doesn't tell you immediately what F is in terms of pounds-force. To figure that out, you have to multiply it by 1, where you rewrite 1 as some dimensionless real constant (I'm not going to bother to figure out which one) times ${\frac {{\textrm {lbf}}\times {\textrm {hour}}\times {\textrm {second}}}{{\textrm {lbm}}\times {\textrm {mile}}}}$. That cancels out the units you had and leaves an expression in terms of lbf, but you didn't change the value of F at all — you just multiplied it by 1, which doesn't do anything. So $F=ma$ is still valid, even if you're using these funky units, because F and m and a don't have units at all; the units only come in when you want to express them as numbers. --Trovatore (talk) 08:08, 24 October 2023 (UTC)

I thought dimensional analysis might have been what you meant, thank you for the clarification and usage of specific terms mentioned there.

I disagree with this statement "the units only come in when you want to express them as numbers"

Because by stating that F is a force you have implicit identified the unit as Name=newton Symbol=N since it is an entry in the table "Named unit derived from SI base units" SI derived unit. This applies whether the mention is a number or a variable in an equation.

I cited the following example from Wikipedia MOS, Units of measurement

• "Units unfamiliar to general readers should be presented as a name–symbol pair on first use, linking the unit name (Energies were originally 2.3 megaelectronvolts (MeV), but were eventually 6 MeV)."

I have been following this consistently.

Here is another example that shows another Wikipedia page using units with variables Magnetic moment#Units. I believe this conforms to the MOS bullet I mentioned above. How would editors revise this page? Dmcdysan (talk) 15:53, 24 October 2023 (UTC)

You say "F is a force you have implicit identified the unit as Name=newton Symbol=N". Sorry, that's false. Force is a concept from physics; the newton is a concept from SI. You have to understand that physics doesn't know anything about SI. Physics is fundamental; SI is not.

Look, this is not to say we shouldn't use SI, when we need units. It's a generally well-thought-out system and it's the worldwide standard. But it's not part of physics per se, and expositions of physics should not be presented in an SI-specific fashion (or in a fashion specific to any system of units). When you have a variable you should not be using units, because the variable represents a quantity that does not have units, just dimensions. --Trovatore (talk) 17:13, 24 October 2023 (UTC)

By the way, I just followed your link to Magnetic moment#Units, and I do not in fact see any units being used with variables there. --Trovatore (talk) 17:56, 24 October 2023 (UTC)

You said there were units associated with variables in that text. I do not see any variables there at all, with or without units. --Trovatore (talk) 18:46, 24 October 2023 (UTC)

OK, I see your point now, there is a level of indirection between "magnetic moment" as a physical quantity and the units used to describe it. In the definition section the magnetic moment variable m is defined and then the Units section begins "The unit for magnetic moment in International System of Units (SI) base units is A⋅m2"

From physical quantity "For example, the physical quantity mass, symbol m, can be quantified as m=n kg, where n is the numerical value and kg is the unit symbol (for kilogram)."

Let me make a revision to the section Neby quoted and post a diff to see if I have it now. I would really like to resolve this soon if possible so that I can get back to content editing. Dmcdysan (talk) 19:35, 24 October 2023 (UTC)

OK, here is the diff:

https://en.wiki.x.io/w/index.php?title=Magnetic_sail&diff=1181715942&oldid=1181699144

Does this address your concern? Dmcdysan (talk) 19:52, 24 October 2023 (UTC)

I replied on your talk page with the following and added some additional comments below - probably becoming obvious that I am a relative newbie, correct? 8)

Here is the linked text.

=== Units ===

The unit for magnetic moment in International System of Units (SI) base units is A⋅m², where A is ampere (SI base unit of current) and m is meter (SI base unit of distance). This unit has equivalents in other SI derived units including:

$$\mathrm {A\cdot m^{2}} ={\frac {\mathrm {N\cdot m} }{\mathrm {T} }}={\frac {\mathrm {J} }{\mathrm {T} }},$$

where N is newton (SI derived unit of force), T is tesla (SI derived unit of magnetic flux density), and J is joule (SI derived unit of energy). Although torque (N·m) and energy (J) are dimensionally equivalent, torques are never expressed in units of energy.

Thank you for taking the time to explain your answer more fully. I agree that the example from Jc3s5H had inconsistent units. Now that you clarified that you meant dimensional analysis and not dimensions and used that terminology, I agree with those points. Using dimensional analysis to check equations in papers and books and have found a number of errors using this method.

However, never mentioning a unit associated with a variable is contrary to many Wikipedia articles, IEEE requirements and the style used in many cited references, and likely a requirement for publication in others. The

I made another pass an believe that the magnetic sail article links to many other articles that use units with variables, and only a few do not. If this is to be changed, it is much larger than a single article. Dmcdysan (talk) 19:27, 24 October 2023 (UTC)

@Dmcdysan: This discussion is getting silly and you are wasting editors' time. Please read the careful analysis written by Trovatore, and return to the discussion once you understand the difference between the dimensions of a quantity (e.g., L T^-2 as dimensions of acceleration) and the unit used to convey a numerical value of the same quantity (e.g., gal, m/s^2 or fathom per fortnight squared). Dondervogel 2 (talk) 12:02, 24 October 2023 (UTC)

I agree. Here is another example of the usage of units upon first mention that are used in a number of Wikipedia articles Magnetic field.

I have gone through the article and tried to match this style.

Can some cite a reliable source that states that something along the lines that "units are never to be mentioned next to a variable?"

Neby claimed that the IEEE has this as a policy and I cited a reliable source that contradicted his statement. I admitted to having used that style. Neby went through removing parentheses and all units not associated with a number. I went back and inserted a limited number of instances using the MOS style upon first use and trying to match the style in a more compact manner similar to that of Wikipedia articles to which Magnetic sail links.

All I see is people stating their opinion, which according to Wikipedia:NOR is acceptable on a Talk page.

I have gone through the article and tried to align with the MOS guideline and the examples given.

Can we stop discussion on this thread and show Wikipedia:Assume good faith as stated on the first line of the box of this Talk page that I will align the magnetic sail article with the quoted MOS guideline and the examples that I have given? Dmcdysan (talk) 16:24, 24 October 2023 (UTC)

As a demonstration of my good faith efforts to align with the above interpretation of style I made another pass, finding a few stray unnecessary units and making some corrections to align with SI units in a linked Wikipedia page as follows:

https://en.wiki.x.io/w/index.php?title=Magnetic_sail&diff=1181699144&oldid=1181610992

While doing so, I found the following for Wikipedia pages linked to by [Magnetic sail]:

Pages that use units next to equation variable:

Biot–Savart law

Dipole#Field of a static magnetic dipole

Magnetic field

Lorentz Force

Vacuum permeability

Ram pressure, Pressure

Power (physics)

Magnetic moment#Units

Ampere

Rotational frequency

Definition of the resonant frequency that links to Rotational frequency

Resistivity

Pages that do not use units next to equation variable:

Specific impulse

Magnetic dipole

Pages that use units only next to a number, but multiple unit choices are available and I plan to state the SI unit choice (kg) only upon the first instance

Electron mass

Proton mass

I have to tried to consistently follow the style of those Pages that use units next to an equation variable only in the first instance per MOS guideline and then only use units next to a number. I hope this is acceptable to everyone and we can close this thread. Dmcdysan (talk) 18:03, 24 October 2023 (UTC)

It occurs to me that I may have somewhat misunderstood what is practically at issue here. I think it's OK, when there's an equation involving lots of quantities, particularly if they're unusual ones like magnetic inductance, to give a little list afterwards saying what SI units the quantities are measured in. That can be useful. I just saw people saying things (possibly just imprecisely worded) that suggested that they thought that the units were naturally part of the quantities themselves, or that SI had some special non-arbitrary status. That's a deep conceptual error, but possibly one that no one was actually making. --Trovatore (talk) 19:12, 24 October 2023 (UTC)

Cross posting this in reply - I think that I get your point now and looking back at the examples I cited, I was skipping a level of indirection. Here is a diff of what I did to the paragraph that Neby quoted. Does this address the concerns expressed in this thread?

https://en.wiki.x.io/w/index.php?title=Magnetic_sail&diff=1181715942&oldid=1181699144

I am going to mark the entire article as "In use" now because I will be moving text around between multiple sections. I won't touch anything regarding units, which I believe is internally consistent (but may require a change as that above). If there is agreement that the above change addresses the concerns, I believe this would be a relatively easy change to make. I will check back here tomorrow if there is agreement regarding this type of edit. Dmcdysan (talk) 20:02, 24 October 2023 (UTC)

References

References

Gram per cubic centimetre

There is some disagreement about the meaning of "gram per cubic centimetre" and "kilogram per cubic metre". Editors are invited to comment at the g/cm^3 talk page. Dondervogel 2 (talk) 13:49, 27 October 2023 (UTC)

Lead mention that a player is a free agent

There is currently a discussion underway at Talk:Colt McCoy § Free agent on how (whether?) to mention that a player is currently a free agent. Feel free to join. Paradoctor (talk) 20:51, 24 October 2023 (UTC)

This seems to be a MOS:DATED matter. I wasn't sure at first how this was relevant, but that seems to be it.  — SMcCandlish ☏ ¢ 😼  01:46, 25 October 2023 (UTC)

That is correct. Sorry for having been unclear. Paradoctor (talk) 02:06, 25 October 2023 (UTC)

Wait... Wouldn't DATED be more appropos Colt McCoy#Personal life? EEng 02:08, 19 November 2023 (UTC)

ISBN RfC

Resolved

 – Already closed (as no consensus).

Please see: Wikipedia:Village pump (policy)#RfC: Standardizing ISBN formatting (and an end to editwarring about it)  — SMcCandlish ☏ ¢ 😼  07:08, 31 October 2023 (UTC)

Date format for non-English speaking country

In Nintendo article, IceWelder changed its use of mdy dates in late September 2016 without consensus. The article has evolved using predominantly the mdy date format (since early January 2005, and here's first major contribution or first person to insert a date), and IceWelder's edit appears to have violate MOS:DATERET. IceWelder claims that consensus is needed for change as there has been implicit consensus for 7 years (for more information, see User talk: IceWelder). However, no matter how much time passes, it is not fair to say that the consensus on the date format change was achieved solely through observation alone, without any discussion.

My main question is whether consensus is needed to change this to mdy. I don't think this needs consensus. The reason IceWelder changed the date format was not clear, and even if it was clear, it is against the rule. Therefore, it should be changed to mdy without consensus. Anyone who wants to change the date format chosen in the first major contribution to other format should achieve consensus, according to the rule. Also, according to the IceWelder's seven-year implicit consensus rationale, IceWelder should have achieved consensus on the article's talk page. This is because over a period of 11 years, from early January 2005 to late September 2016, the article has evolved using predominantly the mdy date format. WAccount1234567890 (talk) 05:00, 18 November 2023 (UTC)

This question has been raised a few times in the past but there was no consensus. Most of us agreed that the date format should not be changed without a talk page consensus. However, it happened anyway and nobody care enough in the last 7 years to revert it. My opinion is that 7 years of the article using that date format is implicit consensus. If somebody care enough then they could have reverted it back when the change was first made. Waiting 7 years and then crying foul is far, far too late. Of course, others may have different opinions.  Stepho  talk  05:25, 18 November 2023 (UTC)

"First major contributor" is a fall-back to default to when consensus cannot be reached, but no attempt to do so has yet been made in this case (that I know of – Stepho-wrs hints at some prior discussion, but it sounds like it was from before IceWelder's action). The first major contributor's choice is not a set-in-stone establishment that consensus cannot change, or we'd have some very crap results like articles on British subjects written by Americans and stuck forwever with American MDY dating, and vice versa. IceWelder did in fact provide a rationale for the switch away from American MDY format [24]: "date formats per MOS:DATEFORMAT by script - Strong tie to japan, one of its largest companies". And it has remained stable in DMY for 7 years, which is a strong indicator of (though not absolute proof of) consensus. The switch probably should have been discussed by IceWelder first, especially since the rationale provided is questionable. The most common date format in the Japanese language is YMD, but our article at date and time notation in Japan is missing information on what format predominates in that country in materials written in English or in other non-Japanese-script materials, so the best that IceWelder's rationale seems, at least on the immediate surface, to have going for it is that Japan isn't the US and so US MDY format isn't appopriate. Various counter-arguments can be imagined, such as that the US has had more influence on Japan than any other Western country has; that since neither MDY or DMY are the norm there that both are arbitrary so it never should have been changed; and so on. But at this late a remove, there is no justification to "date-war" is back to DMY, only a very belated rationale to open a discussion on the article talk page about what the date format should be. Have the discussion now that should have been had back then.  — SMcCandlish ☏ ¢ 😼  05:30, 18 November 2023 (UTC)

I've opened a discussion at Talk:Nintendo#Date format (without expressing any opinion in it), and "advertised" it to wikiprojects on Japan, video games, and companies.  — SMcCandlish ☏ ¢ 😼  05:46, 18 November 2023 (UTC)

• Who cares? Why is it such a big deal? Tony (talk) 11:28, 18 November 2023 (UTC)

  Well, for WT:MOSDATE it's not; it's a routine thing to deterine at an article's talk page.  — SMcCandlish ☏ ¢ 😼  18:03, 18 November 2023 (UTC)

  But on a talk page it will stall when one side says "it was illegally changed 7 years, so it must be changed back" and the other side says "7 years implies consensus, so it must not be changed back". And both sides are supported by policies. There is no way forward from that and that's why they have come here.  Stepho  talk  22:45, 18 November 2023 (UTC)

  Neither of those are good reasons for a change from one arbitrary form to another, so both of them should be discounted as not particularly meaningful (though the latter of the two is actually stronger per WP:CONSENSUS and WP:NOT#BUREAUCRACY policies). Unless someone has a good and reader-facing reason to change the style now there isn't a good rationale to change it, no matter what might have been a reasonable argument 7 years ago. And this guideline talk page isn't going to change that, since there's not really a way around it. The higher-up MoS principle is MOS:STYLEVAR: if two styles are equally acceptable, don't change from one to another without a good reason. Vidictiveness and wikilawyering about a questionable decision more than half a decade ago is not such a reason. The info put forth on the article talk page so far is that English-language media in Japan don't seem to show a preference, and that Nintendo's own corporate publications seem to favor MDY. The first of these doesn't help and the second is basically meaningless for encyclopedic purposes. An argument not raised there yet is that DMY is more broadly expected by our readership, but this is also weak because date formats of both sorts are easily understood by everyone. At this rate, I would expect consensus to conclude there is no reason to change away from the format that's consistently been used for 7 years, since it makes no difference anyway.  — SMcCandlish ☏ ¢ 😼  00:08, 19 November 2023 (UTC)

  I think you missed the point. One side will argue that the change 7 years ago was illegal as per WP:DATERET, and therefore they are fully justified and supported by WP policy to change it back immediately - case closed! And the other side will say that after 7 years of no reversion that there is WP:CONSENSUS and any such late reversion can be undone immediately - case closed! Both sides claim full justification and support from WP policies. Stalemate.  Stepho  talk  01:49, 19 November 2023 (UTC)

  If literally no one can come up with an actual reason to favor one form over the other and no consensus is possible, then we default to the style used in the first non-stub version of the article (or first one to have a date, anyway). We have that rule for a reason, namely so that stalemate is not possible. But there is really no reason to go there; consensus could easily form that 7 years is long enough for the style (which is arbitrary anyway) to be considered established and for there to be no reason to change away from it. Either there is sufficient support for that idea, and it stays DMY, or there is not and we revert to the MDY of 7+ years ago, and neither will actually make any difference anyway. And it isn't something to decide at WT:MOSDATE. There is no reason for this redundant discussion to continue here.  — SMcCandlish ☏ ¢ 😼  02:26, 19 November 2023 (UTC)

• I will just point to the similar dispute at Talk:Sea Peoples#ERA just a month ago (in which I linked to Wikipedia talk:Manual of Style/Archive 226#MOS:ERA: dispute over what "established era style" means from last year). Rather than fighting over which policy or guideline rules, I think resolution of the dispute calls for a talk page discussion to establish the current consensus for what form to express the dates in. - Donald Albury 13:49, 19 November 2023 (UTC)

Date consistency across different but related articles?

Kris Wu is using dmy format while Kris Wu rape case is using mdy format. If a reader reads both articles, the different date formats may surprise them. MOS:DATE is silent on whether to unify the format or have some form of consistency across such related articles. Nonetheless, should the date format be the same across the articles? If so, how should this be resolved? – robertsky (talk) 10:47, 25 November 2023 (UTC)

There isn't a rule to have date formats match across articles on related topics; it's an article-by-article consensus. In your position, I think I would figure out what the most common date format is in Canada (something people have argued about before; I'm not sure if there's a definite answer to that question), since the subject is Canadian, and propose at the talk page of the article that doesn't match that format that the article should be changed to use that format per national ties, and that while there isn't a rule about it, it would be better for readers, who are very likely to navigate between these two articles, to get the same date format at both, simply as a common sense matter rather than an MoS rule-thumping one. I.e., seek consensus to change to the article that doesn't match the most appropriate date format.  — SMcCandlish ☏ ¢ 😼  10:52, 25 November 2023 (UTC)

I just found that Kris Wu's date format was changed by a sock master in 2020. Nonetheless, I have opened up the discussion at Talk:Kris_Wu#Date_format_consistency_across_multiple_articles. – robertsky (talk) 04:35, 26 November 2023 (UTC)

NOWRAP on sports scores, thread at main MoS talk page

FYI

 – Pointer to relevant discussion elsewhere.

This really would have been more pertinent for WT:MOSNUM, but please see: Wikipedia talk:Manual of Style#NOWRAP on sports scores.  — SMcCandlish ☏ ¢ 😼  00:07, 8 December 2023 (UTC)

Singular date format standardization

I believe that we should standardize all articles on ISO 8601, because it's easy to parse, and impossible to misinterpret. Additionally, situations like https://en.wiki.x.io/w/index.php?title=User_talk%3A2600%3A8800%3AB00%3AB20%3A356B%3AB97%3A1D7%3AAAA3#c-Rokejulianlockhart-20231207174500-Date_Format_Consistency_Regression, where an editor modifies the dates to suit their preference of the options currently available (see https://en.wiki.x.io/wiki/Wikipedia:Manual_of_Style/Dates_and_numbers#Formats) would be entirely prevented. Tag me if you are responding to my content or wish to notify me, because I may not be subscribed. (talk) 18:20, 7 December 2023 (UTC)

That's a brilliant suggestion. I wonder why no one thought of it before now. EEng 18:53, 7 December 2023 (UTC)

Terrible idea. As with our discussion elsewhere of another ISO standard (for separating thousands with thin spaces, rather than commas or period), there is a very specific need for a uniform standard in transnational scientific and technical exchanges — in fields like astronomy — that just won't work for the average reader or editor — almost none of whom will have installed a template (unnecessary because few people need help understanding either July 4, 1776 or 4 July 1776 or 4th July 1776 or July 4th, 1776). But ISO 8601 would confuse a general reader (and flummox the vast majority of off-the street editors) by using astronomer-speak in sentences like "The American colonies declared their independence from Great Britain on 1776.07.14". —— Shakescene (talk) 19:02, 7 December 2023 (UTC)

Oops!, perfect (though unintentional) example right there: I'm so unfamiliar with this format that I confused the ISO 8601 for Bastille Day (1789.07.14) with that for U.S. Independence Day (1776.07.04). —— Shakescene (talk) 19:09, 7 December 2023 (UTC)

"1776.07.04" is not a properly formatted ISO 8601 date. Jc3s5h (talk) 19:12, 7 December 2023 (UTC)

Just proves my point: I'll have to go study ISO 8601 (which I hadn't known by name until today) more closely and report back to class. What is the correct ISO 8601 format for Independence Day and Bastille Day? —— Shakescene (talk) 19:38, 7 December 2023 (UTC)

Two correct ISO 8601 formats for US Independence Day are "17760704" and "1776−07−04". Two correct ISO 8601 formats for Bastile Day are "17890714" and "1789−07−14". There is debate about whether it is more correct to use the minus character "−" or the hyphen-minus character "-"; I used the former. Jc3s5h (talk) 19:50, 7 December 2023 (UTC)

Actually it should be a plain hyphen, so 1789-07-14. See ISO 8601#Calendar dates. Gawaon (talk) 20:35, 7 December 2023 (UTC)

No, I will not refer to a Wikipedia article, all of which are unreliable. Jc3s5h (talk) 21:09, 7 December 2023 (UTC)

What I want to know is, what is the ISO 8601 format for a publication dated "Lent, Easter and Michaelmas terms, 1918–1919"? —David Eppstein (talk) 21:15, 7 December 2023 (UTC)

The reliable source provided there says "ISO 8601 tackles this uncertainty by setting out an internationally agreed way to represent dates: YYYY-MM-DD". While they don't say the word 'hyphen', those appear to be hyphens. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 21:20, 7 December 2023 (UTC)

The only way for people to learn and internalise a new date format is for it to be widely used. Wikipedia using it across the board would help! --ThePiachu (talk) 21:26, 7 December 2023 (UTC)

@Rokejulianlockhart: A date before 15 October 1582 that is in the ISO 8601 format is most likely a falsehood, because the standard requires the use of the Gregorian calendar, and the first use of that calendar was 15 October 1582. Jc3s5h (talk) 19:15, 7 December 2023 (UTC)

So when discussing ancient Rome we should use the Roman Calendar? Or when discussing ancient China we should use their calendar? Or not use any calendars at all when we talk about events from before the calendars got invented? --ThePiachu (talk) 21:26, 7 December 2023 (UTC)

The guideline already covers this at MOS:OSNS: "A date can be given in any appropriate calendar, as long as it is (at the minimum) given in the Julian calendar or the Gregorian calendar or both, as described below." Of course, in the case of ancient China or Rome, we might have an exact date in the Chinese or Roman calendar available, but be unable to precisely convert it to the Julian or Gregorian calendar. In that case we should indicate the conversion is approximate. Jc3s5h (talk) 21:36, 7 December 2023 (UTC)

Benefits of this proposal appear difficult to discern, but I suppose this would at least prevent my several-times-a-year rant at some editor (a different one every time) not to use the script that "fixes" articles that have been deliberately written to use numeric access-dates by converting them to long form dates. —David Eppstein (talk) 19:24, 7 December 2023 (UTC)

Since this proposal was placed in "Wikipedia talk:Manual of Style/Dates and numbers" and not in "Wikipedia:Citing sources" we must presume that this is intended to apply to all parts of articles, not just citations, even though the example given was about citations. Jc3s5h (talk) 19:31, 7 December 2023 (UTC)

Indeed, for the sake of consistency, I propose this across all facets of Wikipedia. Tag me if you are responding to my content or wish to notify me, because I may not be subscribed. (talk) 23:48, 7 December 2023 (UTC)

I wholly support the transition to one, unified date format! It is high time people everywhere start using it to avoid confusion, and the more they get exposed to a good calendar format the more natural they will find it to use.--ThePiachu (talk) 21:26, 7 December 2023 (UTC)

It seems to me an encyclopedia's prose is for the human reader rather than for computer sorting. Asking for all the human beings who consume this work to get accustomed to a format they very rarely see in their newspapers or online articles seems to be quite an ask. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 21:35, 7 December 2023 (UTC)

For computer sorting, I would consider positive and negative values relative to the UNIX Epoch, measured in seconds, to be ideal. However, that is unreadable, whereas I consider ISO 8601 to be easily readable, hence I propose the latter. I hope that that provides a more apt comparison between what you mention. Tag me if you are responding to my content or wish to notify me, because I may not be subscribed. (talk) 23:50, 7 December 2023 (UTC)

Easier, but not optimal. ISO 8601 would be an unexpected, more difficult format for the average reader. We're not here to surprise readers with our own special format (i.e. special relative to what readers are accustomed to) on anything. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 01:54, 8 December 2023 (UTC)

Excellent suggestion. In favour! 86.17.94.33 (talk) 21:56, 7 December 2023 (UTC)

Please be aware this is a discussion, not a !vote. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 22:14, 7 December 2023 (UTC)

Does an FR in the WikiMedia software exist for discussion votes? Tag me if you are responding to my content or wish to notify me, because I may not be subscribed. (talk) 23:50, 7 December 2023 (UTC)

Not that I know of, but there might be some add-on of some kind for it. We wouldn't use it here, per WP:NOT#DEMOCRACY and WP:CONSENSUS. Recent (but perennial :-) RfA reform proposals have called for a plain ol' vote without discussion stuff being a part of it, and a (aside from general hating on the idea) it was pointed out that there wasn't a means to implement this (technically yet, or policy-wise).  — SMcCandlish ☏ ¢ 😼  23:59, 7 December 2023 (UTC)

Well, I'm an ueber-geek, and even I think this is a dreadful idea (as well as one that needs to be listed at WP:PERENNIAL). It looks like content that was generated by a bot or something, and while most nerds know what the order is, most general readers of English are going to be just as confused about whether 2023-06-09 is 9 June 2023 or 6 September 2023 as when they encounter 9/6/2023 or 6.9.2023 or whatever. I don't even support using ISO dates in citation templates, despite efforts to make them automatically respond in the rendered page to {{Use XXX dates}} templates at the top of the page; I don't support it because innumerable articles have no such templates, and innumerable citations are not templated (but people would mimic the 2023-12-07 date format they see in templated citations). Worse, people would see 2023-12-07 in citations and then use the same "reader hateful" format in running prose, too. PS: I have no issue with it being used in quoted material, or in user-invisible functional ways like the table sort-key thing mentioned in the subthread below. And we have various date/age templates that use parameters like |2023|12|07. (There might be a few that actually require a string like "2023-12-07" but these can easily be fixed; we have numerous templates that parse all our acceptable date formats, and code can simply be lifted from them to do this.)  — SMcCandlish ☏ ¢ 😼  23:55, 7 December 2023 (UTC)

My Oppose is pretty basic. We're not here to create "format surprise", we're here to build an encyclopedia that's comfortably readable by the masses. This site should be as friendly as the ol' morning newspaper and certainly as accessible as contemporary online articles. Basically, this means we spell out the month, and position the day as the mdy or dmy formats call for. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 02:09, 8 December 2023 (UTC)

Long-term readers will know that I strongly favour allowing YMD in references. However, even I stop at using it in the main parts of an article. As said above, the masses do not understand it well enough for mission critical information.  Stepho  talk  03:17, 8 December 2023 (UTC)

Sortkeys

Upon further reflection, I did use a variant of this format in constructing invisible sortkeys to enable readers of a sortable table to sort birth and death dates of the Descendants of Queen Victoria so that (say) 23 May 1845 would (when sorting by date) precede rather than succeed 7 August 1848. But my home-cooked version used decimals, e.g. 1845.0523 < 1848.0807 (no particular events; just random examples). Would this still sort properly in ISO 8601 format with 1845-05-23 and 1848-08-07 ? —— Shakescene (talk) 21:15, 7 December 2023 (UTC)

Yes, ISO format is designed for convenient sortability (alphabetic sorting and sorting by date being the same in that format). Gawaon (talk) 21:19, 7 December 2023 (UTC)

MOS style for odds

Curious: Do odds like "2-to-1" in horse racing follow MOS:RATIO ("2:1") or MOS:ENDASH ("2–1")? I see it expressed as "2-1" with a hyphen and that seems incorrect. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 01:02, 28 October 2023 (UTC)

The en dash markup wouldn't be applicable because this is not meaning "2 through 1" (as would be the case in 2–1 BCE). So, "2:1", though I have to wonder whether writing out "2-to-1 odds" or "two-to-one odds" would not be better in sporting contexts instead of the maths-leaning "2:1 odds" format. I don't do enough sports betting to know whether "2:1" is a format the average reader familiar with that scene will recognize.  — SMcCandlish ☏ ¢ 😼  06:10, 28 October 2023 (UTC)

OK, that makes sense but our current MOS text prescribes en-dash "In compounds when the connection might otherwise be expressed with to, versus, and, or between", so we see it in text like game scores ("Celtics earned a 39–26 victory") and vote results. So, the 'to' in "2-to-1 odds" should be seen as a different kind of 'to'? Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 06:44, 28 October 2023 (UTC)

Yes. I can't think of a way in natural language to encapsulate every nuance of something like this in a one-liner rule. The fact that ratios have their own rule about colons basically precludes them being covered by a different rule about dashes that seems like it could have applied if not for the colon rule that is more specific to the case. And "2–1" isn't used in source material (either specialized or general-audience, as far as I know) to mean "two-to-one", so MoS would have no reason to impose it. MoS is generally derived from usage found in other (academic-leaning) style guides, not just made up out of nowhere. :-)  — SMcCandlish ☏ ¢ 😼  07:41, 28 October 2023 (UTC)

PS: MOS:RATIO already addressed this anyway, including not using an en dash for this, and in wording consistent with what I said above about using a colon or preferring written-out words: "Dimensionless ratios (i.e. those without accompanying units) are given by placing a colon between integers, or placing to between numbers-as-words: favored by a 3:1 ratio or a three-to-one ratio, not a 3/1 ratio or a 3–1 ratio."  — SMcCandlish ☏ ¢ 😼  07:46, 28 October 2023 (UTC)

PPS: And this was also already covered at MOS:DASH, too: "Colons are often used for strictly numeric ratios, to avoid confusion with subtraction and division: a 3:1 ratio;  a three-to-one ratio". Maybe it could be clarified by adding the word "odds" somewhere, if we think that "two-to-one odds" is not obviously a subset of "two-to-one ratios".  — SMcCandlish ☏ ¢ 😼  07:57, 28 October 2023 (UTC)

This should prevent the confusion happening again.  — SMcCandlish ☏ ¢ 😼  08:01, 28 October 2023 (UTC)

Update: Self-reverted that, given the material below.  — SMcCandlish ☏ ¢ 😼  11:32, 28 October 2023 (UTC)

Since gambling odds are not ratios, this requires them always to be expressed as words e.g. six to four on. Hawkeye7 (discuss) 08:44, 28 October 2023 (UTC)

How are they not ratios? If there are 6-to-1 odds against me winning a race againt you, this appears to be directly analogous me and you having blemishes in a 6:1 ratio, or me having 6 times more cats than you do.  — SMcCandlish ☏ ¢ 😼  11:36, 28 October 2023 (UTC)

Ah, but if I bet you a cat at 6-1 and win, I will have seven cats to your none. NebY (talk) 11:59, 28 October 2023 (UTC)

Yes, the outcome of the bet could change the possession ratios (like unto transplanting all your belmishes onto me in a weird dermatological experiement).  — SMcCandlish ☏ ¢ 😼  01:15, 29 October 2023 (UTC)

For horse-racing in the UK, the BBC website and the Guardian use x/y in tables but x-y in prose (e.g. 9/2 Fav, 5/1, etc, had hit 999-1, 11/2, at around 6-1). The Guardian's style guide uses x-y in prose discussing betting odds eg 2-1 on, sometimes expressed as 1-2 The first and fourth editions of Fowler's don't touch on it. NebY (talk) 11:05, 28 October 2023 (UTC)

That is the standard form in Australia too. Hawkeye7 (discuss) 11:13, 28 October 2023 (UTC)

So, hyphens then? And why is BBC News using two conflicting formats?  — SMcCandlish ☏ ¢ 😼  11:31, 28 October 2023 (UTC)

I suspect x/y is the style used first when chalking odds at racecourses, then at bookmakers when off-course betting was legalised, but a different prose style was established as an abbreviated form of "x to y". A larger survey might well show this apparent inconsistency is the norm throughout UK usage and for all I know, US usage too. NebY (talk) 11:44, 28 October 2023 (UTC)

Or we could just look it up on Wikipedia, of course. :) The end of the lead of Odds lists the many different notations of fractional odds, tote boards and US Moneyline, while Fixed-odds betting differs slightly and has a handy conversion table. NebY (talk) 11:57, 28 October 2023 (UTC)

Well, if there are "many different notations", i.e. wide inconsistency, we can't depend on our readers understanding any of them, so should probably advise writing out "two-to-one odds".  — SMcCandlish ☏ ¢ 😼  01:23, 29 October 2023 (UTC)

• Thanks everyone for the above enlightening discussion. So I guess this really boils down to whether we should have a Wikipedia guideline for the presentation of odds. We've made so many other things have a consistency via the MOS, so why not for odds? And if we went with something like "x:y" in prose, is that complicated for the general reader compared to "x-to-y"? And should we then say "x/y" or "x:y" is preferred in table formats? By the way, I live in the home of the Kentucky Derby, so I kind of get confronted with this quandary perhaps more than most editors. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 18:36, 28 October 2023 (UTC)

  why not for odds? – Because see WP:MOSBLOAT. This is exactly the situation The Wise One (that's me) was aiming to prevent. A thread that opens "just curious" should never end in a new guideline. When there's a thread that begins "For a long time there's been dispute about how to present odds in various articles ..." -- that's when we should talk about a guideline. EEng 19:04, 28 October 2023 (UTC)

  How the discussion begins is irrelevant. If we are producing an encyclopedia, then it stands to reason we have a standard for how we show particular types of information. We're not talking notes we send to our bookie (heh) or the various ways other publications show it. How is the Wikipedia going to present these values? This is an important question and I take umbrage at the question being so belittled. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 19:10, 28 October 2023 (UTC)

  For the record: How the discussion begins is very relevant, for the reason I just gave (which is elaborated at MOS:BLOAT). And while it stands to reason that some types of information should have a standard presentation project-wide, it does not stand to reason that project-wide standardization is needful or even desirable for all types of information; some things are better left to editor discretion. EEng 18:58, 7 December 2023 (UTC)

  My stance since I joined in 2004, which I believe to be consistent with project history and norms, is that we're here for the reader, and if this is considered a single work, consistency in its presentation is something to strive for. Also, WP:APF suggests we shouldn't be challenging others' motivations for asking questions, especially a fair question as what should be the consistent style we use for odds (and I think I already explained what brought me here anyway - I work on horse racing articles). Last, an eventual little note in guidelines about odds hardly bloats anything. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 19:08, 7 December 2023 (UTC)

  Lots of eventual little notes in guidelines about nitpicky micro-topical things, especially little notes trying to make exceptions against general principles, is exactly what MoS bloat, a pervasive form of WP:CREEP, is. We already have a general principle that applies here, a guideline on how to write ratios, and odds are ratios, so there has to be a really compelling reason to not use the ratio format for them. The fact that a few UK publications use different formats for them (different formats even within the same publication!) is not at all a compelling reason.  — SMcCandlish ☏ ¢ 😼  23:43, 7 December 2023 (UTC)

  Since there are a significant number of horse racing articles here, I don't think we should consider this a micro concern. If indeed odds are to be treated as ratios, it can't hurt to briefly state that in the MoS where it discusses ratios. But oddly (ahem), it doesn't seem clear there is consensus in this discussion that odds = ratios and that they should be formatted like ratios per the current MoS recommendations. I agree with your adeptly defended position on this, of course. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 00:02, 8 December 2023 (UTC)

  To be clear, this isn't a question I need resolved today, but just that I come across presentations of the values that don't have an encyclopedic consistency. How's it's ultimately resolved is something for which I hold a lot of patience. Also, complaints of "too many rules" (like "too many laws" or "too many regulations") generally have plenty of folks sitting on either side of the question. Really, what's necessary here is determining what is our ideal technical resolution, whether or not it makes it into the guidelines. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 19:42, 28 October 2023 (UTC)

  Can you show any particular benefit that would result from uniformity in this? Wikipedia doesn't have a principle that "it stands to reason we have a standard"; we have considerable flexibility, some of it explicit in our policies and guidelines (eg WP:ENGVAR, WP:RETAIN, WP:ERA), and the encyclopedia thrives nevertheless and even in consequence. The process of forming dogma can be argumentative and alienating (cf First seven ecumenical councils), its imposition likewise; we don't want to lose editors and our admin corps is stretched thin. Poor guidance brings the MOS into disrepute, generally weakening the uniformity you seek. The brief discussion above has demonstrated that several different notations exist and are appropriate with some variation in a variety of circumstances, but no-one, yourself included - indeed, yourself especially as the person proposing we should have a rule - has been able to quote any style manual or handbook's guidance on the matter and hardly anyone, not even you yourself as the person raising the question and claiming familiarity with "this quandary", has provided any survey of usage within or outside Wikipedia or shown that readers are likely to be confused. As to what's necessary, if we aren't going to write guidelines then there is no necessity to determine an ideal technical solution. We have at least found that what you thought was incorrect is not; let that suffice. NebY (talk) 00:51, 29 October 2023 (UTC)

  "Can you show any particular benefit that would result from uniformity in this?" – See my comment above: if there are "many different notations", i.e. wide inconsistency, we can't depend on our readers understanding any of them, so should probably advise writing out "two-to-one odds". There appears to be no international standards body that has issued a standard for how to do this, so we don't seem to have something at-least-arguably-authoritative to fall back on in picking between things like "2/1" and "2-1" and "2:1". It would thus be best to avoid all of them as certain to be unrecognizable to some (probably large) subset of editors, meanwhile anyone competent to read English well enough to use our site (or even just feeding our material into a machine translator) will not be confused by "two-to-one odds".  — SMcCandlish ☏ ¢ 😼  01:23, 29 October 2023 (UTC)

  In the UK, one of the most RS for horseracing is the Racing Post. A typical result page is the 2:35 at Aintree today; the odds here are given using the slashed form - i.e. 1 1 Inthewaterside 4/7F (winner, runner no. 1, at starting odds of four to seven favourite, or seven to four on); 2 10 Jagwar 7/2 (second place, runner no. 10, at seven to two); 3 4 Rich Spirit 50/1 (third, no. 4, at fifty to one), etc. Notice that on each row are other numeric items using hyphens, such as 11-4 or 11-2 - these are the weights carried, in stones and pounds, so using a hyphenated form for the odds could be misleading. --Redrose64 🌹 (talk) 15:01, 29 October 2023 (UTC)

  Well, that explains why a particular publisher is using that format, when they have other stuff to disambiguate from in the same table, using the other format. It doesn't really do anything about other formats being used in the same country, including two conflicting ones by BBC at the same time. I still don't see a rationale for MoS to favo[u]r a particular format with digits, even in BrEng articles, instead of using words. Maybe if there were ever a cause for WP to have a table with a bunch of odds in it, but even then if we had to use digits for space reasons, we'd probably need to include a note somewhere that "7/2" (or "7-2" or whatever) was an expression of odds.  — SMcCandlish ☏ ¢ 😼  17:08, 29 October 2023 (UTC)

  I don't see why you keep describing formats as conflicting that are contextual, conventional and appropriate, or for that matter why we should invent a MOSNUM way of expressing odds which is at odds with the expression of odds in the world outside Wikipedia and in Wikipedia articles too. I fear you underestimate the ability of "anyone competent to read English well enough to use our site" to recognise when numbers are being used to represent odds, to their detriment and the detriment of our editors (and thus of our MOS). NebY (talk) 17:26, 29 October 2023 (UTC)

  They are conflicting formats if used in the same context (e.g. British sport reporting). Same with dates; "29 Oct 2023", "29th October 2023", "29th Oct. 2023", "29 October 2023", "29th of October 2023", etc., are all conflicting ways of writing a date that can be found in British (and other largely non-American) publications, and we don't permit them all here. I am not advocating that MOS invent a new format for this at all; I suggested nothing like that, ever. I'm skeptical that MoS should adopt any of these attested digit formats, because they are inconsistent (conflicting), and there is no standard on which we can rely (unlike for unit abbreviations, and several other categories of things covered at MOS:NUM). Your assertion that they are "conventional" is self-contradictory. Conflicting usages (ones that do not match, do not agree, are different, are inconsistent, are not formatted the same – however you want to express that, if you just somehow don't like the word "conflicting") by definition do not form a convention, a standard. Using plain English like "two-to-one odds" por perhaps "2-to-1 odds" if we prefer numerals for most sport purposes, is in no way an "invent[ed] ... MOSNUM way of expressing odds"; it's the everyday-English-language way to do it. The fact that various publications have, in fact, invented conflicting short-hand ways of encoding odds doesn't impose on Wikipedia a duty to adopt one of them, nor a duty to adopt all of them simultaneously and just left to random to editorial whim, page-by-page. In the end, I'm skeptical MoS needs to say anything about this at all, but if we do, it looks like we should advise using plain English, and if a table necessitates using a compressed form, make it clear that it is an expression of odds, since we cannot depend on any class of readers, even British ones, to recognize that "2/1" or "2-1" are necessarily an odds expression (though "2-to-1" is probably recognizable as one). PS: I had thought that "2:1" would be good enough, since it's our format for ratios, which are said exactly the same, "two-to-one", and odds appear to be ratios (someone claimed otherwise but did not back up their claim). But there's disagreement with the "2:1" idea, so I've abandoned it.  — SMcCandlish ☏ ¢ 😼  17:53, 29 October 2023 (UTC)

  Odds are ratios. If the bookmaker offers odds of 7/2 for Jagwar, that means that if I stake two pounds for Jagwar to win, the bookie will cover that with seven pounds making a prize pot of nine pounds which goes to me if Jagwar wins, to the bookie if it doesn't. But my stake need not be exactly £2.00, nor indeed a whole number of pounds - I might only be willing to risk fifty pence, so the bookmaker puts 0.50 * 7 / 2 = £1.75 into the pot, plus my £0.50 making £2.25 coming to me if Jagwar wins. The same goes for Rich Spirit: 0.50 * 50 / 1 + 0.5 = £25.50 in the prize pot; or for Inthewaterside: 0.50 * 4 / 7 + 0.5 = £0.79 (rounded to the nearest penny) in the pot. In each case the odds are a term in the calculation prize pot = (stake * odds + stake), and that term is a ratio. --Redrose64 🌹 (talk) 20:01, 29 October 2023 (UTC)

  That's what I thought (in more maths than I thought it). Since they are ratios, and we already have a prescribed shorthand for ratios, the burden is on other editors to show that there is some special standard that applies to odds ratios that MoS should adopt for that case.  — SMcCandlish ☏ ¢ 😼  03:11, 30 October 2023 (UTC)

  The BBC and the Guardian both use the same pair of formats, one for prose and one for tables and lists. This should not be decried as "conflicting" or "inconsistent"; their application of this convention is consistent, considered and appropriate. We would be quick to quote and consider being guided by Chicago or Fowler's; given their silence, it's observable conventions such as these that we should consider, not reinvent the wheel and watch it fall off. Still, we agree on one thing: we're both sceptical that MOSNUM needs to say anything at all about odds so unless consensus emerges that something must be said, I'll happily leave the question of what (I dare not say table it for fear of other transatlantic confusion). NebY (talk) 00:03, 30 October 2023 (UTC)

  You just don't seem to have an understanding of what "inconsistent" AKA "conflicting" means in relation to a style guide like this one. When a pair of publications can't even agree internally how to render this, and conflict further with other publishers within their own country, this is by definition not a "convention". I think the odds of you getting a consensus to add a special rule to MoS to use either of those formats for odds ratios are extremely low.  — SMcCandlish ☏ ¢ 😼  03:11, 30 October 2023 (UTC)

  To me it sounds reasonable to recommend formatting them like ratios (x:y), if we want to give any recommendation. Both because they are ratios, or at least close enough, and because that style seems to be fairly common. The dashed style I would consider not ideal, since it looks too much like "minus" for my taste. Gawaon (talk) 17:46, 2 November 2023 (UTC)

  I would consider either x:y or x/y to be reasonable for odds. For scores I would stick to x-y or spelled out as x to y. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:26, 3 November 2023 (UTC)

  Scores are supposed to have an en dash, but that's a different subject. :) Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 18:37, 7 December 2023 (UTC)

  Yes, definitely a different subject, and we shouldn't mix them. Scores and vote tallies are their own MoS line item.  — SMcCandlish ☏ ¢ 😼  23:46, 7 December 2023 (UTC)

• For the record, I've come back around to firmly supporting "2:1" format, because these are ratios, we already have a format for that, and alternative formats are not consistently used, even within a single country (sometimes not even a single publication), so there is neither a "there's a standard" argument to make nor WP:ENGVAR argument to make.  — SMcCandlish ☏ ¢ 😼  07:32, 4 November 2023 (UTC)

  "2:1" would be my preference as well, although I think it's not unreasonable for an editor to consider an en dash to be superior to a hyphen, as the odds are pronounced "2-to-1". Spelling it out as "2-to-1" seems fair as well. No matter what is ultimately agreed upon, though, we're here for the reader, and if we consider the Wikipedia a single work, we should care about consistency of presentation. But I'd reiterate I'm not looking for a quick decision. By the way, I dropped out of the discussion earlier as it seemed my mere question opened up a hornet's nest, and I frankly still do not understand the vitriol over it. Stefen Tower_{s among the rest!} ^{Gab • Gruntwerk} 18:49, 7 December 2023 (UTC)

  The vitriol is because someone got it in their head that it's an MOS:ENGVAR matter, but then were unable to demonstrate a consistent British usage, so it turns out to not be one. It's just that some publications use other formats, but we knew that already.  — SMcCandlish ☏ ¢ 😼  23:31, 18 December 2023 (UTC)

  SMcCandlish, you had once added "This includes odds ratios in sport, gambling, and other prediction." after the sentence on "Dimensionless ratios" in MOS:RATIO, but then self-reverted it. Considering the length of this discussion, that's evidently a non-obvious topic, so I think it would indeed be useful (and not BLOAT) to have such a sentence for clarity. Gawaon (talk) 10:25, 9 December 2023 (UTC)

  Agreed. I know I made a MOSBLOAT/CREEP argument earlier, but this seems like simultaneously a general and concise enough tweak to make, plus there has been substantial argument about it, and that argument seems to be heading one direction. Though there were a couple of hold-outs for "/" or some other format, it was on the basis of inconsisent usage of the alternative markup by some particuilar publishers. It seems insufficient to create a divergent style on WP for unitless numeric ratios for one specific context when all the rest of them have ":" format.  — SMcCandlish ☏ ¢ 😼  12:11, 10 December 2023 (UTC)

  I have now boldly readded the sentence, to that this discussion won't be forgotten without a result. I've changed the wording a bit, because "odds ratios" sounded somewhat duplicated, considering that odds are ratios. Gawaon (talk) 12:12, 18 December 2023 (UTC)

Suggestion: binary prefixes (MOS:BINPREFIX) should be re-considered

We're obviously not going to preemptively agree to have the same discussion every year. If you've got a proposal to make regarding a change to the guideline, just make it. Concisely, please.

The issue of MOS:BINPREFIX rules was, apparently, last discussed more than 10 years ago, here: [25] I'm not aware of newer discussion on the issue. If there is one, then I would like to be pointed to the latest arguments. In short, I think that the rules about MOS:BINPREFIX should be re-considered on a yearly basis, because the World is changing. Every year, Wikipedia needs to determine what is the latest consensus on MOS:BINPREFIX. I'm on the side that binary prefixes should be allowed, or, at least, less for restrictive rules. I'm for allowing that the units in question can be used without restrictions. But I can't force the consensus. It is Wikipedia's responsibility to determine what is the latest consensus on the question, every year. The units are: KiB, MiB, GiB, etc..., for binary multiples of bytes Kib, Mib, Gib, etc..., for binary multiples of bits - Z80Spectrum (talk) 23:04, 12 January 2024 (UTC) This is not how Wikipedia works. We don't do yearly RfCs. If you feel that the actual guidance in the MOS should change, feel free to propose something, but mandating a yearly discussion about it is a non-starter. Writ Keeper ⚇♔ 23:29, 12 January 2024 (UTC) The last discussion was just over a year ago at Template talk:Quantities of bits. The world is changing slowly. Some changes (like this one) are pretty much ignored by industry. Adoption is very, very slow and hasn't seemed to grown over the last 5 years. Most chip datasheets that I use in my work (embedded software engineer) continue to use the old form of MB. Yearly discussions like this are about as welcome as yearly tax time.  Stepho  talk  00:20, 13 January 2024 (UTC)

Units for human height and weight

In MOS:MEASUREMENT, there is a statement that, "In non-scientific articles with strong ties to the United Kingdom, ... the primary units for personal height and weight are feet​/inches and stones/​pounds".

• The use of the slashes seems vague, and the two slashes in that statement seem to mean different things. The slash in "feet/inches" indicates the use of a combination of feet and inches, but the slash in "stones/pounds" seems to indicate two alternatives. See also MOS:SLASH. Would there be an objection to changing "feet​/inches and stones/​pounds" to "feet-and-inches and stones or pounds"?
• There is no mention of the primary units for personal height and weight in SI units. The human height and human weight articles indicate a clear convention. There is a list of "Special considerations:" at the bottom of MOS:MEASUREMENT. Would there be an objection to adding a bullet that says "the primary SI units for personal height and weight are centimetres and kilograms"?

—⁠ ⁠BarrelProof (talk) 01:06, 8 December 2023 (UTC)

It seems unnecessary to specify primary SI units for human height and mass. Although centimeters and kilograms would probably be most common, if height were expressed in meters or millimeters readers could easily convert mentally. Similarly, if mass were expressed in grams the mental conversion is easy. Jc3s5h (talk) 01:38, 8 December 2023 (UTC)

It seems rather unnatural for these human measures to be expressed in other SI units. An example of this strangeness is the use of metres for the heights of NBA basketball players, which seems to be the convention that is being used – e.g., see the table at Boston Celtics#Current roster. Mental conversion to cm should be unnecessary, and using metres causes the visual clutter of the need for a decimal point. —⁠ ⁠BarrelProof (talk) 01:52, 8 December 2023 (UTC)

An occasion when a unit other than kilograms or centimeters might be appropriate would be if humans were being compared to other animals, which were substantially larger or smaller than humans. Jc3s5h (talk) 02:11, 8 December 2023 (UTC)

I think the word "primary" takes care of that, along with the general statement that the guideline "is best treated with common sense, and occasional exceptions may apply". And there are probably very few occasions where it is desirable to compare human heights and weights to other things that are that much larger or smaller. —⁠ ⁠BarrelProof (talk) 02:18, 8 December 2023 (UTC)

In the old measurements, you measured people's heights in feet and inches (eg. 6 feet, two inches) and weight in stones and pounds (eg 10 stone, nine pounds). Decimals were not used. Hawkeye7 (discuss) 02:34, 8 December 2023 (UTC)

Oh, I see. It's more similar to feet and inches than I thought. So in the UK, would someone's weight not be reported as 149 pounds, but rather only as 10 stone, 9 pounds? (I don't think inches are generally used without feet when reporting heights in non-scientific contexts.) Also, I notice you referred to "old measurements" and used the past tense for "measured", but MOS:MEASUREMENT is for Wikipedia current practices. Has that usage faded? —⁠ ⁠BarrelProof (talk) 03:02, 8 December 2023 (UTC)

Faded to some extent but not gone. Here's an example from the Daily Mail: [26]. I picked the Mail because a) I knew I would immediately find some article yelling about someone's diet or weight gain; and b) it's a tabloid, basically the least niche kind of publication I can think of. "Stone" is still widely understood. -- asilvering (talk) 03:39, 8 December 2023 (UTC)

That has stones but no remainders in pounds, and this one linked on the same page has pounds but no stones. —⁠ ⁠BarrelProof (talk) 03:42, 8 December 2023 (UTC)

Ah, I see what you're asking for now. Ok, here's an example of that: [27]. -- asilvering (talk) 04:01, 8 December 2023 (UTC)

• Here's a poser: Which_units_should_be_primary_for_the_height_of_a_UK_statue_of_a_UK_politician. (Answer: statute miles.) EEng 05:34, 8 December 2023 (UTC)

  You can't be serious. He's a Scottish politician. You'll have to divide that figure by 1.123. -- asilvering (talk) 06:36, 8 December 2023 (UTC)

  Where were you when we needed you? EEng 00:59, 9 December 2023 (UTC)

It's tempting to say something like "hardly anyone outside the UK, Ireland, and a few Commonwealth countries has any idea what 'stone' comes out to in any other unit; it's just gibberish to them", but of course the same is true of a lot of US customary units in countries outside the US (though I think most of the British, Canadians, etc., are still actually pretty familiar with most of them and use them spottily for a variety of traditional measurement purposes). Anyway, I think we actually have a three-way conversion need here. In the US, for persons, they use pounds. The British (and some with close connections to them) use stone + pounds, I gather. Meanwhile, the rest of the world uses metric. I think a modification of the guidance to suggest using stone in addition to, not in place of, either metric or US, would be reasonable (for this specific purpose, not for measuring weights of hay bales or automobiles, of course). And maybe there are some other cases like this (hands for horses?) There may already be other situations where we're doing 3-way conversion (or should be), e.g. km + nautical miles + regular miles for nautical topics, since nearly no one intuits in nautical miles.  — SMcCandlish ☏ ¢ 😼  11:16, 8 December 2023 (UTC)

When reading charts and at sea I'd always think in terms of nautical miles. Martin of Sheffield (talk) 20:29, 24 December 2023 (UTC)

Thus "nearly".  — SMcCandlish ☏ ¢ 😼  03:10, 28 January 2024 (UTC)

FWIW, {{convert}} is geared up for this. E.g., {{cvt|120|kg|stlb lb}} yields 120 kg (18 st 13 lb; 260 lb). (Jonah Lomu, if anybody cares.) --𝕁𝕄𝔽 (talk) 11:29, 8 December 2023 (UTC)

This answers a long-standing question I've had about the English nanny's weight in Eloise at the Plaza: 18 st (110 kg) —Thanks! kencf0618 (talk) 12:21, 8 December 2023 (UTC)

Sorry, no matter how hard I try, I just can't imagine Julie Andrews as a tighthead prop --𝕁𝕄𝔽 (talk) 00:47, 9 December 2023 (UTC)

Those "US customary units outside the US" - what's in that group beyond inches/feet/yards? I can't think of anything. I would expect any other non-metric measurements that look like US measurements are actually Imperial ones. For example, a pint as far as I know is 20 oz everywhere except the USA, where it's 16, with the bonus fun that those ounces aren't the same size either, and the additional bonus fun that American pints come in "wet" and "dry". (If you buy a pint of California strawberries in Vancouver, what measurement is being used? I haven't the foggiest.) -- asilvering (talk) 19:41, 8 December 2023 (UTC)

@BarrelProof: I mentioned stones and pounds in my post of 15:01, 29 October 2023 (UTC) in an earlier section. --Redrose64 🌹 (talk) 14:21, 10 December 2023 (UTC)

• Would there be an objection to adding a bullet that says "the primary SI units for personal height and weight are centimetres and kilograms"? I have not seen any clear objection. —⁠ ⁠BarrelProof (talk) 19:49, 24 December 2023 (UTC)

Where would you put your bullet point? If under the UK it contradicts "the primary units for personal height and weight are feet​/inches and stones/​pounds", and the catchall "In all other articles" already specifies metric. Martin of Sheffield (talk) 20:29, 24 December 2023 (UTC)

I'd put it under "In all other articles". Yes, that specifies metric, but it does not specify which metric units to use for personal height and weight. Height could be measured in metres or millimetres and weight could be reported in grams, but (as described in the human height and human weight articles), it is generally preferable to uniformly use centimetres for height and kilograms for weight. —⁠ ⁠BarrelProof (talk) 00:51, 30 December 2023 (UTC)

We're recommending the use of "Stones"? Really? I'm bobbleshipped. Spurtgrabbled. We should stop this. Let's think this thru:

• Two-thirds of the Anglosphere population are Americans.
• Nobody -- I mean essentially nobody, within rounding error -- in the United States knows what a "stone" is. It's gibberish. I don't mean just that they don't know its value, they don't know that it's a unit. (I expect that a lot of English speakers outside the United States know that feet, pounds, and miles exist and are not meaningless words, at least. Similarly for grams and meters in the United States.)
• If you want to consider ESL readers, it probably gets even worse, since I doubt that most Indian and certainly Japanese and Spanish people using this English Wikipedia are very familiar with stone. (Canada and Australia I don't know.)
• I expect that most everyone who knows the value of a stone also knows the value of pound, that few people are going to have to consult their reference books if a weight is given only in pounds. Willing to be corrected on this.
• And keep in mind that WP:ENGVAR is mostly a device to keep peace. It's an excellent rule. But it's not like many of even the obscure English-subject articles aren't read by at least a good percentage of Americans and ESL folk. After all there are at least four times more of us. So WP:ENGVAR, fine, but not to the point of using fortnights or chains or barleycorns (=1/3 inch) -- or stone.

If using stone is mostly just a matter of gruntling the English and making them feel cared about and important rather than giving units they need to understand a passage -- and I suspect that this is very much in the mix, we being humans -- then enh. They've had their time in the sun, and if they wanted their units to still be widely used internationally they could have, I don't know, not passed the Intolerable Acts maybe? But no backsies on that, it is what it is.

(FWIW I thought that the plural of "stone" was "stone". Maybe as with cannon/cannons both are OK, but then we shouldn't valorize "stones" over "stone" in our advice, but rather give both. If we're going to use stone at all. Which, I hope not.) Herostratus (talk) 20:38, 30 December 2023 (UTC)

In other words, the american way is the only way, sod the rest of the world (metric) or the rest of the anglophones, they'll just have to learn the good ol' American way. Why not use {{convert}} and stop this imperialism? Martin of Sheffield (talk) 21:48, 30 December 2023 (UTC)

I found the part that suggested that US customary units are widely used internationally particularly amusing. Kahastok talk 21:57, 30 December 2023 (UTC)

"I'm bobbleshipped. Spurtgrabbled. We should stop this." I have to agree with this. It kinda makes sense that imperial units are used in reference to countries where they are widespread, but pounds as imperial unit for weight are much more widely understood than stones. Very simply said: everybody who knows what a stone is, knows what a pound is, but the opposite is not true. The MOS says that opportunities for commonality are to be sought. The use of stones for weight is the opposite of commonality, so let's deprecate it. Gawaon (talk) 04:56, 31 December 2023 (UTC)

And how are your concerns not resolved by using three-way conversions, as discussed above? This is already the default behaviour of {{convert}} when stones are input.

To be clear, since you're apparently not aware. People in the real world don't estimate measurements in a unit-independent way and then convert up and down to their preferred unit. They tend to have an intuitive scale that relies on a specific unit. You'll find Brits who prefer stones for personal weight, and you'll find Brits who prefer kilograms (though the latter can generally manage stones if required). It'd be very rare to find a Brit who prefers pounds without a clear US connection, and people in the first two groups would not be expected to have an intuitive scale for personal weight in pounds. So, using pounds alone in this context fails your commonality test. Kahastok talk 09:58, 31 December 2023 (UTC)

As one who prefers kilograms, no, I can't generally manage stones without converting them to pounds first (then take off 10% and divide by two to get a meaningful figure. Something easy like "a four-stone sack" = 56 pounds => 25kg I can do in my head. But if it is 17st 12lb rugby forward, fogeddaboudid! --𝕁𝕄𝔽 (talk)

But you knew that 17 st 12 lb was a reasonable weight for a rugby forward - that a rugby forward would be unlikely to be 40 stone or 7 stone? And how about a 17 st 12 lb (113 kg; 250 lb) rugby forward, which is how it would be presented on Wikipedia? FTR, I am also one of those who prefers kilograms. Kahastok talk 11:37, 31 December 2023 (UTC)

Added MOS:BINPREFIX

I need the MOS:BINPREFIX shortcut in order to simplify a future argument about MOS:COMPUNITS.

So I added the shortcut.

I also added a new redirect-page MOS:BINPREFIX.

The redirect-page informed me that it takes a few weeks for it to be approved. Until the approval completes, the new shortcut MOS:BINPREFIX will not work. Z80Spectrum (talk) 22:42, 12 January 2024 (UTC)

I've created the redirect for you. Just start your discussion about the topic as a new section. Nthep (talk) 22:44, 12 January 2024 (UTC)

Thanks. MOS:BINPREFIX now works. Z80Spectrum (talk) 22:47, 12 January 2024 (UTC)

The action were suggested and approved in Teahouse, by user User:Writ Keeper, under:

Questions on WWF:BINARY_PREFIXES and questions about complaints about archive of complaints Z80Spectrum (talk) 22:45, 12 January 2024 (UTC)

What is "WWF:"? That's not a shortcut pattern we use. Anyway, the threads pertaining to this seem to be:

• Wikipedia:Teahouse/Questions/Archive 1212#Complaint on WWF:BINARY PREFIXES and complaints about complaints about archive of complaints
• Wikipedia:Teahouse/Questions/Archive 1212#Questions on WWF:BINARY_PREFIXES and questions about complaints about archive of complaints

This of course goes back to perennial arguments about "mibibytes" and so on, like:

• Wikipedia talk:Manual of Style (dates and numbers)/Archive B17 (2010)

back to:

• Wikipedia talk:Manual of Style (dates and numbers)/Archive B1 starting in 2007.

Some intermittent post-2010 dicussion of the issue not archived in this "B" page series. E.g.:

• Wikipedia talk:Manual of Style/Dates and numbers/Archive 94#Omegatron's recent changes to the main page involving binary prefixes (2008)
• Wikipedia talk:Manual of Style/Dates and numbers/Archive 133#RFC on the use of IEC prefixes to describe binary quantities (2011)
  • Discussion referred to there has been archived as Talk:Hard disk drive/Archive 7#IEC prefixes and WP:MOSNUM (2011)
• Wikipedia talk:Manual of Style/Dates and numbers/Archive 140#IEC vs ISO binary prefixes (2013)
• Wikipedia talk:Manual of Style/Dates and numbers/Archive 141#Problematic binary prefix paragraph (2013)
• Wikipedia talk:Manual of Style/Dates and numbers/Archive 143#Problematic binary prefix paragraph (2013)
• Wikipedia talk:Manual of Style/Dates and numbers/Archive 146#Binary prefixes February 2014
• Wikipedia talk:Manual of Style/Dates and numbers/Archive 153#Binary prefixes (new thread moved here from previous discussion) (2015)
• Wikipedia talk:Manual of Style/Dates and numbers/Archive 153#Binary prefixes again (2015)
• Wikipedia talk:Manual of Style/Dates and numbers/Archive 160#Binary prefixes (2020)
• Wikipedia talk:Manual of Style/Dates and numbers/Archive 161#RFC: Column name/position/content for binary computing units (2022)
  • Discussion referred to there is still unarchived at: Template talk:Quantities of bits#RFC: Column name/position/content for binary computing units (2022)
• Wikipedia talk:Manual of Style/Dates and numbers/Archive 161#More eyes needed at Binary prefix (2022)

Probably a bunch I missed, plus endless debate in the archives of Talk:Binary prefix, and something semi-recently at Template talk:Quantities of bits.  — SMcCandlish ☏ ¢ 😼  03:07, 28 January 2024 (UTC)

Thank you for the links. I'll try to read as much as I can, as I find the discussion amusing.

IMO, my argument about MOS:BINPREFIX is a valid argument, but the discussion below was closed (unfairly, IMO). I also made a concrete proposal, in the same post, so the green summary is incorrect, IMO. I'm ready to continue the discussion, if the other side is willing. Z80Spectrum (talk) 13:28, 28 January 2024 (UTC)

My suggestion is:

Some kind of summary needs to be written, which includes the best arguments from both sides. The way the MOS:BINPREFIX arguments are presented makes me immediately suspicious of intentional manipulation and misuse of power. The way that | my suggestion below has been handled makes it even worse, and I might consider reporting the involved parties to WP:ANI. Z80Spectrum (talk) 21:18, 28 January 2024 (UTC)

Poring over the material, and producing a neutral summary might be helpful, and might point the way to some kind of proposal that would not be ignored immediately as tiresome rehash. However, beware going in directions like "makes me immediately suspicious of intentional manipulation and misuse of power"; this is a WP:CTOP area (whether we think internal rule-making discussions should be or not), and WP:ASPERSIONS, especially bad-faith-assumptive ones, are strongly contra-indicated. PS: vaguely threatening people with ANIing is in no way going to "win friends and influence people", just make them treat you like an axe-grinder/PoV-pusher/battlegrounder and make them dig in their heels. Any time you're actually certain something rises to ANI level, just go open an ANI discussion.  — SMcCandlish ☏ ¢ 😼  00:22, 31 January 2024 (UTC)

Thanks. I'm not certain about anything, because I'm new here. I just highly disliked the way my suggestion was treated here.

I was thinking of producing a more detailed proposal, but I can't do it alone because I don't have enough experience. As for arguments in previous debates about MOS:BINPREFIX, I find them completely missing the point. Z80Spectrum (talk) 00:44, 31 January 2024 (UTC)

Revising MOS:DATED

At the "Statements likely to become outdated" section, the material there appears to have been written only with a concern about facts that might change at any time and claims about which can be pinned to more specific dates. It completely misses the common use of "now", "today", "modern", etc., as clear and obvious shorthand for a construction like "in the modern era". Some examples:

• At Borlengo: Originally a food eaten by the poor and made only with flour and water, it now also usually includes salt and optionally eggs
• At History of the kilt: Widespread use of this type of kilt continued into the 19th century, and some still wear it today ... as highly formal attire; and: the garment people would recognize as a kilt today was invented in the 1720s; and: the earliest documented example with sewn-in pleats, a distinctive feature of the kilt worn today.

This sort of usage is in no way "broken", and replacing it would require longer and less clear verbiage for no benefit to the reader.

The same section also makes the claim that Terms likely to go out of date include best known for, holds the record for, etc.. The latter is often correct (not in every case, e.g. for records in dead sports like 18.2 balkline billiards, or records that aren't of that sort, such as longest river in the world), but the former usually is not except in biographies of still-active living people, and "best known for" is one of the most common phrases in our biographical leads, so red-flagging it as something that must be avoided is clearly wrong.

I propose a revision along these lines:

Statements likely to become outdated

[shortcuts and hatnotes]

Generally, there is no "present" in a work of reference. Except on pages that are inherently time-sensitive and updated regularly (e.g. the "Current events" portal), terms such as now, today, currently, present, to date, so far, soon, upcoming, ongoing, and recently should usually be avoided in favor of phrases such as during the 2010s, since 2010, and in August 2020. Wording can usually be modified to remove the "now" perspective: not she is the current director but she became director on 1 January 2024; not 2010–present but beginning in 2010 or since 2010.

Phrases often used in lead sections that may go out of date include best known for in biographies of living people, holds the record for when the record could be broken later, etc.^{[footnote elided]} For current and future events, use phrases like as of November 2024 or since the beginning of 2024 to signal the time-dependence of the information; use the template {{as of}} or {{updated}} in conjunction. This is not necessary for information unlikely to change any time soon, such as the best-known work of a retired actor, or the location of a company's headquarters.

Relative-time expressions are acceptable for long periods. Terms like now, today, modern, and present-day can be used appropriately and concisely to distinguish the modern era from earlier history, if the modern conception of the subject is unlikely to change within coming decades. E.g.: Modern cuisines worldwide have integrated chili peppers, originally native only to the Americas.; and: The Inca empire stretched across parts of present-day Peru, Ecuador, Bolivia, Argentina, and Colombia.; and: Humans diverged from other primates long ago, but only recently developed state legislatures.

Or use some other examples. We could actually lose the entire Samuel Butler joke anyway, since it's not really illustrative of encyclopedic writing.

The original version for comparison:

Statements likely to become outdated [shortcuts and hatnotes] There is no "present" in a work of reference. Except on pages that are inherently time-sensitive and updated regularly (e.g. the "Current events" portal), terms such as now, today, currently, present, to date, so far, soon, upcoming, ongoing, and recently should usually be avoided in favor of phrases such as during the 2010s, since 2010, and in August 2020. Wording can usually be modified to remove the "now" perspective: not she is the current director but she became director on 1 January 2024; not 2010–present but beginning in 2010 or since 2010. Terms likely to go out of date include best known for, holds the record for, etc.[footnote elided] For current and future events, use phrases such as as of November 2024 or since the beginning of 2024 to signal the time-dependence of the information; use the template {{as of}} (or {{updated}}) in conjunction. Relative-time expressions are acceptable for very long periods, such as geological epochs: Humans diverged from other primates long ago, but only recently developed state legislatures.

 — SMcCandlish ☏ ¢ 😼  23:13, 1 February 2024 (UTC)

Ordinals

Our text on ordinals leads off with For guidance on choosing between e.g. 15th and fifteenth, see § Numbers as figures or words, referring and linking back to the section immediately above. But the section above doesn’t contain any pertinent guidance that I can see? Other than the general statement about single-digit numbers that is already in the ordinals section itself. MapReader (talk) 06:19, 16 January 2024 (UTC)

MapReader, I think all of the guidance of the preceding section is meant to apply to ordinals. For example, it's saying we should avoid starting a sentence with an ordinal expressed as a figure (e.g. don't use "15th place went to Aida."). Firefangledfeathers (talk / contribs) 04:18, 25 January 2024 (UTC)

It doesn’t say that, at all. It specifically refers to choosing between number and written format, about which that section says nothing new or relevant. I suggest the cross reference can be deleted? MapReader (talk) 04:23, 25 January 2024 (UTC)

Your use of pronouns is throwing me off a bit. Are you saying that §Numbers as figures or words doesn't advise against starting a sentence with a figure? Firefangledfeathers (talk / contribs) 04:29, 25 January 2024 (UTC)

Why raise something not in my original post? The issue with the article is that it says For guidance on choosing between e.g. 15th and fifteenth… and then cross-refers to a section that doesn’t provide any additional guidance to what is already stated below. MapReader (talk) 05:50, 25 January 2024 (UTC)

I'm trying my best to respond to something raised in your original post. I think you are saying that §Numbers as figures or words does not contain any guidance that would be pertinent to deciding whether to represent ordinals using figures or words. I'm expressing that I see all of the guidance of §Numbers as figures or words as pertinent. Of the bulleted guidance in that subsection:

1. The first, about one-digit numbers, is duplicated in §Ordinals; you already noted this
2. The second, about numbers expressible in one or two words, is relevant to ordinal numbers (e.g. don't use "five hundred and second best runner"); I had not previously brought that up
3. The third, about avoiding beginning sentence with figures, is also relevant to ordinal numbers; I tried above to show this using the "15th place" example

I could go on to the remaining bulleted items, but I'm sensing there's some disconnect here, and I can't place it. Firefangledfeathers (talk / contribs) 17:53, 25 January 2024 (UTC)

You’re really just muddying the water, and so rendering this talk item ineffective. Which is sad. If there aren’t any better focused comments from other editors, I will just edit the main page and wait for any reaction. MapReader (talk) 18:02, 25 January 2024 (UTC)

Please don't. With your support of a change to the guideline and my opposition, we're short of the consensus need to ensure that the change is "faithfully reflecting the community's view", as required by WP:PGCHANGE. I am sorry that my answers have muddied instead of clarified the waters, and I hope someone new can either explain your points to me or mine to you. Firefangledfeathers (talk / contribs) 18:09, 25 January 2024 (UTC)

This is also how I interpreted it: When deciding whether to write an ordinal in words or figures, look up the cardinal equivalent in the section above and apply that to the ordinal. I think this is also supported by the proper names and technical terms paragraph which doesn't differentiate between cardinal and ordinal examples. —-Mgp28 (talk) 23:43, 25 January 2024 (UTC)

Following this ambiguity, would there be any appetite for changing the first bullet point under 'Ordinals' to something like

* The decision whether to write an ordinal using figures or words, e.g. 15th or fifteenth, should follow the same principles as § Numbers as figures or words. Generally, for single-digit ordinals write first through ninth, not 1st through 9th.

Mgp28 (talk) 04:58, 27 January 2024 (UTC)

Sure. Firefangledfeathers (talk / contribs) 05:05, 27 January 2024 (UTC)

Yes. Firefangledfeathers and Mgp28 seem to be parsing the material as-intended, while MapReader was not, and might not be alone in that, so just clarifying the cross-reference in this manner should resolve the issue.  — SMcCandlish ☏ ¢ 😼  02:37, 28 January 2024 (UTC)

Thank you. I've made the change.

I'm not sure if MapReader had seen the suggestion. Please let me know if you don't think this sorts the issue. Thanks Mgp28 (talk) 12:23, 28 January 2024 (UTC)

Please can someone say what the “principle” we are supposed to be following, in deciding between “fifteenth”, or “15th”, actually is? Or are? For example, I want to edit into an article, ”Mr X was a prolific author and this was his fifteenth/15th book” - explain to me how I use the cross-referred section to make my decision? MapReader (talk) 06:17, 29 January 2024 (UTC)

Unless there's more to the context, either form would be fine in that example. Firefangledfeathers (talk / contribs) 01:36, 30 January 2024 (UTC)

So, as I said, pointing to the section above for guidance on the "decision" was not helpful, since there is no such guidance there. Hopefully this is now resolved with the tweaked wording? MapReader (talk) 09:01, 30 January 2024 (UTC)

I think the relevant bit of guidance is Integers greater than nine expressible in one or two words may be expressed either in numerals or in words.

Regarding the separation of the words and figures and ordinals sections, I think the general layout is meant to be that words and figures is a general section that applies to ordinals as much as it does to cardinals. The ordinals section is then primarily about suffixes and dates.

I think the hyperlink to the previous section is fine because people don't necessarily read the manual of style in order. If they arrived via the MOS:ORDINAL link, they may not know that the words and figures guidance is just above.

I'm content with the current text but might also suggest losing "same" and "also": The general principles set out in § Numbers as figures or words apply to ordinals. Mgp28 (talk) 10:15, 30 January 2024 (UTC)

A sensible Copyedit. Making things shorter is often good, esp in the MoS! MapReader (talk) 13:40, 30 January 2024 (UTC)

"Either form would be fine in that example" (of 15th or fifteenth) is not correct, though (for most situations, anyway); MoS means to use 15th because we use 15 not fifteen (under most circumstances). How is there still any confusion about this?  — SMcCandlish ☏ ¢ 😼  23:32, 1 February 2024 (UTC)

I have boldly had a go at some clearer wording, in the article. It removes the example, which was not helpful. Even my shorter wording includes both the cross-reference and the shared principles; if the only other pertinent principle is “don’t mix and match formats” it might be more straightforward simply to restate that principle for ordinals, and delete the cross-reference altogether. Referring to the paragraph immediately prior with a section link isn’t great practice, since it implies sloppy drafting. Alternatively, if the same set of principles apply to both cardinal and ordinal numbers, why do we need separate sections for these in the first place? MapReader (talk) 06:37, 29 January 2024 (UTC)

It might be better to merge them, if it makes the confusion go away and produces shorter wording with less crossreferencing. All three results appear likely. Simply saying "cardinal or ordinal numbers" and including examples of both should be sufficient.  — SMcCandlish ☏ ¢ 😼  23:32, 1 February 2024 (UTC)

End dates, when they end at midnight.

At the stroke of midnight, beginning on 1 January 1801. The Kingdom of Great Britain & the Kingdom of Ireland merged to become the United Kingdom of Great Britain and Ireland. Here's the question - Which is the correct end date, for the Kingdom of Ireland & the Kingdom of Great Britain? Is it 31 December 1800 or 1 January 1801. GoodDay (talk) 03:40, 5 February 2024 (UTC)

Depends on whether midnight means 00:00 (ie start of 1 Jan) or 24:00 (ie end of 1 Jan).  Stepho  talk  05:56, 5 February 2024 (UTC)

The 31 December 1800 is the last day the two old kingdoms existed. Gawaon (talk) 06:14, 5 February 2024 (UTC)

This is an interesting question, and one that I don't think has a properly-defined answer. In the Army, they avoid ambiguity by never using the term "midnight" - they say things like "this pass expires at 23:59" or "the operation will commence at 00:01". Similarly, barring death of the incumbent, the U.S. presidency changes hands at noon (Washington time) on 20 January of the year following an election, or another date as arranged: I shall resign the Presidency effective at noon tomorrow. Vice President Ford will be sworn in as President at that hour – Richard M. Nixon, August 8, 1974.

In the world of railways we have a similar problem. Our many thousands of articles about railway stations have information like the opening date, plus the closing date where relavant. Opening dates are easy; it's the day when the first public train ran. But closing dates are more difficult - some RSs give the date when the last public train ran, others give the date when no trains ran that (barring closure) would otherwise have run. If a station was last served by trains on 31 December, some books will give that date, others will say that it closed on 1 January. It's more complicated when the station previously had no service on Sundays and public holidays - in Scotland, which has two days public holiday for Hogmanay, it's conceivable to have a station where the last train ran on Saturday 31 December, but the "closure" date is given as Wednesday 4 January (no Sunday service on 1 Jan, no bank holiday service on 2-3 Jan, as happened in January 2023).

All in all, I would say to go with the last date when the two constituent kingdoms were separate, i.e. 31 December. --Redrose64 🌹 (talk) 12:08, 6 February 2024 (UTC)

Our article "12-hour clock" addresses this, and cites a page from one of the two agencies in the US charged with disseminating time: the National Institute of Standards and Technology. (The other is the Department of Defense.) The relevant NIST page indicates there is no universal convention and says "to avoid ambiguity, specification of an event as occurring on a particular day at 11:59 p.m. or 12:01 a.m. is a good idea". Jc3s5h (talk) 12:23, 6 February 2024 (UTC)

The union was effective as soon as it was the first of January. The linked article Acts of Union 1800 has external links to the legislation including The Union with Ireland Act 1800, which has

that the said Kingdoms of Great Britain and Ireland shall, upon the first Day of January which shall be in the Year of our Lord one thousand eight hundred and one, and for ever after...

and so the last day the kingdoms were separate was 31 December. "At the stroke of midnight" is a red herring; the drafting is smarter than that. NebY (talk) 12:24, 6 February 2024 (UTC)

One of the unfortunate side effects of a 12-hour clock. 24-hour clock is unambiguous: a day starts at 00:00 and ends at 24:00. -- Michael Bednarek (talk) 13:09, 6 February 2024 (UTC)

Actually 24:00 doesn't exist – that would be 00:00 the next day. Gawaon (talk) 13:35, 6 February 2024 (UTC)

I can assure you, 24:00 is widely used. You may want to consult ISO 8601. Talk:24-hour clock/Archive 1 is also interesting. -- Michael Bednarek (talk) 13:59, 6 February 2024 (UTC)

Well, I have yet to see a clock that shows 24:00. ISO 8601 allows lots of things, not all of which are good practice. But sure, you can use 24:00 if you really want to. Gawaon (talk) 15:40, 6 February 2024 (UTC)

You're not looking hard enough: Commons:Category:Time 24:00. -- Michael Bednarek (talk) 15:44, 6 February 2024 (UTC)

It isnt if you are talking about 'when school starts at 9' or 'your exam starts at 1' because why would school start at night or exams begin after midnight? But when it comes to 'their train leaves at 7' you see a problem thinking the train leaves at 19:00 (7:00 pm) when it actually left at 07:00, hence why UK railway stations use 24 hour clock, even in spoken text so here is my example of an announcement: (not a real train timetable)

• 'the next train to arrive at platform five, will be the 14:24, East Midlands Railway service, to Sheffield.'

14:24 is pronounced as 'fourteen twenty-four'. if it is 0 mins past the hour, then after 10:00, it says eleven hundred, twelve hundred, thirteen hundred, etc.

See also: Wikipedias example at 12 hour clock:

• '...if one commutes to work at "9:00", 9:00 a.m. may be implied, but if a social dance is scheduled to begin at "9:00", it may begin at 9:00 p.m.'

Basically in short, context and common sense is used if 12 hour time is used without am/pm but in some cases, such as railway stations, can be ambiguous. JuniperChill (talk) 21:47, 6 February 2024 (UTC)

To a normal human, the answer is "ended 31 December 1800", because 12:00 (or 24:00 if you prefer that style) is how this get conceptualized by most people; "00:00" is a rather modern and computery idea. When 31 December ended, so did the original polity, and when 1 January started at the same moment so did the replacemet polity. I would not be sensible to say that the original one survived into 1 January, because it did not. Same goes for saying that the new one started at the end of and within 31 December; it just didn't.  — SMcCandlish ☏ ¢ 😼  07:15, 9 February 2024 (UTC)

Prefer words over figures in comparable numbers?

I reverted a recent change by MapReader and wanted to expand on my reasons. For ease of reference, the change in question added the following* at the end of the rule about comparable values needing to be styled the same:

Where all the numbers can be spelled straighforwardly, prefer this (for example nine and twelve, four and one hundred, or eight and fifty-one) but use figures where spelling would be cumbersome (3 and 157, or 9 and 1,032).

Among my objections:

1. The general rule is that words and figures are both fine, except when clarity, concision, convention, or some other important consideration demands otherwise. I don't see such a reason here.
2. "spelled straightforwardly" and "cumbersome" are unclear. The examples suggest the existing "one or two words" rule applies.
3. The guidance clashes with the example given earlier ("ages were 5, 7, and 32") and the sub-item about mixed units, where both figures and words are presented as appropriate.

If there are good reasons for the change, I could get behind it, and many of the other issues are fixable. Looking forward to hearing more. *The effect of intervening edits by Dondervogel 2 and MapReader is the removal of the "eight and fifty-one" example, but it doesn't factor into my objections either way. Firefangledfeathers (talk / contribs) 02:07, 30 January 2024 (UTC)

The challenge to the current draft is that the general rule isn't as you state. The general rule is that single digit numbers are spelled out, and that otherwise there is editor choice (the criterion/a nowhere specified - another weakness) except that there should be consistency within proximate related values. Logically this ought to mean that a formulation like "nine and twelve" is always spelled out, to meet both rules. But we have an example, as currently drafted, sitting as an exception (I have tried to tweak this previously to deal with the contradiction, but this too was reverted).

In my view our examples should exemplify what has already been described - not introduce a new guideline that is nowhere explictly stated (and our title "notes and exceptions" is both lame and unhelpful). My edit just reverted was an attempt to be explicit about the criteria to bear in mind when making the choice between figures and spelling, and is - I suggest - what editors already do in practice.

I recognise your (2) that it's imprecise, but I considered that trying to be precise and specific would be equally problematic (and just as likely to be reverted as my making up a new 'rule' on the hoof). In real editing it is unclear, because it depends considerably on context, and ISTM that a loose guideline as to whether to use figures or spelling would be better than no guidance at all.

The TLDR is that our guidance states boldly "Integers from zero to nine are spelled out in words" and then goes on to give an example/exception of correct usage "ages were 5, 7, and 32", which is neither an example nor an explained exception. MapReader (talk) 08:57, 30 January 2024 (UTC)

I would probably be inclined to follow the additional advice MapReader added, including the "eight and fifty-one" example. As stated, if all earlier guidance can be followed simultaneously, that feels optimal.

However, I'm not certain we need to add it as a rule. I don't feel that "5, 7, and 32" is necessarily wrong. Sometimes (outside Wikipedia) I see numbers that have been written to obey a rule that end up feeling quite unnatural, so I'm inclined to prefer that we don't have more rules than are needed. If we do adopt this into the MOS then it may as well be clear, so I agree that "in one or two words" feels more consistent than "spelled straightforwardly". Mgp28 (talk) 10:29, 30 January 2024 (UTC)

PS To write "three and one hundred and fifty seven" would feel wrong, so the "3 and 157" example also seems wise. Mgp28 (talk) 10:39, 30 January 2024 (UTC)

As above, I don’t think we need (nor would it be easy to produce) a hard and fast rule to decide every case. The broad thrust of the guidance we want is that spelling out is preferred for short numbers, because figures tend to interrupt the readers’ flow, whereas longer numbers should be in digits to avoid long strings of spelled out numbers when we can just say ‘1,032’. The ‘disagreement’ above over ‘fifty-one’ illustrates that people will have different views as to what is cumbersome and what is not. The example “5, 7 and 32” is unhelpful because, with the current wording, the contradiction with the general rule, ‘spell out single digit numbers’ isn’t justified or explained. MapReader (talk) 13:45, 30 January 2024 (UTC)

I'm in agreement with "not certain we need to add it as a rule. I don't feel that '5, 7, and 32' is necessarily wrong". For giving people's ages, that would actually be entirely normal, and less cumbersome both for editor and for reader than the written-out form. This sort of thing should be left to editorial discretion. "the contradiction with the general rule ... isn’t justified or explained": then just explain it, e.g. "when short and long numbers are juxtaposed, normalize them to the same style. Prefer numerals over words when the result would be awkward." PS: "one hundred and fifty seven" wouldn't comply with our style guide anyway, and many editors not even knowing that it should be "one hundred fifty-seven" or "one hundred and fifty-seven" by MoS (with the dispute about the excrescent "and" never resolved that I know of) is a good reason to not force them to write out such constructions just to agree with an initial default of doing "five" and "seven".  — SMcCandlish ☏ ¢ 😼  23:17, 1 February 2024 (UTC)

Seems to me that we really prefer numbers to be written in digits, but we allow them to be spelled out in some contexts. We just aren't quite clear on how to write out what those contexts are. --User:Khajidha (talk) (contributions) 16:28, 12 February 2024 (UTC)

Do we add "born" in front of the birth date in the lead, where "née" is present?

Moved from Wikipedia talk:Biographies of living persons § Do we add "born", in front of the birth date, in the lead?

GoodDay (talk) 05:01, 16 February 2024 (UTC)

An editor is in disagreement with me at Kamila Magalova, as to how to handle the intro of living. Do we add or 'not' add "born" in front of the birth date, in the lead. GoodDay (talk) 01:20, 16 February 2024 (UTC)

MOS:BIRTHDATE indicates that "birth and death labels are included only when needed for clarity". Nikkimaria (talk) 01:23, 16 February 2024 (UTC)

It also says to add "born" in the intro of BLPs. Anyways I've opened a discussion at the BLP for input. GoodDay (talk) 02:03, 16 February 2024 (UTC)

It gives examples of including the label, but I'm not seeing where it says born must be added? Nikkimaria (talk) 02:06, 16 February 2024 (UTC)

Look closer, at the bottom, the Sally Wong example. PS - Would you recommend deleting "born" from the intros of BLPs & just leave the birth date? GoodDay (talk) 02:08, 16 February 2024 (UTC)

The Sally Wong example indicates the format for use in lists, not general bio articles.

The article in question already uses "née"; I don't see a need to add "born" to that. Nikkimaria (talk) 02:11, 16 February 2024 (UTC)

So you would have just "(December 25, 1971)" for Justin Trudeau's intro? GoodDay (talk) 02:19, 16 February 2024 (UTC)

No - what I'm saying is it doesn't make sense to have two labels, not that we should have none. Nikkimaria (talk) 02:31, 16 February 2024 (UTC)

MOS:NEE provides more than one example with exactly those two labels. As I wrote on the talk page of an individual article, because we are writing in English not French here, and even though in French "née" means the same as the English "born", in its English meaning "née" is more specifically about names. So readers of English rather than French still need to see "born" in front of the date to clarify that it is a date of birth rather than some other date; I don't think we can reasonably expect them to know enough French to use the French meaning of "née" instead of the English meaning. —David Eppstein (talk) 06:31, 16 February 2024 (UTC)

MOS:DOB does recommend the use of "born". I don't think it makes sense to double up where 'née' is present, but cases like Trudeau's benefit from 'born' for sure. Firefangledfeathers (talk / contribs) 02:28, 16 February 2024 (UTC)

Yes, we add "born" when we are giving only one date. It is "needed for clarity": without it, we would not know whether it is a birth or death date. (Using verb tense is too ambiguous.) See also the "Nationality examples" section, later, which includes another "born". —David Eppstein (talk) 02:28, 16 February 2024 (UTC)

In cases like this, where policy/guideline examples may not be clear, I like to look at examples in featured articles. I just checked probably 90 to 100 articles, and noticed that "born" is used:

1. When the subject had a different name at birth (ex: Alexis Bachelot, Chinua Achebe, Maya Angelou, Honoré de Balzac)—though this does not seem to apply when we list maiden names (ex: Josephine Butler).

2. When the subject is still alive (ex: Ann Bannon, Amy Adams, Ben Affleck, Angel Aquino, Vidya Balan, Christian Bale, Eric Bana). Similarly, we use "died" when we don't have a birthdate (ex: Ælfwynn, wife of Æthelstan Half-King and Abishabis.

At Kamila Magálová, it seems like "born" is appropriate, not because of her maiden name but because she is still alive. Woodroar (talk) 02:29, 16 February 2024 (UTC)

Would "(Slováková) (born 16 November 1950)" be acceptable? If "(Slováková; born 16 November 1950)" isn't? GoodDay (talk) 02:35, 16 February 2024 (UTC)

I'm still looking through featured articles. The only similar articles I've found are Priyanka Chopra, Kareena Kapoor Khan, and Courtney Love. All use "(née Name; born date)". Woodroar (talk) 02:43, 16 February 2024 (UTC)

If I were writing that article, I'd have thought something like Kamila Magálová (née Slováková; born 16 November 1950) would be appropriate. Pretty sure I've seen wording like that on plenty of articles. Sideswipe9th (talk) 02:46, 16 February 2024 (UTC)

I tried to make that change, but kept getting reverted. GoodDay (talk) 02:56, 16 February 2024 (UTC)

@Revirvlkodlaku: You're invited to give your input here, too. GoodDay (talk) 02:55, 16 February 2024 (UTC)

This entire discussion is what our MOS pages are designed to address. I suggest that any decision here be implemented there, and taking the entire discussion there would not be inappropriate, either. Jclemens (talk) 04:19, 16 February 2024 (UTC)

Moved from WT:BLP talk. GoodDay (talk) 05:02, 16 February 2024 (UTC)

'born' should be added - it provides crucial context to what otherwise might appear to be a meaningless date. The wording suggested by Sideswipe9th and supported by GoodDay looks correct. GiantSnowman 11:57, 16 February 2024 (UTC)

Clarification on mixed numbers

Personally, I don't think there's any lack of clarity at all, but maybe there is. User:Chris the speller is making changes en masse to prose citing MOS:FRAC changing seemingly every instance of "x and a half" written out to {{frac|4|1|2}} and the like (example diff, but this isn't done on just one article, it's being done on many). Here's the relevant line:

• Mixed numbers are usually given in figures, unspaced (not Fellini's film 8 1⁄2 or 8-1⁄2 but Fellini's film 8+1⁄2 – markup: {{frac|8|1|2}}). In any case the integer and fractional parts should be consistent (not nine and 1⁄2).

The implicit and obvious comment here is that this only applies when talking about the number specifically, in say a mathematical or numerological context where the number-as-number is important. If it's just a vanilla measurement like four and a half teaspoons (roughly) or four and a half miles (loosely), spelling it out is fine. It's possible that an editor might use a fraction, but it's certainly not required, and mass changes along this line are "fixing" a non-existent problem.

I'm not sure there's even any change to the MOS required here, just a validation that yes, Chris the speller's interpretation is incorrect? Alternatively, if somehow Chris the speller's interptation of this line as mandating using the frac template rather than spelling out "X and a half" (even when the frac template unduly draws attention to a meaningless amount, like loosely half a year), then maybe we do need to modify this line to be more restrictive that it's talking about numbers-as-numbers only, not numbers used as units of measurement, etc. SnowFire (talk) 03:50, 24 February 2024 (UTC)

Your second edit to my talk page caused a conflict just as I was saving my reply. It would have been nice to wait and hear what I had to say: please go read it now. Chris the speller ^yack 04:16, 24 February 2024 (UTC)

Well, you've mostly verified that we should have this conversation here, since you think you're right. You've misinterpreted this guideline, which is why I'm asking you to stop your edits until you can verify that this guideline is actually mandating what you think it is. There is no blanket prohibition to writing out "five and a half" or the like, especially for vague, imprecise rounded figures trying to get a gist. This guideline is specifically about numbers as numbers, which is not the case in basically any of your 500+ recent edits on the matter. SnowFire (talk) 04:20, 24 February 2024 (UTC)

The guideline generally recommends the use of figures, but it's clear that the use of words is permissible. The line "In any case the integer and fractional parts should be consistent (not nine and 1⁄2) implies that consistent use of words is fine. There's an example given in the prior section, §Singular versus plural, that approves of "one and one-half doses". Firefangledfeathers (talk / contribs) 04:28, 24 February 2024 (UTC)

@Chris the speller: To go back to the merits of the case, the relevant part of MOS:FRAC is this:

• Where numerator and denominator can each be expressed in one word, a fraction is usually spelled out (e.g. a two-thirds majority; moved one-quarter mile); use figures if a fraction appears with a symbol (e.g. 1⁄4 mi – markup: 1⁄4 mi, not a quarter of a mi or one-quarter mi). A common exception is a series of values: The distances were 1+1⁄4, 2⁄3 and 1⁄2 mile, respectively.

But you know this already because this was already cited in this edit, which you also reverted. All of these cases you've changed are this case that asks for spelled-out fractions like "one-quarter mile." I don't understand why you're using the sentence on numbers-as-numbers like 8+1⁄2 (which isn't measuring anything and is a number-as-a-number) in edits like this recent one changing one and a half years to a fraction. SnowFire (talk) 04:27, 24 February 2024 (UTC)

I'm done trying to point out the difference between fractions and mixed numbers to someone who appears unable to understand. The MoS guidance on mixed numbers does not mention anything about "numbers-as-numbers". The MLB Advanced Media article had an improperly formatted mixed fraction. I haven't changed anything like "one-quarter mile." Chris the speller ^yack 04:38, 24 February 2024 (UTC)

It's improperly formatted in that it should have said "one and a half years" rather than "one and half", but that isn't the fix you made.

Anyway, I guess we've found our problem: you think that this line only applies to "pure" fractions like one-quarter, not one and a quarter. As Firefangledfeathers says above, I don't think that's the intent given that a spelled out mixed fraction is used elsewhere as an example. Would explicitly adding an example of a mixed fraction to this line satisfy you that spelled-out fractions in prose are covered as well, here's how they're done, etc.? "Four and a half years" is common English, not a style violation. The line on mixed numbers is clear from context to be talking about "mixed numbers in a mathematical sense" but I don't see a way to phrase that cleanly and nobody else seems to have had an issue with it. SnowFire (talk) 04:58, 24 February 2024 (UTC)

• I don't care what the guideline says, this edit [28] is clearly inappropriate. In fact, it looks completely ridiculous. I'm the one who wrote the phrase "usually given in figures" into the guideline ten years ago, but for the life of me I don't know what I was thinking. I've removed it [29]. EEng 05:09, 24 February 2024 (UTC)

@EEng: Take a look at the policy page WP:OWN: "No one, no matter what, has the right to act as though they are the owner of a particular article (or any part of it)". Please restore the MOS:FRAC guideline until there is consensus to change it. If it has been that way for ten years, it should remain unless and until we find a a good reason to change it. There's no hurry here. Chris the speller ^yack 14:57, 24 February 2024 (UTC)

Making a bold change to remove something being interpreted as implying articles should say ridiculous things like "He was at the school 1+1⁄2 years" isn't ownership. EEng 15:51, 24 February 2024 (UTC)

The implication that I can't read and understand written English, which Snowfire has made repeatedly, is somewhat undermined by the fact that EEng has rushed to change the MoS to now support Sunfire's claims. Maybe I did read it correctly. Maybe an apology is in order. Chris the speller ^yack

I didn't rush to do anything, nor do anything to support anyone's claims. I removed an inflexible guideline which was clearly wrong. I've now made another edit [30], for consideration by my esteemed fellow editors, which brings the guideline on this particular point in line with well-established guidance elsewhere on the page. EEng 15:51, 24 February 2024 (UTC)

If the accusation that I don't properly interpret the MoS is true, I'm not the only one with a reading disability: Firefangledfeathers stated above "guideline generally recommends the use of figures". --Chris the speller in such a rush he forgot to sign

If you're quoting their comment, quote it in full: FFF also said in the same exact sentence that it's "clear that the use of words is permissible". You don't appear to agree since you were replacing spelled-out words everywhere. SnowFire (talk) 16:22, 24 February 2024 (UTC)

• Chris: You're "standing on procedure" a lot above with comments about OWN, consensus, etc. rather than what the style guideline should be. Can we get back to discussing the merits? This line you're citing is about how to do mixed numbers with numerals if you are already using numerals. That's fine. Nowhere does it say that using numerals is required. Can you cite a style guideline or style example elsewhere as reason to prefer your apparent preference for a mandate for the use of numerals? Or just some other reason it's "better" to do that compared to "four and a half years"? Again, I don't think anyone else has really interpreted the guideline the way you have, and it's not just the people here - it's the multiple separate editors in good standing who reverted you in your edit above who don't think such a mandate is common English. SnowFire (talk) 16:22, 24 February 2024 (UTC)

Anybody looked at the use of mixed numbers in sports? The Washington Post and LA Times report "games behind" in baseball standings almost always in figures. WP had 16 articles with properly formatted "xx and a half games behind the" – 10 articles with improperly formatted "xx-and-a-half games behind the" – 10 articles with some form of figures "xx+1⁄2 games behind the". And no, this is not a result of changes made by me. I have not analyzed horse lengths or track lengths in racing, but I expect to find something similar there. A ratio of 16:10 for correct:incorrect spelled-out mixed numbers should strike most editors as unsatisfactory. Shouldn't we get a grip on the use of mixed numbers in cases other than literary prose before we go flipping the MoS without a consensus? Chris the speller ^yack 17:29, 24 February 2024 (UTC)

"5+1⁄2 games behind" might have its uses; "five and a half games behind" (or maybe "five-and-a-half games behind" -- I always get that mixed up) might have its uses; "five and a 1⁄2 games behind" would never be acceptable. Beyond that I can't tell what you're talking about. For sure not every mixed number is always given in figures, which is what you seem to be saying the guideline might reasonably say. EEng 18:03, 24 February 2024 (UTC)

My search was faulty. I missed 107 cases of "xx+1⁄2 games behind the" where the Frac template was used. Wikipedia and newspapers predominantly use figures for games behind, and probably for innings pitched. I think it is a very bad idea to ignore these facts when loosening up the MoS. Chris the speller ^yack 19:01, 24 February 2024 (UTC)

There is nothing in the MOS, "loosened" or not, that forbids such expressions. Also, the only thing that has happened was that an obvious oversight has been corrected – forbidding expressions such as "two and a half years" was certainly never the intent of the MOS. Gawaon (talk) 19:05, 24 February 2024 (UTC)

FWIW, I prefer Mapreader's

example to that of EEng. Dondervogel 2 (talk) 20:38, 25 February 2024 (UTC)

I think it's pretty clear that MOS has said for ten years that mixed numbers should be in figures, whether used as a measurement or a number per se, and regardless of whether other numbers elsewhere in the article are in words, except in unusual cases. And that Wikipedia style rules should not be changed without consensus.

As for which is the better style, that is less clear, but I prefer figures for mixed numbers for the same reason I prefer figures for large numbers. "Two-thirds" is reasonable to me, but "one and two-thirds" is exhausting. In prose where figures would be awkward, I'd rather not see mixed fractions at all (e.g. not "one and a half years", but "a year and a half"). I do feel strongly that Wikipedia should pick a style. If MOS just says "either way is fine", then the only thing that can determine the style of an article is article ownership, which I oppose. ("This article spells out mixed fractions because it was written by John, and Johns prefers to spell them out"). Bryan Henderson (giraffedata) (talk) 19:50, 26 February 2024 (UTC)

Primary Unit

The UK and the USA get their units as the primary unit.

In all other articles, the primary units chosen will be SI units (such as kilograms), 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 (such as revolutions per minute (rpm) for rotational speed, hands for heights of horses, etc.)

Or such other Units…, How and when did this get into the MOS? Anyone can still put in x metres (x hands) for the height of horses, many editors think this allows non SI units like PS or hp as the primary unit, disregarding the first line statement “will be SI units”.

The preponderance of editors on Wikipedia appear to reside in the UK and the USA. The only area the above applies to is the “rest of the World”, This leads many people to assume they can use any non SI unit as the primary unit, This is not the way I read it. “or such other units as are conventional in reliable-source discussions of the article topic (such as revolutions per minute (rpm) for rotational speed, hands for heights of horses, etc.) needs to be removed. Avi8tor (talk) 14:26, 11 February 2024 (UTC)

There are plenty of contexts where SI units are not conventional in reliable source discussions of article topics, no matter what the national context is. Examples are feet for aircraft height, light years and parsecs for astronomical distances, and months and years for time durations (such as people's ages). In some of these contexts it would be inappropriate to use SI units even as secondary - who would benefit from a rule that insists that Usain Bolt be 1.18 gigaseconds old instead of 37 years? Kahastok talk 14:59, 11 February 2024 (UTC)

It's no good the MOS stating "the primary unit chosen will be SI" when there is an exception everyone can use. Feet can be the supplemental unit for altitude, parsecs and light years or AU for space distance. People's ages in gigaseconds is stupid, there is no convert template for giving someones age so it's superfluous and years are used worldwide. We are talking about some of the planet who speak English using units the other 95% do not use. Avi8tor (talk) 17:20, 19 February 2024 (UTC)

Isn't the protection against non-SI units being used inappropriately given in the requirement that they have to be discussed in reliable sources? Mgp28 (talk) 18:58, 19 February 2024 (UTC)

It goes further than that - they have to be conventional in reliable sources, which implies some level of broad acceptance across a range of sources. Kahastok talk 19:10, 19 February 2024 (UTC)

I suggest that if you believe that the idea of requiring SI units for people's ages is "stupid", perhaps you ought to reconsider whether you feel we should remove the part of the guideline that allows us to use more conventional units? Kahastok talk 19:10, 19 February 2024 (UTC)

Define conventional units?

Does anyone on the planet use other than years for age? unless it's months for a baby or toddler? Avi8tor (talk) 13:13, 20 February 2024 (UTC)

Not as far as I am aware. This is my point. Your proposal would require us to use megaseconds and gigaseconds for measuring people's ages, because the conventional unit - the year - is neither SI nor officially accepted by SI. I am opposing that proposal.

(Incidentally, the month is also not accepted by SI, for the same reason - not all months are the same length). Kahastok talk 17:15, 20 February 2024 (UTC)

I think this is getting off topic, my comments refer only to Units of measurement Unit Choice and Order which in Wikipedia use the convert template because some of the planet use US customary, the UK has imperial and metric and the rest of the planet is metric. I'm not suggesting we use mega or giga second when everyone (as far as I'm aware) uses years for age. Age is dealt with in the previous section of the MOS. Avi8tor (talk) 08:34, 21 February 2024 (UTC)

I don't think it's getting off topic at all. Proposals sometimes have unintended consequences. You may not be intending to replace the year with the megasecond or gigasecond - and this doesn't just affect ages but any period of time measured in months or years - but that is the effect of your proposal. Kahastok talk 18:45, 21 February 2024 (UTC)

Don't be absurd. Gawaon (talk) 18:48, 21 February 2024 (UTC)

The fact that the proposal is that we do things that are absurd is a good reason not to adopt the proposal.

If you want to claim that that is not the effect of the proposal, I suggest you go away, look up SI and the units officially accepted for use with SI, and try and find where they define the month and the year. I'll give you a hint - they don't. Kahastok :talk 19:28, 21 February 2024 (UTC)

That is such a fundamental misreading of SI that it is difficult to AGF. The SI does not a have a standard month. Nor does it have a standard rock, standard elephant, etc etc. It has no significance whatever and I agree with User:Avi8tor and Gawaon that this is wildly off topic. The {{Colonel}} is getting ready to come on set. You give the appearance of arguing for the sake of arguing. --𝕁𝕄𝔽 (talk) 20:25, 21 February 2024 (UTC)

People don't measure things in rocks or elephants. People do measure things in years. The SI unit of time is the second. The minute, the hour and the day are allowed as units of time in SI. The month and the year are not.

The proposal is that we should be required to use SI, even where other units are conventional and SI units are not. Even in contexts where no serious reliable source would ever consider using SI, Wikipedia would be the outlier.

For example, most of the world uses feet for aircraft altitude. Wikipedia would not. The foot is conventional but it is not SI.

For example, most of the world uses inches for digital display sizes. Wikipedia would not. The inch is conventional but it is not SI.

Practically every astronomer on the planet measures interstellar distances in light-years or parsecs. Wikipedia would not. The light-year and parsec are conventional but they are not SI.

And yes, everyone in the world measures long periods of time in years. Wikipedia would not. The year is conventional but it is not SI.

None of that is a misreading of SI. It's the natural consequence of this proposal. You don't like that? Change the proposal. Kahastok talk 21:08, 21 February 2024 (UTC)

I don't think I understand the benefit of the proposed change. The Unit choice and order section currently seems generally sensible, if a little long-winded. In summary, I interpret it as saying we should use the units found in reliable sources. We then have some guidance on what we can expect those to be. The UK and US have idiosyncratic unit systems so get special mention (I think for this reason, not because of the nationality of editors) ,then for the rest of the world we expect to use SI units except where we find that the sources all say otherwise.

Define conventional units: Those which are used by reliable sources. I interpret this reliable-sources requirement as preventing the use of any unit of choice, or rocks, as the primary unit. But I think there needs to be some allowance for using non-SI units. It would be very strange to convert engine speeds from revolutions per minute to hertz, and, yes, adults' ages really must be given in years.

I interpret some comments above as suggesting that conventional units such as years are so obvious that we don't refer to this MOS when deciding to use them. But taking organ pipes as a less obvious example (because it's discussed at the top of this talk page, not because I know about the subject), it isn't hard to imagine someone diligently going around and changing the pitches on all organ pipes outside the UK and US to metric measures if that's what the guidance suggested.

Perhaps it would help to have some specific examples of problems caused by this clause (or such other units as are conventional in reliable-source discussions of the article topic (such as revolutions per minute (rpm) for rotational speed, hands for heights of horses, etc.)) that would be helped by deleting it? Thanks, Mgp28 (talk) 07:54, 22 February 2024 (UTC)

I agree with Mgp28; I don't have statistics, but if This leads many people to assume they can use any non SI unit as the primary unit, then those people need to reread it; In all other articles, the primary units chosen will be SI units (such as kilograms), 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 (such as revolutions per minute (rpm) for rotational speed, hands for heights of horses, etc.) (emphasis added) says nothing of the sort. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:19, 22 February 2024 (UTC)

Leaving the guidelines as they are leads to edit warring. Editors can cherry pick their sources. Age is irrelevant here because it's dealt with in a prior part of the MOS under "Dates, months, and years". Scientific articles are all SI primary. Aircraft altitudes can be metres (feet). Living in a non metric country like the UK or USA gives people the impression the whole planet is likely using "their" units. Pilots worldwide (except Russia, China and Mongolia) might use feet for altitude but non pilots (passengers) probably know nothing of feet. This applies particularly in Australia, New Zealand, South Africa and former British colonies which converted to metric in the 1960's, more than 50 years ago. I was in a dinner conversation with Brits and Australians. The Brits were astonished the Australians had no idea of their weight in stones, they used only kg. The same goes for height, anyone under about 45 years old in the above countries has no idea what feet and inches are, they have never used them. Avi8tor (talk) 07:24, 23 February 2024 (UTC)

Isn't Astronomy a science?

How is the speed of a ship given outside of US and UK? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:07, 23 February 2024 (UTC)

Sailors will probably use knots; for lay people (i.e. the typical readers of our encyclopedia), on the other hand, kilometres per hour will be easier to understand. Like with aircraft, where chiefly professionals use feet, while our typical reader likely isn't a professional pilot. Gawaon (talk) 21:23, 23 February 2024 (UTC)

I've just scanned Bowditch and charts made to INT (international) standards (according to the IMO) use heights/depths in metres and distances in nautical miles (though US charts are only being slowly converted). the latter is a slightly moot point though, since the latitude scale on either side of the chart is used to read off miles and cables. If you're using nautical miles, then it follows that you'll use knots. Martin of Sheffield (talk) 22:05, 23 February 2024 (UTC)

Yeah, that's what sailors (in the sense: "a person in the business of navigating ships or other vessels") do. I doubt lay people will often use these charts or be accustomed to thinking in the units they use. Gawaon (talk) 22:10, 23 February 2024 (UTC)

If we look at an article about a modern ship in a foreign-language Wikipedia, it ought to mention the speed somewhere. For instance, at Wikipédia en français, fr:Classe Clemenceau has an infobox saying "Vitesse 32 nœuds", i.e. 32 knots. Of note is that there is no metric equivalent. So if the ultra-metric French use knots, I don't see why we shouldn't. --Redrose64 🌹 (talk) 14:58, 24 February 2024 (UTC)

And what about astronomers? Are we to believe that it's only professional astronomers use light years while laypeople use petametres and exametres? Are we to believe that it's only experts in Canadian football that use the yards painted on the pitch, while laypeople use metres? Are we to believe that it's only experts in the music industry that measure turntable speeds in rpm, and laypeople use hertz? Or similarly car experts with engine rotation speed?

Reality is, contexts exist where the conventional usage in reliable sources is not SI. The proposal is that, in those contexts, we should not follow the conventional usage, but should religiously follow SI, no matter how incomprehensible it makes our articles to readers. Opposing this really doesn't feel like it should be controversial. Kahastok talk 21:42, 23 February 2024 (UTC)

I didn't say that and would reply that units that are used by experts and lay people alike, and throughout the world, are fine (light years and rpm, say). On the other hand, take "hands for heights of horses". How many people in continental Europe, Asia or Africa will know how much a "hand" is? I bet it's a tiny minority. So in that case the metre would be without any doubt the more international choice (and English being as widespread as it is, we do write for an international audience, so no excuses). Gawaon (talk) 22:07, 23 February 2024 (UTC)

Heaven forfend that someone might accidentally learn something by reading a Wikipedia article!

If the conventional units are not the units that laypeople - in any English-speaking country - would use, then we should be providing conversions for them per MOS:CONVERSIONS.

But, while we write for an international audience, we are an English-language encyclopedia and in every aspect of the MOS it is conventions that are used in English-speaking countries that are preferred. We do not use decimal commas. Our definition of the billion and trillion are based on the convention in the English-speaking world, even though that is different from the convention elsewhere. We put Euro and dollar signs before the number with no space, even when discussing countries where they add a space or where the sign goes after the number. There is no reason why this should be an exception. Kahastok talk 12:13, 24 February 2024 (UTC)

Err, being picky; we use the American definition of billion and trillion (10⁹ and 10¹² respectively). Traditionally English usage was 12¹² and 10¹⁸, but of recent years even august publications like The Times seem to have crossed the pond. Martin of Sheffield (talk) 12:33, 24 February 2024 (UTC)

This isn't "picky"; it's just anachronistic. We use the short scale because we live in the 21st century, and to the best of my knowledge it's a rapidly dwindling minority in the English-speaking world that's used the long scale much this side of roughly the 1970s. I suspect the vast majority of people of my generation would never have heard terms such as "milliard" and "billiard", much less recognising them as numbers, which in my own life is a usage I've not personally encountered outside French- and German-speaking Europe. Yes, the USA adopted the short scale before the rest of the Anglophone world, but calling it "the American definition" in the 2020s is a bit like calling the alphabet we're using now "those newfangled Carolingian letters" because they're not all uppercase Latin of the sort that might be chiselled on a Caesar's tomb, or even a more "indigenous" northern European writing system like Ogham or Futhark. Everything is indeed the way it is because it got that way, but for the purposes of a MOS that is usually irrelevant historical detail, I feel. Archon 2488 (talk) 19:17, 28 February 2024 (UTC)

Perhaps you missed the word "traditionally" and the phrase "of recent years" in your desperation to write off editors who started work in the 1970s. Martin of Sheffield (talk) 20:24, 28 February 2024 (UTC)

FYI South Africa uses the decimal comma and a space for thousands. Avi8tor (talk) 17:39, 24 February 2024 (UTC)

Heaven forfend that someone might accidentally learn something by reading a Wikipedia article! – a devil's advocate might well point out that this very same logic applies to the people who pretend not to know what a metre is, and any number of units vastly less obscure than the imperial hand. Archon 2488 (talk) 18:56, 28 February 2024 (UTC)

It's not that people don't know what a metre is, more that they have no feel for it. If something is 25 metres high, that's 75' plus a bit more, say 80'. Now I have a feel for how high it is. Likewise I'm sure that you could convert a furlong (if you wanted to), you just have no feel for it. Providing courtesy conversions allows our readers to flow using the appropriate units instead of having to stop, think, and then continue. Remember WP:RF? Martin of Sheffield (talk) 20:24, 28 February 2024 (UTC)

Bear in mind that other Wikipedia language articles have no need for a convert template whereas English does (because of the USA and the UK). The trouble is many articles have no convert template or don't follow the manual of style Talk:Fiat 509 and Fiat 509: Revision history (there are many more examples) or the 1814 London Beer Flood Read the "Backround" to the flood. No conversions only a footnote (a). The article talks about imperial gallons which did not exist until the 1824 Weights and Measures Acts (UK). There are quite a few people who interpret the MOS as allowing such other units as are conventional in reliable-source discussions of the article topic, leading to different interpretations of the Style guide. So while there are many instances pointed out by Kahastok, it's the way the exceptions are listed. Obviously all RPM as per the abbreviation is Revolutions per Minute. It took about 500 years to convert Europe to Arabic numerals, it will probably take that long to convert the USA to SI even if it is presently the preferred unit of measurement for trade and commerce (https://www.nist.gov/pml/owm/metric-si/metric-policy) and widely used in the USA. Temperature given to pilots at airports in the USA is in Celsius only, but wind speed is in mph despite pilot using knots. Avi8tor (talk) 17:36, 24 February 2024 (UTC)

It's not just a US and UK issue. In addition to cases previously mentioned, there's also CGS (In many fields of science and engineering, SI is the only system of units in use, but there remain certain subfields where CGS is prevalent.), although I certainly hope that SI eventually replaces it completely. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:42, 29 February 2024 (UTC)

Look at the SI brochure 9th edition from the BIPM website, we see the following:’Table 8. Non-SI units accepted for use with the SI units' [31] page 145. This includes:

Time, minute, hour and day.

Length, astronomical unit

Plane and phase angle, degree, minute, second.

Area, hectare.

Volume, litre.

Mass, Tonne & Dalton.

Energy, electronvolt.

Logarithmic and ratio quantities.

I propose we amend the MOS:Units of Measure, Unit Choice and order: To the following text only:

"In all other articles, the primary units chosen will be SI units, or non-SI units officially accepted for use with the SI".

This might mean RPM would be presented as Hz but would be followed by RPM or we add an exemption for RPM. Do we need other exceptions? Avi8tor (talk) 09:57, 2 March 2024 (UTC)

You probably need to mention which revision to use, and even then it is not straightforward. For instance the 8th edition accepts the nautical mile as "a practical unit for marine and aerial navigation to express distance".page 127 The 9th edition does not. Likewise the 9th edition bans the use of decimal prefixes for binary values: "The SI prefixes refer strictly to powers of 10. They should not be used to indicate powers of 2"page 143 whereas Wikipedia bans the use of binary prefixes and prefers to interpret decimal prefixes as binary when required.MOS:COMPUNITS Squaring the circle might be easier than coming up with a solution acceptable to all. Martin of Sheffield (talk) 10:45, 2 March 2024 (UTC)

This (from Avi8tor) was the same proposal as was made at the beginning of the thread, just worded differently. All the conventional non-SI units discussed above, that are barred by the proposal above, would also be barred by this proposal. All the objections made to the initial proposal also apply to this one. Kahastok talk 12:22, 2 March 2024 (UTC)

Which is why everyone interested has been having the above discussion. I'm not suggesting we ban any units, they can go after the SI unit, presently used by every country including the UK and the USA. The UK and USA can have whatever unit they want as the primary unit per the MOS. The SI is continually updated and the latest edition is the 9th. Note that the BIPM, which decided this stuff has representatives from the USA, the UK and 57 other member states. There is no reason to have the present poorly worded exception which allows editors to state "well my unit should be primary because it's mentioned in this or that magazine". If you look at https://stats.wikimedia.org/wikimedia/squids/SquidReportPageViewsPerLanguageBreakdown.htm (I don't think there is a more up to date breakdown) you can see that 49.3% of Wikipedia readers are from the UK and USA, meaning that the majority (50.7%) of readers live elsewhere. Avi8tor (talk) 16:50, 2 March 2024 (UTC)

The whole US and UK thing is a straw man. In fact the whole point of this exception - as much discussed above - is to cover cases where non-SI units are conventional outside the UK and US. Many of the examples of conventional units given above are not imperial or US units, so using them does not put American or British readers at an advantage. And that's even if we accept - and I don't - that Canadian readers of Canadian football articles are put at a disadvantage by prioritising the measurements drawn on the field rather than their SI equivalents. Kahastok talk 19:33, 2 March 2024 (UTC)

Ignoring a lot of discussions above (which I have been following) I think the units used in the source should take priority. The Convert template can handle conversions more reliably that editors. The Convert template has options for ordering the output in any order you desire, but the input should be what appears in the source. - Donald Albury 17:47, 2 March 2024 (UTC)

No. Different sources covering the same subject use different units. That way lies chaos. The units in any one article should be the ones specified in the MOS. The connection with sources is that the MOS typically specifies units used by a majority of reliability sources. Dondervogel 2 (talk) 18:11, 2 March 2024 (UTC)

We have quite a lot experience of this because that argument was a way some editors gamed the system in the past. You end up either with articles with units that are inconsistent from sentence to sentence, or with articles where the sources are chosen for the units they use rather than the other way round. Kahastok talk 19:33, 2 March 2024 (UTC)

Why does the Manual of Style state SI shall be the primary unit when some editors put more credence on the verbiage that follows? They pick a source and now that's the primary unit. I read the last part of the sentence as being able to use strange units after the primary unit, like hands and cubits, etc. Wikipedia does not exists for the benefit of individual editors, it's here for the public worldwide. The MOS needs to be definitive, not this or that if I so choose. Avi8tor (talk) 09:30, 3 March 2024 (UTC)

I think that there should be a list of units, other than SI units and those acceptable for use with the SI, that may be used as the primary unit. I would include

• the week, month, year, and decimal multiples of the year;
• the RPM, since the minute is acceptable with the SI;
• the light year and parsec, which are used internationally by astronomers;
• the Sun's mass and Jupiter's mass, since stars' masses are known more precisely in these than in yottagrams;
• the square degree (about 304.6 µsr), which is used in astronomy for solid angles of sky.

I would exclude the calorie and the horsepower, since they have conflicting definitions. I don't follow sports, so I'd rather see heights of horses and football fields measured in metric, whatever the source unit is. The metric equivalent should be given, though in the case of stars' masses, it has to be limited to the precision of the gravitational constant. phma (talk) 22:39, 5 March 2024 (UTC)

Use of feet in music for pitch, organ stops, wind instrument air column length

There is a whole nomenclature and system in music, particularly organology (the study of musical instruments), for describing musical pitch in terms of the length of a vibrating air column (originally an organ pipe) measured in feet. It is notated with the old prime ′ symbol for feet, such that an 8′ air column corresponds to the note C₂, the lowest C on an organ keyboard, two octaves below C₄ (middle C).

Thus, notes from a 4′ and 2′ organ stop would sound one and two octaves higher than written, respectively, and 16′ and 32′ stops sound one and two octaves lower. This notation is also used to describe the fundamental or nominal pitches of wind instruments, e.g. a contrabass trombone in 12′ F. I would like to add something to MOS:UNITS to account for this usage in music-related articles, which is still standard in music literature. Do I need to start some sort of proposal or RfC process? — Jon (talk) 03:55, 12 January 2024 (UTC)

@Jonathanischoice: This page has many subpages. As this does not come up frequently, I would suggest adding something at Wikipedia:Manual of Style/Music. The people who watch that page are probably better able to give feedback too. SchreiberBike | ⌨  23:45, 12 January 2024 (UTC)

@SchreiberBike: thanks for replying. It's not really the usage in music that's up for debate, but it occurred to me as a result of the current WP:GoCE backlog elimination drive that we perhaps need to mention the appropriate usage somewhere here in the MOS:UNITS section, so that we can avoid/clarify situations like this one about the use of feet (and the ′ symbol) in relevant music articles. Jon (talk) 20:27, 14 January 2024 (UTC)

• I can't quite tell what the issue is here. Is your concern MOS:FOOT's proscription on using the prime to represent foot/feet-- that if articles refer to "a contrabass trombone in 12-foot F", we'd look like dopes? Since I'm a musical ignoramus, can you quote a passage from some WP:RS that uses the prime notation, to give us a feel for it in context? EEng 22:21, 14 January 2024 (UTC)

Followup: I'm afarid I created some confusion by saying (above) proscription on using the prime, when I should have said "proscription on using the prime or apostrophe". I made it sound like prime-vs-apostrophe is maybe the issue. That can't be it. The issue, AFAICT, is prime or apostrophe (whichever) versus "foot" or "feet" or "ft". EEng 04:06, 15 January 2024 (UTC)

Is Westminster Abbey also here reliable enough? Martin of Sheffield (talk) 22:38, 14 January 2024 (UTC)

As an organist: if you use "foot" or "ft" once or twice in a paragraph of prose, that might be fine (particularly if you're discussing something like the physical construction or physics of organs); but anything more than that (such as on mixture) and you would indeed look like a dope. Saying 8' is, from everything I've seen, basically universal, and if you wrote "an example of a plenum is a 8 ft flute, 4 ft principal, and 2 ft principal," everyone would look at you very weirdly. I would support a MOS exception when referring to organs, possibly music more broadly but I haven't heard feet used much outside of organs. LittlePuppers (talk) 23:49, 14 January 2024 (UTC)

I have encountered several WP:RS that use it for other areas of organology, e.g. tubing lengths and other specifications for wind and brass instruments, and string lengths in keyboards (harpsichords, spinels etc.) although that said, the only one I have currently to hand at work uses e.g. 12-ft F rather than 12′ notation. — Jon (talk) 02:52, 15 January 2024 (UTC) Jon (talk) 02:52, 15 January 2024 (UTC)

If there are respected RS that write "12-ft F", it will be an uphill battle to argue that the prime/apostrophe form should be used in article. EEng 04:06, 15 January 2024 (UTC)

MOS:FOOT and MOS:UNIT have nothing to do with the nomenclature for organs and similar instruments. The use of the prime symbol is the slightly contentious issue here. The symbols &prime; ( ′ ) and apostrophe ( ' ) are almost undistinguishable, but using the former has several disadvantages, similar to Wikipedia's use of straight vs. curly symbols. Then there's the added complication of &Prime; ( ″ )vs. &prime;&prime; ( ′′ ). On balance, I would recommend using apostrophes. -- Michael Bednarek (talk) 03:19, 15 January 2024 (UTC)

(Re: Jon): Yeah, I'm less familiar with nomenclature outside of organs, but I wouldn't be surprised if the same was used.

The case of prime vs apostrophe is something we should discuss, but I do think we also need to amend MOS:UNIT. I'm doing a quick spot check of a few random organ-related articles and just under half of them are using the "ft" notation, all of them because of changes by semi-automated tools, most of them by Beland. (I'm just mentioning this to make the point that we do need more clarity in guidelines here, not to call anyone out.)

Coming back to prime vs apostrophe: could you spell out the disadvantages of the former? I would naturally default to the apostrophe, largely because it's easier to type; I was going to say that prime looks weird to me (as in Mixture (organ stop)), but that seems to be a result of {{prime}} adding some weird spacing. Usage in other articles seems to be mixed; I should go look at a few organs tomorrow and see which is more similar to the labels on their stops. LittlePuppers (talk) 03:37, 15 January 2024 (UTC)

Thanks, but please don't do that. (a) We're not going to go off that kind of OR. (b) First we need to resolve the "foot/feet/ft" question. EEng 04:05, 15 January 2024 (UTC)

Oh fine, I'll do OR for my own curiosity and not mention it here. :P LittlePuppers (talk) 04:42, 15 January 2024 (UTC)

The use of ' and " and ′ and ″ for foot and inches is also pretty universal in say, the American construction industry, including reliable sources. Wikipedia is not written for organists and American contractors; it's written for a general, international audience. Most people only know the metric system, and are unfamiliar with the use of these abbreviations for anything other than angular minutes and seconds. Presumably the MOS consensus for "in" and "ft" formed to favor intelligibility to everyone over copying the stylistic choices of professionals. Even as an American woodworker myself, I found the use of ' and " to describe pitch as confusing, and had to hunt around until I found some explanatory web pages, starting with figuring out if "8′" meant "8 prime", "8 minutes", or "8 feet". So in the articles I changed, though I wasn't involved in making the rule, I kind of liked having "ft" or "foot" written out for clarity. I think I would recommend keeping it that way. Ridicule from specialists is probably irrelevant. I'm a programmer; if an article in a computer science journal was written in Wikipedia style, it would look ridiculously out of place, but also it would be a lot more intelligible, especially to people who are not academic computer scientists. That's fine, they are just two different audiences.

But, if there's a strong consensus for the prime symbol, I recommend:

1. Tweaking {{prime}} and {{pprime}} to add the right amount of space after numbers. We're supposed to do {{prime|E}} not E{{prime}} which looks like: E′ not E′, so {{prime|8}} should look better than 8{{prime}} after tweaking. That looks like: 8′ vs. 8′
2. Have the MOS require very briefly explaining the notation in each article before using it or at the very least linking to an explanation of the notation, for which the only article I think right now is Eight-foot pitch.

--- Beland (talk) 04:01, 15 January 2024 (UTC)

Hmm, that's not a perspective I considered thoroughly. We do appear to have at least three different ways of notating it in stoplists, which all... kind of explain it? To varying degrees? LittlePuppers (talk) 04:53, 15 January 2024 (UTC)

The Grove Dictionary, pretty much the definitive English language music reference, uses primes: Compound and mutation stops may belong to any of the three flue categories and are never used without a suitable foundation (i.e. a flue stop of 8′ pitch, occasionally 4′, 2′ or 16′) (and here). I'll have a look for other RS. — Jon (talk) 09:14, 15 January 2024 (UTC) Jon (talk) 09:14, 15 January 2024 (UTC)

Grove doesn't dictate Wikipedia's MoS. Most printed and online sources use curly quotes, EN Wikipedia doesn't. -- Michael Bednarek (talk) 09:28, 15 January 2024 (UTC)

Sorry, that might well have been my fault; if we're allowed such latitude over using ft, I'm happy with apostrophes (8') since it seems there's already a consensus I was unaware of about not using primes (8′); let's just drop the whole prime thing. Perhaps all we might need is to amend the MOS:FOOT prohibition of using apostrophes/primes to indicate feet, in order to allow for its usage in music articles. — Jon (talk) 08:03, 15 January 2024 (UTC)

As an aid to readers who might not be familiar with organ-related terms, editors in this field might add a wikilink on the first occurrence of such a term, e.g. "the Lieblich Gedeckt organ stop at 8' has been …" or "the ophicleide 16' was never …". We do this regularly for specialist terms lik Op., WoO, BWV, KV, and many more. (Creating a suitable REDIRECT (organ feet?) for Organ stop#Pitch and length would be sensible.) -- Michael Bednarek (talk) 09:50, 15 January 2024 (UTC)

Beland, thoughts on this? LittlePuppers (talk) 19:37, 15 January 2024 (UTC)

Where I've used it in articles about musical instruments, I've linked its first appearance to Eight-foot pitch, e.g. French horn in 12' F but it is possible that the contents of both Organ stop and Eight-foot pitch could be reviewed and considered together (as a separate thing out of scope here?) — Jon (talk) 21:50, 15 January 2024 (UTC)

I think it's not a bad idea to explicitly mention that pitch is measured in feet if it's not clear from context, but at a minimum I'd follow the general rule of MOS:UNITNAMES which says "Units unfamiliar to general readers should be presented as a name–symbol pair on first use, linking the unit name (Energies rose from 2.3 megaelectronvolts (MeV) to 6 MeV)." I think that would mean writing e.g. "8-foot (8′)" at first use and then it would be OK to use the prime symbol for the rest of the article. -- Beland (talk) 07:52, 16 January 2024 (UTC)

@Beland: I agree with this, sorry I missed it back in January. If we are happy to use 8′ (prime) in a music/organ-related article, would you support amending the MOS to allow prime for feet in the units table, to help address situations like this one? Jon (talk) 00:39, 18 March 2024 (UTC)

I think it would be more reader-friendly to only use prime for angular measurements, but I would accept writing out feet on first instance to introduce the prime abbreviation and using prime thereafter, as suggested above (and noting whichever practice is adopted in the MOS). -- Beland (talk) 05:52, 18 March 2024 (UTC)

The phrasing proposed below on 17 March would be fine. -- Beland (talk) 05:56, 18 March 2024 (UTC)

• Musicians will say: the bass line in this movement needs a sixteen foot because the tenor goes below it a few times. There's no way to translate that into the metric system, and I believe it's used in other languages (like German and French). Tony (talk) 09:14, 16 January 2024 (UTC)

Hokely-dokely then, do we have some sort of consensus? It's gone quiet. Perhaps a tweak to the table at MOS:FOOT, something like the following. Although, I can't help but think that if we are going to make an exception for 16' notation which is for feet, then it should use prime, like we insist for arcminute further down in the same table, which would be used for old feet-and-inches notation. — Jon (talk) 08:14, 5 February 2024 (UTC)

Guidelines on specific units

Group	Unit name	Unit symbol	Comment
(Existing)	inch foot	in ft	Do not use ′ (′), ″ (″), apostrophe ('), or quote (").
(Proposed)	inch foot	in ft	Do not use ′ (′), ″ (″), apostrophe ('), or quote ("), except in music, eight-foot pitch notation uses an apostrophe ('), e.g. a 16' organ stop; see MOS:MUSIC [which we will also need to amend]

Looks good and sensible to me. (Therefore bound to fail!) BTW, "old feet-and-inches notation" is still in use in the real world, just banned by the SI-brigade on WP. Martin of Sheffield (talk) 09:44, 5 February 2024 (UTC)

As there is no term other than 'feet' for organ stops/pitches, the guidance at MOS:FOOT doesn't apply; as that section explains. "The following table lists only units that need special attention." and refers to SI standards – which don't exist in this area. Still, if there is a problem using this measurement (Is there?), mentioning this special case as proposed above might help. However, I find the phrasing above after "except in music …" confusing: after recommending an exception in favour of &prime; it then switches to apostrophe and claims it should be and is used in eight-foot pitch which is not the case, nor do I understand the reference to a necessary amendment at MOS:MUSIC. -- Michael Bednarek (talk) 12:57, 5 February 2024 (UTC)

@Michael Bednarek: there seemed to be some fairly strong opposition to the use of prime in the above discussion, so I'm suggesting apostrophe as a compromise; personally I'd much prefer to use prime, which is the correct character. I mentioned Grove (which uses prime) because folks wanted to know which RS were using it. I'm happy to do a bit more digging. — Jon (talk) 19:47, 5 February 2024 (UTC)

@Jonathanischoice, Michael Bednarek, and Martin of Sheffield: I've been meaning to come back to this discussion for a while. I would suggest something like Do not use ′ (′), ″ (″), apostrophe ('), or quote (") except in music (such as when describing an organ stop), where an apostrophe (') may be used. In this case, it is encouraged for an article to link to an article such as eight-foot pitch or organ stop#Pitch and length at this notation's first occurance. (Perhaps we want to choose one of these to prefer?) I suppose a section should also be added to MOS:MUSIC. LittlePuppers (talk) 02:48, 13 February 2024 (UTC)

Sorry everyone; I've un-auto-archived this discussion, because I still want to figure this out, but I've been snowed for the last 30 days. A new proposal amendment to the foot/inches part, below. — Jon (talk) 23:01, 17 March 2024 (UTC)

Guidelines on specific units

Group	Unit name	Unit symbol	Comment
(Existing)	inch foot	in ft	Do not use ′ (′), ″ (″), apostrophe ('), or quote (").
(Proposed)	inch foot	in ft	Do not use ′ (′), ″ (″), apostrophe ('), or quote ("). Exception: in music, eight-foot pitch notation describes organ stops and wind instrument lengths in feet. A prime may be used with an explanation on first use, e.g. a 16 foot (16′) organ pedal stop; see MOS:MUSIC

Jonathanischoice, I'm supportive of the general idea, two questions with regards to technicalities: (1) is there a specific reason for prime over apostrophe, and (2) currently MOS:MUSIC does not mention this at all, presumably we should put something there? LittlePuppers (talk) 19:47, 20 March 2024 (UTC)

The prime is the "correct" character to use for feet (as in 8′) and can be notated with an HTML element or by using the {{prime}} template, i.e. ′ or {{prime}}. Perhaps we should create a {{music|foot}} shortcut for it. For MOS:MUSIC, see the new Talk:Pitch discussion, opinions welcome :) — Jon (talk) 20:33, 20 March 2024 (UTC)

Have started a Music template discussion to propose a new shortcut, which may or may not be useful. — Jon (talk) 21:02, 20 March 2024 (UTC)

"Correct" in what sense? According to MOSNUM, the only correct symbol is ft. The only exception is the one recently added for organ stops and related musical use. Dondervogel 2 (talk) 22:38, 20 March 2024 (UTC)

"Correct" as in not an apostrophe in this specific case (musicology/organology). — Jon (talk) 23:04, 20 March 2024 (UTC)

Got it. Thank you for clarifying. Dondervogel 2 (talk) 23:10, 20 March 2024 (UTC)

(ec) The correct nomenclature in this area has been discussed in this section before; Ctrl+Fdope. -- Michael Bednarek (talk) 23:17, 20 March 2024 (UTC)

Aha, more discussions to watchlist. Thanks for the references. LittlePuppers (talk) 04:58, 21 March 2024 (UTC)

Right now the newly added "see MOS:MUSIC" on the main page reads a bit strange though, because there is nothing whatsoever there (yet)! Gawaon (talk) 06:14, 21 March 2024 (UTC)

Separate section for off-color musical jokes

• For those who don't know, Bach had 20 children. So, question: Why did Bach have so many children?

Unhide for answer
Because he didn't have any stops in his organ. Nothing to do with his feet, then...!? — Jon (talk) Oh yuck! You're DISGUSTING! EEng 04:06, 15 January 2024 (UTC) Perhaps he just liked the pitter-patter of (tiny) feet. Dondervogel 2 (talk) 20:19, 15 January 2024 (UTC)

References

idea to help prevent disruptive invocation of WP:ERA

As written, it is quite easy for editors to misuse this policy to disrupt an article in which they have no interest beyond the imposition of their preferred era style. I see that this policy has been debated ad nauseam in the past, and that this problem might not be as easy to fix as I had initially assumed. Nevertheless, I have a proposal. The sentence at issue is the following:

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.

The problem, as I see it, is that it is entirely unclear what constitutes reasons specific to its content. None of the previous proposals for clarification seemed to go anywhere in past discussions, which I am sure no one wants to revisit. But what if, instead of seeking a positive characterization, we modified the language to instead include a negative prohibition. I have in mind something along the lines of the following:

Reasons that contradict the earlier policy language stating that The default calendar eras are Anno Domini (BC and AD) and Common Era (BCE and CE). Either convention may be appropriate for use in Wikipedia articles depending on the article context. are to be disregarded in article talk space discussion. It is a violation of WP:SPURIOUSPROTECT to invoke a policy only to litigate against that very policy. Consensus as to what constitutes relevant article context must be established with reasons specific to the subject matter of the article itself.

My hope is that this, or something like it, would reduce the number of disruptive interventions by editors not actually there to improve the article under discussion. It would, at minimum, make it much more difficult for editors (whether involved in the development of the article or not) to effectively shut down discussion with a wall of irrelevant considerations likely recycled from previous such debates.

Thoughts, suggestions, criticisms all most welcome! My goal here is just to limit disruptive editing. (The best solution, of course, would be for the MOS to just pick one or the other of these interchangeable styles. But apparently we can't have nice things.)

Cheers, Patrick J. Welsh (talk) 16:38, 23 March 2024 (UTC)

Do you have examples of this disruptive editing you speak of, by editors who have actually read the guideline? --Trovatore (talk) 16:59, 23 March 2024 (UTC)

Hi @Trovatore,

Yes I do, and I notified them on their talk page, detailing my objections to their editing practice, and offering a chance to provide a more sympathetic account. This was more than two weeks ago, however, and they have not responded or made any other edits since. Anyone who wants can find this through my edit history, but I would prefer to keep this discussion at the policy level. If it goes nowhere, I will consider ANI (it's not their first offense), but I'd much rather just amend the language here to help prevent it from happening again by clarifying the language of the policy. Pursuing sanctions on a case by case basis just eats up more of everyone's time.

To the second part of your question: yes, and this is the problem. I changed BC to BCE throughout an article (two, actually). I thought this was just a copy edit, and I explicitly described what I was doing in my edit description. According to WP:ERA, however, anyone can come in at any time in the future and change it back – with no content-specific justification – unless there was first a talk page consensus established under the heading "era". Since hardly anyone is familiar with the policy, this empowers drive-by editors to selectively revert per WP:ERA and then throw up roadblocks to any actual effort to engage in a collaborative discussion.

In the archived discussion to which I link above, no consensus was reached with respect to limiting this policy-protected right to revert (not with respect to article-involvement, stability, or time-frame). The intention of my suggestion here is to instead insist that any discussion subsequent to such a revert be kept narrowly focused on the actual article and its context, per the policy as currently written. Anyone who doesn't care enough to engage on these terms could then be easily reverted by anyone who cares enough to provide a context-specific justification for changing it back on the talk page—subject, of course, to the normal policy on consensus.

Cheers, Patrick J. Welsh (talk) 18:15, 23 March 2024 (UTC)

Why did you change from BC to BCE in the first place? Gawaon (talk) 18:24, 23 March 2024 (UTC)

Per current policy, that's a discussion to be conducted on that article's talk page in terms specific to its subject matter and the relevant context. Patrick J. Welsh (talk) 19:02, 23 March 2024 (UTC)

The best way to avoid disruptive editing on ERA is not to change the era style without getting the change agreed on the Talk page first. And in fact, where there is a consistent era style in the article, a lot of effort can be saved by leaving the existing era style in place. Sweet6970 (talk) 17:04, 24 March 2024 (UTC)

Hi @Sweet6970,

I am not proposing that we remove the requirement of prior discussion, which would be a policy change. The issue I raise concerns the current policy-restricted scope of the required talk page discussion.

Per the explicit assumptions of this policy, there are two acceptable styles, and at least sometimes there are good reasons to make a change in one direction or the other. (It was an option to simply forbid such changes; this did not achieve consensus.)

It is also a fact that editors, whether aware of this policy or not, believe they have such good reasons.

My point is that, any argument that, if sound, would apply just as much to all articles as to the article in question is, for this reason, in contradiction with this very same policy, which states that there are actually two at least more-or-less equally acceptable practices.

Therefore any such argument should be disregarded in that context. Because, again, any universal argument to adopt one style over the other is an argument that violates this same policy's stipulation that talk page discussion be conducted in terms specific to the content of the article.

If anyone does have such an argument in favor of either style, I suppose I should add, I would be happy to see it prevail so that the MOS could be revised to simply stipulate which to use. Until then, however – and since, apparently, the normal bold policy and consensus procedure are insufficient for this weirdly charged issue – we must work with what we have. And that is what I take myself to be doing.

My proposed rewording of the current policy, if I understand it correctly, only makes explicit what is already included, but which is less than immediately apparent as currently articulated.

If there is a flaw in my reasoning – or if there is some other justification for not drawing attention to this implication of the policy – could someone please explain?

Cheers, Patrick J. Welsh (talk) 18:19, 24 March 2024 (UTC)

PatrickJWelsh I think you have rather fundamentally misunderstood WP:ERA. For there to be an "established style", there does not have to have been "a previous discussion under the heading 'era'". If all occurrences (or the overwhelming majority) were BC before you changed it, then that was the established style, and your edit violated WP:ERA. --Trovatore (talk) 04:48, 25 March 2024 (UTC)

That's what I fear as well. It sounds like the needlessly disruptive type of edit which WP:ERA is meant to avoid. Gawaon (talk) 08:04, 25 March 2024 (UTC)

No need for fear! I most definitely violated ERA with my edits. This policy is a very specific exception to the usual WP:BRD, of which I was not aware. Once made aware, however, I attempted to engage in the requisite discussion.

For a variety of reasons, I do think that this is a bad policy we would all be better off without. All of my remarks, however, accept it as given. The amended wording that I propose would not change that I violated the policy. It would only, if it works I suppose, have kept the talk page discussion focused on what was best for the article in question.

My intention is only to make it more burdensome to invoke this policy in order to pursue what is, apparently, for some people a culture war issue, but which interferes with making Wikipedia a better encyclopedia.

I assume this weird exception to standard practices was implemented in order to prevent folks overly passionate about era styles from causing pointless disruption. It's specificity, however – not just talk page discussion, by talk page discussion under a specific heading! – makes it ripe for abuse. So, in the spirit of the policy itself, let's do our best to minimize that on the terms of the policy itself.

Cheers, Patrick J. Welsh (talk) 14:51, 25 March 2024 (UTC)

I don’t see any reason to change the current wording. It says that the era style should not be changed without discussion, and that the reasons used in the discussion should be specific to the article. You say The problem, as I see it, is that it is entirely unclear what constitutes reasons specific to its content. Well, being realistic, there probably are very few such reasons. This means that once a style is established, it is likely to stay. Sweet6970 (talk) 13:11, 25 March 2024 (UTC)

You seem to be arguing against the policy itself. No?

It is stipulated that there are some. This is a discussion about the proper procedure in the event of a disagreement. Patrick J. Welsh (talk) 14:55, 25 March 2024 (UTC)

No reasons are ‘stipulated’. And no, I am not arguing against the policy, as such. I am just pointing out the way it works out in practice. Sweet6970 (talk) 16:11, 25 March 2024 (UTC)

No specific reasons are stipulated as decisive in either direction (which is part of why it is a poor policy). It does however stipulate that there in some cases some such reasons. Otherwise the policy would instead state that once established, era style should never be changed. Which it does not. If you think it should, by all means advance such a proposal. It's less good of a solution than deciding on one style to be preferred by default, but it would address my concern about disruptive edits. Patrick J. Welsh (talk) 16:28, 25 March 2024 (UTC)

• I endorse most of the comments above that are not by Patrick J. Welsh. I'd just add that the level of invalid changes of era, and spats over them, seems a good deal lower than a few years ago, and that most people starting them are pretty clearly unaware of WP:ERA. Many think, or claim to think, that BCE/CE are the preferred or mandated style. Johnbod (talk) 13:25, 25 March 2024 (UTC)
• I would support removing the "by opening a discussion under a heading using the word era, and briefly stating why the style should be changed". I think a talk page discussion with the heading "BC vs. BCE" with a lengthy opening comment would be just fine, if it led to consensus to change the established style. I would not support adding additional language about which arguments are acceptable in such discussions. Firefangledfeathers (talk / contribs) 14:55, 25 March 2024 (UTC)

  Hi @Firefangledfeathers,

  I am concerned that requiring that a discussion take place under any specific header makes this policy subject to abuse by those passionate about era styles for reasons unrelated to any specific article. Is there any reason not simply to require prior talk page discussion?

  I'm also inclined to think that the policy should not specify whether the initial justification be brief or lengthy. This is subjective, and I would expect it to be ignored with impunity. For that reason, however, I don't think it particularly matters.

  Cheers, Patrick J. Welsh (talk) 15:09, 25 March 2024 (UTC)

  I agree. I only brought up "BC vs. BCE" as an example of a perfectly adequate heading that would be inappropriate under the current rule. Again, my preferred outcome here is removing "by opening a discussion under a heading using the word era, and briefly stating why the style should be changed". Firefangledfeathers (talk / contribs) 15:13, 25 March 2024 (UTC)

  Oh, I misunderstood! That does not go as far as I would like, but I do believe it would be an improvement.

  I will add that my ideal outcome, whatever the best means to achieve it, would be to redirect editors with a strongly held universal preference away from individual articles to instead hash things out at the Village Pump.

  If policy allowed, I would strongly support reopening a RfC on revising the MOS in either direction with the further stipulation that, should there be no consensus, it be decided by the coin toss of an uninvolved admin.

  The two styles are interchangeable. It's frankly embarrassing that we can't just pick one so that we can all get on with making Wikipedia a better encyclopedia. Patrick J. Welsh (talk) 15:39, 25 March 2024 (UTC)

  That won't happen, and for the same reason that we don't postulate that all of Wikipedia be written in American (or British, or whatever) English. Gawaon (talk) 16:00, 25 March 2024 (UTC)

  There is no intrinsic difficulty preventing the MOS from taking a stance. Doing so is a large part of the point of having such a thing at all. What I'm proposing, however, is a clarification of what is already there. Patrick J. Welsh (talk) 16:38, 25 March 2024 (UTC)

  Some of us have participated in several discussions on this subject, and we know from experience that they are a waste of our virtual breath. The question is not going to be resolved in the foreseeable future. Sweet6970 (talk) 16:14, 25 March 2024 (UTC)

  Sorry? In any case, please don't feel obliged to waste any further breath. Patrick J. Welsh (talk) 16:39, 25 March 2024 (UTC)

  You're not the first person to think that there should be a project wide standard for this, but developing a community-wide consensus has not happened. What is currently in the MOS is a compromise, and until something shifts it is going to be around for a while. MrOllie (talk) 17:14, 25 March 2024 (UTC)

  Hi @MrOllie,

  Yes, I understand and accept that, however unfortunate.

  As best I understand it, however, the language of this compromise policy already excludes from article-specific discussion such general reasons such as "this is standard", "this is traditional", or "this is more neutral".

  If my understanding is correct, then making this explicit in the wording of the policy might help prevent talk page discussions from devolving into an irrelevant culture war debate.

  Cheers, Patrick J. Welsh (talk) 17:29, 25 March 2024 (UTC)

  I think the best approach to pursue here is simply not to start any talk page discussions on the subject. If the current era style used in an article is inconsistent, you are free to clean it up anyway. But if there is a clear dominance of one or the other style detectable, just clean up whatever inconsistencies remain. That's the best usage of everybody's time. Gawaon (talk) 17:58, 25 March 2024 (UTC)

  You're almost certainly right that it is a waste of time to argue about anything so trivial. The current policy, however, says that that is what you must do if you think a change should be made. Which some people do.

  If you want to propose a policy change to "always retain established style per first use of either convention", I would reluctantly support that as at least better than what we currently have. Patrick J. Welsh (talk) 18:16, 25 March 2024 (UTC)

  Just act is if that already is the rule (I think it essentially is, for most practical purposes), and you won't go wrong. Gawaon (talk) 20:08, 25 March 2024 (UTC)

  I could get on board with adding something like "or another expressive heading" after "using the word era". I decidedly don't think that the requirement for a preceding talk page discussion should be dropped. Gawaon (talk) 16:03, 25 March 2024 (UTC)

  @PatrickJWelsh: The first post in this thread fails to state when the language being complained about was first put into the policy. Obviously the language does not apply to any consensus reached on any talk page before the language first appeared in the guideline. Jc3s5h (talk) 17:26, 25 March 2024 (UTC)

  Hi @Johnbod,

  Yes, thanks, I hadn't thought about that, but it makes sense (no ex post facto). I would support adding the qualifier "before [date]" to the language in order to prevent particularly egregious abuse of the policy.

  Cheers, Patrick J. Welsh (talk) 17:45, 25 March 2024 (UTC)

  I just looked up the bit that it looks like you two are talking about; it says [...]by opening a discussion under a heading using the word era[...]. I don't think that was ever meant to be a legalistic requirement; it's just a helpful hint to open a discussion that other discussants can easily understand and join. If we're talking about it as something that has to be grandfathered to take into account earlier discussions, then it's just being misinterpreted and we should remove it. The intent is just, if you want to change the era style away from an established one, you need consensus first. --Trovatore (talk) 19:57, 25 March 2024 (UTC)

Patrick J. Welsh changed BC to BCE on the Aristotle article, Crumpled Fire reverted, Patrick J. Welsh changed BC to BCE again, Crumpled Fire reverted again, and it was discussed .on the talk page with participants Patrick J Welsh, Andrew Lancaster, Crumpled_Fire, Peter Gulutzan (i.e. me), 86.6.148.125. Patrick J. Welsh also posted what looks like a warning on Crumpled Fire's talk page. I continue to support the reversion, and will support any other reasonable actions that might persuade Patrick J. Welsh to stop, or at the least to ping all participants when moving to a new forum. By the way, WP:ERA is not a policy but a guideline, as is WP:TALKHEADPOV. Peter Gulutzan (talk) 19:42, 25 March 2024 (UTC)

Hi @Peter Gulutzan,

I quote myself from the talk page discussion:

Thanks for weighing in! The emerging consensus does seem to be "what is wrong with you people and why are you arguing about this?"...Cheers, Patrick J. Welsh (talk) 5:26 pm, 18 February 2024, Sunday (1 month, 6 days ago) (UTC−6)

And then I dropped the matter and left it BC/AD.

I am not here to change the style of the Aristotle article back to what I consider a very slightly preferable convention. The policy is correct in stating that both conventions are fine.

What I am attempting to do is to raise the barrier to entry for people who do not care about the article in question, but are just gunning for a fight.

Please do share here any considerations you might have in response to the concerns I raise above. If your problem, however, is with my individual editorial conduct, it would probably be more appropriate to raise that on my talk page.

Cheers, Patrick J. Welsh (talk) 20:10, 25 March 2024 (UTC)

I don't see any need to raise barriers to entry. People care about articles for different reasons, it isn't up to us to question people's motivations. MrOllie (talk) 20:36, 25 March 2024 (UTC)

No kidding. Masterhatch (talk) 20:53, 25 March 2024 (UTC)

Hi @MrOllie,

I should not have expressed myself that way. In both this discussion and in the Aristotle discussion I have made a conscious effort to avoid imputing bad faith motives to individual participants, and doing so in this more general way did no one any favors. I apologize to all concerned.

With respect to "barriers to entry" I should clarify that the only barrier I am proposing is that participants in a discussion about changing era style provide reasons more specific to the article in question than those general reasons that have been proposed and that have failed to achieve consensus in a more general forum. For what less than this could reasons specific to its content be construed to mean?

That said, however, I am satisfied that I have had my say, and I acknowledge that I appear to persuaded precisely no one that this is, in fact, a little bit of a problem that we could easily do a little bit to fix. So, unless someone speaks up in support of this or a related proposal, I will drop the matter. (On pain of rank hypocrisy!)

I am glad that this discussion appears to have at least resulted in a consensus to clarify that the talk page header does not literally need to be "era". If no one else makes the change, I'll swing back around and implement the language suggested by Gawaon and link to this thread in the edit description.

Cheers, Patrick J. Welsh (talk) 23:49, 25 March 2024 (UTC)

The current text does not say that the header must be merely "era". "Change era style from BC to BCE" and other headers using the word era would also be compliant. NebY (talk) 13:54, 26 March 2024 (UTC)

Revisions to MOS:SEASON

@Premeditated Chaos, Gog the Mild, Mike Christie, SchroCat, and FrB.TG: I've made several changes to MOS:SEASON following our discussion on Wikipedia:Featured article candidates/Oyster dress/archive1. Hopefully the revised guideline is clearer, but please do feel free to edit further. Also thanks to @Gawaon for helping clean up the text. Edge3 (talk) 19:37, 2 March 2024 (UTC)

I think the guidance for magazine issues could be clearer. For example, this is the Summer 2012 issue of Startling Stories; it would go against usage in reliable sources not to capitalize that. Can we restore the Quarterly Review example? On the other hand, if you're simply talking about an issue that came out in the (northern hemisphere) summer of 2012, there's no reason to say "summer 2015 issue" as you now have it; it would usually be better to say "mid-2015" instead. Mike Christie (talk - contribs - library) 20:24, 2 March 2024 (UTC)

I removed Quarterly Review because it hasn't been published since 1967, so "Summer 2015" is factually incorrect. I suppose you could change it to a historically correct example, such as "Summer 1966". But going to the crux of our issue, Amazon really isn't a reliable source because the product description page was written by the publisher of Startling Stories, so it's not independent. MOS:CAPS looks at usage in "independent, reliable sources" (emphasis added). Edge3 (talk) 20:33, 2 March 2024 (UTC)

See this archived discussion for numerous examples from reliable sources, and in particular see NebY's comment at the end. The few counter-examples given look to me like cases where the writer was not referring to an issue titled that way, so I'm not even sure all of them are counter-examples. Mike Christie (talk - contribs - library) 20:37, 2 March 2024 (UTC)

Oh interesting! I didn't realize you had previously brought up this issue in 2022. Thanks for sharing it now.

I think we're always going to find cases where one publication uses capital letters, and others use lower case. For example, Stanford Social Innovation Review refers to its own "summer 2015 issue" (lower case) in running text, even when the issue is titled "Summer 2015". Edge3 (talk) 20:57, 2 March 2024 (UTC)

Yes, there are certainly exceptions, but there was a strong preponderance of evidence in those examples -- unanimity for genre examples, and majority for others. Given that the previous discussion was closed with a consensus to retain the capital letters for magazine seasonal issues, would you mind reverting that part of your changes while this discussion continues? I think, given the previous discussion, we'd need to demonstrate a new consensus before we could make the change you've made. Mike Christie (talk - contribs - library) 21:10, 2 March 2024 (UTC)

I'd be happy to, but my concern about the historical inaccuracy of "Quarterly Review, Summer 2015" still applies. Do you have a specific example that you like better than that? Edge3 (talk) 21:18, 2 March 2024 (UTC)

How about one of the first two given in that earlier discussion? Either "Spring 1942, Tales of Wonder" or "Science Fiction Quarterly, Summer 1942" depending on whether you prefer an example with the date before the title or vice versa. Mike Christie (talk - contribs - library) 21:31, 2 March 2024 (UTC)

Mostly these examples seem to be treated as titles, meaning that the usual rules of title case are applied, and so every major word is capitalized. No surprise here. Only the "summer 2015 issue" example mentioned by Edge3 is not title-cased, hence no capital letters. It would be odd to talk about "the Summer 2015 Issue of Whatever Magazine" or "the Summer 2015 issue of Whatever Magazine". No, this is running text and so lowercase letters are called for: "the summer 2015 issue of Whatever Magazine". But when the issue date is mentioned as part of the title, title case is fine: "Whatever Magazine, Summer 2015". Gawaon (talk) 21:54, 2 March 2024 (UTC)

I agree. Perhaps two examples, so that those cases can be distinguished? Mike Christie (talk - contribs - library) 22:00, 2 March 2024 (UTC)

I've added the examples per both of your comments. Feel free to revise further. Edge3 (talk) 22:07, 2 March 2024 (UTC)

Actually, looking back at the list of examples from the 2022 discussion, it seems many of the running text examples also use upper case, so I'm not sure I fully agree with that part. My main concern was that we keep an example using title case as that's helpful when (as has happened to me) someone contests that. Personally I think it would be OK to have "the Fall 1943 issue of Thrilling Wonder Stories" which is certainly supported by reliable sources, and if you truly mean "the issue that came out that summer" that in itself is a violation of SEASON and should be rephrased. But let's wait and see what others think. Mike Christie (talk - contribs - library) 22:15, 2 March 2024 (UTC)

After reviewing some more examples I've removed the "running text" part. It doesn't correspond to the usage in the sources I have. I'm aware that we don't always comply with the usage in other sources, but I think we need more of a consensus to vary from that usage than we have here. Mike Christie (talk - contribs - library) 01:44, 3 April 2024 (UTC)

I believe the exception makes sense and have reverted your proposed change. Dondervogel 2 (talk) 09:00, 3 April 2024 (UTC)

Seasons in magazine titles in running text

Dondervogel 2 reverted this edit of mine, which removed the bolded text in the sentence below, about the use of seasons in magazine titles:

They are capitalized when part of the title of a work (Science Fiction Quarterly, Summer 1942), except when referring to a seasonal edition in running text (the summer 1942 issue of Science Fiction Quarterly).

The example was added about a month ago without much discussion; see further up this talk page. I removed it for two reasons:

1. Sources that discuss magazines mostly do capitalize the season name even in running text; and
2. The use of the lower-case season in this way is against the advice of SEASON in any case, since if we're not using the formal title of the issue, "Summer 1942", then we should be avoiding the use of season names.

It appears that the sources capitalize in this way when they are referring to a specific issue that has that title. I started to compile a list of usage by source, but it's easier to simply go to Google Books and search for "the summer 2019 issue". The first fifteen results have ten with "Summer" and five with "summer". I think the example that Dondervogel 2 reinstated should be removed again: it advises a usage that doesn't agree with what reliable sources do; it makes no allowance for the writer wishing to refer to a specific issue with that formal title; and it conflicts with the main point of SEASON. Mike Christie (talk - contribs - library) 10:32, 3 April 2024 (UTC)

My point is that "summer" in "the summer 1942 issue" is not a proper noun, so I see no reason to capitalise. Dondervogel 2 (talk) 18:13, 3 April 2024 (UTC)

I agree it's not a proper noun. The reason it's capitalized is that it's part of the formal title of that issue of the magazine. The example in the first half of the sentence uses upper case; if a writer is referring to that issue of the magazine, they can use the title of the issue if they wish -- and from a look in Google Books it's evident that's what most writers do. Mike Christie (talk - contribs - library) 18:45, 3 April 2024 (UTC)

Instead of removing it, I've now replaced it with text saying "if a mention of a seasonal edition does not capitalize the season name, avoid using the season name because of the ambiguity". That avoids implying that it should always be capitalized or always uncapitalized in running text, and also avoids giving an example that uses a lower-case season name. Mike Christie (talk - contribs - library) 10:36, 4 April 2024 (UTC)

I have reverted that, since I don't think it's an improvement. It's totally unclear what's meant by "a mention" (in Wikipedia? in a RS?) and "avoid using" is not useful advice if you don't know how else to refer to the issue in question. Gawaon (talk) 11:47, 4 April 2024 (UTC)

Personally I think that when such an issue identifier is mentioned in running text it's often unclear whether it's indeed part of the title (which calls for capitalization) or just a generic identifier similar to "the second issue of 1942". Maybe because of this ambiguity, we could simply allow either capitalization and write something like "except that seasonal editions may be lower-cased in running text (the Summer/summer 1942 issue of Science Fiction Quarterly)"? Gawaon (talk) 11:52, 4 April 2024 (UTC)

My main concern is that the prior wording forbade the use of upper case in running text, so that would work for me. Is it a problem that the example you give uses "summer", which we're trying to avoid recommending? We do say it's "appropriate when it is part of a conventional name or designation"; I think here the "conventional name" would be the magazine issue's title, and that would be upper case. I think the usages one can see of lower case "summer 2019 issue of" in Google Books are season references of the type we discourage. But other than that your wording seems good to me. Mike Christie (talk - contribs - library) 11:57, 4 April 2024 (UTC)

I've gone ahead and made the change to your wording. Mike Christie (talk - contribs - library) 12:05, 6 April 2024 (UTC)

I object to the change because if "the Summer 1942 Issue" is interpreted as a part of the title, then "Issue" would also be capitalised. Dondervogel 2 (talk) 12:33, 6 April 2024 (UTC)

I don't think we can say "issue" is part of the title; the phrase "Summer 1942" will typically appear on the cover and contents page and sometimes the masthead of a magazine, but it is never accompanied by the word "issue". Mike Christie (talk - contribs - library) 12:56, 6 April 2024 (UTC)

I don't think that's true. The magazine cover will probably just say something like "Science Fiction Quarterly – Summer 1942", the magazine title being the main title, and the issue identifier something like the subtitle. The word "issue" probably won't appear on the cover and so is not part of the title. (I had already largely written this when Mike Christie's comment appeared, so I'll let it stand despite the repetition.) Gawaon (talk) 12:58, 6 April 2024 (UTC)

I fully agree the word "issue" is not normally considered part of the title, in which case it should not be capitalised. My point is that if "issue" is not part of the title, then neither is "summer 1942". It's just text describing which issue we are referring to. Just because "Summer 1942" can be part of the title, as in Science Fiction Quarterly, Summer 1942, does not imply it always is. It depends on the construction. Dondervogel 2 (talk) 14:25, 6 April 2024 (UTC)

I think it's the other way round -- the only difference between the two constructions (the writer is using the title of the issue vs. the writer is mentioning the time of year when the issue appeared) is the capitalization. If it's capitalized, the writer is using the issue's title. The revised wording suggested by Gawaon allows for both, which is in line with actual usage in the sources. Mike Christie (talk - contribs - library) 14:28, 6 April 2024 (UTC)

Indeed. "Summer 1942" is how the publisher named the issue, as well as being how others refer to it. It may or may not bear any particular relationship to the season in which it was actually published or even indicate when it could be taken off sale and returned. NebY (talk) 14:43, 6 April 2024 (UTC)

Sounds like I am in a minority of one. For that reason I withdraw my objection. Dondervogel 2 (talk) 18:43, 6 April 2024 (UTC)

I agree with @Dondervogel 2 that we should default to lower-case in running text. Let's consider a non-season example. Our MOS would recommend using Science Fiction Quarterly, Third Edition when referring to the edition as a title, but on the other hand we would state third edition of Science Fiction Quarterly in running text. I don't see a compelling reason to do anything differently just because we're now dealing with a season name.

For what it's worth, I initiated the discussion above because of an MOS discussion at the 'Oyster dress' FAC, which actually concerned a fashion collection rather than a periodical title. Over there I was a so-called "minority of one". Just as an FYI to you, Dondervogel 2, that you're not alone in your position. I maintained my objection in that discussion because I could not find an MOS-based reason to support capitalization despite my best efforts.

I like the wording that @Gawaon and @Mike Christie added. It gives flexibility based on how reliable sources handle capitalization. However, I do have two recommended changes.

1. The new text currently states the Summer/summer 1942 issue, but in the MOS we usually provide separate instances of an example to avoid ambiguity. We're not telling people to actually write down Summer/summer; we want them to pick one or the other. So I think the text should be fully expanded to say "the summer 1942 issue of Science Fiction Quarterly or the Summer 1942 issue of Science Fiction Quarterly". But this also might unnecessarily lengthen the guideline so I'd appreciate thoughts from others.
2. It also might be helpful to remind editors of MOS:CAPS, which looks for a "substantial majority" of such sources to support capitalization. Of course, "substantial majority" is still an imprecise term so I don't know how helpful it would be on the more contentious cases.

Edge3 (talk) 05:01, 7 April 2024 (UTC)

For #1, a shorter magazine title would help. How about "the summer 1985 issue of Interzone or the Summer 1985 issue of Interzone"? Mike Christie (talk - contribs - library) 10:57, 7 April 2024 (UTC)

Fine with me. But we should probably keep the capitalized form first. Gawaon (talk) 11:28, 7 April 2024 (UTC)

I tried to incorporate my changes for #1 and #2, along with the feedback here. See edit. It's a somewhat complex change, so feel free to revise further! Edge3 (talk) 02:38, 8 April 2024 (UTC)

I have partially reverted that since it's not what we agreed on and would put an undue burden on editors, who cannot be expected to research "substantial majority" distributions for every issue title they mention. Let's keep it simple and allow both case forms without prejudice. Gawaon (talk) 05:19, 8 April 2024 (UTC)

I agree. I've changed the date for the Interzone example to 1985, since we might as well use an issue that really appeared as an example. Mike Christie (talk - contribs - library) 10:08, 8 April 2024 (UTC)

I was trying to address my point #2 above to give guidance on when to capitalize. You both haven't talked about it yet so I'm happy to hear feedback. Edge3 (talk) 14:46, 8 April 2024 (UTC)

I don't know that there's anything useful we can add on when to capitalize. It seems that in running text the seasons are more often capitalized than not, but as discussed above I think the only way to tell the writer's intent is from the capitalization -- that is, we're not going to be able say "if your sentence is like <this> then capitalize". I suppose we could say something like "if you mean to refer to the issue by its title, capitalize; otherwise if you are referring to the season of the year when the issue appears, then do not capitalize", but that seems a bit wordy. I think the lower-case usage does run into a problem with the main reason for SEASON in the first place so ideally we wouldn't mention it at all, but then we'd have to say something like "northern summer" which is just not how the sources do it -- they assume the context is the location where the magazine is published. Mike Christie (talk - contribs - library) 15:11, 8 April 2024 (UTC)

Let's not overcomplicate this. The current wording works. Gawaon (talk) 16:35, 8 April 2024 (UTC)

The current wording may be fine for seasonal periodicals, but it still doesn't give clear guidance in other cases. Specifically for fashion-related articles, a majority of sources use lowercase, but our WP articles still capitalize based on a previous interpretation of the MOS. The phrasing "may be lower-cased" is permissive, while MOS:CAPS provides an explicit test: avoid capitalization unless supported by a "substantial majority" of sources. Edge3 (talk) 17:10, 8 April 2024 (UTC)

Uh, seasonal periodicals is what the wording is all about, so where shouldn't it be fine? Gawaon (talk) 06:05, 9 April 2024 (UTC)

Edge3, if you're talking about fashion shows such as the Spring/Summer 2006 collection at which Neptune was shown, then I'd say the sources show exactly the same variation that source about magazines do -- when the writer is referring to the show by what they regard as the formal title they use the upper case version; when they are referring to the season they use lower case. Just as with magazines, the capitalization is what tells you their intention -- the fact that both occur doesn't mean one is right and one is wrong; it just distinguishes the two usages. Pinging Premeditated Chaos as I know this discussion began on one of her FACs. Mike Christie (talk - contribs - library) 11:00, 9 April 2024 (UTC)

Mike, while I appreciate the ping, I'm not interested in participating in this discussion. Edge3 has consistently shown that he has no interest in listening to the opinions of other editors, as indicated by his single-minded dismissal of the clear consensus from something like a half-dozen-plus editors (including FAC coords!) who showed up at the Oyster dress FAC to tell Edge3 that his interpretation was incorrect.

I'll repeat the argument I made when Edge3 showed up at my next FAC to complain that I wasn't following the arbitrary change he made to MOS:SEASONS, despite the fact that the capitalization was actually correct under his arbitrary brand-new wording.

"Season names are generally not capitalized (a hot summer), except when personified (Old Man Winter) or when part of a formal name". A fashion season such as "Autumn/Winter 2008" or "Resort 2014" is a formal name for a particular period in the industry, so it is capitalized. Other editors clearly agreed with this interpretation in the last discussion, so although the MOS wording may have changed, the reality underpinning my reasoning has not.

I do not see the point in participating in a discussion with someone who has decided that consensus is irrelevant unless it's in his favor, who feels he can arbitrarily rewrite the MOS whenever consensus does not go his way, and who feels he can interpret his brand-new wording however he wants even when it actually supports my position despite his rewrites. I have zero intention of altering the capitalization for fashion seasons unless there is a strong consensus for this change from editors who are not Edge3. I am deliberately not watching this page, will not be reading any replies, and do not wish to be pinged back here to this or any further discussion on the topic, because I find attempting to speak to Edge3 on this topic exhausting and frustrating, and I would prefer to do literally anything else with my time than argue about capital letters. ♠PMC♠ (talk) 11:46, 9 April 2024 (UTC)

"Mos:DOB" listed at Redirects for discussion

The redirect Mos:DOB has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 April 25 § Mos:DOB until a consensus is reached. Utopes _{(talk / cont)} 21:59, 25 April 2024 (UTC)

"Full, unambiguous signifier" for currencies

Do we have a list somewhere of "full, unambiguous signifier[s]" for currencies? MOS:CURRENCY links to List of circulating currencies, but nowhere can we find "A$" or "US$" there, which MOS:CURRENCY recommends us to use. LightNightLights (talk • contribs) 10:41, 18 May 2024 (UTC)

@LightNightLights: See Currency symbol#List of currency symbols currently in use. That article deviates heavily from the World Bank Group's editorial guide (p. 134) that lists uncommon symbols like $A. ~~lol1VNIO (I made a mistake? talk to me) 11:25, 19 May 2024 (UTC)

@LightNightLights: I've just discovered that templates that are titled after ISO 4217 codes standardize the signifiers on enwiki. Use {{AUD}}, {{CAD}}, {{USD}} etc. or {{Currency|value|code}} with codes at Module:Currency/Presentation ~~lol1VNIO (I made a mistake? talk to me) 15:39, 19 May 2024 (UTC); edited 16:52, 19 May 2024 (UTC)

@Lol1VNIO Thank you. I do not consider myself as someone who writes or contributes to style manuals so I do not know the answers to these questions, but:

• Should MOS:CURRENCY link to Currency symbol § List of currency symbols currently in use?
• Should MOS:CURRENCY recommend editors to use the templates (instead of checking a list?) in the MOS?

LightNightLights (talk • contribs) 18:03, 20 May 2024 (UTC)

@LightNightLights: The guide already links to Currency symbols, specifically to #dollar variants, though a link to the page after "full, unambiguous signifier" wouldn't be a bad idea. As for templating every currency, not really. It makes sense in some (฿100) but others you can just enter on your keyboard. Often, you're familiar with a set of currencies that you don't need to look up, anyway. ~~lol1VNIO (I made a mistake? talk to me) 20:15, 20 May 2024 (UTC)

@Lol1VNIO I swear that I fully read MOS:CURRENCY multiple times, but I didn't notice the Currency symbols link. I am not sure how to correctly add the link after "full, unambiguous signifier", so I am okay with you adding it. LightNightLights (talk • contribs) 10:24, 21 May 2024 (UTC)

Perhaps add suggestions to consider using {{currency}}, {{USD}} and similar.  Stepho  talk  06:11, 24 May 2024 (UTC)

Hyphenation in spelled-out fractions

Per MOS:FRAC: Spelled-out fractions are hyphenated.

Should this always be so? I noticed One half doesn't abide in its title, and there are potential ambiguities in use. Remsense诉 05:54, 18 May 2024 (UTC)

See existing (but closed) discussion at Talk:One half, on a failed proposal to move it to one-half. In particular, there, jacobolus wrote MOS:FRAC is straight up wrong here, and should be changed. Whether to add a hyphen depends on the grammatical context. Some others (myself included) agreed. —David Eppstein (talk) 06:03, 18 May 2024 (UTC)

Right, it seems to make more sense to add a hyphen when they are used as modifier (adjective), but not when used as noun. Gawaon (talk) 07:04, 18 May 2024 (UTC)

On this basis there is clearly no consensus for the rule as stated, so I removed it until there is agreement on what it should be replaced by. My view is that of Gawaon. For example

• A one-half octave is one half of an octave.
• Seven eighths of a mile is 1,540 yards.
• Three tenths of a kilometre is 300 m.

Dondervogel 2 (talk) 10:29, 18 May 2024 (UTC)

"Hyphenate a spelled-out fraction used as a modifier" or similar seems like a fine rule to include. –jacobolus (t) 16:32, 18 May 2024 (UTC)

I had WP:BOLDly edited the page and suggested the following wording: "Spelled-out fractions are hyphenated before a noun (They won a two-thirds majority), but not when used stand-alone (The distance was seven eighths of a mile)." That change was reverted so it seems more discussion is needed. Gawaon (talk) 16:50, 18 May 2024 (UTC)

FWIW, the latest Fowler's Modern English describes real-world usage of the hyphen as "chaos", notes it's on the wane "even in British English", identifies some main uses (creating a single unit of meaning (dry-clean); phrases in front of nouns (up-to-date record, well-known man); with prefixes (ex-husband, re-cover); in lists (two- or three-fold); to avoid misinterpretation (extra-marital sex); with phrasal verbs, as a mistake; in printing,to break a word) but doesn't address this question directly.

Two-thirds majority fits Fowler's first and second usages; I think seven-eighths of a mile fits Fowler's first, a single unit of meaning, especially considering its other representations (0.875, ⁠7/8⁠). NebY (talk) 17:20, 18 May 2024 (UTC)

• I don't think I've got the energy to stick with this discussion, but let me point something out. In he walked three quarters of a mile, I'm not sure the phrase "three quarters" is a fraction; seems to me it's 3 quarters, if you get my meaning. EEng 17:14, 18 May 2024 (UTC)

  I do, but though that works in I ate three quarters of the quattro stagioni (but not the mushrooms) or even he ran three quarters of the mile (but walked the third one), by itself he walked three quarters of a mile is no more than he walked ⁠3/4⁠ mile. NebY (talk) 17:41, 18 May 2024 (UTC)

  Just throwing this out: "he played three quarters of the basketball game" (it has four quarters), versus "he watched three-quarters of the movie". Just wondering. Bubba73 ^{You talkin' to me?} 04:56, 20 May 2024 (UTC)

  Would you really write them differently? I would tend to write them the same (both without a hyphen). Gawaon (talk) 05:22, 20 May 2024 (UTC)

  What would you say if the sentence is, "he played in three quarters of the basketball game"? To me, that reads that he played in at least part of each of three quarters of the games (say, from the middle of the second quarter to the middle of the fourth quarter), but not necessarily for a full three-quarters of the games. A bit contrived, but edge cases test rules. Donald Albury 16:54, 20 May 2024 (UTC)

  True, I'd say that "he played in three quarters of the basketball game" might mean that he played less compared to "he played three quarters of the basketball game", which is more likely to give the total length of his play. However, I'd say if the use or non-use of a hyphen should depend on such subtleties, we're overcomplicating things. According to the rule I favour, no hyphen should be used in either case. Gawaon (talk) 17:19, 20 May 2024 (UTC)

  Would it make a difference with fourths instead of quarters? —David Eppstein (talk) 18:22, 18 May 2024 (UTC)

  Not sure. To be honest, I was quite sleep-deprived when I made that post and I'm not sure now how exactly I thought it would clarify anything. :( What about the case of "one half"? There's no "one twoth". EEng 07:02, 19 May 2024 (UTC)

  "One half" is somewhat an exception because it is used so commonly (cf. first, second, third, instead of oneth, twoth, threeth). The same goes for "one quarter" (though "one fourth" is an accepted alternative). I don't see anything wrong with the phrase "three quarters of a mile", that's just 3*(1/4) mi = 3/4 mi. ~~lol1VNIO (I made a mistake? talk to me) 10:28, 19 May 2024 (UTC)

  I didn't say there's anything wrong with it. I was just pointing out, since this discussion is nominally about fractions, that it may not be clear that "three quarters" (and so on) actually is a fraction. EEng 20:34, 19 May 2024 (UTC)

  I think it's clear that a "quarter" is 1/4. A quarter of an hour is 15 min. A quarter of a dollar is 25 cents. I'm sorry, I'm not sure where the confusion lies. ~~lol1VNIO (I made a mistake? talk to me) 09:01, 20 May 2024 (UTC)

  Well, since you press the point: no, it's not clear. "Three quarters" might be a fraction (3/4), or it might be three times a fraction (3 · 1/4), but not itself a fraction. EEng 09:25, 20 May 2024 (UTC)

  3/4 and 3(1/4) are both the same, just expressed differently. One can choose interpret "three quarters" as the former and the problem would be solved. ~~lol1VNIO (I made a mistake? talk to me) 09:28, 20 May 2024 (UTC); edited 09:31, 20 May 2024 (UTC)

  • 3/4 and 3(1/4) are both the same, just expressed differently – Wow, and to think I spent all that money on a degree in applied math from Harvard, and they never taught me that. If what you're saying is really true, then I'm going to ask for my money back! Next you'll be telling me that (1/x) · x = 1.
  • One can choose interpret "three quarters" as the former – You're contradicting yourself. If the two things are the same, then choosing between them makes no sense, since (says you) they're both the same -- there's no choice to be made. But they're not the same. That's the point. One's a fraction and one is an integer times a fraction, in which case the question of "how to write fractions" doesn't apply to it.

  EEng 09:51, 20 May 2024 (UTC)

  Are you saying that "one eighth" is a fraction, but "three eighths" isn't? That would be a highly original interpretation of "fraction". Gawaon (talk) 10:04, 20 May 2024 (UTC)

  No. If we interpret "three eighths" not as a fraction, but rather as an integer followed by a fraction, then "one eighth" is also not a fraction. EEng 17:49, 20 May 2024 (UTC)

  How silly of me! All those Aristotlean logic I learned for nothing! ~~lol1VNIO (I made a mistake? talk to me) 10:06, 20 May 2024 (UTC)

  All those grammar, too! EEng 17:49, 20 May 2024 (UTC)

  Not necessarily. The fraction 3/4 can be seen as indicating a cohesive part. While 3(1/4) would equal the same amount, it might not be a single "thing". For example, imagine a cake cut into 8 equal parts (labeled 1-8 in clockwise fashion). If I eat pieces 1-6, then I can be said to have eaten 3/4 of the cake and also to have eaten 3 of the quarters of the cake. However, If I eat pieces 2-4 and 6-8, then I can be said to have eaten 3/4 of the cake but not to have eaten 3 of the quarters of the cake. --User:Khajidha (talk) (contributions) 15:34, 20 May 2024 (UTC)

  ^ This guy gets it. EEng 17:49, 20 May 2024 (UTC)

  I think rarely in articles, you would dig into the nitty-gritty of how it came to 3/4. In the original example (he walked three quarters of a mile), no reader would be perplexed as to if he walked three (quarters of a mile) or (three quarters) of a mile. If you really want to specify that he either walked in quarter miles, taking breaks along the way, or walked 0.75 miles in one go, then say it.

  In User:Khajidha's example, there is a fraction in both cases: said to have eaten 3/4 of the cake and also to have eaten 3 of the quarters of the cake (here, 3/4 is "three quarters"); and have eaten 3/4 of the cake but not to have eaten 3 of the quarters of the cake (also 3/4 aka "three quarters"). So "three quarters" is a fraction either way. ~~lol1VNIO (I made a mistake? talk to me) 19:42, 20 May 2024 (UTC)

  I.e., basically what Chicago is saying in the passage I quoted below? (And using the same example, incidentally!) Graham (talk) 03:19, 21 May 2024 (UTC)

  As for "used stand-alone", that is when the denominator of the fraction is not an attribute, that's when it shouldn't be hyphenated (according to the discussion). An attribute is optional, so if you remove it, it still makes grammatical sense. For example, They won a three-quarters majority (not standalone), if you remove "three-quarters", it makes grammatical sense; whereas They won a majority of three quarters (standalone), if you remove "three quarters", it makes no sense. Thus, NebY's example above (seven-eighths of a mile) should not be hyphenated because there, the attribute is "of a mile". ~~lol1VNIO (I made a mistake? talk to me) 10:49, 19 May 2024 (UTC)

  That was my proposal (also suggested by others), and I still think it makes a lot of sense and reflects widespread usage fairly well. EEng, if you think the used wording was unclear, maybe you have a suggestion on how to improve it? Gawaon (talk) 11:21, 19 May 2024 (UTC)

  We could explain it linguistically and note that hiding attributes would still make grammatical sense: Spelled-out fractions are hyphenated when it is used as an attribute (They won a two-thirds majority), but not when used stand-alone (The distance was seven eighths of a mile). Rule of thumb: hyphenate if removing the fraction would still make grammatical sense. Instead of "when used stand-alone", we could dig deeper into linguistics and say "when the denominator is used as the head noun of the phrase", but I doubt that would be any more clear. ~~lol1VNIO (I made a mistake? talk to me) 11:50, 19 May 2024 (UTC); edited 11:58, 19 May 2024 (UTC)

  Hmm. I might not hyphenate if the emphasis was on the denominator, but that's a more narrow exception and perhaps more traditionalist. NebY (talk) 12:18, 19 May 2024 (UTC)

  The suggested wording sounds fine for me. Gawaon (talk) 13:05, 19 May 2024 (UTC)

  Lol1VNIO's suggestion makes sense to me too. I would just replace "when it used" with "when used". Dondervogel 2 (talk) 18:56, 19 May 2024 (UTC)

If we were writing here for The New Yorker or some other highfalutin publication, we could, perhaps, follow a more complex style, but in the encyclopedia anyone can edit, simple rules are better. It's like the comma after a mdy date. Sometimes there is no need for a comma after May 20, 2024, but it is so much easier to always use it and it doesn't hurt anything. Let's stick with the hyphen in written out fractions. One half may or may not be correct, but we can live with some inconsistency.  SchreiberBike | ⌨  11:36, 20 May 2024 (UTC)

I would agree with others that I don't think it makes sense to hyphenate fractions where they are being used as compound modifiers. However, to maintain consistency with MOS:HYPHEN, I would suggest that we further specify that we only use hyphens with fractions where it is being used as an attributive or substantive modifier (which is what I think most of us have in mind anyway) rather than a predicative modifier. Graham (talk) 04:27, 20 May 2024 (UTC)

That matches my intuition. —David Eppstein (talk) 08:10, 20 May 2024 (UTC)

Our manual of style has to be plain and direct, providing easily understood guidance to all editors who need it, not only those who are trained in the use of high-falutin' terms like attributive, substantive, predicative and modifier. NebY (talk) 11:19, 20 May 2024 (UTC)

Are you proposing that we amend MOS:HYPHEN? Graham (talk) 03:07, 21 May 2024 (UTC)

The Australian style guide says Use a hyphen in fractions written out in words (eg two-thirds). I oppose any change to the MOS. Hawkeye7 (discuss) 04:46, 20 May 2024 (UTC)

What's "the Australian style guide"? Anyway, our old rule stating the same has already been thrown out. The question is now what to replace it with. Gawaon (talk) 05:24, 20 May 2024 (UTC)

That's here, along with Write fractions in full in running text, and use a hyphen. The Australian govenment's style manual has Hyphens link parts of a fraction.[32] NebY (talk) 10:33, 20 May 2024 (UTC)

The BBC News Style Guide has simply three-quarters (and other fractions).[33] NebY (talk) 10:22, 20 May 2024 (UTC)

Purdue has a collection of style guides; I only found Use a hyphen with compound numbers: forty-six, sixty-three, Our much-loved teacher was sixty-three years old.[34] NebY (talk) 10:44, 20 May 2024 (UTC)

That's not really relevant to fractions. Graham (talk) 03:04, 21 May 2024 (UTC)

It is relevant when the only guidance on compund numbers is to hyphenate; that includes fractions. Back in 2007, we stated it as Spelled-out two-word numbers from 21 to 99 are hyphenated (fifty-six), as are fractions (seven-eighths)[35] (it may have been on some other MOS page before then). NebY (talk) 15:48, 23 May 2024 (UTC)

"as are fractions" are the key words there, which are absent from the cited article. Graham (talk) 04:27, 25 May 2024 (UTC)

Graham11 reports The Chicago Manual of Style also prescribes the hyphenated form, even when the term is used as a noun.[36] NebY (talk) 17:35, 20 May 2024 (UTC)

The most relevant passage is 9.14:

9.14 Simple fractions. Simple fractions are spelled out. For the sake of readability and to lend an appearance of consistency, they are hyphenated in noun, adjective, and adverb forms. In the rare event that individual parts of a quantity are emphasized, however, as in the last example, the expression is unhyphenated. See also 7.89, section 1, under fractions, simple. For decimal fractions, see 9.19.

She has read three-fourths of the book.

Four-fifths of the students are boycotting the class.

I do not want all of your material; two-thirds is quite enough.

A two-thirds majority is required.

but

We divided the cake into four quarters; I took three quarters, and my brother one.

Graham (talk) 03:17, 21 May 2024 (UTC)

Thanks for that. In short, Chicago supports our Spelled-out fractions are hyphenated with one minor exception. NebY (talk) 15:41, 23 May 2024 (UTC)

Collins English Dictionary's entry for two-thirds begins with two-thirds of.[37] NebY (talk) 17:48, 20 May 2024 (UTC)

Merriam-Webster online gives for three-quarters Three-quarters of the class will be going on the trip and three-quarters of an hour, plus many "Recent Examples on the Web", each using three-quarters of, hyphenated: nearly three-quarters of those using the feature (WSJ); three-quarters of lawmakers (Anchorage Daily News); three-quarters of a percentage point (Los Angeles Times) and more.[38] NebY (talk) 18:06, 20 May 2024 (UTC)

Numbers

Under the Numbers section, it states:

"Generally, in article text:

Integers from zero to nine are spelled out in words."

I wonder why is "from zero to nine" instead of "from zero to ten"? We humans have ten fingers, we learn how to count from one to ten since we were little kids. If we learn a foreign language, the first thing we learn is words like hello, thank you, good bye, and count from one to ten. It doesn't make sense that only integers from zero to nine shoulde be spelled out in words. It should be integers from one to ten. 120.16.218.233 (talk) 17:18, 13 April 2024 (UTC)

Yes, but cats have nine lives, so it makes perfect sense actually. GiantSnowman 17:19, 13 April 2024 (UTC)

LOL. You must be joking. 120.16.218.233 (talk) 17:21, 13 April 2024 (UTC)

...weren't you? GiantSnowman 17:23, 13 April 2024 (UTC)

Nope. I really think that in article text, integers from zero to ten should be spelled out in words (i.e. ten years ago not 10 years ago). 120.16.218.233 (talk) 17:28, 13 April 2024 (UTC)

We don't say that "only integers from zero to nine shoulde be spelled out in words". We do say that Integers greater than nine expressible in one or two words may be expressed either in numerals or in words and proceed to qualify that in several ways, allowing for either "10" or "ten" to be used as appropriate. NebY (talk) 17:39, 13 April 2024 (UTC)

I’ve thought this for a long time, so agree with you. Numbers expressed as words are easier to read and don’t visually interrupt a sentence in the same way as does sticking figures in the middle of it. IMHO figures should only be used when multiple words are needed to express the quantity. MapReader (talk) 18:59, 13 April 2024 (UTC)

"Numbers expressed as words are easier to read". My experience is the opposite. I find it much easier to express numbers as numerals always. I only express them in words when English convention says Thou Must Use Words For Small Numbers but I never liked it. Mind you, I spend most days writing software and doing engineering stuff, so I may not represent the typical reader.  Stepho  talk  11:07, 14 April 2024 (UTC)

Agreed. We should be looking to REDUCE the instances of "numbers as words", not increase them. --User:Khajidha (talk) (contributions) 17:19, 17 April 2024 (UTC)

While I have no strong preference one way or the other, adding ten to the numbers for which words are preferred would be fine with me. Ten is indeed just one more character than 10, so it's the number easiest to spell out. Gawaon (talk) 19:25, 13 April 2024 (UTC)

Some other style guides:

• The BBC News Style Guide has "For the most part, we use words for single-figure numbers, digits for anything above nine (ie eight, nine, 10, 11)" followed by various exceptions.[39]
• The Guardian and Observer style guide has "Spell out from one to nine; numerals from 10 to 999,999 ...."[40]
• According to this 2005 discussion here in WT:MOSNUM, Wikipedia talk:Manual of Style/Dates and numbers/Archive 25#Numbers written as words, the Chicago Manual of Style has (or had) "According to Press style, the following are spelled out in ordinary text: Whole numbers from one through ninety-nine; Any of these followed by hundred, thousand, million, etc."
• According to the same discussion, the Oxford Style Manual (2003) had "In non-technical contexts, OUP style is to use words for numbers below 100."
• Fowler's Modern English Usage (4th edn) has "Figures should be used when the matter consists of a sequence of stated quantities [e.g.] The past 12 months show an increase of 5 tons" and "In descriptive matter, numbers under 100 should be in words, but write 90 to 100, not ninety to 100."

I haven't tried a proper search in MOSNUM's history – I doubt a straightforward Wikiblame search would help – but it looks as if the core one-to-nine rule's been stable since Wikipedia talk:Manual of Style/Dates and numbers/Archive 73#Proposed revision of "Numbers in words" in 2007. NebY (talk) 20:26, 13 April 2024 (UTC)

Proposal The IP user brought up an interesting point. Why "from zero to nine"? Why not "from zero to seven, eight, ten, or eleven"? I propose that we change the rule to "Integers from zero to twenty are spelled out in words". If we can express a number in a single, simple English word, then use the English word. If more than one word or a hyphen is involved (e.g. twenty-one, one hundred and one), use the numerals. N. Mortimer (talk) 00:32, 14 April 2024 (UTC)

Against - Existing form (words for single digits, numerals for more) works fine. Examples for each:

1. There 14 reasons to object.
2. There are fourteen reasons to object.

The numeral form is so much more compact, quicker to type, quicker to read, requires less effort to understand and the quirks of spelling for 11-19 are avoided for our English as a second language audience (why is 11,12 different to 13-19; why is 13-19 different to 23-29, etc?). Keep it simple.  Stepho  talk  01:53, 14 April 2024 (UTC)

So you also support my proposal of adding "ten" to the mix? Thank you. Ten is a very simple word, I think all people with a basic understanding of English know this word.

By the way, even if we use "14" instead of "fourteen" in your sentence example, we can't really omit the "are", but I agree with you that numbers greater than ten should be written in the numeral form. 120.16.218.233 (talk) 09:57, 14 April 2024 (UTC)

Oops, I forgot to type in "are" for the first example. My mistake.

Oh dear, it looks like only 1 of us knows how to count up to 2. "10" is not a single digit, so "words for single digits, numerals for more" means I support "10", not "ten".  Stepho  talk  10:22, 14 April 2024 (UTC)

Why don't you support "ten"? "Ten" is shorter than "three", "seven" or "eight". People like to group things in even numbers, not odd numbers (because they are odd 😂). 120.16.218.233 (talk) 23:59, 14 April 2024 (UTC)

Because "10" is not a single digit. Am I saying this wrong? Should I type slower? Should I use words with one syllable or less?  Stepho  talk  00:31, 15 April 2024 (UTC)

No. Spelling out such simply words is already allowed, it shouldn't be required. It's very hard to see why 17 should be treated differently than 27, and if this rule were adapted, it would logically have to apply to thirty, forty etc. as well. Gawaon (talk) 04:43, 14 April 2024 (UTC)

Yes, it should logically apply to thirty, forty etc. And the reason is obvious; single spelled words are easier to read than interrupting a sentence with digits, but that advantage weakens when multiple words are required to spell out a number. MapReader (talk) 06:40, 14 April 2024 (UTC)

Actually, I find "The applicants' ages ranged from seventeen to seventy" harder and less convenient to read than "The applicants' ages ranged from 17 to 70". Especially, in latter sentence the numbers stand out, making them very easy to detect when one skims a text quickly, which is not the case in the former sentence. Gawaon (talk) 07:02, 14 April 2024 (UTC)

That's why we should make "ten" the cut-off point:

Zero

One

Two

Three

Four

Five

Six

Seven

Eight

Nine

Ten

11

12

13.... 120.16.218.233 (talk) 10:03, 14 April 2024 (UTC)

No. As spelt out in the very next sentence after Integers from zero to nine are spelled out in words, we already allow that Integers greater than nine expressible in one or two words may be expressed either in numerals or in words, both subject to and extended by the following notes and exceptions. This is appropriately flexible; the mere fact that single words exist for some numbers does not meant they are always the best way for readers to take in quantitative information, even when reading the text closely rather than skimming it for key points – as many encyclopedia readers do. Our manual is in keeping here with at least some other major style guides, and has served as stable guidance and a sound reference point for Wikipedia editors for many years. NebY (talk) 18:02, 17 April 2024 (UTC)

• I don't care whether the boundary is at non, ten, or eleven. Tony (talk) 04:48, 25 May 2024 (UTC)

I have a question regarding numbers. What if a number below 10 is part of a larger number that is partially spelled out? For example, 3 million, 4 thousand, 6 hundred, etc? Also note that numbers below 10 are not spelled out in {{Convert}} which is inconsistent with this MOS. Volcanoguy 17:48, 17 June 2024 (UTC)

Just happened to see this pop up; I'll record that, while I don't think it's a big deal, it would make sense to me to include "ten" as the last use-words number. I think that's what I learned in typing class. Also the English names up through ten all have five letters or fewer, whereas from eleven on they generally have six or more (the exceptions I can think of being "forty", "fifty", "sixty" — I think that's it? unless you count mega, which few people would). One thing we should emphasize in any case is to avoid mixing; don't say the winner got 13 points and the loser got seven. But I assume without checking that this is already mentioned. --Trovatore (talk) 18:14, 17 June 2024 (UTC)

And I know without checking that it is. EEng 18:19, 17 June 2024 (UTC)

Templatizing date format

With regard to the discussion above on date format, I have a technical proposal. Under Preferences > Appearance there's a "Date format" option, allowing editors to select DMY, MDY, or YMD for their personal display. For example, this works with the templates {{Birth date}} and {{Death date}}; if the parameter df= or mf= is not specified, it will display based on the user's set preference. However, it does not seem to work with the template {{Date}}. If the "Date format" preference were enabled for the template {{Date}} (and the parameters df= or mf= deprecated, or overridden by the "Date format" preference), a bot could presumably templatize all dates, and users that prefer DMY or MDY would always see dates displayed in their preferred format—and this would presumably overcome the objections of anyone committed to a particular date format. There would be some details to work out, such as dates without years, ranges of dates, and so on, as well as protecting date formats in quotes. I am not technically able to work on this (and there may be pitfalls I haven't anticipated), but it seems like it could be considered as a solution. Doremo (talk) 08:02, 24 June 2024 (UTC)

See User:Dabomb87/Summary of the Date Linking RFCs. An earlier method to let users see dates in their preferred format was to link the date to the articles about the day of the year and the year, and the system would then attempt to display in the format set in the user's preferences. This was ripped out as an utter failure. One of the chief reasons was that readers with no account couldn't set a preference. Editors usually did have accounts. So the dates in an article would be a mish-mash of different formats, which would (presumably) annoy most readers but wouldn't be noticed by the editors who could fix it. Jc3s5h (talk) 13:24, 24 June 2024 (UTC)

In addition, I challenge Doremo's claims "For example, this works with the templates Birth date and Death date; if the parameter df= or mf= is not specified, it will display based on the user's set preference."

But the Template:Birth date documentation for the Birth date template states "The default output of this template is to display the month before the day." Please prove that your claim is correct. Jc3s5h (talk) 13:30, 24 June 2024 (UTC)

If a previous attempt was poorly executed, it doesn't mean that someone with better skills couldn't execute it better. I presume that readers with no account would view a consistent default template output if all dates were templatized. If I look at an infobox with {{death date|1807|6|26}} (e.g., here: John Smith (antiquary)) and my "Date format" preference is set to MDY, it displays as "June 26, 1807". At the same time, the template {{date|1807-6-26}} in the lede displays as "26 June 1807". I don't know if that's true for everyone that looks at that page. Doremo (talk) 13:42, 24 June 2024 (UTC)

Jc3s5h is correct (I see now that I misread the part about the default output). I agree that the "Date format" preference does not affect the display of the {{Birth date}} and {{Death date}} templates. I do not know if "Date format" preference can be made to affect displayed output on a template; it's a technical matter beyond my skills. Doremo (talk) 14:14, 24 June 2024 (UTC)

IIRC certain templates (certain citation templates for sure) understand and obey Template:Use MDY dates and Template:Use DMY dates. Not sure what other templates do. Those features are a far cry from automagically formatting dates in running article text. Yes, it would be possible to wrap all dates, everywhere, in some special template, but see my comments lower down in this thread. EEng 21:28, 24 June 2024 (UTC)

People who were heavily involved in Wikipedia development were involved in the date linking fiasco and ultimately decided recognizing date preferences for readers who were not logged in would create an unacceptable performance degradation. Jc3s5h (talk) 14:39, 24 June 2024 (UTC)

• Trust me on this one. Nothing like this is ever going to happen. And if it did, it would represent a massive waste of development resources. There are many, many truly important things we've been waiting years and even decades for, and this isn't one of them. EEng 21:21, 24 June 2024 (UTC)
• It would complicate caching, for little benefit: readers are not confused by seeing either format, even if it's not the one to which they're most accustomed. isaacl (talk) 01:15, 25 June 2024 (UTC)
• Thanks for the various feedback above; I accept that it's not a viable option. Doremo (talk) 03:35, 25 June 2024 (UTC)

Age ranges

An experienced editor has changed "2,251 children are in the age group of 0–6 years", to "2,251 children are in the age group of zero–six years" with an edit summary of MOS:NUMERAL. This seems extremely awkward, are children referred to as "Zero" years old?, but "nought-six" is also unnatural. However, it does seem to comply with the wording of MOS:NUMERAL, whereas 0-6 does not.
This may seem a minor point, but 0-6 is the range used in the census of India, and many other countries, so would affect tens of thousands of articles. Any comments/clarification of the guideline appreciated. - Arjayay (talk) 09:49, 27 June 2024 (UTC)

I would suggest something like "age group of up to six years" or "... six years or less". Gawaon (talk) 10:35, 27 June 2024 (UTC)

Irrespective of context, to write "zero–six" of anything looks mighty weird. It should always be "zero to six". Dondervogel 2 (talk) 10:49, 27 June 2024 (UTC)

If the article is also considering other age ranges (eg children aged 7–14, students aged 18–25) then I'd say we should use numbers throughout, per Comparable values nearby one another should be all spelled out or all in figures and for clarity in presenting statistics. If we're going to use words then it should be phrased appropriately per Gawaon or Dondervogel2 or "aged up to six" and suchlike, not with a mere replacement that's neither one thing nor the other. NebY (talk) 10:56, 27 June 2024 (UTC)

Inconsistency

What do I do at Masaya Kimura (singer)? The subject is Japanese so MOS:ENGVAR is irrelevant. The article was published with "Use British English" and "Use mdy dates" which doesn't make sense because dmy is the norm in the UK. [41] And then later on, someone came by and replaced "Use British English" with "Use American English" AND "Use Canadian English" without leaving an edit summary explaining why. [42] So I guess the question is do I change it back to Use British English per MOS:RETAIN and does that mean I retain "Use mdy" or can I change that to "Use dmy"?  Bait30  ^{Talk 2 me pls?} 07:57, 30 June 2024 (UTC)

Per MOS:RETAIN and MOS:DATERET, "Use British English" and "Use mdy dates" should both be retained. However, if you think that DMY dates are preferable, you can ask on the talk page if anybody would object to such a change, and if nobody does (within a week or so), go ahead and change it. Gawaon (talk) 08:29, 30 June 2024 (UTC)

MDY is standard for Japanese articles in my experience. GiantSnowman 09:30, 30 June 2024 (UTC)

There wasn't any problem of inconsistency. On Wikipedia, using British English doesn't require using DMY dates; as MOS:DATETIES says, For any given article, the choice of date format and the choice of national variety of English (see Wikipedia:Manual of Style#Strong national ties to a topic) are independent issues. So as Gawaon says, "Use British English" and "Use mdy dates" should both be retained (barring consensus to the contrary) and as GiantSnowman says, MDY is normal for articles about Japanese subjects. NebY (talk) 15:15, 30 June 2024 (UTC)

Everything you say is correct, except for the idea that there's any date format "standard", or engvar "standard", for Japanese subjects (or any other subject not strong-tied to an English-speaking subject). EEng 18:19, 30 June 2024 (UTC)

Hence my use of "normal" rather than "standard". NebY (talk) 18:48, 30 June 2024 (UTC)

I didn't mean any criticism of you. It's just I'm a bit, um, hot under the collar because of time wasted along these lines elsewhere on this page recently. EEng 19:52, 30 June 2024 (UTC)

Right, there's no requirement that American English be coupled with MDY or that British English be coupled with DMY. Gawaon (talk) 15:42, 30 June 2024 (UTC)

As far as I can tell, there is nothing in the "Manual of Style" or any of the related pages saying that MDY is normal for articles about Japanese subjects. Perhaps the basis of this statement is that one or more of the editors of this thread have read a bunch of English Wikipedia articles about Japanese subjects and noticed the predominant date format is MDY. Or maybe the editors asserting this have some other basis for the statement. Personally, I haven't read many articles about Japanese subjects so have not formed an impression about what date format is most common. Jc3s5h (talk) 15:55, 30 June 2024 (UTC)

Yes, it's from experience, something you acknowledge you don't have in this area. GiantSnowman 16:29, 30 June 2024 (UTC)

Luckily, your experience and Jc3s5h's lack of experience are irrelevant: there's no "standard" for articles not strong-tied to an English-speaking country. A dozen editors just spent a week, on this very page, getting you to understand that, and yet here you are playing the "experience" card as a cover to keep spouting misinformation. Meanwhile, of course, you haven't supplied the link requested here [43], though you've made some edits since I made that request (which included a ping to you). Any chance you can get around to that sometime soon? EEng 18:19, 30 June 2024 (UTC)

I also have years of experience of dates in Asian countries and it tells me that MDY is not the norm in Japan. Most Asian countries use YMD in their native language. In English, businesses tend to use either the date format of their biggest customer. When this is not the most important thing then they tend to use the format used by their teacher. If they (or their teacher) studied in England then they use DMY. If they studied in the US then they use MDY. It's very much an arbitrary thing. It's irrelevant in this case anyway but I bring this up because I have seen you say this before and I want you to know that it is not a valid argument.  Stepho  talk  21:31, 30 June 2024 (UTC)

It won't sink in, I assure you. EEng 00:23, 1 July 2024 (UTC)

Quite possibly true. But I don't want him to say "I mentioned this multiple times before and nobody objected."  Stepho  talk  03:00, 1 July 2024 (UTC)

I realize now that you didn't have the pleasure of following last week's discussion. See #Discussion on other talk page and project. Delicious. EEng 03:06, 1 July 2024 (UTC)

Ahh I missed that sentence under MOS:DATETIES, thanks.  Bait30  ^{Talk 2 me pls?} 18:26, 30 June 2024 (UTC)

Wikipedia date formats

• I agree with Gawaon that MOS:RETAIN and MOS:DATERET apply to Masaya Kimura (singer) and that "strong national ties" does not apply because he appears to have no strong tie to an English-speaking country. As it was created with UK English but mdy dates, consensus on the article talk would be needed to change either of those. That choice of styles is idiosyncratic but not actually inconsistent as there is no logical tie between dialect and date style. Inconsistency in style from other members of similar groups could be a valid argument for a style change, but a matter for the article talk rather than here; I don't think we want to legislate that sort of thing as a global rule, because it's too nitpicky to make a good rule. —David Eppstein (talk) 19:13, 30 June 2024 (UTC)

  Yes, and just to use this as a teachable moment, because of the time wasted on stuff like this recently: the budding debate, a bit above, about who has more experience in judging what is normal or standard in a give topic area is exactly the reason MOS:DATETIES and MOS:DATERET specify that, in general, there is no normal or standard to debate about: it's first come, first served, nothing to debate, doesn't matter what various editors think their experience is. EEng 19:59, 30 June 2024 (UTC)

  Agreed. Tony (talk) 05:15, 1 July 2024 (UTC)

Adjectival ordinals for centuries and millennia BC

This is subtle and requires several simultaneous conditions, but I run into it enough that I think it might be worth a sentence of explication. I was also sure before, but I'm less so now, having reread the relevant guidelines.

With ordinals e.g. 2nd century BCE and 1st millennium BC, are we meant to use a hyphen or an en dash in the adjectival form? It's multiple words, but they're not quite independent wholes as described in MOS:ENBETWEEN; the era designator also isn't quite an affix as per MOS:AFFIXDASH. Remsense诉 22:21, 30 June 2024 (UTC)

• I'll activate our team of rabbis. EEng 00:18, 1 July 2024 (UTC)
• I can't say I've ever been confident on when to use one or the other in a lot of cases, but I've used hyphens (the doohickey next to the zero on my keyboard) many times in phrases like "a 2nd-century coin" and no one's complained yet. SchreiberBike | ⌨  01:38, 1 July 2024 (UTC)

That's clearly correct. But it begins to look weird when it gets to pre-2nd-century-BCE coins or post-World-War-II morality or Empire-State-Building-sized project. I think that's what the query is about. I used to know how to handle stuff like that but I'm too tired to think now -- and IIRC it sometimes involves en edashes (or, you might say, it's an en-dash–related issue) and I'm not up for an en-dash argument right now. EEng 01:50, 1 July 2024 (UTC)

Sorry for writing up another puzzle for folks! 2nd-century (adj.) is very much correct. I'm curious about how to write 2nd-century BC (adj.) Options seem to be:

1. 2nd-century BC – It's likely that no one would ever get mad at this; it seems the cleanest.
2. 2nd–century BC – Seems wrong, especially when used alongside AD/CE centuries that use a hyphen.
3. 2nd-century-BC et al. are clearly unacceptable; I think this is probably a rule of thumb for adjectival phrases longer than two words.

Well, I guess I've answered my own question by writing it down properly. Dangit. Remsense诉 02:01, 1 July 2024 (UTC)

Oh, I guess this isn't totally worthless—might it be worthwhile to include an example with BC next to the ones without it? Remsense诉 05:21, 1 July 2024 (UTC)

So your proposal is "2nd-century BC" (1)? Looks fine for me too. Gawaon (talk) 06:25, 1 July 2024 (UTC)

That's right and in agreement with Fowler's Modern English Usage, in particular that

• we use hyphens to avoid misinterpretation (a second-century coin, not a second century coin).

• Avoid creating words with multiple hyphens. Burchfield suggested that phrases such as early-nineteenth-century poets can always be written as poets of the early nineteenth century instead, which, though longer, is probably easier for readers to process. Similarly ... instead of a nuclear-weapon-free world ... a world free of nuclear weapons. Hyphenating should not become burdensome.
  — hyphen, 4th edition

NebY (talk) 11:17, 1 July 2024 (UTC)

Discussion on other talk page and project

See Wikipedia:Village pump (policy)‎#MOS on date format by country and Talk:Lisa del Giocondo‎#Edit warring about whether the date format customary in a non-English speaking country has any bearing on what date format should be used in an English Wikipedia article. Jc3s5h (talk) 22:31, 16 June 2024 (UTC)

The answer is yes, we should use the local date format regardless of the language spoken. GiantSnowman 17:58, 18 June 2024 (UTC)

DATETIES vs. DATEVAR/DATERET

I agree with Eeng's edit to make it even clearer that DATEVAR/DATERET is referring to DATETIES when it says "strong national ties". This was already clear to me, but it seems like the change will help avoid an interpretation that would put the two in parts of the guideline in conflict with each other. It has been evident since this guidance was first added that the two parts are meant to be harmonious. Firefangledfeathers (talk / contribs) 18:00, 18 June 2024 (UTC)

I personally think it's pretty silly to have MDY set on articles whose topic doesn't touch North America. It's just awkward to work with when most quotes and literature will be in the other format. Remsense诉 18:00, 18 June 2024 (UTC)

"most quotes" is an interesting one. I could see that being a strong basis for change based on talk page consensus. Firefangledfeathers (talk / contribs) 18:10, 18 June 2024 (UTC)

There's also cultural reasons when terminology used in the article is usually tied to a certain order. I do feel this is a distinct issue from ENGVAR. Remsense诉 18:15, 18 June 2024 (UTC)

Could you give an example of what you mean here? Firefangledfeathers (talk / contribs) 18:26, 18 June 2024 (UTC)

This all started with Lisa del Giocondo using MDY, even though Italy used DMY and all related significant articles to that one use DMY... GiantSnowman 18:53, 18 June 2024 (UTC)

Thanks, but I meant examples of "terminology used in the article" that is "tied to a certain order". Firefangledfeathers (talk / contribs) 18:59, 18 June 2024 (UTC)

I'll retract this for now, as I can't actually think of a good example. I'll update this if one pops into my head. Remsense诉 19:33, 18 June 2024 (UTC)

I don't actually really care if you want to tweak the wording here. However, my strong position remains that we should use the local date format regardless of the language spoken. Remove "English-speaking countries" to reflect this. GiantSnowman 18:01, 18 June 2024 (UTC)

I'm not at all opposed to changing the guidelines collectively so that they match your preference here. It's just that I do conceive of that as being a substantive change, and I'd like to see it run through the proper process. In the meantime, I think it's important that we have language in our guideline that is internally consistent. Firefangledfeathers (talk / contribs) 18:19, 18 June 2024 (UTC)

I too think that EEng's change (which was reverted by GiantSnowman) is constructive – it's very clearly just expressing what the current guidelines are meant to express, just didn't quite as clearly because (I suppose) nobody thought that the brief backreference to the more detailed language in DATETIES would be misinterpreted. Gawaon (talk) 18:24, 18 June 2024 (UTC)

I also agree that EEng's change was a good one that added clarity to established style. Doremo (talk) 18:34, 18 June 2024 (UTC)

I would agree with this, which reflects my impression of how most articles already are, except where someone has decided to make date format an issue. MapReader (talk) 19:32, 18 June 2024 (UTC)

"English-speaking countries" is appropriate in the guidelines. There is no reason why English-language material on Wikipedia should be subordinated to a pattern in a non-English language—whether this is date format, punctuation, alphabetization, calendrical system, numbering system, first/last name order, or any other language feature. Doremo (talk) 18:23, 18 June 2024 (UTC)

Actually, there are pretty clear distinctions there: some concern how a specific language is written, and others are invariant of the language being written. Also wait, name order? Are you suggesting we put every biography by default in given-family order, assuming there's not an existing English-language COMMONNAME? That's loony.Remsense诉 18:25, 18 June 2024 (UTC)

That's right. Looking at a non-English language to decide how to write English is loony, as you put it. Doremo (talk) 18:31, 18 June 2024 (UTC)

No, you are painting with the world's broadest brush and conflating a lot of different things into "English vs. non-English", and it sounds ridiculous. It's not how any other publication on Earth would do things. Remsense诉 18:31, 18 June 2024 (UTC)

To be clear, this would result in new biographies of Chinese people being written in an order that is used by no one except us, and then we would always have to change it to the right way around when we notice that other English-language sources are doing the natural, obvious thing. Inane. Remsense诉 18:40, 18 June 2024 (UTC)

GiantSnowman, since you seem most committed to getting this changed, could you suggest a rewording to MOS:DATETIES that you would prefer? To discuss this, I think it would help to know what specifically the alternative would be – and when I look at DATETIES, it doesn't seem all that trivial to find one. Gawaon (talk) 18:59, 18 June 2024 (UTC)

I have no issues with EEng's proposed wording, minus "a particular English-speaking country", which instead should just be "a particular country" or "particular date format" or similar. GiantSnowman 19:31, 18 June 2024 (UTC)

I agree with the overwhelming majority here, that EEng's edit should be restored. It clearly reflects both the original intent of the guideline and the consensus here. JoelleJay (talk) 04:29, 4 July 2024 (UTC)

I do not want to see us make a change that would cause us to use 2024 June 18 (nor 2024-06-18) as the main date format for articles about Japan-related topics. For this sort of reason, I prefer to continue to restrict this guideline to only apply to English-speaking countries, and I would prefer to reinstate EEng's edit to clarify this continued restriction. —David Eppstein (talk) 19:04, 18 June 2024 (UTC)

That's not what anyone wants. DMY is preferable to MDY since we naturally don't use YMD. Remsense诉 19:07, 18 June 2024 (UTC)

Yeah, the date formats used are DMY or MDY. In my experience Japanese topics tend to use MDY. GiantSnowman 19:31, 18 June 2024 (UTC)

Right, that's currently the case (since your suggested rule modification is not yet in force), but can anyone of us say with any certainly which date formats are usual in arbitrary non-English-speaking countries? If it's YMD or YDM or something like that, that would be quite awkward to try to mimic in English. Hence I think just striking "English-speaking" is not going to fly. Gawaon (talk) 20:12, 18 June 2024 (UTC)

The usual Japanese format appears to be Y-M-D, written out in numerals, with kanji after each number specifying what it is [44]. If we were required to follow national ties for non-English-speaking countries, some kind of Y-M-D format would be the one. Probably YYYY-MM-DD since that's the only one in that order that matches our MOS. GiantSnowman, if you want the guideline to be "follow national ties only for countries that have M-D-Y or D-M-Y format and otherwise do something else" then you need to be more specific rather than focusing the current discussion on following national ties more generally for all non-English-speaking countries. It sounds to me like your intended proposal is really "allow Americans to use M-D-Y and force all other topics to use D-M-Y", regardless of whether that is relevant for the nation in question. Your experience of what we have historically tended to use for our articles on topics from those countries is not particularly relevant. National ties means ties to a format used by people in that nation, not accidents of past Wikipedia editing. —David Eppstein (talk) 20:47, 18 June 2024 (UTC)

Since, for good reasons, the "Manual of Style/Dates and numbers" only allows the YYYY-MM-DD format for dates from the year AD 1583 and onward, and only for Gregorian dates, some articles with strong ties to some countries in eastern Asia would not be able to use the YYYY-MM-DD format. And what about other than dates containing the year, month, and day. How would a date like June 18 be formatted? Where would an English-speaking editor find that information? Jc3s5h (talk) 20:57, 18 June 2024 (UTC)

Nobody is suggesting we use YMD, given that that is not an established format on English Wikipedia. GiantSnowman 17:58, 19 June 2024 (UTC)

List of date formats by country? Hawkeye7 (discuss) 20:54, 18 June 2024 (UTC)

Since "List of date formats by country" was written and is maintained by the same editing community that inhabits this talk page, except editors seem to pay less attention to it, I pay no attention to it. Jc3s5h (talk) 20:59, 18 June 2024 (UTC)

To the list, or to this MOS page? Hawkeye7 (discuss) 21:27, 18 June 2024 (UTC)

I pay no attention to the article, because I have no confidence in its factual correctness. I pay attention to the style manual because style manuals are arbitrary decisions by a publication. Jc3s5h (talk) 21:53, 18 June 2024 (UTC)

Jc3s5h, unsure if you're trolling or having AI write your responses for you? GiantSnowman 17:58, 19 June 2024 (UTC)

I understand GiantSnowman's concern about using the local date format regardless of the language spoken. However, I also recognize the concerns of other editors, such as David Eppstein, that using local date formats could introduce non-dmy or non-mdy date formats, such as Japan's yyyy-mm-dd.

To address both viewpoints, we could add a new sentence to the manual of style, such as For articles about non-English-speaking country, the date format used should generally match the one most commonly found in English-language sources from that country. For example, in the case of Japan, the mdy format is used because English-language sources from Japan such as NHK, Japan Times, Mainichi, Asahi Shimbunand Kyodo News all use it.. What do you think about this suggestion? Ckfasdf (talk) 03:09, 19 June 2024 (UTC)

No, no, no. First of all, a provision addressing articles "about a non-English-speaking country" is useless, because it would only apply to the articles Japan and Russia and Rwanda and so on. Second, changing "ties to an English-speaking country" to just plain "ties to a country" is an absolutely terrible idea, as I will describe below. EEng 08:32, 19 June 2024 (UTC)

Not sure why we are duplicating the discussion that is at Wikipedia:Village pump (policy)#MOS on date format by country. Anyway...

Beware that Japan does not have a default English language format. They use whichever format they have business partners with or whichever format the individual person learnt from his/her teachers. If they deal more with Brits/Aussies then they use DMY. If they deal more with yanks then they use MDY. The sources you listed are all closely tied to finances and the US leads the world's economy (rightly or wrongly), so therefore they follow MDY. Plenty of other sources from other industries in Japan use DMY too.

I'm in favour of adding an extra rule something like For topics closely tied to a country that uses DMY or MDY (the 2 formats used in English) then that format should be used.

And we continue to avoid local formats that are not DMY or MDY from prose, using the existing first-come rule for anything else.  Stepho  talk  06:06, 19 June 2024 (UTC)

Yeah, that would be fine with me too. Broaden the "close ties" rule, but only for cases where DMY or MDY are locally dominant. Gawaon (talk) 06:22, 19 June 2024 (UTC)

As for duplicating discussions: I think this is the best place to have this discussion, since it's the talk page of the page where the rule is formulated. Gawaon (talk) 06:23, 19 June 2024 (UTC)

I think this would be fine. Remsense诉 06:33, 19 June 2024 (UTC)

Do you mean the proposed "should generally match the one most commonly found in English-language sources from that country" wording? Gawaon (talk) 07:27, 19 June 2024 (UTC)

Yes. Remsense诉 07:28, 19 June 2024 (UTC)

Hmm, the more I think about it the more I think that that particular wording would be highly impractical to actually use. We know that DMY is dominant in Italian-language publications, but it would shift the burden to English-language publications coming out of Italy. Which are those, and how do we find them? Do we have to make statistics on English-language publications from (say) Ethiopia before we can write about topics related to that country? Gawaon (talk) 07:36, 19 June 2024 (UTC)

I don't see it as that problematic? Something like If there is a clear preference in English-language publications from the country, use that. If not, defer to the choice of the first main contributor. Maybe you see clear as a qualifier that will just be argued over, but I think it works as a safety valve here? Remsense诉 07:48, 19 June 2024 (UTC)

Oh no, I've just realized that both English People's Daily and Xinhua use MDY. What have I done! SCMP uses DMY though. Remsense诉 07:53, 19 June 2024 (UTC)

Right, so there we have one publication that uses one style and two that use the other one. Is that a "clear preference"? Almost certainly not – just find another publication and the score might be balanced. Also, do you know which date style English-language publications from Italy prefer? Even if you know (certainly only after doing your research, since you can't know without) where would the results of this WP:OR be documented so that others can know too? And why should we suddenly be expected to do OR here, which in Wikipedia is otherwise forbidden? Gawaon (talk) 08:32, 19 June 2024 (UTC)

Aye, I think I've now come around to EEng's formulation. Remsense诉 08:33, 19 June 2024 (UTC)

• This suggestion ("a country that uses DMY or MDY") is flawed for several reasons. First, it would make the English dependent on the patterns of a non-English language (i.e., follow the patterns of Korean, Finnish, etc. when writing about Korea, Finland, etc. in English). Second, many countries are not monolingual, and so the editor would need to choose which foreign language to imitate in English (note that it is languages that use DMY, MDY, YMD, etc., not countries per se). Third, it raises additional issues involving subordination of English to foreign languages (for example, Slovenian does not use the serial/Oxford comma, and so by analogy the English serial/Oxford comma would be forbidden in articles about Slovenia or Slovenian topics). Fourth, this places an onus on editors to conduct original research on languages: who really wants to study date format in Tucano or Khoekhoe before editing English-language articles about them? If the suggestion refers to "English-language sources from that country", this raises the additional burden of more original research (determining which English-language sources from county X are representative or dominant) and the problem that English-language sources produced in countries where English is not a native language are not reliable sources of standard English usage. The status quo at MOS:DATETIES and MOS:DATERET has worked well for years and should be retained. Doremo (talk) 07:35, 19 June 2024 (UTC)

  The status quo at MOS:DATETIES and MOS:DATERET has worked well for years and should be retained – Amen. There are two issues here:

  • Question 1: Was my edit [45] a substantive change, or merely a clarification of what was undoubtedly both the intent of the guideline and the (almost) universal understanding of it?
    Answer: Gawaon (commenting above) has it right: my change was (if I do say so myself) very clearly just expressing what the current guidelines are meant to express, just didn't quite as clearly because (I suppose) nobody thought that the brief backreference to the more detailed language in DATETIES would be misinterpreted.
  • Question 2: Instead of changing DATEVAR/DATERET's "country" to read "English-speaking country" -- thereby making its wording consistent with DATETIES -- should we instead change DATEVAR's "English-speaking country" to just "country", so that everything now just says "country"?
    Answer: This would be a disaster. The reason DATEVAR/DATERET and DATETIES are what they are (i.e. the test is English-speaking country, not just country -- even if DATERET is elliptic on that point) is this:
    • American editors (for example) find it dissonant to read that Roosevelt died "12 April 1945", while British readers feel the same about Churchill dying "January 24, 1965". The strong-ties provision says what to do in those cases, and edit-warring is avoided.
    • But what about Philip II of Macedon? Should he die "21 October 336 BC" or on "October 21, 336 BC". Should we use strong ties to figure that out? If so, are his ties to Macedonia, which doesn't exist anymore? Greece, maybe? OK, let's say we eventually settle on Greece -- then we have to research, and maybe argue about, which date format is used in Greece. And for what? Greek readers are reading the Phillip article on the Greek Wikipedia, not ours. We're not going to get a lot of editwarring over Phillip's date format.
    • This is why the guideline recognizes only ties to English-speaking countries: it's a restricted set of articles where "strong ties" are relatively easy to determine, where the associated country's date format is well known, and where editwarring to "correct" any Roosevelt-Churchill dissonance previously described is relatively likely. None of that applies to Phillip, and that's why the "first major contributor" test is the path of least resistance for that article (and other articles with no strong English-speaking country ties). (This isn't the best explanation I've ever given in my life, but it's the best I have time for.)

  The purpose of the guideline is avoid style churn and editwarring, not to have the "just right" format for articles about Ethiopia. The idea that we're going to debate the clear preference in English-language publications from the country is either a joke or part of a plot to destroy Wikipedia from the inside. I modestly propose that we adopt my extremely excellent edit (linked earlier) -- which doesn't actually change anything, but rather clarifies what already exists -- and drop this mad idea of changing "English-speaking country" --> "country", which would open a Pandora's box to no benefit at all. All in favor? EEng 08:45, 19 June 2024 (UTC)

  In favor. Restore the clarification [46] by EEng and maintain the status quo. Doremo (talk) 09:13, 19 June 2024 (UTC)

  Support the status quo ante (DATETIES applies only to English-speaking countries and DATERET applies in all other cases). Also support date formatting choices for readers (like we had 20 years ago). —Kusma (talk) 10:11, 19 June 2024 (UTC)

  In favour, let's keep the status quo, but including EEng's clarification which (while not changing it at all) makes misreadings less likely. I wasn't opposed to changing the rules to encourage DMY for countries where that's locally the default (many European countries at least), but making a clear-cut rule of out that seems more trouble than it's worth. Gawaon (talk) 10:43, 19 June 2024 (UTC)

  I say just so to EEng's edit at 8:45 in the morning on the 19th day of June in the year of our Lord 2024, Greenwich Mean Time. Jc3s5h (talk) 11:47, 19 June 2024 (UTC)

  Shirley you mean UTC. GMT went out with the horse and buggy. Jeesh. EEng 17:50, 19 June 2024 (UTC)

  While I realise you are joking, Mr Feynman, just pointing out that Greenwich Mean Time is still a thing. Dondervogel 2 (talk) 18:38, 22 June 2024 (UTC)

• As stated by others, the purpose of a style guide is to make arbitrary style decisions once, so they don't have to be debated repeatedly. The guidance on strong national ties and retaining the initial variant in one sense acts against this principle, but it tries to avoid needless churn by allowing editors interested in a given topic to use what would be a natural format for them. Having to evaluate the preferred date format on a country-by-country basis for English-written texts in that country just opens up the door further for more debate, with little benefit since all these formats are understood by all readers, even if it's not what they're most used to. isaacl (talk) 14:03, 19 June 2024 (UTC)

  Why couldn't you have posted your short, incisive explanation last night, thus preempting me from inflicting my long, rambling post on everyone? EEng 16:06, 19 June 2024 (UTC)

  It's all part of the process—you ramble, I ramble, I realize I'm wrong, we all grow a little bit. Remsense诉 16:45, 19 June 2024 (UTC)

  It takes a Wikivillage to raise an editor. EEng 22:16, 19 June 2024 (UTC)

Going once... EEng 09:00, 21 June 2024 (UTC)

Going twice... EEng 06:08, 22 June 2024 (UTC)

I repeat - we should change "English-speaking country" --> "country", given that certain non-English language countries do have specific date formats which are appropriate for the English-language Wikipedia (see e.g. Date and time notation in Italy). GiantSnowman 06:20, 22 June 2024 (UTC)

How about actually engaging with the objections made to this idea by various editors above? Gawaon (talk) 06:51, 22 June 2024 (UTC)

Nobody has explained why topics related to non-English language countries (of which we probably have at least dozens!) should not have sensible and appropriate date formatting. GiantSnowman 10:13, 22 June 2024 (UTC)

Well of course nobody has explained why topics related to non-English language countries should not have sensible and appropriate date formatting, because nobody is advocating that topics related to non-English language countries should not have sensible and appropriate date formatting. What we are doing instead is discussing what constitutes "sensible and appropriate date formatting" -- except you, who just say over and over what you want.

So I'll repeat Gawaon: How about actually engaging with the objections made to this idea by various editors above? EEng 14:42, 22 June 2024 (UTC)

It's quite difficult to engage with people who accuse their opponents of being "part of a plot to destroy Wikipedia from the inside". GiantSnowman 14:45, 22 June 2024 (UTC)

And if that accusation had actually been made, that would be understandable. For my part, I find it difficult to engage with someone who uses feigned (or -- worse -- actual) inability to grasp hyperbole as an excuse not to engage the detailed, careful reasoning of his or her fellow editors. EEng 21:44, 22 June 2024 (UTC)

I don't normally participate in debates about date formatting, but something attracted me to this one because I can't help but agree with GiantSnowman's view, that MOSNUM can do better than say "choose whatever date format you want". It has been pointed out that the whole point of a style guide is to provide a norm, even when (or perhaps especially when) there is no precedent for that norm. "Why?!?" I here you all ask (all except GiantSnowman, that is). Well, because that is what the style guide is for. Its whole raison d'etre is to facilitate a harmonised encyclopaedia by specifying such norms. Why would that not apply to articles that have no clear attachment to an English speaking country? None. None at all. Dondervogel 2 (talk) 18:49, 22 June 2024 (UTC)

Let's see...

• Why would that not apply to articles that have no clear attachment to an English speaking country? – Because it would require determination of the strong ties between 1,000,000 articles topics (literally -- and that's a conservative minimum) and countries, and 200 debates on what the right date formats are for the various countries, and a way to memorialize the result of those debates, and editors to consult that archive every goddam time they write an article related to some obscure country -- all to no benefit. See Gawaon's post just above, and my long post before that. EEng 21:44, 22 June 2024 (UTC)

I am not arguing for determining local customs in non-English speaking countries when writing in English. I accept that is unworkable. Just pick either DMY or MDY and apply it to all articles without a strong connection to one or other. Dondervogel 2 (talk) 22:55, 22 June 2024 (UTC)

My position on this has shifted since reading List of date formats by country, which suggests an overwhelming preference for DMY outside North America. A reasonable rule might be "pick DMY unless there is a good reason to prefer MDY". Permissible "good reasons" could then be listed, including subjects closely associated with USA. Dondervogel 2 (talk) 16:31, 23 June 2024 (UTC)

Yes, for example Philippines uses MDY in my experience, due to historical links to US. But in Europe, I pretty much only ever see DMY. GiantSnowman 16:41, 23 June 2024 (UTC)

• It has been pointed out that the whole point of a style guide is to provide a norm, even when (or perhaps especially when) there is no precedent for that norm. – False. As expressed by the brilliant author of WP:MOSBLOAT:

Something belongs in MOS only if (as a necessary but not sufficient test) either:

• 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 ...

The purpose of MOS is absolutely not to go out of its way to prescribe stylistic choices just to fill a vacuum.

EEng 21:44, 22 June 2024 (UTC)

I'm not arguing for inventing a rule where one is not needed. I had the impression that editor time is being wasted by edit warring between DMY and MDY. Was my impression incorrect? Dondervogel 2 (talk) 23:04, 22 June 2024 (UTC)

Yes there has been editwarring -- by GiantSnowman [47] [48] [49] [50] [51] [52], based on his logically impossible interpretation that where DATEVAR/DATERET says "strong national ties", it means ties to any country whatsoever, rather than being an elliptical backreference to DATETIES's (immediately preceding) "strong ties to a particular English-speaking country". (BTW I'll just point out MOS:TIES, on the main MOS page, which also restricts its applicability to English-speaking countries only.) At this article talk page you'll see him asserting that "DMY is used for Italian topics" -- a statement for which there's no basis whatsoever, because for pages not tied to a particular English-speaking country, MOS doesn't ask editors to go research and argue about what format Italy or Botswana or Romania use -- it specifies first come, first serve. Giant Snowman apparently didn't understand that, and now that he does he wants to change it. He can propose that, but in the meantime I'm just trying to make the sure current guideline can't be misinterpreted as GS misinterpreted it. EEng 00:20, 23 June 2024 (UTC)

Unsure if you are continuing to ignore Date and time notation in Italy deliberately??? GiantSnowman 10:29, 23 June 2024 (UTC)

But do we have similar pages for all the 200 countries of today's world? And what about historical countries that no longer exist, and their conventions? Gawaon (talk) 10:44, 23 June 2024 (UTC)

See Category:Date and time representation by country. If a country has no established format, then nothing changes, does it? GiantSnowman 10:53, 23 June 2024 (UTC)

Thank you! And to make it perfectly clear, I am NOT proposing implementing just any date format - just the ones already established at en.wikipedia, being DMY or MDY. GiantSnowman 18:58, 22 June 2024 (UTC)

And neither is anyone else proposing anything other than DMY or MDY. EEng 21:44, 22 June 2024 (UTC)

Wrong. Someone has suggested YMD might be used. GiantSnowman 10:28, 23 June 2024 (UTC)

Right, and inevitably, because it logically follows from your proposal to simply remove "English-speaking" from DATETIES. Apparently you didn't mean it, but that that time you hadn't clearly explained what you meant, and so far you haven't proposed a wording that would actually achieve what you're apparently trying to achieve, namely allowing TIES to apply to any country that uses DMY or MDY (but not to any other). Gawaon (talk) 10:48, 23 June 2024 (UTC)

What's the issue with changing DATETIES from "Articles on topics with strong ties to a particular English-speaking country should generally use the date format most commonly used in that nation" to "Articles on topics with strong ties to a particular country should generally use the date format most commonly used in that nation where that date format accords with the formats in common usage on English-language Wikipedia"? GiantSnowman 10:57, 23 June 2024 (UTC)

Would be okay with me. Not sure if I would vote for it (since it would force a lot of changes with little obvious benefit), bit it's essentially the rule of thumb I use myself and I certainly wouldn't vote against it. But I guess a change of such magnitude would require an RFC or similar, and then we'll see how it goes. Gawaon (talk) 12:14, 23 June 2024 (UTC)

I don't think there would be such huge changes as feared. The majority of articles use the 'correct' format already. It's only when you have things like Americans writing articles on Italian topics (which is what started all this), meaning the original date format is out of kilter with all related articles... GiantSnowman 12:24, 23 June 2024 (UTC)

Example - Michel Fribourg being DMY for 7 years (including from article creation) even though topic is American... GiantSnowman 13:10, 23 June 2024 (UTC)

Let's go back to just Question 1

Let me see if I can untangle this. Earlier I foolishly bundled resolution of both my Question 1 and my Question 2 (both above) into a single package, which is now hung up on GiantSnowman's preoccupation with Question 2. I'd now like to re-propose resolving, first, only Question 1 by making my edit [53], which as Gawaon said was just very clearly just expressing what the current guidelines are meant to express, just didn't quite as clearly because (I suppose) nobody thought that the brief backreference to the more detailed language in DATETIES would be misinterpreted

After that's resolved then GS can argue for changing the guideline. Pinging back everyone who's participated so far: Firefangledfeathers, Remsense, Gawaon, Doremo, David Eppstein, MapReader, Kusma, Jc3s5h, Isaacl, Stepho-wrs, Dondervogel, 2 GiantSnowman, Hawkeye7. EEng 21:44, 22 June 2024 (UTC)

• Support for your edit regarding question 1: TIES should be considered only for English-speaking countries. (Americans writing about Cambodia should not be bound by whatever convention Cambodians use when writing dates). Ping @Dondervogel 2, @GiantSnowman as @EEng seems to have messed that up. —Kusma (talk) 21:56, 22 June 2024 (UTC)
• Support from me too, as might be expected. Gawaon (talk) 22:01, 22 June 2024 (UTC)
• Support from me for myself too, as also might be expected. EEng 01:48, 23 June 2024 (UTC)
• Yes on question 1: EEng's edit to DATERET to clarify that it only concerns English-speaking countries was not a substantive change, but an accurate clarification of long-standing consensus. Question 1 is only about the status quo ante, not about whether and how the consensus might change. —David Eppstein (talk) 22:07, 22 June 2024 (UTC)
• I don't have a view on question 1. Happy to abstain. Dondervogel 2 (talk) 22:50, 22 June 2024 (UTC)
• Support for your edit/clarification regarding question 1: TIES are considered only for English-speaking countries. Doremo (talk) 02:43, 23 June 2024 (UTC)
• Support that the edit clarified the current meaning of WP:DATETIES and WP:DATERET. I think the current meaning should be changed but that's question 2.  Stepho  talk  03:45, 23 June 2024 (UTC)
• I support EEng's edit, as stated above. I would be interested to see how future discussion on Question 2 goes, but the edit on the table now just clarifies the long-standing meaning of the guideline. Firefangledfeathers (talk / contribs) 03:56, 23 June 2024 (UTC)
• Oppose any change unless it is removal of 'English-speaking'. Ignoring national date formatting conventions (as shown by e.g. Date and time notation in Italy etc.) which aligns with the established formats in use on en.wikipedia (i.e. DMY and MDY) is a nonsense. GiantSnowman 10:31, 23 June 2024 (UTC)

  It's not a (substantive) change, though, just a clarification. Just saying. Gawaon (talk) 10:52, 23 June 2024 (UTC)

  Turning from 'country' to 'English-language country' is not just a clarification. GiantSnowman 10:54, 23 June 2024 (UTC)

  It is, though, because it's clearly just a backreference to DATETIES (just above) which always had "English-speaking country". But I bet you know this as well as anybody here, you just don't like to admit it. Gawaon (talk) 11:06, 23 June 2024 (UTC)

  Why is DATERET being "clarified" to match DATETIES, and not the other way around? GiantSnowman 11:08, 23 June 2024 (UTC)

  Because DATETIES is the actual rule, and the other one just points back to it to make it clear that there is no conflict between what these two sections say. DATERET is about retaining the date style, not about changing it. Gawaon (talk) 12:11, 23 June 2024 (UTC)

  Then, as I have said, remove 'English-speaking' from DATETIES. GiantSnowman 12:25, 23 June 2024 (UTC)

  See WP:IDHT. Why don't you hold your breath until you turn blue? That might convince people. EEng 18:28, 23 June 2024 (UTC)

• As Doremo wrote, "Support for your edit/clarification regarding question 1: TIES are considered only for English-speaking countries." Jc3s5h (talk) 00:52, 24 June 2024 (UTC)
• Support - this was simply a clarifying edit. --User:Khajidha (talk) (contributions) 11:36, 24 June 2024 (UTC)

Hey, GiantSnowman, do you agree that the consensus at this point is to reinstall my original edit? EEng 14:19, 24 June 2024 (UTC)

Yes. GiantSnowman 17:47, 24 June 2024 (UTC)

And after only 140 posts totaling 45K! So it's not like huge amounts of editor time got wasted arriving at the obvious. EEng 22:35, 24 June 2024 (UTC)

That's not fair. What was obvious to you was not obvious to others, including me. No one is disputing the consensus, but the editor discussion was needed IMO to achieve that consensus. Dondervogel 2 (talk) 23:40, 24 June 2024 (UTC)

Sure it's fair. You're to be excused because, as you mentioned, you haven't been involved in date format–related issues much before. GS has, and should certainly have known (and, for all I can tell, did know) the meaning of the guideline. If he hadn't insisted on repeatedly reverting multiple other editors in order to block the clarifying change which all other watchers understood to be nonsubstantive, none of this would have been necessary. He should have known better. Then, after it was explained over and over why "Question 1" was separate (and precedent to) "Question 2", he insisted on using his butthurt on Question 2 to attempt to block what, by then, was perfectly obviously the inevitable outcome on Question 1. Bad job. EEng 00:02, 25 June 2024 (UTC)

insisted on repeatedly reverting multiple other editors in order to block the clarifying change which all other watchers understood to be nonsubstantive, Hopefully no one will insist this discussion must be Formally Closed before the edit can be restored... JoelleJay (talk) 04:42, 4 July 2024 (UTC)

And of course this [54] (though wisely withdrawn [55]) didn't add to the festive atmosphere either. EEng 15:13, 25 June 2024 (UTC)

Why raise it then, other than to add to the sourness? GiantSnowman 16:23, 25 June 2024 (UTC)

Because it shows that, in addition to wasting a huge amount of editor time in pursuit of your personal hobbyhorse, your perspective is so distorted that it actually occurred to you that I might have used some dumb trick to gain the upper hand in a discussion where, quite obviously, my hand was already so upper that the Hubble telescope would be needed to see it. "Ha! I'll just accidentally fail to ping these guys so maybe they'll forget that a discussion they posted to two hours ago is still going on." Right. I'm crafty that way. EEng 16:47, 25 June 2024 (UTC)

Stow the 'tude please. GiantSnowman 17:31, 25 June 2024 (UTC)

'tude? You wanna see 'tude?

For years you've been told (and not just by me) that your stupid, broken date-fiddling script changes stuff in violation of MOS, but have you learned your lesson? Fixed the script? Found something useful to do? Nooooo. That's your hammer and for you article space is a collection of nails.

In 2020, you used your broken script to screw up a bunch of stuff in a particular article. In reverting you [56], I said (with amazing courtesy -- for me, anyway) ...

Please be more careful in the use of automated tools. None of these changes is appropriate: you've changed the established format of access dates in violation of WP:DATERET, removed a hidden note intended for future article improvement, and even changed verbatim quotations and titles of sources!

Let me repeat that: you changed verbatim text in quoted material and titles of cited articles, and even "fixed" the date inscribed on a physical object. Obviously you weren't paying attention. Then, unbelievably, last year you came back to the same article and did the same things. This time I was more forthright [57]:

User:GiantSnowman, this is the third or fourth time in the last year that I've caught you using some broken script to fuck up dates in literal quotations, tamper with articles' established date formats, and so on. What the hell do you think you're doing? You're an admin and should know better. And admin or not, I'm seriously considering proposing you be banned from making script-assisted changes.

It's like you have ONE job on this lousy project, it's stupid, but you're going to do it whether it improves anything or not. (And to sweeten the pot, you edit-warred with me and another admin -- one who takes the time to read and understand guidelines and documentation -- about the article subject's middle initial [58][59][60][61].)

And now here you've wasted a dozen people's time with your mixed-up reading of MOS. No wonder I'm pissed off at you.

There are many kinds of 'tude, dude. One of them is continuing to use your hobbyhorse script when you've had it rubbed in your face over and over that it breaks stuff. And you obviously aren't reviewing the script's changes before saving, in violation of the most basic rule for automated editing. So you stow the fucking 'tude, bro. Stop using your broken script until you can find someone to fix it for you; I'm sure there are plenty of soccer statistics you can occupy yourself updating. Peace out. EEng 23:02, 27 June 2024 (UTC)

Firstly, it's not my script, and I repeatedly raise improvement suggestions for it/flag bugs. That doesn't fit your agenda though, does it?

Secondly, the above rant (and that's all it is) reflects so, so poorly on you. I'm actually slightly embarrassed for you. There are far better ways of expressing yourself and raising concerns about a script than acting like this. GiantSnowman 11:16, 29 June 2024 (UTC)

As usual, you've used feigned shock at colorful expression to distract from the substantive issue, which is that your script (which is what it is when it's in your hands) makes changes against guidelines and policy, you've been told this for years, and yet you keep on using it. If you've asked for those problems to be fixed, and they haven't, please link to where that conversation is happening so I can participate.

Save your embarrassment for yourself. You need a full supply. EEng 18:31, 29 June 2024 (UTC)

I hereby solemnly declare this discussion closed. Thanks everyone for your participation! Gawaon (talk) 11:39, 29 June 2024 (UTC)

Deprecating "Since"

The advice in MOS:SINCE is contradictory in its treatment of the word "since". The goal of the section is to avoid phrases that are likely to go out of date, but it includes "since" in its recommended examples despite its time-dependency. Saying "She has been the director since 2010" indicates she is still the director, and so will go out of date. I propose the following edits. This leaves "since" as recommended only in the sentence specifically about current and future events, where the use should be flagged for time-dependency.

Except on pages that are inherently time-sensitive and updated regularly (e.g. the "Current events" portal), terms such as now, today, currently, present, to date, so far, soon, upcoming, ongoing, since and recently should usually be avoided in favor of phrases such as during the 2010s, since 2010, and in August 2020. Wording can usually be modified to remove the "now" perspective: not she is the current director but she became director on 1 January 2024; not 2010–present or since 2010 but beginning in 2010 or since 2010. Terms likely to go out of date include best known for, holds the record for, etc. For current and future events, use phrases such as as of November 2024 or since the beginning of 2024 to signal the time-dependence of the information; use the template {{as of}} (or {{updated}}) in conjunction.

(See the back and forth recent edits to MOS:RELTIME for background.)--Trystan (talk) 15:20, 13 July 2024 (UTC)

I don't think this is necessary or advisable. Since by itself doesn't imply anything about the current state. She has been the director of X since 2010 implies that she still holds that position, but because of the tense, not because of the since. Since 2010 she was the director of X, but she resigned in 2022 after a controversial tweet is perfectly possible too. Since by itself is no more likely to go out of date than in, during, or until. Gawaon (talk) 15:54, 13 July 2024 (UTC)

That sentence reads strangely to me. I might say Roosevelt was president from 1933 until his death or Roosevelt had been president since 1933 if speaking about a particular point in time during his presidency, but never Roosevelt was president since 1933 until his death. Is this something that varies between dialects?--Trystan (talk) 17:28, 13 July 2024 (UTC)

Possibly. The Cambridge Dictionary defines since as: "from a particular time in the past until a later time, or until now". I wouldn't use since ... until either, but the example I gave feels natural enough to me. Let's see what others think. Gawaon (talk) 18:14, 13 July 2024 (UTC)

There are far too many unproblematic usages of this phrasing to deprecate.

• "France had colonial possessions, since the beginning of the 17th century"
• "Since the passage of [the Parliament Acts of 1911 and 1949], the House of Commons of the United Kingdom has become the dominant branch of Parliament"
• Austria "inhabited since at least the Paleolithic period"
• "'to the City', the appellation Greek speakers used since the 11th century to colloquially refer to" Istanbul
• Association football "continued to be played by women since the time of the first recorded women's games in the late 19th century"
• Mathematics "until the 16th and 17th centuries, when algebra and infinitesimal calculus were introduced as new fields. Since then..."
• Boats "have been used since prehistoric times"

Beside that, in my experience, discouragement of time-dependent phrasing often merely causes the recentism of an article to remain present but buried in circumlocutions, making it harder to find and keep up to date. It is the recentism, not the specific wordings used to express time relations, that we should prefer to avoid. —David Eppstein (talk) 18:48, 13 July 2024 (UTC)

I do agree with Trystan that "since .. until" reads strangely, and I wouldn't use it. Gawaon, Cambridge's "until a later time" surprises me (but Cambridge sometimes does); it's not supported by examples or shared by Merriam-Webster or Chambers online, or the old print OED, or Collins in print or online, and for your example I'd automatically avoid since and prefer e.g. "Beginning in 2010" or "From 2010 she was .. but resigned". David, those are all good examples but of matters that will remain so indefinitely, rather than something we can reasonably expect to end soon if it hasn't already e.g. "since 1980, the finance manager has been ...". Still, I take your point about recentism and that deprecating "since" wouldn't achieve much. On the other hand, might it not be better to stop recommending it as MOS:SINCE does now? NebY (talk) 19:46, 13 July 2024 (UTC)

Yeah, I admit there's a fairly strong "until now" tendency in since I hadn't sufficiently appreciated above. As for no longer recommending it, I'm sceptical since I'd say that it still has the very clear advantage of precision compared to words like currently and recently which that section is chiefly (and reasonably) advises against. And ultimately, articles that make some kind of statements about the present are more useful than those that don't, even if the risk of going out of date is the price they pay. Since 2019 she has been the director [and we believe she still is] may become outdated, but it's more helpful than In 2019 she became the director, which leaves the reader in the dark about what might or might not have happened since. Plus the first wording can easily be updated to something like From 2019 to 2023 she was the director if somebody realizes it's no longer true, while the other wording is somewhat less easy to update. Anyway, I think both wordings are fine in general and it's not the place of the MOS to discourage one in favour of the other. Gawaon (talk) 20:18, 13 July 2024 (UTC)

A vast number of articles about people, places and organisations, start Name is.... Eventually, all of these will be outdated. I don't know how this is squared with MOS:NOW, but I don't think that changing these would make articles better. I certainly agree that it is more useful to say she is the director than she became the director leaving readers to wonder then what? So while since does imply a statement that will become outdated, I don't think that avoiding it would make articles better. Mgp28 (talk) 10:01, 15 July 2024 (UTC)

...might it not be better to stop recommending it... I would agree with just taking out the two recommended examples above, without adding in the cautions against using it. Some form of updating to recognize that it does have a strong "until now" implication that places it in the class of phrases that may need to be checked for currency (unless very long timeframes are involved).

I wonder if the "until a later time" captures uses like "He had been president since 1981", where both points of time are in the past.--Trystan (talk) 22:15, 13 July 2024 (UTC)

One specific unproblematic class of usage is when writing about longer periods: in the lead of Chinese characters I've written that Following the Han, [i.e. late antiquity] regular script emerged as the result of cursive influence on clerical script, and has been the primary style used for characters since. I don't feel like I can omit the hypothetical future datedness of this statement without explicating a slightly bizarre-feeling 21st century somewhere. Remsense诉 19:52, 13 July 2024 (UTC)

There is specific guidance endorsing relative expressions for long time periods. I'm not necessarily opposed to their use for shorter periods where it is warranted, just think the guideline shouldn't suggest that "since 2010" is immune to going out of date.--Trystan (talk) 22:25, 13 July 2024 (UTC)

Notes

"[Binary prefixes] are generally not to be used"... What? Why?

The section on units for bits and bytes states:

• The IEC prefixes kibi- (symbol Ki), mebi- (Mi), gibi- (Gi), etc., are generally not to be used except:
  • when the majority of cited sources on the article topic use IEC prefixes;
  • in a direct quote using the IEC prefixes;
  • when explicitly discussing the IEC prefixes; or
  • in articles in which both types of prefix are used with neither clearly primary, or in which converting all quantities to one or the other type would be misleading or lose necessary precision, or declaring the actual meaning of a unit on each use would be impractical.

And the rationale behind this is:

...consensus on Wikipedia in computing-related contexts favours the retention of the more familiar but ambiguous units KB, MB, GB, TB, PB, EB, etc. over use of unambiguous IEC binary prefixes. For detailed discussion, see WT:Manual of Style (dates and numbers)/Archive/Complete rewrite of Units of Measurements (June 2008).

I find this ridiculous. Binary units never had any justification for decimal prefixes. Why are we using outdated terminology? Continued usage of the outdated "decimal prefixes with binary meaning" means that the already bad ambiguity is continuously perpetuated, and simply adds to the confusion. While many people will say "it's unambiguous but let's not use it because people aren't familiar with it", it's exactly these people who are preventing others from becoming familiar with them.

A rule I firmly live by and tell others is analogous to Hanlon's razor, and that is: "Never assume unnecessary complexity when lack of familiarity will suffice."

Thank you. DASL51984 ^{(Speak to me!)} 14:04, 15 July 2024 (UTC) DASL51984 ^{(Speak to me!)} 14:04, 15 July 2024 (UTC)

Unhide "Binary prefixes" the little "Archives" box at the top of this very page, and you'll see that this topic has its own little series of 17 (count 'em -- seventeen!) pages of archived discussion on this. If, after reviewing those, you feel you have new arguments to offer that might change the consensus, by all means let us know. EEng 14:39, 15 July 2024 (UTC)

Yes, I've read through them. It was painful beyond recognition from the get-go, and by the end, I felt like I had lost all my brain cells.

Not only that, those discussions were all made back between 2005 and 2010, and the binary prefixes weren't well-known back then. Now, however, they are much more widely known, especially with MacOS and Linux having changed over a decade ago so that they display base-10 units but with base-10 meaning. (When will Windows catch up with reality??) DASL51984 ^{(Speak to me!)} 15:03, 15 July 2024 (UTC)

I fear that archive collection only includes discussions up to 2010. Some more recent ones can be found by searching for "binary prefix".[62] NebY (talk) 15:07, 15 July 2024 (UTC)

Totally agree with you. However I think you'll have difficulty shifting the consensus whilst the big desktop players such as Microsoft continue to use decimal prefixes. It always amuses me that some of the editors who are most determined to implement SI proceed to baulk at following the advice given by BIPM: "The International Bureau of Weights and Measures (BIPM), which maintains the International System of Units (SI), expressly prohibits the use of SI prefixes to denote binary multiples, and recommends the use of the IEC prefixes as an alternative since units of information are not included in the SI". Martin of Sheffield (talk) 14:55, 15 July 2024 (UTC)

You might want to read this case against deprecation of IEC prefixes. Dondervogel 2 (talk) 15:12, 15 July 2024 (UTC)

That was an excellent read. Thanks so much for bringing it up! DASL51984 ^{(Speak to me!)} 16:51, 15 July 2024 (UTC)

My own opinion, for what it is worth, is that the present wording of COMPUNITS reads like a Luddite's handbook, and is used by editor's to justify introducing ambiguity into articles where clarity and precision is needed. Dondervogel 2 (talk) 18:10, 15 July 2024 (UTC)

Your impressions on Locke Cole's point of view? DASL51984 ^{(Speak to me!)} 11:00, 16 July 2024 (UTC)

And the contra essay for your consideration: IEC units are bad. —Locke Cole • t • c 04:53, 16 July 2024 (UTC)

Much of your "essay" is spent regurgitating the exact same rotten excuses that myself and so many other people are absolutely sick and tired of hearing. Over the years, I've heard both perspectives countless times and tried my best to understand both perspectives equally, but none of the arguments I've seen from those against IEC units make any sense at all. DASL51984 ^{(Speak to me!)} 10:49, 16 July 2024 (UTC)

The arguments given in favor of these prefixes seem to fall into two categories: First, "they're better"; second, "they're accepted by standards bodies". Both of these arguments are irrelevant. What matters is whether they're used in the wild. Wikipedia follows; it doesn't lead. --Trovatore (talk) 23:41, 15 July 2024 (UTC)

Why do you think those are the only 2 arguments? Sources choosing to disambiguate use IEC prefixes. Those preferring ambiguity do not. Wikipedia has parked itself firmly in the camp preferring ambiguity. Is that really what you want? Dondervogel 2 (talk) 00:12, 16 July 2024 (UTC)

That's a "they're better" argument, and is irrelevant. --Trovatore (talk) 00:56, 16 July 2024 (UTC)

Nonsense. I made no claims about why the source disambiguate in this way, only pointed out the fact that they do. That is clearly about usage. Dondervogel 2 (talk) 10:45, 16 July 2024 (UTC)

Non sequitur. It's the usage you think is better, which makes it a "they're better" argument -- and irrelevant. --Trovatore (talk) 18:59, 16 July 2024 (UTC)

FYI: Repeating an incorrect statement does not make it any less invalid. DASL51984 ^{(Speak to me!)} 19:45, 16 July 2024 (UTC)

That is certainly true, but I made no incorrect statement, nor did Dondervogel identify one. --Trovatore (talk) 21:07, 16 July 2024 (UTC)

You certainly did make a completely nonsensical statement, and at this point all you have is "it's irrelevant" with no substantiation. And, when you were confronted about it, you merely repeated it as if it helped your case at all (spoiler: it actually weakened it severely). DASL51984 ^{(Speak to me!)} 21:23, 16 July 2024 (UTC)

Your statement that I was making a "they're better" argument is objectively incorrect. I was making a statement about usage and you know it. Dondervogel 2 (talk) 22:57, 16 July 2024 (UTC)

Not following. Yes, it's about usage, specifically the usage you think is better, because it's less ambiguous. I don't know what's subtle about this. That's a "they're better" argument, and I can't make any sense out of your denial of that obvious fact. --Trovatore (talk) 01:13, 17 July 2024 (UTC)

Wikipedia has parked itself firmly in the camp preferring ambiguity. No, Wikipedia has "parked itself firmly" in the camp that follows what the reliable sources used on our project use more often than not. When the day comes that that changes, Wikipedia will change along with it. But we're a long ways away from that day. —Locke Cole • t • c 00:22, 16 July 2024 (UTC)

If certain particular ways of doing things are erroneous and can be proven to be objectively incorrect, they remain incorrect, even if everyone does things in an incorrect way. Therefore, by "park[ing] itself firmly inthe camp that follows what the[...] sources used on our project use more often than not", as a side effect Wikipedia will inadvertently park itself in the camp that causes unnecessary confusion if those "reliable sources" follow outdated or incorrect conventions.

Basically, the entire argument propagated by gatekeepers like you can be boiled down to "we know this way of doing things is confusing, but let's do things that way anyways even though we know it's wrong." Do you seriously not realise how nonsensical this is? DASL51984 ^{(Speak to me!)} 02:44, 16 July 2024 (UTC)

Wikipedia takes the world as it is, not as we'd like it to be. SI wants to change computing units. 90+% of the world has decided to ignore that "standard" in favor of what has existed for decades. WP:DUE, WP:VNT and WP:BUTITSTRUE may help you understand this better.

In the end, your issue isn't with Wikipedia. Your issue is with Microsoft, Apple, The New York Times, CNN, and practically every other major software/hardware vendor and media outlet in existence. If you want to change the world, go make a nicely formatted letter and mail it to each of them. I wish you the best of luck, genuinely. —Locke Cole • t • c 04:46, 16 July 2024 (UTC)

• 90+% of the world has decided to ignore that "standard" in favor of what has existed for decades.

The way I see it, the real reasons are: (1) There are still a lot of old heads who won't admit that they were wrong and want to justify their laziness, (2) people think they sound funny (I think they sound weird too, but I accept that this helps reduce confusion), and (3) the IEC's patch for this bug was only rolled out fairly recently.

I think that, rather than being ignored, a lot of websites simply don't know about the binary prefixes, so they don't realise that the units are wrong. But trying to gatekeep information with this "it's better, but no one is familiar with it, so let's not do it" only adds to the problem. So my issue is actually with both sides. DASL51984 ^{(Speak to me!)} 10:34, 16 July 2024 (UTC)

No, your issue is with the entities I listed for you. Wikipedia reacts to our sources, we don't guide our sources to what is "correct". And to continue my WP:NPA recommendation below, calling people "old heads" who are "lazy" is a form of personal attack. Calling editors who disagree with you "gatekeepers" is likewise an attack. I've held my tongue with this so far, but if you're here to change minds, calling people names is a sure fire way not to accomplish that. —Locke Cole • t • c 04:00, 17 July 2024 (UTC)

(paraphrasing) "If things are incorrect, they're incorrect even if everyone does them that way." I actually agree with that. But the issue here is that's not Wikipedia's call. Wikipedia doesn't decide what's correct. That would be too much power; Wikipedia doesn't want it. You have to go convince the wider world. Then Wikipedia will change. --Trovatore (talk) 07:13, 16 July 2024 (UTC)

@Trovatore: Applying your reasoning, Wikipedia would use kbps (or Kbps? who knows), but MOSNUM prescribes kbit/s. The reason MOSNUM prefers kbit/s, Mbit/s, etc is to remove the ambiguity associated with kbps, Kbps, Mbps, mbps, MBps and countless other permutations used by the computer industry. Dondervogel 2 (talk) 07:29, 16 July 2024 (UTC)

Haven't looked into that one. Maybe that decision was wrong. --Trovatore (talk) 19:00, 16 July 2024 (UTC)

If that decision was wrong it should be re-opened. And while we're at it we should clearly revert to "kt" for knot and "nm" for nautical mile. Dondervogel 2 (talk) 19:15, 16 July 2024 (UTC)

Very possibly. Not under discussion at the moment. --Trovatore (talk) 21:09, 16 July 2024 (UTC)

Do you really think that using "Mbps" (which is more common than Mbit/s for the same reason that MB is more common than MiB) would make Wikipedia a better encyclopaedia? Dondervogel 2 (talk) 23:03, 16 July 2024 (UTC)

The best encyclopedia uses the terminology most familiar to our readers. That typically means the terminology widely used in our sources. Using neologisms does nothing but confuse our readers and is a disservice to the experience we want to present. —Locke Cole • t • c 23:06, 16 July 2024 (UTC)

Yup. This is very much still in the realm of "what do our reliable sources use"? And the answer, as ever, is predominantly the classic units. When major news articles use these units with regularity and they're used in more sources overall will be when Wikipedia can finally transition, not before. —Locke Cole • t • c 00:20, 16 July 2024 (UTC)

Yes, "MiB" is more accurate than "MB" when the latter means 1,024² bytes, but the question is what the majority of reliable sources use. As Trovatore says, Wikipedia doesn't decide what's correct in such matters, annoying though the inaccurate use is to many of us. Peter coxhead (talk) 13:29, 16 July 2024 (UTC)

My day job is as an embedded programmer. As such, I spend a lot of time reading datasheets for individual chips. Overwhelmingly, these datasheets use 32 KB to represent 32×1024 bytes and 1 MB to represent 1024×1024 bytes while still using 20 MHz to represent 20×1000×1000 Hertz. And this is not just like 60:40% majority, it's like 95:5% majority. For chip datasheets (as used by the industry itself) the IEC prefixes are almost completely unused.

It was mentioned that the IEC prefixes were relatively new. In this fast paced industry, 1999 is practically ancient times. In 25 years the industry responded to them with "meh".

The IEC prefixes have exact 2.4% error in them. In most cases this is negligible. Do you really care if you have 34,359,738,368 bytes of flash storage or 32,000,000,000 ? Be aware that you probably don't know how much overhead the file system uses , so you might only have approx 28,000,000,000 bytes available to you, the user. Or maybe less. Or maybe more. 2.4% is neither here nor there for most people.

Then compare it to Mbits/s vs Mbps. One is 8 times the other (1 byte = 8 bits). That is a significant difference to almost everybody. Practically anybody can tell if something is 8 times faster/slower. And it is so, so easy to mix up the 2.

There are very few rules in WP that are absolute. Instead, we give a certain amount of weight to each, stack the opposing arguments against each other and then see which side dominates. Sometimes it will be which has the least confusion and sometimes it will be which has the most use in sources. For Mbits/s and Mbps, both are well attested in use but Mbps has a very high probability for confusion - so we go for clarity. For MiB vs MB, there is a low rate of usage in the sources for MiB but meagre consequences of confusion, so we favour MB.

For what it's worth, I'm OCD and vastly prefer unambiguous statements (which is an asset in my job). But even I recognise that the industry simply did not embrace IEC prefixes.  Stepho  talk  23:55, 16 July 2024 (UTC)

While 1 KiB is only 2.4% larger than 1 KB, this discrepancy is not insignificant, and quickly grows (you most likely already know this by now, but still). 1 MiB is 4.9% bigger than 1 MB, 1 GiB is 7.4% larger than 1 GB, and 1 TiB is 10% larger than 1 TB.

For so long, storage was expensive and had limited capacities, so back in the day the 2.4% really wasn't that big of a difference. But today, there are many old heads that still do things wrong and many legacy systems that are still in use which display incorrect units, so the adoption has been slow. However, the sooner people start fixing the problem instead of grasping at straws and coming up with excuses, like you are doing here, the better. DASL51984 ^{(Speak to me!)} 00:41, 17 July 2024 (UTC)

Oops, my mistake. That should have been 2.4% per K. So G would be 2.4 cubed, which is about 14%. Not quite insignificant but in today's era of cheap memory, not a big problem either (you mentioned yourself that back in the day storage was expensive, implying that today's is cheap).

"grasping at straws" ??? "excuses" ??? I gave reasoned points, showed how we weighed up the pros and cons and did not get involved in name calling. In response, you insult anybody with a different view, put your hands over your ears and went "la-la-la-la-la...".  Stepho  talk  01:23, 17 July 2024 (UTC)

I'm totally on your side, but you need a math refresher. 1G (or Gi, depending on your political tastes) is (1.024)^3 ~= 1.074. It's got nothing to do with cubing 2.4, or whatever you were trying to say. EEng 04:54, 17 July 2024 (UTC)

Egad - I'm on a roll but its downhill :( As pointed out, it should have been 1.024 cubed, not 2.4 cubed, to make approx 1.074 -> 7.4%. So much for my maths degree ...  Stepho  talk  05:08, 17 July 2024 (UTC)

Every argument I've seen defending the erroneous "KB = 1024" is always an appeal to tradition, some other logical fallacy, or has more invalid points than "valid" ones.

I called out what you said as excuses because that's pretty much exactly what they were and your attempt at presenting arguments in favour of not using binary prefixes was anything but "reasoned". For example, your first paragraph about "no one uses them" is an appeal to popularity, since the use of decimal prefixes with binary meaning is objectively incorrect and inconsistent even if everyone does things that way.

And finally, calling out an improper use of units and calling out people who refuse to acknowledge that a wrong use of units is indeed wrong is not "insulting anyone with a different view". I don't know where you got that from. DASL51984 ^{(Speak to me!)} 01:36, 17 July 2024 (UTC)

Try reading WP:NPA and seriously consider your next words carefully. —Locke Cole • t • c 02:03, 17 July 2024 (UTC)

How does this fall under NPA? DASL51984 ^{(Speak to me!)} 02:27, 17 July 2024 (UTC)

DASL51984: Your argument is mostly based around WP:RIGHTGREATWRONGS. As already pointed out, WP is not the place to right great wrongs but follows what the majority of sources say. The majority of sources said "meh" about IEC prefixes.

You said that we are just following tradition. Nope, we are following what the real world uses. If the world changes then we will follow. The world hasn't changed yet. Ask again in 5 years.

Re NPA: "the entire argument propagated by gatekeepers like you" and "the sooner people start fixing the problem instead of grasping at straws and coming up with excuses, like you are doing here, the better". Calling those of the opposite view as gatekeepers and grasping at straws could be considered as a (mild) personal attack. Or at least an ad hominem attack. We prefer that you address the issues rather than (mild) name calling.

We have presented our view as using the same units used in the real world and that the argument of righting great wrongs does not hold water here. These 2 principles are deeply ingrained in WP. Your arguments fly in the face of these 2 principles. You must either find new arguments or be prepared to overturn these 2 principles.  Stepho  talk  02:34, 17 July 2024 (UTC)

Thank you for (finally) not being unreasonable.

I didn't mean to insult anyone, but I code and work with computer software and hardware on a regular basis, and things like this matter a lot to me. The whole 1000 vs. 1024 war was silly to me when I first got interested in coding and computing back in grade school, and it's still silly to this day. DASL51984 ^{(Speak to me!)} 02:53, 17 July 2024 (UTC)

Mbps is an abbreviation for "megabit per second", the unit symbol for which is Mbit/s. There is no factor of 8. Are you confusing it with MBps? Dondervogel 2 (talk) 13:32, 18 July 2024 (UTC)

Sorry, I didn't say it properly. I meant that Mbits/s is very clear but Mbps could easily be confused with MBps, which is what I meant by an 8 times confusion.  Stepho  talk  20:40, 18 July 2024 (UTC)

Stepho, when you said earlier that you're on a roll, was it this kind of roll ?EEng 21:35, 18 July 2024 (UTC)

Certainly feels like it sometimes.  Stepho  talk  23:06, 18 July 2024 (UTC)

Ah yes, that makes sense. You seem to be acknowledging that Wikipedia's use of Mbit/s is justified because it is a less confusing symbol than the abbreviation used by the popular press and much of the computer industry (Mbps). Correct? Dondervogel 2 (talk) 05:12, 19 July 2024 (UTC)

Not quite. Mbits/s and Mbps are both well attested in the real world (I spend a lot of time programming communication protocols) but WP uses Mbits/s because MBps and Mbps are easily confused and the consequences are huge.

Whereas MiB is not used much in the real world and the consequences of confusing MiB with MB is small.  Stepho  talk  00:22, 20 July 2024 (UTC)

Yes, I understand the nuance, but I did not phrase my question carefully enough, so let me explain better. Others on this page are arguing that the inherent value of a unit symbol is irrelevant, and that the ONLY thing that matters is how often that unit symbol is used. Your position differs from that by acknowledging that the value of the unit symbol (in this case its value in disambiguating the factor 8) is also a consideration, in addition to usage. I sense no dogmatic principle in your reasoning that ONLY the frequency of usage matters, and I find that helpful. That was my point. Dondervogel 2 (talk) 06:17, 20 July 2024 (UTC)

Yes, I try to take a balanced viewed instead of looking only at a single point to the exclusion of all else - a distinctly unpopular view ;)  Stepho  talk  09:15, 20 July 2024 (UTC)

Without wishing to put words in your mouth (please correct me if I take this too far), I imagine you apply a similar reasoning to the choice of nmi for nautical mile (avoiding confusion with the nanometre) and kt for knot (avoiding confusion with the kilotonne). Just as well no one ever uses the dB or MB ;-) Dondervogel 2 (talk) 09:27, 20 July 2024 (UTC)

No, that would be taking my point too far. KiloTon and knot are unlikely to be mistaken due to context - weight vs speed. Nautical mile and nanometre are both distances but the difference is so big that wrong usage would also be obvious.  Stepho  talk  23:56, 21 July 2024 (UTC)

Notes

Two questions

1. Why fractions and mixed units are generally not used with metric units? I have seen some uses of fractions with metric units in articles such as Shoe size, but never seen any usage of mixed units.
2. Do articles that have strong ties to both US and Canada use metric or imperial units first? I think that it would be stupid to use imperial units first in articles with strong ties to Canada. --40bus (talk) 15:22, 22 July 2024 (UTC)

   For your second question, I typically use {{Convert}}, and place the unit used in the majority of sources first, i.e., if a source says six miles, I add {{Convert|6|mi}}, yeilding "6 miles (9.7 km)". If a source says ten km, I add {{Convert|10|km|mi}}, yielding "10 kilometres (6.2 mi)". The order in which the output is displayed can be manipulated by the "order=flip" parameter, i.e., {{Convert|6|mi|order=flip}} yields "9.7 kilometres (6 mi)". I don't really care whether "imperial" or "metric" displays first, as long as the unit used in the source is placed in the first parameter in the template to avoid rounding errors. Donald Albury 18:36, 22 July 2024 (UTC)

   You might not care but the Wikipedia Manual of style does. People can pick cherry pick sources, it's what the authorities in that country want that counts. The EU requires that power in all car owner manuals be in kW since about 1980, this includes the UK. The MOS states in Units of measure: SI primary outside the USA and UK. Plenty of people in the US use metric, Space X, Tesla, the auto industry, John Deere, etc. etc. yet congress in the USA does not mandate SI, it's optional. There are lots of other examples. See what the law states [[63]] Avi8tor (talk) 19:51, 23 July 2024 (UTC)

People frequently do calculations with measurements, and usually perform the calculations with calculators and computers. These devices are much easier to use with decimal fractions rather than mixed numerals. Jc3s5h (talk) 16:35, 22 July 2024 (UTC)