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

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 155

←

Archive 160

Archive 161

Archive 162

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:

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:

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

I suspect that those examples really ought to be 21⁄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 21⁄2 (and for 391⁄2 while we're at it), but I've never seen 91⁄10 years or 84⁄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". (21⁄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 "391⁄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 "391⁄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

There is an extremely clear consensus in favour of Option D. No changes are made to Wikipedia:Manual of Style/Dates and numbers. NotReallySoroka (talk) 09:48, 31 December 2022 (UTC)

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

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?

Option A: Currency names and symbols should not be changed unless there is consensus to the contrary.
Option B: Currency names and symbols should not be changed unless there is consensus or reliable sources to the contrary.
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.
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. E Eng 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. E Eng 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

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. E Eng 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. E Eng 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 Talk:Pound sterling/Archive 2 § Notes (=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. E Eng 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. --Jayron 32 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]? E Eng 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. --Jayron 32 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"? E Eng 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.

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.
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.
When recording an age or similar you use cardinal numbers to record the number of complete years: "He was 21 last birthday".
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.
Volume, flow	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? E Eng 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. E Eng 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)? E Eng 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. E Eng 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. E Eng 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. E Eng 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.) E Eng 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). E Eng 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]. E Eng 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. E Eng 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). E Eng 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. E Eng 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. E Eng 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. E Eng 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. E Eng 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?

E Eng 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. E Eng 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. E Eng 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.^[1]

References

^ "percent, percentage, percentage points". AP Stylebook. Associated Press.

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. E Eng 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. E Eng 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. E Eng 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). E Eng 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. Giant Snowman 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... Giant Snowman 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? Giant Snowman 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. E Eng 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. Giant Snowman 08:58, 22 July 2023 (UTC)
Humor impairment strikes again. E Eng 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? E Eng 09:07, 22 July 2023 (UTC)
All of it. Giant Snowman 09:10, 22 July 2023 (UTC)
Then we're back to humor impairment strikes again. E Eng 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? E Eng 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:

Nanker Phelge (fl. 1651 – 1658) was...
Nanker Phelge (before 1651 – after 1658) was...
Nanker Phelge c. 1651 – c. 1658 was... [using {{circa}}]
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 112, 10.875 as 1078 𝕁𝕄𝔽 (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. E Eng 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. E Eng 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.) E Eng 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. E Eng 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%. E Eng 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 RMB 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. E Eng 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)

"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

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.^[a]
- 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)^[b]
- 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. ^[c]

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

^ Whether 00A3 is displayed with one or two bars is typeface (font) dependent.
^ The same methodology should be applied to the Irish, South African, Australian, and New Zealand pounds; £123 Irish, £123 South African, £123 Australian, £123 New Zealand, unless the context is specific to that country, in which case a simple pound sign may be used.
^ Whether 00A3 is displayed with one or two bars is typeface (font) dependent.

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°30′N 0°00′E / 51.5°N 0°E; 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. E Eng 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. E Eng 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.wikipedia.org/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 × 122.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."^[1]

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,^[1], ISO,^[2] NIST,^[3] IUPAC,^[4] the American Medical Association's widely followed AMA Manual of Style,^[5] among others.

^ ^a ^b Bureau international des poids et mesures, "Non-SI units that are accepted for use with the SI", in: Le Système international d'unités (SI) / The International System of Units (SI), 9th ed. (Sèvres: 2019), ISBN 9789282222720
^ "ISO House Style". International Standards Organisation. Retrieved 27 August 2023.
^ Thompson, Ambler; Taylor, Barry N. (March 2008). Guide for the Use of the International System of Units (SI) (PDF) (Report). National Institute of Standards and Technology. §10.5.3. Retrieved 21 January 2022.
^ Guidelines for drafting IUPAC technical reports and recommendations (Report). 2007. Retrieved 27 November 2008.
^ Iverson, Cheryl; et al. (2007). AMA Manual of Style (10th ed.). Oxford, UK: Oxford University Press. p. 793. ISBN 978-0-19-517633-9.

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

Not going to happen. They can put me in BIPM-ISO-NIST jail if they want. E Eng 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. E Eng 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. E Eng 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. E Eng 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. E Eng 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". E Eng 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. E Eng 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. E Eng 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×10⁷ 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 . 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)×10²³ 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,^[1] 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

^ Le Système international d’unités [The International System of Units] (PDF) (in French and English) (9th ed.), International Bureau of Weights and Measures, 2019, pp. 127, 128, 131, 132, ISBN 978-92-822-2272-0

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. E Eng 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. E Eng 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 ^[1], 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.wikipedia.org/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.wikipedia.org/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.wikipedia.org/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^{[note 1]}

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.wikipedia.org/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 = m a

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

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.wikipedia.org/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.wikipedia.org/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:^[2]^[3]

\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).^[4]^: 20–21 Although torque (N·m) and energy (J) are dimensionally equivalent, torques are never expressed in units of energy.^[4]^: 23

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.wikipedia.org/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.wikipedia.org/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

^ Magnetic colatitude is 0 along the dipole's axis and 90° in the plane perpendicular to its axis.

References

^ Le Système international d’unités [The International System of Units] (PDF) (in French and English) (9th ed.), International Bureau of Weights and Measures, 2019, ISBN 978-92-822-2272-0
^ "Magnetic units". IEEE Magnetics. Retrieved 19 February 2016.
^ Mohr, Peter J.; Newell, David B.; Taylor, Barry N. (21 July 2015). "CODATA Recommended Values of the Fundamental Physical Constants: 2014". Reviews of Modern Physics. 88 (3): 035009. arXiv:1507.07956. Bibcode:2016RvMP...88c5009M. doi:10.1103/RevModPhys.88.035009. S2CID 1115862.
^ ^a ^b Le Système international d’unités [The International System of Units] (PDF) (in French and English) (9th ed.), International Bureau of Weights and Measures, 2019, ISBN 978-92-822-2272-0

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? E Eng 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.wikipedia.org/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.wikipedia.org/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. E Eng 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. E Eng 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. E Eng 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.) E Eng 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? E Eng 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:

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

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 April 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 April 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:

The first, about one-digit numbers, is duplicated in §Ordinals; you already noted this
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
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:

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.
"spelled straightforwardly" and "cumbersome" are unclear. The examples suggest the existing "one or two words" rule applies.
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. Giant Snowman 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]. E Eng 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 11⁄2 years" isn't ownership. E Eng 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. E Eng 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 "xx1⁄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)

"51⁄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. E Eng 18:03, 24 February 2024 (UTC)

My search was faulty. I missed 107 cases of "xx1⁄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)

[1] "percent, percentage, percentage points". AP Stylebook. Associated Press.

[2] Whether 00A3 is displayed with one or two bars is typeface (font) dependent.

[3] The same methodology should be applied to the Irish, South African, Australian, and New Zealand pounds; £123 Irish, £123 South African, £123 Australian, £123 New Zealand, unless the context is specific to that country, in which case a simple pound sign may be used.

[4] Whether 00A3 is displayed with one or two bars is typeface (font) dependent.

[SIBrochure-5] Bureau international des poids et mesures, "Non-SI units that are accepted for use with the SI", in: Le Système international d'unités (SI) / The International System of Units (SI), 9th ed. (Sèvres: 2019), ISBN 9789282222720

[6] "ISO House Style". International Standards Organisation. Retrieved 27 August 2023.

[7] Thompson, Ambler; Taylor, Barry N. (March 2008). Guide for the Use of the International System of Units (SI) (PDF) (Report). National Institute of Standards and Technology. §10.5.3. Retrieved 21 January 2022.

[8] Guidelines for drafting IUPAC technical reports and recommendations (Report). 2007. Retrieved 27 November 2008.

[9] Iverson, Cheryl; et al. (2007). AMA Manual of Style (10th ed.). Oxford, UK: Oxford University Press. p. 793. ISBN 978-0-19-517633-9.

[10] Le Système international d’unités [The International System of Units] (PDF) (in French and English) (9th ed.), International Bureau of Weights and Measures, 2019, pp. 127, 128, 131, 132, ISBN 978-92-822-2272-0

[12] Magnetic colatitude is 0 along the dipole's axis and 90° in the plane perpendicular to its axis.

[11] Le Système international d’unités [The International System of Units] (PDF) (in French and English) (9th ed.), International Bureau of Weights and Measures, 2019, ISBN 978-92-822-2272-0

[IEEEM-13] "Magnetic units". IEEE Magnetics. Retrieved 19 February 2016.

[14] Mohr, Peter J.; Newell, David B.; Taylor, Barry N. (21 July 2015). "CODATA Recommended Values of the Fundamental Physical Constants: 2014". Reviews of Modern Physics. 88 (3): 035009. arXiv:1507.07956. Bibcode:2016RvMP...88c5009M. doi:10.1103/RevModPhys.88.035009. S2CID 1115862.

[SI2019-15] Le Système international d’unités [The International System of Units] (PDF) (in French and English) (9th ed.), International Bureau of Weights and Measures, 2019, ISBN 978-92-822-2272-0

[1]

[a]

[b]

[c]

[1]

[2]

[3]

[4]

[5]

[1]

[1]

[note 1]

[2]

[3]

[4]