View source for Wikipedia talk:Manual of Style/Dates and numbers

← Wikipedia talk:Manual of Style/Dates and numbers

You do not have permission to edit this page, for the following reasons:

This IP address has been blocked from editing Wikipedia.
This does not affect your ability to read Wikipedia pages.
Most people who see this message have done nothing wrong. Some kinds of blocks restrict editing from specific service providers or telecom companies in response to recent abuse or vandalism, and can sometimes affect other users who are unrelated to that abuse. Review the information below for assistance if you do not believe that you have done anything wrong.

The IP address or range 206.189.32.0/20 has been blocked by ‪ST47‬ for the following reason(s):

The IP address that you are currently using has been blocked because it is believed to be a web host provider. To prevent abuse, web hosts may be blocked from editing Wikipedia.
You will not be able to edit Wikipedia using a web host provider because it hides your IP address, much like a proxy or VPN.
We recommend that you attempt to use another connection to edit. For example, if you use a proxy or VPN to connect to the internet, turn it off when editing Wikipedia. If you edit using a mobile connection, try using a Wi-Fi connection, and vice versa. If you are using a corporate internet connection, switch to a different Wi-Fi network. If you have a Wikipedia account, please log in.
If you do not have any other way to edit Wikipedia, you will need to request an IP block exemption.

How to appeal if you are confident that your connection does not use a web host's IP address:
If you are confident that you are not using a web host, you may appeal this block by adding the following text on your talk page: {{unblock|reason=Caught by a web host block but this host or IP is not a web host. My IP address is _______. Place any further information here. ~~~~}}. You must fill in the blank with your IP address for this block to be investigated. Your IP address can be determined here. Alternatively, if you wish to keep your IP address private you can use the unblock ticket request system. There are several reasons you might be editing using the IP address of a web host (such as if you are using VPN software or a business network); please use this method of appeal only if you think your IP address is in fact not a web host.

Administrators: The IP block exemption user right should only be applied to allow users to edit using web host in exceptional circumstances, and they should usually be directed to the functionaries team via email. If you intend to give the IPBE user right, a CheckUser needs to take a look at the account. This can be requested most easily at SPI Quick Checkuser Requests. Unblocking an IP or IP range with this template is highly discouraged without at least contacting the blocking administrator.

This block will expire on 07:33, 6 August 2027. Your current IP address is 206.189.44.186.

Even when blocked, you will usually still be able to edit your user talk page, as well as email administrators and other editors.

For information on how to proceed, please read the FAQ for blocked users and the guideline on block appeals. The guide to appealing blocks may also be helpful.

Other useful links: Blocking policy · Help:I have been blocked
This IP address has been blocked from editing Wikipedia.
This does not affect your ability to read Wikipedia pages.
Most people who see this message have done nothing wrong. Some kinds of blocks restrict editing from specific service providers or telecom companies in response to recent abuse or vandalism, and can sometimes affect other users who are unrelated to that abuse. Review the information below for assistance if you do not believe that you have done anything wrong.

The IP address or range 206.189.0.0/16 has been blocked by ‪ST47‬ for the following reason(s):

The IP address that you are currently using has been blocked because it is believed to be a web host provider. To prevent abuse, web hosts may be blocked from editing Wikipedia.
You will not be able to edit Wikipedia using a web host provider because it hides your IP address, much like a proxy or VPN.
We recommend that you attempt to use another connection to edit. For example, if you use a proxy or VPN to connect to the internet, turn it off when editing Wikipedia. If you edit using a mobile connection, try using a Wi-Fi connection, and vice versa. If you are using a corporate internet connection, switch to a different Wi-Fi network. If you have a Wikipedia account, please log in.
If you do not have any other way to edit Wikipedia, you will need to request an IP block exemption.

How to appeal if you are confident that your connection does not use a web host's IP address:
If you are confident that you are not using a web host, you may appeal this block by adding the following text on your talk page: {{unblock|reason=Caught by a web host block but this host or IP is not a web host. My IP address is _______. Place any further information here. ~~~~}}. You must fill in the blank with your IP address for this block to be investigated. Your IP address can be determined here. Alternatively, if you wish to keep your IP address private you can use the unblock ticket request system. There are several reasons you might be editing using the IP address of a web host (such as if you are using VPN software or a business network); please use this method of appeal only if you think your IP address is in fact not a web host.

Administrators: The IP block exemption user right should only be applied to allow users to edit using web host in exceptional circumstances, and they should usually be directed to the functionaries team via email. If you intend to give the IPBE user right, a CheckUser needs to take a look at the account. This can be requested most easily at SPI Quick Checkuser Requests. Unblocking an IP or IP range with this template is highly discouraged without at least contacting the blocking administrator.

This block will expire on 07:37, 6 August 2027. Your current IP address is 206.189.44.186.

Even when blocked, you will usually still be able to edit your user talk page, as well as email administrators and other editors.

For information on how to proceed, please read the FAQ for blocked users and the guideline on block appeals. The guide to appealing blocks may also be helpful.

Other useful links: Blocking policy · Help:I have been blocked
This IP address range has been globally blocked.
This does not affect your ability to read Wikipedia pages.
Most people who see this message have done nothing wrong. Some kinds of blocks restrict editing from specific service providers or telecom companies in response to recent abuse or vandalism, and can sometimes affect other users who are unrelated to that abuse. Review the information below for assistance if you do not believe that you have done anything wrong.

This block affects editing on all Wikimedia wikis.
The IP address or range 206.189.32.0/20 has been globally blocked by ‪EPIC‬ for the following reason(s):

Open proxy/Webhost: See the help page if you are affected

This block will expire on 08:48, 2 July 2025. Your current IP address is 206.189.44.186.

Even while globally blocked, you will usually still be able to edit pages on Meta-Wiki.

If you believe you were blocked by mistake, you can find additional information and instructions in the No open proxies global policy. Otherwise, to discuss the block please post a request for review on Meta-Wiki. You could also send an email to the stewards VRT queue at stewards@wikimedia.org including all above details.

Other useful links: Global blocks · Help:I have been blocked

You can view and copy the source of this page:

{{talkheader|sc1=WT:DATE|sc2=WT:MOSDATE}}
{{Calm}}
{{WikiProject banner shell|
{{WikiProject Manual of Style}}
}}
{{User:MiszaBot/config
|archiveheader = {{aan}}
|maxarchivesize = 800K
|counter = 163
|minthreadsleft = 2
|minthreadstoarchive = 1
|algo = old(60d)
|archive = Wikipedia talk:Manual of Style/Dates and numbers/Archive %(counter)d
}}
{{User:HBC Archive Indexerbot/OptIn 
|target=Wikipedia talk:Manual of Style/Dates and numbers/Archive index
|mask1=Wikipedia talk:Manual of Style/Dates and numbers/Archive <#>
|mask2=Wikipedia talk:Manual of Style/Dates and numbers/Archive zero
|mask3=Wikipedia talk:Manual of Style/Dates and numbers/Archive B<#>
|mask4=Wikipedia talk:Manual of Style/Dates and numbers/Archive D<#>
|leading_zeros=0 
|indexhere=yes }}
{{Wikipedia talk:Manual of Style/Dates and numbers/Archive box}}
{{tmbox|image=[[File:Ambox humor.svg|30px|link=|alt=]] |text=It has been '''{{age in days|2024|6|18}} days''' since the outbreak of the latest dispute over date formats.|small=yes}}

== Recent edits  ==

A string of edits by [[User:Jc3s5h|Jc3s5h]] and [[user:JMF|JMF]]. introducing and removing changes to {{slink|Wikipedia:Manual of Style/Dates and numbers|Common mathematical symbols}}, raise issues that I believe should be discussed.

#The most recent change, [[special:permalink/1247903136|permalink/1247903136]], has the comment {{tq|This page does not cover matrix operations.}}, however, I do not see anything in the article to support a restriction to numerical operations. 
#The most recent change reinstates the link to [[dot product]], despite the comment.
#There seems to be disagreement on the division sign.

The questions that I wish to raise are

#Should that section mention {{tl|tmath}} or {{tag|math}}?
#Are vector operations within the scope of the article? Regardless of the answer, the dot and cross products should be treated consistently.
#Should there be two new rows for dot and cross product?
#Should there be a row for [[tensor product]]?
#Is [[obelus]] unhelpful since it has three forms?
#Should the [[Division sign]] ({{Unichar|F7}}) be deprecated in favor of [[Slash (punctuation)|Slash]] ({{Unichar|2f}})?
#Should {{Unichar|2215}} be explicitly deprecated in favor of Slash?
#Should the use of "x" and "*" as multiplication signs be explicitly deprecated in favor of {{unichar|D7}}?
#Should that section show the {{Stylized LaTeX}} markup for characters in addition to the HTML [[List of XML and HTML character entity references#List of character entity references in HTML|character entity references]]?
-- [[User:Chatul|Shmuel (Seymour J.) Metz Username:Chatul]] ([[User talk:Chatul|talk]]) 10:52, 27 September 2024 (UTC)
:
:# I think the page should be devoted to general articles, and &lt;math&gt; should be reserved for advanced math and science articles.
:# Vector operations are not currently in the scope of the project page, and I'm not thrilled about adding them.
:# Dot product and cross product should certainly not be addressed in the same row as any scalar operation. The multiplication dot should certainly not be linked to the "Dot product" article nor should the multiplication cross be linked to the "Cross product" article.
:# Tensor products should not be covered in this project page because they're too advanced.
:#<li value=7> I'm not willing to spend 5 or minutes figuring out what this line means.
:# The asterisk as a multiplication sign should be limited to articles about computer languages that use it as such.
:# LATEX should not be mentioned, since we don't use it in Wikipedia. This isn't a style manual for writing outside of Wikipedia.
::[[User:Jc3s5h|Jc3s5h]] ([[User talk:Jc3s5h|talk]]) 19:45, 27 September 2024 (UTC)
:Tbh, I wondered what this extensive list is doing in the MOS in the first place. [[Glossary of mathematical symbols]] does it better. It really needs to be reduced to cover only those symbols that have a styling issue: scalar division and multiplication.
:* The grade-school division sign should be formally deprecated, for reasons explained at [[division sign]].
:* The 'ordinary' slash (002F) should be preferred over 2215, same logic as straight quotes and curly quotes.
:* I prefer {{unichar|00D7}} over x, for biology as well as math but maybe that needs debate.
:[[User:JMF|𝕁𝕄𝔽]] ([[User talk:JMF|talk]]) 20:04, 27 September 2024 (UTC)
:Comments:
:*I see no good reason to prohibit using a [[division sign]] to express division. That seems absolutely fine. The [[division sign]] article seems to say it might be confusing in Italian, Russian, Polish, Danish, Norwegian, or Swedish, but this is the English Wikipedia. We use [[full stop|point]]s as [[decimal separator]]s also, and we use [[comma]]s as a [[thousands separator]] too, although that might be confusing in other languages.
:*I also see no good reason to prohibit using an asterisk for multiplication; it seems well-understood, easy to type, unambiguous, and common in practice. I agree with not using "x" for multiplication, although I think it's OK to express "by" relationships for 2x4 lumber, 4x8 sheets of plywood, and 4x4 trucks.
:*<big><nowiki><math>x</math></nowiki></big> (i.e., <big><math>x</math></big>) looks different from <big><nowiki>''x''</nowiki></big> (i.e., <big>''x''</big>), and those look different from <big><nowiki>{{math|''x''}}</nowiki></big> (i.e., <big>{{math|''x''}}</big>), at least on my screen, and seeing mixtures of those in the same article can be a bit annoying (especially if they are near each other).
:—⁠ ⁠[[User:BarrelProof|BarrelProof]] ([[User talk:BarrelProof|talk]]) 21:46, 7 October 2024 (UTC)
:: Asterisk means [[convolution]] (which is somewhat related to the idea of "multiplication" but should not be confused with the usual multiplication). Its use as a substitution for "×" or "⋅" is a bad habit from the old days of poor technology (but it was never used as such in professional typesetting) and has no excuse nowadays. — [[User:Mikhail Ryazanov|Mikhail Ryazanov]] ([[User talk:Mikhail Ryazanov|talk]]) 22:12, 7 October 2024 (UTC)
::: Convolution would only be a matter to consider in very mathematically sophisticated specialized contexts. It's not something most people have ever encountered. Even for those who use it, it would often be expressed using [[summation]] or [[integral|integration]] instead. —⁠ ⁠[[User:BarrelProof|BarrelProof]] ([[User talk:BarrelProof|talk]]) 22:21, 7 October 2024 (UTC)
:::: I don't think that this is a good reason to make exceptions to tolerate/promote sloppy typography (moreover, in some computer fonts the ASCII asterisk [https://fonts.google.com/?preview.text=x%20*%20X%20= looks] more like a superscript than a binary operator consistent with +, −, = and so on).
::::: I don't think we should feel responsible for how Wikipedia is rendered in all possible fonts. We should remember that everyone is supposed to be able to edit Wikipedia articles. In an article that isn't about mathematics, or at least isn't using it beyond the 10th grade level, ''f = 1.8 * c + 32'' seems basically OK to describe conversion from degrees C to degrees F. It's tricky enough that we tell people to pay attention to the difference between "-", "&ndash;", "&mdash;", and "&minus;", and to not use italics for the numbers in that formula, although I support those instructions. —⁠ ⁠[[User:BarrelProof|BarrelProof]] ([[User talk:BarrelProof|talk]]) 03:37, 8 October 2024 (UTC)
:::::Nobody should complain about otherwise good edits that include "lazy" typography. Those edits are 100% OK and a net improvement to Wikipedia. Other editors who care about typography and MoS can clean up the markup and character choices later. Wikipedia is a collaborative project. [[User:Indefatigable|Indefatigable]] ([[User talk:Indefatigable|talk]]) 15:46, 8 October 2024 (UTC)
::Using an asterisk to represent multiplication is programming language syntax; I don't think this is common or even well-known among non-programmers. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 01:47, 20 October 2024 (UTC)
:::I agree we should discourage use of "*" as a multiplication symbol. I agree it's easy to type, so if one editor writes "''y'' = ''m''*''x'' + ''c''" in an otherwise correct edit, the response should not be to revert that edit, but to replace it with "''y'' = ''mx'' + ''c''" or other approved alternative. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 10:40, 20 October 2024 (UTC)
:::Using an asterisk for multiplication is absolutely known to non-programmers because that's what is used on the number pad on most keyboards in the US. --[[User:Khajidha]] ([[User talk:Khajidha|talk]]) ([[Special:Contributions/Khajidha|contributions]]) 14:28, 12 November 2024 (UTC)
::::Ah, but which came first - the {{keypress|*}} key, or its use in mathematical expressions? Forty-some years ago, I was taught that in computer code, the <code>*</code> character was chosen to avoid confusion with the letter <code>x</code>, since the <code>×</code> did not exist in either of the character sets that were in use at the time - ASCII and EBCDIC. It's the same with <code>/</code> vs. <code>÷</code> and indeed <code>-</code> vs. <code>−</code>. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 18:15, 12 November 2024 (UTC)
:::::{{keypress|*}} appeared on many (but not all) early typewriters. When not present it was often replaced by a fraction key (1/2, 1/4, etc) Practically every computer terminal from the 1970s onward has a {{keypress|*}} key - but that's probably due to it being used by Fortran (1957). Early teletype keyboards typically used [[Baudot code]] encoding and did not have {{keypress|*}} - but these were more for telecommunications rather than programming. Fortran was invented at IBM and used punch cards/tape using IBM's [[BCDIC]]. The early variations of BCDIC had {{keypress|*}}, {{keypress|-}} and {{keypress|/}} but not {{keypress|+}}. {{keypress|+}} was added soon after. My take is that BCDIC tried to encode whatever was commonly used on typewriters - subject to the limitation of using only 64 characters. Fortran then assigned functionality to whatever was in that set. {{keypress|*}} looked the most like {{keypress|x}} without being a letter, so it got the job. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 23:56, 12 November 2024 (UTC)
::::::It would really behoove participants here, instead of just speculating from the armchair, to take the radical step of doing some research to ''actually find out the answer''. {{keypress|*}} has been used, in math, to mean multiplication for three hundred years. See the bottom of p. 66 of [https://www.jstor.org/stable/2300111?seq=1]. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 07:15, 13 November 2024 (UTC)
:::::::I didn't mention that paper, because I'm not in the habit of searching through 100-year-old academic journals. Now, 100-year-old ''magazines'' is a different matter, witness my stacks of boxes of ''[[The Railway Magazine]]'' back to 1902 (gaps between 1902 and 1939, complete from 1940 onward). --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 12:02, 13 November 2024 (UTC)
:::::[[FORTRAN]] was a decade earlier than [[ASCII]] and [[EBCDIC]]. What the first FORTRAN compiler used was the scientific [[BCD (character encoding)|BCD]] character set of the [[IBM 704]], which replaced the older Percent (%) and Lozenge ({{unichar|2311}}) with parentheses. -- [[User:Chatul|Shmuel (Seymour J.) Metz Username:Chatul]] ([[User talk:Chatul|talk]]) 14:35, 13 November 2024 (UTC)

== Numerals in a sequence ==

'Phase 1' or Phase one'? This appears to be a case that's not explicitly covered.

The AP Stylebook recommends using figures for sequences in its section on "Numbers":
"Also use figures in all tabular matter, and in statistical and sequential forms", from which I infer that for sequences, such as 'phase 1', figures should be used for clarity and consistency.

Similarly, chapter 9 of The Chicago Manual of Style advises using figures when referring to a sequence.

I propose adding similar explicit advice to this section of the MOS. 

-- [[User:Jmc|Jmc]] ([[User talk:Jmc|talk]]) 20:10, 19 October 2024 (UTC)
*As usual, what's needed before something's added to MOS is examples of this being an issue on multiple articles -- see [[WP:MOSBLOAT]]. Are editors not able to work this out for themselves on individual articles? Anyway, why does the word "Phase" need this in particular? Why not "Section" and "Part" and any other words like that? {{pb}}The advice from APA and CMS are great if you're making up a new sequence for your thesis, but that's not us. It's hard to imagine an article using a phrase like "Phase 1" or "Phase One" on its own -- that is, other than in imitation of the phrasing of sources. So follow the sources; for example, [[Economic Stabilization Act of 1970]] refers to ''Phase I'' and ''Phase II'' and ''Phase III''., because that's the form the Act uses. We're not going to override that in the name of consistency with other, unrelated articles. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 22:00, 19 October 2024 (UTC)
*:To clarify: I'm using 'Phase' purely as an example. The issue of using figures for sequences applies to any sequence. including 'Section' and 'Part' - and other examples: "Game 3", of a sequence of nine; 'Chapter 9' of a sequence of 24; 'Week 4' of a limitless sequence.
*:I raise this issue in the context of differing editorial practices in the [[British Post Office scandal]] article, where both figures and words have been used to reference the same phases and weeks of the inquiry. I sought guidance from the MOS and found none.
*:I'd be content to follow the sources, without adding bloat to the MOS, if I could be confident that that's an accepted stylistic convention in this instance. -- [[User:Jmc|Jmc]] ([[User talk:Jmc|talk]]) 22:27, 19 October 2024 (UTC)
*::Such names are very often established by authoritative sources and constitute proper names; we should follow the sources rather than renaming them. Per EEng, we only need a MOS guideline if our sources don't provide clear names and either there is dissent among editors or consistency across articles would be of significant benefit. In the Post Office case, I see the phases have been titled Phase 1, Phase 2 etc by the inquiry[https://www.postofficehorizoninquiry.org.uk/public-hearings-timeline] so unless the inquiry's inconsistent, we can follow that source. Still, I see that this is a live issue at that [[British Post Office scandal]] article, so it would be wrong to establish a new guideline or issue some sort of MOS talk-page ruling without the knowledge of the other editor; pinging {{u|MapReader}}. [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 14:56, 20 October 2024 (UTC)
*:::Between [[The Savages (Doctor Who)#Broadcast and reception|May 1966]] and [[Survival (Doctor Who)#Broadcast and reception|December 1989]], multi-episode ''Doctor Who'' stories could have titles in any of the four combinations of (i) "Episode ..." or "Part ..."; (ii) numbers as figures or as words. The decision as to which format to use was probably in the hands of the series producer, but in our articles about each story, we give the actual title shown on screen - except that where the on-screen title is all-capitals, we reduce it to title case. Certain ''Doctor Who'' reference books do the same, so we're following the sources. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 18:18, 20 October 2024 (UTC)
*::::The question raised was "differing editorial practices in the British Post Office scandal article". Sounds like a matter of internal consistency, which is different. For all manner of things -- this being one IMO -- we might not need consistency among articles, but it does look bad within articles. Surely we already have a rule addressing that general issue tho? [[User:Herostratus|Herostratus]] ([[User talk:Herostratus|talk]]) 13:24, 21 October 2024 (UTC)
*:::::I think we don't. In articles on TV series it's common to have expressions like "season 3" and "episode 7", which seem to go against our current wording (use words for numbers below 10). [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 16:37, 21 October 2024 (UTC)
*::::::It is indeed a matter of internal consistency and it does look bad, as  [[User:Herostratus|Herostratus]] says. Within the one article ([[British Post Office scandal]]), we have (e.g.) both "Phase 3 hearings" and "Phases five and six". Is there in fact a rule addressing this general issue? -- [[User:Jmc|Jmc]] ([[User talk:Jmc|talk]]) 18:47, 21 October 2024 (UTC)
*::::::From [[Wikipedia:Manual of Style/Dates and numbers#Numbers as figures or words]]: "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." Unless you are dealing only with series with fewer than 10 seasons each with fewer than 10 episodes, it is more in line with MOS to give all season and episode numbers in digits rather than words. --[[User:Khajidha]] ([[User talk:Khajidha|talk]]) ([[Special:Contributions/Khajidha|contributions]]) 13:15, 22 October 2024 (UTC)
*:::::::True, but series with less than ten seasons aren't all that rare, and there are also miniseries with less than ten episodes. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 16:39, 22 October 2024 (UTC)
*:::::::Whether or not it's in line with MOSNUM, we frequently – I suspect in the vast majority of cases – give series/season and episode numbers in digits. I've been dipping into [[Wikipedia:Good articles/Media and drama#Television]]. Articles on individual episodes do routinely begin e.g. " the ninth and final episode of the first season" but with digits in the infobox. Articles on a season/series list episodes using digits, and articles on a show list series/seasons and episodes with digits, regardless of whether there are more or less than ten, in keeping with the examples in [[Wikipedia:Manual of Style/Television#Episode listing]]. Articles are often titled ''&lt;show&gt; season &lt;n&gt;'' where n is a digit, never a word, in accordance with [[Wikipedia:Naming conventions (television)#Season articles]]. Sampling our [[WP:Featured articles#Media]], I see the same treatment in titles, infoboxes, and listings.{{pb}}I very much doubt that editors would accept changes to those FAs and GAs to bring them into line with [[MOS:NUMERAL]], that FA and GA assessors will start to apply [[MOS:NUMERAL]] in such cases, that any move requests would succeed, or that [[MOS:TV]] and [[WP:TVSEASON]] will be brought into line with the current [[MOS:NUMERAL]]. Changing [[MOS:NUMERAL]] might be easier. [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 08:20, 23 October 2024 (UTC)
*::::::::I agree, a small addition to MOS:NUMERAL might be a good thing. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 17:00, 23 October 2024 (UTC)
*:::::::Your final sentence doesn't follow from your statement.  It would be more in keeping with the MOS to give all in words. [[User:MapReader|MapReader]] ([[User talk:MapReader|talk]]) 11:16, 23 October 2024 (UTC)
* Generally concur with EEng and NebY. It's clear that certain conventions adhere strongly to certain things, and these conventions will be readily apparent from the source material about those things. WP is not in a position to impose an artificial WP-invented consistency on them that makes no sense for those familiar with the subject (e.g. referring to "issue number seven" of a comic book or "the three ball" in a game of pool). Where nothing like a consistent convention can be observed for the topic at hand, then MOSNUM already provides us with a default to fall back to: use "one" through "nine", then "10" onward. This is the case with centuries, for example. There is no overwhelming source preference for either "third century BC[E]" or "3rd century BC[E]" in reliable sources. (Books tend to prefer the former, journals use the latter more than books do because journal publishers are more interested in compression/expediency. Scroll through first 10 pages of GScholar resuls [https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=%22third+century+BC%22+OR+%223rd+century+BC%22+OR+%22third+century+BCE%22+OR+%223rd+century+BCE%22&btnG= here] and see how much variance there is, and how frequent the numeral style is compared to "traditional" spelling-out. That said, GScholar searches do include some books as well as journals.) Following our default system, we naturally end up with "third century BC" and "12th century BC". (Of course, our material doesn't perfectly follow this; our editors are human, not robots. Well, mostly.) <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 15:04, 24 November 2024 (UTC)

== μs vs us ==

Which style I should use for micro seconds? Does μs [https://en.wikipedia.org/w/index.php?title=Wikipedia%3AManual_of_Style%2FDates_and_numbers&section=39 relative to] "Do not use precomposed unit symbol characters"? [[User:DungeonLords|DungeonLords]] ([[User talk:DungeonLords|talk]]) 04:44, 30 October 2024 (UTC)

:The 2 characters "μ" and "s" are just fine. The precomposed symbols advice is to guard against particular fonts that combine them into a single character because many software readers for the sight impaired do not know all of these symbols. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 04:53, 30 October 2024 (UTC)
:But do use μ, not "u". The latter was something of an early-Internet halfassed approach, but we have Unicode now. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 15:09, 24 November 2024 (UTC)

== Day, date month format ==

Greetings and felicitations.  I assume that such constructions as "Wednesday, 24 February" are discouraged, but I can't find it in the text or the this page's archives.  (The comma seems unnecessary to me.)  May I please get confirmation or refutation? —[[User:DocWatson42|DocWatson42]] ([[User talk:DocWatson42|talk]]) 04:28, 4 November 2024 (UTC)
*[[MOS:DATEFORMAT]] and [[MOS:BADDATE]] cover the allowed and disallowed formats. Unless the day of the week is ''vitally'' important then we leave it out. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 06:16, 4 November 2024 (UTC)
*:This specifically regards the "[[Hadaka Matsuri]]" article, and its Konomiya Hadaka Matsuri infobox, which includes the days of the week. —[[User:DocWatson42|DocWatson42]] ([[User talk:DocWatson42|talk]]) 07:40, 4 November 2024 (UTC)
*::Ah, the mysterious East. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 08:06, 4 November 2024 (UTC)
*Salutations and hugs and kisses to you too.
**If your question is whether day-of-week should be gratuitously included with dates for no particular reason, the answer is ''No''. That is, if the day-of-week is somehow relevant to the narrative, sure, include it, but otherwise no.
**Assuming we're in some situation where (per the preceding) inclusion of day-of-week is indeed justified, maybe your question is how to append the D.O.W.
***If the date is {{nobr|''February 24''}} or {{nobr|''February 24, 2024''}}, then without doubt the right format is  ''Wednesday, February 24'' or ''Wednesday, February 24, 2024''.
***According to "Elite editing" [https://eliteediting.com/resources/grammar/commas-in-dates] (whoever they may be -- search the text "inverted style" on that page), the corresponding answers for {{nobr|''24 February''}} and {{nobr|''24 February 2024''}} are {{nobr|''Wednesday, 24 February''}} and {{nobr|''Wednesday, 24 February 2024''}}. To me that does seem right -- {{nobr|''Wednesday 24 February 2024''}} (all run together, no commas at all) seems intolerable.
:The question naturally arises as to whether MOS should offer advice on all the above. My answer, as usual, is provisionally ''No'', per [[WP:MOSBLOAT]]. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 08:02, 4 November 2024 (UTC)
::Looking at the article, the date is the 12th day of the Chinese year and the day of the week has no significance. I would remove the day of the week from all those dates in the infobox. For what it's worth, I spent most of the 1990s in Hong Kong/China. Major holidays based on the Chinese calendar treat the day of the week in the same way that we treat the day that Christmas falls on. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 09:18, 4 November 2024 (UTC)
:::Okay—will do.  Thank you both. ^_^ —[[User:DocWatson42|DocWatson42]] ([[User talk:DocWatson42|talk]]) 09:21, 4 November 2024 (UTC)
:The new 18th edition of ''The Chicago Manual of Style'' gives advice about commas in dates in ¶ 6.14. When giving examples they mostly give examples with words after the end of the date so the punctuation at the end of the date is illustrated. Some examples:
:*The hearing was scheduled for 2:30 p.m. on Friday, August 9, 2024.
:*Monday, May 5, was a holiday; Tuesday the 6th was not.
:[[User:Jc3s5h|Jc3s5h]] ([[User talk:Jc3s5h|talk]]) 16:56, 4 November 2024 (UTC)
:Concur with EEng on avoiding adding a rule about this, as more [[WP:MOSBLOAT]]. It's just a matter of basic writing sense, basic comma usage in competent English. Our MoS's purpose is not that of ''CMoS'' or ''Fowler's'', trying to answer every imaginable usage question. Just those that have an impact on reader comprehensibility and/or recurrent editorial strife. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 15:18, 24 November 2024 (UTC)

==Spacing with percentage points==
A question regarding spacing of percentage point (pp) usage. I have always assumed there is no space between the number and pp (e.g. 5.5pp not 5.5 pp), on the basis that you wouldn't put a space between a number and a percentage sign (5% not 5 %). There is no reference to this in the MOS, but the [[percentage point]] article uses it unspaced. It might be good to have it clarified in the MOS as I see regular changes adding spacing, which I am not sure is correct. Cheers, [[User:Number 57|<span style="color: orange;">Number</span>]] [[User talk:Number 57|<span style="color: green;">5</span>]][[Special:Contributions/Number 57|<span style="color: blue;">7</span>]] 23:49, 5 November 2024 (UTC)
*[[MOS:PERCENT]] says "omit space". <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 23:54, 5 November 2024 (UTC)
*:Perhaps I am missing something, but as far as I can see, it says to omit space when using the percentage symbol (%) but nothing about when using pp? [[User:Number 57|<span style="color: orange;">Number</span>]] [[User talk:Number 57|<span style="color: green;">5</span>]][[Special:Contributions/Number 57|<span style="color: blue;">7</span>]] 00:21, 6 November 2024 (UTC)
*::Apologies, I missed the "point" word in your question. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 01:49, 6 November 2024 (UTC)
*% is essentially a constant factor (.01), but ''pp'' is more like a unit so my intuition says it should be spaced. I note that the [[basis point]] article uses a space before ''bp'' (mostly, anyway). I'll be interested to hear what others think. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 18:23, 6 November 2024 (UTC)
*:You've got this back to front. Percent (%) is a standard unit symbol and should be spaced, whereas pp is a made up abbreviation, meaning you can put it anywhere you want, space or unspaced. I know MOSNUM says otherwise, which is WP's prerogative. In other words, if we need a  rule, let's make one up and apply it, but there's no logic involved. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 21:06, 6 November 2024 (UTC)
*Dondervogel, "Percent (%) is a standard unit symbol and should be spaced". Huh? It's not an ISO unit symbol, is it. No spacing in English, unlike French. On pp, I agree with EEng: space it. [[User:Tony1|<b style="color:darkgreen">Tony</b>]] [[User talk:Tony1|<span style="color:darkgreen">(talk)</span>]] 11:10, 8 November 2024 (UTC)
*::Absolutely. When it comes to peepee, always space it [https://www.youtube.com/watch?app=desktop&v=RPv2ffwAuGU#t=3m13s]. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 21:36, 8 November 2024 (UTC)
*:Yes, "%" is an ISO standard unit symbol. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 12:45, 8 November 2024 (UTC)
*::What is it the unit of? [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 13:14, 8 November 2024 (UTC)
*:::Nothing. It's a [[dimensionless quantity]]. To the original q: I don't see "pp" used often, in fact rarely. It's probably better written out in full on first use, and if there are subsequent uses, follow the guidance at [[MOS:ACRO1STUSE]]. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 19:58, 8 November 2024 (UTC)
*::::It's used widely in election infoboxes where there isn't space to write it out. [[User:Number 57|<span style="color: orange;">Number</span>]] [[User talk:Number 57|<span style="color: green;">5</span>]][[Special:Contributions/Number 57|<span style="color: blue;">7</span>]] 22:25, 8 November 2024 (UTC)
*:::I will answer Gawaon's valid question in two parts. The first part is a quotation from ISO 80000-1:2009 (emphasis added)
*:::*In some cases, per cent, symbol %, where 1 % := 0,01, is used as a submultiple of the coherent unit one.
*:::*EXAMPLE 4 
*:::*reflection factor, r = 83 % = 0,83
*:::*Also, per mil (or per mille), symbol ‰, where 1 ‰ := 0,001, is used as a submultiple of the coherent unit one.Since the units “per cent” and “per mil” are numbers, it is meaningless to speak about, for example, percentage by mass or percentage by volume. Additional information, such as % (m/m) or % (V/V) shall therefore not be attached to '''the unit symbol %'''. See also 7.2. The preferred way of expressing, for example, a mass fraction is “the mass fraction of B is w B = 0,78” or “the mass fraction of B is wB = 78 %”. Furthermore, the term “percentage” shall not be used in a quantity name, because it is misleading. If a mass fraction is 0,78 = 78 %, is the percentage then 78 or 78 % = 0,78? Instead, the unambiguous term “fraction” shall be used. Mass and volume fractions can also be expressed in units such as µg/g = 10-6 or ml/m3 = 10-9.
*:::Notice the deliberate space between numerical value (e.g., 83) and unit symbol (%). [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 22:10, 8 November 2024 (UTC)
*:::The second part is a partial retraction, quoting from ISO 80000-1:2022, which supersedes the 2009 document:
*:::* If the quantity to be expressed is a sum or a difference of quantities, then either parentheses shall be used to combine the numerical values, placing the common unit symbol after the complete numerical value, or the expression shall be written as the sum or difference of expressions for the quantities.
*:::*EXAMPLE 1
*:::*l = 12 m - 7 m = (12 - 7) m = 5 m, not 12 - 7 m
*:::*U = 230 ⋅ (1 + 5 %) V = 230 ⋅ 1,05 V ≈ 242 V, not U = 230 V + 5 % 
*:::The space is still there between numerical value (5) and percentage symbol (%), but I could not find an explicit reference to "%" as a unit symbol. I'm unsure how to interpret that change, but I'll report back here if I find further clarification. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 22:16, 8 November 2024 (UTC)
*:::I found this in [https://www.nist.gov/pml/special-publication-811/nist-guide-si-chapter-7-rules-and-style-conventions-expressing-values# NIST Special Publication 811]
*:::*In keeping with Ref. [4: ISO 31-0], this Guide takes the position that it is acceptable to use the internationally recognized symbol % (percent) for the number 0.01 with the SI and thus to express the values of quantities of dimension one (see Sec. 7.14) with its aid. When it is used, a space is left between the symbol % and the number by which it is multiplied [4: ISO 31-0]. Further, in keeping with Sec. 7.6, the symbol % should be used, not the name "percent."
*:::*Example: xB = 0.0025 = 0.25 %     but not: xB = 0.0025 = 0.25% or xB = 0.25 percent
*:::*Note: xB is the quantity symbol for amount-of-substance fraction of B (see Sec. 8.6.2).
*:::*Because the symbol % represents simply a number, it is not meaningful to attach information to it (see Sec. 7.4). One must therefore avoid using phrases such as "percentage by weight," "percentage by mass," "percentage by volume," or "percentage by amount of substance." Similarly, one must avoid writing, for example, "% (m/m)," "% (by weight)," "% (V/V)," "% (by volume)," or "% (mol/mol)." The preferred forms are "the mass fraction is 0.10," or "the mass fraction is 10 %," or "wB = 0.10," or "wB =10 %" (wB is the quantity symbol for mass fraction of B—see Sec. 8.6.10); "the volume fraction is 0.35," or "the volume fraction is 35 %," or " φB = 0.35," or "φB = 35 %" (φB is the quantity symbol for volume fraction of B—see Sec. 8.6.6); and "the amount-of-substance fraction is 0.15," or "the amount-of-substance fraction is 15 %," or "xB = 0.15," or "xB = 15 %." Mass fraction, volume fraction, and amount-of-substance fraction of B may also be expressed as in the following examples: wB = 3 g/kg; φB = 6.7 mL/L; xB = 185 mmol/mol. Such forms are highly recommended (see also Sec. 7.10.3).
*:::*In the same vein, because the symbol % represents simply the number 0.01, it is incorrect to write, for example, "where the resistances R1 and R2 differ by 0.05 %," or "where the resistance R1 exceeds the resistance R2 by 0.05 %." Instead, one should write, for example, "where R1 = R2 (1 + 0.05 %)," or define a quantity Δ via the relation Δ = (R1 - R2) / R2 and write "where Δ = 0.05 %." Alternatively, in certain cases,the word "fractional" or "relative" can be used. For example, it would be acceptable to write "the fractional increase in the resistance of the 10 kΩ reference standard in 2006 was 0.002 %."
*:::As with ISO 80000-1:2022, there is always a space between numerical value (e.g., 35) and the percentage symbol (%), but no mention of % as a unit symbol. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 22:38, 8 November 2024 (UTC)
*:::::{{tq|there is always a space between numerical value (e.g., 35) and the percentage symbol (%)}}{{snd}}Maybe in NIST-world, but not here on Wikipedia (see [[MOS:PERCENT]]), so I don't see how any of that helps us with the issue at hand. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 23:29, 8 November 2024 (UTC)
*::::::I was correcting a misconception that % is not a unit symbol when it is. At least it was until 2022. I find it best not to leave incorrect statements unchallenged or they take on a life of their own. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 00:24, 9 November 2024 (UTC)
*:::::::Um, OK, but you do realize that WP does not follow NIST's advice about spacing it, yes? [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 00:44, 9 November 2024 (UTC)
*::::::::Yep, and I wasn't trying to change that. My contributions have been to
*::::::::*correct a factual error (yours)
*::::::::*respond to questions from Tony and Gawaon
*::::::::I have not weighed in on the main thread regarding percentage points because I don't expect my opinion (based not on NIST's utterings but on the ISO standards on which they are based) to be taken seriously, so why would I waste my e-breath? [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 09:41, 9 November 2024 (UTC)
*It is not conventional to space "%" in English. Nearly no publishers do this, and our MoS doesn't say to do this or incidentally illustrating doing this, so don't do this. "pp" here is a unit abbreviation for ''percentage point'' ("the unit for the arithmetic difference between two percentages)", so space it. % is not a unit abbreviation/symbol, but a quantity symbol, so it's in a different class. It's more like the ~ in "~5&nbsp;ml". That the spelled-out equivalent "approximately", like the spelled out "per[]cent", is spaced apart from the numeral is irrelevant. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 15:24, 24 November 2024 (UTC)

== UNITSYMBOLS (1 × 3 × 6 m): “each number should be followed by a unit name or symbol” ==

[[MOS:UNITSYMBOLS]] currently requires a unit symbol after each value when listing dimensions separated by {{char|×}} (“{{xt|1 m × 3 m × 6 m}}, not {{nobr| {{!xt|1 × 3 × 6 m}}}}”). Could we have a carveout from this rule, and allow editors to use only a final unit when writing for infoboxes, and perhaps other places where space is limited? 

Context: {{tl|Infobox mobile phone}} currently has a preference for listing the dimensions of the product each on a separate line. This, and other parameters, can make the infobox {{em|very}} long. This is especially problematic for pages that cover multiple products or versions of a product; see dimensions in [[Samsung Galaxy S21]] infobox. In order to cut down these infoboxes, we could be using a single line for all three dimensions, but the unit after each value feels unnecessary, and can cause line overflow. 

Prior discussion: [[Wikipedia talk:Manual of Style/Dates and numbers/Archive 145#Repeating units in ranges and dimensions]], where the potential for confusion with actually {{em|multiplying}} values was pointed out. I think this is a minor concern in general, but worth considering in prose, or in contexts where the values could be ambiguous. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">[[User:HTGS|HTGS]]</span>&nbsp;([[User talk:HTGS|talk]])</span> 04:17, 11 November 2024 (UTC)

:Where space is limited, it makes sense to present a single compound unit, equal to the product of the separate units. For the example given, the compound unit symbol would be m<sup>3</sup>. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 12:13, 11 November 2024 (UTC)
::Who ever heard of a phone advertised as 5 cc ? People are more interested in it being wide and tall but very thin. This necessitates stating each individual dimension. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 22:40, 11 November 2024 (UTC)
:::No, what Dvogel means is you'd write that a certain phone measures {{tq|{{nobr|146 x 71.5 x 7.65 mm{{sup|3}}}}}}. Having clarified that, I'm bound to say that that would, of course, confuse 99% of our readers. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 22:47, 11 November 2024 (UTC)
::::Gotcha. As well as confusing most readers, it would also be different to {{tq|{{nobr|1 by 3 by 6 m}}}}, which is allowed. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 23:30, 11 November 2024 (UTC)
:::::To be clear for those playing along at home, while the canonical formuations are {{tq|{{nobr|1 m by 3 m by 6 m}}}} and {{tq|{{nobr|1 m x 3 m x 6 m}}}}, MOS currently makes an exception allowing {{tq|{{nobr|1 by 3 by 6 m}}}} (specifically in the case where all the quantities are in the same unit -- in this case metres), but no corresponding exception allowing {{tq|{{nobr|1 x 3 x 6 m}}}}. While it may offend purists, I really don't see why the exception shouldn't be extended to that last case as well. Thoughts?  [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 23:39, 11 November 2024 (UTC)
::::Thank you for clarifying my intent. And for making me chuckle. LoL
::::For a 3 dimensional object, one can write either 146 mm x 71.5 mm x 7.65 mm or 146 x 71.5 x 7.65 mm<sup>3</sup>.  I agree the former is clearer, but the latter uses less space, which can be a consideration. There is no difference in meaning.
::::I guess one could also write 146 x 71.5 x 7.65 mm, but then we have a length, not a volume. It would be clearer to write that length as 79.86 m. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 23:42, 11 November 2024 (UTC)
:::::{{tq|one could also write {{nobr|146 x 71.5 x 7.65 mm}}, but then we have a length, not a volume}}{{snd}}Formally perhaps, but you could say the pretty much the same about {{nobr| 146 by 71.5 by 7.65 mm}}, and yet we allow it. No one will think that {{nobr|146 x 71.5 x 7.65 mm}} means the length 79.86{{nbsp}}m (i.e. 79860{{nbsp}}mm). In context readers will understand it for what it is. I'd like to hear what others think about my proposal. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 23:56, 11 November 2024 (UTC)
::::::Seconded EEng's proposal - simple and clear. <span style="background:#ff0000;font-family:Times New Roman;">[[User:Mr.choppers|<span style="color:#FDEE00;">'''&nbsp;Mr.choppers&nbsp;&#124;&nbsp;'''</span>]][[User talk:Mr.choppers|<span style="color:#FDEE00;">✎&nbsp;</span>]]</span> 04:36, 14 November 2024 (UTC)
::::::EEng is, of course, correct. At {{tl|convert}} we sometimes are asked how the duplicate mm units can be removed to save space (the trick is to use <code>xx</code> in convert) and we tell them that omitting repeated units is ok if space is limited. May as well make it official. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 05:51, 14 November 2024 (UTC)
:::::::{{tq|EEng is, of course, correct.}}{{snd}}Of course -- [https://en.wikipedia.org/?oldid=1257030023#correct even Dondervogel says so]. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 06:37, 14 November 2024 (UTC)
::::::I also support the proposal. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 05:53, 14 November 2024 (UTC)
::I thought this was a joke and burst out laughing on a train, which got me a weird look from a fellow passenger. Anyhow, I too support allowing the single unit after x symbols per EEng and John. [[User:Toadspike|<span style="color:#21a81e;font-variant: small-caps;font-weight:bold;">'''Toadspike'''</span>]] [[User talk:Toadspike|<span style="color:#21a81e;font-variant: small-caps;font-weight:bold;">[Talk]</span>]] 17:31, 18 November 2024 (UTC)
::: <nowiki>:(</nowiki> <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">[[User:HTGS|HTGS]]</span>&nbsp;([[User talk:HTGS|talk]])</span> 23:34, 18 November 2024 (UTC)
*It's tiresome to have to write (and read) units multiple times when multiplication signs are used. [[User:Tony1|<b style="color:darkgreen">Tony</b>]] [[User talk:Tony1|<span style="color:darkgreen">(talk)</span>]] 09:47, 14 November 2024 (UTC)
* As the person who proposed this in the first place, I too support EEng’s proposal. I will carry on working on the infobox, and leave the written MOS to others. I imagine the purists might be happy if we left some comment or endnote about making sure the measurements are not potentially ambiguous though? 
:And, for anyone who cares, there are already pages where this is in sensible use: [[List of photographic film formats]]. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">[[User:HTGS|HTGS]]</span>&nbsp;([[User talk:HTGS|talk]])</span> 23:34, 18 November 2024 (UTC)

==Do we have to convert inches for wheels?==
I see people adding conversions to mentions of screen sizes and wheel dimensions - is this really necessary? Even in [https://www.reifen.com/de-de/auto/reifen/dimension/15-zoll Germany] or [https://www.evocycles.co.nz/Product/575997/polygon-strattos-s4-disc-white New Zealand], automobile and bike wheels are universally referred to by inches; rim diameters are expressly [https://energy-efficient-products.ec.europa.eu/product-list/tyres/tyres-glance_en#how-to-read-the-tyre-parameters defined in inches in the EU regulations]. To me, adding conversions for these types of dimensions adds unnecessary clutter, harming readability for no return whatsoever. I haven't read the entire MOS today, apologies if I missed a mention of these situations. <span style="background:#ff0000;font-family:Times New Roman;">[[User:Mr.choppers|<span style="color:#FDEE00;">'''&nbsp;Mr.choppers&nbsp;&#124;&nbsp;'''</span>]][[User talk:Mr.choppers|<span style="color:#FDEE00;">✎&nbsp;</span>]]</span> 17:24, 13 November 2024 (UTC)

:It looks like sizing bike wheels in inches is not universal. I see many charts in the I-net such as [https://www.bikelockwiki.com/bike-wheel-sizes/ this] that use both metric and imperial/American units for bike wheels and tires. Whether the convert template handles them correctly is another issue. [[User talk:Donald Albury|Donald Albury]] 17:43, 13 November 2024 (UTC)
:On the matter of wheel sizes, not all are inches. See [[Wikipedia:Village pump (technical)/Archive 210#c-Mr.choppers-20240115212900-Muboshgu-20240115194600|this post]] and my reply. Even for a conventional non-Denovo wheel, the dimensions are a bastard mixture: "195/65 R 15" means a tyre that is 195 mm wide on a 15-inch rim. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 19:10, 13 November 2024 (UTC)
::Yes, there is the Michelin TRX and the Denovo. Just as we wouldn't convert the "195" when we write 195/60 R15, I don't think we ought to convert the diameter either. I would treat all of these tire dimensions as one would nominal measurements, rather than inserting unnecessary templates. Bicycle tires, meanwhile, proved more varied than I was aware of. <span style="background:#ff0000;font-family:Times New Roman;">[[User:Mr.choppers|<span style="color:#FDEE00;">'''&nbsp;Mr.choppers&nbsp;&#124;&nbsp;'''</span>]][[User talk:Mr.choppers|<span style="color:#FDEE00;">✎&nbsp;</span>]]</span> 04:33, 14 November 2024 (UTC)
:::I agree with Mr.Choppers on this subject. I think wheels sizes on cars are a compromise between the USA and the rest of the world. There are metric rims on older vehicles but pretty rare on new vehicles. [[User:Avi8tor|Avi8tor]] ([[User talk:Avi8tor|talk]]) 11:40, 14 November 2024 (UTC)
::::{{ping|Avi8tor}} - I was actually triggered by you converting screen dimensions, but five minutes online showed me that the modern world has indeed begun dropping the use of inches for screens. My gut was wrong. <span style="background:#ff0000;font-family:Times New Roman;">[[User:Mr.choppers|<span style="color:#FDEE00;">'''&nbsp;Mr.choppers&nbsp;&#124;&nbsp;'''</span>]][[User talk:Mr.choppers|<span style="color:#FDEE00;">✎&nbsp;</span>]]</span> 13:36, 14 November 2024 (UTC)
:::::Many people around the planet know only millimetres, so it makes sense to have both. I notice in France the data information on television screen size have it in both inches and millimetres. [[User:Avi8tor|Avi8tor]] ([[User talk:Avi8tor|talk]]) 17:57, 16 November 2024 (UTC)
*I agree with Aviator, who didn't mention that aviation uses "feet" for altitude—needs conversion in my view. [[User:Tony1|<b style="color:darkgreen">Tony</b>]] [[User talk:Tony1|<span style="color:darkgreen">(talk)</span>]] 07:30, 22 November 2024 (UTC)
*:I thought that [[Flight level|"feet" used for altitude]] is not a measure of distance but of pressure, so perhaps it should be converted to pascals first. I'm not saying one should not then convert to metres too - only that the conversion would need some care. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 22:06, 22 December 2024 (UTC)

==RfC Indian numbering conventions==
{{atop
| result = There is consensus to continue using crore and lakhs when appropriate. 

Most participants also generally agreed with SchreiberBike's conditions (or a variant) - '''Always 1) link it on first use, 2) include what it is a measure of (rupees can not be assumed), 3) also include conventional numbering, and 4) allow it only in articles about the subcontinent'''. 

However, this RFC suffered from structural issues that a precise wording isn't agreed on yet. Any changes from status quo should go through a clearer future discussion or RFC on just that.

{{nac}} [[User:Soni|Soni]] ([[User talk:Soni|talk]])  22:02, 24 December 2024 (UTC)
}}
<!-- [[User:DoNotArchiveUntil]] 17:01, 21 December 2024 (UTC) -->{{User:ClueBot III/DoNotArchiveUntil|1734800468}}
I am revisiting an issue that was last brought up 6 years ago [[Wikipedia_talk:Manual_of_Style/Dates_and_numbers/Archive_157#RfC_on_use_of_"crore"|here]] and settled without a strong consensus.

I think we should avoid using Indian numbering conventions unless it is needed for context.  For instance, if we want to list the box office take of an Indian movie, don't use "crore", use "millions". This isn't about disrespecting a culture, it's about using internationally favored notation and unit conventions.  We should use "millions" instead of "crore" for the same reason we favor meters over feet. There is no reason that India-related articles should be an enclave of Indian conventions. People who are not Indian will struggle with these things, it will weaken Wikipedia's role as an information tool for everyone.

This is not the same thing as currency. It is appropriate to list an Indian movie's box office take in rupees.  Providing a US$ conversion is optional, but a good idea since the US dollar is widely used around the world as a reserve currency.  But write it as "millions of rupees", not "crores of rupees". [[User:Kurzon|Kurzon]] ([[User talk:Kurzon|talk]]) 16:38, 16 November 2024 (UTC)
:What's the common usage in english? [[User:GoodDay|GoodDay]] ([[User talk:GoodDay|talk]]) 16:45, 16 November 2024 (UTC)
::I don't think most people in the US understand what "crore" is, and would not recognize it as part of the English language. The online [https://www.merriam-webster.com/dictionary/crore Merriam-Webster dictionary] says it means ten million, specifically, a unit of value equal to ten million rupees or 100 lakhs. I think most people in the US would not even understand that a currency is being mentioned.
::--[[User:Jc3s5h|Jc3s5h]] ([[User talk:Jc3s5h|talk]]) 17:00, 16 November 2024 (UTC)
:::Not just people in the US.  Nobody outside of India can be expected to know what a crore is. [[User:Kurzon|Kurzon]] ([[User talk:Kurzon|talk]]) 17:15, 16 November 2024 (UTC)
:We use meters over feet? Where?
:{{tqb|In non-scientific articles with strong ties to the United States, the primary units are US customary (pounds, miles, feet, inches, etc.)}} [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 17:50, 16 November 2024 (UTC)
::You get extra points for saying "US customary" and not "Imperial". 😉 [[User:Isaac Rabinovitch|Isaac Rabinovitch]] ([[User talk:Isaac Rabinovitch|talk]]) 18:20, 16 November 2024 (UTC)
:::{{smalldiv|1=imperial :3 [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 18:30, 16 November 2024 (UTC)}}
:I agree with [[u|Kurzon]], do not use "crore", use "millions". Wikipedia is for a worldwide audience. [[User:Avi8tor|Avi8tor]] ([[User talk:Avi8tor|talk]]) 18:03, 16 November 2024 (UTC)
::Kinda like how US units are used for US articles, I don't see the harm in using "crore", and it's way more work to manually convert to millions every time a member of India's vast diaspora in the Global North adds "crore" to an article, not knowing our ManualOfStyle. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 18:19, 16 November 2024 (UTC)
:Except we don't favor meters over feet — we use both. That's what the [[Template:Convert|Convert template]] is for. 
:Speaking as a non-Indian, who can never remember what how many is a "crore": I'm fine with it, as long as the [[Template:Crore|international unit is also used]]. [[User:Isaac Rabinovitch|Isaac Rabinovitch]] ([[User talk:Isaac Rabinovitch|talk]]) 18:18, 16 November 2024 (UTC)
:We already make an exception for [[foot (unit)|feet]]. I see no good reason for barring a second exception. State in [[crore]] and convert to a unit non-Indians can understand (millions of [[rupee]]s?). [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 20:48, 16 November 2024 (UTC)
The article for the French movie ''[[Les Visiteurs]]'' lists the budget as "9.5 million", using a point as a decimal separator. In France they use commas for this, ie "9,5 million". We don't use the French notation convention for France-related articles. [[User:Kurzon|Kurzon]] ([[User talk:Kurzon|talk]]) 17:14, 16 November 2024 (UTC)
:Is it the French style to use that notation in English? A different unit elicits way less confusion than a reversed decimal separator meaning anyways. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 17:50, 16 November 2024 (UTC)
*'''Bad RFC'''; see [[WP:RFCNEUTRAL]] and the rest of the guidance there too.  Unsurprisingly, this has just started out as a disorganized discussion that doesn't resemble a normal RFC...you might want to just remove the tag, get some feedback, and then start a proper one in a bit (separate subsections for discussion and survey are pretty helpful too). [[Special:Contributions/35.139.154.158|35.139.154.158]] ([[User talk:35.139.154.158|talk]]) 18:21, 16 November 2024 (UTC)
*:{{replyto|Kurzon}} I did {{diff|Wikipedia talk:Manual of Style|prev|1257781055|advise you}} not to jump straight for a full-blown thirty-day formal RfC without first exhausting the suggestions at [[WP:RFCBEFORE]]. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 18:39, 16 November 2024 (UTC)
:This RfC is clearly improperly formatted, [[User:Kurzon|Kurzon]]; thank you to our unregistered friend for pointing this out.
::Oh come now. It seems to be developing nicely, I doubt that any editors are swayed by the wording. it's not perfect but perfect is the enemy of good and its good enough. [[User:Herostratus|Herostratus]] ([[User talk:Herostratus|talk]]) 04:47, 29 November 2024 (UTC)
:::That reply was before the appropriate discussion centers were notified and before discussion started to develop. It's not just formatting; it's that there was no prior discussion. Now we're effectively having both at the same time, especially when an informal discussion could've resulted in consensus without a time-consuming process. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 16:08, 29 November 2024 (UTC)
:Consistency and clarity to our international readership are valid arguments in favor of prohibiting "crore" and "lakh". However, Aaron Liu makes good points about the fact that we allow local variation in articles with local ties, e.g. all of [[WP:ENGVAR|ENGVAR]]. I am unsure where I sit on this issue. I would like to see some Indian editors weigh in on this. [[User:Toadspike|<span style="color:#21a81e;font-variant: small-caps;font-weight:bold;">'''Toadspike'''</span>]] [[User talk:Toadspike|<span style="color:#21a81e;font-variant: small-caps;font-weight:bold;">[Talk]</span>]] 19:58, 16 November 2024 (UTC)
::I also agree that crores are too obscure (as are lakhs), with use limited to South Asia. Feet and inches, while retrograde and infinitely useless, were used across most of the world not many generations ago. The major unit in Japanese is 万 (man), which is 10,000, but we do not use that because most people wouldn't know it. Engvar is somewhat different: we cannot avoid choosing between "colour" and "color", for instance, whereas we can easily write the globally recognized "millions" rather than crores. As for [[User:Aaron Liu]]'s comment: if someone adds crore, it will be there until fixed – it's not pressing enough of a problem to hunt down every instance. <span style="background:#ff0000;font-family:Times New Roman;">[[User:Mr.choppers|<span style="color:#FDEE00;">'''&nbsp;Mr.choppers&nbsp;&#124;&nbsp;'''</span>]][[User talk:Mr.choppers|<span style="color:#FDEE00;">✎&nbsp;</span>]]</span> 20:03, 16 November 2024 (UTC)
:::Good point about 万 – I completely forgot that Chinese has similarly different units. I think that settles it – either we allow crore and lakh alongside the [[万|East Asian 万 and 亿]] (which I think is ridiculous) and an infinite variety of customary units, or we allow none. 
:::(Two counterarguments: 1. This is a [[slippery slope]] argument, which is a logical fallacy. To which I say no, we can't give only one country special treatment, we ought to be fair. 2. The East Asian units are non-Latin characters and thus more impractical than "crore". This is true.) [[User:Toadspike|<span style="color:#21a81e;font-variant: small-caps;font-weight:bold;">'''Toadspike'''</span>]] [[User talk:Toadspike|<span style="color:#21a81e;font-variant: small-caps;font-weight:bold;">[Talk]</span>]] 20:15, 16 November 2024 (UTC)
:::On the subject of the myriad, I agree with Toads's second counterargument: there is no widely-recognized English translation for the unit in some "East Asian variant" of English; they just convert it to [[short scale]] in translations.{{tqb|we cannot avoid choosing between "colour" and "color", for instance, whereas we can easily write the globally recognized "millions" rather than crores.}}Part of my argument is that "crore" vs long scale is basically the same thing as "colour" vs "color": anonymous editors are going to add them. A ton. Expecting people to not use crore is like expecting people to not spell "colour". It's not pressing enough to hunt down, sure, but you're going to see sweet summer children adding crore into crore-free articles again and again and again. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 01:14, 17 November 2024 (UTC)
::By the way, I've left a (neutrally-worded) note about this discussion at the Talk page of WikiProject India. [[User:Toadspike|<span style="color:#21a81e;font-variant: small-caps;font-weight:bold;">'''Toadspike'''</span>]] [[User talk:Toadspike|<span style="color:#21a81e;font-variant: small-caps;font-weight:bold;">[Talk]</span>]] 20:16, 16 November 2024 (UTC)
*'''Don't allow crore.''' In the interest of making articles understandable to a wider audience, we already do this for the decimal marker (.) and separator for groups of 3 digits (,) as previously mentioned. We also [[Wikipedia:Manual of Style/Dates and numbers#Other numbers|require the use of short-scale]] even though long-scale hasn't entirely died out in the British Isles. [[User:Jc3s5h|Jc3s5h]] ([[User talk:Jc3s5h|talk]]) 21:16, 16 November 2024 (UTC)
*:The decimal marker and long/short scale have a much better reason for their ban: The symbols they use have very different meanings outside of their local context, while crore, lakh, etc. do not. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 01:04, 17 November 2024 (UTC)
*'''Don't allow crore''' Per [[WP:COMMONALITY]]. This is not comparable with US v metric units where we report both - that is just a case of which is primarily reported. Furthermore, imperial units have a relatively recent historical usage across English. It is not like other issues of ENGVAR such as colour v color or ise v ize that do not affect understanding. {{tq|For an international encyclopedia, using vocabulary common to all varieties of English is preferable}} - to the point of being paramount. [[User:Cinderella157|Cinderella157]] ([[User talk:Cinderella157|talk]]) 22:38, 16 November 2024 (UTC)
*'''Allow''' ''crore'', ''lakh'' and [[Indian numbering system]], '''but always''', 1) link it on first use, 2) include what it is a measure of (rupees can not be assumed), 3) also include conventional numbering, and 4) allow it only in articles about the subcontinent.&nbsp;[[User:SchreiberBike|SchreiberBike&nbsp;]]&#124;[[User talk:SchreiberBike#top|&nbsp;⌨&nbsp;]] 23:13, 16 November 2024 (UTC)
*:I agree with all of these conditions. While I remain somewhat ambivalent on the use of “crore” in general, we must provide enough context for non-Indian readers to understand them. [[User:Toadspike|<span style="color:#21a81e;font-variant: small-caps;font-weight:bold;">'''Toadspike'''</span>]] [[User talk:Toadspike|<span style="color:#21a81e;font-variant: small-caps;font-weight:bold;">[Talk]</span>]] 13:56, 17 November 2024 (UTC)
*'''Allow''' ''crore'', ''lakh'' per [[User:SchreiberBike|SchreiberBike]], and with the same caveats. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 00:03, 17 November 2024 (UTC)
*'''Allow ScreiberBike''', per my comments above. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 01:20, 17 November 2024 (UTC)
* '''Allow ScreiberBike'''. But see also [[Wikipedia:Manual of Style/India-related articles#Basic_India_conventions]] - "You may use the Indian numbering system of lakhs and crores ''but should give their equivalents in millions/billions in parentheses''" <!-- Template:Unsigned --><small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Asteramellus|Asteramellus]] ([[User talk:Asteramellus#top|talk]] • [[Special:Contributions/Asteramellus|contribs]]) 00:30, 18 November 2024 (UTC)</small>
* '''Allow''' ''crore'', ''lakh'' and [[Indian numbering system]], '''but always''', 1) link it upon first use <u>in every section where it appears</u>, 2) include what it is a measure of (rupees can not be assumed), 3) also include conventional numbering <u>using template {{tl|convert}}—i.e., don't convert yourself</u>, and 4) allow it only in articles about the subcontinent. [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:11, 18 November 2024 (UTC)
*: Hm; was very surprised to notice that the {{tl|convert}} template does not currently support lakhs and crores. I think it should, and started [[Module talk:Convert#Indian numbering system: lakhs and crores|a discussion]] about that. If you wish to comment, please go to [[Module talk:Convert#Indian numbering system: lakhs and crores]]. Thanks, [[User:Mathglot|Mathglot]] ([[User talk:Mathglot|talk]]) 23:50, 18 November 2024 (UTC)
*::The convert template converts units, like feet and metres. Crores and lakhs are not units, but multipliers. It would be like convert being used to convert between hundreds, thousands, millions etc. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 22:52, 19 November 2024 (UTC)
*:::The {{tlx|lakh}} and {{tlx|crore}} templates make more sense than overloading {{tlx|convert}}. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 23:02, 19 November 2024 (UTC)
*:I agree with SchreiberBike and others; "crores" and "lakhs" can always be used to add colour/color to an article as long as those requirements are met. <span style="background:#ff0000;font-family:Times New Roman;">[[User:Mr.choppers|<span style="color:#FDEE00;">'''&nbsp;Mr.choppers&nbsp;&#124;&nbsp;'''</span>]][[User talk:Mr.choppers|<span style="color:#FDEE00;">✎&nbsp;</span>]]</span> 04:50, 20 November 2024 (UTC)
*'''Do not allow'''. This is not the same as variations of English in wide use where there are multiple widespread usages (color or colour). While SchreiberBike's conditions for use are reasonable, I would say that the standard international measurements should always be primary and subcontinent-specific numbering as a secondary only in articles about the subcontinent. [[User:Avgeekamfot|Avgeekamfot]] ([[User talk:Avgeekamfot|talk]]) 09:50, 20 November 2024 (UTC)
*:What does "widespread" mean? [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 12:17, 20 November 2024 (UTC)
{{block indent|em=1.6|1=<small>Notified: [[Wikipedia talk:Manual of Style/India-related articles]]. [[User:Jlwoodwa|jlwoodwa]] ([[User talk:Jlwoodwa|talk]]) 01:04, 21 November 2024 (UTC)</small>}}<!-- Template:Notified -->
*'''Allow, but always ...''' exactly as Mathglot laid out above (other than, per Stepho-wrs and Redrose64, {{tnull|convert}} isn't actually the right template, or at least isn't presently). I would add a further caveat that these traditional Indic units (technically, multipliers) should be given secondarily not primarily, but I could live without that. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 11:55, 21 November 2024 (UTC)
*'''Allow''' when appropriate, under conditions set out by ScreiberBike. Also, this RfC does not meet [[WP:RFCNEUTRAL]]. [[User:ThatIPEditor|ThatIPEditor]] <sup>[[User talk:ThatIPEditor|Talk]] · [[Special:contribs/ThatIPEditor|Contribs]]</sup> 02:18, 22 November 2024 (UTC)
*'''Do not allow''' crore et al. It's not only native English-speakers who haven't a clue what it means when reading India-related articles; it's non-natives too. [[User:Tony1|<b style="color:darkgreen">Tony</b>]] [[User talk:Tony1|<span style="color:darkgreen">(talk)</span>]] 07:32, 22 November 2024 (UTC)
*:I don't get what native/non-native speakers have to do with the issue. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 12:21, 22 November 2024 (UTC)
* '''Allow per ScreiberBike''' for South Asian articles. [[User:Johnbod|Johnbod]] ([[User talk:Johnbod|talk]]) 17:29, 22 November 2024 (UTC)
*'''Allow''' All Indian academic/professional textbooks and all Indian reliable sources, with few exceptions for specific conditions, use lakhs/crores when denoting INR and millions/billions when denoting foreign currencies. Not allowing is not an option, unless editors want to disregard Indian readers. Using X million rupees is almost as uncommon in India as using Y lakh dollars. My suggestion -- for articles that use {{tl|Use Indian English}} force editors to '''1) link it on first use, 2) include what it is a measure of (rupees can not be assumed)''' with Indian comma separator at 00 after thousands and for articles that don't use that template force editors to '''always''' use millions/billions with 000 comma separator. — [[User:Hako9|hako9]] ([[User talk:Hako9|talk]]) 03:01, 23 November 2024 (UTC)
*:'''Strongly disallow''' use of Indian comma separator. That would only serve to confuse. We don't permit a French comma separator on English Wikipedia. The Indian comma would be much worse. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 09:11, 23 November 2024 (UTC)
*:I concur entirely with Dongervogel_2 on this side-point; we cannot mix-and-match numeric separator styles. We've repeatedly had debates in the past about permitting "," instead of "." as a decimal point to suit the preference of some subset of readers, and the answer is always firmly "no", so this isn't going to be any different. I'm not a professional researcher in this area, but I have looked into the matter in the course of various style debates, and the evidence clearly shows Indian publications using "Western" number formatting systems (or whatever you want to call them) on a regular basis, though often alongside the Indic {{lang|hi-Latn|krore}}, etc., system. That is, it's just not plausible that English-using readers in/from India have any difficulty understanding our numeric material, especially after the rise of the Internet has exposed them to content from all over the world since the mid-1990s and pretty much ubiquitously since the early 2010 with the rise of mobile data. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 14:49, 24 November 2024 (UTC)
*::{{tq | “it's just not plausible that English-using readers in/from India have any difficulty understanding our numeric material …”}} Of course the same could be said of American readers and the spelling of ‘colour’. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">[[User:HTGS|HTGS]]</span>&nbsp;([[User talk:HTGS|talk]])</span> 17:41, 28 November 2024 (UTC)
*:::What isn't the same is how many editors will add "colour" into articles while most wouldn't add numbers in the Indian system. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 18:30, 28 November 2024 (UTC)
*::::I’m genuinely not sure what your point is? Editors are more likely to (erroneously) change spelling to ‘colour’, so that gives them more grounds for the MOS giving them parity with American English? I know we should be realistic about what we can control, but I don’t love that logic. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">[[User:HTGS|HTGS]]</span>&nbsp;([[User talk:HTGS|talk]])</span> 03:18, 29 November 2024 (UTC)
*:::::Yes, that or add spelling that says "colour" is what I'm saying. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 04:03, 29 November 2024 (UTC)
*:::::Like I would campaign for navboxes to be placed in the "see also" section if it weren't so widespread and unduly investative to correct. The corrections for disallowing crore are the same thing to me. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 04:11, 29 November 2024 (UTC)
*:::On this attempt at a ''colo[u]r'' [[false analogy]]: "What isn't the same" even more pertinently is that the cases aren't parallel in any way. ''Crore'' and ''lakh'' are not barely noticeable spelling differences of an everyday word used the same way in every single dialect of English; they're a radically different system of approaching large-ish numbers. There is no audience capable of reading en.wikipedia for whom either ''colour'' or ''color'' is impenetrable. If HTGS's pseudo-analogy is intended to suggest that ENGVAR should be undone on the same basis that we would rejecte or further restrain use of ''crore'' and ''lakh'', that doesn't work since they're not actually analogous at all, plus the fact that not a single element of MoS is more dear to the community than ENGVAR; it is never, ever going away.  If HTGS isn't actually suggesting we get rid of ENGVAR but is instead trying to suggest that opposition to ''crore'' is pretty much the same as advocating the death of ENGVAR, that's not cogent either, for the same false-analogy reason plus scoops of [[slippery slope]], [[overgeneralization]], and [[argument to emotion]] fallacies plopped on top. Aaron Liu's original "what isn't the same" point is that most editors will use ''color'' or ''colour'' as contextually appropriate in our content, yet very few will ever add ''lakh'' or ''crore'' to an Indic-connected article. That could be argued to be suggestive of a {{lang|la|de facto}} community consensus already existing against those units' use at en.wikipedia. While it's worth considering, it's clouded by [[WP:SYSTEMICBIAS]] in that a comparatively small percentage of our editors are from India or its immediate environs, so the statistics are probably not usefully comparable even if they could be gathered with certainty. I would suggest that the reasons to rarely use ''crore/lakh'' and to always convert when used at all, has to do with end-reader comprehensibility, not with editor preference or usage rates. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 12:54, 23 December 2024 (UTC)
*::Because, the fact is, we aren’t using varieties of English solely to ensure accuracy or intelligibility. They are also being used to avoid recreating the Anglo-American hegemony that exists in published English, and to foster a connection in the community with the most interest in the subject. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">[[User:HTGS|HTGS]]</span>&nbsp;([[User talk:HTGS|talk]])</span> 18:05, 28 November 2024 (UTC)
*:::This is not MakeLocalsAsHappyAsPossiblePedia or EngageInCrossCulturalFeelGoodBackscratchingPedia or RightGreatWrongsPedia. It may be unfortunate in some sense that a "Western" (now globally internationalized) enumeration system dominates nearly everywhere (with arguably more benefits than costs), but it is a fact. And it has nothing to do with "Anglo-American" anything, being the same system used by the French and the Russians and the Japanese and so on, and predating both America and England and even the English language, going back to ancient Eurasia very broadly, from the Rome to China. (There's an incidental British correlation of course: it was largely the English, along with the Dutch, who pushed this system in India. That makes it socio-politically and emotively connected to India–UK and Indian–Western relations, but it is not an Anglic counting system and we are not to be confused by sentiment.) More to the point, the "job" of this site is to communicate clearly with as many English-competent readers as possible. The simple fact is that virtually no one outside of the Subcontinent and nearby islands (plus first-generation emigrées therefrom), think in or even understand ''lakh'' and ''crore''; meanwhile pretty much everyone in India and thereabouts {{em|also}} understands millions, and hundreds of thousands, even if it is not their immediate mental model and they have to convert a bit in their heads, like Americans with metric units. There is no [[bothsides-ism]] to be had here; the sides are not equivalent. Finally, it is not the goal of our articles on Indic culture, history, geography, economics, etc., to appeal to and primarily serve the interests of people in South Asia, but {{em|everyone}}. For this reason, I'm supportive of retaining the permissibility of ''crore'' and ''lakh'' in relevant articles as long as they are always converted into the now globally prevalent enumeration system, and usually with that first unless there's an important contextual reason to use ''lakh/crore'' first. Best of both worlds: everyone gets to understand the material, and Indic numbering is not deleted.  It's pretty much the same situation as American customary ("imperial") units of measurement: most of the world doesn't use or understand them, but we should not ban them, just always convert them to metric. (The only difference I can see is "wiki-political": our American editorial and read bases are so large that it would be very difficult to get consensus to always put American units second after metric even in articles about American subjects. That really {{em|should}} be the rule, but it'll be hard to get there.) <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 12:54, 23 December 2024 (UTC)
*'''Do not allow crore''' - I am not convinced that this word is actually English, and this is the English-language wikipedia.  It seems that this is a foreign word that is used ''alongside'' English in areas that have ties to the language this word is from. Even in these areas, it seems that English speakers there fully understand what "millions", "thousands", etc mean, and there have been attestations linked above where they use both, presumably to help English speaking people understand what number is being referred to.  My perspective here is colored by being an American expat living in Japan... in day-to-day speech, I will sometimes mix the languages and say "Oh, this costs 3 man yen."  But I am under no circumstances thinking that "man" meaning "ten thousand" is English.  I'm using another language's word.  That's what it looks like they are doing here. [[User:Fieari|Fieari]] ([[User talk:Fieari|talk]]) 07:01, 28 November 2024 (UTC)
*:As an alternative, I would also accept allowing crore only if the "millions" number is included alongside it. [[User:Fieari|Fieari]] ([[User talk:Fieari|talk]]) 07:28, 28 November 2024 (UTC)
*:"Gumption" is borrowed from Scots; it is English. "Chutzpah" is borrowed from Yiddish; it is English. "Powwow" is borrowed from East-American indigenous language; it is English. "Crore" is borrowed from Hindustani; it is [[Indian English]]. All of the above are attested by dictionaries, while "man" to mean myriads is not. [[User:Aaron Liu|<span class="skin-invert" style="color:#0645ad">Aaron Liu</span>]] ([[User talk:Aaron Liu#top|talk]]) 18:28, 28 November 2024 (UTC)
*'''Allow crore''' - my gut feeling is to disallow it because it is not English as understood by the majority of English readers (including native speakers from UK/US/Australia/etc and second language speakers from China/S.America/Europe/etc). However, crore and lakh are words that Indians practically think in even when speaking English. We have a similar problem where an article is marked as British English and has 99 occurrences of "litre" - an American will still add new stuff with "liter" because it is so naturally to them. In the same way, we will be pushing it up hill trying to get them to stop. So, we should let them use it in articles related to the Indian region but never on anything outside that region. Each first usage should link to [[crore]] and [[lakh]] so that the few non-Indian region readers have a clue what's going on. I would not bother with conversion to millions - once you learn that they are just putting 0's at the end it becomes easy enough in a short time and conversions just clutter up the article. But do not allow grouping like 1,00,000 under any circumstances.<span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 02:41, 29 November 2024 (UTC)
*'''Don't allow crore'''. If there are people who don't know what "million" is, well some level of literacy is required here, yes. As to "link on first use", no, links are supposed to be "here's some extra/more detailed info about the subject if you want" not "you need to interrupt the flow of your reading and go off the page to understand this word". [[User:Herostratus|Herostratus]] ([[User talk:Herostratus|talk]]) 04:57, 29 November 2024 (UTC)
*:Actually that's exactly what links are for. Readers who know the general topic well can just read an article straight forwardly. But readers new to the general topic are likely to come across words they don't know yet and can follow the links to learn. Eg, in car articles we often talk about the [[camshaft]]. If you are new to the detailed study of cars then you can follow that link and then return later. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 06:09, 29 November 2024 (UTC)
*:And if anybody thinks that a politely worded MOS rule will stop them adding crore and lakh then consider that at https://en.wikipedia.org/w/index.php?title=Nissan&diff=1256595427&oldid=1256557060 somebody added a MDY style date in spite of the article having 186 references in DMY style. I fix these (in both directions) practically daily. People do whatever comes natural and do not consider that any other way even exists.
*: But I do feel a little better after my vent :) <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 11:35, 29 November 2024 (UTC)
*::{{+1}} and it’s worth reiterating that most advocates here are suggesting that the Indic value should always be “translated” into a Western value in parentheses, so most naïve readers would still be able to parse the article without following the link. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">[[User:HTGS|HTGS]]</span>&nbsp;([[User talk:HTGS|talk]])</span> 06:21, 29 November 2024 (UTC)
*'''Do not allow crore'''—India-related articles are for international readership. No one outside the subcontinent is familiar with ''crore''. It is a disservice to readers to allow it. [[User:Tony1|<b style="color:darkgreen">Tony</b>]] [[User talk:Tony1|<span style="color:darkgreen">(talk)</span>]] 06:24, 29 November 2024 (UTC)
*:If they are not familiar with crore they can read the conversion to millions. And if they also want to learn about [[crore]] they can click on the link. I see no disservice. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 12:49, 29 November 2024 (UTC)
*:Perhaps some are not aware but English Wikipedia is heavily used in India. The [[Wikipedia:Top 50 Report|Top 50 Report]] from 2023 had five items about Indian movies and movie stars. The latest week's most viewed [[Wikipedia:Top 25 Report|Top 25]] had [[2024 Maharashtra Legislative Assembly election]] and ''[[Kanguva]]''. According to [[Indian English]] there are 128 million English speakers there. If we say to basically never use ''crore'' and ''lakh'', we are sending a discouraging, even insulting, message to many of our readers and editors.&nbsp;[[User:SchreiberBike|SchreiberBike&nbsp;]]&#124;[[User talk:SchreiberBike#top|&nbsp;⌨&nbsp;]] 13:51, 29 November 2024 (UTC)
* '''Allow''' in articles with strong ties to India, provided that the conversion is shown at first use. Hey, we could even write {{tq|In non-scientific articles with strong ties to <s>the United States</s> India, the primary <s>units are US customary (pounds, miles, feet, inches, etc.)</s> multipliers are Crore and Lakh}}. See [[sauce for the goose]]. Also, it is very relevant that a huge fraction of en.wiki readers are Indian. "ccording to a 2011 census, 10.2% of the Indian population speaks English. This figure includes all Indians who speak English as a first, second, or third language. 10% of India's population is approximately 145 million people." Twice as many as in the UK, half as many as in the US.  --[[User:JMF|𝕁𝕄𝔽]] ([[User talk:JMF|talk]]) 11:49, 29 November 2024 (UTC)
*'''Allow''' only with linking and conversion as per Mathglot. The most practical solution for both Indian and non-Indian readers. [[User:Chaotic Enby|<span style="color:#8a7500">Chaotic <span style="color:#9e5cb1">Enby</span></span>]] ([[User talk:Chaotic Enby|talk]] · [[Special:Contributions/Chaotic Enby|contribs]]) 23:41, 8 December 2024 (UTC)
===Discussion===
Maybe this can be solved technologically so that every user sees numbers in the way they are accustomed to? [[User:Alaexis|Alaexis]]<sub>[[User_talk:Alaexis|¿question?]]</sub> 20:43, 8 December 2024 (UTC)
:This could be done for logged in users, but the vast majority of readers are not logged in with an account. Similar solutions have been proposed for date style and variety of English, but they won't work.&nbsp;[[User:SchreiberBike|SchreiberBike&nbsp;]]&#124;[[User talk:SchreiberBike#top|&nbsp;⌨&nbsp;]] 20:50, 8 December 2024 (UTC)
{{abot}}

== Which era? ==
I'm inviting fellow editors to figure out whether [[Religious perspectives on Jesus]] should use BC / AD or BCE / CE. The issue is that the article mixes eras and when I went back to see which was first, I saw it originally used "BC/BCE" and it stayed like that for years. The thread: [[Talk:Religious perspectives on Jesus#BC BCE AD CE]]. Thanks! <!-- Template:Unsigned --><small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Masterhatch|Masterhatch]] ([[User talk:Masterhatch#top|talk]] • [[Special:Contributions/Masterhatch|contribs]]) </small>
:[[MOS:ERA]] applies so status quo ante should apply. (FWIW, Judaism and Islam have religious perspectives on Jesus of Nazareth, so the neutral style seems entirely appropriate.). --[[User:JMF|𝕁𝕄𝔽]] ([[User talk:JMF|talk]]) 00:18, 22 December 2024 (UTC)
::Agreed on the last part. As for the procedural matters, all of our [[MOS:VAR]] principles ultimately default/fallback to the style used in the first non-stub version that used one of the competing styles, if consensus fails. [[MOS:STYLEVAR]] is the general principle, the root rule: Don't change from one acceptable style without a very good reason. If there is or you expect resistance, discuss to establish consensus. If you don't get consensus for your change (i.e., there is consensus against you), it stays the {{lang|la|status quo ante}}. If there's no consensus on which would be better (which is often the case and likely the one in this case), then use the version established earliest.  For particular things covered by [[MOS:DATEVAR]], [[MOS:ERA]], [[MOS:ENGVAR]], [[WP:CITEVAR]], we simply reiterate this principle and process more topically, and these ones also basically resolve to an additional rule: don't change that particular kind of style without establishing consensus first {{em|even if}} you're sure you've got a good reason and don't think there should be resistance.<!-- --><p>The STYLEVAR process actually sometimes (namely when there's clearly no firm consensus in favor of the {{lang|la|status quo ante}}, either) overrides the usual Wikipedia {{lang|la|status quo ante}} principle, which in practice amounts to "fall back to whatever the discussion closer thinks is more or less a pretty long-term {{lang|la|status quo}}". That usually works for a lot of things, but for these "I will win my Holy Style War or die trying" tedious cyclic [[bikeshedding]] typographic disputes, it has proven unworkable, because the dispute lives on and on, simply shifting in stages to: what constitutes a {{lang|la|status quo}}; how long is long enough; whether interruptions in the use of the alleged {{lang|la|status quo}} have reset its tenure; whether this *VAR-imposed consensus discussion was followed when the alleged {{lang|la|status quo}} was imposed; if not, then whether that imposition pre-dated STYLEVAR requiring it; and yadda yadda yadda. There's just no end to it, because it's too often a super-trivial but deeply obsessive PoV-pushing exercise grounded in prescriptivist emotions (mixed sometimes with nationalist, or socio-politically activistic, or my-profession-vs.-yours, etc.). The style-war-ending default of falling back to the first major edit that established one of the competing styles is arbitrary (in both senses), but it is {{em|the end of it}}, and we move on to something more productive.</p><!-- --><p>For this particular article: If "it originally used 'BC/BCE{{'"}} in the original post isn't a typo, and really does mean that the style was mixed from day one, then that's a rare edge case, and JMF's "status quo ante should apply" is probably the only reasonable approach. (Even from an excessively proceduralist viewpoint: If STYLEVAR and its application ERAVAR impose an overriding principle that in this case cannot actually be applied, then the default necessarily must be the normal Wikipedian {{lang|la|status quo ante}} principle, even if for matters like this it tends to lead to re-ignition of the dispute again in short order. Not every solution is perfection.) <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 12:02, 23 December 2024 (UTC)</p>
:::But what would be the status quo ante in this case? Surely you can't mean the mixed BC/BCE style? [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 08:56, 24 December 2024 (UTC)

== Four questions ==

#Can 24-hour clock be used in articles with strong ties to United States (I have seen no US-related articles with 24-hour clock) such as: "The Super Bowl begins at 18:40 ET?
#Can 12-hour clock be used with UTC time?
#How are primary units of an article determined if the article has strong ties to both US and Canada, as Canada-related articles always use metric units first? For example,  [[Great Lakes]] is such an article, and it currently uses imperial units first, but it would be more logical to use metric units first as a Canada-related article. 
#Why mixed units are not used with metric units? Why it is either 1.33 m or 133 cm, but never 1 m 33 cm? --[[User:40bus|40bus]] ([[User talk:40bus|talk]]) 23:04, 21 December 2024 (UTC)
#:I'd add a fifth question: why does Wikipedia not use ISO dates, i.e. yyyy/mm/dd? They are becoming more common internationally. [[User:Skeptic2|Skeptic2]] ([[User talk:Skeptic2|talk]]) 00:02, 22 December 2024 (UTC)
#::# I wouldn't recommend it.
#::# Probably?
#::# That should be decided on a case-by-case basis.
#::# No benefit for the additional visual or semantic complexity; that's part of the appeal of the metric system, right?
#::# English-language sources never use this format, and the English Wikipedia bases its style on that of other English-language media.
#::<span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff">&nbsp;‥&nbsp;</span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 00:58, 22 December 2024 (UTC)
#:::You write "English-language sources never use this format", but this is untrue. ISO date format is widely used in scientific publishing and it is standard in aviation and for machine processing. Have a look at the Wikipedia entry [[List of date formats by country]]. You might be surprised.[[User:Skeptic2|Skeptic2]] ([[User talk:Skeptic2|talk]]) 23:35, 22 December 2024 (UTC)
#::::I personally use ISO format on my devices; if it helps, you can replace "never" with "almost never". <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff">&nbsp;‥&nbsp;</span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 23:36, 22 December 2024 (UTC)
::#[[MOS:TIME]] says 12 and 24 clocks are equally valid. It's just that the majority of native English speakers use 12 hour clocks, so they choose to use 12 hour clocks. If you create an article (or are the first to mention times within an existing article) then you can choose. Don't change an existing article from one to the other. With the possible exception of US Army articles, you may get kick-back from readers not familiar with the MOS. See the [[WP:JUSTDONTLIKEIT]] essay.
::#UTC is an offset. It is a separate question from how you format that time. UTC can be used with either 12 or 24 hour clocks. See [[MOS:TIMEZONE]] but it doesn't actually say much.
::#Primary units are based on ''strong'' ties to a country. If you have multiple countries with a mix of units then you have multiple weak ties and no strong ties. Therefore we default to metric first, as per [[WP:UNITS]]. Only articles with strong ties to the US and UK get to use imperial units first.
::#A major benefit of metric is that we can change from m to cm to mm to km just by shifting the decimal point. Splitting it into 1 m 33 cm makes that harder and is now rarely used in metric countries. It was more common in my country of Australia during the first 20 years after metrication when we copied our old imperial habits but it fell out of favour and we now universally say 133 cm, 1.33 m or 1330 mm as appropriate. Countries using imperial units tend to use split units because it is so hard to convert miles to feet, gallons to ounces, etc in your head.
::#[[ISO 8601]] dates are allowed in limited cases (mostly references and tables where space is limited). It is not used in prose because it is not yet common for native English speakers to use this in their day-to-day lives. Note that any other purely numeric format is strictly disallowed. See [[WP:DATEFORMAT]] <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 01:09, 22 December 2024 (UTC)
::#:(In terms of accuracy in my own answers, 2 out of 5 ain't bad right?) <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff">&nbsp;‥&nbsp;</span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 01:11, 22 December 2024 (UTC)
:::::Being OCD helps 😉 <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 01:58, 22 December 2024 (UTC)
::::::I'm unsure how to medicalize it, but I'm certainly obsessive and compulsive, and it only helps somewhat! <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff">&nbsp;‥&nbsp;</span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 02:00, 22 December 2024 (UTC)
::Answering #2 and #4 only
::*2. No. The clarity of UTC is obtained only with a 24-hour clock.
::*4. You could write 1 m + 33 cm if you want, but why make life so complicated? The plus sign is needed because without it a multiplication is implied (1 m 33 cm = 0.33 m<sup>2</sup>).
::[[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 07:43, 22 December 2024 (UTC)
:::The answer to Q2 will depend at least in part on whether UTC was chosen because it's local time or because it's the international time standard.  It would make no sense to allow the 12-hour clock for events in London between March and October, but ban it for events between October and March. '''''[[User:Kahastok|Kahastok]]'''''&nbsp;<small>''[[User Talk:Kahastok|talk]]''</small> 14:56, 22 December 2024 (UTC)
::::{{rto|Kahastok}} I don't get this reply. The time of an events in London is given according to BST (= UTC+01:00) in summer and according to GMT (= UTC+00:00) in winter{{snd}} normally without either qualification stated unless it is the weekend when the time changes. It the time zone matters (for an internationally televised live event, for example), the time is normally given both ways: in the local and in the international notations. (Or did you not realise that GMT is just another timezone, not a synonym for UTC though often used that way, especially by seafarers.) [[User:JMF|𝕁𝕄𝔽]] ([[User talk:JMF|talk]]) 15:58, 22 December 2024 (UTC)
:::::I don't accept that UTC is always distinct from GMT. Usually there is not enough information about the reasons a particular author used one or the other abbreviation to tell if the author intended a distinction or not. [[User:Jc3s5h|Jc3s5h]] ([[User talk:Jc3s5h|talk]]) 17:15, 22 December 2024 (UTC)
:::::Well OK, if we're going to insist that the sub-second formal discrepancy between GMT and UTC is somehow vitally important (despite all evidence to the contrary) the split hairs do not count in the case of Lisbon, where the local time in the winter is defined as UTC, rather than just being UTC in practice.  Why would we say that a winter event in Lisbon has to use the 24-hour clock, but a summer event does not?
:::::For the record, I don't think I have ever seen a time recorded at {{tq|17:00 GMT (17:00 UTC)}} and I would like to see examples of that usage. '''''[[User:Kahastok|Kahastok]]'''''&nbsp;<small>''[[User Talk:Kahastok|talk]]''</small> 19:48, 22 December 2024 (UTC)
::::::and you never will, because it would be pedantic in the extreme. In fact most timestamps you see anywhere will be just one of (a) not stated, because it is for local use; (b) the local timezone (notation adjusted according to whether or not DST is in operation); (c) a poor third at "front of house" (excepting worldwide online systems like Wikipedia), UTC time. Use of both (b)&(c) at once is very rare, vanishingly so if b=GMT or even BST.
::::::Jc3s5h is certainly correct for use of GMT in almost all sources pre this century and still quite a few recently{{snd}}it will take 50 years to fall out of use as a world standard, I suspect. Perhaps more ... who would think that there are still people who insist on [[chain (unit)]]s? 
::::::Just to be clear, I am not proposing that we introduce an MOS rule mandating any notation. Just clarifying that GMT is not a synonym for UTC. [[User:JMF|𝕁𝕄𝔽]] ([[User talk:JMF|talk]]) 20:25, 22 December 2024 (UTC)
:::::::If you weren't aiming to be {{tq|pedantic in the extreme}}, why bring it up?  And in particular, why claim - specifically in the context of GMT vs UTC - that {{tq|the time is normally given both ways: in the local and in the international notations}} in situations where time zone matters? ''''[[User:Kahastok|Kahastok]]''''&nbsp;<small>''[[User Talk:Kahastok|talk]]''</small> 21:22, 22 December 2024 (UTC) s
::My 2c:
::# Not just English speakers, anybody with an analogue wristwatch display does so. BUT (in the UK at least), train, bus and plane timetables are invariably shown using 24 hour clock notation. Basically, anywhere that it matters, where ambiguity might arise.
::##The application of am and pm to 12:00 noon and midnight seems to be a perennial source of dispute, see [[12-hour clock#Confusion at noon and midnight]]. Good luck with writing an MOS guidance that avoids that minefield.
::# I was about to declare that [[UTC offset]]s never exceeds 12:00 so crisis, what crisis? But I think there is a UTC+13:00 on one of the Pacific islands near the date line? 
::# Stepho, the use of imperial units in the UK is dying out, literally as well as metaphorically since they are preferred by the older generation. Don't be fooled by the rail-fans insistence on [[chain (unit)|chain]]s{{snd}} all UK railway engineering has been done in metric since 1975. So no, [[MOS:RETAIN]] applies to UK articles too. {{midsize|Except articles under the aegis of [[Wikipedia:WikiProject UK Railways]], of course. --[[User:JMF|𝕁𝕄𝔽]] ([[User talk:JMF|talk]]) 15:43, 22 December 2024 (UTC)}}
::# I concur with Stepho's reply.
::# Anybody who puts their boiled egg upside down should be taken out and beheaded immediately! (aka, ask us again in a 100 years time but it is a non-starter right now.)
::Here endeth the lesson. [[User:JMF|𝕁𝕄𝔽]] ([[User talk:JMF|talk]]) 15:40, 22 December 2024 (UTC)
:::You say, {{tq|the use of imperial units in the UK is dying out}}.  Is it therefore your contention that the British (or even just younger British people) all use kilometres really and just put miles on all the road signs to confuse foreigners? '''''[[User:Kahastok|Kahastok]]'''''&nbsp;<small>''[[User Talk:Kahastok|talk]]''</small> 19:48, 22 December 2024 (UTC)
::::Because of the multitude of road signs and therefore the huge cost of moving from miles, that one will likely never change.  In most other fields, however, there has been a progressive move toward using metric measurements in the UK over recent decades. [[User:MapReader|MapReader]] ([[User talk:MapReader|talk]]) 04:05, 23 December 2024 (UTC)
:::::Never mind that other countries that went metric changed our road signs just fine. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 05:09, 23 December 2024 (UTC)
:::::{{@|Dondervogel 2}}, why must UTC be 24 hours? UTC is just a timezone. Technically it is no different any other timezone and the other time zones can use either 12 or 24 hour times as they wish. Of course, UTC is a little special in that it gets used as the "universal" timezone. And when somebody wants to be unambiguous they tend to use 24 hour time. And when they want to be really unambiguous they write it as UTC rather than local. But a lot of that is just convention. They could equally well say 4:00 pm UTC and still be very precise and unambiguous.
:::::Also, why do you need the "+". In the 1970s in Australia (just after metrication) we used to see "1 m 33 cm" a lot. I've never seen anyone think that it was multiplication. It was more likely from the habit of doing "4 ft 7 in". Once we learnt that writing it as 1.33 m or 133 cm made conversion between them trivial (just shift the little dot), we dropped the complication of mixed units. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 05:09, 23 December 2024 (UTC)
::::::*UTC is not a time zone. It's a time standard, and it uses a 24-hour clock.
::::::*In the language of the SI, symbols have special meanings. If you mean addition (as here) you need a "+" sign. In the absence of any other symbol, a space denotes multiplication. Outside the SI you can invent any conventions you want, and Wikipedia sometimes chooses to depart from the SI, via MOSNUM. I don't believe MOSNUM permits this particular departure.
::::::[[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 08:30, 23 December 2024 (UTC)
:Remsense, one reason Wikipedia can't rely on ISO 8601 throughout is that some articles express dates in the [[Julian calendar]], or even the [[Roman calendar]], and ISO 8601 only allows the [[Gregorian calendar]]. ISO 8601 is fine for airline schedules and hotel reservations, but it truly sucks for history. [[User:Jc3s5h|Jc3s5h]] ([[User talk:Jc3s5h|talk]]) 15:13, 22 December 2024 (UTC)
::::If we can't get Americans to switch to DMY, or Brits to switch to MDY, what hope do we have of getting both groups to switch to YMD? --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1f339; ([[User talk:Redrose64|talk]]) 00:03, 23 December 2024 (UTC)
::::: I think the biggest problem with YMD, besides unfamiliarity, is that you frequently want to suppress the Y part when it's understood, and that's harder to do when it's at the start. --[[User:Trovatore|Trovatore]] ([[User talk:Trovatore|talk]]) 00:14, 23 December 2024 (UTC)
:::::I think the UN should enforce use of DMY worldwide on Mondays, Wednesdays and Fridays, MDY on Tuesdays and Thursdays, and of course dedicate the weekends to YMD. <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff">&nbsp;‥&nbsp;</span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 00:20, 23 December 2024 (UTC)
::::::Whaaaaat? Why would we want the least fun format on the {{em|weekend}}? <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 09:02, 23 December 2024 (UTC)
:::::::Year-first encourages us to meditate on the long term while many are less occupied at work. <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff">&nbsp;‥&nbsp;</span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 08:59, 24 December 2024 (UTC)
:My responses to these questions would be:
:# There is no strong tie of "18:40" format to the US, or the UK, or whatever. It's a format used in a variety of military, otherwise-governmental (e.g. transport/transit scheduling), and sometimes scientific and a few other contexts, and that's true inside and outside the US. It's a completely abnormal format outside of those kinds of contexts, and people don't use it on an everyday basis (that I know of; maybe there is some English-using country in which it has been so aggressively imposed that it's become an everyday norm there and people don't know what "3 pm" means any more, but I'm not aware of such a place). MOS:NUM grudgingly permits its use, but 24-hour format verges on "user-hateful" and should be avoided in most circumstances (i.e. where it's not an established norm for the subject in question).
:#*On JMF's side point about "12:00 pm", MoS could easily have a rule about this, just to settle the confusion, which is common among the general populace, but not among reliable sources on time and writing, in which it virtually always corresponds to "12:00" in 24-hour time, with "12:00 am" being "00:00". MoS saying something about it, though, should be to avoid it in favor of "midnight" and "noon", because confusion among everyday people persists. (My city is gradually changing all of its "No Parking 12 AM – 6 AM, Street Cleaning, Tu, Th" signs to "No Parking 12:01 AM – 6:01 AM, Street Cleaning, Tu, Th" because of this factor).
:# Meaningless, confused question. As Stepho-wrs explained, UTC is an offset, not a format. There's a standardized way of writing {{em|the name of}} a UTC time-zone offset, e.g. as "UTC+05:00", but that's not relevant to how times are used or referred to (in various styles) for typical human consumption. Likewise, the Unicode name of "@" is "{{Unichar|0040}}", but this has no implications for use of the symbol or for plain-English references to it; writing "the at-sign" is not an error. When WP puts "3:05 pm, February 3, 2002 (UTC)" in someone's sig to conform to their date settings in the WP "Preferences" panes, that is also not an error.
:#* Stepho-wrs (which surprises me, given the above) wondered why UTC offset names use a +. It's because the offsets run both directions, e.g. "UTC−05:00" is US and Canadian eastern standard time, and rendering the positive ones as "UTC 05:00" or "UTC05:00" would be problematic for humans and automation alike in various ways. The + isn't any more superfluous than the leading 0 on 00–09.
:# A Canada–US squabble over ordering: A) Who cares? We have {{tlx|convert}} for a reason. B) This is a pretty good argument (from Stepho-wrs): "If you have multiple countries with a mix of units then you have multiple weak ties and no strong ties. Therefore we default to metric first, as per [[WP:UNITS]]." B) If that argument were not persuasive, then [[MOS:STYLEVAR]] still already covers this: When there are two competing acceptable styles, do not change from one to the other without an objectively defensible reason. Try to establish consensus on the article's talk page about which should be preferred, if you are convinced a change should happen. [[Iff]] such a consensus cannot be reached, then default to whatever was used in the first post-stub version of the article (same as with ENGVAR disputes, and CITEVAR ones). So, we are not missing any rules.
:# It's "1.33 m" (not "1 m 33 cm") primarily because that is how the metric system is internationally standardized and how it is used in the real world, rather consistently. The two-units version is also less concise, and annoyingly repetitive because of how the units are named. And the system is designed to be decimal from the ground up. Thus Steoph-wrs observation: "Once we learnt that writing it as 1.33 m or 133 cm made conversion between them trivial (just shift the little dot), we dropped the complication of mixed units." It's not WP's role to treat occasionally-attestable but very disused variants away from a near universal system as if they had become norms and must at all costs be permitted. (Much of MoS's role is eliminating unhelpful variation that is confusion or which causes cyclic dispute, even if we settle on something arbitrary; but most of MOS:NUM is not arbitrary but standards-based.) As for US customary (or "imperial" units, never mind the British empire doesn't exist any longer and what's left of it metricated a long time ago), you can find decimal uses of it for various purposes in real-world publications (e.g. "0.35 in"), but it tends to be for special purposes, like establishing margin widths when printing on non-metric paper, and in electronic media when calculation or sorting might be needed. But the typical use of such units is in "3 ft 7 in" form because they are unrelated units, and because the two-unit split format is deeply conventionalized, including in various industries like construction. That's not true of "3 m 7 cm".
:#*I don't buy Dondervogel_2's "multiplication implied" argument. Virtually no one outside of some particular ivory towers (and even then only in specialist material that was explicit about it) would ever interpret any "# unit1 # unit2" construction, in any context, as a multiplication operation. The real world routinely uses formats like this and {{em|never}} means multiplication by it. E.g. look at the fine print on any laptop's or other device's power-brick; you'll likely see back-to-back, undivided measurement-and-unit-symbol pairs, like "12&nbsp;W&nbsp;&nbsp;3.7&nbsp;A".
:# Skeptic2's add-on ISO-dates question: WP doesn't use 2024-12-23 format (except for special purposes) because it is not a norm, anywhere (as an ENGVAR or other geographical or dialect consideration). It's only standardized within specific industries, systems, processes, organizations, and other specialized usage spheres. (I use it very, very frequently in web development and other coding. But it's not something I'd use in a letter or a novel or an op-ed, because it's a format for computers, and for precision and cross-language exchange among engineers and scientists, not a format for everyday communication.) I've never seen one iota of evidence of broad and increasing acceptance of ISO among the general public for daily use, in regular writing (though ability to parse it has likely increased in the last 30 years because of the Internet and the amount of people's exposure to code that uses it). But it does not match anyone but maybe an ultra-nerd's English-language parsing. If you're American, probably (unless you are older and rural) what you think and say aloud to express today's date is "December 23, 2024" or perhaps "December 23rd, 2024". If you're not American, you probably (some Canadians are an exception too) would express it as some variant of "23 December 2024", "23rd December, 2024", or "the 23rd of December, 2024", depending on your age, social background, country of origin, etc. (American yokels often use the last of those; I have relatives in the Deep South who do it habitually.) These correspond closely (between exactly and too-close-to-matter) to MOS:DATE's two "M D, YYYY and "D M YYYY" formats. An ISO date does not. It's very unnatural. It requires the reader (most readers, anyway) to stop and "translate" it in their heads, thinking about which block of numbers means what, and so on. (I've been using ISO dates on a daily basis since around 1990, and I still have to think about it a little, and once in a while get it wrong, especially shortly after transferring from narrative work to coding work.) Worse, many people do not know at all whether that represents YYYY-MM-DD or YYYY-DD-MM; lots of non-geeky non-Americans mistakenly think it's the latter because they are used to D M YYYY order otherwise, and the idea of the month coming before the day is foreign to them, an annoying Americanism. I run into this problem in a great deal of online content.
:<span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 09:02, 23 December 2024 (UTC)
::Official documents in South Africa are YYYY-MM-DD, I personally use it to name bank statements etc. on my computer because they are easier to find. It depends on what you are used to. [[User:Avi8tor|Avi8tor]] ([[User talk:Avi8tor|talk]]) 12:56, 29 December 2024 (UTC)
:::It isn’t however very readable, on articles of prose. [[User:MapReader|MapReader]] ([[User talk:MapReader|talk]]) 18:20, 29 December 2024 (UTC)
::::To reiterate a distinction that's not potentially reducible to cultural acclimation, it's clear that purely numerical formats are less natural in prose. <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff">&nbsp;‥&nbsp;</span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 18:23, 29 December 2024 (UTC)

== Unit formatting ==

Are any of these formats correct?
* a 10-cm blade
* a 10 cm blade
* a 10-cm-long blade
* a 10 cm-long blade
* a ten-cm blade
* a ten-cm long blade

And why numbers are not spelled out before unit symbols, and why unit symbols are used more with metric than imperial units, where unit names are typically written in full? --[[User:40bus|40bus]] ([[User talk:40bus|talk]]) 13:56, 22 December 2024 (UTC)

:In answer to your first question I suggest choosing between "a 10 cm blade" and "a ten-centimetre blade".
:To the second, there is no internationally accepted standard describing symbols for the imperial unit system. Perhaps that is the reason. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 14:05, 22 December 2024 (UTC)
:You can also consult our {{tlx|convert}} template which deals with all these edge cases: {{tlx|convert|10|cm|adj{{=}}on|abbr{{=}}on}} produces {{convert|10|cm|adj=on|abbr=on}}, per [[MOS:UNITSYMBOLS]].
:Also, is there a reason you're not just consulting the MOS directly? It more or less covers your questions so far. <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff">&nbsp;‥&nbsp;</span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 15:07, 22 December 2024 (UTC)
::This is possible to output: {{tlx|convert|10|cm|adj{{=}}on|abbr{{=}}on|spell=in}}, and it produces: {{convert|10|cm|adj=on|abbr=on|spell=in}}. So, why it is not used? And a sixth question, why fractions are not usually used with metric units? Fractions would be useful indicating repeating decimals, such as one-seventh of a meter, as things like "0.142857142857... m" or "0,{{overbar|142857}} m" would look ugly, so {{frac|7}} m would be only option. --[[User:40bus|40bus]] ([[User talk:40bus|talk]]) 23:13, 22 December 2024 (UTC)
:::Do you have a real world example illustrating your concern? [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 23:22, 22 December 2024 (UTC)
:::How would {{frac|1|7}} be the "only option"? You yourself just used the obvious other one: simply writing "one-seventh", which isn't broken in any way, and is probbaly easier to read for most people, than {{frac|1|7}}, which can mess with line height. It actually copy-pastes as <code>1⁄7</code>, with inconsistent display on various systems. The use of the Unicode fraction-slash character is interpreted by some OSes, including my Win11 box (but not my Mac, or any Linux I can remember using), as an instruction to superscript the 1 in nearly unreadably tiny font and do the same to 7 but as a subscript. (Win11 even does this to me in a {{tag|code}} block!) I'm not convinced we should have that template at all, since the Internet has done just fine with <code>1/7</code> for decades. Regarding the other material, Remsense is correct that there's a standard way of abbreviating metric units (and there's also a lot of systemic enforcement of that), but there isn't an entirely standardized approach to other units (perhaps better called "American traditional" at this point), and they are often unabbreviated in the real world. So, despite MoS providing a standard way of abbreviating them (based on ANSI or whatever, I don't remember), there's less editorial habit and desire to bother with it, while editors steeped in metric (everyone but Americans) are habituated to the short symbols. Nothing's really harmful about any of this, with regard to reader comprehension, so we have no need to firmly impose a rigid rule to do it this way or that. (We do have such a rationale for settling on particular American/"Imperial" unit abbreviations, though, since use of conflicting ones from article to article would be confusing for readers and editors alike, and some of them found "in the wild" are ambiguous and conflict with actual standards (e.g. using "m" to mean 'miles' instead of 'metres/meters'). As for the original question, yes it's "a 10 cm blade", and the output of {{tnull|convert}} is MOS:NUM-compliant. A construction like this is taken as an strongly conventionalized exception to the [[MOS:HYPHEN]] rule of hyphenating compound modifiers (writing "a 10 cm-blade" or "a 10-cm-blade" isn't really any clearer, and probably less so). In long form it would be "a ten-centimetre-long blade" and Dondervogel is correct that "-long" would usually be omitted for concision, unless it was necessary to indicate length versus width of something (which isn't the case with a knife or sword or whatnot, but would be with a shipping box). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — [[User:SMcCandlish|'''SMcCandlish''']] [[User talk:SMcCandlish|☏]] [[Special:Contributions/SMcCandlish|¢]] 😼 </span> 07:12, 23 December 2024 (UTC)

== Mixed spelled/figure format ==

How did we come to this guidance? 
:Comparable values near one another should be all spelled out or all in figures, even if one of the numbers would normally be written differently: {{xt|patients' ages were five, seven, and thirty-two}} or {{xt|ages were{{nbsp}}5, 7, and{{nbsp}}32}}, but not {{!xt|ages were {{nobr|five, seven, and 32}}}}.
This goes against the [https://writingexplained.org/ap-style-numbers AP Stylebook] that pretty firmly enforce that the numbers nine and below should be spelled out, while figures should be used for 10 and above. I’m not as aware as other style guides, is this a case of AP being the odd one out… or is Wikipedia style the odd one? -- [[User:RickyCourtney|RickyCourtney]] ([[User talk:RickyCourtney|talk]]) 04:14, 28 December 2024 (UTC)

:The example shows it very well. Mixing both types in one sentence like {{!xt|ages were {{nobr|five, seven, and 32}}}} looks very amateurish. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 05:43, 28 December 2024 (UTC)
::I agree, but as the MoS is the only style guide I've perused at length, I'd naturally be inclined to. I wonder what the provenance of this guideline is also—and that of other guidelines of note as well if anyone knows and cares to waste time telling me. <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff">&nbsp;‥&nbsp;</span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 05:54, 28 December 2024 (UTC)
:::Saying it “looks very amateurish” is very much a subjective opinion. 
:::But to focus this on my more real-world concerns, this question was prompted by in connection to coverage of the jet crash in Kazakhstan. So in keeping with that, I present how the New York Times handles three such sentences on [https://www.nytimes.com/2024/12/25/world/asia/kazakhstan-plane-crash.html?unlocked_article_code=1.k04.5cab.uMM41oWsYLil&smid=nytcore-ios-share&referringSource=articleShare&tgrp=on one article on the topic]: {{xt| Kazakhstan’s Emergency Situations Ministry said that at least 29 people had survived, including two children}} … {{xt|Kazakhstan’s transportation ministry said that the flight’s passengers included 37 Azerbaijani nationals, 16 Russians, six Kazakh citizens and three Kyrgyz nationals.}} … {{xt|The airline’s last major episode was in 2005, when an An-140 plane crashed shortly after takeoff, killing 18 passengers and five crew members.}} 
:::Because of editors closely following our current MOS, our introduction on this same topic reads: {{xt|On 25 December 2024, the Embraer 190AR operating the route crashed near Aktau International Airport, Kazakhstan, with sixty-two passengers and five crew on board. Of the sixty-seven people on board, thirty-eight died in the crash, including both of the pilots and one flight attendant, while twenty-nine people survived with injuries.}}
:::If we adopted AP style it would read: {{xt|On 25 December 2024, the Embraer 190AR operating the route crashed near Aktau International Airport, Kazakhstan, with 62 passengers and five crew on board. Of the 67 people on board, 38 died in the crash, including both of the pilots and one flight attendant, while 29 people survived with injuries.}}
:::In my opinion, the AP style is vastly superior to what is suggested by our current MOS. [[User:RickyCourtney|RickyCourtney]] ([[User talk:RickyCourtney|talk]]) 07:29, 28 December 2024 (UTC)
::::The present guidance not to mix forms has consensus here. If you want that to change you'll need to propose a change to the wording, and explain why it is better. Saying "AP does it that way" seems unlikely to change the consensus. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 07:40, 28 December 2024 (UTC)
:::::Long time editor, but this is definitely the first time I’ve encountered a MOS rule that I found so out of line with how I am used to writing (as you can probably surmise, I use AP in my day job). Frankly, I was just trying to get insight into ''why'' this was the consensus. I’m happy to propose something, is this the correct venue? Does it need to be in a formal format? [[User:RickyCourtney|RickyCourtney]] ([[User talk:RickyCourtney|talk]]) 08:17, 28 December 2024 (UTC)
::::::Go ahead and suggest an improvement. This is the right place for it. Indeed it is the raison d'etre of this talk page. There is no formal format. Just make sure the proposed change is clear, and explain how it results in an improvement. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 08:21, 28 December 2024 (UTC)
:::::::It's pretty clear they're suggesting the AP style, right? I don't think it'll catch on here, though. However, one point in its favor one could argue is it doesn't depend at all on the surrounding context. <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff">&nbsp;‥&nbsp;</span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 08:24, 28 December 2024 (UTC)
::::::::I agree the verbatim AP wording, including “You should use figures for 10 or above and whenever preceding a unit of measure or referring to ages of people, animals, events or things”, would be unlikely to gain acceptance here, mainly because of its far-reaching consequences for other parts of MOSNUM. Let’s judge the proposal when it comes. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 08:50, 28 December 2024 (UTC)
::::::No one has yet replied to the "why?" question. One would need to check the archives to be sure, but I imagine one reason is to avoid bizarre combinations like "the sum of 11 and two is 13". [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 09:18, 28 December 2024 (UTC)
::::::I suspect a significant part of the answer to “why?” is that, unlike other publications that set down a preferred style which they then use universally, Wikipedia explicitly tolerates a ''variety'' of styles across its ‘publications’ - most obviously for the national varieties of English, and date formats, but also in many other respects (‘AD’ or ‘CE’ being just one example) - with the MoS itself being guidelines that are widely respected, but not policy that can be rigidly enforced.  This is a pragmatic compromise, given our global reach and multitude of editors of all ages and nationalities, and the practical impossibility of enforcing any single way of writing. But it does make '''consistency''' a policy issue for WP, which it simply isn’t for any other publisher (since by definition their style guides ensure that everything is consistent).   Thus WP guidelines put a lot of emphasis on style choices being internally consistent within articles, because they aren’t between articles.  When it comes to number format this means using either words or figures, but not a confusing jumble of both.  Personally, I think this is a sensible guideline and would expect to oppose any proposed change, unless the argumentation is exceptionally convincing. [[User:MapReader|MapReader]] ([[User talk:MapReader|talk]]) 14:08, 28 December 2024 (UTC)
::::I'd say that {{xt|Of the 67 people on board, 38 died in the crash, including both of the pilots and one flight attendant, while 29 people survived with injuries}} is absolutely fine and in agreement with our guidelines. The numbers {{xt|one}} and {{xt|29}} are so far from each other that there's just no reason to consider them "comparable" (except in the trivial sense that you can compare anything with anything, but that's certainly not the intended one here). I'd also consider {{xt|with 62 passengers and five crew on board}} as fine since crew members and passenger numbers aren't really comparable either – there'll likely to be an order of magnitude or more away from each other, as in this case. That's very different from people's ages (the example given), which all come from a population's age distribution and rarely exceed 100. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 08:49, 28 December 2024 (UTC)
:::::I would argue the present guidance should result in "62 passengers and 5 crew", not "62 passengers and five crew". I have the impression {{u|RickyCourtney}} would like to change the guidance to reverse that preference. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 08:58, 28 December 2024 (UTC)
::::::{{xt|62 passengers and 5 crew}} is certainly possible if we consider this as falling under the guideline. However, {{xt|Of the 67 people on board, 38 died in the crash, including both of the pilots and 1 flight attendant, while 29 people survived with injuries}} is certainly too odd to consider! My point, of course, was that these sentences don't fall under the guideline anyway, due to these numbers not really being "comparable". [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 09:39, 28 December 2024 (UTC)

:::::::Re: 'Saying it “looks very amateurish” is very much a subjective opinion.' Sure. But your follow up of "in my opinion" is also subjective. There are no objective measurements here. The alternatives are:
:::::::*Existing MOS: "with 62 passengers and 5 crew on board" or the equally allowed "with sixty two passengers and five crew on board". Both are consistent and do not require me to do a mental switch between styles. I like the all numbers version and hate the all words version - subjectively of course ;) The disadvantage is that it disagrees with a couple of major US style guides - which WP is not required to match anyway.
:::::::*AP/Times style: "with 62 passengers and five crew on board" Advantage is that it is the same as a couple of major style guides used in the US. Do British style guides agree? Disadvantage is it requires that mental switch halfway through the sentence.
:::::::It is entirely subjective whether the mental switch or matching an outside style guide is more important to you. If you like consistency (like me) then consistency is more important. And naturally, if you grew up in the US then matching major US style guides is possibly important.
:::::::Re: 'The numbers one and 29 are so far from each other that there's just no reason to consider them "comparable"'. They are in the same sentence and are comparing similar things (people). Why would you consider crew and passengers as different when listing fatalities?

:::::::Re: '{{xt|Of the 67 people on board, 38 died in the crash, including both of the pilots and 1 flight attendant, while 29 people survived with injuries}} certainly too odd to consider.' Why too odd? Its the form that I personally prefer and allowed by the current MOS. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 13:09, 28 December 2024 (UTC)
::::::::29 only has meaning to me in that it is comparable to 1. <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff">&nbsp;‥&nbsp;</span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 13:15, 28 December 2024 (UTC)
::::::::This isn’t just “US style.” AP is US-based, but they serve news organizations across the world. Reuters, which is UK-based, uses the same style [https://www.reuters.com/world/asia-pacific/azerbaijan-airlines-flight-was-downed-by-russian-air-defence-system-four-sources-2024-12-26/ in this article]. As does [https://www.euronews.com/2024/12/26/azerbaijani-president-ilham-aliyev-launches-criminal-probe-into-azerbaijan-airlines-plane- Euronews]. As does the [https://www.irishmirror.ie/news/world-news/over-30-feared-dead-plane-34374244.amp Irish Mirror]. [[User:RickyCourtney|RickyCourtney]] ([[User talk:RickyCourtney|talk]]) 15:40, 28 December 2024 (UTC)
:::::::::Fair enough - not just US. But still an external style that is just one among many and one that we are not necessarily compelled to match. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 22:44, 28 December 2024 (UTC)

:::::@[[User:Gawaon|Gawaon]] this is an ''extremely'' helpful interpretation. Thank you. I wonder if you and others would weigh in on another sentence in the [[Azerbaijan Airlines Flight 8243]] article: {{tq|The aircraft was carrying sixty-two passengers. Of those, thirty-seven people were citizens of Azerbaijan, sixteen of Russia, six of Kazakhstan, and three of Kyrgyzstan. Four minors were on board.}} My preferred way to rewrite this would be: {{tq|The aircraft was carrying 62 passengers. Of those, 37 people were citizens of Azerbaijan, 16 of Russia, six of Kazakhstan, and three of Kyrgyzstan. Four minors were on board.}} That would be in alignment with how it’s been written in the [https://www.nytimes.com/2024/12/25/world/asia/kazakhstan-plane-crash.html?unlocked_article_code=1.k04.5cab.uMM41oWsYLil&smid=nytcore-ios-share&referringSource=articleShare&tgrp=on New York Times],  [https://www.euronews.com/2024/12/26/azerbaijani-president-ilham-aliyev-launches-criminal-probe-into-azerbaijan-airlines-plane- Euronews] and the [https://www.irishmirror.ie/news/world-news/over-30-feared-dead-plane-34374244.amp Irish Mirror]. -- [[User:RickyCourtney|RickyCourtney]] ([[User talk:RickyCourtney|talk]]) 15:58, 28 December 2024 (UTC)
::::::But is more readable as it was. [[User:MapReader|MapReader]] ([[User talk:MapReader|talk]]) 18:01, 28 December 2024 (UTC)
::::::My choice would be all numeric: {{tq|The aircraft was carrying 62 passengers. Of those, 37 people were citizens of Azerbaijan, 16 of Russia, six of Kazakhstan, and 3 of Kyrgyzstan. 4 minors were on board.}} No mental context switch required between numeric and spelt out words within closely related sentences — which could easily be a combined: {{tq|The aircraft was carrying 62 passengers. Of those, 37 people were citizens of Azerbaijan, 16 of Russia, six of Kazakhstan, and 3 of Kyrgyzstan — 4 minors were on board.}} <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 22:44, 28 December 2024 (UTC)
:::::::{{+1}} to this, though I admit my preference is biased because I've been taught in business correspondence to write related numbers either in words or figures, with figures taking precedence if the largest number is at least 10. —[[User:Tenryuu|<span style="color:#556B2F">Tenryuu&nbsp;🐲</span>]]&nbsp;(&nbsp;[[User talk:Tenryuu|💬]]&nbsp;•&nbsp;[[Special:Contributions/Tenryuu|📝]]&nbsp;) 04:20, 2 January 2025 (UTC)
Okay, so I did some more research this morning and found the answer I was looking for. This is a case of journalists adopting a style different from academics, and the MOS adopting the academic style. The APA has strict rules about consistency within categories, requiring numerals for all items in a list if any number is 10 or above. But it appears our MOS most closely matches the Chicago Manual of Style, which requires consistency, but allows for context-specific judgment if numerals or spelled-out numbers are used. -- [[User:RickyCourtney|RickyCourtney]] ([[User talk:RickyCourtney|talk]]) 20:46, 28 December 2024 (UTC)

== Acceptable Date Format: Month Year ==

Right now, "Month Year" is listed as an acceptable format, with an example of September 2001, but this is *bad grammar*, violating the basic rules of English.  There are two acceptable ways to convey this, grammatically:

# Month of Year (September of 2001), which is listed as unacceptable but is correct grammar in the form Noun of Noun, e.g. Juan Esposito of Peru.
# Month, Year (September, 2001), also listed as unacceptable, but again, correct grammar, of the same shape as general dates (September 1, 2001), which *is* listed as acceptable, which is correct but inconsistent, because September, 2001 and September 1, 2001 are two uses of the *same format and grammar*.

"September 2001" is bad grammar and an unacceptable format and should be labeled as such. [[User:Quindraco|Quindraco]] ([[User talk:Quindraco|talk]]) 15:48, 30 December 2024 (UTC)

*It’s common English usage, both in the UK and US, so on what authority are you suggesting it is bad grammar? [[User:MapReader|MapReader]] ([[User talk:MapReader|talk]]) 15:51, 30 December 2024 (UTC)
*Agree with MapReader, this is standard. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 15:55, 30 December 2024 (UTC)
*Agree with MapReader. ''Chicago Manual of Style'' 18th ed. ¶ 6.41 states "Commas are also unnecessary where only a month and year are given...." and gives the example "Her license expires sometime in April 2027." [[User:Jc3s5h|Jc3s5h]] ([[User talk:Jc3s5h|talk]]) 16:30, 30 December 2024 (UTC)
*There ain't nothin' wrong with September 2001. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 20:07, 30 December 2024 (UTC)
*:To be clear, that particular month was not one of unalloyed pleasantness, but the ''formatting'' has nothing wrong, anyway. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 21:51, 30 December 2024 (UTC)
*{{replyto|Quindraco}} You're about {{diff|Wikipedia:Manual of Style/Dates and numbers|prev|5087496|twenty years too late}} to change the guideline. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1F98C; ([[User talk:Redrose64|talk]]) 21:25, 30 December 2024 (UTC)
*:Ah, yes.  The very well-respected defense of "we've been doing it the wrong way for so long, lord knows we mustn't stop ''now''." [[User:Quindraco|Quindraco]] ([[User talk:Quindraco|talk]]) 05:27, 7 January 2025 (UTC)
*The OP's complaint is, I regret to say, just so much [[WP:MISSSNODGRASS]]ism. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 21:52, 30 December 2024 (UTC)
*Agree with MapReader.  "September 2001" is perfectly acceptable in formal written English and was acceptable long before I was born.  --[[User:Coolcaesar|Coolcaesar]] ([[User talk:Coolcaesar|talk]]) 06:38, 7 January 2025 (UTC)
*It's recognised to be [https://www.noslangues-ourlanguages.gc.ca/en/writing-tips-plus/commas-in-a-date standard usage in Canada]. —[[User:Tenryuu|<span style="color:#556B2F">Tenryuu&nbsp;🐲</span>]]&nbsp;(&nbsp;[[User talk:Tenryuu|💬]]&nbsp;•&nbsp;[[Special:Contributions/Tenryuu|📝]]&nbsp;) 16:12, 7 January 2025 (UTC)

== [[MOS:CENTURY]] appears to be incorrect ==

I'm surprised that this hasn't been fixed already but [[MOS:CENTURY]] currently incorrectly claims that "the 17th century as 1601–1700", for example. I was about to fix the [[21st century]] article which incorrectly claims that the 21st century started in 2001, not 2000, but then noticed that it's only like that thanks to this MoS guideline!

There have been quite a few news articles analysing the 21st century recently, many of them because the first quarter of the century (2000-2024) is now over: [https://www.theguardian.com/business/nils-pratley-on-finance/2024/dec/26/the-first-quarter-of-the-21st-century-wasnt-great-for-investors-the-next-needs-an-ai-boost Guardian], [https://www.bloomberg.com/opinion/articles/2024-12-30/how-has-the-21st-century-gone-so-wrong?embedded-checkout=true Bloomberg], [https://www.billboard.com/music/pop/beyonce-greatest-pop-stars-21st-century-1235842572/ Billboard], [https://www.ifimes.org/en/researches/the-end-of-the-first-quarter-of-the-21st-century-marked-by-significant-searches-for-new-global-geopolitical-balances/5371 IFIMES], [https://www.nytimes.com/interactive/2024/books/best-books-21st-century.html New York Times]. 

I can only assume the current MOS wording came out of the mistaken assumption/hypercorrection that a century must begin in a year ending in "1" thanks to the lack of a year zero in the calendar system, but that is of course not how the term is actually used in any sources. Thoughts on the best way of fixing this? I imagine quite a few articles will be affected by this error given it's somehow ended up in the MOS. [[User:Chessrat|<b style="color: #c90; font-family: comic sans ms">Chessrat</b>]] <sup>([[User talk:Chessrat|<span style="color:green">talk</span>]], [[Special:Contribs/Chessrat|<span style="color:#f78">contributions</span>]])</sup> 13:29, 1 January 2025 (UTC)
*If it ain't broke, don't fix it. [[MOS:CENTURY]] is correct. Ask yourself when the 1st century CE (using the [[proleptic Gregorian calendar ]]) began and then work your way forward. -- [[User:Chatul|Shmuel (Seymour J.) Metz Username:Chatul]] ([[User talk:Chatul|talk]]) 15:22, 1 January 2025 (UTC)
*:But there wasn’t such.  The dating system was invented many years later (and incorrectly, as it turned out) and applied retrospectively.  Such that it doesn’t matter whether there was a year zero, or not.  Centuries nowadays are commonly recognised as 1900-1999, 2000-2099, and it’s only the WP pedants that hold out for 1901-2000. [[User:MapReader|MapReader]] ([[User talk:MapReader|talk]]) 17:55, 2 January 2025 (UTC)
*::Where did you hear that. I was taught for 60 years it was 1901-2000. Did schools change their courses recently? I guess it wouldn't be the first time, but this sounds like since so many get it wrong we should make sure that Wikipedia follows that same wrong thinking. Like people following a printing error on the term "Blue Moon" so they think it's the second full moon of a month. [[User:Fyunck(click)|Fyunck(click)]] ([[User talk:Fyunck(click)|talk]]) 09:38, 3 January 2025 (UTC)
*:::That sounds like a case of [[Wikipedia:Lies Miss Snodgrass told you|Lies Miss Snodgrass told you]]. (I'm not saying it's actually a lie, but it's a lie that that's the ''only'' way in which centuries can be spliced.) [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 11:01, 3 January 2025 (UTC)
*Chessrat didn't explain where they looked for sources to justify the assertion "but that is of course not how the term is actually used in any sources." Wikipedia guidelines do not need to cite sources, since they announce the community's consensus on various matters. It is articles that must cite sources. A number of sources are cited at "[[Century]]" including
::{{Cite web| title = century | work = Oxford Dictionaries| access-date = 20 January 2021| url = https://www.lexico.com/definition/century| archive-url = https://web.archive.org/web/20191230065254/https://www.lexico.com/definition/century| url-status = dead| archive-date = December 30, 2019}}
:[[User:Jc3s5h|Jc3s5h]] ([[User talk:Jc3s5h|talk]]) 15:43, 1 January 2025 (UTC)
*“Incorrect” is not the way I would put it. Either you treat it as a style decision, with both systems being valid ways to designate the years (using either 1–99 or 1–100 for the first century) or you treat it as a logical / mathematical system, ending at 100 because you want every century to actually be 100 years, and the first year wasn’t 0. I could see it either way, but I don’t see a lot of sense trying to change it now. 
:What might be more sensible to pursue is a footnote that acknowledges and explains the two common ways of counting. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">[[User:HTGS|HTGS]]</span>&nbsp;([[User talk:HTGS|talk]])</span> 03:28, 2 January 2025 (UTC)
::+1 [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 04:27, 2 January 2025 (UTC)
::I don't think there's any evidence that there are two different common ways of counting? As far as I can tell from looking into this, use of the term for the period beginning in a year ending in "1" is very rare, and the only sources that mention the "ending in 1" definition (such as the Oxford dictionary entry mentioned by {{ping|Jc3s5h}} mention that it is a technical definition only and not used that way in practice. It is not the case that there were widespread celebrations of the new millennium both on 1 January 2000 and also 1 January 2001!
::If there were two equally-used systems then I would agree with your comment, but that isn't the case; Wikipedia has a duty to provide accurate information even if it does take a significant amount of work fixing this across various articles. [[User:Chessrat|<b style="color: #c90; font-family: comic sans ms">Chessrat</b>]] <sup>([[User talk:Chessrat|<span style="color:green">talk</span>]], [[Special:Contribs/Chessrat|<span style="color:#f78">contributions</span>]])</sup> 16:15, 2 January 2025 (UTC)
:::How many years were there in the 1st [[century]]? [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 18:27, 2 January 2025 (UTC)
::::100, obvs. 1 AD to 100 AD. Next question please? --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1F98C; ([[User talk:Redrose64|talk]]) 21:12, 2 January 2025 (UTC)
:::::My question was in response to {{u|Chessrat}}'s post claiming that centuries start in 00, in which case they must end in 99. If the 1st century had 100 years, its first year would therefore have been 1 BC (and the 1st century BC would have ended in 2 BC). Alternatively, if the first year of the first century was 1 AD, it would have been a century with 99 years. Just trying to understand how it works (I don't know which of the two is more bizarre). [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 21:44, 2 January 2025 (UTC)
::::::It is a matter of personal preference. I find it logical and satisfying that the 19th century ended with 1900 and the 20th century ended with 2000. There are many people, though, who are more comfortable with the 19th century consisting only of the years that began with 18-- and the 20th century consisting only of the years that began with 19--. I remember that [[:Stephen Jay Gould]], someone I have long admired for his adherence to logic, stated that he was willing to accept that the First century consisted of only 99 years (although I think he was wrong). We do need to be consistent in Wikipedia, however, and if anyone feels strongly enough about the current guidance being wrong, RfC is thataway. [[User talk:Donald Albury|Donald Albury]] 22:10, 2 January 2025 (UTC)
::::::Again, the numbering of years AD/BC wasnt actually devised until over five centuries after the purported BC to AD break point, and such numbering was not widely used until over eight hundred years afterwards.  And it was then applied retrospectively to historical events (with, historians now believe, an error of four years in terms of when they were trying to pitch the start), relatively few of which during that period can be fixed to a particular year in any case (not insignificantly because when these events were recorded, the AD/BC calendar system didn’t exist).  So it’s an artificial construct and it doesn’t really matter what the first year was purported to have been. [[User:MapReader|MapReader]] ([[User talk:MapReader|talk]]) 22:24, 2 January 2025 (UTC)
::::::Sources are fairly clear that in common usage, a century starts with a year ending in –00, so yes, by implication that means that the 1st century had 99 years (albeit of course the Gregorian calendar did not enter use until far later so this is purely retroactive)
::::::I didn't really expect that there would be any disagreement with this– will probably start an RfC to gain wider input as it seems like this will be a matter which there is somehow internal disagreement on. [[User:Chessrat|<b style="color: #c90; font-family: comic sans ms">Chessrat</b>]] <sup>([[User talk:Chessrat|<span style="color:green">talk</span>]], [[Special:Contribs/Chessrat|<span style="color:#f78">contributions</span>]])</sup> 22:38, 2 January 2025 (UTC)
::::Why should all centuries have the same length? Years haven't always the same length, so why should centuries be any different? [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 08:08, 3 January 2025 (UTC)
:::::{{replyto|Chessrat|Gawaon}} A century doesn't have to be 100 years, but it must be 100 ''somethings'', for example 100 runs in a cricket innings, or a military unit comprising 100 Roman legionaries. This is because the word "century" is derived from "[[:la:centum|centum]]", which is Latin for "hundred". If you had a span of 99 years, it couldn't be called a century. Also from "centum" we get words like "cent" for the hundredth part of a dollar. If I gave you 99 cents, you probably wouldn't give me a dollar in exchange. By contrast, the word "year" doesn't have a comparable derivation from 365 (or 366). --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1F98C; ([[User talk:Redrose64|talk]]) 22:24, 3 January 2025 (UTC)
::::::Common usage having the 21st century starting in 2000 is utterly irrelevant to the Latin etymology of the word "century". The calendar system came into use long after 1 CE so analysis of the durations of past centuries is purely retroactive and simply a case of how society largely agrees to define it.
::::::If one were to strictly assume Latin etymology is always fully indicative of how a word is used, then the article on [[September]] would say that it is the seventh, not the ninth, month of the year. [[User:Chessrat|<b style="color: #c90; font-family: comic sans ms">Chessrat</b>]] <sup>([[User talk:Chessrat|<span style="color:green">talk</span>]], [[Special:Contribs/Chessrat|<span style="color:#f78">contributions</span>]])</sup> 07:40, 4 January 2025 (UTC)
::::::Yes, the argument by name origin is fairly weak, since actual meanings don't always live up to their origins – or certainly not exactly. [[Centurion]] say: "The size of the century changed over time; from the 1st century BC through most of the imperial era it was reduced to 80 men." So if a century can have just 80 men, surely it can have just 99 years too! [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 15:06, 4 January 2025 (UTC)
:::::::I agree the etymology argument is weak, but a century has 100 years, regardless of etymology. That's what we were all taught at school and that's what all credible sources say. Wikipedia should not take it upon itself to make up an exception. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 19:11, 4 January 2025 (UTC)
:::@[[User:Chessrat|Chessrat]]:
:::1) I actually don’t hate the idea of doing it your way, I just don’t see the need or the community interest. As you point out, socially and culturally we {{em|do}} treat it this way; we did have a special party on 31 Dec 1999, and not so much 31 Dec 2000. But the effort to shuffle it all around still comes with the need for a footnote explainer for our choice of convention and that now the [[1st century]] is just the “first century” in name, and covers only 99 years. Honestly this is (imo) not a big deal, just not a hill I’d be looking to die on, and such a change will need a whole bunch of annoying cleanup. As everyone else has said, the old way has the seductive logic that 100=100. This area of Wikipedia especially was built early and therefore done so by those net-denizens more inclined towards “logic” than social convention.
:::2) As far as I know, articles on the subject of centuries are either covering the entire period broadly, or just giving a timeline of events that occurred in such years (or really, both). Presumably there’s not much worry whether we start with 1900 or 1901 when the topic is “world war, atomic energy, the end of empire, mass telecommunication and the beginnings of the internet” (etc). Alternatively, the specific events occurring on those crossover years is just arbitrarily dumped into whichever list-like article we like, and if it has carry-over effects on future events, that should get a mention either way. I guess this point (2) actually cuts both ways though, in the sense of “both work fine”. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">[[User:HTGS|HTGS]]</span>&nbsp;([[User talk:HTGS|talk]])</span> 06:50, 3 January 2025 (UTC)
:::::I assume by "we" you mean you personally. I also had a 31 Dec 1999 "2000" party, but my big millennium party for the century change came on Dec 31 2000. And my tickets to the event are on that date. [[User:Fyunck(click)|Fyunck(click)]] ([[User talk:Fyunck(click)|talk]]) 09:49, 3 January 2025 (UTC)
::::::That’s honestly surprising to me. Whereabouts were you? I was in New Zealand, but my impression was that the big deal end-of-millenium in “Western” (global “North”? Anglosphere?) popular culture was 1999 to 2000. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">[[User:HTGS|HTGS]]</span>&nbsp;([[User talk:HTGS|talk]])</span> 08:23, 4 January 2025 (UTC)

::::Yes, it would be a significant amount of work, but retaining an incorrect status quo is not desirable. If Wikipedia lasts to reach 2100, there would be the ludicrous scenario where it's impossible to cite the large number of sources stating the arrival of the 22nd century because Wikipedia policy defines the word "century" differently to the rest of the world.
::::You're probably right that regardless, a hatnote/explanatory note of some nature is needed. For instance, a lot of sources such as [https://www.reuters.com/article/world/worlds-oldest-person-last-one-of-19th-century-dies-in-italy-at-117-idUSKBN17H0J6/ Reuters], [https://www.telegraph.co.uk/news/2016/11/29/emma-morano-worlds-oldest-living-person-celebrate-117th-birthday/ The Telegraph], [https://www.theatlantic.com/science/archive/2017/05/who-was-the-last-person-on-earth-born-in-the-1700s/526548/ The Atlantic], [https://www.theguardian.com/us-news/2016/may/13/worlds-oldest-person-susannah-mushatt-jones-dies-at-age-of-116 The Guardian] [https://www.france24.com/en/20170416-worlds-oldest-person-dies-italy-aged-117 France 24], [https://www.timesofisrael.com/last-known-survivor-of-19th-century-dies-at-117/ Times of Israel] report that [[Emma Morano]] (1899–2017) was the last surviving person born in the 19th century. However, there are also a few sources such as [https://slate.com/news-and-politics/2018/04/the-last-known-person-born-in-the-19th-century-died-in-japan.html Slate], [https://www.washingtonpost.com/news/worldviews/wp/2018/04/22/the-worlds-oldest-person-died-at-117-she-was-the-last-known-person-born-in-the-19th-century/ the Washington Post], and [https://news.sky.com/story/worlds-oldest-person-dies-in-japan-aged-117-11343651 Sky News] which report that [[Nabi Tajima]] (1900–2018) was the last surviving person born in the 19th century, using the ending-in-1 definition.
::::At the moment, the implication of Wikipedia policy is that Tajima is described as having been the last person born in the 19th century on her article section, but Morano is ''not'' described as having been the last person born in the 19th century despite the numerous reliable sources stating that she was. The current policy effectively overrides any amount of sourcing of facts like that- every article treats the uncommon ending-in-1 definition as not only being a common definition but as the ''only'' definition. I don't see how a policy which arbitrarily overrides established facts and sources like that can possibly be justifiable. [[User:Chessrat|<b style="color: #c90; font-family: comic sans ms">Chessrat</b>]] <sup>([[User talk:Chessrat|<span style="color:green">talk</span>]], [[Special:Contribs/Chessrat|<span style="color:#f78">contributions</span>]])</sup> 09:03, 3 January 2025 (UTC)
:::::So your suggested change would also affect many other articles such as our own sourced [[19th century]] article. [[User:Fyunck(click)|Fyunck(click)]] ([[User talk:Fyunck(click)|talk]]) 10:08, 3 January 2025 (UTC)

{{outdent}}
As per [[WP:RS]] (with the emphasis on ''reliable''), I asked Mr Google <code>when does the new century start</code>, then looked at any hit that seemed reliable (typically government or scientific time orientated organisations) and ignored anything like quora, mass media (I gave Scientific American a pass as they are scientific) and forums. The first 3 pages gave me the following list, plus I added the Greenwich observatory. Note, I choose them based on the sources ''before'' looking at what they said.

{| class="wikitable"

! Organisation !! URL !! 00 or 01
|-
| Hong Kong Observatory || https://www.hko.gov.hk/en/gts/time/centy-21-e.htm#:~:text=The%20second%20century%20started%20with,continue%20through%2031%20December%202100. || 01
|-
| timeanddate.com || https://www.timeanddate.com/counters/mil2000.html || 01
|-
| Scientific American || https://www.scientificamerican.com/article/when-is-the-beginning-of/ || 01
|-
| US Navy Astronomical Applications Department || https://aa.usno.navy.mil/faq/millennium || 01
|-
| US Library of Congress || https://ask.loc.gov/science/faq/399936 <br> https://www.loc.gov/rr//scitech/battle.html (Battle of the Centuries) || 01
|-
| Merriam Webster || https://www.merriam-webster.com/grammar/centuries-and-how-to-refer-to-them || says it used to be 01 but that public opinion is swinging
|-
| Greenwich Observatory || http://www.thegreenwichmeridian.org/tgm/articles.php?article=12 || 01

|}

Seems like the scientific community has a solid consensus on new centuries starting in the year xx01. The "Battle of the Centuries" is a good read. To be fair, does anybody have any authoritative sources backing the xx00 change date?

This is, of course, counter-intuitive to the layman who just sees 1999 tick over to 2000 and therefore assumes that change in the 3rd digit means a new century. But as we all know, intuition and truth do not always agree.

So why did the world celebrate the new century on 1 Jan 2000 ? I'm going to digress into armchair philosophising but bear with me. Image that you are a major newspaper, news channel, magazine, etc  and you want readers to buy/subscribe. You can research it, find out that 1 Jan 2001 is the correct date and make a big thing on that date. But your competitors celebrated way back on 1 Jan 2000 and the public goes "meh, we did all that last year - get with the times you out of date moron!" The big news companies know this, so they all go with the earlier date to avoid their competitors getting the jump on them. Never let the truth get in the way of profit! Joe public naturally follows the mass media and ignores the nerds saying "2001" - why listen to boring nerds when you can party now! Party, party, party!

So, here we are, arguing whether to follow the truth or to follow Joe Public with both of his brain cells following news companies who are chasing the almighty dollar. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 11:44, 3 January 2025 (UTC)

*There are some known inconsistencies/anomalies in our treatment of centuries, including categories or articles covering decades. For example, [[:Category:1900s in biology]] is a subcategory of [[:Category:20th century in biology]], but includes 1900 which the MOS puts in the 19th century. If we were starting again, I think it would have been better to avoid using century in categories or articles, e.g. use "1900–1999" instead of "20th century", but we are where we are. [[User:Peter coxhead|Peter coxhead]] ([[User talk:Peter coxhead|talk]]) 12:36, 3 January 2025 (UTC)

:I'm not sure why you're focusing only on the specific niche of science-related sources? If the scientific community chooses to adopt an unorthodox definition of the duration of the centuries, but most other sources follow the common definition, obviously the latter is more accurate. [[User:Chessrat|<b style="color: #c90; font-family: comic sans ms">Chessrat</b>]] <sup>([[User talk:Chessrat|<span style="color:green">talk</span>]], [[Special:Contribs/Chessrat|<span style="color:#f78">contributions</span>]])</sup> 13:45, 3 January 2025 (UTC)
::{{ping|Chessrat}} the century beginning in XX01 is not {{tq|unorthodox}}, quite the reverse. As people above have said, it's the definition that has been taught for years, but one that I agree is increasingly being replaced by the century beginning in XX00 definition. {{tq|Obviously the latter is more accurate}}, well, no – as pointed out above, this definition leads to the first century having only 99 years, so can hardly be called more accurate. Orthodoxy and accuracy are not the important issues in my view; the most important issue is what most readers now think 'century' means, which does appear to be the XX00–XX99 definition. [[User:Peter coxhead|Peter coxhead]] ([[User talk:Peter coxhead|talk]]) 14:21, 3 January 2025 (UTC)
:::Back in 2000 it was suggested that a year zero be created with (since years have variable numbers of days anyway) zero days. That way the first century would have 100 years in it.  [[User:Hawkeye7|<span style="color:#800082">Hawkeye7</span>]] [[User_talk:Hawkeye7|<span style="font-size:80%">(discuss)</span>]] 22:06, 3 January 2025 (UTC)
::::At least we can all agree that that would be the ugliest possible solution. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">[[User:HTGS|HTGS]]</span>&nbsp;([[User talk:HTGS|talk]])</span> 08:26, 4 January 2025 (UTC)
::{{replyto|Chessrat}} Scientists put much thought into the matters that they comment upon, it's a poor scientist who states something as fact when they have no demonstrable evidence. So I would take a scientist's view over a newspaper's view any day. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1F98C; ([[User talk:Redrose64|talk]]) 22:52, 3 January 2025 (UTC)

== RfC on the wording of [[MOS:CENTURY]] ==
<!-- [[User:DoNotArchiveUntil]] 15:01, 7 February 2025 (UTC) -->{{User:ClueBot III/DoNotArchiveUntil|1738940465}}
{{rfc|hist|lang|rfcid=6F3124E}}
Should [[MOS:CENTURY]] specify the start of a century or millennium as a year ending in 1 (e.g. the 20th century as 1901–2000), as a year ending in 0 (e.g. the 20th century as 1900–1999), or treat both as acceptable options with the use of hatnotes for clarity in the case of ambiguity in articles? See the discussion above. [[User:Chessrat|<b style="color: #c90; font-family: comic sans ms">Chessrat</b>]] <sup>([[User talk:Chessrat|<span style="color:green">talk</span>]], [[Special:Contribs/Chessrat|<span style="color:#f78">contributions</span>]])</sup> 14:57, 3 January 2025 (UTC)

*The year ending in zero, which is nowadays the most common understanding.  Whether or not there was ever a year zero is irrelevant, given that AD year numbering wasn’t invented until the 500s and wasn’t widely used until the 800s. [[User:MapReader|MapReader]] ([[User talk:MapReader|talk]]) 21:21, 3 January 2025 (UTC)
*As the 1st century is 1–100, the [[20th century]] is 1901–2000, as its article says. Let us not turn this into another thing (like "billions") where English becomes inconsistent with other languages. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 22:22, 3 January 2025 (UTC)
*:Also, I do not understand what "hatnotes in case of ambiguity in articles" should mean: whenever any article uses the word "20th century", it should have a hatnote explaining whether it follows the centuries-old convention of numbering centuries or the "starts with 19 is 20th century" approximation? Perhaps it would be easier to outlaw the word "century". —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 22:26, 3 January 2025 (UTC)
*:In short, '''oppose change'''. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 17:46, 4 January 2025 (UTC)
*First year of a century ends in 01, last year of a century ends in 00. This has been extensively discussed above. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] &#x1F98C; ([[User talk:Redrose64|talk]]) 22:52, 3 January 2025 (UTC)
*The RfC does not make clear what specific change is being proposed to MOSNUM wording, and I fear will lead only to a continuation ''ad nauseum'' of the preceding discussion. For what it's worth, I '''oppose''' any change resulting in a century of 99 years. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 23:06, 3 January 2025 (UTC)
*'''Oppose change''' Century and Millennia begin in 01 and ends Dec 31, 00, like it always has and per the discussion above. Just because people make errors, like with Blue Moon, doesn't mean an encyclopedia has to. Why would we change from long-standing consensus? [[User:Fyunck(click)|Fyunck(click)]] ([[User talk:Fyunck(click)|talk]]) 09:28, 4 January 2025 (UTC)
* '''Treat both as acceptable options.''' [[Century]] already explains both viewpoints, without describing one of them as "correct". Generally our business it not to arbiter truth (which in this case doesn't exist anyway, as either viewpoint is just a convention), but to describe common understandings of the world, including disputes and disagreements where they exist. [[Century]] doesn't privilege a particular POV here, and neither should [[MOS:CENTURY]]. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 16:31, 4 January 2025 (UTC)
*:All of our articles on individual centuries mention only the traditional point of view where the first century starts in year 1 and each century has 100 years. There is no need for [[MOS:CENTURY]] to do anything else. —[[User:Kusma|Kusma]] ([[User talk:Kusma|talk]]) 17:46, 4 January 2025 (UTC)
* '''Oppose.''' If this matters to you, convince the academic sources to adopt the change, then Wikipedia can follow. [[User:Jc3s5h|Jc3s5h]] ([[User talk:Jc3s5h|talk]]) 18:14, 4 January 2025 (UTC)
* '''Oppose change''' I prefer centuries to begin with --01 and end with --00. I'll not bother with any arguments, since I think this boils down to personal preference. I do oppose allowing both options, as that leads to confusion and edit wars. [[User talk:Donald Albury|Donald Albury]] 18:20, 4 January 2025 (UTC)
*:Why is it personal preference to favour 1-100 AD over 1 BC-99 AD? The latter choice leads to the first century BC running from 101 to 2 BC. I find the asymmetry highly unorthodox (and hence hard to justify). [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 12:37, 6 January 2025 (UTC)
*::You wouldn’t start at 1BC for the first century AD in either case though. You would just treat “century” as the name for the period, and ignore that it only has 99 years. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">[[User:HTGS|HTGS]]</span>&nbsp;([[User talk:HTGS|talk]])</span> 19:22, 6 January 2025 (UTC)
*:::You seem to be saying the choice between a century (the first, whether [[first century|AD]] or [[first century BC|BC]]) of 99 or 100 years amounts to personal preference. Do you have credible sources showing they are equally valid? [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 19:23, 7 January 2025 (UTC)
*'''Oppose treating both as acceptable''' This would lead to endless confusion. [[User:Peter coxhead|Peter coxhead]] ([[User talk:Peter coxhead|talk]]) 22:02, 5 January 2025 (UTC)
*'''Oppose''' change;  century starts at ###1 and ends ###0 <!-- Template:Unsigned --><small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Mr Serjeant Buzfuz|Mr Serjeant Buzfuz]] ([[User talk:Mr Serjeant Buzfuz#top|talk]] • [[Special:Contributions/Mr Serjeant Buzfuz|contribs]]) 23:18, 5 January 2025 (UTC)</small>
* '''Strongly oppose''' any change resulting in more than one definition of a century. The reasons seem self-evident, but others have spelt them out above. In a nutshell, such a change would be a retrograde step, against the spirit of the MOS. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 23:21, 5 January 2025 (UTC)
*'''Just use '00s.''' Why on Earth should MoS <em>ever</em> encourage using wording that will be misunderstood by many or most people? To most people, "20th century" means 1900-1999. To pedants of history, it means 1901-2000. Cool. We should try to not confuse either of those groups. If I had to pick one, I'd say confuse the pedants, but fortunately we don't have to pick, because a third option exists: "1900s" (etc.). That's the phrasing I've always used on Wikipedia, for this exact reason. It's consistent with how we refer to decades (see [https://en.wikipedia.org/w/index.php?search=insource%3A%2F%28%5B0-9%5D%7B1%2C2%7D%7C%27%29%5B0-9%5D0s%2F&title=Special:Search&profile=advanced&fulltext=1&ns0=1] vs. [https://en.wikipedia.org/w/index.php?search=decade+insource%3A%2F%281st%7C2nd%7C%5B03-9%5Dth%29+decade%2F&title=Special:Search&profile=advanced&fulltext=1&ns0=1]). It's universally understood. It avoids silly arguments like this one. Let's just do that. <span style="font-family:courier"> -- [[User:Tamzin|<span style="color:#E6007A">Tamzin</span>]]</span><sup class="nowrap">&#91;[[User talk:Tamzin|<i style="color:#E6007A">cetacean needed</i>]]]</sup> <small>([[User:Tamzin/🤷|they&#124;xe&#124;🤷]])</small> 23:36, 5 January 2025 (UTC)
*:And to put this in terms of what the wording should be, I would suggest something like {{tq2|Because phrases like {{!xt|the 18th century}} are ambiguous (sometimes used to mean 1700–1799, sometimes 1701–1800), phrases like {{xt|the 1700s}} are preferable. If the former is be used—for instance, when quoting a source—an explanatory note should be included if the two definitions of ''n''th century would lead to different meanings.}} <span style="font-family:courier"> -- [[User:Tamzin|<span style="color:#E6007A">Tamzin</span>]]</span><sup class="nowrap">&#91;[[User talk:Tamzin|<i style="color:#E6007A">cetacean needed</i>]]]</sup> <small>([[User:Tamzin/🤷|they&#124;xe&#124;🤷]])</small> 23:52, 5 January 2025 (UTC)
*::Is this a joke? <small>Sorry if I ruined it by asking.</small> <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">[[User:HTGS|HTGS]]</span>&nbsp;([[User talk:HTGS|talk]])</span> 23:56, 5 January 2025 (UTC)
*:::No? From any descriptive point of view, there is no widely-accepted definition of "''n''th century". Some Wikipedians thinking there <em>should</em> be a widely-accepted definition doesn't make it so. And MoS should not be in the business of encouraging ambiguous wording. Instead we should encourage solutions that avoid ambiguity, [[MOS:COMMONALITY|much as we do with ENGVAR]]. <span style="font-family:courier"> -- [[User:Tamzin|<span style="color:#E6007A">Tamzin</span>]]</span><sup class="nowrap">&#91;[[User talk:Tamzin|<i style="color:#E6007A">cetacean needed</i>]]]</sup> <small>([[User:Tamzin/🤷|they&#124;xe&#124;🤷]])</small> 00:05, 6 January 2025 (UTC)
*::::Ah, sorry. This is all just not the question at hand though, and it directly contradicts current (well-positioned) guidance.
*::::In any case, I’m sure we’re better off with the ambiguity between 1900–1999 and 1901–2000, which, in most cases, is not really a problem. Your idea introduces an ambiguity between 1900–1910 and 1900–[1999/2000]. This is explicitly called out by [[MOS:CENTURY]], of course. And does “1700s” even solve the issue of which year to start or end with? It {{em|implies}} that the century starts with 1700, but not explicitly. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">[[User:HTGS|HTGS]]</span>&nbsp;([[User talk:HTGS|talk]])</span> 03:05, 6 January 2025 (UTC)
*:We should avoid use of "1900s" to mean anything other than 1900-1909. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 12:29, 6 January 2025 (UTC)
*::What's funny is I have never heard people talk about the 1500s, 1600s, 1700s, 1800s or 1900s, as anything except Jan 1 00 to Dec 31 99. Always 100 years. I checked and I'm shocked our wikipedia article only covers 1900-1910. The only time it gets used as a decade is when the parameters are specifically talking about the 1930s, 1920s, 1910s, and 1900s. Without that fine tuning it's always 100 year period. It would be used [https://www.loc.gov/classroom-materials/united-states-history-primary-source-timeline/progressive-era-to-new-era-1900-1929/womens-suffrage-in-progressive-era/ like the Library of Congress does], or [https://www.uscis.gov/sites/default/files/document/lesson-plans/USHistory_Since_1900_lesson_plan.pdf US history lesson plans]. Usually I would say the "first decade of the 1900s" with no other context. I would amend your comment to say we should never leave 1900s dangling without context. And that's only for 1900s, not anything else.[[User:Fyunck(click)|Fyunck(click)]] ([[User talk:Fyunck(click)|talk]]) 19:36, 6 January 2025 (UTC)
*'''Oppose treating both as acceptable'''; otherwise indifferent to 31 Dec 1999 vs 31 Dec 2000. This is a style decision, but one that affects a lot of content. To use both would be a terrible solution. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">[[User:HTGS|HTGS]]</span>&nbsp;([[User talk:HTGS|talk]])</span> 23:52, 5 January 2025 (UTC)
*'''Oppose change'''; continue using "20th century" for 1901–2000 and "1900s" for 1900–1999. [[User:Doremo|Doremo]] ([[User talk:Doremo|talk]]) 03:48, 6 January 2025 (UTC)
*'''Oppose change''' - The ''n''{{sup|th}} century is 01-00, you can feel free to use "the xx00s" for 00-99.  Neither is prefered to the other, but the meaning is determined by which you use. [[User:Fieari|Fieari]] ([[User talk:Fieari|talk]]) 04:53, 6 January 2025 (UTC)
*:Per the MOS, and as Dondervogel 2 most succinctly puts it above: {{tq|We should avoid use of "1900s" to mean anything other than 1900-1909.}} <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">[[User:HTGS|HTGS]]</span>&nbsp;([[User talk:HTGS|talk]])</span> 19:25, 6 January 2025 (UTC)
*::I somewhat disagree. It is a very ambiguous term so we should avoid use of 1900s at all without context, because obviously readers will be confused. I sure would since I would immediately think a 100 year period just like 1800s , 1700s, and 2000s (25+ years thus far). [[User:Fyunck(click)|Fyunck(click)]] ([[User talk:Fyunck(click)|talk]]) 07:16, 7 January 2025 (UTC)

== Sorting of numerical data with mixed units ==

I need to implement sorting for a table column that mixes different units, but there is no existing guidance on how to do this. For example, the [[half-life]] column on [[Isotopes of thulium]] uses values with different units, ranging from nanoseconds to years. (For years, NUBASE2020 uses a conversion calibrated to the [[tropical year]]: {{nowrap|1=1 year = 365.2422 d}}.{{NUBASE2020|ref}}) –[[User:LaundryPizza03|<b style="color:#77b">Laundry</b><b style="color:#fb0">Pizza</b><b style="color:#b00">03</b>]] ([[User talk:LaundryPizza03|<span style="color:#0d0">d</span>]][[Special:Contribs/LaundryPizza03|<span style="color:#0bf">c̄</span>]]) 04:48, 6 January 2025 (UTC)

:Try this:
{|class="wikitable sortable"
!value!!name
|-
|data-sort-value="100"|100 years||big
|-
|data-sort-value="{{#expr: 2/365.2422}}"|2 days||tiny
|-
|data-sort-value="{{#expr: 10/365.2422}}"|10 days||tiny
|-
|data-sort-value="{{#expr: 20/365.2422}}"|20 days||tiny
|-
|data-sort-value="10"|10 years||mid
|-
|data-sort-value="2"|2 years||small
|}
:Note that anything less than a year is NumDays/365. Of course, you can choose your own base unit.
:See [[Help:Sortable_tables#Specifying_a_sort_key_for_a_cell]] <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 05:04, 6 January 2025 (UTC)
::I don't understand your proposal. I'm pretty sure that sort will need numerical sorting with all values converted to a common unit. –[[User:LaundryPizza03|<b style="color:#77b">Laundry</b><b style="color:#fb0">Pizza</b><b style="color:#b00">03</b>]] ([[User talk:LaundryPizza03|<span style="color:#0d0">d</span>]][[Special:Contribs/LaundryPizza03|<span style="color:#0bf">c̄</span>]]) 05:24, 6 January 2025 (UTC)
:::It is more obvious when you look at the wiki mark-up: <syntaxhighlight lang=wikitext>{|class="wikitable sortable"
!value!!name
|-
|data-sort-value="100"|100 years||big
|-
|data-sort-value="{{#expr: 2/365.2422}}"|2 days||tiny
|-
|data-sort-value="{{#expr: 10/365.2422}}"|10 days||tiny
|-
|data-sort-value="{{#expr: 20/365.2422}}"|20 days||tiny
|-
|data-sort-value="10"|10 years||mid
|-
|data-sort-value="2"|2 years||small
|}</syntaxhighlight> The <code>data-sort-value</code> is what the sort looks at. In this case I have chosen 1 year as the base unit. So 10 days is 10/365.2422 -> {{#expr: 10/365.2422}} . The rest is just for display. Click on the up/down arrows to sort increasing, sort decreasing or return to original (unsorted) order. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 05:35, 6 January 2025 (UTC)
::::Sure, why not. –[[User:LaundryPizza03|<b style="color:#77b">Laundry</b><b style="color:#fb0">Pizza</b><b style="color:#b00">03</b>]] ([[User talk:LaundryPizza03|<span style="color:#0d0">d</span>]][[Special:Contribs/LaundryPizza03|<span style="color:#0bf">c̄</span>]]) 02:10, 7 January 2025 (UTC)

Pages transcluded onto the current version of this page (help):

User:ClueBot III/DoNotArchiveUntil (view source) (template editor protected)
User:HBC Archive Indexerbot/OptIn (view source) (template editor protected)
User:MiszaBot/config (view source) (template editor protected)
Wikipedia:Manual of Style/Dates and numbers (edit)
Wikipedia talk:Manual of Style/Dates and numbers/Archive box (edit)
Template:!xt (view source) (template editor protected)
Template:'" (view source) (template editor protected)
Template:+1 (view source) (template editor protected)
Template:- (view source) (template editor protected)
Template:@ (view source) (template editor protected)
Template:Abot (view source) (template editor protected)
Template:Age in days (view source) (template editor protected)
Template:Archive bottom (view source) (template editor protected)
Template:Archive list (view source) (template editor protected)
Template:Archive top (view source) (template editor protected)
Template:Archive top/styles.css (view source) (template editor protected)
Template:Archives (view source) (template editor protected)
Template:Atop (view source) (template editor protected)
Template:Block indent (view source) (template editor protected)
Template:Block indent/styles.css (view source) (template editor protected)
Template:Calm (view source) (semi-protected)
Template:Char (view source) (semi-protected)
Template:Cite journal (view source) (protected)
Template:Cite web (view source) (protected)
Template:Clear (view source) (protected)
Template:Collapsible list (view source) (template editor protected)
Template:Comma separated entries (view source) (template editor protected)
Template:Convert (view source) (template editor protected)
Template:Diff (view source) (template editor protected)
Template:Em (view source) (template editor protected)
Template:Encodefirst (view source) (template editor protected)
Template:For loop (view source) (template editor protected)
Template:Frac (view source) (template editor protected)
Template:Fraction (view source) (template editor protected)
Template:Fraction/styles.css (view source) (template editor protected)
Template:HasTemplate (view source) (template editor protected)
Template:Hex2dec (view source) (semi-protected)
Template:Human readable duration (view source) (template editor protected)
Template:If empty (view source) (protected)
Template:Ifexist not redirect (view source) (template editor protected)
Template:Ifsubst (view source) (template editor protected)
Template:Key press (view source) (template editor protected)
Template:Key press/styles.css (view source) (template editor protected)
Template:Keypress (view source) (template editor protected)
Template:LASTYEAR (view source) (template editor protected)
Template:Lang (view source) (template editor protected)
Template:Main other (view source) (protected)
Template:Math (view source) (template editor protected)
Template:Mbox (view source) (protected)
Template:Midsize (view source) (extended confirmed protected)
Template:Mono (view source) (template editor protected)
Template:Mono/styles.css (view source) (template editor protected)
Template:NUBASE2020 (view source) (semi-protected)
Template:NUBASE2020/cite journal (view source) (semi-protected)
Template:Nac (view source) (template editor protected)
Template:Nbsp (view source) (protected)
Template:No redirect (view source) (template editor protected)
Template:No spam (view source) (template editor protected)
Template:Nobr (view source) (protected)
Template:Non-admin closure (view source) (template editor protected)
Template:Nowrap (view source) (protected)
Template:Outdent (view source) (template editor protected)
Template:Overbar (edit)
Template:Overline (view source) (template editor protected)
Template:Pagetype (view source) (protected)
Template:Paragraph break (view source) (protected)
Template:Pb (view source) (protected)
Template:Ping (view source) (template editor protected)
Template:Plainlist/styles.css (view source) (protected)
Template:Reply to (view source) (template editor protected)
Template:Replyto (view source) (template editor protected)
Template:Resize (view source) (template editor protected)
Template:Rfc (view source) (template editor protected)
Template:Rfc/topic (edit)
Template:Rto (view source) (extended confirmed protected)
Template:Search box (view source) (template editor protected)
Template:Section link (view source) (template editor protected)
Template:Shortcut (view source) (template editor protected)
Template:Side box (view source) (template editor protected)
Template:Single+double (view source) (template editor protected)
Template:Slink (view source) (extended confirmed protected)
Template:Smalldiv (view source) (template editor protected)
Template:Snd (view source) (template editor protected)
Template:Spaced en dash (view source) (template editor protected)
Template:Spaces (view source) (protected)
Template:Strong (view source) (template editor protected)
Template:Stylized LaTeX (edit)
Template:Sup (view source) (template editor protected)
Template:Tag (view source) (template editor protected)
Template:Talk header (view source) (template editor protected)
Template:Talk header/archivebotparse (view source) (template editor protected)
Template:Talk header/styles.css (view source) (template editor protected)
Template:Talk other (view source) (protected)
Template:Talk quote block (view source) (template editor protected)
Template:Talk quote block/styles.css (view source) (template editor protected)
Template:Talk quote inline (view source) (template editor protected)
Template:Talk quote inline/styles.css (view source) (template editor protected)
Template:Talkheader (view source) (protected)
Template:Template link (view source) (protected)
Template:Template link expanded (view source) (protected)
Template:Template link null (view source) (template editor protected)
Template:Template other (view source) (protected)
Template:Template parameter value (view source) (template editor protected)
Template:Th/abp (view source) (template editor protected)
Template:Tl (view source) (protected)
Template:Tlx (view source) (protected)
Template:Tmbox (view source) (protected)
Template:Tmpv (view source) (template editor protected)
Template:Tnull (view source) (template editor protected)
Template:Tooltip (view source) (template editor protected)
Template:Tooltip/styles.css (view source) (template editor protected)
Template:Tq (view source) (template editor protected)
Template:Tq2 (view source) (extended confirmed protected)
Template:Tqb (view source) (extended confirmed protected)
Template:Trim (view source) (protected)
Template:U (view source) (template editor protected)
Template:Unichar (view source) (semi-protected)
Template:Unichar/gc (view source) (semi-protected)
Template:Unichar/glyph (view source) (semi-protected)
Template:Unichar/hexformat (view source) (semi-protected)
Template:Unichar/main (view source) (semi-protected)
Template:Unichar/name (view source) (semi-protected)
Template:Unichar/notes (view source) (semi-protected)
Template:Unichar/ulink (view source) (semi-protected)
Template:User link (view source) (template editor protected)
Template:Userbox (view source) (template editor protected)
Template:Void (view source) (template editor protected)
Template:WikiProject Manual of Style (edit)
Template:WikiProject banner shell (view source) (template editor protected)
Template:Xt (view source) (template editor protected)
Template:Yearly archive list (view source) (template editor protected)
Template:Yearly archive list/display (view source) (template editor protected)
Template:Yesno (view source) (protected)
Template:Yesno-no (view source) (template editor protected)
Template:Yesno-yes (view source) (template editor protected)
Module:Age (view source) (template editor protected)
Module:Archive list (view source) (template editor protected)
Module:Arguments (view source) (protected)
Module:Banner shell (view source) (template editor protected)
Module:Banner shell/config (view source) (template editor protected)
Module:Banner shell/styles.css (view source) (template editor protected)
Module:BaseConvert (view source) (template editor protected)
Module:Category handler (view source) (protected)
Module:Category handler/blacklist (view source) (protected)
Module:Category handler/config (view source) (protected)
Module:Category handler/data (view source) (protected)
Module:Category handler/shared (view source) (protected)
Module:Check for deprecated parameters (view source) (template editor protected)
Module:Check for unknown parameters (view source) (protected)
Module:Citation/CS1 (view source) (protected)
Module:Citation/CS1/COinS (view source) (protected)
Module:Citation/CS1/Configuration (view source) (protected)
Module:Citation/CS1/Date validation (view source) (protected)
Module:Citation/CS1/Identifiers (view source) (protected)
Module:Citation/CS1/Utilities (view source) (protected)
Module:Citation/CS1/Whitelist (view source) (protected)
Module:Citation/CS1/styles.css (view source) (protected)
Module:Collapsible list (view source) (template editor protected)
Module:Convert (view source) (template editor protected)
Module:Convert/data (view source) (template editor protected)
Module:Convert/text (view source) (template editor protected)
Module:ConvertNumeric (view source) (template editor protected)
Module:Date (view source) (template editor protected)
Module:Exponential search (view source) (template editor protected)
Module:For loop (view source) (template editor protected)
Module:Human readable duration (view source) (template editor protected)
Module:If empty (view source) (protected)
Module:InfoboxImage (view source) (template editor protected)
Module:Key (view source) (template editor protected)
Module:Lang (view source) (template editor protected)
Module:Lang/ISO 639 synonyms (view source) (template editor protected)
Module:Lang/configuration (view source) (template editor protected)
Module:Lang/data (view source) (template editor protected)
Module:Lang/data/iana languages (view source) (template editor protected)
Module:Lang/data/iana regions (view source) (template editor protected)
Module:Lang/data/iana scripts (view source) (template editor protected)
Module:Lang/data/iana suppressed scripts (view source) (template editor protected)
Module:Lang/data/iana variants (view source) (template editor protected)
Module:List (view source) (protected)
Module:Message box (view source) (protected)
Module:Message box/configuration (view source) (protected)
Module:Message box/tmbox.css (view source) (protected)
Module:MultiReplace (view source) (template editor protected)
Module:Namespace detect/config (view source) (protected)
Module:Namespace detect/data (view source) (protected)
Module:Outdent (view source) (template editor protected)
Module:Pagetype (view source) (protected)
Module:Pagetype/config (view source) (protected)
Module:Pagetype/rfd (view source) (protected)
Module:Pagetype/softredirect (view source) (protected)
Module:Redirect (view source) (protected)
Module:Reply to (view source) (template editor protected)
Module:Section link (view source) (template editor protected)
Module:Separated entries (view source) (protected)
Module:Shortcut (view source) (template editor protected)
Module:Shortcut/config (view source) (template editor protected)
Module:Shortcut/styles.css (view source) (template editor protected)
Module:Side box (view source) (template editor protected)
Module:Side box/styles.css (view source) (template editor protected)
Module:String (view source) (protected)
Module:TableTools (view source) (protected)
Module:Template link general (view source) (protected)
Module:Template parameter value (view source) (protected)
Module:Unicode data (view source) (template editor protected)
Module:Unicode data/names/000 (view source) (semi-protected)
Module:Unicode data/names/002 (view source) (semi-protected)
Module:Unicode data/scripts (view source) (template editor protected)
Module:Unsubst (view source) (protected)
Module:Userbox (view source) (template editor protected)
Module:WikiProject banner (view source) (protected)
Module:WikiProject banner/config (view source) (protected)
Module:WikiProject banner/styles.css (view source) (protected)
Module:Wikitext Parsing (view source) (protected)
Module:Yesno (view source) (protected)

Return to Wikipedia talk:Manual of Style/Dates and numbers.

Retrieved from "https://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style/Dates_and_numbers"