Wikipedia talk:Manual of Style/Dates and numbers/Archive 162
![]() | This is an archive of past discussions on Wikipedia talk:Manual of Style/Dates and numbers. 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 | Archive 163 |
Decimals when quoting time periods?
There is a debate here about whether it's acceptable to use decimals when discussing a timeframe in a person's life, e.g. "he was a prisoner for 39.5 years". Personally I think this the sort of thing you'd expect to see in a science article, not a person's biography. However, the MOS here doesn't seem to cover this circumstance. Thoughts? Muzilon (talk) 09:01, 13 January 2023 (UTC)
- To include the voices from that article's talk page: Dondervogel 2 (talk · contribs) and I agree that decimalized years in prose are a "normal practice in English" (the specific charge by Muzilon). I originally wrote the body to say
He was instead held prisoner in North Korea for 39.51 years
; Dondervogel 2 and I concur that rounding that to the tenth is better. — Fourthords | =Λ= | 14:41, 14 January 2023 (UTC)- You have not included all
the voices from that article's talk page
. To repeat (with a slight addition thus), expressing a period of time in a person's life in decimal years, and to the nearest 0.01 years at that, is not normal practice in English. The source's phrasing is common practice when wishing to add emphasis and drama, and the tone of that paragraph (and the entire report) is dramatic:For 39 years, six months and four days, he was trapped in a bizarre Stalinist state — hungry, suffering, told by the government how to live, what to read, and even when to have sex. Never before has an American lived among the secretive North Koreans so long and escaped to tell the tale.
We don't use such a tone in our encyclopedia, nor do we use phrasing which would be natural in speech ("thirty-nine and a half a years"), nor do we treat a period of someone's life as a measurement (unlike "completed in 39.51 seconds"). Instead, and especially in a brief summary such as a Wikipedia:LEAD as well as in the body of the article, "over 39 years" and "nearly 40 years" are both good English and both communicate quite enough to the reader without tripping them up. NebY (talk) 15:01, 14 January 2023 (UTC)- I am so sorry! In my quick look, I thought only myself, Muzilon, and Dondervogel 2 were participating. Hell, I even assumed Muzilon—in their zeal— was the original editor who'd changed the text: IACOBVS (talk · contribs). I promise that was unintentional. In the moment, I absolutely thought there were only three voices.
expressing a period of time in a person's life in decimal years, and to the nearest 0.01 years at that, is not normal practice in English.
As for that, I can't help but assume that you are the authority for "normal English", and that others' contradictory experiences are invalid.'over 39 years' and 'nearly 40 years' are both good English and both communicate quite enough to the reader without tripping them up.
Using the phrase "over 39 years" includes both 40 and 400 years, and suggests that the specific amount of time is actually unknown. Whose interpretation of "nearly 40 years" equals "six months less than"; could it be interpreted by readers to mean 38 years or 43 years (and again it suggests that the specific amount of time is actually unknown)? Also, I don't understand how one "trips up" a reader with specific decimalized years in prose; can you elaborate on that (is it related to MOS:ACCESS)? — Fourthords | =Λ= | 15:29, 14 January 2023 (UTC)I absolutely thought there were only three voices
? Really. Yesterday you replied to me, sayingMy 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)
- 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 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.
- You have not included all
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 to39 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:
- Children aged up to 2.5 years are assessed for healthy weight and nutrition during universal visits
- police officer Thomas Lane sentenced to 2.5 years in prison
- scam mastermind sentenced to 3.5 years
- Alexei Navalny sentenced to 3.5 years in prison
- Held by Somali Pirates for 4.5 years
- Rodrigo Rato gets 4.5 years for embezzlement
- it takes on average 6.5 years for men to receive a diagnosis and 8.8 years for women
- How many more do you need? Dondervogel 2 (talk) 21:44, 15 January 2023 (UTC)
- I suspect that those examples really ought to be 2+1⁄2 ({{frac|2|1|2}}) years and are only written as "2.5" to avoid using "2½". Martin of Sheffield (talk) 21:52, 15 January 2023 (UTC)
- That works for 2+1⁄2 (and for 39+1⁄2 while we're at it), but I've never seen 9+1⁄10 years or 8+4⁄5 years. That would be weird. Dondervogel 2 (talk) 21:58, 15 January 2023 (UTC)
- Exactly. All except the last examples above are "... and a half". It would also be sensible for "... and a quarter". (2+1⁄4 for example.) Anything else should normally be expressed in with months/weeks/days and reserve the decimals only for mathematical and statistical use. Martin of Sheffield (talk) 22:14, 15 January 2023 (UTC)
- @Martin of Sheffield: All of the examples are "... and a half" ... except for the ones that are not (9.1 years, 8.8 years). How would you write those? Dondervogel 2 (talk) 23:02, 16 January 2023 (UTC)
- Oops, yes I did miss the 8.8 years, I just saw the 6.5 years for men (the 9.1 wasn't on your list though). Your last example is noticably different from the preceding six. They are all fixed preriods of time whereas the seventh is the result of a statistical calculation. You might note the phrase "and reserve the decimals only for mathematical and statistical use" above. Martin of Sheffield (talk) 09:31, 17 January 2023 (UTC)
- In that case I think you and I agree. In the original context I have no objection to replacing "39.51 years" with "39+1⁄2 years". (The 9.1 years was from a previous link to a BBC article, also about statistics). Dondervogel 2 (talk) 11:38, 17 January 2023 (UTC)
- 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)
- @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)
- Exactly. All except the last examples above are "... and a half". It would also be sensible for "... and a quarter". (2+1⁄4 for example.) Anything else should normally be expressed in with months/weeks/days and reserve the decimals only for mathematical and statistical use. Martin of Sheffield (talk) 22:14, 15 January 2023 (UTC)
- That works for 2+1⁄2 (and for 39+1⁄2 while we're at it), but I've never seen 9+1⁄10 years or 8+4⁄5 years. That would be weird. Dondervogel 2 (talk) 21:58, 15 January 2023 (UTC)
- 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)
- I suspect that those examples really ought to be 2+1⁄2 ({{frac|2|1|2}}) years and are only written as "2.5" to avoid using "2½". Martin of Sheffield (talk) 21:52, 15 January 2023 (UTC)
- I don't see why the continuity matters. Still, it was just one example. It's not hard to find more:
- Just my native speaker of American English intuition (who just happens to have a PhD in Linguistics), but I find "39+1⁄2 years", "more than 39 years", and "almost 40 years" much more natural in the given context than "39.5 years". Even "39 years and 6 months" is better than "39.5 years", although I like it less than the first three choices. - Donald Albury 14:40, 16 January 2023 (UTC)
Count me as another who thinks expressing years in decimals is a strange and unnatural sounding practice for anything outside of a statistical analysis or other similar mathematical or scientific use. It's just not how people discuss years because years aren't divided in to easy decimal divisions. They're divided into 12 months, not 10. And while "and a half" and "and a quarter" are used because 12 divides into halves and quarters easily, that has a certain informality in writing that may not be appropriate for an encyclopedia. Plus there's fact that it's over-precise to attempt to express that period as a decimal. Frankly, there's zero reason anyone would unless they have a poor grasp of the language. oknazevad (talk) 18:20, 16 January 2023 (UTC)
There're a lot of claims here as to what's normal, common practice, unencyclopedic, professional, tripping, the average reader's understanding, sensible, and intiutive. However, as we're all editors of the English Wikipedia: do we have any reliable sources? A lot of our MOS rules have been derived from preexisting standards; should we not cite similar when writing (or arguing about) new MOS guidance regarding decimalized years in biographies? (For what it's worth, I don't have a preference—except to lean towards precision when we have it; I disputed being told my experiences, exposure, and use of the English language are abnormal and not to be duplicated, especially in the absense of an MOS consensus.) — Fourthords | =Λ= | 22:40, 16 January 2023 (UTC)
- As the editor who first used "39.51 years"[2] and reinstated it,[3] can you cite a pre-existing standard supporting such usage? NebY (talk) 13:33, 17 January 2023 (UTC)
- I don't understand the question. Are you asking if I have that for which I, myself, am asking? If so, I don't: that's why I asked. — Fourthords | =Λ= | 13:59, 17 January 2023 (UTC)
- The consensus thus far seems to be that decimalized years - especially with two decimal places - are not standard in biographical prose and should be limited to a statistical/mathematical context. Can you, as a minority voice, produce something from the Chicago Manual of Style (or similar) to refute the majority position? Muzilon (talk) 04:00, 18 January 2023 (UTC)
- I agree with this as the consensus position, but I wouldn't want it as a policy I think. Johnbod (talk) 05:02, 18 January 2023 (UTC)
- Yes, so far there's been no convincing evidence that this needs to be settled by the MoS. If the folks tracking the Jenkins bio can work it out among themselves, that would be great; otherwise they should try dispute resolution. If the issue starts to come up repeatedly in multiple articles, then it might be worth discussing what to do in the MoS. --Trovatore (talk) 05:44, 18 January 2023 (UTC)
- Yes, and if it comes up again in one or two other articles, reference to this discussion might help resolve matters without needing to add a section to the MoS. NebY (talk) 14:50, 18 January 2023 (UTC)
- That's where it was being discussed, where I asked about a recent edit. I'm not sure why Muzilon (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) moved it here; I just followed them. — Fourthords | =Λ= | 15:13, 18 January 2023 (UTC)
- 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)
- 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)
- 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 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)
- 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 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)
RfC on changes to currency names
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Do you favour the addition of the following text at Wikipedia:Manual of Style/Dates and numbers#Currencies and monetary values, under the "Currency names" section?
- 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. EEng 14:40, 23 December 2022 (UTC)
- Option D. Where is the link to prior discussion? Why would new text be necessary? Where would it be placed? Why would we need to say that this sort of text, specifically, should not be changed without consensus or reliable sources? Why does this section have a generic header name? – Jonesey95 (talk) 14:58, 23 December 2022 (UTC)
- @Jonesey95: I propose adding "this sort of text" on currency nomenclature because TCG has done mass changes to them. NotReallySoroka (talk) 21:52, 23 December 2022 (UTC)
- Thank you for the response. It is not a good idea to add to a guideline because of a single editor's misunderstanding or malfeasance. I suggest that you withdraw this RFC, now that you have gotten a sense of how it will end. Doing so will avoid wasting the time of editors at this page. – Jonesey95 (talk) 22:59, 23 December 2022 (UTC)
- @Jonesey95: But then editors' time is also wasted on en masse changes of currency spellings and notations sans consensus. I shouldn't have to start a single discussion on currency names and notations; conversely, TCG should have started a few RfC and RMs before they made their mass edits.
- It is what it is, though; I will snow close this RfC very soon in favour of D. Thank you for your participation in this RfC. NotReallySoroka (talk) 09:47, 31 December 2022 (UTC)
- 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: 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)
- D per EEng, and because Wikipedia policy and guidelines are already quite sufficient, and because no evidence has been presented that our use of currency names and symbols is in an exalted state of grace, and because this seems to be a totally superfluous attempt to shut down the work of an editor who has already been indefinitely blocked and rage-quit, and in amazement that this sudden RFC follows the proposer's creation of a "law" in project space Wikipedia:NotReallySoroka's Law, and per Jonesey95. NebY (talk) 15:08, 23 December 2022 (UTC)
- Completely agree, though in fairness it should be said that TCG wasted a lot of editor time pushing his intransigent ideas about currency names and so on, so I can understand the OP's desire to dampen such activity. But see, as always, WP:MOSBLOAT. EEng 15:45, 23 December 2022 (UTC)
- Indeed, even when they had consensus they ... well anyway, yes, WP:MOSBLOAT. NebY (talk) 16:38, 23 December 2022 (UTC)
- @NebY: But then WP:TenPoundHammer's Law and WP:Shirt58's Law also exist, although they aren't subject to RfCs. I don't intend for my "law" to be more powerful than TPH's or Shirt's law barring consensus to the contrary. NotReallySoroka (talk) 21:50, 23 December 2022 (UTC)
- Completely agree, though in fairness it should be said that TCG wasted a lot of editor time pushing his intransigent ideas about currency names and so on, so I can understand the OP's desire to dampen such activity. But see, as always, WP:MOSBLOAT. EEng 15:45, 23 December 2022 (UTC)
- 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)
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)
- 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)
- 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)
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)
- 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)
- 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)
- Not my experience in the United States. — Moops ⋠T⋡ 17:44, 21 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)
- 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)
- 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)
- 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))
- 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)
- Please, God, not this shit again. EEng 05:15, 8 February 2023 (UTC)
- Perhaps we could add it to Wikipedia:Perennial proposals Hawkeye7 (discuss) 00:09, 9 February 2023 (UTC)
- Yes please. Tony (talk) 12:01, 8 February 2023 (UTC)
- Thanks Tony. I'd love to see this happen. Even if it takes a long time. :) — Moops ⋠T⋡ 18:30, 12 February 2023 (UTC)
- If no one has a proposal which stands a chance of being approved (and I'm sure no one does), let's not waste time and energy on this. SchreiberBike | ⌨ 23:25, 8 February 2023 (UTC)
Clarifying exceptions
In the section Numbers as figures or words, we have:
- Integers from zero to nine are spelled out in words.
- Integers greater than nine expressible in one or two words may be expressed either in numerals or in words...
The exception to this is listed farther down, in the middle of "Notes and exceptions":
- Comparable values nearby one another should be all spelled out or all in figures, even if one of the numbers would normally be written differently...
Can this be moved up closer to the main text? This exception is too far down the page, and it's being missed by editors who haven't read the long exceptions section carefully enough. Thanks. BilCat (talk) 19:20, 23 March 2023 (UTC)
- Juggled some stuff. EEng 05:14, 27 March 2023 (UTC)
- Thanks. BilCat (talk) 16:30, 28 March 2023 (UTC)
Petition to have dates start with the month, followed by the day
This discussion has been closed. Please do not modify it. |
---|
This is not happening and there's no point in wasting more of our time discussing why it won't happen. —David Eppstein (talk) 23:39, 2 March 2023 (UTC) |
It has come to my attention that some don’t agree with having a month before the day (I.e. March 1, 2023) and would rather have it like this (1 March, 2023). Personally I think that is ridiculous, and we normally would have it the other way around. Is there any way to start a petition here on the wiki to allow these kinds of changes. Marino13 (talk) 18:56, 2 March 2023 (UTC)
|
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)
- 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)
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:£.
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:
"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£".
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)
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)
|
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)
- 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
- 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)
- The "first diff" in question here could have limited itself to only adding
- 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)
- What cases are you talking about? I'm a bit confused. Wracking 💬 21:42, 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 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)
- If the article has
- 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
- 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
- When the book or website being cited has a date on it, should this not be the format used for
|date=
? OK, I'll accept a conversion from Roman numerals to Arabic, but otherwise it should be copied as is. Access and archive dates on the other hand are subject to the Access and archive dates section of MOS, quoted above. Martin of Sheffield (talk) 07:37, 4 April 2023 (UTC)- I'm sorry, but that's silly. A date is information, not a form of expression (as text is), and while we are unavoidably forced to choose a date format for any particular article, the whole reason for doing so is so that the information in the article's various dates will be presented in a way that's as unobtrusive as possible, and that means not varying the format willy-nilly. EEng 13:37, 4 April 2023 (UTC)
Crore
MOS:CRORE currently provides this advice (emphasis added):
- Provide a conversion to Western numbers for the first instance of each quantity (the templates
{{lakh}}
and{{crore}}
may be used for this purpose), and provide conversions for subsequent instances if they do not overwhelm the content of the article. For example, write three crore (thirty million). When converting a currency amount, use the exchange rate that applied at the time being written about; the{{INRConvert}}
template can be used for this purpose.
But WP:ICTF#Films says that there is consensus that {{INRConvert}}
should not be used in list-type articles or in infoboxes (at least for Indian film-related articles).
Monetary conversion templates such as INRConvert should not generally be used in list type articles or infoboxes per this consensus and this discussion. The prevailing attitude was: 1) Converting to US dollars is arbitrary. 2) Default conversion templates create problems with inflation, Ex: where the gross from a 2008 film is converted to the present year's US$ rate. 3) The inflation adjustment option in the template results in infobox clutter.
I had started using {{INRConvert}}
in Indian film articles based on MOS:CRORE. It wasn't until later that I saw WP:ICTF#Films and realized what I was doing was counterproductive.
So, I wonder we should add something to the current writeup at MOS:CRORE to acknowledge or note this "consensus" about avoiding {{INRConvert}}
in list-type articles and infoboxes? — Archer1234 (t·c) 16:01, 30 March 2023 (UTC)
- Strictly speaking, the provisions at MOS:CRORE override the WikiProject consensus, per WP:CONLEVEL. It might be possible to alleviate the infobox clutter concern (number 3) by footnoting the conversion, and the problems with inflation concern (number 2) is already addressed by MOS:CRORE where it says
use the exchange rate that applied at the time being written about
. - That just leaves concern number 1, which MOS:CURRENCY leaves open to lower-level consensus:
in non-country-specific articles, such as Wealth, use US dollars (US$123 on first use, generally $123 thereafter), euros (€123), or pounds sterling (£123)
. XAM2175 (T) 01:41, 31 March 2023 (UTC) - One of the main concerns I have about using INRConvert in the infobox is the clutter, but not just in the infobox. The conversion would be in the infobox and in the article lead, toward the bottom, which generally is quite close to where the conversion in the infobox will be. That feels like content overload for the reader. Keeping a fairly clean infobox presents relevant information to the reader, with easy access to the conversion in the lead mitigates that without giving an undue burden. Ravensfire (talk) 03:06, 7 April 2023 (UTC)
- Don't use crore in those circumstances; MOS:CRORE and MOS:COMMONALITY both discourage it, and it makes the article less accessible. BilledMammal (talk) 05:10, 7 April 2023 (UTC)
MOS:DATED proposal "a recent study"
I think MOS:DATED (and perhaps also MOS:RELTIME) should include a note about adjectives such as recent in phrases such as a recent study, which I see all the time. Case in point: I changed A recent synthesis gives to A synthesis by Harper (2017) gave. MOS:DATED is focused on adverbs such as recently and currently, but also has present, upcoming and ongoing that could be used both adverbially and adjectively, and already features the adjective example she is the current director. I think we should add a sentence about replacing a phrase like a recent study with example solutions such as a 2017 study or a study by Foo (2017).
I think we should also add an extra alternative to the example of she is the current director, namely one with the formulation has been (or plural have been), which is already commonly applied, e.g. she has been director since 1 January 2023. This is to cover ongoing situations that have a known starting date, but an unknown ending date, which may or may not have already passed. Terms and tenures of certain offices or positions such as director are typical examples of that. They may not have set end-dates (e.g. directors of companies or organisations which they (co-)founded themselves can often remain director indefinitely until they pass the position to someone else at some point at their pleasure), and even positions with fixed terms may be extended (due to re-election or reappointment for another term) or cut short (due to resignation, removal from office, death, or otherwise).
Situations in which a sportsperson or tallest building or whatever is the current (world) record holder are similar: it is uncertain how long they will remain the current record holder. Apart from formulations such as She set a world record in fooing in 2023 or Foo is the tallest building in Fooland as of 2023, a has/have been formulation can be useful, especially in articles that are not frequently updated. So the formulation has/have been is a good solution to indicating when a tenure began without necessarily saying it is still ongoing (or has already ended) whenever that is unknown, or whenever it can in fact be known from reliable sources, but hasn't been updated yet. (Once it is known, it can always been changed to had been, if that makes narrative and grammatical sense). Cheers, Nederlandse Leeuw (talk) 10:08, 4 April 2023 (UTC)
- You're quite right about "recent" and I would even avoid she has been director since 1 January 2023, preferring she became director on 1 January 2023 (was appointed, was promoted to, ...). Some editors may be happy using {{As of}} eg {{as of|2023|01|01|lc=on}} as of 1 January 2023[update] or even {{as of|2023|01|01|lc=on|since=y}} since 1 January 2023[update], but even that's less durable. NebY (talk) 18:19, 4 April 2023 (UTC)
- I agree. Nederlandse Leeuw (talk) 11:51, 5 April 2023 (UTC)
- Like the above, I prefer simple past to any perfect tenses, as things like the present perfect still imply conditions which may or may not be true any longer. "She became such and such" is much better than "She has been such and such since" because that still implies we have knowledge of the present condition, which the article may not. --Jayron32 13:25, 5 April 2023 (UTC)
- I very much agree with NebY and Jayron32. Whenever I see "since" or "has been", I think to myself "as of when?" or "until what date?", and sometimes even check the refs (if any, hah) when I'm in pure reader mode, to see (guesstimate) how out of date the statement might be. — JohnFromPinckney (talk / edits) 14:25, 6 April 2023 (UTC)
- I agree. Nederlandse Leeuw (talk) 11:51, 5 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)
Over at List of fatal crowd crushes, the format of the article is confusing regarding the year 2000. Events from 2000 are included in the sub-heading "The 2000s", which is under the heading "The 21st century". This pretty clearly goes against MOS:CENTURY, which proscribes that the year 2000 belongs to the 20th century.
We could try using only one system in the article, but neither result seems satisfactory. If we removed "2000s/2010s/etc", we end up with awkward 10-year groupings like "2001-2010" and "2011-2020", which are completely unnatural. We could remove "17th/18th/etc century", and instead write "1600-1699" and the like, but that seems esoteric, and also a bit unnatural... Is there an elegant solution here I'm not seeing? Are all or most list articles like this? PhotogenicScientist (talk) 22:00, 18 April 2023 (UTC)
- PhotogenicScientist, this is a good question. what if, under the table for "20th century", an entry was placed at the bottom that stated "for the year 2000, see § 2000s"? better yet, the entries for the year 2000 could be moved to the table for "20th century" instead, and an entry at the top of the table for "2000s" could state "for the year 2000, see § 20th century", because the year 2000 is in the 20th century and not the 21st century. to avoid sorting issues, code like the following could be used.
colspan="6" align="center" data-sort-value="" | ''for the year 2000, see {{section link||20th century}}''
- different lists seem to have tackled the issue differently. the list of floods mentions a flood in the year 2000 under the 19th (!) century heading, does not have a 20th century heading, and completely ignores the 2000 flood under the 2000s heading. (it also mentions a 1900 flood under the 19th century heading, and an 1800 flood under the 18th century heading.) the list of building or structure fires mentions all the relevant fires of 2000 under the 2000s heading and completely ignores them under the 20th century heading, but it also mentions all the relevant fires of 1900 under the 20th century heading.by the way, i think you mean "prescribes" rather than "proscribes". they are pretty much antonyms, but people often confuse the two, so the mistake is understandable. dying (talk) 23:30, 18 April 2023 (UTC)
- Wow, that floods article is ridiculous lol. I made what quick corrections I could there.
- Thanks for bringing up those two examples - they give me some ideas. Personally, I think it makes sense to include years ending in '00 in the century with the years after it. That's how we celebrate, after all - January 1 2000 marked the start of the 21st century, and the new millennium, to pretty much the whole world. And that just makes sense - the number in the hundreds place changes, so it feels like a new century. But apparently, this is some grand academic debate, spawning because there was no year 0 AD, and so the "first century" or first group of 100 years was necessarily 1-100 AD...
- Anyways, I suppose that means I'd be in favor of amending MOS:CENTURY, as above. (also, thank you - I'll stop using proscribes wrongly :))PhotogenicScientist (talk) 13:39, 19 April 2023 (UTC)
- No it didn't. The year 2000 was the last year of the 20C, the 21C started on 1 January 2001. It's not really "some grand academic debate"; count your fingers: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. You don't say you have two-and-a-fifth hands now, do you? For years, the first decade was 1-10, the first century 1-100 (otherwise it wouldn't be a century) and take it from there. Martin of Sheffield (talk) 13:52, 19 April 2023 (UTC)
That's how we celebrate, after all - January 1 2000 marked the start of the 21st century, and the new millennium, to pretty much the whole world. And that just makes sense - the hundreds number changes, so it feels like a new century.
So, did you just miss this part? Or did you purposefully ignore it? Because I feel I demonstrated that I can count in 10s and 100s by acknowledging the source of the issue.- I don't know if you were alive at the time, but pretty much everyone everywhere on Jan 1 2000 was celebrating the turn of the millennium (and the century). PhotogenicScientist (talk) 14:04, 19 April 2023 (UTC)
- Not only alive at the time, but I'd been warning about and mitigating against, Y2K at work since the 1980. New Year is a nice excuse for a booze-up whatever the numbers, and I joined in the Y2K celebrations, but never referred to it as the start of the new millennium. That's simply mathematically and logically wrong. there really isn't any need for discussion, you can use whatever personal definitions of a millenium you want, but it is correctly a period of 1,000 years, not 999. Martin of Sheffield (talk) 14:17, 19 April 2023 (UTC)
That's simply mathematically and logically wrong
. Correct. But is it Wikipedia's calling to be "exactly, logically correct" or "approachably, familiarly correct," in cases like these where there is conflict, perhaps outright contradiction, between the two?- You can say that you yourself never referred to 2000 as the start of the new millennium, but I imagine you're in scant company there. I imagine there are others, like you and me, who have different opinions on how the year 2000 should be treated. Which is why I disagree that
there really isn't any need for discussion.
PhotogenicScientist (talk) 14:26, 19 April 2023 (UTC)- I suggest changing the heading 19th century to 1800-1899, 21st century to 2000–present, etc. That being disposed of, I have a question, PhotogenicScientist: are you by chance scientist/supermodel Symmetra [6]? EEng 15:10, 19 April 2023 (UTC)
- I appreciate the input. That being said, no, that person is not me - but I did have a sensible chuckle at that mailing. PhotogenicScientist (talk) 15:49, 19 April 2023 (UTC)
- (edit conflict) I doubt that we're ever going to agree, but in response to your (possibly rhetorical) question: 'is it Wikipedia's calling to be "exactly, logically correct" or "approachable, familiarly correct,"' then I would say the former. There are plenty of cuddly social sites where accuracy is secondary, but Wikipedia strives to be an encyclopaedia where precision and truth are fundamental. All IMHO of course. EEng who has just edit conflicted with me, has the correct answer. Martin of Sheffield (talk) 15:14, 19 April 2023 (UTC)
- That's quite alright - my intention isn't to convince people to agree with me. Only to start a discussion and see where the opinions of others lie.
- A minor quibble, though, with
Wikipedia strives to be an encyclopaedia where precision and truth are fundamental
: Wikipedia is a compendium of that which is verifiable in reliable sources, and not necessarily of that which is true. If there's a preponderance of reliable sources asserting something to be true, then Wikipedia follows. This may at times be at odds with what could be considered the "absolute truth" of a matter. - As that pertains here, "the public at large" might not be considered a reliable source to base our content on. But what about basing our practices/formatting? The public at large is our primary customer - the reason WP exists is to share knowledge with them. If our formatting could change to improve the transfer of knowledge to readers, that would be a benefit worth considering. PhotogenicScientist (talk) 15:59, 19 April 2023 (UTC)
- I suggest changing the heading 19th century to 1800-1899, 21st century to 2000–present, etc. That being disposed of, I have a question, PhotogenicScientist: are you by chance scientist/supermodel Symmetra [6]? EEng 15:10, 19 April 2023 (UTC)
- 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)
- 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)
The problem that no one wants to address is that "the 1900s" way of naming a century and "the 20th century" way of naming a century do not have the same years. If we call our centuries "the 1800s" or "the 1900s" we're delineating our centuries based on the left-most two digits of the number. If we're calling it "The 20th century", we're delineating it based on counting from "year 1", where "years 1-100" were "the first century". You'll note that this means that "the 1900s" is close to, but not identical to "the 20th century". Notably, this means that the year "2000" is in "the 2000s century" AND in the "21st century". If you categorization scheme doesn't take this into account, you're going to need to make adjustments. In this case, it may be best to just remove all mentions of the "Ordinal" century and use "1900s" and "2000s" and don't use the terms "20th century" or "19th century", because it's actually impossible to mix the systems and be accurate. --Jayron32 15:31, 19 April 2023 (UTC)
- I went source-hunting, and have collected those that seemed the most reputable and reliable. In short, it seems the mathematicians and pedants have an iron grip on the press - reliable sources, by and large, strictly adhere to notion that year 2000 belongs to "the 20th century."
- Library of Congress
- Contains my favorite quote, which very succinctly sums up my thoughts: "When does the century end? This simple question has such a simple answer that the very existence of a dispute is puzzling... Yet many find the truth of the matter so unacceptable that the resulting controversy has generated a considerable literature."
- USN Astronomy department
- Scientific American
- LA Times article from 1988
- timeanddate.com
- Library of Congress
- I find myself leaning toward using "Xth century" nomenclature less, due to its inherent incompatibility with decade nomenclature...
- Should we amend WP:CENTURY to recommend that preference in writing? PhotogenicScientist (talk) 20:59, 19 April 2023 (UTC)
- How many years are there in a century? When, in your opinion, did the first century CE begin and end? Are the answers compatible? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:52, 20 April 2023 (UTC)
- What's "CE"? EEng 14:35, 20 April 2023 (UTC)
- @Chatul: 100. The CE/AD system has no Year Zero, so the first century ran from 1 CE to 100 CE. The first decade ran from 1 to 10, the second from 11 to 20 and the 20s ran from 20 to 29. Of course the answers aren't compatible. --𝕁𝕄𝔽 (talk) 15:22, 20 April 2023 (UTC)
- The CE nomenclature is intended to match the year numbers of the AD nomenclature while reducing the religious friction with the term "Anno Domini". The AD system was invented by Christians before the Orthodox Christians and the Protestants split away from the Roman Catholic Christians, so it belongs to all Christians, with the possible exception of denominations that split away before 525 CE, when the AD system was invented. Since these Christians do not have a mechanism to resolve differences today, there is no answer. Jc3s5h (talk) 16:00, 20 April 2023 (UTC)
- 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)
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)
- See Ordinal numeral Martin of Sheffield (talk) 20:25, 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)
- 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)
- 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)
- PL/I? PL/I is perfectly capable of doing 0-based indexing.
- 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)
- ordinal number is real in Fortran. Hawkeye7 (discuss) 00:22, 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)
- "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)
- 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)
- 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)
- 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)
- ITYM empty set. --Trovatore (talk) 20:26, 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)
- 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
|
|
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. |
|
ml or mL | Derivative units of the litre may use l (lowercase "el") as guided by WP:ENGVAR. |
The "don't use lowercase ell in isolation" and as guided by ENGVAR
bits both originate with this edit [7], which came on the heels of WT:Manual of Style/Dates and numbers/Archive 160#Litre abbreviation RFC. However, I don't see where the closer (who hasn't edited in a year) got the ENGVAR part -- nor do I know what it means.
I believe we should just drop the text as guided by ENGVAR
. Thoughts? EEng 05:44, 27 March 2023 (UTC)
- Agreed - drop. Stepho talk 05:53, 27 March 2023 (UTC)
- Long ago in the mists of time the US National Institute of Standards and Technology had officially recommended that people in the US should use L rather than l as the symbol for liter. According to the most recent version of Special Publication 811, page 8, Table 6, footnote b, the General Conference on Weights and Measures (CGPM) has adopted L as an alternative symbol for the liter to avoid confusion with the digit 1. So I would say it used to be an ENGVAR issue, because the guidance to use L came from the US, but now that the main international organization, CGPM, endorses L, it is no longer an ENGVAR issue.I could go further and suggest that the English Wikipedia adopt L as the preferred symbol. Jc3s5h (talk) 16:04, 27 March 2023 (UTC)
- That's already what the first row of the table (above) says -- for the symbol standing alone i.e. without (for example) an m for milli. The question is the second row: what forms should be used for milliliter: ml or mL or it-depends-on-ENGVAR? AFAICS the outcome of the RfC I linked didn't support an ENGVAR angle -- I don't see where the closer got that -- so we should drop the text
as guided by ENGVAR
. If you want L to be used in all cases -- L and mL -- you'll need a new RfC, but please in the name of Jesus do not do that, at least not now. For now I'd really like to just get this odd bit of text dropped. EEng 17:17, 27 March 2023 (UTC)
- 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
- I also see no relevance of WP:ENGVAR. The closing 4 words (if engvar counts as a word) add nothing. Dondervogel 2 (talk) 17:50, 27 March 2023 (UTC)
- Go straight to "L". Drop the ENGVAR bit. — JohnFromPinckney (talk / edits) 18:42, 27 March 2023 (UTC)
- The Australian style manual says that either is acceptable but the capital L is preferred to avoid confusion. So I support dropping the ENGVAR bit. Hawkeye7 (discuss) 19:33, 27 March 2023 (UTC)
Now that I've had my coffee, I realize that (I think) we have (A) a solution that then leads to (B) a new problem. The solution (A) is to change
Derivative units of the litre may use l (lowercase "el") as guided by WP:ENGVAR.
to
Derivative units of the litre may use l or L (lowercase or uppercase "el"), with in-article consistency.
Are we all together on this?
But then here's the other problem: (B) Is "milliliters per liter" ml/L? or ml/l? -- or are both acceptable? (And now that I think about it, mL/L is a possibility too. But mL/l makes no sense at all, obviously.) I'm just previewing this (B) thing. Can we all agree on (A) above before we start debating (B)? EEng 02:09, 28 March 2023 (UTC)
- Let's just go for L everywhere (including derived units). Removes the complications altogether. Stepho talk 02:40, 28 March 2023 (UTC)
- Please, please, please, pretty please, let's just start by agreeing on (A). You can raise the idea of "L everywhere" later. EEng 03:38, 28 March 2023 (UTC)
- Yep - already agreed to (A) dropping mention of ENGVAR. Stepho talk 03:44, 28 March 2023 (UTC)
- Agreed. Support A. And "in-article consistency" rules out ml/L. Somebody please keep EEng away from the coffee before we get to "Y for Gaw'd sake" Hawkeye7 (discuss) 03:10, 28 March 2023 (UTC)
- Please, please, please, pretty please, let's just start by agreeing on (A). You can raise the idea of "L everywhere" later. EEng 03:38, 28 March 2023 (UTC)
- 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)
- You're swinging a very broad brush with
- 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)
- 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)
- 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)
- 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)
- 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 "
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Comment IRL
mastersmatters preclude substantive participation on this matter, though I delight in having managed to spark a lively debate. What I suggest y'all do is start by reviewing the RfC I l linked above, to decide (1) whether the close was faithful to the discussion, and (2) whether the edit made to the guideline was faithful to the close. After making any corrections there, THEN start debating new ideas like "let's all go to L". Just my thoughts. EEng 14:41, 28 March 2023 (UTC)- You're studying for a(nother) master's? But seriously, this is not a good way to challenge or overturn the close of an RFC. A recent close can be challenged by discussion with the closer or at WP:AN per Wikipedia:Closing discussions. Two years later? Launch a new RFC. NebY (talk) 16:55, 28 March 2023 (UTC)
- Before getting all formal, let's see if we can agree on what happened. To some extent the question is whether the close was flawed, but as much or more is the question of whether the edit reflected the close. I don't see at all where the ENGVAR text comes from. (But I've been run ragged recently so maybe I'm just not seeing it.) Fixing that wouldn't be challenging the close, just implementing it properly. EEng 17:12, 28 March 2023 (UTC)
- It's a good implementation that follows the reasoning of the close (which was good too) by applying the second of the three arguments against B analysed and assessed by the closer, the first having been rejected outright and the third being inapplicable given that there's no consensus re "ml". NebY (talk) 18:05, 28 March 2023 (UTC)
- Here's the actual text that you seem to be talking about in the close:
- As Option A is the status quo, this leaves Option B as the potential change to assess. The numerical vote is roughly 12-8 in favor of B (with two votes for option D and one vote for option C). The argument for B is primarily that it will avoid confusion with uppercase "I" and number "1". The arguments against B are threefold. The first is an argument against MoS guidances at all. The second is an ENGVAR argument. The third is that while "l" for litre should be discouraged, other abbreviations such as ml should be used. Regarding ENGVAR, capital L is not just an "Americanism", but is permissible everywhere and widely used outside of Europe; furthermore editors can still spell out litre in running text. As the third argument notes that lowercase "l" is confusing (as well as the voters for C and D), I find there is consensus to stop using a standalone "l" for litres.
- As I read this, the first two rationales are rejected, and only the third is partially affirmed. I don't see any support in the close for mentioning ENGVAR in the guidance. --Trovatore (talk) 23:28, 28 March 2023 (UTC)
- Right. That's my reading as well. Somewhere between making the close and doing the edit, the closer seems to have swept ENGVAR into the mix accidentally. I'm hoping we can all recognize that and get rid of the EMGVAR big, after which the floor is open for further refinement, and hopefully a final settlement of this accursed matter. (That further refinement might even include someone proposing that there should be an ENGVAR angle after all, but to repeat, that doesn't seem to have been any part of the outcome of the original RfC, so it's only fair to return to that base before opening the floor to new change proposals.) EEng 05:49, 29 March 2023 (UTC)
- Followup: My conjecture is that the closer was working on that row of the table, his eye fell on the left cell reading
millitre / milliliter (US)
, and the idea popped into head that there's an ENGVAR issue (which there's not, because that row is about unit symbols, not unit names). EEng 16:58, 29 March 2023 (UTC)
- Here's the actual text that you seem to be talking about in the close:
- 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)
- Before getting all formal, let's see if we can agree on what happened. To some extent the question is whether the close was flawed, but as much or more is the question of whether the edit reflected the close. I don't see at all where the ENGVAR text comes from. (But I've been run ragged recently so maybe I'm just not seeing it.) Fixing that wouldn't be challenging the close, just implementing it properly. EEng 17:12, 28 March 2023 (UTC)
- 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)
- 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 thatrigour
becomesrigorous
,valour
becomesvalorous
, 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 tomL
, is the symbol for the megalitre; 1 ML = 1,000,000 L (264,172 US gal). A rather significant difference! - (The discussion here would suggest that a British megalitre would have the symbol
Ml
, which I confess to my eyes looks exceptionally odd.) XAM2175 (T) 16:21, 29 March 2023 (UTC)- Wow, one slip of the shift key and suddenly ... [9]. EEng 16:55, 29 March 2023 (UTC)<>/del>
- Yes, it is a shame that merchants and customers don't pay attention to official definitions. Should I sue the distributor because the bottle of wine says 750 ML on the label, but only holds 750 ml? I wonder if I could find a court that would allow me to pursue that case. Donald Albury 18:11, 29 March 2023 (UTC)
- I once saw a pharmacist in the US label a prescription in "Mg" rather than "mg"... XAM2175 (T) 18:16, 29 March 2023 (UTC)
- @Donald Albury: Be sure to check the settlement is paid in MUSD, not mUSD. Dondervogel 2 (talk) 19:26, 3 April 2023 (UTC)
- For the avoidance of doubt here Donald,
- 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)
- As an aside, your gesture
- Coming a bit late to this, but FWIW my !vote is to support the proposal to drop the ENGVAR reference (I am not sure whether mathematical symbols can even be considered part of English, or any natural human language) as it seems pedantic and unnecessary. There's no reason we can't be consistent in recommending the use of "L", which (as pointed out above) is what most standards orgs do in any case. I don't recall seeing any authoritative body prescribing the use of "l" over "L", come to think of it. Moreover, it is not unreasonable to expect an editor coming to MOSNUM for advice on such usage to find it a bit confusing that they are instead referred to ENGVAR, which does not discuss anything related to units of measurement (nor should it). Archon 2488 (talk) 14:31, 3 April 2023 (UTC)
- For the record, I also support deprecation of the lower case "l". That would promote increased coherence within and between articles. I am not advocating a mass change from "ml" to "mL" in existing articles, but suggesting that a change in the other direction would be discouraged. Evolution, not revolution. Dondervogel 2 (talk) 21:57, 3 April 2023 (UTC)
- Given that IEC allows both, I would go with upper case, since it is easier to distinguish "L" from "1". --Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:49, 3 April 2023 (UTC)
- We're not talking about L vs l now. EEng 01:30, 4 April 2023 (UTC)
OK, just to count heads: Unless I'm missing something, only NebY objects to the proposal on the table -- which (to repeat) is to replace
Derivative units of the litre may use l (lowercase "el") as guided by WP:ENGVAR.
to
Derivative units of the litre may use l or L (lowercase or uppercase "el"), with in-article consistency.
NebY: before I unleash the mob to pummel you into submission, is there any possibility that Trovatore's response to you above (see #anchor) has convinced you to go along? And anyone who does object, but I missed, please speak up now (after considering, as mentioned, the above). EEng 01:30, 4 April 2023 (UTC)
- Needless violent language here, EEng. DePiep (talk) 08:27, 21 April 2023 (UTC)
- Needless comment born of your misreading of social cues three weeks after the fact, DePiep. EEng 12:37, 21 April 2023 (UTC)
- You wrote it. It's agressive. If you mean something else, write something else. -DePiep (talk) 15:20, 21 April 2023 (UTC)
- DePiep, you've been asked over and over to stop trying to referee the interactions of other editors, because you lack sufficient awareness of social cues to understand what's going on. I meant what I wrote, and I'm not going to use kindergarten baby-talk just because that's what you need in order to understand what everyone else readily gets. Really, just butt the fuck out of others' conversations -- see (among many examples) WP:Administrators'_noticeboard/IncidentArchive1018#EEng_agression. EEng 22:38, 25 April 2023 (UTC)
- @EEng: agressive and condescent language here, again. Usage not motivated, no opening for discussion. Civility is a pillar. "Request" denied. My question stands: EEng, please avoid agressive language. DePiep (talk) 04:50, 26 April 2023 (UTC)
- Too bad cluelessness and unintelligibility aren't pillars -- you'd be the undisputed God King Emperor of Wikipedia. EEng 10:49, 26 April 2023 (UTC)
- DePiep, if I may interject: EEng's post was colloquial in nature. It employs a form of jocular hyperbole frequent – and almost universally accepted – in casual English. It was not meant as a threat, and I cannot imagine anybody seriously interpreting it as a credible threat, or thinking that it is egregiously uncivil. If you, or any other person, do genuinely feel that this is offensive, you are welcome to report it at AN/I. Further discussion here will be completely unproductive. XAM2175 (T) 09:20, 26 April 2023 (UTC)
- Hang around DePiep a while and you'll find your powers of imagination greatly enhanced. My link above is just one of a dozen times he's been told -- at ANI! -- that he doesn't know what he's talking about. But like a bad penny he just keeps coming back. EEng 10:49, 26 April 2023 (UTC)
- @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)
- DePiep, you've been asked over and over to stop trying to referee the interactions of other editors, because you lack sufficient awareness of social cues to understand what's going on. I meant what I wrote, and I'm not going to use kindergarten baby-talk just because that's what you need in order to understand what everyone else readily gets. Really, just butt the fuck out of others' conversations -- see (among many examples) WP:Administrators'_noticeboard/IncidentArchive1018#EEng_agression. EEng 22:38, 25 April 2023 (UTC)
- You wrote it. It's agressive. If you mean something else, write something else. -DePiep (talk) 15:20, 21 April 2023 (UTC)
- Needless comment born of your misreading of social cues three weeks after the fact, DePiep. EEng 12:37, 21 April 2023 (UTC)
- Needless violent language here, EEng. DePiep (talk) 08:27, 21 April 2023 (UTC)
- I see Kahastok and MapReader both arguing that it's an ENGVAR matter, and arguments that Ireland or Australia use "L" don't detract from that; ENGVAR has never been about a binary choice between AmEng and all the rest, and it should surprise no-one that sometimes BrEng differs from AusEng or IrEng. EEng, when you opened this discussion it was in terms that you weren't trying to overthrow the close of an RFC that's only two years old, merely its implementation, as if the two were separate and the implementation was by someone who misunderstood the close. I at least failed at first to appreciate that the closing statement and the implementation were by the same respected and experienced editor at the same time. Far from one editor misunderstanding another, what we have is User:力 being thorough and performing a close in two parts, a statement and an implementation. Together they make the totality of the close. You don't like the close of an RFC and it's too late to question the closer or take it to WP:AN for review? Ask a question directly in another RFC. NebY (talk) 17:59, 4 April 2023 (UTC)
- I agree with this, both on the substantive point and the procedural point. Kahastok talk 19:04, 4 April 2023 (UTC)
- The Australian manual of style given above says that L is preferable but that both L and l are acceptable, so that takes Australian out of the ENGVAR argument.
- I didn't see an explicit Ireland reference above but I gave a UK (including Northern Ireland) reference that uses lots of lowercase examples but says both L and l are acceptable (technically it used the number 1 instead of lowercase el but that was probably a typo and not repeated in ml, etc). So the UK is also out of the ENGVAR argument. Stepho talk 22:22, 4 April 2023 (UTC)
- I reiterate my strong opposition to classifying unit symbols, or any other mathematical symbols, in any context, for any reason whatever, as part of any variety of English or any other natural language. To anyone who objects, please explain to me what variety of English, or any other natural language, the statement "eπi + 1 = 0" is written in.
- And for emphasis: I oppose any attempt to push any MOS-level advice on the appropriate use of unit symbols to any part of the MOS other than MOSNUM. I would also note that no RS deprecating the usage of the symbol "L" in UK/IE (or any other, AFAICS) contexts have been cited, and at present we have nothing but the POV of a couple of editors against its usage. Archon 2488 (talk) 21:55, 4 April 2023 (UTC)
- I apologize for overlooking Kahastok and MapReader. I'm really distracted IRL and not hitting on all cylinders:
- As already stated, it's not that I "don't like the close", just I think the closer may have had a brain fart between the close per se and the edit meant to implement it. Tell me again where in the close per se there's anything about recognizing an ENGVAR issue?
- EEng 04:05, 5 April 2023 (UTC)
- I boldly implemented EEng's suggestion. My reason? The argument that ENGVAR is remotely connected with the choice of symbol is patently absurd, per Archon 2488. The whole point of international standard unit symbols is that they are international standard symbols. It does not matter whether one is writing in Spanish, French, Italian or any other language using a Latin alphabet. Beyond the alphabet, language is irrelevant. Dondervogel 2 (talk) 13:40, 5 April 2023 (UTC)
- Not even confined to the Latin alphabet, actually! Archon 2488 (talk) 13:58, 5 April 2023 (UTC)
- 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)
- I agree with this, both on the substantive point and the procedural point. Kahastok talk 19:04, 4 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 12th, 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)
- No th, nd, or st. Tony (talk) 03:01, 23 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)
- 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)
- 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)
- 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)
- Oh, and for the record I don't like US mdy formatting either. But I follow the rules as best I can. Tony (talk) 07:46, 25 May 2023 (UTC)
- Seems to me that the only dates currently being used on the Seafarer 31 Mark II article are only in citations templates, not directly in the article prose or the infobox. Thus WP:CITESTYLE applies, and the YYYY-MM-DD format could be used instead for all those citations. I will concede that this would only be a temporary compromise until a DMY or MDY date is actually added to the article prose or the infobox. Zzyzx11 (talk) 12:12, 25 May 2023 (UTC)
- Well that really is the irony here in this rather long and involved debate, that all the actual dates in the article are contained in reference templates and so subject to the page's templated formatting. So for either outcome here it is really a matter of swapping two letters or not: {{Use dmy dates|date=May 2023}} or {{Use mdy dates|date=May 2023}}. That is it. - Ahunt (talk) 17:21, 25 May 2023 (UTC)
- However the date thing turns out, be sure to refer to boats as "she". See Wikipedia:Queen Elizabeth slipped majestically into the water. EEng 02:43, 31 May 2023 (UTC)
Line wrapping and units
Is there a sound reason why we require that "...a normal space is used between a number and a unit name"
and not a non-breaking space? To me, it looks wrong (doubly so where the figure is a single digit), and I strongly suspect it hinders readability. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:03, 10 April 2023 (UTC)
- It seems a bit odd, yes. It's also inconsistent with how the MOS treats constructions like "21 million", where MOS:NUMERAL holds that a non-breaking space should be used. XAM2175 (T) 12:38, 10 April 2023 (UTC)
- I find all linebreaks between a numeral and any following term ugly, jarring, and confusing but the discussionshave always gone against me.--User:Khajidha (talk) (contributions) 04:36, 12 May 2023 (UTC)
- For a decade I've been meaning to bring order out of the linebreak chaos, but it's a daunting task. EEng 06:11, 12 May 2023 (UTC)
Proposal: Allow use of %
for percentages in non-technical articles
MOS:PERCENT currently has the following to say:
- In the body of non-scientific/non-technical articles, percent (American English) or per cent (British English) are commonly used: 10 percent; ten percent; 4.5 per cent. Ranges are written ten to twelve per cent or ten to twelve percent, not ten–twelve per cent.
- In the body of scientific/technical articles, and in tables and infoboxes of any article, the symbol
%
(unspaced) is more common: 3%, not 3 % or three %. Ranges: 10–12%, not 10%–12% or 10 to 12%.
This seems a bit dated to me, as the percent symbol is ubiquitous these days and easily understood not just in technical spaces. Reflecting this, the AP Stylebook changed its advice in 2019 to start advising Use the % sign when paired with a number, with no space, in most cases
.[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:
- "Writing out" seems an odd wording to me. I think what is meant is "using words"
- I advocate that we explicitly state that "three %" is no good and that the % sign is only used with numbers.
- Is mixing forms okay? In particular, we have the case of avoiding starting a sentence with a number.
- The Australian Style Guide has more restrictions on their use [10] which could be considered
- 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)
- Re (2): three % is already in red, but only for scientific and technical articles. Hawkeye7 (discuss) 22:48, 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)
- I have no objection to "3%" being used for non-technical articles, but for technical articles, "3 %" should be preferred. International standards describing the International System of Quantities (ISO 80000) require a space between the numerical value ("3") and the unit symbol ("%") in technical writing. Dondervogel 2 (talk) 22:28, 14 May 2023 (UTC)
- Whether to have a space or not is something that varies between style guides, it seems, but it's been a longstanding convention on Wikipedia to not have the space. Changing it would require modifying a ton of articles; you could try proposing it separately (this proposal is just about percent/per cent vs. %), but I don't see a compelling case to switch that would justify the disruption. {{u|Sdkb}} talk 22:38, 14 May 2023 (UTC)
- ISO80000 can go to hell. Percents are unspaced, always. Headbomb {t · c · p · b} 22:40, 14 May 2023 (UTC)
- I think you meant to say 100% of the time. —Locke Cole • t • c 23:18, 14 May 2023 (UTC)
- ISO 8000:
The symbol of the unit shall be placed after the numerical value in the expression for a quantity, leaving a space between the numerical value and the unit symbol. It should be noted that this rule also applies to the units per cent, % and per mil, ‰.
[11] Hawkeye7 (discuss) 00:13, 15 May 2023 (UTC)- My attempt at humor failed. For what it's worth, I agree with the general proposal. —Locke Cole • t • c 00:31, 15 May 2023 (UTC)
- Better leave the humor to the professionals. EEng 02:44, 31 May 2023 (UTC)
- 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)
- ISO 8000:
- I think you meant to say 100% of the time. —Locke Cole • t • c 23:18, 14 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)
- ISO80000 can go to hell. Percents are unspaced, always. Headbomb {t · c · p · b} 22:40, 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)
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)
- FYO stylemanual.gov.au, Imperial College London, regards, Govvy (talk) 08:30, 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)
- 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)
- @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 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)
- 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)
- 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)
- 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)
- 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 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)
MOS:CENTURY-related discussion at VPP
Please see Wikipedia:Village pump (policy)#Without looking it up, what year and day were the ends of the 6th century BC? Firefangledfeathers (talk / contribs) 20:10, 24 July 2023 (UTC)
Semi-automated changes to YYYY-MM-DD in templates
Edits like this made with the MOSNUM dates script provide no benefit to the reader, as dates already render as intended. They do, however, make translating citations more difficult as I explain here. YYYY-MM-DD is allowed in citation templates per MOS:DATEUNIFY—there is no MOS reason to change this formatting, but because these changes are not explicitly prohibited, the script continues to be used in this way.
Relevant discussions I am aware of:
- In June 2019 an editor notified the script creator that date formatting in citation templates was no longer necessary, and advised that edits which solely make this change should not be completed.
- In March 2023, discussion was raised at the script's talk page. Editors deferred the conversation to this page.
- In April 2023, discussion was taken here (WT:DATE), but it fizzled out and ultimately no action was taken.
- In May 2023, I raised the issue again. There were well-intentioned, but convoluted, suggestions on how I could personally fix the issue.
I find this specific use case of the script incredibly frustrating and demotivating. With the script, this change takes a few seconds to perform and doesn't seem to provide any benefit, but causes extra work for others. I can individually reach out to the editors making these semi-automated edits (and I have), but I'm just one person. Maybe an RfC is the correct next step here? Thanks. Wracking talk! 19:45, 12 July 2023 (UTC)
- We need an end to this bullshit, which has been going on for years and years and years, to no purpose but causing much wasted editor time. The script is broken and should not be used. Either the script itself should be banned (WP:BAG?) or Giant Snowman, who seems unable to learn how to use it without causing regular disruption, should be banned from using it. Paging David Eppstein. EEng 22:16, 12 July 2023 (UTC)
- To add to "the script is broken": it does not know how to handle cs1-dates=ly format (that is, spelled-out publication dates and numerical access dates for references), which is one of the standard MOS-approved styles, and will break that format when applied to articles using that style. I have complained about this for years, with the typical response from the script writer being WONTFIX and the typical response from the script users being "that's just how the script works, I can't change it and I'm not going to stop using it". I'm too lazy to look for diffs for all that right now.
- Giant Snowman is only one of multiple editors doing this. For a long time I even thought Giant Snowman and The Rambling Man might be socks for the same editor because they were behaving the same way with respect to this script, but I encountered others later and now think that it's just the existence of the script that caused them to behave similarly.
- It's also mostly cosmetic, in the sense that it does not affect the readers at all: in any article using citation templates and properly tagged for its date style, the dates are reformatted by the templates and rearranging them beforehand is pointless. —David Eppstein (talk) 22:33, 12 July 2023 (UTC)
- As a minor procedural note, since this is users individually choosing to run a script on a page it does not fall within the purview of WP:BAG any more than use of twinkle does. 74.73.224.126 (talk) 01:07, 13 July 2023 (UTC)
- Whether it's BAG, ANI, or firing squad, I don't care. EEng 02:28, 13 July 2023 (UTC)
- I think the issue is about the script's task of changing YYYY-MM-DD to MDY or DMY in reference templates. The issue isn't that certain people are using the script in this way, but that the script is able to be used in this way (and it's the default!). Based on WP:BOTAPPEAL, I think WP:BOTN may be the place to go, with a clear and concise explanation of the issue and why it is fundamental to the script, not an issue of individual operator action. Wracking talk! 21:34, 14 July 2023 (UTC)
- If a script is broken, then either fix the script or delete it. The only thing remotely BOT-related here is if there's WP:MEATBOT behaviour, and WP:MEATBOT gives admins all the leeway they need to act here. BAG has no special purview over scripts. Headbomb {t · c · p · b} 21:49, 14 July 2023 (UTC)
- I think the issue is that, while some editors think the script is broken and have asked for this functionality to be removed or restricted, others (such as some script users and the original developer) disagree, saying the script is not broken and is working as intended. This (YYYY-MM-DD to DMY or MDY in ref templates) is a default functionality of the script, to my understanding. (Meaning I would not define it as an issue of individual script-users.) Wracking talk! 03:18, 15 July 2023 (UTC)
- I have to agree with Wracking that the function of the script is not indisputably broken. As the CS1 templates work today, the presentation to the users can easily be made to comply with whichever format the editors of the article form a consensus for. We have no unequivocal principle of style or citation that says the wikitext must obey any particular style (with a few exceptions for especially confusing usages). We are not like a software shop where if your code doesn't follow the company style, you'll be in trouble with the boss.
- The strongest ground to attack the script, in my opinion, is that it my experiments suggest it doesn't behave the way the documentation says it behaves; I would have thought if you put a particular value in the cs1-style parameter, the script would obey it. But so far as I can determine, that parameter is ignored. Jc3s5h (talk) 10:20, 15 July 2023 (UTC)
- 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)
- 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 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)
- Whether it's BAG, ANI, or firing squad, I don't care. EEng 02:28, 13 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)
- 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.
- @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)
- Dondervogel 2 (talk) 18:54, 20 July 2023 (UTC)
- @Dondervogel 2: Rather than debate subjective aesthetics, I'll point out that YYYY-MM-DD never occurs in the body of an article, and thus could never fulfill MOS:DATEUNIFY. There's no reason to defend it so vehemently against a very useful script ("
BAG, ANI, or firing squad
"!), since its practicality is a matter of question. 〜 Festucalex • talk 19:01, 20 July 2023 (UTC)- You need to carefully read Wikipedia:Manual_of_Style/Dates_and_numbers#Consistency, especially the bullet on Access and archive dates. If an article's established citation format uses YYYY-MM-DD for access and archive dates, you must not change that unilaterally, even if this stupid script invites you to do so. The fact that this script has over and over tempted editors to do what they must not do, apparently without warning them about it, is the reason it needs to be either fixed (immediately) or trashed (immediately). EEng 19:42, 20 July 2023 (UTC)
- An editor could avoid breaking the consistency rule by using the script, and also inspecting the cs1-dates parameter in the use xxx dates template and insuring the value is correct; in the scenario mentioned by EEng a parameter value of ly would be suitable. Jc3s5h (talk) 20:04, 20 July 2023 (UTC)
- Incorrect. They could avoid breaking the consistency rule by NOT using the script on articles that are formatted in this way. The script is incapable of behaving correctly on articles with this formatting. It will always spell out the dates even when the article is tagged as using numeric access dates. And it is not always the case that articles in this format are tagged with the parameter stating that they are in this format. —David Eppstein (talk) 20:32, 20 July 2023 (UTC)
- MOSNUM only applies to the rendered result, not the wikitext. Prove otherwise. Jc3s5h (talk) 23:30, 20 July 2023 (UTC)
- Scripts that make only unseen changes to articles are generally forbidden, by WP:COSMETICBOT. —David Eppstein (talk) 23:57, 20 July 2023 (UTC)
- WP:COSMETICBOT only applies to bots. The script is not a bot. Jc3s5h (talk) 13:55, 21 July 2023 (UTC)
- COSMETICBOT also applies to bot-like editing from users, meaning (as I understand it) wide-ranging or rapid-fire changes done manually or with semi-automated tools. This would apply to users who use the script repeatedly and rapidly, but not, I think, to users who just run it on pages they're working on anyway. Even though I don't tend to use the script rapidly, I do still try and avoid making cosmetic-only edits while using it. I make a few copyedits rather than publish an edit that doesn't affect the rendered page. Firefangledfeathers (talk / contribs) 14:39, 21 July 2023 (UTC)
- These are not unseen changes, though. GiantSnowman 07:19, 22 July 2023 (UTC)
- To an extent, they are, and that was part of the earlier discussions. For example, here's one of your script-assisted edits that was purely cosmetic. FYI, I had to go back sixteen edits on this list to find it. Firefangledfeathers (talk / contribs) 01:00, 25 July 2023 (UTC)
- These are not unseen changes, though. GiantSnowman 07:19, 22 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)
- WP:COSMETICBOT only applies to bots. The script is not a bot. Jc3s5h (talk) 13:55, 21 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)
- MOSNUM only applies to the rendered result, not the wikitext. Prove otherwise. Jc3s5h (talk) 23:30, 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)
- 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)
- You need to carefully read Wikipedia:Manual_of_Style/Dates_and_numbers#Consistency, especially the bullet on Access and archive dates. If an article's established citation format uses YYYY-MM-DD for access and archive dates, you must not change that unilaterally, even if this stupid script invites you to do so. The fact that this script has over and over tempted editors to do what they must not do, apparently without warning them about it, is the reason it needs to be either fixed (immediately) or trashed (immediately). EEng 19:42, 20 July 2023 (UTC)
- @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 ("
- @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'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)
- SchroCat —Got any suggestions for fixing it? I'm not very technical. Tony (talk) 10:16, 22 July 2023 (UTC)
- Wracking, readers do see YYYY-MM-DD text when the cs1-dates parameter is set for that format. Tony, I think the main culprit for dmy in US English articles is the RefToolbar, which automatically scrapes website for dates and defaults to DMY. If Template:Use MDY dates is present, these wikitext DMY dates display as MDY for readers. Firefangledfeathers (talk / contribs) 14:42, 21 July 2023 (UTC)
- It's hardly satisfactory, the default. Tony (talk) 02:29, 22 July 2023 (UTC)
- It is only 'translated' if the article as a DMY or MDY tag - which is what the script adds... GiantSnowman 07:20, 22 July 2023 (UTC)
- 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)
- 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)
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)
- 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)
- 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)
- @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)
At what point was somebody going to notify me about this discussion, given you (@EEng and David Eppstein:) are, respectfully, slagging me off and trying to impose some kind of ban on me? GiantSnowman 07:13, 22 July 2023 (UTC)
- We're not saying anything about you that you haven't heard us say 100 times: using this script you regularly mess up dates in articles, and won't stop. EEng 08:09, 22 July 2023 (UTC)
- and always respectfully Dondervogel 2 (talk) 08:36, 22 July 2023 (UTC)
- That is nonsense and you know it. GiantSnowman 08:58, 22 July 2023 (UTC)
- Humor impairment strikes again. EEng 09:05, 22 July 2023 (UTC)
- Actually, wait... what are you saying is nonsense? The
always respectfully
bit? TheWe're not saying anything about you that you haven't heard us say 100 times
bit? Or theyou regularly mess up dates in article
bit? EEng 09:07, 22 July 2023 (UTC)- All of it. GiantSnowman 09:10, 22 July 2023 (UTC)
- Then we're back to
humor impairment strikes again
. EEng 09:19, 22 July 2023 (UTC)- Are the personal insults necessary or appropriate here? -- Pemilligan (talk) 11:38, 22 July 2023 (UTC)
- Then we're back to
- All of it. GiantSnowman 09:10, 22 July 2023 (UTC)
- That is nonsense and you know it. GiantSnowman 08:58, 22 July 2023 (UTC)
- and always respectfully Dondervogel 2 (talk) 08:36, 22 July 2023 (UTC)
- Talking of notification, Ohconfucius has finally been alerted to the discussion (in another context). David Brooks (talk) 14:40, 22 July 2023 (UTC)
There may be some misunderstanding about how my script works in conjunction with MOSNUM so I'll try and discuss what my operating considerations are:
firstable, the script was and is intended to convert or unify formats throughout any given article. It still does the job pretty well, with very few false negatives or false positives. There is no reason not to use the script. The controversy seems more to be related to the political choice of editors.
According to strict interpretation of guidelines, once autoformatting began, there is no reason for any ref dates to be changed; users are to rely on parameters within the {{use xxx dates}} templates. By that same token, editors should use the parameters if they want ref dates to display in yyyy-mm-dd form.; the script ought to stop acting on dates within references. So although we have been ordered not to care any more about the underlying dates and focus on the rendered output, I have not modified the script to stop their conversion because I found to not do so sometimes gives rise to unsatisfactory results: especially where the references pre-exist without citation templates, in which case the automatic rendering ordered by the "use" templates fail. There is no solution to this in any event.
Secondly, most existing articles started life with either dmy or mdy dates; yyyy-mm-dd dates are a relative latecomer and few were inserted by human editors. To decide which format should prevail, we defer to WP:RETAIN in disputes. But precious few editors check what original format the "first major contributor" used.
We see some editors preferring yyyy-mm-dd ref dates increasingly up in arms, but there is no reason to be, for the reasons already stated above – we only care about the rendered output. Bearing the above in mind, I certainly don't see the need to rewrite the script so that it allows conversion of ref dates to yyyy-mm-dd form. All editors need to do is to confirm that the very first date is indeed in yyyy-mm-dd form, and then apply the parameter as in {{use xxx dates|ls}}. There should also be no more discussing "ugliness" of one date format over another, nor for chastising fellow editors for the inconsequential removal of yyyy-mm-dd dates lest forget the goal of having consistent date formats in any given article. -- Ohc revolution of our times 22:46, 24 July 2023 (UTC)
- Ohconfucius, don't you think an edit like this one is troublesome? Prior to the script-assisted edit, the article had no Use XXX dates tag, but was fully consistent in its use of a MOS-accepted style. The script changed from one acceptable style to another, which we urge editors not to do without discussion. Firefangledfeathers (talk / contribs) 01:00, 25 July 2023 (UTC)
- I think I've already said what needed to be said. It's a political editorial choice and my script is but a tool to that end. The only issue I have with the edit is that the editor neglected to add the
|cs1-dates=
parameter, and appeared to edit war over the format. The insertion of {{use mdy dates}} is useful and necessary, and correct application of the parameter at the outset may well have avoided the conflict. Although the script doesn't add the parameter, it doesn't overwrite it. Ohc revolution of our times 18:29, 25 July 2023 (UTC)- Why do you keep saying things are "political"? What in the world are you talking about? EEng 19:09, 25 July 2023 (UTC)
- I mean it's editorial choice based on interpretation of policies. Ohc revolution of our times 19:20, 25 July 2023 (UTC)
- Why do you keep saying things are "political"? What in the world are you talking about? EEng 19:09, 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
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).
- In the interests of making consensus visible, I'd second everything said here. UndercoverClassicist (talk) 19:09, 16 July 2023 (UTC)
- 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)
- 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)
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
NebY (talk) 10:11, 27 July 2023 (UTC)an editorour fellow editors withextra textlong diatribes and unrealistic proposals, God killsa kittenall the kittens.
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)
- 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
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)
- @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)
- 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 11/2, 10.875 as 107/8 𝕁𝕄𝔽 (talk) 16:36, 15 August 2023 (UTC)
- I don't know whether screenreaders can handle {{sfrac}} but category names cannot so the question isn't relevant. Thryduulf (talk) 17:24, 15 August 2023 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
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)
- 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)
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)
- Indeed, they're just silent for the unrecognised character or read it like a question mark. Graham87 17:10, 15 August 2023 (UTC)
Kelvins
@Dondervogel 2: Kelvin#Orthography now has several sources documenting the preference for "kelvins" in plural contexts like "four kelvins". Is it OK to revert this revert now? -- Beland (talk) 18:31, 21 August 2023 (UTC)
- To be honest, "four kelvin" sounds more natural to me than "four kelvins", but that's a poor reason on its own to object to NIST or CERN guidance. I suggest first seeking the views of others. If there are no objections after 3 days to "four kelvins", I would not object either. Dondervogel 2 (talk) 21:19, 21 August 2023 (UTC)
- Just guessing, but this might have to do with temperature vs temperature difference: "Hydrogen boils at 23 kelvin" vs "Over the next minute the temperature increased 42 kelvins". To repeat: just guessing. EEng 21:44, 21 August 2023 (UTC)
- That's not how NIST approaches it; instead, they have
For example, “mercury loses all electrical resistance at a temperature of 4.2 kelvins.”
[12] I guess it may seem odd because we often skip the "degrees" from "degrees Celsius" or "degrees Fahrenheit" and talk of 68 Fahrenheit not 68 Fahrenheits; or because until 1967 the SI term was "degrees kelvin"; or because we so very rarely do talk of temperature in kelvins at all. NebY (talk) 22:10, 21 August 2023 (UTC)- I guess it's a good thing I kept repeating that I was just guessing. Also, I was just guessing. EEng 23:55, 21 August 2023 (UTC)
- That's not how NIST approaches it; instead, they have
- Just guessing, but this might have to do with temperature vs temperature difference: "Hydrogen boils at 23 kelvin" vs "Over the next minute the temperature increased 42 kelvins". To repeat: just guessing. EEng 21:44, 21 August 2023 (UTC)
Dates in citations
I was recently pointed to MOS:NUM in an edit which only changed all ISO8601 dates in citations to plain text. However I didn't see anything of the sort on this page... Is there a reason for such changes? IMO we should put ISO8601 in citations as the templates auto-convert them to the appropriate format specified by one of the "use" templates which makes it easier if the article is ever put under a different date format. Aaron Liu (talk) 20:57, 22 August 2023 (UTC)
- Some publication dates are in the Julian calendar. According to Wikipedia:Manual of Style/Dates and numbers, for the YYYY‐MM‐DD format,
Use yyyy-mm-dd format only with Gregorian dates from 1583 onward.
- Jc3s5h (talk) 22:15, 22 August 2023 (UTC)
- Sure, but none of the dates in that article were before 1583. Aaron Liu (talk) 22:18, 22 August 2023 (UTC)
- Do you promise to never edit an article which cites material published before 1 March 1923, or which cites anything published by an Orthodox church, or publisher affiliated with an Orthodox church? Jc3s5h (talk) 22:39, 22 August 2023 (UTC)
- And dost thou renounce Satan? and all his works? and all his pomps? (But not his pumps -- see File:Satan In High Heels - 1962 - Poster.jpg.) EEng 22:55, 22 August 2023 (UTC)
- What? Sorry, I've lost you. What does this have to do with 1923 or the Orthodox? What do articles that can't use ISO8601 in infoboxes (which is where you might use mdy exposed) have to do with citation templates which have their dates auto-converted to the suitable general use format? Aaron Liu (talk) 22:53, 22 August 2023 (UTC)
- You said you want to use ISO 8601 dates. ISO 8601 requires that dates be in the Gregorian calendar. If you use ISO 8601 format but it's really a Julian calendar date, it's a lie. Also, some branches of the Orthodox churches still use the Julian calendar. The Greek government didn't switch from Julian to Gregorian until 1923. Jc3s5h (talk) 23:39, 22 August 2023 (UTC)
- It's preferred but nothing's going to go wrong if you use an old style date. It's not like the article's going to automatically convert the date as if it was Gregorian. How would it be a lie? Aaron Liu (talk) 23:45, 22 August 2023 (UTC)
- If somebody removes the use xxx template it becomes a clear lie. Jc3s5h (talk) 23:57, 22 August 2023 (UTC)
- 44-03-15 BC is exactly the same as 15 March 44 BC. How is it a "clear lie"? Aaron Liu (talk) 00:00, 23 August 2023 (UTC)
- "44-03-15 BC" is nonsense and doesn't mean anything. If 15 March 44 BC is a Julian proleptic calendar date, then in ISO 8601 it would be written −0043‐03‐13, which is in the Gregorian proleptic calendar. Also, it would be contrary to the guidance in WP:MOSNUM to use "−0043‐03‐13" in a Wikipedia article because that format is not to be used for dates before 1583. Jc3s5h (talk) 00:13, 23 August 2023 (UTC)
- 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)
- If somebody removes the use xxx template it becomes a clear lie. Jc3s5h (talk) 23:57, 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)
- 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)
- 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)
- Sure, but none of the dates in that article were before 1583. Aaron Liu (talk) 22:18, 22 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 thesefailure 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)
- 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)
- 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)
- 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)
- 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
calenricalcalendrical peculiarities that the module does not know about. - The module is not intended to know all there is to know about calendars because the templates are general purpose templates which are designed to be sufficient for most citation needs. If you need to cite the 29 February 1699 London Gazette issue, you would be better served to hand-craft the citation for that special case.
- —Trappist the monk (talk)
15:36, 23 August 2023 (UTC)Fix spelling 16:00, 23 August 2023 (UTC)- Calenrical isn't a word but I feel like it ought to be. EEng 15:51, 23 August 2023 (UTC)
- Reingold, Edward M.; Dershowitz, Nachum (2018). Calendrical Calculations: The Ultimate Edition (4th ed.). Cambridge University Press. ISBN 978-1-107-68316-7.
- Jc3s5h (talk) 16:14, 23 August 2023 (UTC)
- Calenrical isn't a word but I feel like it ought to be. EEng 15:51, 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)
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 sayIn 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)
- 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)
- 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)
- 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)
- 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)
Good catch. I've been doing a lot of conversions (recently a lot of Fahrenheit and furlongs) and use this section a lot, and I hadn't even noticed this directive was not made explicit. I support adding something that encourages conversions of each mention of unfamiliar units, except where this would become excessive. We already assume Americans have learned the metric system in science class, and don't do conversions in science articles, so I think it would be fine to only require conversion to SI units. Converting to both SI and American customary would make the conversions take up twice as much space as the original measurement, and starts to be a bit much in running prose. I don't object to a dual conversion on initial mention of an unusual unit, for editors who want to do that, but personally when I'm running around adding conversions as long as there are metric units I consider my job done. Maybe something like the below?
- For units of measure that are obsolete, obscure, or otherwise not part of the SI or US customary systems (e.g. furlong, zlotnik), supply a parenthetical conversion into at least SI units. Convert each mention, unless this would be excessive given the context. Take care to distinguish between different definitions of the same unit if it has changed over time or differs geographical (e.g. cubit, batman). An approximate or range conversion is acceptable if the exact historical value is uncertain (e.g. stadion).
-- Beland (talk) 02:30, 10 August 2023 (UTC)
- A furlong is a US customary unit. Hawkeye7 (discuss) 03:06, 10 August 2023 (UTC)
- And in South Asia, unlike the US & UK, it is not essentially confined to horse racing, but still a common unit when eg giving street directions. Johnbod (talk) 14:17, 10 August 2023 (UTC)
- Yes, furlongs are part of the American system, but for Americans, they are obscure, and the text above intentionally encompasses both. Furlongs are not taught in school, and if you stop people on the street, I'm sure over 95% of people will not be able to tell you how long one is. The existing MOS:UNITS says primary units in South Asia are metric, so they would already need to be converted if used in articles about that region. Would it help to say "obscure from an global perspective" instead of just "obscure"? It's not particularly helpful to have unconverted units that are only familiar to people in a specific geography. -- Beland (talk) 16:38, 10 August 2023 (UTC)
- 99.9%. EEng 21:41, 10 August 2023 (UTC)
- 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)
- 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)
- @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 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 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:
Examples of type for less familiar currencies:
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)
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
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)
Revised proposalI 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.
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)
Notes
Side note: a previous disruptive edit to a template provided the weak foundation for this debate
Discussion has become mootUser: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)
- 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)
- 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)
- 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)
- 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)
- 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 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)
- Yes, I strongly agree with this. It's pointless and distracting having them at the top. — SMcCandlish ☏ ¢ 😼 21:20, 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)
- When coords are displayed at the top of the article, by means of
- 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)
- 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 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)
- 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)
- @Yngvadottir: You appear to have it backwards. With the
- 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)
- If there is only one {{coord}} template with the parameter
|display=inline,title
, it's still a single coord template, so I don't think it counts as duplication. Sure, the same info is going to be displayed in two places, but I do not see this as a bad thing as long as the same coordinates are shown in the title and the infobox. After all, infoboxes duplicate info that is already in the body, and (in many cases) the lead also summarizes info that is in the body. I would be far more concerned if the infobox had one set of coordinates, and if there was a different set of coordinates displayed just below the page title.By the way, I oppose moving coordinates down to the footer. It doesn't really solve anything and, in the case of geographical locations, actually makes it much harder to see that location on a map (there is a little drop-down map next to the globe icon of the {{coord}} template if the coordinates are displayed in the title). Further, it's quite pointless. – Epicgenius (talk) 14:18, 25 August 2023 (UTC)- While "geographiles" love the coordinates upfront, the average reader likely find it's just clutter. fgnievinski (talk) 23:43, 25 August 2023 (UTC)
Suggested shortcuts
Suggested for § Scientific and engineering notation: MOS:SCNOT, MOS:SCINOT, MOS:ENGNOT. Was surprised there was no shortcut to that section.
Also more "out-there" but might be easier for some to remember: MOS:TENTOTHE, MOS:10TOTHE. Meaning of course "ten to the power of x".
WP:AFC/R template barfs on cross-namespace redirs because it's designed to catch newbies who don't know what they're doing. Figured I'd just put the suggestions here instead. Plus that lets people provide input into what they consider redir-worthy. Go ahead and create if you like. Just trying to be helpful (for myself in the future even). Have a fine day. --47.155.41.104 (talk) 04:51, 25 August 2023 (UTC)
- "FOONOT" tends to be used for notability guidelines, but I guess with "MOS:" on the front of it there would be less likelihood of confusion. If no one's got objections, I can handle this; I think I created about half the MoS shortcuts. :-) — SMcCandlish ☏ ¢ 😼 16:49, 25 August 2023 (UTC)
- "NOT" does make me think of negatives. MOS:EXPO? NebY (talk) 17:16, 25 August 2023 (UTC)
- How about MOS:SCIENTIFICNOTATION? I don't see it getting a 2 x 10^3 lb of use. EEng 17:38, 25 August 2023 (UTC)
- That's short measure, try 2.24 x 10^3 lb. ;-) Martin of Sheffield (talk) 19:49, 25 August 2023 (UTC)
- i agree that "NOT" suggests a negative, as seen in "MOS:NOTUSA" and "WP:NOTSTUPID". (i think notability is more associated with "N", as seen in "WP:GNG" and "WP:NSPORT", though i just realized that the "NOT" in "WP:TRUMPNOT" might be referring to notability.) "MOS:EXPO" admittedly suggests to me that we have a style guideline about large international exhibitions.how about "MOS:SCIENG", or alternatively "MOS:SCIENGNOTATION", if additional clarification seems necessary? for the "out-there" variants, i would suggest "MOS:10EX" or "MOS:10^X". dying (talk) 21:13, 25 August 2023 (UTC)
- MOS:SCIENG might been too vague (lots of MoS, especially MOS:NUM, has something to do with science. MOS:SCIENGNOTATION should work. MOS:10^X should also work well. — SMcCandlish ☏ ¢ 😼 22:10, 25 August 2023 (UTC)
- I like those. Just interested in something shorter to punch in if in a hurry. 47.155.41.104 (talk) 23:25, 25 August 2023 (UTC)
- It's more important that your fellow editors be able to recognize the shortcut without clicking through than that you be able to type it quickly. EEng 16:34, 27 August 2023 (UTC)
- Especially when it comes to the shortcuts we "advertise" in the page itself, which is what this discussion is really about. Anyone can create any shortcut they want (within reason; if you create crap ones, then WP:RFD will nuke them, of course). But we should only present one or two really good shortcuts as the "advertised" ones here. (Some MoS sections have 20+ shortcuts, but we only list one to a handful of them). — SMcCandlish ☏ ¢ 😼 17:25, 27 August 2023 (UTC)
- Yeah, fine with me. Right now that section has no shortcuts. I have no sentimental attachment to my suggestion—just wouldn't mind one or two for that section. 47.155.41.104 (talk) 01:56, 28 August 2023 (UTC)
- seeing support for (and no opposition to) "MOS:SCIENGNOTATION" and "MOS:10^X", i have gone ahead and boldly created those two redirects. i will let others decide whether they should be the advertised shortcuts; adding them to the manual myself seemed somewhat self-promotional.by the way, i recently realized that the mos:num shortcut was apparently changed about a year ago to point to a specific section of the guidelines. is this desirable? dying (talk) 20:23, 1 September 2023 (UTC)
- Added them for you. Also fixed the MOS:NUM redirect, which is what Wikipedia:Manual of Style/Dates and numbers advertises as it main page-top shortcut. If we wanted it to go to the #Numbers section, and pick a new page-top shortcut, that would be a consensus discussion to have. — SMcCandlish ☏ ¢ 😼 21:05, 1 September 2023 (UTC)
- 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)
- 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)
- 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)
- It's more important that your fellow editors be able to recognize the shortcut without clicking through than that you be able to type it quickly. EEng 16:34, 27 August 2023 (UTC)
- 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)
- That's short measure, try 2.24 x 10^3 lb. ;-) Martin of Sheffield (talk) 19:49, 25 August 2023 (UTC)
- How about MOS:SCIENTIFICNOTATION? I don't see it getting a 2 x 10^3 lb of use. EEng 17:38, 25 August 2023 (UTC)
- "NOT" does make me think of negatives. MOS:EXPO? NebY (talk) 17:16, 25 August 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 × 12/2.1. Indefatigable (talk) 20:34, 1 September 2023 (UTC)
- or . 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, which of course simplifies to . --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)
- You can eliminate the decimal point in the denominator by multiplying top and bottom by 10, which of course simplifies to . --Redrose64 🌹 (talk) 22:59, 2 September 2023 (UTC)
- Err,
- or . CapitalSasha ~ talk 23:08, 1 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. EEng 16:39, 27 August 2023 (UTC)
- Yeah, WP is not written to SI's style guide (or ISO's or BIPM's, etc.). We're happy to accept their advice when it doesn't conflict with normal English usage, when there's a "clearly improves the encyclopedia" reason to do so, and especially when the particular point has made its way into major general style guides (e.g. much of WP:MOSNUM is derived from Scientific Style and Format, which is essentially a collation of the most useful and consistent style points promulgated by such organizations and by academic journal publishers). A side point: The South African government officially uses "1 234 567,890" style, but WP is not written in bureaucratese/officialese, and I can't find any evidence that South African readers have any trouble interpreting "1,234,567.890" format, which is otherwise used nearly universally in the English-speaking world, and is also built into many programming languages, user interfaces, etc. (regardless of language). I have a strong suspicion that even non-native users of English today have no difficulty with this format at all because of its modern ubiquity. However, there is probably some kind of Javascript "gadget" approach that could be built to convert between these formats on-the-fly, on the user side. I know that the citation templates are doing complex date-format translation, so this is clearly technically possible. — SMcCandlish ☏ ¢ 😼 17:41, 27 August 2023 (UTC)
- I oppose a Wikimedia Foundation approved method for users to reformat numbers according to their preference. The next thing you know, the users of the system would demand we go in and apply special markup to numbers that are, for some reason, incompatible with the system. Jc3s5h (talk) 19:31, 27 August 2023 (UTC)
- You may remember when Wikipedia tried across-the board date autoformating, or maybe you've happily blanked it, in which case there's an overview here. That's a nicely circumscribed problem compared to rendering all numbers. Rendering all numbers held within {{val}}-like templates would be a bit easier, but then we'd have to persuade all editors to template numbers and to put up with the source text being even harder for human readers to parse, plus many of the other problems in that overview. NebY (talk) 18:20, 28 August 2023 (UTC)
- 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 would support a change along the lines of the one proposed by Nativeblue (talk · contribs). Using thin spaces instead of commas makes lists of numbers easier to read and eliminates the risk of the comma being misinterpreted as a decimal separator. Dondervogel 2 (talk) 17:52, 27 August 2023 (UTC)
- Clarification: I don't think anyone wants a blanket ban on use of the comma as thousands separator, and I would not support that either. It has been mentioned that some subject areas (e.g., finance) would not benefit from thin spaces, and that's reasonable. I just think that Wikipedia as a whole would benefit from wider use of thin space separators where there is no good reason to insist on a comma. Dondervogel 2 (talk) 20:26, 29 August 2023 (UTC)
- I'm a techie; I happily read numbers separated by thin spaces and sometimes use them within and outside Wikipedia. Most of our readers aren't, and most websites, newspapers, books and magazines don't use thin spaces. Most of our editors don't either, and many will complain about or revert them. Switching to thin spaces across Wikipedia, for mentions of monetary values, distances, demographics, and all the other quantities in the encyclopedia, would require broad support and clear consensus among active editors. It would not be possible to impose it by consensus among the few regulars at WT:MOSNUM; that would only result in MOSNUM guidance being revereted. Instead it would require techies and non-techies alike to agree it in a massive centralised discussion, and that would be dominated by the question of what actually happens in the world we describe - a world which has largely metricated (or metrificated), mainly implementing SI, with this one glaring exception. NebY (talk) 18:25, 27 August 2023 (UTC)
- Just no this is not how the majority of English-speaking countries render numbers in educational or business prose. Given that this is the English Wikipedia, we go with the common English-language style. TonyBallioni (talk) 18:50, 27 August 2023 (UTC)
- This is already dead in the water, but I'll add my opposition. – John M Wolfson (talk • contribs) 19:16, 27 August 2023 (UTC)
- Sorry this sounds like a terrible idea. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:40, 27 August 2023 (UTC)
- I'm not against it - although not wildly for it either. But how would it be implemented? Editors are not going to type in the Unicode for thin space - we have enough trouble getting them to use various dashes (note my incorrect but common use of "-"). Also, cutting and pasting those numbers to other programs or web pages may have those Unicode characters in them that may confuse that other program. They would have to wrap every number over 999 (or 9999) in something like
{{val}}
, which uses clever CSS tricks to copy only the digits. But wrapping them is a huge inconvenience to the editors and makes the wiki mark-up clumsy and hard to read and the majority of editors simply won't even realise that it should be done at all. Stepho talk 22:46, 27 August 2023 (UTC) - Clearly a non-starter, for the numerous pragmatic reasons already discussed above, and more besides. This is an encyclopedia, not a technical resource. As such, its content is formatted and stylized in a fashion calculated to make it as easily digestible to the average reader of English, and consistent with broadest conventions employed within the most commonly used written idiolects. The principle of least astonishment should definitely be employed here, not for prescriptive reasons, but simply to make the content as accessible as possible to the average user likely to be reading our content. The proposal would replace that calculus for an effort to reach towards a more regularized and universal standard. But putting aside that my experience suggests to that the standard itself is not nearly as universally adopted in technical spheres and in global populations as the OP seems to think, it's just clearly not practical for encyclopedic form in the relevant language here. SnowRise let's rap 22:59, 27 August 2023 (UTC)
- "principle of least astonishment" Lol. Thank you for that addition to my mental furniture. Elinruby (talk) 03:14, 28 August 2023 (UTC)
- @Elinruby: See also WP:ASTONISH, and Principle of least astonishment. — SMcCandlish ☏ ¢ 😼 05:13, 28 August 2023 (UTC)
- thanks. surprised I had not previously encountered that Elinruby (talk) 05:53, 28 August 2023 (UTC)
- And don't forget WP:Principle of Some Astonishment. EEng 06:03, 28 August 2023 (UTC)
- thanks. surprised I had not previously encountered that Elinruby (talk) 05:53, 28 August 2023 (UTC)
- @Elinruby: See also WP:ASTONISH, and Principle of least astonishment. — SMcCandlish ☏ ¢ 😼 05:13, 28 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)
- 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)
- 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)
- 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)
- @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)
- @Elinruby: Which of these two lists do you find easier to read:
- 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)
- Do you mean like this?
- 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)
- 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)
- 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)
- 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
- 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)
- 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)
- 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 or 3.141592654.... I should get or 3.141,592,654, should I? Because that looks way off to my eye. And the non-breaking spaces don't always work at all. I mean, I can render 3.141 592 654 using
{{math}}
but<math>
won't render a non-breaking space. I think whatever we decide here is going to need fixes to the way math syntax works. I also don't think it's right to to insist on American high school number style for articles covered by WikiProject Mathematics, WikiProject Astronomy, and other hard science for grown ups, and I feel we need a sort of WP:ENGVAR-style "don't alter the original author's formatting" rule.—S Marshall T/C 13:37, 2 September 2023 (UTC)- I don't think anyone is considering grouping with commas after the decimal point. I haven't read the whole discussion so I can't be sure, but I'd be fairly shocked. I would remove such commas on sight, and I think most people would, without needing anything said about them in the MoS. Commas before the decimal point are what I think we're discussing. --Trovatore (talk) 16:19, 2 September 2023 (UTC)
- Yeah, I don't know what S Marshall's going on about. Nothing in either the main MOS or MOSNUM suggests these weird things. EEng 17:24, 2 September 2023 (UTC)
- It startled me too. But it's possible to take
In general, digits should be grouped and separated either by commas or by narrow gaps
to mean that commas may be used as separators after the decimal point, with an exception for numbers greater than 999,When commas are used left of the decimal point, digits right of the decimal point are not grouped (i.e. should be given as an unbroken string)
. NebY (talk) 17:43, 2 September 2023 (UTC)- If anyone seriously suggests doing that we'll just have them killed. I know people who will do it for nothing as a public service. EEng 18:38, 2 September 2023 (UTC)
- We should probably mention that. NebY (talk) 18:42, 2 September 2023 (UTC)
- What, and spoil the fun? Dondervogel 2 (talk) 19:05, 2 September 2023 (UTC)
- We should probably mention that. NebY (talk) 18:42, 2 September 2023 (UTC)
- If anyone seriously suggests doing that we'll just have them killed. I know people who will do it for nothing as a public service. EEng 18:38, 2 September 2023 (UTC)
- It startled me too. But it's possible to take
- Yeah, I don't know what S Marshall's going on about. Nothing in either the main MOS or MOSNUM suggests these weird things. EEng 17:24, 2 September 2023 (UTC)
- 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)
- If it means don't group numbers after the decimal then it should say so. And my other point remains: we still need to make exceptions to the commas rule for people using
{{math}}
and<math>
so the articles about serious maths can use serious maths formatting.—S Marshall T/C 21:48, 2 September 2023 (UTC)- Please say the exact change to the guideline text you want. I can't tell what the problem is. EEng 23:52, 2 September 2023 (UTC)
- The rule is "always use commas for large numbers". I want exceptions to that rule, firstly for articles within the scope of WikiProject Mathematics, and secondly, for all editors using
{{math}}
or<math>
rather than typed out numbers.—S Marshall T/C 01:04, 3 September 2023 (UTC)- By "the exact change" I mean something of the form: "Add blah blah blah as a new bullet point to the Foo list" or "Change the text lorem ipsum to mickey mouse". EEng 07:31, 3 September 2023 (UTC)
- Playing Devil's advocate, if I was editing an article about how many of a particular car were sold in 2020 and I didn't want to use commas, then according to your proposal I could wrap the sales figures in
{{math}}
or<math>
. Stepho talk 01:11, 3 September 2023 (UTC) - The rule given at WP:MOS#Numbers is "In general, use a comma in numbers with five or more digits to the left of the decimal point." I think that's generally good guidance. It links to MOS:DIGITS for the specifics, and DIGITS gives us "[grouping with narrow gaps] is especially recommended for articles related to science, technology, engineering or mathematics". I think the status quo is not far off from what you're looking for, but I may be misunderstanding your view. Firefangledfeathers (talk / contribs) 01:16, 3 September 2023 (UTC)
- For example, binaries. The decimal number 100 should be rendered in binary as 1100100 and not 1,100,100. Our article on binary number, if you check it, actually uses commas to separate numbers in a list of numbers rather than to group digits. It's a pretty decent article and trying to make it comply with this MOS rule would break it.—S Marshall T/C 01:22, 3 September 2023 (UTC)
- No one in their right mind would understand the guideline to mean you should do that. EEng 07:31, 3 September 2023 (UTC)
- My experience with editors who're MOS focused is very different from yours, then.
- Humour me, Eeng. Utterly needless though these clarifications are, let me put them in.—S Marshall T/C 08:46, 3 September 2023 (UTC)
- For, like, the third or fourth time, say exactly what change you want, or just put it in the guideline directly so we can all see it, or do something else tangible. You keep saying you want something added but never say quite what. EEng 19:59, 3 September 2023 (UTC)
- No one in their right mind would understand the guideline to mean you should do that. EEng 07:31, 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)
- 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
- Please say the exact change to the guideline text you want. I can't tell what the problem is. EEng 23:52, 2 September 2023 (UTC)
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
|
---|
|
- 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)
- Grouping of digits (whether by commas or spaces) is never done after the point, only before it. Our
- 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" ex