< Misplaced Pages talk:Manual of Style Browse history interactively← Previous editContent deleted Content addedVisualWikitextInline

Revision as of 01:06, 28 January 2007 editGuy Harris (talk | contribs)Extended confirmed users76,615 editsm →Converting to SI prefixes: Fix typo.← Previous edit		Latest revision as of 19:36, 10 January 2025 edit undoEEng (talk | contribs)Edit filter helpers, Autopatrolled, Extended confirmed users, New page reviewers, Pending changes reviewers, Template editors97,963 edits →RfC on the wording of MOS:CENTURY: fmt (hope you don't mind, User:Dondervogel 2)
Line 1:		Line 1:
			{{talkheader|sc1=WT:DATE|sc2=WT:MOSDATE}}
	==Archives==
			{{Calm}}
	{| class="infobox" width="270px"
			{{WikiProject banner shell|
	|-
			{{WikiProject Manual of Style}}
	!align="center"|]<br>]
			}}
	----
			{{User:MiszaBot/config
	|-
			|archiveheader = {{aan}}
	|
			|maxarchivesize = 800K
	*], ], ], ], ], '']'', ], ], ], ], ],
			|counter = 163
	*], ], ], ], '']'', ], ], ], ], ],
			|minthreadsleft = 2
	*], ], ], ], ], ], ], ], ], ],
			|minthreadstoarchive = 1
	*], ], ], ], ], ], ], ], ], ],
			|algo = old(60d)
	*], ], ], ], ], ], ], ], ], ], '']'',
			|archive = Misplaced Pages talk:Manual of Style/Dates and numbers/Archive %(counter)d
	*], ], ], ], ], ], ], ], ], ]
			}}
	*], ],
			{{User:HBC Archive Indexerbot/OptIn
			|target=Misplaced Pages talk:Manual of Style/Dates and numbers/Archive index
			|mask1=Misplaced Pages talk:Manual of Style/Dates and numbers/Archive <#>
			|mask2=Misplaced Pages talk:Manual of Style/Dates and numbers/Archive zero
			|mask3=Misplaced Pages talk:Manual of Style/Dates and numbers/Archive B<#>
			|mask4=Misplaced Pages talk:Manual of Style/Dates and numbers/Archive D<#>
			|leading_zeros=0
			|indexhere=yes }}
			{{Misplaced Pages talk:Manual of Style/Dates and numbers/Archive box}}
			{{tmbox|image=] |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 ==
	|}<!--Template:Archivebox-->
			A string of edits by ] and ]. introducing and removing changes to {{slink|Misplaced Pages:Manual of Style/Dates and numbers|Common mathematical symbols}}, raise issues that I believe should be discussed.
	See also:
	* ]
	* ]
	* ]
			#The most recent change, ], 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 ], despite the comment.
			#There seems to be disagreement on the division sign.
			The questions that I wish to raise are
	== A new parallel syntax for autoformatting dates ==
			#Should that section mention {{tl|tmath}} or {{tag|math}}?
	===Text of initial request===
			#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 ]?
			#Is ] unhelpful since it has three forms?
			#Should the ] ({{Unichar|F7}}) be deprecated in favor of ] ({{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 ]?
			-- ] (]) 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 Misplaced Pages. This isn't a style manual for writing outside of Misplaced Pages.
			::] (]) 19:45, 27 September 2024 (UTC)
			:Tbh, I wondered what this extensive list is doing in the MOS in the first place. ] 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 ].
			:* 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.
			:] (]) 20:04, 27 September 2024 (UTC)
			:Comments:
			:*I see no good reason to prohibit using a ] to express division. That seems absolutely fine. The ] article seems to say it might be confusing in Italian, Russian, Polish, Danish, Norwegian, or Swedish, but this is the English Misplaced Pages. We use ]s as ]s also, and we use ]s as a ] 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).
			:—⁠ ⁠] (]) 21:46, 7 October 2024 (UTC)
			:: Asterisk means ] (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. — ] (]) 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 ] or ] instead. —⁠ ⁠] (]) 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 more like a superscript than a binary operator consistent with +, −, = and so on).
			::::: I don't think we should feel responsible for how Misplaced Pages is rendered in all possible fonts. We should remember that everyone is supposed to be able to edit Misplaced Pages 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. —⁠ ⁠] (]) 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 Misplaced Pages. Other editors who care about typography and MoS can clean up the markup and character choices later. Misplaced Pages is a collaborative project. ] (]) 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. ] (]) 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. ] (]) 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. --] (]) (]) 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>. --] &#x1f339; (]) 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 ] 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 ]. 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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&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 . ]] 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 '']'' back to 1902 (gaps between 1902 and 1939, complete from 1940 onward). --] &#x1f339; (]) 12:02, 13 November 2024 (UTC)
			:::::] was a decade earlier than ] and ]. What the first FORTRAN compiler used was the scientific ] character set of the ], which replaced the older Percent (%) and Lozenge ({{unichar|2311}}) with parentheses. -- ] (]) 14:35, 13 November 2024 (UTC)
			== Numerals in a sequence ==
	:<div style="padding:10px; background-color:#E6E6FA">Please create an additional syntax for autoformatting dates that does not make hyperlinks to date pages. The current syntax conflates the two independent functions of autoformatting and linking. The current syntax is simple; it would be an advantage if the additional syntax were also simple.
			'Phase 1' or Phase one'? This appears to be a case that's not explicitly covered.
	:<div style="padding:10px; background-color:#E6E6FA">The new syntax is conceived not as a replacement but as an alternative, retaining (1) the option to link to a chronological article where useful, and (2) the validity of the huge number of date-links already marked up in the project.
			The AP Stylebook recommends using figures for sequences in its section on "Numbers":
	:<div style="padding:10px; background-color:#E6E6FA">There are significant advantages to allowing autoformatted dates to be black rather than blue, where there is consensus to do so in an article. Specifically, reducing the density of blued-out links will:
			"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.
	:<div style="padding:10px; background-color:#E6E6FA">(1) improve the readability of the text;
	:<div style="padding:10px; background-color:#E6E6FA">(2) improve the aesthetic appearance of the text;
	:<div style="padding:10px; background-color:#E6E6FA">(3) remove low-value chronological links that may lead readers to pages that are irrelevant to an article;
	:<div style="padding:10px; background-color:#E6E6FA">(4) increase the prominence of high-value links;
	:<div style="padding:10px; background-color:#E6E6FA">(5) reduce the spill-over effect, in which editors feel they should link centuries, decades, and bare years, months and days of the week; and
	:<div style="padding:10px; background-color:#E6E6FA">(6) reduce conflict.
			Similarly, chapter 9 of The Chicago Manual of Style advises using figures when referring to a sequence.
	:<div style="padding:10px; background-color:#E6E6FA">This request is signed by . Some supporters have suggested specific mark-ups, such as <<date>>, but on balance it is considered best that the developers use their expertise to choose the most appropriate mark-up.
			I propose adding similar explicit advice to this section of the MOS.
	] 10:25, 13 December 2006 (UTC)
			-- ] (]) 20:10, 19 October 2024 (UTC)
	===List of supporters===
			*As usual, what's needed before something's added to MOS is examples of this being an issue on multiple articles -- see ]. 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, ] 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. ]] 22:00, 19 October 2024 (UTC)
	Please add your name here if you agree in principle for your name to be listed in the initial request. The more names the better. At any stage before the request, you can of course remove your name. --] 05:06, 9 December 2006 (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 ] 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. -- ] (]) 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 so unless the inquiry's inconsistent, we can follow that source. Still, I see that this is a live issue at that ] 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}}. ] (]) 14:56, 20 October 2024 (UTC)
			*:::Between ] and ], 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. --] &#x1f339; (]) 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? ] (]) 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). ] (]) 16:37, 21 October 2024 (UTC)
			*::::::It is indeed a matter of internal consistency and it does look bad, as ] says. Within the one article (]), we have (e.g.) both "Phase 3 hearings" and "Phases five and six". Is there in fact a rule addressing this general issue? -- ] (]) 18:47, 21 October 2024 (UTC)
			*::::::From ]: "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. --] (]) (]) 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. ] (]) 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 ]. 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 ]. Articles are often titled ''&lt;show&gt; season &lt;n&gt;'' where n is a digit, never a word, in accordance with ]. Sampling our ], 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 ], that FA and GA assessors will start to apply ] in such cases, that any move requests would succeed, or that ] and ] will be brought into line with the current ]. Changing ] might be easier. ] (]) 08:20, 23 October 2024 (UTC)
			*::::::::I agree, a small addition to MOS:NUMERAL might be a good thing. ] (]) 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. ] (]) 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" or "3rd century BC" 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 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'"> — ] ] ] 😼 </span> 15:04, 24 November 2024 (UTC)
			== μs vs us ==
	# ] 05:06, 9 December 2006 (UTC)
	# ]&nbsp;] 05:27, 9 December 2006 (UTC)
	# ] (]) 05:36, 9 December 2006 (UTC)
	# ] 14:22, 9 December 2006 (UTC)
	# ] ]'', 14:53 ] ] (GMT).
	# ]<small> (] | ])</small> 16:02, 9 December 2006 (UTC)
	# ] 16:07, 9 December 2006 (UTC)
	# ] 16:29, 9 December 2006 (UTC)
	# ] (]) 16:58, 9 December 2006 (UTC)
	# ] 17:06, 9 December 2006 (UTC)
	# ] 20:57, 9 December 2006 (UTC) -- strongly agree: links should be human generated
	# ] 23:54, 9 December 2006 (UTC) -- as per Doom
	# per Outriggr -- ] 01:03, 10 December 2006 (UTC)
	# ] 01:47, 10 December 2006 (UTC) -- Have had to clean up useless date links from several articles.
	# Most of the time date links are irrelevant and distracting. ''']'''<font color="green">]</font> 02:03, 10 December 2006 (UTC)
	# ] 02:25, 10 December 2006 (UTC)
	# ] 02:37, 10 December 2006 (UTC)
	# ]] 02:41, 10 December 2006 (UTC)
	# ] 03:02, 10 December 2006 (UTC)
	# ] 04:28, 10 December 2006 (UTC)
	# ] 04:40, 10 December 2006 (UTC)
	# clear and should be helpful. ] 05:21, 10 December 2006 (UTC)
	# ]]]]]] 05:28, 10 December 2006 (UTC) I support (indeed like others in this list - I have always supported this view and versions that have worked towards a similar end) - and now I await the same-same ''naysayer'' brigade...
	# I'm all for reducing the number of irrelevant blue links. Just cleaned up some an hour back . I support the move with the possibility that we can also have the a new functionality for the time too. ] ] 06:28, 10 December 2006 (UTC)
	# Agreed on general principle. This would help a lot with the less useful links. ] 06:32, 10 December 2006 (UTC)
	# Warmly agreed in principle. <s>(But couldn't the request be phrased in a way that's less pompous but just as clear? Or perhaps all such requests hereabouts are phrased in this style; I really don't know.)</s> -- ] 08:07, 10 December 2006 (UTC) .... PS <s>in response to Tony's invitation on my talk page, I hurriedly revised ''this'' request there.</s> I find President Lethe's proposal below (and as elaborated ]) very persuasive. -- ] 22:12, 10 December 2006 (UTC) ... PPS struck though obsolete material 00:51, 12 December 2006 (UTC)
	# Support the idea. --] 08:28, 10 December 2006 (UTC)
	# Strong support, I previously campaigned for this; hopefully we'll get someone to implement it in MediaWiki this time. <span class="user-sig user-Quarl"><i>—] <sup>(])</sup> <small>2006-12-10 08:39Z</small></i></span>
	# ] ] - ] 10:08, 10 December 2006 (UTC)
	#] ] 10:28, 10 December 2006 (UTC)
	#] 11:57, 10 December 2006 (UTC)
	# —] <small>(] • ])</small> 12:01, 10 December 2006 (UTC)
	# ] | ] 12:47, 10 December 2006 (UTC)
	# '''<font color="navy">]</font>''' 13:53, 10 December 2006 (UTC) Keep the request simple/single issue.
	#] (]) 15:32, 10 December 2006 (UTC)
	#--] 15:35, 10 December 2006 (UTC) I support this request. The current method in addition to the faults mentioned above is non-intuitive and consufing.
	# '''I strongly support this proposal. Links should support and advance the primary focus of the article. ] 15:47, 10 December 2006 (UTC)'''
	#] 15:49, 10 December 2006 (UTC) As Michael said, Links should support and advance the primary focus of the article.
	#&mdash; ''']]]''' 15:58, 10 December 2006 (UTC)
	#] 16:11, 10 December 2006 (UTC)
	# Yes, and I tried to lead the charge on this the last time, too. --] 16:37, 10 December 2006 (UTC)
	# Good idea, full support in principle, presuming some appropriate syntax can be found. ] 16:51, 10 December 2006 (UTC)
	# ] 17:33, 10 December 2006 (UTC) — I support this '''with reservations and/or extra requirements'''. See my comments ] ''and immediately above this section .''
	# ] 17:49, 10 December 2006 (UTC)
	# ] 18:03, 10 December 2006 (UTC) Oh, absolutely support this, as simply cannot understand why the date I accessed a web reference should be blue linked. Check out the ] article, and related, some time to see the absurdity of links that ruins articles on Misplaced Pages.
	# I like the wording and context. Kudos to getting this restarted. -- '']']'' 18:20, 10 December 2006 (UTC)
	# I '''support''' the idea, specifically the request as expressed in the proposal. I reserve my opinion about other issues and suggestions raised in the comments to the proposal. ] 19:04, 10 December 2006 (UTC) ''As I noted in reply to the initial proposal:''<blockquote> I'm with Outriggr and Tony1. I agree in principle that auto-formatted non-linking dates is a Very Good Idea, and that the worst thing we can do in support of that idea is to over-specify it. The first sentence of the request should be the '''entire''' request, with the remainder justifying it. ] 19:04, 10 December 2006 (UTC)</blockquote>
	# '''Support'''. The fact that dates must be linked in order to autoformat is terrible. Dates should be linked ''only'' when it is useful to link them, i.e. when the date's article is likely to be of interest to the reader. Dates should never be linked under other circumstances, and the software should provide a way to implement this without losing the autoformat capability.--] 20:00, 10 December 2006 (UTC)
	# Long overdue. Something like ||February 10|| would be ideal. --]<sup>]</sup> 21:43, 10 December 2006 (UTC)
	#*<nowiki>||February 10||</nowiki> would clash with ]. (This is why I think we should let the developers decide on the syntax: they're in the best position to think about these things). ] (]) 10:29, 11 December 2006 (UTC)
	# ''] 00:25, 11 December 2006 (UTC)''
	# Date linking and format preferences have different purposes. Don't overload them; it devalues highly relevant date links and overvalues totally irrelevant date links (e.g. ]), and has collateral effects. —]→]&nbsp;&bull; 01:27, 11 December 2006 (UTC)
	# ] 02:22, 11 December 2006 (UTC)
	# ] 06:27, 11 December 2006 (UTC)
	# It'd be a huge improvement. &mdash;] 08:10, 11 December 2006 (UTC)
	# Agree, black should be the default with linked dates available for useful context. .. ], ] 09:14, 11 December 2006 (UTC)
	# Oh, yes, I'm a supporter. This might reduce mindless rollbacks as well. ] 10:18, 11 December 2006 (UTC)
	# ] 13:34, 11 December 2006 (UTC)
	# ] 17:26, 11 December 2006 (UTC) Support in principle.
	# ] 20:05, 11 December 2006 (UTC)
	# Support as per user Centrx, date linking and format preferences have different purposes ] <sup>]</sup> 20:15, 11 December 2006 (UTC)
	# ] 21:46, 11 December 2006 (UTC)
	# ] Oh, I can only hope, the current proliferation of year links makes them all but useless ] 21:53, 11 December 2006 (UTC)
	# Seems to be a good idea. ] 22:04, 11 December 2006 (UTC)
	# Sounds like a good idea ] |] 03:52, 12 December 2006 (UTC)
	# --] 04:43, 12 December 2006 (UTC)
	#Like the idea a lot. ] (]) 21:10, 12 December 2006 (UTC)
	#] <sup>]</sup> 21:45, 12 December 2006 (UTC)
	#Brilliant idea. ] &middot; <small>]</small> 06:58, 13 December 2006 (UTC)
	# ] 08:03, 13 December 2006 (UTC) Fully agree in principle.
	# I hope this goes through! — Reinyday, 18:14, 14 December 2006 (UTC)
	# ] <sup><font color="#E32636">]</font></sup><sub><font color="#177245">]</font></sub> 13:02, 17 December 2006 (UTC) This is an intelligent solution to the problem of date linking, and I support it wholeheartedly.
	# Absolutely. --]<sup>]</sup>&nbsp;<small><font color="brown">]</font></small> 19:49, 17 December 2006 (UTC)
	#] 02:07, 5 January 2007 (UTC) If when I wikilinked, I received a list of all other important events that happened on that month-day, that'd be neat. But if all I find out is it is day X on the Gregorian calendar ... it seems pretty useless ... other than for displaying dates in the form of my preferences.
	#Good idea. --] <small>]</small> 02:10, 5 January 2007 (UTC)
	# Excellent idea - esp per points 3 and 5 --] 01:47, 6 January 2007 (UTC)
	# '''Strong support''' ] 01:34, 9 January 2007 (UTC)
	# Oh my yes! Make links explicit (once in a while they actually are needed) rather than implicit (most of the time they are not) ++]: ]/] 05:29, 13 January 2007 (UTC)
	# I would like that very much. ] 00:28, 22 January 2007 (UTC)
	# Linked dates, and cities, countries etc, that have no special relevance to the article is an unnecessary eyesore.Strongly agree.] 10:18, 22 January 2007 (UTC)
	# If articles can't be marked up in accordance with common sense and Misplaced Pages guidelines, so as only to link significant terms, then this is a reasonable move. It's just a pity that it's necessary. --] 11:30, 23 January 2007 (UTC)
	# This would be a great improvement. <font face="Trebuchet MS, Trebuchet"><i><b>]]</b></i></font>
			Which style I should use for micro seconds? Does μs "Do not use precomposed unit symbol characters"? ] (]) 04:44, 30 October 2024 (UTC)
	===Amendments===
			: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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&nbsp;</span></span> 04:53, 30 October 2024 (UTC)
	Please debate the autoformatting/linking issue here, and keep the text and list of supporters relatively simple and neat. Please note that this is framed as a "minimalist" request, under the assumption that that is most likely to succeed. ] 07:22, 11 December 2006 (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'"> — ] ] ] 😼 </span> 15:09, 24 November 2024 (UTC)
			== Day, date month format ==
	I have one: Let the developers expand colon-prefixed wikilinking (e.g., <nowiki>]</nowiki>) to distinguish whether or not to wikilink (or blue-link) an auto-formatted date. Since we already use the colon syntax to produce text wikilinks to categories and images, expanding it to dates would be simple and easy for everyone to learn.
	*Method 1: '''<nowiki>]</nowiki>''' produces a '''non'''-linked (or '''black'''-linked) date, while '''<nowiki>]</nowiki>''' produces a blue-linked date. I believe this is the more intuitive option, but it is not necessarily backwards compatible.
	*Method 2 - Vice versa: '''<nowiki>]</nowiki>''' produces a blue-linked date, while '''<nowiki>]</nowiki>''' produces a non-linked (or black-linked) date. This is backwards compatible, only low-importance links need to be changed. But it is arguably less intuitive to adjust to.
			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? —] (]) 04:28, 4 November 2024 (UTC)
	If added into the proposal text, then this would let the developers know that we have specific ideas on exactly ''how'' to address the issue (rather than merely saying what the issue is and leaving all the rest to the developers), however no solution is perfect, and not everyone may agree on exactly what the solution should be. --''00:48, 11 December 2006 (UTC)''
			*] and ] 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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&nbsp;</span></span> 06:16, 4 November 2024 (UTC)
			*:This specifically regards the "]" article, and its Konomiya Hadaka Matsuri infobox, which includes the days of the week. —] (]) 07:40, 4 November 2024 (UTC)
			*::Ah, the mysterious East. ]] 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" (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 ]. ]] 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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&nbsp;</span></span> 09:18, 4 November 2024 (UTC)
			:::Okay—will do. Thank you both. ^_^ —] (]) 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.
			:] (]) 16:56, 4 November 2024 (UTC)
			:Concur with EEng on avoiding adding a rule about this, as more ]. 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'"> — ] ] ] 😼 </span> 15:18, 24 November 2024 (UTC)
			==Spacing with percentage points==
	:Still retains problem of how would you perform a link to a full date article (some of which exist, such as ]) *and* keep user preferences working. If they come up with a new syntax, hopefully it can handle flexible, optional linking. --] (]) 00:34, 11 December 2006 (UTC)
			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 ] 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, ] ]] 23:49, 5 November 2024 (UTC)
			*] says "omit space". <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&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? ] ]] 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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&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 ] article uses a space before ''bp'' (mostly, anyway). I'll be interested to hear what others think. ]] 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. ] (]) 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. ] ] 11:10, 8 November 2024 (UTC)
			*::Absolutely. When it comes to peepee, always space it . ]] 21:36, 8 November 2024 (UTC)
			*:Yes, "%" is an ISO standard unit symbol. ] (]) 12:45, 8 November 2024 (UTC)
			*::What is it the unit of? ] (]) 13:14, 8 November 2024 (UTC)
			*:::Nothing. It's a ]. 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 ]. --] &#x1f339; (]) 19:58, 8 November 2024 (UTC)
			*::::It's used widely in election infoboxes where there isn't space to write it out. ] ]] 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 (%). ] (]) 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. ] (]) 22:16, 8 November 2024 (UTC)
			*:::I found this in
			*:::*In keeping with Ref. , 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 . 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. ] (]) 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 Misplaced Pages (see ]), so I don't see how any of that helps us with the issue at hand. ]] 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. ] (]) 00:24, 9 November 2024 (UTC)
			*:::::::Um, OK, but you do realize that WP does not follow NIST's advice about spacing it, yes? ]] 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? ] (]) 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 "percent", is spaced apart from the numeral is irrelevant. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 15:24, 24 November 2024 (UTC)
			== UNITSYMBOLS (1 × 3 × 6 m): “each number should be followed by a unit name or symbol” ==
	::I don't know for certain, but I suspect that user date preferences should apply only to the ''text'' of a wikilinked date (same effect as a piped link) and not the actual target article. --''] 00:48, 11 December 2006 (UTC)''
			] 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?
	::Alternately, I suppose triple-brackets is another option, e.g., '''<nowiki>]]</nowiki>''' versus '''<nowiki>]</nowiki>''', where both are auto-formatted, one is linked but the other is not. And the target article for a given date probably already has redirects set up to accommodate different user preferences. (Which is probably a good idea to implement ''anyway''....)) --''] 00:50, 11 December 2006 (UTC)''
			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 ] 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.
	:::Upon further retrospect (and review of the current proposal version), I'm going to summarize all that -- developers implement a solution by which:
	:* All existing date-formatted links are rendered in black text instead of blue, and for high-value dates of interest we use the colon prefix or triple-brackets to make them appear blue-linked.
	:* OR vice versa, existing links are unaffected and we apply the colon prefix or triple-brackets to turn low-value / non-relevant date links as black (normal) text.
	:::--''] 01:02, 11 December 2006 (UTC)''
			Prior discussion: ], 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">]</span>&nbsp;(])</span> 04:17, 11 November 2024 (UTC)
	:::I think both of these options are sub-par to other proposals I've seen, such as a <nowiki>{{date|}}</nowiki> template or new syntax for preferences such as <nowiki><<date>> or ||date||</nowiki>. They do not address linking to full dates (<nowiki>] ]]]</nowiki> seems unlikely to please) and also don't take the comma issue that others have raised into account. This proposal was left without a specific syntax defined so that a clear voice can be heard that change is needed. The developers are smart and can either come up with syntax they want to implement (syntax isn't even that important, as long as it gets the job done) or solicit the community for ideas. That's my opinion anyway. --] (]) 02:42, 11 December 2006 (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>. ] (]) 12:13, 11 November 2024 (UTC)
	::::<nowiki>||date||</nowiki> would clash with ]. ] (]) 10:26, 11 December 2006 (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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&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. ]] 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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&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? ]] 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. ] (]) 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. ]] 23:56, 11 November 2024 (UTC)
			::::::Seconded EEng's proposal - simple and clear. <span style="background:#ff0000;font-family:Times New Roman;">]]</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. ] (]) 05:51, 14 November 2024 (UTC)
			:::::::{{tq|EEng is, of course, correct.}}{{snd}}Of course -- . ]] 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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&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. ] </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">]</span>&nbsp;(])</span> 23:34, 18 November 2024 (UTC)
			*It's tiresome to have to write (and read) units multiple times when multiplication signs are used. ] ] 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: ]. <span style="font-family:Avenir, sans-serif">—&nbsp;<span style="border-radius:5px;padding:.1em .4em;background:#faeded">]</span>&nbsp;(])</span> 23:34, 18 November 2024 (UTC)
			==Do we have to convert inches for wheels?==
	<s> :Would the simplier solution be for WP software to parse any text that has the valid name of a month and a valid day (in either order) and just display the date based on preference, not requiring any text encoding at all to handle this? Thus 'January 20' or '20 January' could be in the text and would simply be displayed correctly because the WP software would be smart enough to know what to do. I could code this to happen with my own software programs; I am sure WP software could do this also. ] 02:00, 11 December 2006 (UTC)</s>
			I see people adding conversions to mentions of screen sizes and wheel dimensions - is this really necessary? Even in or , automobile and bike wheels are universally referred to by inches; rim diameters are expressly . 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;">]]</span> 17:24, 13 November 2024 (UTC)
	::There are cases where this is incorrect (inside of quoted text, article names, etc.) --] (]) 02:28, 11 December 2006 (UTC)
			:It looks like sizing bike wheels in inches is not universal. I see many charts in the I-net such as that use both metric and imperial/American units for bike wheels and tires. Whether the convert template handles them correctly is another issue. ] 17:43, 13 November 2024 (UTC)
	:(Sorry if this comment isn't in the best place.) Of course, if we stopped worrying about the readers who somehow don't know that "December 10" means "10 December" (or vice versa), then we wouldn't have to bother with any of this stuff about HTMLing the blue out of links, or using triple brackets or colons or bracey templates or angle brackets, &c. Rather than develop new encoding, why not just stop trying to accomodate a very silly aspect of pickiness? Think about it: how long would this discussion last if it were about magically encoding "color" to be "colour" and vice versa? And is Misplaced Pages really made superior by having this "One way of writing a date results in multiple ways of displaying it" function? It's true that, at some other websites, you can choose how you want your dates displayed; but this applies only to automatic dates, not to, say, the ''body'' of a message posted by someone at a forum. I really don't think Misplaced Pages is made better by expanding the realm of date variability; I do think a ton of editors who could be improving Misplaced Pages's content in more-important ways are being distracted by this niggling little matter. If people can learn to add a third colon or HTML, or to put the comma outside of the upcoming quotation marks, and if they can tell that "standardize" is just about the same as "standardise", then they probably can get used to reading and writing dates in just one way for one website. — ] 03:34, 11 December 2006 (UTC)
			:On the matter of wheel sizes, not all are inches. See ] 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. --] &#x1f339; (]) 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;">]]</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. ] (]) 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;">]]</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. ] (]) 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. ] ] 07:30, 22 November 2024 (UTC)
			*:I thought that ] 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. ] (]) 22:06, 22 December 2024 (UTC)
			==RfC Indian numbering conventions==
	::Well, the real issue is merely that the only way to auto-format dates in Misplaced Pages articles is to wikilink them. This results in visual clutter, links with no relevance to the article or context in question, etc. And btw, I experimented with trying to make a template to do something like this, but the simple and obvious approach to templating it didn't work (it black-colored the link perfectly, but didn't autoformat the date), Misplaced Pages software does not (yet) support the string ParserFunctions defined by Meta, and I don't think templates have any means to access user preferences to figure out what date format to use. --''] 04:45, 11 December 2006 (UTC)''
			{{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'''.
	:::I've been thinking more about this, inspired partly by ]; and I think that the following is both the simplest of the options that I favor ''and'' the simplest ''to implement'':
			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.
	:::Let's think about what we do for all the rest of Misplaced Pages. It boils down to exactly three points:
	:::• (1) in some aspects of written style, we have one rule for everyone to follow (for example, you don't use an unspaced hyphen when an em dash is in order);
	:::• (2) for certain style issues, writers and editors use a variety of standards (for example, whether to write "color" or "colour", and whether SI units are the main ones or the ones in parentheses), and readers have to read articles as they're written (there's no fancy little tool that converts ''neighbour'' to ''neighbor'' and vice versa);
	:::• (3) the main kind of special encoding used is just for making cross-references, and the only way in which a cross-reference can be made to be displayed as anything other than the name that it points to is with piping (e.g., <nowiki>]</nowiki> shows up as "two" but points to the "one" article).
			{{nac}} ] (]) 22:02, 24 December 2024 (UTC)
	:::We could apply this same logic, which has worked fairly satisfactorily for the entire rest of Misplaced Pages, to the date issue. If we do this, allowing dates to continue to be written with their components in multiple orders (e.g., "10 December" and "December 10"), and removing from the present form of date encoding this magical display variability, then we get these results:
			}}
			<!-- ] 17:01, 21 December 2024 (UTC) -->{{User:ClueBot III/DoNotArchiveUntil|1734800468}}
			I am revisiting an issue that was last brought up 6 years ago ] 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 Misplaced Pages's role as an information tool for everyone.
	:::• Picky writers are allowed to put dates in whichever format (from a short list of acceptable standards) they prefer. (This is ''already'' what happens.)
	:::• Picky readers sometimes have to tolerate dates in formats that they don't prefer (just as they have to accept ''color'' or ''colour''). (This ''already happens'' every time a date isn't encoded as a link or isn't written according to the MoS's guidelines, and happens in comma screwups with some coded links.)
	:::• Dates are encoded only for the purpose of ''cross-referencing''. (This is the rule that we ''already'' use for ''everything else'' at Misplaced Pages (make it a link only if your point is ''to link to another page''). And the question of when a ''cross-reference'' is or isn't relevant will continue to be a point for individual little disputes.)
	:::• Nobody spends any time designing new syntax and putting it into the programming, and nobody spends time learning it and trying to stick it into thousands and thousands of dates.
			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". ] (]) 16:38, 16 November 2024 (UTC)
	:::As far as I can tell, there is no simpler way of handling this (unless, of course, we just leave everything as it is, and continue with these battles and discussions). Even my own other proposals are more complicated than this way. This way is so simple: everything remains the same, except for two points—namely, (1) that whoever programs Misplaced Pages to work as it works just removes the bits that make encoded dates show up differently for different users, and (2) that battles about linking end up being only about relevant cross-referencing and not how the date appears to various readers.
			:What's the common usage in english? ] (]) 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 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.
			::--] (]) 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. ] (]) 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.)}} ] (]) 17:50, 16 November 2024 (UTC)
			::You get extra points for saying "US customary" and not "Imperial". 😉 ] (]) 18:20, 16 November 2024 (UTC)
			:::{{smalldiv|1=imperial :3 ] (]) 18:30, 16 November 2024 (UTC)}}
			:I agree with ], do not use "crore", use "millions". Misplaced Pages is for a worldwide audience. ] (]) 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. ] (]) 18:19, 16 November 2024 (UTC)
			:Except we don't favor meters over feet — we use both. That's what the ] 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 ]. ] (]) 18:18, 16 November 2024 (UTC)
			:We already make an exception for ]. I see no good reason for barring a second exception. State in ] and convert to a unit non-Indians can understand (millions of ]s?). ] (]) 20:48, 16 November 2024 (UTC)
			The article for the French movie '']'' 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. ] (]) 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. ] (]) 17:50, 16 November 2024 (UTC)
			*'''Bad RFC'''; see ] 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). ] (]) 18:21, 16 November 2024 (UTC)
			*:{{replyto|Kurzon}} I did {{diff|Misplaced Pages 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 ]. --] &#x1f339; (]) 18:39, 16 November 2024 (UTC)
			:This RfC is clearly improperly formatted, ]; 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. ] (]) 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. ] (]) 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 ]. I am unsure where I sit on this issue. I would like to see some Indian editors weigh in on this. ] </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 ]'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;">]]</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 ] (which I think is ridiculous) and an infinite variety of customary units, or we allow none.
			:::(Two counterarguments: 1. This is a ] 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.) ] </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 ] 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. ] (]) 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. ] </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 ] even though long-scale hasn't entirely died out in the British Isles. ] (]) 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. ] (]) 01:04, 17 November 2024 (UTC)
			*'''Don't allow crore''' Per ]. 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. ] (]) 22:38, 16 November 2024 (UTC)
			*'''Allow''' ''crore'', ''lakh'' and ], '''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;]&#124;] 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. ] </span>]] 13:56, 17 November 2024 (UTC)
			*'''Allow''' ''crore'', ''lakh'' per ], and with the same caveats. ] (]) 00:03, 17 November 2024 (UTC)
			*'''Allow ScreiberBike''', per my comments above. ] (]) 01:20, 17 November 2024 (UTC)
			* '''Allow ScreiberBike'''. But see also ] - "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 ] comment added by ] (] • ]) 00:30, 18 November 2024 (UTC)</small>
			* '''Allow''' ''crore'', ''lakh'' and ], '''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. ] (]) 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 ] about that. If you wish to comment, please go to ]. Thanks, ] (]) 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. --] &#x1f339; (]) 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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&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;">]]</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. ] (]) 09:50, 20 November 2024 (UTC)
			*:What does "widespread" mean? ] (]) 12:17, 20 November 2024 (UTC)
			{{block indent|em=1.6|1=<small>Notified: ]. ] (]) 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'"> — ] ] ] 😼 </span> 11:55, 21 November 2024 (UTC)
			*'''Allow''' when appropriate, under conditions set out by ScreiberBike. Also, this RfC does not meet ]. ] <sup>] · ]</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. ] ] 07:32, 22 November 2024 (UTC)
			*:I don't get what native/non-native speakers have to do with the issue. ] (]) 12:21, 22 November 2024 (UTC)
			* '''Allow per ScreiberBike''' for South Asian articles. ] (]) 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. — ] (]) 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 Misplaced Pages. The Indian comma would be much worse. ] (]) 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'"> — ] ] ] 😼 </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">]</span>&nbsp;(])</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. ] (]) 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">]</span>&nbsp;(])</span> 03:18, 29 November 2024 (UTC)
			*:::::Yes, that or add spelling that says "colour" is what I'm saying. ] (]) 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. ] (]) 04:11, 29 November 2024 (UTC)
			*:::On this attempt at a ''color'' ]: "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 ], ], and ] 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 ] 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'"> — ] ] ] 😼 </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">]</span>&nbsp;(])</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 ] 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'"> — ] ] ] 😼 </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. ] (]) 07:01, 28 November 2024 (UTC)
			*:As an alternative, I would also accept allowing crore only if the "millions" number is included alongside it. ] (]) 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 ]. All of the above are attested by dictionaries, while "man" to mean myriads is not. ] (]) 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 ] and ] 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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&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". ] (]) 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 ]. 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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&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/search/?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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&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">]</span>&nbsp;(])</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. ] ] 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 ] they can click on the link. I see no disservice. ] (]) 12:49, 29 November 2024 (UTC)
			*:Perhaps some are not aware but English Misplaced Pages is heavily used in India. The ] from 2023 had five items about Indian movies and movie stars. The latest week's most viewed ] had ] and '']''. According to ] 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;]&#124;] 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 ]. 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. --] (]) 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. ] (] · ]) 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? ]<sub>]</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;]&#124;] 20:50, 8 December 2024 (UTC)
			{{abot}}
			== Which era? ==
	:::] 06:12, 11 December 2006 (UTC)
			I'm inviting fellow editors to figure out whether ] 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: ]. Thanks! <!-- Template:Unsigned --><small class="autosigned">—&nbsp;Preceding ] comment added by ] (] • ]) </small>
			:] 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.). --] (]) 00:18, 22 December 2024 (UTC)
			::Agreed on the last part. As for the procedural matters, all of our ] principles ultimately default/fallback to the style used in the first non-stub version that used one of the competing styles, if consensus fails. ] 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 ], ], ], ], 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 Misplaced Pages {{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 ] 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'"> — ] ] ] 😼 </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? ] (]) 08:56, 24 December 2024 (UTC)
			== Four questions ==
	*'''Comment'''. Preslethe, while I agree with many of your points, the formatting/spelling issues are a complicated compromise on Misplaced Pages, and proposals for radical change are unlikely to succeed. That is why I've made the request as simple as possible, while hoping that it treads on no one's toes in an area that has tended to be emotive.
			#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?
	I can assure you that if the launching of the request is followed by debate, uncertainty, and a cascade of technical suggestions, '''it will fail again'''. To succeed, a simple, unitary argument needs to be put in one fell swoop, period, no further discussion or disarray, just let them assess it and, we hope, act. That's the reason for signing the request with 50+ names: all speaking at once.
			#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, ] 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? --] (]) 23:04, 21 December 2024 (UTC)
			#:I'd add a fifth question: why does Misplaced Pages not use ISO dates, i.e. yyyy/mm/dd? They are becoming more common internationally. ] (]) 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 Misplaced Pages bases its style on that of other English-language media.
			#::<span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</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 Misplaced Pages entry ]. You might be surprised.] (]) 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">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 23:36, 22 December 2024 (UTC)
			::#] 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 ] 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 ] 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 ]. 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.
			::#] 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 ] <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&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">]<span style="color:#fff">&nbsp;‥&nbsp;</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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&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">]<span style="color:#fff">&nbsp;‥&nbsp;</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>).
			::] (]) 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. ''''']'''''&nbsp;<small>'']''</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.) ] (]) 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. ] (]) 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. ''''']'''''&nbsp;<small>'']''</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 Misplaced Pages), 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 ]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. ] (]) 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? '''']''''&nbsp;<small>'']''</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 ]. Good luck with writing an MOS guidance that avoids that minefield.
			::# I was about to declare that ]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 ]s{{snd}} all UK railway engineering has been done in metric since 1975. So no, ] applies to UK articles too. {{midsize|Except articles under the aegis of ], of course. --] (]) 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. ] (]) 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? ''''']'''''&nbsp;<small>'']''</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. ] (]) 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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&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 Misplaced Pages sometimes chooses to depart from the SI, via MOSNUM. I don't believe MOSNUM permits this particular departure.
			::::::] (]) 08:30, 23 December 2024 (UTC)
			:Remsense, one reason Misplaced Pages can't rely on ISO 8601 throughout is that some articles express dates in the ], or even the ], and ISO 8601 only allows the ]. ISO 8601 is fine for airline schedules and hotel reservations, but it truly sucks for history. ] (]) 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? --] &#x1f339; (]) 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. --] (]) 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">]<span style="color:#fff">&nbsp;‥&nbsp;</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'"> — ] ] ] 😼 </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">]<span style="color:#fff">&nbsp;‥&nbsp;</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 ]." B) If that argument were not persuasive, then ] 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. ] 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'"> — ] ] ] 😼 </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. ] (]) 12:56, 29 December 2024 (UTC)
			:::It isn’t however very readable, on articles of prose. ] (]) 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">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 18:23, 29 December 2024 (UTC)
			== Unit formatting ==
	We need to avoid (1) possible problems with back-compatibility, (2) offending those who—for whatever reason—want to retain blue chronological items, and (3) complication. The developers do NOT want to enter contentious debates; it's just easier for them to say "no" than to become wound up in unpleasant politics. Getting them to add this parallel syntax will be a major step, and will bring a number of significant improvements that we'll all enjoy. PLEASE, let it go in its simple form, and allow the technical experts to apply their skills. ] 07:35, 11 December 2006 (UTC)
			Are any of these formats correct?
	:Hear, hear. Every previous move to change this has petered out in a discussion of the pros and cons of different syntaxes. So let's just ask that we can somehow format without linking, and let the developers decide how to do it. ] (]) 10:26, 11 December 2006 (UTC)
			* 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? --] (]) 13:56, 22 December 2024 (UTC)
	*Suggestion: the new syntax should also deal with, or be extendable later to deal with date ranges. Reason 3-5 July has to become - ATM. In general, ask for the implementation to be forward looking. ''] ]'', 17:48 ] ] (GMT).
	*Suggestion: mention the comma thing. ''] ]'', 17:59 ] ] (GMT).
	*<s>Suggestion: make the syntax extendable later to convert to preferred units (lb/kg, etc). <span class="user-sig user-Quarl"><i>—] <sup>(])</sup> <small>2006-12-13 22:02Z</small></i></span> </s>
	:I'm pretty sure preferenced unit conversion isn't going to make it into Misplaced Pages. I modified the code to do this, even taking significant units into account, and was basically told it was a bad idea according to the wikitech mailing list. --] (]) 22:20, 13 December 2006 (UTC)
	::I see, that's unfortunate and unexplained. Thanks for trying! <span class="user-sig user-Quarl"><i>—] <sup>(])</sup> <small>2006-12-13 23:51Z</small></i></span>
			:In answer to your first question I suggest choosing between "a 10 cm blade" and "a ten-centimetre blade".
	Unfortunately I've found the developers to be fairly picky about not imposing their will on the community (which is not so unfortunate when you think about it), so ''my'' fear is that if we send them a "" message, they'll kick it right back as rejected until we give them a syntax as well. That being said, I think we can succeed by a) giving them a list of concerns such as date-range extensibility and retaining wikilinks where appropriate, or b) using an up-down poll for the ''principle'' and approval voting (or whatever) for the syntax options discussed so far. -- '']']'' 21:32, 12 December 2006 (UTC)
			:To the second, there is no internationally accepted standard describing symbols for the imperial unit system. Perhaps that is the reason. ] (]) 14:05, 22 December 2024 (UTC)
	::The community has put forward many great syntax options, but it always devolves into an argument. This proposal is saying "we need a change". No one has yet disputed that we do need a change. Specific syntax will be disputed. Who better to select from the excellent syntax options that have been presented than the developers who know how it will affect future plans, Misplaced Pages, and the rest of the mediawiki universe? I also don't think it would be terrible to "cross that bridge when we come to it" if they do decide to kick it back to the community. --] (]) 00:54, 13 December 2006 (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 ].
			: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">]<span style="color:#fff">&nbsp;‥&nbsp;</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. --] (]) 23:13, 22 December 2024 (UTC)
			:::Do you have a real world example illustrating your concern? ] (]) 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 ] 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'"> — ] ] ] 😼 </span> 07:12, 23 December 2024 (UTC)
			== Mixed spelled/figure format ==
	:::I may well be wrong, as this discussion has grown far beyond my capability to follow it (condensing it a bit, anyone?), but while everybody seems to agree that "we need a change" I see a lot of different ways to intend that; many seem to focus on the color of the text, for instance. All in all, I think I'd prefer eliminating preferences altogether to any half-backed solution which considers dates only, and tries to cope with the developers' capriciousness (though the ''captatio benevolentiae'' in the final part of the proposal text might well do the job :-)). After all, I've never seen anyone complaining they didn't like how their paper encyclopedia was spelling dates out as long as there was no ambiguity. &mdash;]] 20:49, 17 December 2006 (UTC)
			How did we come to this guidance?
	:::Fair enough, I am perfectly happy to be found too pessimistic by the consensus of the group. :) -- '']']'' 19:51, 13 December 2006 (UTC)
			: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}}}}.
	::::I intend to pursue the matter further if our representation is ignored. ] 01:17, 14 December 2006 (UTC)
			This goes against the 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 Misplaced Pages style the odd one? -- ] (]) 04:14, 28 December 2024 (UTC)
	----
	A lot of the requests I see here could be solved by a rollout of clever templates. e.g. data ranges. I'd like to see dates encapsulated in templates like: '''<nowiki>{{dmy}}</nowiki>''' (for day, month, year), '''<nowiki>{{dm}}</nowiki>''' (for day and month), '''<nowiki>{{my}}</nowiki>''' (for month and year), '''<nowiki>{{my range}}</nowiki>''' for a month and year date range), etc.
	:e.g. <nowiki>{{dmy|18|December|2006}}</nowiki>
	What we need is some mechanism that permits us to implement such templates while honouring users' date preferences. This might be something as simple as a <nowiki>#DATEPREF</nowiki> magic variable. ] 04:53, 18 December 2006 (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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&nbsp;</span></span> 05:43, 28 December 2024 (UTC)
	:I thought to templates too when reading the MoS pages about dashes, hyphens, beams and motes (;-)) but in fact such usages would be workarounds of software deficiencies (as many existing templates are, for instance {{tl|ISSN search link}}, which I created myself for lack of a better solution). And in this case they would still need a new software feature. Unfortunately (or very fortunately) Misplaced Pages has pushed MediaWiki to its limits; I don't know if its authors ever had in mind something similar in extent and complexity but certainly the software can't cope with it. It would be the software responsibility, for instance, to convert between units and number notations (at least if we are serious about avoiding human errors). And we are in desperate need of an ] system. I'd see with enthusiasm a (long-term) project to create a full-fledged content manager, perhaps around SVN, and a migration of all the Misplaced Pages contents to it. &mdash;]] 05:26, 18 December 2006 (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">]<span style="color:#fff">&nbsp;‥&nbsp;</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 : {{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. ] (]) 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. ] (]) 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? ] (]) 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. ] (]) 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">]<span style="color:#fff">&nbsp;‥&nbsp;</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. ] (]) 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". ] (]) 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, Misplaced Pages 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. ] (]) 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. ] (]) 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. ] (]) 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". ] (]) 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:
	::The reason I would be sceptical about using templates like that is that they're (let's be fair) not that intuitive for newcomers (neither would other options, but this is even less so), and the syntax, well, it's rather intrusive for something so common and it'd be difficult to persuade people to actually use it. I mean, I know it's not that long, but imagine writing that out every time you had to write a date. I guess this is why we're leaving it to the developers. ] 06:44, 18 December 2006 (UTC)
			:::::::*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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&nbsp;</span></span> 13:09, 28 December 2024 (UTC)
	:::I had another idea for a potential syntax (since it's been mentioned that, if we have one in mind, that might make the developers' job a bit easier), for an auto-formatted ''but non wikilinked'' date, what if we could simply type it in as a piped link ''with no target'' e.g. '''<nowiki>]</nowiki>'''. It's obvious the link doesn't actually ''go'' anywhere, and when that is the case the Wiki software could format the ''date text'' per user preferences. Intuitive and fully backwards compatible (we could organize date de-linking campaigns later), so it's another viable option for a syntax suggestion. --''] 13:36, 21 December 2006 (UTC)''
			::::::::29 only has meaning to me in that it is comparable to 1. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</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 . As does . As does the . ] (]) 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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&nbsp;</span></span> 22:44, 28 December 2024 (UTC)
			:::::@] this is an ''extremely'' helpful interpretation. Thank you. I wonder if you and others would weigh in on another sentence in the ] 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 , and the . -- ] (]) 15:58, 28 December 2024 (UTC)
	===Update on progress===
			::::::But is more readable as it was. ] (]) 18:01, 28 December 2024 (UTC)
	After receiving no substantive reply, we now have one from developer "Simetrical"> S/he suggests that the conflation of autoformatting and linking may be an issue, and that it is solvable with effort, an effort that s/he is unwilling to provide. There's a suggestion that one or more of the other developers may be willing to review code that is written by one of us. Rob Church is kindly working on one now for this purpose, and two other signatories here have expressed a cautious interest in being involved some time next month.
			::::::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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&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. —]&nbsp;(&nbsp;]&nbsp;•&nbsp;]&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. -- ] (]) 20:46, 28 December 2024 (UTC)
			== Acceptable Date Format: Month Year ==
	I suppose that the summary message is:
			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:
	(1) persistence and active code-writing will be required to generate interest among the developers;
	(2) it won't be a speedy process; and
	(2) once an acceptable code is written, and successfully reviewed by the developers, it becomes a matter of having the new syntax approved, which is not a foregone conclusion.
			# 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.
	I'll be reminding the developers occasionally of the growing list of signatories, so please advise your fellow WPians if they may be interested in signing on.
			# 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. ] (]) 15:48, 30 December 2024 (UTC)
	] 06:30, 21 December 2006 (UTC)
			*It’s common English usage, both in the UK and US, so on what authority are you suggesting it is bad grammar? ] (]) 15:51, 30 December 2024 (UTC)
	:'''One or more''', '''may''', '''review''' (not "implement it")… Wow! Didn't he add a ''perhaps'' too? &mdash;]] 15:35, 21 December 2006 (UTC)
			*Agree with MapReader, this is standard. ]] 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." ] (]) 16:30, 30 December 2024 (UTC)
			*There ain't nothin' wrong with September 2001. ] (]) 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. ]] 21:51, 30 December 2024 (UTC)
			*{{replyto|Quindraco}} You're about {{diff|Misplaced Pages:Manual of Style/Dates and numbers|prev|5087496|twenty years too late}} to change the guideline. --] &#x1F98C; (]) 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''." ] (]) 05:27, 7 January 2025 (UTC)
			*::Except you haven't shown it to be wrong in the first place. "Month Year" dates have always been taught to be correct in my experience. If you think about it, requiring "July, 1776" would also require "4 July, 1776". I have noticed that my computer's available date formats include a few oddities that I was always taught were flat out wrong. Is that where you are getting this idea?--] (]) (]) 00:28, 9 January 2025 (UTC)
			*:::Yep. Just checked. Windows has "Wednesday, 5 April, 2017" and "5 April, 2017" listed as date formats. Commas should only be used within the date when it is not in either "day-month-year" or "year-month-day" order. I've sent feedback about this, but I doubt that anything will be done about it.--] (]) (]) 16:55, 9 January 2025 (UTC)
			*The OP's complaint is, I regret to say, just so much ]ism. ]] 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. --] (]) 06:38, 7 January 2025 (UTC)
			*It's recognised to be . —]&nbsp;(&nbsp;]&nbsp;•&nbsp;]&nbsp;) 16:12, 7 January 2025 (UTC)
			*"January 2018" is the official usage in Australia: https://www.stylemanual.gov.au/grammar-punctuation-and-conventions/numbers-and-measurements/dates-and-time ("Incomplete dates" section). <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&nbsp;</span></span> 00:50, 9 January 2025 (UTC)
			*Agree with those above; "September 2001" is perfectly acceptable. ] (]) 15:02, 9 January 2025 (UTC)
			== ] appears to be incorrect ==
	::Interested parties may wish to view for updates on his progress. In particular, there is a working version of Rob's parser hook solution at . ] 08:02, 4 January 2007 (UTC)
			I'm surprised that this hasn't been fixed already but ] currently incorrectly claims that "the 17th century as 1601–1700", for example. I was about to fix the ] 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: , , , , .
	:::Dear supporters,
			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. ] <sup>(], ])</sup> 13:29, 1 January 2025 (UTC)
	:::Rob Church has posted the following update:
			*If it ain't broke, don't fix it. ] is correct. Ask yourself when the 1st century CE (using the ]) began and then work your way forward. -- ] (]) 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. ] (]) 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 Misplaced Pages 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. ] (]) 09:38, 3 January 2025 (UTC)
			*:::That sounds like a case of ]. (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.) ] (]) 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." Misplaced Pages 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 "]" 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}}
			:] (]) 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">]</span>&nbsp;(])</span> 03:28, 2 January 2025 (UTC)
			::+1 ]] 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; Misplaced Pages has a duty to provide accurate information even if it does take a significant amount of work fixing this across various articles. ] <sup>(], ])</sup> 16:15, 2 January 2025 (UTC)
			:::How many years were there in the 1st ]? ] (]) 18:27, 2 January 2025 (UTC)
			::::100, obvs. 1 AD to 100 AD. Next question please? --] &#x1F98C; (]) 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). ] (]) 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 ], 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 Misplaced Pages, however, and if anyone feels strongly enough about the current guidance being wrong, RfC is thataway. ] 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. ] (]) 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. ] <sup>(], ])</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? ] (]) 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 "]", 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). --] &#x1F98C; (]) 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 ] would say that it is the seventh, not the ninth, month of the year. ] <sup>(], ])</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. ] 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! ] (]) 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. Misplaced Pages should not take it upon itself to make up an exception. ] (]) 19:11, 4 January 2025 (UTC)
			:::@]:
			:::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 ] 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 Misplaced Pages 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">]</span>&nbsp;(])</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. ] (]) 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">]</span>&nbsp;(])</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 Misplaced Pages 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 Misplaced Pages policy defines the word "century" differently to the rest of the world.
	:::"Just to follow up...most of the work for the DateParser class is now done, and the FormatDates extension has been checked into Subversion. I need to find some time to write an exhaustive set of test cases for it, and run some profiling checks on it.
			::::You're probably right that regardless, a hatnote/explanatory note of some nature is needed. For instance, a lot of sources such as , , , , report that ] (1899–2017) was the last surviving person born in the 19th century. However, there are also a few sources such as , , and which report that ] (1900–2018) was the last surviving person born in the 19th century, using the ending-in-1 definition.
			::::At the moment, the implication of Misplaced Pages 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. ] <sup>(], ])</sup> 09:03, 3 January 2025 (UTC)
			:::::So your suggested change would also affect many other articles such as our own sourced ] article. ] (]) 10:08, 3 January 2025 (UTC)
			:Usage such as 20th century for 1900 - 1999 simply reveals the source as being unable to perform basic counting. Any such source is immediately rendered unreliable. --] (]) (]) 13:06, 8 January 2025 (UTC)
			:I'm usually one to say that we should accept that language changes and that we in the language police should go along with it, but in this case, many, especially the mainstream press, looking for headlines, are wrong. Saying the first century has 99 years, is like saying 99 cents is sometimes a dollar. Sometimes a misused word becomes acceptable, but not in this case.&nbsp;]&#124;] 14:42, 8 January 2025 (UTC)
			{{outdent}}
	:::The extension, for those who weren't following, introduces a <date> tag."
			As per ] (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"
	:::It's very pleasing to know that progress is being made, although there's a way to go yet. Many thanks to Rob for his efforts! ] 07:44, 6 January 2007 (UTC)
			! Organisation !! URL !! 00 or 01
	== two nine-page letters or two 9-page letters? ==
			|-
			| 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
			|}
	Can we add an exception to the spell-out-all-numbers-under-10 rule for hyphenated adjectives with numbers? In other words, include something like this on the project page:
			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?
	For hyphenated adjectives with numbers, like 2-year contract, 5-story building, use numerals instead of words.
			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.
	Someone just reverted my change to "7-vowel system" back to "seven vowel system", and they're right according to this page, but they're wrong according to the Technical Editing course I took. --] 16:55, 20 December 2006 (UTC)
			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!
	: I would always write "two-year" or "five-story" (well, I'd write "five-storey", but that's a different question). ] (]) 17:16, 20 December 2006 (UTC)
			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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&nbsp;</span></span> 11:44, 3 January 2025 (UTC)
	:: Could you please also give an opinion on "3-volume", appearing in the ] article? &mdash;]] 22:00, 20 December 2006 (UTC)
			*There are some known inconsistencies/anomalies in our treatment of centuries, including categories or articles covering decades. For example, ] is a subcategory of ], 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. ] (]) 12:36, 3 January 2025 (UTC)
	::: Again, I'd consider "three-volume" to be good style, although it seems Dblomgren would disagree. Anyone else? ] (]) 22:40, 20 December 2006 (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. ] <sup>(], ])</sup> 13:45, 3 January 2025 (UTC)
	::::Stephen's right, so "seven-vowel system" is the widely accepted way. "Two 9-page letters" is a recommended exception in several major style manuals, but there's no universal rule: it makes sense as an exception. The other exception is for units. And I wonder whether the MoS makes the SI distinction between "3 mm" radius and "3-millimetre" radius? That's a widely accepted distinction in hyphen use between abbreviated and spelt out units, where they're part of a double or triple adjectival form. ] 06:11, 21 December 2006 (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. ] (]) 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. ] ] 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">]</span>&nbsp;(])</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. --] &#x1F98C; (]) 22:52, 3 January 2025 (UTC)
			== RfC on the wording of ] ==
	:::::Yeah, I'd agree with Stephen on that. ] 08:35, 21 December 2006 (UTC)
			<!-- ] 15:01, 7 February 2025 (UTC) -->{{User:ClueBot III/DoNotArchiveUntil|1738940465}}
			{{rfc|hist|lang|rfcid=6F3124E}}
			Should ] 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. ] <sup>(], ])</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. ] (]) 21:21, 3 January 2025 (UTC)
	::::::I'm a little confused now. Why is ""two 9-page letters" a recommended exception? Because it employs two consecutive numeral adjectives (''two'' and ''nine'')? So one would say, for instance, "three 7-vowel systems"? Thanks, ]] 09:29, 21 December 2006 (UTC)
			*As the 1st century is 1–100, the ] is 1901–2000, as its article says. Let us not turn this into another thing (like "billions") where English becomes inconsistent with other languages. —] (]) 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". —] (]) 22:26, 3 January 2025 (UTC)
			*:In short, '''oppose change'''. —] (]) 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. --] &#x1F98C; (]) 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. ] (]) 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? ] (]) 09:28, 4 January 2025 (UTC)
			* '''Treat both as acceptable options.''' ] 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. ] doesn't privilege a particular POV here, and neither should ]. ] (]) 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 ] to do anything else. —] (]) 17:46, 4 January 2025 (UTC)
			* '''Oppose.''' If this matters to you, convince the academic sources to adopt the change, then Misplaced Pages can follow. ] (]) 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. ] 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). ] (]) 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">]</span>&nbsp;(])</span> 19:22, 6 January 2025 (UTC)
			*:::You seem to be saying the choice between a century (the first, whether ] or ]) of 99 or 100 years amounts to personal preference. Do you have credible sources showing they are equally valid? ] (]) 19:23, 7 January 2025 (UTC)
			*'''Oppose treating both as acceptable''' This would lead to endless confusion. ] (]) 22:02, 5 January 2025 (UTC)
			*'''Oppose''' change; century starts at ###1 and ends ###0 <!-- Template:Unsigned --><small class="autosigned">—&nbsp;Preceding ] comment added by ] (] • ]) 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, and others have spelt them out above. In a nutshell, such a change would be a retrograde step, against the spirit of the MOS. ] (]) 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 Misplaced Pages, for this exact reason. It's consistent with how we refer to decades (see vs. ). It's universally understood. It avoids silly arguments like this one. Let's just do that. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]]</sup> <small>(])</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"> -- ]</span><sup class="nowrap">&#91;]]</sup> <small>(])</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">]</span>&nbsp;(])</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, ]. <span style="font-family:courier"> -- ]</span><sup class="nowrap">&#91;]]</sup> <small>(])</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–. This is explicitly called out by ], 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">]</span>&nbsp;(])</span> 03:05, 6 January 2025 (UTC)
			*:We should avoid use of "1900s" to mean anything other than 1900-1909. ] (]) 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 , or . 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.] (]) 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">]</span>&nbsp;(])</span> 23:52, 5 January 2025 (UTC)
			*'''Oppose change'''; continue using "20th century" for 1901–2000 and "1900s" for 1900–1999. ] (]) 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. ] (]) 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">]</span>&nbsp;(])</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). ] (]) 07:16, 7 January 2025 (UTC)
			*'''Oppose''' treating them both as acceptable. I imagine this could lead to headaches concerning inclusion in categories, list articles, timelines, templates, etc. ] (]) 01:23, 8 January 2025 (UTC)
			*'''Oppose change''' People have been getting it wrong for centuries (pun not intended) and will probably continue doing so for centuries. Intuition says that the year 2000 was the start of the new century but intuition is wrong. Just like people believing that light-years and parsecs are a measure of time (doing the Kessel run or otherwise) or trying to learn relativity, intuition is simply wrong. <u>All</u> authoritative sources for measuring time say that the new century starts in the year xx01. WP is only suppose to report on this. If we try to say that the year 2000 is the first year of the new century then we are actively entering the battle and are try to ]. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&nbsp;</span></span> 04:12, 10 January 2025 (UTC)
			*'''Keep XX1 as the start of a decade, century, or any other unit of year.''' It sounds ridiculous to have only the first CE century be 99 years long while everything before and after it remains at 100. —]&nbsp;(&nbsp;]&nbsp;•&nbsp;]&nbsp;) 18:34, 10 January 2025 (UTC)
			*:I think they consider the ] to also have 99 years. ] (]) 19:15, 10 January 2025 (UTC)
			It is high time to end this :
	::"five-story", etc. is good style, and the only problem with things like "two nine-page letters" is if you do "2 9-page letters" —]→]&nbsp;&bull; 08:42, 21 December 2006 (UTC)
			:{{tq|When the encyclopedia of human folly comes to be written, a page must be reserved for the '''minor imbecility''' of the battle of the centuries--the clamorous dispute as to when a century ends. The present bibliography documents the controversy as it has arisen at the end of the 17th, 18th, and 19th centuries, as well as a few skirmishes in the quarrel that has begun to develop with the approach of the third millennium.}}
			:{{tq|The source of the confusion is easy to discern; ever since learning how to write, we have dated our documents with year designations beginning with the digits 19. Obviously, when we must begin to date them starting with 20, we have embarked on a new century! Haven't we? The answer is no, we have not; we have merely arrived at the last year of the 20th century. As historians and others involved in measuring time continue to remind us, there was no year 0. In fact, there has never been a system of recording reigns, dynasties, or eras that did not designate its first year as the year 1. To complete a century, one must complete 100 years; the first century of our era ran from the beginning of A.D. 1 to the end of A.D. 100; the second century began with the year A.D. 101.}}
			:{{tq|While the period 1900-1999 is of course a century, as is any period of 100 years, it is incorrect to label it the 20th century, which began January 1, 1901, and will end on December 31, 2000. Only then will the third millennium of our era begin.}}
			:{{tq|Those who are unwilling to accept the clarity of simple arithmetic in this matter and who feel strongly that there is something amiss with the result have developed some impressively convoluted arguments to promote their point of view. Baron Hobhouse, studying some of these arguments as set forth in letters published in the Times of London during the first few days of January 1900, found "that many of the reasons assigned are irrelevant, many are destructive of the conclusion in support of which they are advanced, and that such as would be relevant and logical have no basis whatever to maintain them in point of fact." He was one of several observers of the fray at the end of the 19th century who predicted that the foolishness would recur with the advent of the year 2000, as people began to look for ways of demonstrating "that 1999 years make up 20 centuries."}}
			:{{tq|As a writer stated in the January 13, 1900, Scientific American, "It is a venerable error, long-lived and perhaps immortal." The shortness of human life is also a factor; as a century approaches its end, hardly anyone who experienced the previous conflict is still living, so we are doomed to undergo another round.}}
			:{{tq|Astronomers have been blamed for some of the confusion by their adoption of a chronology that designates the year 1 B.C. as 0 and gives the preceding years negative numbers, e.g., 2 B.C. becomes -1, 3 B.C. becomes -2, etc. This system permits them to simplify calculations of recurring astronomical events that cross the starting point of our era, such as series of solar eclipses and the apparitions of periodic comets. However, this scheme affects only the years preceding A.D. 1 and cannot be used as a justification for ending subsequent centuries with the 99th year.}}
			:{{tq|Some argue that Dionysius Exiguus made a mistake in his determination of the year of Christ's birth when he devised our present chronology in the sixth century, and that the discrepancy allows us to celebrate the end of a century a year early. However, even though the starting point of our era may not correspond to the chronologist's intention, it is still the point from which we count our centuries--each of which still requires 100 years for completion.}}
			:{{tq|Nevertheless, as many of the entries in this list (from p. 45 on) will indicate, plans to celebrate the opening of the 21st century and the third millennium at midnight on December 31, 1999, have become so widespread that anyone who tries to call attention to the error is disparaged as a pedant and ignored. Perhaps the only consolation for those intending to observe the correct date is that hotels, cruise ships, supersonic aircraft, and other facilities may be less crowded at the end of the year 2000.}}
			] (]) 18:04, 10 January 2025 (UTC)
			== Sorting of numerical data with mixed units ==
	:::Personally, I'd write "two nine-page letters", because in my mind, the hyphen is sufficient to resolve any confusion there. As Tony says, there's no universal rule on that &mdash; I guess it could be considered a pedanticism? (excuse the coinage) Probably the two number-words in a row, yeah, though personally I don't quite get it either. ] 10:18, 21 December 2006 (UTC)
	::::Sure, this is fine too; there are cases where it's not, though: "three three-millimetre bullets" might better as "three 3-millimetre bullets". Up to you. ] 12:00, 21 December 2006 (UTC)
	:::::I see... maybe (just ''maybe'') I could buy that one... :-) interesting, these things are. ] 04:14, 22 December 2006 (UTC)
			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 ] column on ] uses values with different units, ranging from nanoseconds to years. (For years, NUBASE2020 uses a conversion calibrated to the ]: {{nowrap|1=1 year = 365.2422 d}}.{{NUBASE2020|ref}}) –] (]]) 04:48, 6 January 2025 (UTC)
	I happened to find an example in the literature of this very juxtaposition using words, not numerals; from the OED: 1711 ''London Gaz.'' No. 4906/2, I had two Nine pound Shots through my Fore~mast. —]→]&nbsp;&bull; 10:25, 21 December 2006 (UTC)
	:It's understandable where Tony is coming from, his last example is one of the same number twice in a row, which might encourage some people to think of it as a typo, when it's not. --''] 13:52, 21 December 2006 (UTC)''
	::"Two letters, each nine pages long". "Two 9-page letters" is to grammar as a rubber patch is to a bicycle tyre. -] 02:03, 13 January 2007 (UTC)
			:Try this:
	== Usage of m as an abbreviation ==
			{|class="wikitable sortable"
			!value!!name
	I think that the usage of m as an abbreviation should be discouraged, except when it is clear that meters are being talked about or if it is necessary due to space constraints in a table. The reason for this is that m can stand for meters or miles and it is not always clear which is being talked about. For example, an island could easily be 100 meters or 100 miles off the coast. You might say that we can use mi for miles, but that is irrelevant because visitors would not know that and even editors would not know whether the writer of the text is aware of the convention or not. -- ] 23:55, 20 December 2006 (UTC)
	:No, "mi" stands for miles. Since 96% of the world uses metres, I'm unwilling to dispense with a widely understood and convenient abbreviation. <small>—The preceding ] comment was added by ] (] • ]){{#if:{{{2|}}}|&#32;{{{2}}}|}}.</small><!-- Template:Unsigned -->
	::"m" pretty much universally stands for "metres". I don't think it's ambiguous. ] 08:39, 21 December 2006 (UTC)
	::You can always link it the first time it occurs if you consider it necessary: 15 ]. Using m for miles is a bad idea though, in my opinion, because most of the world uses m for metres. ] (]) 08:41, 21 December 2006 (UTC)
	:::First, "m" is a common abbreviation for miles in the United States. I love the metric system and I wish that English/Imperial units could be dispensed with. Unfortunately, the vast majority of people in the United States have virtually no comprehension of the metric system (note: I have lived in the U.S. all of my life and I have an extensive and broad scientific education). The only significant exposure that most young people have to the metric system is in physical science classes, like chemistry (many biology classes below the university level do not deal with a lot of measurement or calculations, even though metric units are nominally used). If he or she does not go to college, a typical young person may have had a couple of science classes that used the metric system and that is it. This is not a good enough exposure to have an good understanding of the metric system, and what little knowledge they do have will soon be forgotten because they never use it again. Worse, older people never even used the metric system in school at all.
	:::Second, as I tried to explain in my original post, using "mi" does not solve the problem. Visitors from the United States who know nothing of Misplaced Pages policy will not know of a convention to use "m" for meter and "mi" for mile, so there will be a problem when they come across an article that uses the abbreviation "m" in it. I sincerely believe that the vast majority of people from the U.S. will not only believe that "m" stands for "miles" in my example above, but that most of them will not even think of the possibility that it could be "meters" (some may not know that "m" is an abbreviation for meters and/or be unaware of what a meter is).
	:::Third, as I stated in my original post, I am not suggesting that the abbreviation be abandoned, just that when the possibility for misunderstanding exists, it should be stated explicitly what units are being used. -- ] 16:44, 25 December 2006 (UTC)
	::::I agree with Kjkolb. It's illogical to assume that whatever makes sense to most people in one country must make sense to people in other countries, and it's selfish and unreasonable to disregard evidence to the contrary. Furthermore, while Americans are a minority overall, we also constitute a majority of native English readers.
	::::It's perfectly easy to type "metres" or "meters," which in no way makes the articles less understandable for anyone. In my opinion, this also is vastly preferable from a stylistic standpoint. &mdash;] 18:28, 25 December 2006 (UTC)
	:::::Admittedly, I'm not American. The current guideline (or my intepretation of it) is that ''all'' units are to be spelt out in prose, except when:
	:::::*they are a conversion, e.g. "An NBA basketball court is 96 feet (29 m) long" or "A FIBA basketball court is 28 metres (92 ft) long"
	:::::*it is in a specialist article where it is obvious what unit is being used (in the case of metres, possibly science?)
	:::::*it is in a table or infobox, where space is precious (though I've never actually seen that in practice, except in specialist science/technical articles)
	:::::To some extent it means that "metres" has to be spelt out, but not necessarily always. The infobox case might be a borderline one. I must admit, I'm still unsympathetic (they need to learn about the rest of the world, just as the rest of the world learns what an inch is when they never use it, or at least, they'll look it up as necessary, and it's not like a metre and mile are similar in length so it should be fairly obvious something's different) but I want to see where the current guideline stands with respect to this issue. I think, to some extent, it addresses the concerns. So, are the exceptions okay, i.e. are the exceptions cases where it would be obvious enough? ] 00:23, 26 December 2006 (UTC)
	::::::Americans' relative lack of familiarity with meters is a secondary issue. (Many Americans have at least some understanding of the unit, often associating it with the slightly smaller ]). The primary problem is that Americans might misinterpret "m" to mean "miles" (given the fact that this abbreviation sometimes is used in the U.S.). Kjkolb cited an instance in which this application would seem to make sense.
	::::::In your conversion examples, no reasonable person would make this mistake, but I still see no harm in using language that more people would understand. (I don't know how recognizable the abbreviation "ft" is to individuals in countries that primarily use the metric system, but I certainly would support spelling out "feet" if this were to help people.)
	::::::Regarding "specialist article where it is obvious what unit is being used," this would depend upon the context, but my point regarding the harmlessness of spelling out "metres"/"meters" applies.
	::::::As for tables and infoboxes, the context can be clarified in the main prose, so abbreviation here is a legitimate space-saver. &mdash;] 00:55, 26 December 2006 (UTC)
	:Units should always be spelt out in prose, so this is only an issue for the conversions and usages in infoboxes/tables. Always spelling out conversions might be good—it would look more professional—but it would not be relevant to the above matter because any metric conversion would already have the English units spelled out before them. For infoboxes and tables, they are not spelled out because it is necessary to use less space, so there would be no other alternative to "m" except an utterly novel "me". —]→]&nbsp;&bull; 02:29, 26 December 2006 (UTC)
	:The issue of spelling out conversions would have to be considered for all units, not just metres; and in my opinion it would be more of an issue of "is it stylistically better" (i.e. more professional), and if it is found that it ''is'' stylisically better to spell out conversions (which, in order for conversions to take up less space and therefore reduce impact on the flow of the article, I disagree with, but anyway) then that of course will work fine. For specialist articles, in the case of metres, the only instance I can think of is in science (probably the physical sciences?), and it'd probably just about always be preceded by a rather long number in scientific form, and surrounded by a sea of metric/SI units in the rest of the article which should make it obvious that it's metres not miles (right? you tell me, keeping in mind that readers of those articles are likely to have at least some background in the subject (otherwise they'll understand nothing))...
	:What I'm trying to say is, the current guideline effectively encourages spelling out of the word "metres". It is only in cases where the symbol is recommended (which are relatively few) that "m" is preferred. ] 09:30, 26 December 2006 (UTC)
	:To the original question of m being confused with miles instead of meters: I've never seen an instance where m was used to mean miles&mdash;nither wikipedia or elsewhere. Most of us Americans who are on Misplaced Pages for one reason or another are smart enough to know what a meter is. I think it is safe to keep m as an abbreviation for meters per some of the great reasons given above. &mdash;] 21:46, 26 December 2006 (UTC)
	::While this isn't a error that you or I would commit, I have seen such an abbreviation used informally. Furthermore, even smart people make mistakes&mdash;such as your ironic use of the phrase "us Americans" (no offense intended).
	::Misplaced Pages is an encyclopedia for the masses. If a tiny amount of effort can assist some of out readers (without causing any harm), I see no reason not to expend it. &mdash;] 22:07, 26 December 2006 (UTC)
	:::MJCdetroit, you just haven't paid any attention. There are a great many Misplaced Pages articles which have at one time had "m" used for miles, primarily for one reason: that (well, actually "m.") is what the 1911 Encyclopædia Britannica used. They should always be converted to "mi" or spelled out. Furthermore, there have been many Misplaced Pages articles using "mile" as a symbol for miles. They should also be converted to "mi" or spelled out (the spelled-out word, unlike the symbol, adds an "s" in the plural).
	:::Just for you, I went out and found one that is still that way: see ] (no, you cannot jump over the Gironde Estuary there!). It isn't the only one. ] 18:00, 19 January 2007 (UTC)
	:::Furthermore, I take issue with the ] claim that "Units should always be spelt out in prose". This has been discussed here before. It is quite the opposite in the recommendations of ]s dealing with measurement, as in ] Special Publication 811, ''Guide for the Use of the International System of Units,'' Section '''7.6 Symbols for numbers and units versus spelled-out name of numers and units'''
	::::This ''Guide'' takes the position that the key elements of a scientific or technical paper, particularly the results of measurements and the values of quantities that influence the measurements, should be presented in a way that is as independent of language as possible. This will allow the paper to be understood by as broad an audience as possible, including readers with limited knowledge of English. Thus, to promote the comprehension of quantitative information in general and its broad understandability in particular, values of quantities should be expressed in acceptable units using
	::::* the Arabic symbols for numbers, that is, the Arabic numerals, not the spelled-out names of the Arabic numerals; and
	::::* the symbols for the units, not the spelled-out names of the units.
	:::The same reasoning about international recognition including "readers with limited knowledge of English" apply to Misplaced Pages. ] 18:00, 19 January 2007 (UTC)
	*Let me add that I think it's crass to insist on the spelling out of units, whether metric or imperials, after the first occurence in an article. I won't do it, whether within parentheses as "equivalent" units or not. ] 08:52, 20 January 2007 (UTC)
	::::I agree with you, and furthermore, it is often the ones within parentheses that would be best spelled out on first occurrence. ] 14:03, 20 January 2007 (UTC)
	::I find Gene Nygaard's comment odd: If a user doesn't know enough English to be able to read the word "metre", how on earth are they going to read the ''rest'' of the article? This is the English Misplaced Pages, after all. If the goal is to make it more readable by people with limited English skills, there are plenty of more complex bits of English we should start cutting out before we resort to cutting out the word "metre". --] 09:27, 20 January 2007 (UTC)
	:::The only thing I can read at ] is "986.980 Km<sup>2</sup>", even though they didn't quite get the right symbol, improperly using "Km" rather than "km". With that, I might even be able to go somewhere else and figure out what those strange characters refer to.
	:::But in any of the other Wikipedias I might visit (the two Norwegian ones, the German one, etc.) any measurements are easier to read if they are in Arabic numerals and SI symbols. It is just one little thing you don't need to worry about, one thing you don't need to bother translating in your head. If you run across something saying "sju dekar" on one of them, you might not know what in the world they are talking about, but if it is instead "7 da" you might even figure out that this is 0.7 ha or 7,000 m². ] 17:27, 23 January 2007 (UTC)
	== ISO 8601 dates again ==
	I just removed examples of ISO 8601 dates from the section "]".
	When we rewrote that section in April, there was a consensus to remove those dates. And their presence there contradicts the later section "]" (which had consensus although with a small amount of dissent), which explains that linking such dates is magical too but recommends not to use them in most contexts.
	I have been back through the history, and discovered that the examples were reinserted by ] on ] (GMT). The edit summary says "as per talk", and indeed there was a short discussion ]. However, it doesn't seem to me to show a consensus for restoring them, and the ] did show a consensus for removing them. I note that it was added at the same time as another edit of Docu's which also said "as per talk" but which hadn't achieved consensus and was quickly reverted.
	So I've removed it again. We can discuss it here if people want. But my understanding is that there are a couple of people who think it should be allowed because it's an unambiguous standard, but a clear majority think it's bad style in normal prose.
	] (]) 11:26, 21 December 2006 (UTC)
	:As usual, the majority is wrong. Unambiguous dates should be the standard and enforced as a rule, not merely a guideline). Lacking that, ISO 8601 format should at the very least be a documented option for people with the good sense to use it. Aside from that, the example you deleted was a useful example of a perfectly valid Misplaced Pages feature, and as such it serves a useful purpose in that place in the article. I have therefore reverted your deletion. -- -- ] <sup><small>]</small></sup> 19:31, 28 December 2006 (UTC)
	::As it happens, the firm views of a clear majority is what determines these guidelines. Most of us agreed that they were not standard practice in modern English prose. Anyway, I never really understood how ] ] could be ambiguous... ] 00:11, 29 December 2006 (UTC)
	:::2006-12-29 ''isn't'' ambiguous. That's exactly what I am saying. -- ] <sup>]</sup></small> &bull; 2007-01-03</small>
	::Bblackmoor, I'm surprised to find an experienced editor justifying an edit to the Manual of Style with the phrase "As usual, the majority is wrong", especially after you talk so much about consensus on ]. For all its faults, ] is the way we determine our guidelines.
	::I still maintain that ISO 8601 dates should never be linked. There may be occasional circumstances where use of ISO 8601 dates is appropriate, but there is never a time when you want established users to see "29 December 2006" or "December 29, 2006", and new or anonymous users to see "2006-12-29".
	::] (]) 08:38, 29 December 2006 (UTC)
	:::There is never a time I want any user to see "29 December 2006" or "December 29, 2006" -- not in a reference work. Like Roman numerals and archaic measurements like "stone" and "cubit" (and some would say "pounds" and "yards"), that's suitable for prose and poetry, but not for a reference work. It annoys me that an editor can enter a valid, unambiguous date in an article and Misplaced Pages will senselessly reformat it. I suppose the alternative is typing dates like this: <nowiki>]</nowiki>. I may start doing that from now on to avoid this problem. -- ] <sup>]</sup></small> &bull; 2007-01-03</small>
	::::Shouldn't have linked that date above. My sentence was "I never really understood how 29 December 2006 could be ambiguous", not 2006-12-29.
	::::Is 29 December 2006 ambiguous? ] 08:42, 5 January 2007 (UTC)
	== "Numbers in letters" (for two-word or less) or "Consistency" comes first? ==
	Apparently, I could not agree with ]'s opinion about the numbers in numeral/letter form (in this case it is mostly about order numbers. I think). The problem was started in ] about . There is a small discussion about this in , although I felt the need to have more opinions from different people. There is also a change in number style under (I had it on watchlist, so I noticed that). Any thoughts about this issue? Replying in either here or on ] are fine, although keeping this discussion in the other talk page might be preferred. Regards, ]<sub><i>(])</i></sub> 16:50, 27 December 2006 (UTC)
	== Date formats related to topics ==
	We've had a couple of looks at this before. I reverted the addition of France to this list because the change, in my opinion, is significant enough to require prior discussion and, if necessary, the gaining of consensus.
	My view is that no date format should be recommended for any country that is not English-speaking. Learning how to write the date is part of learning the language, so non-English speakers will learn about how we write our dates. After all, we wouldn't expect articles about China to use 2006 December 30 for its purposes, would we? The British-American difference is not unique to dates, but the division is unique to English. That's my view, anyway. ] 12:34, 30 December 2006 (UTC)
	:I can't follow this logic. Every country has a preferred format for dates, whether it is 1-23-1945 or 23-1-2000. The name of the month is the only part of it that is English: the format applies to the country, not the language. 14 Juilliet is Bastille Day in France, and of course we translate the French month name as July - a thoroughly noncontroversial usage. I note that several countries in the ] don't use English as their primary language. Exampleas are India (Hindi), Pakistatn (Urdu), Bangladesh (Bengali), Cameroon (French), Mozambique (Portugese), Maldives (Dhivehi), Brunei (Malay), Cyprus (Greek) etc. etc. Rather than make an illogical and inconsistent choice on language, I suggest that we continue to use date format actually used in the country as the criterion for date format in the article. This is consistent with other usages, such as metric/Imperial units. --] 17:20, 30 December 2006 (UTC)
	::I'm sure I've said this before (although I can't be bothered to search through the archives now) but I strongly believe we shouldn't have a list of example countries there at all. It just invites people to add more and more. I don't believe the list of countries adds anything to the guidance. Let's just remove them. ] (]) 20:26, 30 December 2006 (UTC)
	:::Left to my own devices, I would tend to agree that we shouldn't have a list at all. Historically, however, the problem has been that certain editors mostly in the US have taken the view that in the absence of instructions to the contrary it's OK to use month-day-year format for all countries even when normal practice in those countries' languages is day-month-year, thus rubbing everyone else up the wrong way and creating the perception that all countries should be named in the example countries, even though countries which use month-day-year format are a very small minority in the world (and ignoring East Asian languages which use year-month-day format). Personally, I would prefer the statement to be changed to read "use month-day-year format in articles relating to North America and a few countries very heavily influenced by the US, such as the Philippines and Micronesia, and day-month-year format everywhere else." -- ] (]) 14:50, 31 December 2006 (UTC)
	::::I would leave the instructions, but without the list. In other words:
	:::::''If the topic itself concerns a specific country, editors may choose to use the date format used in that country. This is useful even if the dates are linked, because new users and users without a Misplaced Pages account do not have any date preferences set, and so they see whatever format was typed. See ] for more guidance.''
	::::This seems to me to be just as definite and more concise. If, as in your example, a U.S. editor were to change a British or a French article to American dates, it's just as good to cite this guideline as the existing one when changing it back.
	::::] (]) 17:35, 31 December 2006 (UTC)
	A change to the project page must be supported by a ''prior'' discussion. I reverted the change because of a lack of this discussion (what is above is still insufficient, you must give everyone some time).
	To emphasise this, I am deliberately ''not'' commenting on my opinion on this change. All I want to press on in this post is that this is not a minor change, and agreement (or lack of opposition within a reasonable time) must be found here first. I will leave further comment on the change itself to other users and may comment on it in one or two days, to emphasise that I reverted not because of my opposition, but because of process. ] 03:02, 31 December 2006 (UTC)
	:Adding another nation to an existing list of nations '''is''' a minor change, when they are united in date format. The debate is whether there should be a list at all. --] 20:27, 31 December 2006 (UTC)
	:Looking back, it seems there was no problem with adding other nations such as Ireland and Palau. I cannot see why France should require special treatment. --] 08:11, 1 January 2007 (UTC)
	::I've reverted it again. It's clear from the discussion here that there is no consensus for this change. Neonumbers is right &mdash; you need to wait until the discussion has concluded. ] (]) 08:45, 1 January 2007 (UTC)
	::My point is that prior consensus was not found for other additions such as . Adding to a list where the criteria for membership are known should require no discussion. Ireland uses day-month-year format, as does France. --] 09:31, 1 January 2007 (UTC)
	:::So do you think we should add all two hundred or so countries in the world? ] (]) 13:13, 1 January 2007 (UTC)
	::::No, but if process is as important as some insist, then building on past process is the way to go. Once again, I point out that adding countries to a list has needed no prior discussion in the past. I'm happy to dispense with a list entirely, but '''that''' is exactly the sort of change that requires consensus. --] 17:35, 1 January 2007 (UTC)
	:::::Adding an English-speaking country seems a bit different, perhaps. But in any case you shouldn't assume that because one edit didn't get reverted that a precedent has thereby been established. ] (]) 08:41, 2 January 2007 (UTC)
	:::::Again I make the point that the list contains several nations that do not have English as a primary or official language, in that they are members of the British Commonwealth. In fact, most of the citizens of the totality of countries belonging to the Commonwealth do not speak English. Speaking English is quite irrelevant to whether a nation uses one date format or another - I need only point out that the U.S. and the U.K. both speak English, yet use different formats.
	:::::And no, it's not just one addition to the list. The last half-dozen additions have been added with no objection or prior consensus. That looks like a pretty good precedent right there, which is why I simply added France to the list. --] 17:28, 2 January 2007 (UTC)
	Would anyone like to comment on my proposal above that the list of countries be deleted entirely? ] (]) 08:41, 2 January 2007 (UTC)
	:You've convinced me, Stephen. I support it. ] 11:11, 2 January 2007 (UTC)
	:I'm happy to lose it, but I make the point that we still need to know which countries use which date format. Who knows what format Wallis uses? Or Burkino Faso? --] 17:28, 2 January 2007 (UTC)
	::I'm assuming that someone writing the article is likely to know. In any case, I don't think we should maintain a list to tell people which format Burkino Faso uses. ] (]) 18:21, 2 January 2007 (UTC)
	:::Looking back at the history of date formats, it seems that a lot of editors imagine that all nations use the same date format. For example, look at ], an article which has had a lot of attention recently, yet still contains at least one day-month-year date, in the third paragraph of the "childhood" section. This was in the past week. This format is incorrect according to the bulk of dates in the article, the subject matter, and these guidelines. I think that even if someone knows the date of independence of Burkina Faso, or when the explosion at ] occurred, we have no guarantee that they know what format to put that date in. They will probably guess. --] 01:01, 3 January 2007 (UTC)
	::::Yes, you're probably right actually. But I still don't think we should have a list of 200 countries with their date formats, and therefore we shouldn't have a list at all. At least, not on this page &mdash; it would be a good idea as a proper article. ] (]) 10:43, 3 January 2007 (UTC)
	:I agree that the list of countries should be deleted, because I also think that all Misplaced Pages articles should use international standard date format. However, I also think that a list of date formats used by various countries would be a worthwhile Misplaced Pages article. -- ] <sup>]</sup></small> &bull; 2007-01-03</small>
	::I think both the decision and publication of which format to use should be left to the Wikiproject for each respective country. I think editors involved with those projects have the right to determine that for theirselves, and post their guideline on their page, if and only if they wish to do so (and some countries may not). If there is no Wikiproject for a given country (or a given non-country Wikiproject), then leave it to the article's editors to decide.
	::Keep in mind that an editor might enter the wrong date format from mistake, ignorance or newbieness: in this event, all that needs to happen is for another editor to correct it. Editors are not expected to be familiar with the manual (it's too big); it exists for articles to adhere to, not editors. As long as one person can stop by and correct it, it's not big deal (that's what a wiki's about). ] 09:48, 4 January 2007 (UTC)
	I've removed the list now, since the few people who commented seemed to approve, and no-one objected. I notice, by the way, that there is some guidance about individual countries in the article ] (which the paragraph links to through the redirect page ]). ] (]) 11:19, 5 January 2007 (UTC)
	:I have no problems with removing the list, and I especially like the idea of letting WikiProject editors decide how to handle nation-specific dates. Some date formats (such as year-month-day) used in Asia might require special treatment, at least until we find a solution to the date linking/user preferences thing. --] 00:40, 6 January 2007 (UTC)
	== Time interval ==
	I can't find out a policy concerning time intervals.. think about a sport competition.<br />
	What about 22 seconds and 7 tenths? 22.7 / 22.70<br />
	What about 4 min and 22.7 seconds? 4 m 22.7 / 4 min 22.7 / 4'22"70<br />
	What if you take into account hours?<br />
	Don't bite newcomers, ] 23:53, 30 December 2006 (UTC)
	:22.7 and 22.70 are not the same thing so it is not a style matter to be decided. " and ' are discouraged as too opaque. 4 min 22.7 sec is acceptable. ] 00:54, 31 December 2006 (UTC)
	::These are not the same thing. 22.70 specifies that the measurement was precise to the hundredths. —]→]&nbsp;&bull; 02:56, 31 December 2006 (UTC)
	That's a very good question, Marra.
	My take is that an interval of a time is a quantity, and is therefore governed by the "Units of measurement section" rather than the "Times" section, which aims to do with times of the day. Therefore, in prose, it should be expressed as "22.7 seconds" or "22.70 seconds" (depending on the accuracy of the measurement as Centrx said). Likewise, for minutes, "4 minutes 22.7 seconds" or "4 minutes and 22.7 seconds". If in a table or infobox, the symbols are min and s respectively (SI), though "sec" might be more appropriate &mdash; personally I much prefer "s".
	It would help if you gave us a pointer to the article itself so that we can understand the context. Good job with pointing out the lack of clarity there. ] 03:14, 31 December 2006 (UTC)
	::I first found 3 m 46.29 s in ]'s article, that was not consistent within the article. Looking at other swimming/athletic articles I found that there is not an uniform style, and neither a clear MOS entry.<br />
	::Quite a lot diffused is to say 3:46.29, in my opinion is more compact and clear than 3 min 46.29 s .. add a couple of hours and it makes 2:03:46.29. I think this is the best format despite heavy when going from hours to hundredth (hh:mm:ss.xx - with xx I mean 1/100th). ] 09:24, 31 December 2006 (UTC)<br />
	:::How would I know that 3:46 was three minutes and forty-sex seconds but not 3 hours and 46 minutes? I don't like that format at all. Remember "Wiki is not paper" and spell out as much as possible. ] 21:57, 31 December 2006 (UTC)
	You'd certainly be right to say that the format should be consistent!
	While it would be possible to argue that the true meaning of 3:46 (and, for that matter, 3:46.29) can be determined based on context, I would still prefer to avoid the risk. In my opinion, 3 min 46.29 s is more readable than 3:46.29&mdash;which is of course simply opinion.
	It is best to spell out units as 3 minutes 46.29 seconds, but looking at that article, it looks as if it would become rather cumbersome. (Personally, I think the article focuses too much on the little things like times and details, but that's another issue and not one for us.) It might be fair to abbreviate units here, but I would still prefer against 3:46.29, except in extended tables (of more than, say, ten rows). My two cents. ] 07:49, 1 January 2007 (UTC)
	Well.. I did a quick survey on ] and ] websites, it turns out that the format hh:mm:ss.xx (with xx I mean 1/100th) is the one actually used.<br />
	* In long events hundredth are avoided and sometimes even tenth
	* In sprints hours are not taken into account and even minutes may be omitted and
	This format is never ambiguous (3:46 can't exists since for a such short race hundredth are considerd, so 3:46.29) and rarely heavy to read (since you never go from hours to hundredth).<br />
	Choosing the format for wikipedia you should consider that this kind of articles are often filled with a lot of timing info so compactness is an issue. By the way I wouldn't say that these infos are details! Believe me that these are really interesting things for a fan. ] 16:36, 1 January 2007 (UTC) <br />
	:lol, okay, for a fan (as only an encyclopedia can do), if you say so... :-P and ''we'' should consider, Marra ;-)
	:For an article like that I could understand 1:23.45. The only concern I would have is immediate clarity for people that aren't sports fans. In context, it's not ambiguous, but as is always the case, it needs to be clear. Such clarity could be achieved by, say, clear wording of a sentence, or may not need any effort at all to be achieved.
	:I would imagine that this format would only work well for race times (and lots of them). Intervals of time in other contexts would be better off with 1 min 23 s &mdash; unless there's other contexts? ] 07:37, 2 January 2007 (UTC)
	::I completely agree with you, in sport-related articles hh:mm:ss.sss is the right format.. moreover ] and ] say the same thing! :)
	:: I read some ISO directives and stuff like 3 min 46.29 s are never mentioned. Will ''we'' still allow this on wikipedia? I'd say yes for purpose of clarity.. but the answer is no more obvious in my opinion. ] 09:25, 2 January 2007 (UTC)
	:::I'm just trying to think of an instance in which it would actually need to be used. If there is one, then yes. The abbreviations are those recommended by the SI manual, and it follows all of the guidelines in the units section of our manual here, and of course it's clear. I think we would need it for intervals of time that are both abbreviated and not a race time, but I can't name any. Even for non-race sports like football and basketball, I don't see how such information would be encyclopedic content anyway (except in exceptional circumstances).
	:::As always, most instances would be fully spelt out, but in the event that abbreviation of this is required, I'd say yes too. ] 11:09, 2 January 2007 (UTC)
	::::For instances look and . There are a lot of space related articles, but this seems to be the only other field. I think this format fits well here, because space articles use it few times. ] 18:47, 2 January 2007 (UTC)
	:::::Okay. That clears that up, then. I don't think it's necessary to include this explicitly in the manual, but at least we've cleared it all up. ] 08:55, 5 January 2007 (UTC)
	==Question RE: Linking Source Access Dates in a Citation==
	For a FA-candidate, one reviewer continues to object on the grounds that the dates on which a cited source was accessed as mentioned in the footnote/citation should be linked up. I refuse do to this, as the nominator and chief contributor to the FA-candidate because it's just ludicrous given that this is just a "guideline" and that it would violate ] in that linking up such dates will not be relevant to the article's context or aid or facilitate in any way a reader's understanding of the article. So I ask the following:
	* What is the consensus regarding this guideline being in force on access dates in citations?
	* If there hasn't been a consensus, what is the opinion of the contributers and other people who debate this MOS provision?
	I thank you in advance for your answers and assistance. &mdash;] 18:04, 1 January 2007 (UTC)
	:The reason we use linked dates is not because they link to anything, but because they are automatically converted to the user's preferred format. For a FA, all dates should be wikidates. --] 18:37, 1 January 2007 (UTC)
	:* Please see and respond to the question below posed to Dwaipayanc. &mdash;] 18:43, 1 January 2007 (UTC)
	:'''My observation''' Quoting ], ''"If a date includes both a month and a day, then the date should almost always be linked to allow ] to work, displaying the reader's chosen format."''
	:Also, ''"This ''']''', like all ]s, attempts to encourage consistency and ease of reading. The guidelines here are just that: guidelines are not inflexible rules; one way is often as good as another, but if everyone does it the same way, ] will be easier to read, write and edit."'' Please comment. Regards.--] (]) 18:39, 1 January 2007 (UTC)
	:* '''Please explain how linking source access dates are relevant to the context of the article or how they increase the understanding of an article? Please don't just quote the MoS, because it's already accepted as a given...ambiguous and contradictory as it is.''' &mdash;] 18:43, 1 January 2007 (UTC)
	::Well, access dates are ''not'' relevant to the context of the article. That is clear. This policy concerns allowing ] (to display the reader's chosen format).--] (]) 19:57, 1 January 2007 (UTC)
	::Linked dates make the article easier to read because the date appears in a format which is natural to the reader, not one which is unnatural. I think almost everyone agrees that linking and formatting should be able to be done separately, but the software doesn't work that way at the moment. Given that they're the same operation, the clear consensus is that the advantage of making dates appear in the reader's preferred format is greater than the disadvantage of making links that are not relevant to the context. ] (]) 20:03, 1 January 2007 (UTC)
	:This again? Please see ] above, especially the subsection "Update on progress". A lot of people share your concern about overpurposing the linking of dates, but progress on a fix is slow. -- '']']'' 17:37, 2 January 2007 (UTC)
	== Space between currency symbol and number? ==
	So for most units (which go after the number) we have a clear guideline to use an nbsp space between number and unit. For currency symbols in front of the number, there is no such guideline - and the examples in this manual are not consistent:
	*]123
	*]123
	*] 123 or ] 123 '''''<====='''''
	*]123
	*]123
	*]123
	*]123
	*123 ], ] 123, or ] 123 '''''<====='''''
	...so GB pound and Renminbi both have spaces - but the others don't? Where there is a space, it's not a nbsp space? I can see why we might want a space between ]/] and the number - it looks weird with the ] form - and why is it any different than ] in this regard? When there is a space - should it be an nbsp? I think so - we don't want it split from the number by a newline. Help! ] 00:40, 3 January 2007 (UTC)
	:I agree that any space ought to be a nonbreaking space. Past that, I have no opinion. This may be one of those cases where every country on Earth uses a quaint local format. And we are a long way from an international standard currency. -- ] <sup>]</sup></small> &bull; 2007-01-03</small>
	::Well, then I think I'll 'be bold' and just fix it. I'm going to put:
	:::"Cases such as ] which end in a symbol should not be followed by a space and the cases where there is an alphabetic character should be followed by a single, non-breaking space."
	::] 05:58, 4 January 2007 (UTC)
	: I still think currency should be treated just like any other unit, i.e. suffixed with a space (123 GBP), but I guess even if I got support here, the common English editor would ignore that (logic) convention (because he would not look for it and assume a different one). ] 12:04, 10 January 2007 (UTC)
	== Context (Number in words) ==
	<blockquote>*Within a context or a list, style should be consistent. Example: ''There were 5 cats, 12 dogs, and 32 birds.'' or ''There were five cats, twelve dogs, and thirty-two birds.''</blockquote>
	Is there a clearer definition of "context"? Something like "He is nth place in RBI (three-digit number) and nth place in stolen bases (two-digit number)" would be confusing because it looks like there are two contexts intertwined (and often viewed as one context). <small>—The preceding ] comment was added by ] (] • ]) 18:02, 6 January 2007 (UTC).</small><!-- HagermanBot Auto-Unsigned -->
	:(Damn, got caught by HagermanBot :( ) ]<sub><i>(])</i></sub> 18:03, 6 January 2007 (UTC)
	::I'm not sure it's possible to be definitive about what makes a "context", because it could be very subject-specific. ] (]) 20:17, 6 January 2007 (UTC)
	:::In that sentence, I would consider the two places in the same context, and each of the numbers in parentheses in their own contexts &mdash; but then again, you could apply the "list" one to that sentence, because if you remove everything in parentheses, you'd find that it's sort of a list. ] 10:07, 7 January 2007 (UTC)
	== ] ==
	Not only does the the Manual of Style recommend ] of measure for science-related articles, but also: a Misplaced Pages goal is to present a world-wide view, see:
	<div class="messagebox cleanup metadata plainlinks">
	{| style="width:100%;background:none;"
	| style="width:60px;text-align:center;vertical-align:top;" | ]
	| This article or section deals primarily with the ] and does not represent a ''']''' of the subject.<br /><small>Please or discuss the issue on the ].</small>
	|}</div>
	Because only Burma, Liberia, and the United States have not adopted the metric system as their official non-voluntary system, it seems appropriate to use the Metric System first (with the US Customary Sytem in parentheses) in most Misplaced Pages articles.
	The US did "officially" adopt the metric system in 1975 (see ]). And, in 1988, the ] designated the metric system as "the preferred system". '''But''' it calls for a '''voluntary conversion''': the 1988 legislation states that the Federal Government has a responsibility to assist industry in voluntarily conversion.
	Please edit the project page—reversion isn't particularly helpful.--] 20:34, 6 January 2007 (UTC)
	:I've reverted it again. I'm not trying to be unhelpful, and I realise your changes were well-intentioned, but it's conventional not to make changes to the Manual of Style until after they've been discussed and reached consensus, because it affects all the other pages on Misplaced Pages. (I realise that this is contrary to the usual rule of ]).
	:There are many factors to weigh up when deciding which units to use, in particular which units the source you got it from used, and which country the article is about. But in any case it seems rather inflammatory to point out in the style guide that only Burma, Liberia and the United States have not adopted the metric system.
	:] (]) 21:07, 6 January 2007 (UTC)
	::Thank you for the very helpful discussion. I'll wait for further discussion before making any significant changes.--] 21:42, 6 January 2007 (UTC)
	:::...and thanks for your understanding. Being reverted is never pleasant, so I'm sorry I felt it necessary.
	:::I notice that the guidance does already say "If for some reason the choice of units is arbitrary, choose ] as the main unit, with other units in parentheses. For subjects dealing with the United States, it might be more appropriate to use U.S. measurements first." So I'm not even sure your latest addition "Consider applying this policy to non-science articles as well" is necessary. Do you feel the existing guideline doesn't cover it well enough?
	:::] (]) 22:00, 6 January 2007 (UTC)
	::::It's just that the quote—near the top of Units-of-Measure section—from Scientific Style, "use SI units as the main units in science articles" implies that using SI units as the main units applies only to science articles, and one has to read the rest of the Units-of-Measure section to get the sense that SI units should generally be used as the main units, followed by US units in parentheses.--] 23:01, 6 January 2007 (UTC)
	:::::No, the style guide takes no position on this, and the relevant guidance is already in the section with the appropriate wording that was given far more consideration than you edit warring. —]→]&nbsp;&bull; 04:30, 7 January 2007 (UTC)
	== Month and Year only ==
	*April, 2006
	*April of 2006
	Which one should we standardize on? --] 10:45, 8 January 2007 (UTC)
	:Pardon? What would be the ''need'' to standardise on anything here?
	*:We don't ''need'' to even create an online encyclopedia, yet we do. --] 11:24, 8 January 2007 (UTC)
	:*: However, we don't create Misplaced Pages '''guidelines''' for the fun of creating them. If there's no issue to address, this is called rulecruft, per ]. "Instruction creep" is the equivalent of "non-notable" in main namespace, and gets deleted. So if you can't demonstrate making a choice between "April, 2006" and "April of 2006" is beneficial for the encyclopedia, there's not going to be a rule about it. Further, if you'd have read the below, you'd have gotten the hint that, as far as ''page names'' are concerned, current standardisation seems to go toward ], and neither "]" nor "]". No problem for me to add that to ] --] 11:36, 8 January 2007 (UTC)
	:**:Done, see ] --] 12:05, 8 January 2007 (UTC)
	:Only for page names, arguably, some standardisation *might* (that is if this would be a real problem, as in: matter of dispute) be in order. In which case ] is the relevant guideline, and not this MoS page. Note that ] is an example on that NC guideline page, in this paragraph (I added some bolding):<blockquote>If a time indicator is used in the title of an article on an event that doesn't recur at regular intervals (or didn't recur at all) '''there's no "standard format" for the representation of the time indicator''', so there is for instance: ]; ] (one of the developments of the First Crusade); ], etc... The format of the date depends, in these cases, from '''established practice in history books and the like'''. In general, however, '''abbreviations for years or months are avoided''' (e.g., <s>May '68</s> &rarr; May 1968); for centuries numerals are given in text, capitalised (e.g., <s>Crisis of the 3rd century</s> &rarr; Crisis of the Third Century)</blockquote>So, neither "]" nor "]" as page name for the content (but both can be redirects of course). And in all other articles you use what is most appropriate. Which may be "May of 1968" or "May, 1968" as you choose, for example for something that happened in the US, and has no relation to what is described in the ] article. --] 11:08, 8 January 2007 (UTC)
	:Note also that currently ] is a page name, without ] nor ] redirecting to it. Feel free to create these redirects. --] 11:18, 8 January 2007 (UTC)
	Oops, and then I also just noticed this in ]:
	* Do not put a comma or the word "of" between a month and year:
	** Incorrect: "December, 1945" and "December of 1945"
	** Correct: "December 1945"
	...which seems to make this discussion moot (as far as the current content of the MoS is concerned - or was there an intention to change that?) --] 12:22, 8 January 2007 (UTC)
	:...ummm, yes, April 2006 is the correct format, and has been for quite some time, and neither month nor year should be linked. ] 23:44, 8 January 2007 (UTC)
	== a dot m dot ==
	I think it's a little inflexible to disallow 1pm and 7am. Why insist on dots when the language has undergone a clear shift to removing them in initialisms such as NATO, NASA, and BBC? Only U dot S dot survives, in the US alone, since other English-speakers have lost the dots in that one. ] 11:10, 8 January 2007 (UTC)
	* NATO, NASA, and BBC are not equivalent comparisons to A.M. and P.M. and neither do NATO, NASA and BBC use them. They use 24-hour time, sometimes like 0700 or 1300, sometimes split by a colon 07:00, 13:00. Most of Europe doesn't use P.M. or A.M. And writing it as 1pm is lazy, sloppy and not acceptable per style guides, writing manuals, etc.. This isn't a metric measurement abbreviation like kilometer, or gram, (which is usually the abbreviation of one word), it's an abbreviation of a Latin phrase. When abbreviating a multi-word phrase (like post meridian or ante meridian, or anno domini, or before christ, or id est, or examplia gratia, or ad majorem dei gloriam) or something that isn't speficially an acronym like NATO or NASA or BBC, it's typical to use periods (they have a name...and that name isn't "dots"). The U.S./USA (as well as U.K./UK) example is not accurate (spots outside the U.S. still commonly use the punctuated form), nor is it a decent comparison. Because it hovers on that acronym/abbreviation boundary and does so chiefly because of the third letter, as in USA. &mdash;] 19:08, 8 January 2007 (UTC)
	**No, you misunderstood what ] said. We don't use N.A.T.O., N.A.S.A. or B.B.C. anymore - so why would we say 1p.m. and 7a.m.? We say NATO, NASA and BBC - so we should also say 1am and 7pm. (And we do - I've looked at a bazillion articles and I've yet to find one that uses the a.m. and p.m. style. If this policy says that, it's being widely ignored - and correctly so I would say). ] 19:28, 8 January 2007 (UTC)
	*** No I didn't, I understood completely, and explained to Tony the rationale. You're the one with reading comprehension problems NATO is an acronym. p.m. is an abbreviation, not an acronym. I don't use p.m./a.m. I stick to the 24 hour clock that most of the world uses and which renders p.m. and a.m. obsolete. &mdash;] 19:28, 8 January 2007 (UTC)
	**** I agree that 24 hour clock notation is clearer - but that's not what a large fraction of the English speaking world uses - so we are stuck with am and pm (or a.m. and p.m.) and we need a policy to allow us to write times like that. (Incidentally, you said that 'period' is preferred over 'dot' - that's only true amongst US English speakers - British English speakers call that character a 'full stop'. Since 'full stop' is a bit of a mouthful, many people (especially computer users) just say 'dot' instead. Notice that people say: "W W W dot Misplaced Pages dot org" rather than "W W W period Misplaced Pages period org" or "W W W full-stop Misplaced Pages full-stop org". I would go so far as to suggest that 'dot' is used when talking about the ASCII character '.' and 'full-stop' or 'period' refers to the use of that character as a punctuation symbol. ] 19:34, 8 January 2007 (UTC)
	***** FYI, they've only been known as "full stops" since the telegraph was invented. &mdash;] 00:10, 9 January 2007 (UTC)
	****** I'm from New Zealand, and here, we always say "dots" unless we're referring to something that goes at the end of a sentence, in which case, "full stops". :-P ] 00:23, 9 January 2007 (UTC)
	The guideline is deliberately inflexible to encourage consistency. For all it's worth, am, a.m., AM, or A.M. could well have been chosen at random; however, I am still of the position that a.m. would be the best option. From what I have seen, none of those four options is any more common than another, and all are equally accurate and understandable. However, for ''one'' encyclopedia, ''one'' format should be chosen.
	The difference between a.m. and an acronym is that acronyms are all in uppercase, thereby making it clear that it is an acronym, whereas the same does not hold for a.m.. I do not see this as comparable to acronyms: I see them as entirely independent situations. "a.m.", in my opinion, looks neater and more obvious that it is an abbreviation of something. ExplorerCDT provided a good (better) explanation (from his fourth sentence onwards).
	The Chicago Manual of Style recommends either "a.m." or "<small>AM</small>" (in small caps). For obvious reasons, the latter wouldn't really work here.
	In terms of application, I would encourage everyone to try not to think of the manual in terms of "working" or "ignored", but as guideline of good and consistent style that articles will eventually find their way to. The time guideline is the relatively new one, and times are not often encountered in articles (at least, not in my experience), so I would fully understand that most times don't follow it yet. Editors are not obliged to follow the manual of style, and for something uncommon like this I wouldn't expect most editors to even know about it. ] 23:39, 8 January 2007 (UTC)
	* Also consider that in Latin, it is "ante meridian" (or meridien, meridiem...the "ian" is horribly anglicized Latin) and "post meridian" and should be used in lowercase for chiefly grammatical reasons relating to its case and sentence placement. The subscripted "<small>AM</small>" is probably recommended by Chicago MoS to differentiate it from the typeface of the regular text by which it may be surrounded. &mdash;] 00:08, 9 January 2007 (UTC)
	: "am" would be the unmarked case, i.e. it looks like a normal word. It has been a long tradition and it is a good choice to use a marked case for abbreviations. Using dots (or whatever you prefer to call them) is one option, uppercasing (or using ]s) is another, combining both is redundant and therefore for a large part is being phased out. Some people prefer to use dots for abbreviations that are (usually) expanded upon reading ("i.e." -> "that is") and all caps otherwise (and then there are those acronyms (e.g. RADAR) that become real words (radar) after a while).
	: The "U.S." case I could only explain with situations where the unmarked case is all uppercase as often seen in CNN-inspired TV crawls, because there is also another, common English word that would look the same ("us"). Why US-Americans cannot get used to "US" in normal text, I do not understand. It was not possible to convince them over at Talk of the parent of this page the last two times I tried.
	: We would not have to have this discussion at all if we had stayed with the 24-hours format. ] 12:33, 10 January 2007 (UTC)
	:: Yet again, if Misplaced Pages would just standardize on international standard date format (ISO 8601), this would not even be an issue. -- ] <sup>]</sup></small> &bull; 2007-01-11 21:43Z</small>
	*Explorer, I wasn't expecting to be called "lazy" and "sloppy", nor to see someone else accused of having a reading problem. They're acronyms ''only'' if they can be said as a word in their own right, such as "NATO"; they're initialisms if not, such as "PBS". AM and PM are initialisms whether we like it or not. Yes, e.g., needs the dots, still, I'm advised by professional editors, despite what plain English proponents say. I think that this issue is unresolved, and that the neatest solution is to be inclusive and allow WPs to use upper or lower case, dots or no dots, as they choose—just as for the free policy on the use of spelling dialects. Consistency within an article is, of course, the important issue. ] 01:12, 12 January 2007 (UTC)
	::I still hold that we should advise one specific format for the entire encyclopedia (i.e. one for 12-hour, and another for 24-hour). Consistency across the encyclopedia is best.
	::I hope that people will be willing&mdash;especially on a minor issue like this&mdash;to abandon their personal preferences and agree to stick to one format, whatever the format will be. Yes, I meant the "personal" part &mdash; even if you can ''explain'' your personal preference logically (and I know we all can), if we take a step back and think about it, ''all'' the formats ''can'' work.
	::Some, in our respective opinions, will work better than others. For example, I am of the opinion that "a.m." works best. But this does not mean "am" doesn't work at all. I've seen all four formats (AM, A.M.) and understood them all. But it is far more beneficial for us to stick to one format&mdash;any format&mdash;in the interests of making Misplaced Pages one, coherent, professional encyclopedia.
	::Before anyone brings up instruction creep, this isn't intended to make ''people'' use one format, it's intended to get ''articles'' consistent. All that matters is that changes to make it that format are respected (and editors that ''want'' to know which one can come here and find out&mdash;those that don't needn't worry). To say "use any" defeats the purpose of this so-called "guidance". ] 04:27, 12 January 2007 (UTC)
	::: You have nailed the problem of many of the so-called guidances in this Manual of Style. They are too loose. ] 14:02, 12 January 2007 (UTC)
	:::: I don't see the benefit of rigid standardation on such a trifling detail. There are plenty of things in Misplaced Pages that are inconsistent, starting with the article prose and on through the category system, use of BE/AmE, and through just about everything else. That is pretty much what makes the encyclopedia work; rigid standardization improves nothing and harms much, and I for one don't plan to follow the people on this crusade. --] 09:24, 20 January 2007 (UTC)
	::::: I fail to see how any article can be harmed by having it's a.m./p.m. style changed. Certainly a substaintial number of the articles that I edited some time ago when I brought them all into alignment, used a mixture, which was not good. The only downside is we may be giving (by a combination of all the stlyle editing) an air of a level professionalism which the content falls short of. ''] ]'', 14:33 ] ] (GMT).
	== Date ranges ==
	What about date ranges? I ran into 14-15 May 1994. Either ]-], 1994 nor ]-] ] won't work for user with different preferance. Is this addressed? Thank you.--] 03:09, 12 January 2007 (UTC)
	:It's brought up on this talk page from time to time. You certainly need the month in both dates as you've discovered, but if I recall correctly, I think the only format which works for all date preferences is to include not only the month but also the year in both dates, i.e., <nowiki>] ] &ndash; ] ]</nowiki> or equivalent.
	:Do people think we should make a guideline about this? It seems to be something of a ].
	:] (]) 09:37, 12 January 2007 (UTC)
	::Yep, that seems to be worth it. Would it work without the first mention of the year? It'd be fine by me. ] 11:40, 12 January 2007 (UTC)
	:::I think it doesn't work for the few people who've chosen ISO 8601 dates. They would see ] &ndash; ]-]. ] (]) 12:23, 12 January 2007 (UTC)
	::::And people who've chosen the year-first format "1994 May 15" have the same problem: "14 May - 1994 May 15". ] (]) 12:25, 12 January 2007 (UTC)
	:::::Would it be possible to create template for such things? f.e. <nowiki>{{dr|94-05-16|94-05-17}}</nowiki>. Would it be possible to program it to include different user settings and different types of ranges? It doesn't look good to have in the text May 16, 1994&ndash;May 17 1994, does it? It even spoils the meaning since such a long range looks rather like different years not two days. Thank you.--] 01:34, 13 January 2007 (UTC)
	:I rather foolishly hinted at this problem with the proposed alternative syntax for dates. But the above summary is correct, although I think that adding the month is a good compromise. (How many people havbe ISO set (I know I have had) ? ''] ]'', 14:35 ] ] (GMT).
	== Year linking and delinking ==
	I am posting here as I have just finished an attempt to mediate between two users who were falling out over their strong and opposed positions on whether (some, or all) standalone years should be linked.
	I thought the edited highlights of the discussion we had there might be interesting to readers of this page, and so I append them below. I'd like to think that, especially if we are eventually able to remove the necessity to link dates for them to follow users' date preferences, this could allow us to reduce the amount of overlinking currently present in many articles, clarify the current "wooly" MoS guideline, and thus avoid future friction over this.
	Specifically, I propose Quadell's remedy (see table below) as a new guideline for linking years. I'd also suggest something along the lines of "If in doubt, don't link" as many, many of these year articles do not provide any useful context and, it seems to me, never can. Anyway, please read it and see what you think. The original text this was condensed from is at ] and ].
	--] 03:42, 12 January 2007 (UTC)
	(copied text begins)
	This page is an attempt to resolve the dispute about the linking of year articles. Perhaps it could serve as a step towards a more general agreement though. Once this dispute is resolved I will paste it into ].
	===Background===
	At present we have got:
	"'''Partial dates'''
	If the date does not contain both a month and a day, date preferences do not apply: linking or not linking the date will make no difference to the text that the reader sees. So when considering whether such a date should be linked or not, editors should take into account the usual considerations about links, including the recommendations of ]. ...
	... There is less agreement about links to years. Some editors believe that links to years are generally useful to establish context for the article. Others believe that links to years are rarely useful to the reader and reduce the readability of the text. Another possibility is to link to a more specific article about that year, for example <nowiki>]</nowiki>, although some people find this unintuitive because the link leads to an unexpected destination."
	(]).
	While I think I understand why this compromise version was adopted, I also think the ambiguity leads to some unfortunate friction between users who think all year links, or almost all, should be delinked, and those who regard this as a loss of utility in articles.
	===Declaration of my own POV===
	I tend to side more with the delinkers than with the linkers. I find that the majority, even a vast majority of year links are adding little or nothing. I can see the merit of the other side's opinion too, and I promise to try my best to mediate here without regard to my own POV. For interest, here is a recent copyedit I made which includes date delinking: .
	] 04:23, 3 November 2006 (UTC)
	===Framework===
	{| class="wikitable"
	|-		|-
			|data-sort-value="100"|100 years||big
	!Never link / Can be delinked on sight
	!Seldom link / Usually delink
	!Usually link / Sometimes delink
	!Always link / Never delink
	!User
	!Comment
	|-		|-
			|data-sort-value="{{#expr: 2/365.2422}}"|2 days||tiny
	| Multiple repetitions of the same linked year within a page, especially in lists. Links where the article linked to would in my judgement clearly add '''no''' context to the subject of the article.
	| '''Recent''' links, say roughly from ] - ]. "Easter egg links" like <nowiki>]</nowiki>. Rather use: (See also ])
	| ] - ]
	| dates prior to ]
	| ] (before)
	| These are just my own interpretations; I stress I always discuss link removal on the odd occasion someone challenges it. I obviously try to judge each case on its merits.
	|-		|-
			|data-sort-value="{{#expr: 10/365.2422}}"|10 days||tiny
	|Standalone year or year-month links where, in my judgement, they add no context. I rarely see any such value, just confusion as the reader is confronted with a sea of blue years: what is of value to them? What not?
	| N/A
	| N/A
	| Year links in century articles
	| ]
	| As far as I know, this is the editing I am supposed to be doing as a WP editor. However, I also do not like the loose guidelines and the trouble they cause and said so when they were being discussed; however, in the interest of 'consensus', the guidelines, as written, were accepted.
	|-		|-
			|data-sort-value="{{#expr: 20/365.2422}}"|20 days||tiny
	| I think this is inherently a judgement call. If someone thinks it is useful, keep it. If someone doesn't, remove it. Just don't get in the habit of spending all ones time doing either one or the other.
	| Generally, I don't mind if people cut recent links (say, last twenty years). I disagree with Guinnog about setting a cutoff about 1900 - most of the most useful links, I would argue, are those for historical articles during the 20th century, where providing a broader geopolitical context is often really quite relevant.
	| Again, I think this is inherently a judgement call. There are many cases where links in the time periods both Guinnog and I mention where date links may be relevant, but there also many where they may not. I don't think setting specified dates is particularly helpful, though I do think there's much less likely to be an issue with removing date links in the last couple of decades.
	| As above.
	| ]
	| I think this really is a matter of both having respect for other points of view and using a bit of discretion. Setting hard and fast rules inevitably leaves useless date links in and leads to the removal of perfectly useful ones.
	|-		|-
			|data-sort-value="10"|10 years||mid
	| Multiple repetitions of the same linked year within a page.
	| Any year link, except in special circumstances. "Easter egg links" like <nowiki>]</nowiki>. Rather use: (See also ])
	| Century links (most cases)
	| Year and/or century links '''that are critical to the understanding of the article'''
	| ] (after)
	| I have learned a lot from this study and thought it would be interesting to summarise that in this table.
	|-		|-
			|data-sort-value="2"|2 years||small
	| Multiple repetitions of the same linked year within a page. "Easter egg links".
	| Years mentioned in an article, where the event is important, but not the year itself. E.g., the year an album was released in an article not about the album.
	| Any year links important enough to the article that it would be appropriate to use them in the main (summary) section, e.g. the founding year for an empire in that empire's article, or the year a swimmer won the Olympics in an article about the swimmer.
	| Birth and death years, or years in century articles.
	| ]
	|
	|}		|}
			:Note that anything less than a year is NumDays/365. Of course, you can choose your own base unit.
			:See ] <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&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. –] (]]) 05:24, 6 January 2025 (UTC)
	====Links removed by both====
			:::It is more obvious when you look at the wiki mark-up: <syntaxhighlight lang=wikitext>{|class="wikitable sortable"
	* Repeated links, especially close together in article. NB that medieval is a redirect to ], and that eg 1400s is often misused in place of 15th century. Whether linked or unlinked, this is a serious error and should be checked and corrected wherever seen. Note also that forms like "twelfth-century" and 1980's (for the decade) are considered wrong and should be corrected, and that ]s is not a link to the decade but to the single year.
			!value!!name
	* Recent links are seen as low-value by all three of us. I thought roughly the last 100 years, Rebecca is more conservative and says the last 20 years. Obviously both of us would use an element of discretion here when delinking.
	* Easter-egg links of the type <nowiki>]</nowiki> are deprecated.
	====Links removed by Hmains but retained by Rebecca====
	(in order of appearance in the article)
	*]; some good background about the historical era.
	*]; much less useful
	*]; another fairly poor article. Peripheral interest only.
	*]; thin article but contained one interesting fact slightly relevant to article
	*]; peripheral interest only.
	*]; one interesting fact; but this article is tiny. Little benefit.
	*]; thin article but contained one interesting fact slightly relevant to article
	*]; a slightly better article. One or two interesting facts. Some interest.
	<s>*] (second instance, but well down a long article from the first)</s>
	*]; another thin article. One slightly relevant fact.
	*]; nothing here of any relevance to the article at all.
	*]; peripheral interest only.
	*]; article hardly exists. Nothing whatsoever here.
	*]; Small article. Couple of peripherally relevant facts.
	*]; Small article. One peripherally relevant fact.
	*]; article hardly exists. Nothing whatsoever here.
	*] Little more than a stub. No interest here.
	*]; peripheral interest only.
	*] Little more than a stub. No interest here.
	*]; peripheral interest only.
	*]; peripheral interest only.
	<s>*] (second instance)</s>
	*]; stub (unmarked). No utility at all.
	*]; stub (unmarked). No utility at all.
	*] Better article. Still peripheral interest only.
	*] Decent article. Good historical context.
	*]; peripheral interest only.
	*] Stub-class. Nothing, or very little that was pertinent
	<s>*] (second instance, in image caption)<s>
	*] Slightly better. One interesting (though still peripheral) link, to ]
	*] Stub. Another mention of Boethius.
	<s>*] (second instance)</s>
	*] Little here. We did get the birth of ], slightly relevant.
	*] Sub-stub article. Bede's death.
	*]; peripheral interest only.
	*] Sub-stub article. Nothing here at all
	*] Decent article. Some good context.
	*] Less good, but some peripheral interest.
	*] Some minimal peripheral interest
	<s>*] (second instance)</s>
	*] Decent article. Good historical context.
	*] Stub. Little or nothing of relevance here.
	*] Decent article. Good historical context.
	*] Barely above a stub. No interest.
	*] Mention of ] supernova slightly interesting and of peripheral relevance.
	*] Birth of ]. Very peripheral relevance.
	*] Less poor article. Little of relevance though.
	<s>*] (third instance)</s>
	*] Little here of interest. Less poor than some of the earlier year articles. Peripheral interest only.
	*] Stub article. One very interesting and relevant fact. Unfortunately ] is a redlink. Could be improved though.
	*] Good historical context.
	*] Nothing much here. Peripheral interest for those who like random facts.
	*] Very respectable article. Good historical context.
	*] Reasonable article. One very relevant reference.
	*] Nothing much here. Peripheral interest for those who like random facts.
	*] Nothing much here. Peripheral interest for those who like random facts.
	*] Nothing of relevance.
	*] Some minimal historical context.
	*] One interesting fact.
	*] Some minimal historical context.
	====In chronological order, by type====
	{| class="wikitable"
	|-		|-
			|data-sort-value="100"|100 years||big
	!Century or year
	!Grade for article quality <br>(1=high, 5= low) <br><small>(=x)</small>
	!Grade for relevance to ] <br><small>(=y)</small>
	!Grade for utility <br><small>(=x*y)</small>
	!Comment
	|-		|-
			|data-sort-value="{{#expr: 2/365.2422}}"|2 days||tiny
	| ]
	| 3
	| 2
	| 6
	| Decent article, provides some historical context to when ] lived
	|-		|-
			|data-sort-value="{{#expr: 10/365.2422}}"|10 days||tiny
	| ]
	| 4
	| 4
	| 16
	| Little here
	|-		|-
			|data-sort-value="{{#expr: 20/365.2422}}"|20 days||tiny
	| ]
	| 4
	| 4
	| 16
	| Little here
	|-		|-
			|data-sort-value="10"|10 years||mid
	| ]
	| 4
	| 4
	| 16
	| Little here
	|-		|-
			|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;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&nbsp;</span></span> 05:35, 6 January 2025 (UTC)
	| 4
			::::Sure, why not. –] (]]) 02:10, 7 January 2025 (UTC)
	| 4
	| 16
	| Little here
	|-
	| ]
	| 4
	| 4
	| 16
	| Little here
	|-
	| ]
	| 4
	| 4
	| 16
	| Very thin indeed. Nice map.
	|-
	| ]
	| 4
	| 4
	| 16
	| Minimal article, minimal interest
	|-
	| ]
	| 4
	| 4
	| 16
	|
	|-
	| ]
	| 3
	| 3
	| 9
	| Better article
	|-
	| ]
	| 3
	| 3
	| 9
	|
	|-
	| ]
	| 4
	| 4
	| 16
	| Back to an article which is a formless list; hard to see any relevance
	|-
	| ]
	| 4
	| 4
	| 16
	|
	|-
	| ]
	| 4
	| 4
	| 16
	|
	|-
	| ]
	| 3
	| 4
	| 12
	| Longer article but still a sequence of lists.
	|-
	| ]
	| 2
	| 3
	| 6
	| Very interesting article; lots of peripheral historical articles to browse to, if you were finished reading the original article.
	|-
	| ]
	| 5
	| 3
	| 15
	| Stub article
	|-
	| ]
	| 5
	| 4
	| 20
	| Even less, and less of interest
	|-
	| ]
	| 5
	| 3
	| 15
	|
	|-
	| ]
	| 5
	| 4
	| 20
	|
	|-
	| ]
	| 5
	| 4
	| 20
	|
	|-
	| ]
	| 5
	| 5
	| 25
	| Nothing here
	|-
	| ]
	| 5
	| 4
	| 20
	|
	|-
	| ]
	| 5
	| 5
	| 25
	|
	|-
	| ]
	| 5
	| 4
	| 20
	|
	|-
	| ]
	| 5
	| 3
	| 15
	|
	|-
	| ]
	| 5
	| 4
	| 20
	|
	|-
	| ]
	| 5
	| 4
	| 20
	|
	|-
	| ]
	| 5
	| 5
	| 25
	|
	|-
	| ]
	| 5
	| 5
	| 25
	|
	|-
	| ]
	| 5
	| 5
	| 25
	|
	|-
	| ]
	| 4
	| 5
	| 20
	|
	|-
	| ]
	| 5
	| 5
	| 25
	|
	|-
	| ]
	| 5
	| 4
	| 20
	|
	|-
	| ]
	| 4
	| 4
	| 16
	|
	|-
	| ]
	| 5
	| 4
	| 20
	| Year identifies the death of Bede, but article is so poor it provides only '''two''' other links, plus the turgid ] as context.
	|-
	| ]
	| 5
	| 5
	| 25
	|
	|-
	| ]
	| 4
	| 4
	| 16
	|
	|-
	| ]
	| 4
	| 4
	| 16
	|
	|-
	| ]
	| 4
	| 4
	| 16
	|
	|-
	| ]
	| 4
	| 4
	| 16
	|
	|-
	| ]
	| 4
	| 5
	| 20
	|
	|-
	| ]
	| 3
	| 3
	| 9
	|
	|-
	| ]
	| 4
	| 4
	| 16
	|
	|-
	| ]
	| 3
	| 3
	| 9
	|
	|-
	| ]
	| 2
	| 2
	| 4
	|
	|-
	| ]
	| 3
	| 3
	| 9
	|
	|-
	| ]
	| 2
	| 3
	| 6
	|
	|-
	| ]
	| 2
	| 3
	| 6
	|
	|-
	| ]
	| 2
	| 3
	| 6
	|
	|-
	| ]
	| 2
	| 3
	| 6
	|
	|-
	| ]
	| 2
	| 2
	| 4
	|
	|}
	===Analysis (preliminary)===
	I will have more to say on this. For now, let me explain what I have just done. I tried to put myself into the role of a reasonably intelligent but non-expert person reading the article on ] (the subject of the test piece). If we can take as read that the repeated, easter egg and very recent year links are regarded by both editors (and by me) as low-value links, it is interesting to click on each of the links that Hmains would have deleted and Rebecca would not, with a view to finding what information if any related to, or even gave meaningful context to, the events described in the article.
	Some rather surprising (at least to me) things came up. The century articles seem more valuable for providing historical context than the individual year links for the earlier periods. Many of these early individual year links are so poor in my opinion as not to be worth linking to at all at present. It is also rather hard for me to see how they could ever plausibly be significantly improved. Look at ] for example.
	If you review the links in question, it is hard to avoid the conclusion that many of the year links added nothing at all in terms of direct relevance to the article. I do recognise there are some Misplaced Pages users who will value the semirandom possibility in, say, clicking on ] and thus navigating from ] to ], the roller-coaster pioneer. I had not been aware though that many of the early year articles are so poor as not to give any real possibility for this activity. I'll think about it some more and try to take this onward this evening. For now, anybody else want to comment? --] 13:02, 6 November 2006 (UTC)
	:Well, I've made a table with the links that Hmains would have deleted and Rebecca would have kept (notionally) in chronological order. For my next trick, I'm going to grade each of the articles (which I've linked from the data table; you were right, ], thank you). I've chosen to grade each article separately for article quality and relevance, from which I'll make up a utility score by multiplying the two. Like everything else here it might seem arbitrary, but I think it is fair. In the wiki spirit, I'll only do them one or two at a time, and will be happy if anyone else wants to join in. We should, especially if Rebecca and Hmains (and potentially other people) will take part, end up with a very interesting dataset, showing what links are better than others, for this randomly chosen article. I'd still like anyone taking part not to edit the original article though. I'll start by grading a couple tonight, and then leave it to see if anyone else will have a go. Enjoy, and remember we are evaluating the links not on principle, but from the point of view of being valuable to a hypothetical person doing research for a project, say. --] 23:24, 6 November 2006 (UTC)
	===Desired outcome===
	I thought this might be a good place to consider what we want from this, beyond a resolution of the immediate dispute between these two respected editors. It has become obvious that the existing policy is flawed by its well-meaning ambiguity. I'd like to propose that we aim to come up with a list of examples along the model of the table I made up; something like '''Always link''', '''Usually link''', '''Seldom link''' and '''Never link'''. I would stress that the criteria I used myself, which largely depended on the period of the date being linked to, were only my own ones, and need not be seen as a model for whatever we will end up with. I hope that the exercise I have asked Hmains and Rebecca to do may allow us to discuss towards establishing such principles. Any comments would be most welcome. --] 13:25, 5 November 2006 (UTC)
	:A resolution of the immediate conflict would be good. An improvement of the guidelines to prevent recurrence and improve clarity would be even better. '''Support''' your efforts. ++]: ]/] 22:38, 6 November 2006 (UTC)
	=== Preliminary conclusions ===
	1. I came at this as a modest date delinker ("I find that the majority, even a vast majority of year links are adding little or nothing") but with the idea that "dates prior to 1800" should be linked or left linked, while more modern ones were superfluous.
	a) I could see some merit in what Hmains was doing; systematically removing all partial date links in articles he edited, per his understanding of what the MoS allowed. I could also see the annoyance of Rebecca at what she saw as mechanistic edits, against her understanding of what the MoS allowed.
	b} It seems obvious that a lot of the problem lies with the ambiguity of the present MoS; I know that has been controversial but the compromise we have ended up with is a fudge that leaves us open to the kind of misunderstanding that happened here.
	2a) Overall, I think the results favour the idea that I came into this with, that most year links are pretty worthless. However, I will now look differently on which year and century articles are and aren't worth linking. The ] one is rather good for instance. I know that many of the 20th century year articles (that we ruled out in this study) are fairly informative.
	b) I know now that many of the year articles from early years are so poor as not to be worth linking to, ever. Furthermore I see no realistic way they can ever be improved. I saw no article for a year before 1000 that was more than stub-quality. I will certainly be much less inclined to leave links to articles like ] in place than I was before doing this. Even many of the more recent ones are poor in terms of adding understanding. You have to get into the 19th century before the articles get quite informative and well-written. Even then, few of them added real core meaning; it was more of a serendipitous sort of "what else happened that year" ability that became more real as the articles got (modestly) better through the years. (This is the opposite of what I believed before this exercise).
	c) The century articles are better than the years. Even so, some quite late ones are remarkably poor (] for example). This could be an opportunity to improve these articles; a much more realistic aspiration than fixing up the early year articles, in my view. Meantime, I would still only link to century articles in exceptional cases where it would provide a useful perspective. I would change my view somewhat if the century articles were improved.
	3. While there might seem to be nothing wrong with Hmains' edits in removing these (very often worthless) links, I understand the annoyance of editors like Rebecca at what they see as an unauthorised bot-like bulk edit.
	a) Although I have no more authority than anyone else to tell Hmains and Rebecca how to act, having thought about it a great deal, I suggest the following compromise might offer a way forward:
	b) Hmains should refrain from using automated or semiautomated methods for unlinking dates (pending the clarification to the MoS I propose below). All linking or delinking done should be justifiable; for each and every link added or removed a rationale should be possible and be provided on demand, and the rationale '''should take into account the value of the date article linked or delinked to the main article being edited'''.
	c) Rebecca should refrain from mass-reverting Hmains' edits; if she perceives a problem with an individual edit, she should merely ask Hmains nicely and he should provide his rationale, as noted above.
	d) Neither party should revert-war or be anything but civil with each other. Any problems should be referred to me in the first instance.
	4. Finally, if there is no objection, an edited version of this should be copied to the relevant MoS talk page, in case it can help progress formulation of a better policy. --] 08:02, 8 December 2006 (UTC)
	(copied text ends)
	===Suggested change to MoS===
	I propose where we currently have:
	"There is consensus among editors that bare month and day names should not be linked unless there is a specific reason that the link will help the reader to understand the article. There is less agreement about links to years. Some editors believe that links to years are generally useful to establish context for the article. Others believe that links to years are rarely useful to the reader and reduce the readability of the text."
	We substitute:
	"Bare month and day names should not be linked unless there is a specific reason that the link will help the reader to understand the article. Links to years on their own are often deprecated as adding little value to articles, but consideration should be given to including year links which add value to the article. If the year link adds little, a century link may be more useful. (Years in century articles, by convention, are always linked.)
	In deciding whether or not to include any link, the principle of ] should be followed, and the value, quality and relevance of an individual year article being linked to should be considered. The use of linking merely to emphasise important dates should be avoided.
	Mass edits which solely remove (or add) date links across many articles are discouraged, as with any mass minor edits (see for example
	'Avoid making insignificant minor edits ... because it wastes resources and clogs up watch lists.'(])), and especially because different editors will make different judgements about the value of different links.
	Easter-egg links of the type <nowiki>]</nowiki> are deprecated.<!-- The last sentence is also at ], so if it's changed here it should be changed there too --> Instead use a transparent form like (see also ]), where that article has relevant information to the article."
	--] 03:59, 18 January 2007 (UTC)
	===Comments===
	:There is no consensus for that particular guideline, as per the discussion-to-death of this issue in 2006. There is no consensus that "links to years on their own are normally deprecated as adding little value to articles". The present language is fine: date links should be treated accordingly to ], with people actually using some common sense, thought and discretion. ] 08:48, 12 January 2007 (UTC)
	::Sure. I couldn't ever be against common sense, thought and discretion. I just think it would be clearer if we could use some of what we found out in our exercise about the very low value of many of these links. It was an eye-opener for me. On the other hand, I like the idea of naming places where year articles '''should''' be linked. I certainly think the vagueness of our current wording is unsatisfactory to all and a recipe for possible further conflict. --] 08:53, 12 January 2007 (UTC)
	:::The reason the language is vague is because there isn't a ] for any stronger language. Yes, it's a recipe for occasional conflict. When we had stronger guidance here it was the recipe for a lot more conflict though. ] (]) 09:43, 12 January 2007 (UTC)
	I really dislike reading articles with a sea of blue dates. It's almost never useful to click on the date number and the blue links are distracting. However, I can see a value in such links from a point of view of information content. It is very useful indeed to be able to go to a page about a particular year and find all of the pages that link to it in order to automatically find all of the things that happened in that year. So what is truly needed is not '''''links''''' from years but '''''categories''''' for each century, for each year and perhaps even each month and day within each year. Some people have already started doing this - I see ] for new products released in 1959. So if we are considering changing the standard, I think we'd be better off having some kind of year template that spits out the year (unlinked) into the text of the article - yet adds a category reference for that year.
	As for the 'preferences' thing of rendering dates in alternative styles - that leaves me cold. Linking dates as a way to make the MediaWiki recognise them as such is an ugly mechanism. If we must do that, there should be some other kind of markup that doesn't result in an ugly link. However, providing the month name is spelled out in letters (ie not as a number), there is really no ambiguity and readers who may '''prefer''' "10th January 2007" are unlikely to be '''confused''' by "Jan 10th 2007". On the other hand, we must strongly deprecate using month numbers because "01/10/07" is utterly ambiguous. To an American, it means "Jan 10th 2007", to a Brit, it mean "August 1st 2007" and to a Dutch reader, it would mean "2001 August 7th". If we would only require the use of month names ("Aug" or "August", not "10"), I think we could simply dump the user-preference date presentation. After wall, we don't have user-preferences for regional spelling ("tyre" vs "tire", "colour" vs "color", etc) - or word choice ("lorry" instead of "(big) truck", "ute" versus "(pickup) truck") - and that can be much more disturbing for the reader! We aren't trying to fix "rubber" (meaning "condom" to Americans and "pencil eraser" to a Brit) or "Durex" (being a brand of condom to a Brit or a brand of adhesive tape to an Assie). Compared to the potential for confusion there, the date issue is very, very minor indeed!
	] 14:43, 12 January 2007 (UTC)
	:As for the date delinking preference guideline, ditching it would be a bad idea because a) this prompted some massive edit wars over personal preferences in its time, which I don't really want to see a repeat of, and b) there is a current bug request to remove the reliance on links for this function to work. ] 23:06, 12 January 2007 (UTC)
	::I think it will be good if we can get a method of applying date preference that doesn't depend on linking dates, which is why I supported the proposal above. In the meantime I think our policy should explicitly refer to the utility of links to readers, and give a little less leeway for personal preference as that is where I see a lot of the trouble arising from. Alongside that I think we need to underline the general advice against making minor edits in a mechanistic (ie automated or indistinguishable therefrom) manner. If we can find a way of putting something to that effect of these two points into the MoS, I think we will help a lot of people, both editors (who'll have a clearer idea of when and how year links should be linked and delinked), and readers (many of whom express a preference for less overlinking on grounds of readability). --] 23:17, 12 January 2007 (UTC)
	I think if we can reduce conflation of linking and formatting, per the proposal above, it would be good, because then we could discuss when dates actually ought to be linked. Based on the analysis, and on my own gut feeling, my view is most of the time they ought not to be linked. I think a case needs to be explicitly makeable to link them, and that by default they ought not to be. I'd support a change to the MoS that moved in that direction. How did I arrive at that conclusion? At least in part thanks to Guinnog's thorough analysis, above. ++]: ]/] 05:33, 13 January 2007 (UTC)
	I created a stub article today and for some odd reason, I linked the Month/Date and then the year...which is something I rarely have done in the past. I look at the stub now and see little improvement by linking to the dates actions mentioned in the article may have occurred. The cite templates also do this, linking to year/month/date and I can't see what the purpose of this is either. Articles that are discussed in the year articles or date articles might be benefited by themselves linking to those dates, but I can't see how any improvement is gained by having this be part of MoS.--] 05:42, 13 January 2007 (UTC)
	: You've misunderstood the purpose of the guideline. It's not because the links are useful, it's to make readers' date preferences work. Hopefully these two functions will be separated in the near future. ] (]) 10:04, 13 January 2007 (UTC)
	::As Jack Harkness said "Everything changes in the twenty first century." ''] ]'', 18:03 ] ] (GMT).
	Guinnog, I see you keep refining the proposal, but I still haven't seen any sign that it's going to gain any consensus. ] (]) 11:05, 15 January 2007 (UTC)
	:Really? That's funny, I see mostly supportive comments here, apart from your own. Once the proposal is refined sufficiently (and I think it is almost there), I'll see about a straw poll. Meanwhile, do you have any constructive suggestions to make? --] 11:41, 15 January 2007 (UTC)
	::These "mostly supportive" comments consist of two for and two against. We discussed this to absolute death last year, featuring somewhere in the vicinity of twenty or thirty editors in total, and the current wording emerged as a compromise acceptable to nearly everybody. Unfortunately, you seem to have appointed yourself as some sort of self-appointed arbiter of this dispute, and seem hell-bent on reigniting it. Thankfully, that's not how this place works, and you'll have to actually get consensus for your changes just like everyone else. ] 11:53, 15 January 2007 (UTC)
	:::As to "constructive" suggestions, the current version reflects that there really is no consensus on all of these issues, and reflects the ability for people to use their own discretion. Your version destroys this compromise, replacing this with "feel free to kill them all, but maybe keep about thinking the occasional one". This is your own personal opinion, and in no way can be seen to reflect any sort of consensus. Really, I've had enough of people trying to assert their own style preferences on everyone else, other people be damned, and having to fight the same battle every six months when some new intolerant jerk decides that his way *must* be imposed on everyone else. ] 11:57, 15 January 2007 (UTC)
	::::And let me get this right, Rebecca: you're ''not'' asserting your own preferences as to how to deal with this unfortunate scenario ... ] 12:27, 15 January 2007 (UTC)
	:::::No, I'm not. I'm saying "use your discretion, within reason". This allows room for a variety of interpretations, from mine through to a bunch of people who are not fond of date links (Quadell being one example, but there are quite a few others I've seen around and have no objection to), as long as they don't systematically strip them everywhere. Guinnog is saying "delink in virtually all cases", which allows room for only his particular preference. ] 12:57, 15 January 2007 (UTC)
	:::::Let's try and keep it civil please. I think I have the right to make the proposal I have made; it would be great if we could restrict comments here to constructive suggestions with a view to improving the vagueness of the policy. Clearly we all have different preferences and it is very much "how this place works" for us to discuss clarifying the guideline. --] 12:43, 15 January 2007 (UTC)
	::::::I'm sorry, but this is the arrogance I object to. You've made the basic assumption that what you've put down must be superior to what is there and that this is the basis we should work from. The current version exists because it was something that basically everyone could agree on (it is for precisely for this reason that it *is* vague, and for everyone except you and Hmains, this has not proved to be a problem); yours is purely a matter of trying to slam your opinion through regardless. ] 12:57, 15 January 2007 (UTC)
	::Sorry Guinnog, doesn't seem very likely that this proposal is going to gather a broader consensus than the previous one. --] 12:36, 15 January 2007 (UTC)
	:::Well, that's if you give Rebecca's clawing and scratching any weight. She's only one voice, let's remember, not 10. ] 13:29, 15 January 2007 (UTC)
	::::As are you. Three and three still does not make a consensus in your favour. ] 13:33, 15 January 2007 (UTC)
	Guys. This is a perennial problem, in my view, and it may need more worrying at to resolve neatly. Last year's compromise may have helped, but that doesn't mean that trying to get a proposal that is crisper and that does have consensus isn't worth pursueing. I do not in any way see Guinnog as being arrogant! Rather I see him trying to take on an rather difficult and contentious topic at considerable personal cost, for the betterment of the wiki, and if the consensus is not in favour of moving in a particular direction, so be it. Terms like "slam your opinion through regardless", and "Rebecca's clawing and scratching any weight" might not be quite as helpful as they could be, don't you think? Let's work together collegially if we can. ++]: ]/] 13:53, 15 January 2007 (UTC)
	:The central problem here is that this isn't "crisper"; it takes a compromise that was neutral and replaces it with one that is very decidedly biased towards one side, which the author happens to belong to. As I just stated on Guinnog's talk page, there are a bunch of opinions here which simply can't be reconciled into a "this is exactly what you must do" sort of guideline. We can either respect that difference, as the present version does, or try to ride straight over it and replace it with the personal preferences of a small group, as Guinnog's does. ] 14:04, 15 January 2007 (UTC)
	My view is that the elimination of YEAR in X|YEAR links would be a mistake. If you liken Misplaced Pages to a print encyclopedia, the YEAR articles are like the yearbooks--here's everything that happened in 1982. Referring someone to the entire book is not particularly helpful--much more helpful would be pointing them to a particular chapter of the yearbook where they are most likely to find the context they are looking for. If the user wants a broader context, it will always be easy to find 1982 from 1982 in table tennis, but the reverse is often not true.
	The suggestion sometimes made that YEAR in X links should be replaced with parenthetical (See YEAR in X) statements strikes me as contrary to the spirit of Misplaced Pages, where links are supposed to be unobstrusive and expendable. ] 19:05, 15 January 2007 (UTC)
	:Hmm, well that's already the guidance at ] I think. Unless you hover over a piped link like that, you have no way of knowing that it points to a more useful link than the catchall year article. Also, using the format <nowiki>] ]</nowiki> breaks the date formatting we currently have. I'm not against linking these often very informative articles but at the moment we have the worst of both worlds when folk are using them as easter egg links. I thought that was the least controversial bit of what I was proposing! --] 20:55, 15 January 2007 (UTC)
	] said:
	''Easter-egg links of the type <nowiki>]</nowiki> are deprecated.<nowiki><!--</nowiki> The last sentence is also at ], so if it's changed here it should be changed there too <nowiki>--></nowiki> ''
	I don't see that at ]; instead, I find:
	:There is disagreement about whether it is appropriate to pipe year numbers to "year-in-x" articles (such as <nowiki>]</nowiki>).
	Am I looking in the wrong place? ] 07:26, 18 January 2007 (UTC)
	::I don't think so, although the phraseing has changed. Project Albums uses the format "1999 (see ])", and as Guinnog remarked we should avoid "12 May ]" if we want to respect peoples ISO preferences. I am of the opionion that generally the second level generic year articles are unhelpful, where soemthing with a wider temporal spread and a closer subject spread might give context, say, "interwars British comedy" or "1980s Australian Tennis". To some extent this is also the purpose of "Navboxes". ''] ]'', 13:23 ] ] (GMT).
	== Converting to SI prefixes ==
	I'm presently dealing with a new user whose sole contribution to the encyclopedia has been to push SI prefixes into a variety of Macintosh hardware articles. And by "dealing with", I mean, reverting all their changes.
	There's a serious problem here with the stated MOS guideline: It contravenes both ] and ]. In essence, SI prefixes are meant to solve an ambiguity issue between "powers of 2" and "multiples of 10". This decision was made by a task force a few years ago, and was adopted by various organisations and communities as a result. The problem is that most major manufacturers of hardware and software, as well as most publications and news sources, have ''not'' adopted this naming for whatever reason. I don't necessarily agree with it, but that's their collective perogative.
	So what's an encycopedia to do? The answer seems clear enough: our core policies revolve around a neutral presentation of our sources, which means it behooves us to use MB, GB, etc. ''when our sources use those prefixes''. Wikipedians should absolutely not take it upon themselves to state numbers differently from how our verifiable, reliables sources do. Arguments along the lines of "But Apple does it wrong!" don't wash either, since that's a matter of personal opinion. Using SI prefixes to describe consumer hardware is nothing more than a ''minority viewpoint'' at this point. Personally, I'd like to see these prefixes be adopted more widely so as to solve this ambiguity, but Misplaced Pages isn't the place to champion that agenda. We report on what others say, and that's it... policies always override MOS guidelines. <span style="color:blue;font-weight:bold;font-size:larger;font-family: Monotype Corsiva;"> ] ]</span> 22:31, 21 January 2007 (UTC)
	:I'm afraid I disagree-we need not always report sources ''verbatim''. Apple may call their new laptop "the best thing to happen to graphics designers since Photoshop", but that doesn't mean we've got to put that verbatim in any article which mentions it! Similarly, KiB/MiB/GiB are the ''correct'' ways to represent binary values. The prefix "kilo" means "one thousand". That is not a matter of opinion, any more than it's a "matter of opinion" to say that three is a quantity one greater than two and one less than four. That is not my opinion, that's ''what the word means''. Similarly, if a source is using imprecise and inaccurate terminology, especially when their terminology is intended to appeal to a mass audience, we need not repeat it exactly-in our context, so long as the meaning is clear, we can certainly use better, more precise terminology. In this case, it is indisputably clear that the numbers referred to are binary values. In this case, the use of XiB prefixes are correct, and the use of XB prefixes are incorrect-we're not referring to the numbers that "kilo", "mega", and the like refer to! That is not an opinion, it is verifiably and provably true. ] 00:54, 22 January 2007 (UTC)
	:: You're advocating silently correcting our sources for them when they're wrong, then? Ehhhh, something seems really wrong with that. I'd rather let articles on ] etc. explain the issue (per ] and Jimbo's own assessment that minority viewpoints should be in ancilliary articles -- YES, the "correct" measurement is a matter of opinion)... '''or''' specifically disclaim the conversion on pages where we use it. We don't generally use metric measurements on articles on American subjects, do we? Nobody would advocate switching from miles to kilometers in those Misplaced Pages just because ] said so, would they? The answer is no -- we tend to choose what to present based on common usage in the article's domain space, not based on what governments and standards organisations (or advocates thereof) say we should use. <span style="color:blue;font-weight:bold;font-size:larger;font-family: Monotype Corsiva;"> ] ]</span> 01:21, 22 January 2007 (UTC)
	:::However, here, we're dealing with a layman's term which is commonly used, but is also ''factually and provably'' incorrect. Whether to say "one inch" or "2.54 centimeters" is indeed a matter of opinion-either one is correct. However, if one of our sources was incorrectly using a conversion factor of 1 inch = 3.54 centimeters, ''they are wrong''. It's not my opinion, in that case, that they're wrong. They're wrong. I would agree when ''directly'' quoting, we certainly should not change a direct quote (though we probably should tag it with (''sic'') where the incorrect terminology appears). But when paraphrasing, yes, we should put an obviously-incorrect layman's term into the correct technical term. ''The prefix kilo means 1000''. That is a fact. "Kilobyte" means 1000 bytes, just like "kilometer" means 1000 meters and "kilogram" means 1000 gram. That's just what the prefix means. If a source uses "kilometer" to refer to a distance which is actually 1024 meters, ''they're wrong''. If a source uses "kilobyte" to refer to 1024 bytes, ''they're wrong''. That's not a matter of opinion. They may have figured it for "close enough", in what they were doing, but we should be as precise as possible. Especially up into the MiB/GiB ranges, there is a ''significant'' variance between the base 10 and binary prefixes, and what kind of number they indicate. This is not a matter of opinion, however. Either there's 1000 bytes, or there's 1024. In the cases we're talking about here, there ''are'' 1024. KiB properly represents that. KB does not. That's not my opinion, or anyone's. Words have meanings, and so do prefixes. K means 1000. Ki means 1024.
	:::I suppose our other option would be to simply eschew prefixes and report all values ''in bytes'', but that would get cumbersome, to say the least. However, just because most computer manufacturers would rather settle for "close enough" and allow error doesn't mean ''we'' need to, or should. That is not a "rewording" of what the source said, any more than any paraphrase is. But this is no "minority viewpoint"-find me ''any'' computer scientist who will disagree on the actual binary values. For that matter, not even Apple or Dell would disagree-they're just using incorrect but widely-recognized terms for marketing purposes. The "minority viewpoint" criteria do not apply when the viewpoint in question is effectively universal! ] 01:35, 22 January 2007 (UTC)
	::::No, kibibit, etc. are ill-conceived needless committee-driven nonsense. The English language is quite able to to accommodate words with slightly different meanings dependent on context. —]→]&nbsp;&bull; 01:45, 22 January 2007 (UTC)
	:::::Not quite necessarily-the reason I advocate use of precision numbers was, first, when I started getting angry calls from people whose systems I'd upgraded. I promised them a 200 GB drive, you see, but it says it's only 185! It generally took a good deal of explaining to get them to comprehend they hadn't gotten shortchanged, and even then some of them seemed rather unconvinced. (Anymore, I explain this ''beforehand'', and people don't seem to have much trouble understanding the basics-the "gigabyte" term is ambiguous, and the file system requires some space to set up its tables and such.) At least I never got sued over the discrepancy, though-but it sure looks like ]! There is not a thing wrong with being precise or taking proactive steps to prevent confusion, and relying on "context" to handle such things inevitably leads to misinformation and misunderstanding sooner or later. Perhaps, in most cases, context would handle it fine. But when a better, more correct, more precise alternative is available, why not use it? ] 02:10, 22 January 2007 (UTC)
	:Actually, it is '''incorrect''' to say that one kilobyte can only mean 1000 bytes, at least in American English. See, for example, and . Even dictionaries which include the smaller variant list that as a second, less common definition; see, for example, . --] 04:55, 22 January 2007 (UTC)
	::Interesting. Given that, staying with xB might make sense, provided we take care to link to something that clearly explains the discrepancy. (Still, I fail to see what harm it would do to use more precise terminology when it's known which one applies.) ] 06:59, 22 January 2007 (UTC)
	:I totally agree with Seraphimblade. This is not a matter of opinion. Even if dictionaries say that kilobyte could mean 1024 bytes, it is ambiguous and an encyclopedia should be precise and consistent. There are prefixes specially designed for this purpose. They are internationally adopted as standards and they are unambiguous : what is written is what is meant, why not use it ? ] 11:38, 22 January 2007 (UTC)
	We can decide to use whatever convention we like, but we should be consistent. If it's clear that a source is using MB to mean 2^20 bytes, there is no problem with us reporting it as MiB, if that's the convention we decide on. The only problem is when it's not clear what the source means, in which case I guess the best we can do is use whatever they use. --] 11:50, 22 January 2007 (UTC)
	:I would agree, if there could be ''any'' doubt as to which one the source actually means, we should stay with what they use. In most cases, though, it's pretty clear whether it's a reference to base-10 or base-2. ] 11:53, 22 January 2007 (UTC)
	: I agree, but the question is: Do we stay consistent with our ''sources'' and with ''common usage'' in the article domain? Or do we stay cosnistent across the encyclopedia? When this question has been asked of other measurement and naming standards, we have almost always decided on "sources and common usage". We use British spelling and linguistics in British articles; we use kilometers in Canadian articles; we use the time zone relevant to an event's location; we have also had a strong tendency towards binary prefixes in popular computing articles, because that's what's used in general conversation, print and online media, and by the manufacturers themselves. That's a pretty large group of real people to turn our backs on and say, "no, you're wrong, these technical committees know better". The article on ] does explain the ambiguity early on.
	: Hmm... a footnote or some other kind of explanatory widget in articles where this is an issue may be a good answer here. We do this to resolve ambiguity in other areas (pronunciation, for example.) Heck, I'm willing to do that work myself in the 1,500+ computing articles I have on my watchlist where these measurements would be relevant. <span style="color:blue;font-weight:bold;font-size:larger;font-family: Monotype Corsiva;"> ] ]</span> 13:53, 22 January 2007 (UTC)
	::A footnote or something like that might work. Maybe some kind of template could be devised? I'm not going for any single solution, I just think we should make the issue clear to our readers-a lot of people have no idea there even is any kind of discrepancy. ] 14:00, 22 January 2007 (UTC)
	::I think we should go by what would be the world wide norm, even apple uses MB and GB not MiB or GiB,No where in my computer does it reference MiB or GiB I have visted every major computer site and they all use the MB and GB term.Not one of them uses the GiB or MiB term that I saw.<small><span style="border: 1px solid">]]</span></small> 17:52, 22 January 2007 (UTC)
	How ever I do see that if you have a 512 memory it would correctly be 512 MiB but if you have a 1 GB it would not be a GiB.<small><span style="border: 1px solid">]]</span></small> 17:56, 22 January 2007 (UTC)
	: You are still confusing prefixes... If you have a "1 GB" memory, you have 2 times a "512 MB" memory. A "512 MB" memory is actually a 512 MiB memory, so you have 2*512 MiB = 1024 MiB = 1 GiB. ] 18:07, 22 January 2007 (UTC)
	*one mebibyte (MiB) is 1048576 bytes
	one Megabyte (MB) is 1000000 bytes
	Source http://www.physics.nist.gov I don't think they are wrong. <small><span style="border: 1px solid">]]</span></small> 18:30, 22 January 2007 (UTC)
	:Hard drive seller "gigabytes" are neither binary gigabytes nor decimal gigabytes. They are usually either 1,000,000 binary kilobytes (i.e. 1,024,000,000 bytes) or 1,000 binary megabytes (i.e. 1,048,576,000 bytes). It's weird how they confuse and conflate the two meanings into a single prefix. --] 18:32, 22 January 2007 (UTC)
	:: No, Hard Drive sellers are using "decimal" gigabytes (1,000,000,000 bytes) and "decimal" megabytes . They are using the prefixes like they should be used. ] 18:47, 22 January 2007 (UTC)
	: Why do you quote this source ? I'm telling you that a 1 GB RAM has an actual capacity of 1 GiB, nothing more.] 18:47, 22 January 2007 (UTC)
	All i'm saying is that MiB and GiG are not part of the measuring system in place now.and untill this changes, what's in place now should be reflected in the Misplaced Pages articles.
	"It is important to recognize that the new prefixes for binary multiples are not part of the International System of Units (SI), the modern metric system."
	"Faced with this reality, the Institute of Electrical and Electronics Engineers ( IEEE ) Standards Board decided that IEEE standards will use the conventional, internationally adopted, definitions of the SI prefixes. Mega will mean 1 000 000, except that the base-two definition may be used (if such usage is explicitly pointed out on a case-by-case basis) until such time that prefixes for binary multiples are adopted by an appropriate standards body. " <small><span style="border: 1px solid">]]</span></small> 19:19, 22 January 2007 (UTC)
	: If you want to use SI prefixes with their real values (why not...), you have to change the numbers. When Apple, MS, Intel or AMD says 512 MB, it means 512 MiB so if you want to keep the real MB unit (=1 000 000 bytes) you have to change 512 MB to 536.870912 MB. Isn't it easier to say 512 MiB than 536.870912 MB ? ] 19:45, 22 January 2007 (UTC)
	No, I think it's easier to stick with the accepted (world wide)values instead of the confusing "new" prefixes that are not yet recognized by the world community. <small><span style="border: 1px solid">]]</span></small> 20:02, 22 January 2007 (UTC)
	: So why do you quote the IEEE that says the opposite ? What is the accepted value of 1 MB according to you ? ] 20:13, 22 January 2007 (UTC)
	as quoted above Mega will mean 1 000 000.You might want to read the IEEE currant standards. <small><span style="border: 1px solid">]]</span></small> 21:01, 22 January 2007 (UTC)
	The "generally accepted values" are very dependant on context, and even then they aren't always universal. For example, should the size of my hard drive be reported as "200GB" as the manufacturer reports it, or "189GB" as Windows reports it? (Interestingly, 189GiB=203GB, I guess the 200GB it was sold as was approximate...) --] 21:03, 22 January 2007 (UTC)
	: IMO (and that's also what the current MoS recommends), the size of your hard drive should be reported as "200 GB" because 1) It uses the standard SI prefix G=10<sup>9</sup> 2) It is consistent with the use of binary prefixes for binary capacities 3) Manufacturers chose this unit so there is no conversion to do.
	: Planetary Chaos, if 1 000 000 bytes is the value of 1 MB and you don't want to use binary prefixes, you are aware that it implies that we change all the capacity values when dealing with memory capacities (512 MB becomes 536.870912 MB, 1 GB becomes 1,073741824 GB...)? Is it really what you want to do ? ] 21:27, 22 January 2007 (UTC)
	::I don't understand your point (2), using 200GB isn't using binary prefixes at all... And point (3) doesn't say why the manufacturer's choice should trump Microsoft's choice. Anyway, it was a rhetorical question - I was just pointing out that is isn't as simple as saying "Use the generally accepted values". --] 23:26, 22 January 2007 (UTC)
	::: Using "200 GB" isn't using binary prefixes but is coherent with the use of binary prefixes. You can use "200 GB" for hard drive and GiB for RAM in the same article. If you use "189 GB" for the HD and "1 GiB" for the RAM, it is not consistent since in that case GiB and GB mean the same thing. ] 23:49, 22 January 2007 (UTC)
	Tango,Is your hard drive shared? Meaning your hard drive is typically C do you have a restore D or E partitioned? <small><span style="border: 1px solid">]]</span></small> 21:44, 22 January 2007 (UTC)
	:The hard drive in question is an external drive (well, a normal drive in an external caddy, to be precise), and is unpartitioned (or has a single partition, to be precise). --] 23:26, 22 January 2007 (UTC)
	Sarenne,it is not what I want,but it is however the international standard. <small><span style="border: 1px solid">]]</span></small> 22:01, 22 January 2007 (UTC)
	: Binary prefixes (Ki, Mi, Gi...) are international standards too. ] 22:17, 22 January 2007 (UTC)
	Show your source. <small><span style="border: 1px solid">]]</span></small> 22:24, 22 January 2007 (UTC)
	:], ], ], , , . ] 22:38, 22 January 2007 (UTC)
	Let me say this M as in Mega has allways been a million long before the introduction of the PC.I to have a 200 GB HD 195 GB on C and 5 GB on RECOVERY D .Now correct me if my math is not correct but 195 + 5 = 200? <small><span style="border: 1px solid">]]</span></small> 00:04, 23 January 2007 (UTC)
	:Goody, this biscuit again... Since I haven't seen any arguments that haven't been used before, I'll just say that I don't see any compelling reason to change the current style guidelines on this matter. Conforming strictly to the SI definitions of the prefixes in question and using the binary prefixes proposed by IEC (and endorsed by BIPM, IEEE, et al) where appropriate prevents the ugly ambiguity. It only only seems to annoy people who already understand the issue at hand and dislike the prefixes for superficial reasons or are totally, utterly confused themselves. For further arguments made by myself and others at various times in the past, see this talk page archive. (specifically, , , , and (note the list at the end)) P.S. - Planetary Chaos' comments seem nearly comical considering the argument he (seems) to be attempting to make... Come on, folks, at the very least read the related Misplaced Pages articles on this matter before trying to express your opinion. P.S.2 - Shame on the folks that patronized Sarenne by labeling his obviously good-faith edits as vandalism and engaging in revert warring. -- ] <code>@ 2007-01-23T00:17Z</code>
	:Yes, and K as in Kilo has been used to mean 1024, not 1000, in computer contexts, long before the introduction of the PC, too. See, for example, , which says on page 1 (PDF page 5) that "Core storage capacity is designated by a letter following the 1131 model number; A = 4k, B = 8k, C = 16k, and D = 32k.", and on page 2 (PDF page 6), speaks of machines with 4096, 8192, 16384, or 32768 words of memory, and, for machine that actually ''have'' megabytes of memory, see , which, on page 6-15 (PDF page 78), speaks of machines with "real-storage capacities of 1,024K (1,048,576 bytes) to 8,092K (8,388,608 bytes)". ] 07:21, 23 January 2007 (UTC)
	::Interestingly, for 2^10 bytes, the abbreviation "KB" is most common, which is arguably not using an SI prefix at all (SI defines a lower-case 'k' to mean 10^3). -- ] <code>@ 2007-01-23T14:11Z</code>
	Who here has bought a computer that uses the terms GiG or MiB? Any one? Any one at all? I just bought this computer two weeks ago..a 2007 PC and nowhere does it say GiG or MiB. On another note MiB might be confused with (Men In Black).<small><span style="border: 1px solid">]]</span></small> 00:33, 23 January 2007 (UTC)
	:Have you bothered to read half the links that have been provided, or are you more concerned with defending your original viewpoint than trying to understand why many people here are disagreeing? Let me say this explicitly: you yourself have confused terms and arithmetic several times here, so it's more than slightly ironic for you to counsel others to do their homework. -- ] <code>@ 2007-01-23T00:46Z</code>
	::(in reply to Planetary Chaos) I'm not really considering writing any article on any of my computers, but even if I were telling you the capacities of the system, I would be sure to use the correct prefixes. For example, this laptop has 512 MiB of memory and an 80 GB HD. If I told you it had 512 MB of memory, I would be wrong. Not far wrong, granted, but wrong. "Mega" is a prefix that ''far'' predates computing, and it means one million of whatever follows it. Granted, the XiB terms are newer-that's to be expected, we only now have need of them, as only now are numbers such as 2^10, 2^20, and so on, important on a wide scale. However, they are clearly defined, verifiable, international standards, approved by multiple standards bodies, which have a clear, verifiable, and unambiguous meaning. Further, we can make trivial and obviously-correct changes to source wording, as commonly accepted when paraphrasing. For example, some companies may refer to their laptops as "laptop" computers, others to "portable" computers. If we decided that, for stylistic reasons, we should use only the term "laptop", that would be a perfectly acceptable paraphrase. Similarly, let's say an American source refers to an "organization" in an article which already uses British spelling. In that case, it would be perfectly acceptable to change that to "organisation"-we have not changed the ''meaning'' of what was said in our paraphrase. In the same vein here, when Dell refers to MB in terms of things that are always measured in MiB, we can safely presume that they mean MiB, and paraphrase for stylistic reasons and to avoid confusion. Dell may wish to speak in "layman's terms" when writing promotional material, and for that purpose, saying "1 GB of RAM" is certainly "close enough". However, in terms of writing an encyclopedia, we should work to be more precise, and to use exact numbers and terminology. ] 02:54, 23 January 2007 (UTC)
	:::Words take on different meanings in different contexts. In computing, the long-established meaning of the prefix "kilo" is 1024. Recently, there has been an attempt to re-define the prefix to accord with the non-computing meaning of 1000, and to invent a new prefix, "kibi", to replace what was conventionally denoted "kilo". This attempt is so far only partially successful, so it makes no sense to speak of "correct" or "incorrect", any more than it makes sense to speak of either or both "organisation" and "organization" as "incorrect spelling". The argument is between using something unconventional within computing, or something unconventional outside of computing, when writing about computers, and both approaches have their pros and cons. --] 10:33, 23 January 2007 (UTC)
	::::Quite so. The labels "correct" and "incorrect" are overblown here. My point (and others') every time this comes up is that strictly adhering to SI definitions and using IEC binary prefixes clears up any possible ambiguity assuming the writer is competent. I feel that the advantages of removing this ugly ambiguity outweigh any minor confusion that can be alieviated by reading the article that should be linked with the first usage of binary byte prefixes. I think it's far more advantageous for a reader to notice an unfamiliar abbreviation like ], click it, and learn about this notation issue than to see (excuse my own opinion here) misused SI prefixes and go on blissfully unaware that there is a difference between 10^6 and 2^20. If it came to a vote again, my position is clear (though I don't think it should have to since this has been discussed many times now). -- ] <code>@ 2007-01-23T13:27Z</code>
	*One MegaMinute! I think we're writing a professional encyclopedia here and we don't need to use incorrect definitions if we know how to use the correct versions. I don't expect you would open a copy of Encyclopedia Britanica and find that different articles on the same subject would be using different definitions for the same units. Switching Imperial and Metric units is a poor decision as well. I think the entire encyclopedia should be written in International standard units. I am pushing for a wikimedia software feature to allow a user to set a units preference in this . ] 13:47, 23 January 2007 (UTC)
	::Again, the label "correct" is overblown. While I tend to agree with you that we should only use SI prefixes with their strict SI definitions as set by the BIPM, there's the equally valid point that these SI prefixes have become nearly ubiquitous in common usage with computers (even professionals and engineers who know the issue often use them). It doesn't get us anywhere to insist upon which is the more correct usage, but we should consider which is the most accurate and uniform, and ambiguity plays a role in that. -- ] <code>@ 2007-01-23T14:09Z</code>
	:::Seraphimblade, Take alook at my second reply on this discussion.It kind of says what you said.
	:::Mat, what is uniform? If you are speaking of MiB being more uniform then MB. I think you are wrong,How ever, MiB for something like 512 would be more accurate then MB.But on the other hand...MB would be more accurate for 500 then that of MiB.<small><span style="border: 1px solid">]]</span></small> 17:12, 24 January 2007 (UTC)
	::::I'm really not sure what your question is... Can you express yourself with more lucidity? I fail to see much significant about the numbers you gave. The issue at stake is that using the prefix 'M', for example, in both the SI (10^6) and binary (2^30) contexts throughout Misplaced Pages is inconsistant. That's all I meant by "uniformity". I don't believe that it's good style to assume that the reader will perceive the correct context every time, or indeed even realize that there IS a context issue. Just as Misplaced Pages uses SI units in scientific articles for uniformity and accuracy, usage of the IEC binary prefixes where appropriate brings the same type of standard to computer and digital communications articles. (speaking of digital communications, just think about all the confusion there is between a kilobit, a kilobyte, a kibibyte, and a kibibit... Broadband companies make their living off this) -- ] <code>@ 2007-01-24T18:23Z</code>
	::::MiB for multiples of 1024*1024 (1048576) would be more accurate that MB. MB for multiples of 1000*1000 (1000000) would be more accurate than MiB. 500*1024*1024 (524288000) is 500 MiB, not 500 MB, just as 512*1000*1000 (512000000) is 512 MB. It's the ''units'', not the ''multiple'', that matters. Perhaps 500 is more commonly a multiple of 1000000 than of 1048576, and 512 is more commonly a multiple of 1048576 than of 1000000, but it's still the units that matter. ] 07:40, 25 January 2007 (UTC)
	:::::In the real world of talking about personal computer tech specs, nobody, nil, no one, '''not one single person''' refers to xiB units. Misplaced Pages articles, as they are written for non-experts, shouldn't be any different. I haven't been able to find even ''one'' other encyclopedia, magazine, or manufacturer website that refers to "gibibytes" of hard disk space or "mebibytes" of RAM. As xB units are the accepted norm, at least for now, changing to xiB units would only result in reader confusion. ] 04:27, 26 January 2007 (UTC)
	:::::: You should take a look at a PC under Linux.] 13:29, 26 January 2007 (UTC)
	::::::If we used PC manufacturer marketing drivel as a benchmark, I can't even imagine how poor our standards of quality would be. -- ] <code>@ 2007-01-26T04:45Z</code>
	Should we have a vote on this? I think that everything was said. Current manual of style specifies very well where binary prefixes are to be used and still some editors are opposing it saying there isn't consensus. The only valid point why not to use them is IMO that it's ] but there is no disscusion about accuracy. So we should decide whether we are about to use correct values or ones that are used in marketing materials of the computer industry (and may be utilize more info from computer marketing then since it's WP:OR not to call Apple' computers the best ones when Apple does so;). I don't think new consensus can be achieved by discussion, it has been discussed in the past (and not once) and nothing new has been said here. So we should probably vote to get over with this.--] 11:29, 26 January 2007 (UTC)
	:PC manufacturer's specifications are not "marketing drivel." They are legal documents carefully reviewed for accuracy. They don't make "we're the best" claims. If you have more authoritative published sources for information about particular PC models covered in Misplaced Pages articles, please cite them. MOS is a guideline, ] is official policy. It's not subject to a vote.--] 12:41, 26 January 2007 (UTC)
	:: Legal documents ? Reviewed for accuracy by who ? ] 13:29, 26 January 2007 (UTC)
	::You're joking, right? When they publish that the computer has 2 MB of cache and 512 MB of RAM they are accurate? I thought we've been through this. It is not accurate and wikipedia is not accurate either when using MB instead of binary prefixes despite it's in WP:MS already.--] 13:39, 26 January 2007 (UTC)
	::Err... I can't even count how many misleading statements, exaggerations, and outright lies I've seen in marketing documents, especially those relating to consumer products. Computers are not immune to this by any means. If you want an example of some of the most nauseatingly self-serving marketing in existence, browse Apple's site for a few minutes. Most of it isn't exactly untrue, but anyone can see the spin that they put on things. That's the job of marketing, to spin things in the way that is most likely to make a sale to their target audience. Consumer product marketing is NOT, by and large, concerned with publishing the most accurate specifications. -- ] <code>@ 2007-01-26T13:52Z</code>
	:::We can take it to a vote if you guys want, but that won't stop people from bringing this up. It's been voted on at least once before (twice, I think), and I still see the same debate with the same arguments every few months. -- ] <code>@ 2007-01-26T13:43Z</code>
	::::OK, so there is consensus and guideline; still it can't be enforced in articles because there is edit war every time somebody tries to push it. So it's going to stay the same despite the guidelines. It seems pretty strange to me.--] 02:16, 27 January 2007 (UTC)
	:::To briefly interject... Matt, you're talking about marketing materials, while others (such as Arnold and Pethr) are talking about technical specifications. These are two distinct sets of documents. Marketing materials are generally prepared by the marketing department and are used for advertising. Technical specifications are factual documents which are not typically used in any sort of marketing capacity. --] 21:38, 26 January 2007 (UTC)
	In most consumer product manufacturing companies, published technical specifications go through an extensive engineering sign off and then are submitted for review by the legal department. They are contractual documents. Misrepresentations violate consumer protection laws and can result in civil suit. Apple, in particular, is a litigation magnet, so you can count on their review process being particularly thorough. If you can find one, just one, error in an Apple product specification, there are any number of class action law firms that would be glad to hear from you. Here is an example: http://www.apple.com/macbook/specs.html And the fact that you see the same debate with the same arguments every few months may be a clue that there is no consensus here.--] 15:21, 26 January 2007 (UTC)
	: In these specs, Apple is incoherent. They use GB=1,000,000 B for hard drives and GB = 1024*1024*1024 bytes for RAM. Thus, there are at least 2 errors. ] 15:37, 26 January 2007 (UTC)
	::This usage is standard practice in the industry and Apple clearly states that for hard drive capacity "1GB = 1 billion bytes; actual formatted capacity less." This is precisely the point. You want to substitute your view of how the specs should be written for what is the widely accepted standard in published sources. That is OR and POV. --] 16:32, 26 January 2007 (UTC)
	::: It is not "clear" at all. This usage is incoherent, Misplaced Pages should be coherent and accurate. We don't want to force Apple to be coherent, that's their choice. ] 16:39, 26 January 2007 (UTC)
	::It is not just marketing.It was what was used BEFORE personal computers.One thing is clear, the articles written in Misplaced Pages are about the computer of topic. ie.Mac/Pc. The citations and reference links contained herein about the product at hand '''DO NOT''' reference the new SI prefix. Therefore, the article should reflect those citations and references. <small><span style="border: 1px solid">]]</span></small> 18:27, 26 January 2007 (UTC)
	:::I still challenge anyone to state how this is OR. ] certainly must allow ''some'' degree of latitude-if every article we had here was as sure as some people seem to want to use the "source's exact wording", every article we have would be a glaring copyvio! ''Trivial paraphrasing is allowed'', provided it does not change the ''meaning'' of what was said. Finally, as it seems there is not any consensus to change the MOS at this time, I would hope that no one continues to use reverting good-faith changes supported by MOS in an attempt to make a ]. ] 02:47, 27 January 2007 (UTC)
	::::It's OR because technical judgement or interpretation is required for each conversion. This is not a case of "trivial paraphrasing," or even ordinary unit conversion, where the conversion factor is always clear cut. One must determine ''in each case'' whether KB, MB or GB were meant as binary or decimal in the source. If published sources do not provide that information, we should not interpolate it. Verifiability is an absolute requirement on Misplaced Pages, not subject to consensus.--] 00:05, 28 January 2007 (UTC)
	:::::That does, of course, leave it up to the readers to make the technical judgement. It also means that the article is "verifiable" in the sense that the article uses the same two letters as the primary source, not in the sense that the article and the primary source both unambiguously specify a particular amount of memory and the two amounts of memory are the same. ] 01:05, 28 January 2007 (UTC)
	Ok so let's change the wording.That means for every article that contains MB,GB and so on should be changed. Computers,games,phones,memory sticks, any and all devices.I don't know about you but i'm sure this would create chaos on Misplaced Pages. <small><span style="border: 1px solid">]]</span></small> 17:26, 27 January 2007 (UTC)
	:It hasn't in the year or so it has been a guideline. -- ] <code>@ 2007-01-27T22:40Z</code>
	Only a few pages were changed to meet those guidlines and then changed back I have already counted more then 40 pages that would need to be changed.<small><span style="border: 1px solid">]]</span></small> 23:07, 27 January 2007 (UTC)
	== Imperial and Metric Auto Conversion like date format ==
	I am noticing a lot of duplication of imperial and metric units. I notice that dates are automatically converted based on user preferences and I am curious if there is a similar capability for distance, area and volume. If one doesn't exist, how do we move to create such an option? ] 12:19, 23 January 2007 (UTC)
	:I think that would be a bad idea. With dates, you're just reordering the parts of the date. Converting units would be a far more substantial change, and in my opinion requires human judgement. For example, to how many significant figures would you convert it? Which units do you choose anyway? &mdash; e.g., m<sup>2</sup> or km<sup>2</sup>; m<sup>3</sup> or litres; inches, feet, yards or miles? And can the engine parse the vast number of different units and different ways of writing them anyway? Quoting the source unit and providing a conversion in parentheses seems like the best solution to me. ] (]) 14:08, 23 January 2007 (UTC)
	:: I believe someone already wrote the patch, as noted either above, or in the bugzilla request for date syntax. ''] ]'', 14:49 ] ] (GMT).
	:::Like Stephen, I'm wary of automatising this function. WPians just need to be skilled at judging the variables, for our readers' sake. ] 15:07, 23 January 2007 (UTC)
	::::I'm not wary. It's just a bad idea, plain and simple. ] 17:30, 23 January 2007 (UTC)
	::::*Ok sure, you can go through all the City pages and do the calculations manually for {{tl|Infobox City}}. Or maybe I should just automate this template, like the hurricane template and then everyone else who finds that it's possible will do the same so we can continue duplicating our work here and wasting time. The key point here is that entering any figure twice is duplication which is prone to inconsistencies and typographical error. Further, articles become cluttered with 3 different units stated for the same figure. That's not to mention the conversion errors people make. Alternatively, we can state everything in MKS causing regional or interest groups readers who seek to view the encyclopedia in a different measurement standard will find themselves doing the calculations. ]
	:::::Date formats are simple in comparison, yet have caused an enormous amount of difficulty over the years to arrive at the current unsatisfactory situation. Automating units of measurement is an immeasurably more difficult task, just to get to the stage where registered users see what they want to see. And what happens to the majority of our users, who are unregistered and have no preferences to set? What units would they see? In this diverse world, we should cater for users from all cultures and backgrounds as best we can, and while it isn't too hard to work out that 5 June 2007 is the same day as June 5, 2007, we should avoid forcing readers to hunt for a calculator if they want to understand just how long, heavy, hot or bothered something is. --] 23:51, 25 January 2007 (UTC)
	:::::::They would see the metric units or whatever units were most common in the world for that type of measurement. ] 01:27, 26 January 2007 (UTC)
	:::::::Well, of course. But a sizable percentage would see unfamiliar units. It would be like us trying to work out dimensions given in cubits and leagues. We don't want to make life difficult for many of our readers as we pursue, with puritan zeal, a shining set of standards. The current system, where we quote Imperial and metric, and put the most relevant unit first, seems to work better than any alternative that has been suggested. --] 02:32, 26 January 2007 (UTC)
	:::::::::Who will determine the most relevant unit? Continuing in this fashion only promotes duplication and disputes over which unit is more relevant. ] 03:57, 27 January 2007 (UTC)
	::::::::::We'll work out disputes through consensus. In most cases, it is obvious which units are most relevant. --] 16:42, 27 January 2007 (UTC)
	:::::::::::It's usually the one in the ]. ] (]) 17:12, 27 January 2007 (UTC)
	== Individual Years ==
	<!-- This discussion has been moved from ] to here.
	-->I've put up the disputed tag because I think each year in this century, and for that matter, all centuries, are inherently notable. This morning someone else disagreed with this, and I wanted to come here to the talk page of this century where I began to remove redirects to the century as a whole for indvidual years yesterday. Hopefully we can gain a consensus in one way or another rather than have an edit war off the talk page. ] 14:19, 23 January 2007 (UTC)
	*I don't think any individual year, beyond the 21st century, can be notable enough to have a page of its own. The most distant year to have a page of its own is 2065 and I think that's far enough for now. What information beyond anniversaries and fictional and astronomical events (all of which are on the century's page anyway) can be put on these suggested pages?] 15:14, 23 January 2007 (UTC)
	::The fact that there are anniversaries and astronomical events should be enough, but besides that there are also Non-] predictions from the present or past(just to clarify, even though the events may be crystal ball, the predictions themselves are not Crystal Ball and may be notable, ala ] or some other notable figure.)
	There's also...
	**Dates mentioned in notable fiction.
	**Showing different calendar years for differing calendar systems
	**Pecularities of a year (such as 2002 being a ] and so on.)
	and probably many others that I can't think of here, but others definately could if we just give them a chance. ] 18:40, 23 January 2007 (UTC)
	*Yes but all of these can be found on the respective century pages and I see no reason to repeat this information. Also, there is very little of this information per year and creating a page for every individual year would lead to many hundreds of little articles with only "such a thing happen in Star Trek in this year" on them. Would it not be better to have all this information on one or two century pages where it can be easily accessed? ] 19:30, 23 January 2007 (UTC)
	*Then let's start pages for George Bush's right foot, Goerge Bush's left foot, Goerge Bush's right thumb,.... ] 23:30, 23 January 2007 (UTC)
	**That analogy is a bit 'over the top'. I'd like to see a statement on ] that states no pages should be created for individual years beyond the 21st century (not for the next 30 or 40 years at least) and any that are created should be instantly redirected to their respective century. ] 06:16, 24 January 2007 (UTC)
	==Binary prefixes==
	I would like to question the guideline that states "If a contributor changes an article's usage from kilo- etc. to kibi- etc. where the units are in fact binary, that change should be accepted." There is currently something of an edit war going on about such a change on the pages dealing with several Macintosh personal computers, e.g. ], ]. There are several good reasons not to use binary prefixes for articles dealing with consumer products:
	*These prefixes have not received general acceptance. Almost no one uses them. Their use on Misplaced Pages only serves to confuse readers.
	*While the binary prefixes have official recognition, their limited acceptance arguably makes them neologisms. We should not take the lead in popularizing new terms. See ].
	*Use of the binary prefixes makes it harder to verify the accuracy of specifications contained in these articles as one cannot directly compare what the article says with the manufacturer's specifications. Typically there is a mix of binary and decimal prefixes in those specs and sorting this out comes close to original research. See the complex guidelines included in this MOS page.
	I suggest that the sentence I quoted above be deleted and that the use of binary prefixes be left to the consensus of the editors working on particular articles or projects.--] 10:45, 25 January 2007 (UTC)
	:See the "Converting to SI prefixes" section of this talk page for further discussion of that issue.
	:Note also that one of the reasons offered by people converting to binary prefixes is that the decimal prefixes are, in fact, inaccurate, so that when the vendor says that a processor has 4 MB of cache or a machine has 2 GB of memory, that vendor statement is inaccurate as the machine actually has 4 MiB of cache or the machine actually has 2 GiB of memory. Some others appear to have thought, at least at some point, that a processor claimed to have 4 MB of cache has, in fact, 4*1000*1000 bytes of cache, or that a machine claimed to have 2 GB of memory has, in fact, 2*1000*1000*1000 bytes of memory; hopefully, nobody ''here'' would argue that, as it's wrong. Given that, verifying, in any meaningful sense, the accuracy of specifications in an article requires that you somehow determine whether the vendor, when using K/M/G/T, meant 1000/1000*1000/1000*1000*1000/1000*1000*1000*1000 or meant 1024/1024*1024/1024*1024*1024/1024*1024*1024*1024, which could well mean that verifying a specification '''''requires''''' original research. ] 11:16, 25 January 2007 (UTC)
	::Memory and processor cache operate with the binary specifications. It does not require "original research" to state that a machine with 2 RAM cards at 512 each has a total of 1024 MiB of memory, any more than it requires "original research" to state that the machine has two cards because 1+1=2. On the other hand, hard drive capacities typically ''are'' measured in "true" decimal specifications-an HD specified at 200 GB really does have (200*1000*1000*1000) bytes of available storage. Also, we shouldn't shy away from using a specific term over a general one just because it's a "big word" that some people may not initially understand. The XiB prefixes are international standards with unambiguous meanings, they are not a neologism. I would venture a guess that many of our users may not know exactly what ] is, but that doesn't mean we should use the more general term "battery acid"-instead, we should use the specific term, and link to its page, so that our readers may ''learn'' what the specific term means if it's not clear to them. (Some people refer to the electrolyte in alkaline batteries as being "battery acid"!) In the same vein, it is our job to be ''specific'' when referring to technical specifications. The XiB prefixes are unambiguous terms with clearly defined meanings, and we do a disservice to our readers by ''not'' being as accurate as we possibly can. ] 11:31, 25 January 2007 (UTC)
	Misplaced Pages is a tertiary source and verifiability is one of its bedrock principles. Making manufacturers' specifications "more accurate" goes beyond our charter. Converting to binary prefixes requires some technical judgement. If that judgement cannot be independently verified by a published source, it's a problem. We are talking about dozens of articles here. And I don't agree that it is a service to our readers to use terminology that is not widely adopted--and which may never be. We don't call water "dihydrogen oxide," even though that term may more closely conform to internationally accepted chemical nomenclature. Note I am not suggesting the XiB prefixes be banned, merely that their use be subject to editorial consensus. --]
	:In practice, vendors use K/M/G/T as binary prefixes; nobody should dispute that. A Core 2 Duo that Intel says has "4 MB" of level 2 cache, for example, does '''''not''''' have 4 000 000 bytes of L2 cache, it has 4 194 304 bytes of L2 cache. Trust me on this one - it'd just be too much of a pain to get rid of those extra 194304 bytes, given that addressing in modern processors work with binary addresses, not BCD addresses. Thus, clearly, K/M/G/T are ambiguous, as, when you're not counting bits or groups of bits, they're decimal prefixes, not binary prefixes. The same technical judgement that would be required to convert those prefixes to binary prefixes in a Misplaced Pages article would also be required to ''interpret'' a Misplaced Pages article not using binary prefixes. ] 19:23, 25 January 2007 (UTC)
	:Misplaced Pages does not derive its value from blindly copying data from manufacturers. Making the data unambiguous and comparable is added value of wikipedia. Note for example that although disks are usually measured in decimal prefixes (e.g. 100 GB), Windows reports with the same visible prefix, but digital values (e.g. 93.1 GB, actually 93.1 GiB). Clearing up that kind of differences is useful. Therefore we should perhaps adopt a similar approach as to other units of measure and indicate both the source value and a conversion or re-interpretation to internationally standardised units. So me might have:
	:* the disk size is 100 GB (93.1 GiB)
	:* the memory size is 2 GB (2 GiB)
	:This approach allows both verification against sources and verification of interpretation. &minus;] 14:01, 25 January 2007 (UTC)
	::This isn't a matter of verifiability at all, it's simply which prefix is more accurate. It's not making vendors' specifications "more accurate", it's correctly interpreting the context and removing the ambiguity, something that many readers could not do own their own. I support the current wording exactly because whenever I've seen this issue play out on a per-article basis it often gets overrun by people who are totally ignorant of the issue and just stubbornly cling to their own uninformed and confused ideas. A strong guideline is necessary to prevent pages and pages of debate from developing on every article where this comes up; we've discussed it enough times here as it is. -- ] <code>@ 2007-01-25T14:20Z</code>
	:::Referring to editors who disagree with your position as "totally ignorant of the issue and just stubbornly cling to their own uninformed and confused ideas." is unacceptable. See ]. We are trying to write articles appropriate to our audience. The personal computer industry has thus far not accepted the IEC binary prefix recommendation. A reader who looks at an article converted to use them will be confused when comparing it to other sources, not aided. We allow articles about cars to cite top speeds in mi/hr and km/hr, not m/s and we don't expect fuel economy in meters/mole, even though the later terms are what SI specifies. Nor should we be "interpreting" manufacturer's specifications. From ] "the only way to demonstrate that you are not doing original research is to cite reliable sources that provide information directly related to the topic of the article, and to adhere to what those sources say." I have less problem with ] suggestion of giving XiB units parenthetically, as it is adding info, not interpreting, though, again, I think this can be left to project editors who know their audience and subject area.--] 16:10, 25 January 2007 (UTC)
	::::I'm sorry, but I don't see identifying a problem for what it is as uncivil. I'm not going to water down my words for the sake of some silly ideal of political correctness, but I'm certainly not mentioning names or trying to pick a fight or demeaning anybody. Nor did I imply that everyone who doesn't agree with me is ignorant; if you bother to read, I have at several points acknowledged the validity of opposing points of view on this matter. However, the fact is that many (not all) people are either ignorant or confused about this issue. If you look at all the previous discussions you can clearly see this element popping up in the form of bad arithmetic or just a total lack of understanding of what these prefixes are and intend to do. If you think it's uncivil for me to say so explicitly, I'm sorry to say that I can't please you with candy-coated words or a runaround suitable for a career in diplomacy. Anyway, my position is clear, I feel the current verbiage should stay. -- ] <code>@ 2007-01-25T18:51Z</code>
	I fully support the current wording. These prefixes don't cause confusion; they cause accuracy. Just make sure they link to the appropriate articles as specified in the MoS. — ] 15:46, 25 January 2007 (UTC)
	what i think? since the pc and mac manufactures and the computers them selves do not use the new si. the article for that computer should not either.i support the new prefixes but only if the computer and the manufacture start using them my mac does not so the article for it should not reflect that change.when a computer or manufacture starts using the new si prefix then yes i think it should go in to the article the way i see it mb may be old not not fully correct but it is what the computer and manufactures say wikipedia should not try and change this as it is not wikipedias or its editors place to do so.
	{{unsigned}}
	The argument on popular understanding is a straman: nobody really cares about the added i. ] 15:25, 26 January 2007 (UTC)
	:I tend to agree. It's an arguable point which is difficult, if not impossible to back up with any hard facts. -- ] <code>@ 2007-01-26T23:09Z</code>

---

Latest revision as of 19:36, 10 January 2025

This is the talk page for discussing improvements to the Manual of Style/Dates and numbers page.

Put new text under old text. Click here to start a new topic. New to Misplaced Pages? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed Shortcuts WT:DATE WT:MOSDATE

Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163Auto-archiving period: 2 months

Please stay calm and civil while commenting or presenting evidence, and do not make personal attacks. Be patient when approaching solutions to any issues. If consensus is not reached, other solutions exist to draw attention and ensure that more editors mediate or comment on the dispute.

This project page does not require a rating on Misplaced Pages's content assessment scale. It is of interest to the following WikiProjects:

Manual of Style This page falls within the scope of the Misplaced Pages:Manual of Style, a collaborative effort focused on enhancing clarity, consistency, and cohesiveness across the Manual of Style (MoS) guidelines by addressing inconsistencies, refining language, and integrating guidance effectively.Manual of StyleWikipedia:WikiProject Manual of StyleTemplate:WikiProject Manual of StyleManual of Style This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Misplaced Pages Manual of Style, and the article titles policy. Both areas are subjects of debate. Contributors are urged to review the awareness criteria carefully and exercise caution when editing. For information on Misplaced Pages's approach to the establishment of new policies and guidelines, refer to WP:PROPOSAL. Additionally, guidance on how to contribute to the development and revision of Misplaced Pages policies of Misplaced Pages's policy and guideline documents is available, offering valuable insights and recommendations.

Archives

General 1, 2, 3, 4, 5, vote, 6, 7, 8, 9 (AD/CE), 10, 11, 12, 13, 14, 14a, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 49a, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161 Binary prefixes B0, B1, B2, B3, B4, B5, B6, B7, B8, B9, B10, B11, B12, B13, B14, B15, B16, B17 Years and dates D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14 See also Misplaced Pages:WikiProject Dates Misplaced Pages talk:Date debate Misplaced Pages talk:Naming conventions (calendar dates) Misplaced Pages talk:Timeline standards Misplaced Pages:Measurements Debate Misplaced Pages talk:Manual of Style (dates and numbers)/Date autoformatting Complete rewrite of Units of Measurements (June 2008) Dec. 2008 RfC on Date linking/autoformatting (three proposals) Dec. 2008 RfC on Date linking/autoformatting (detailed)

This page has archives. Sections older than 60 days may be automatically archived by Lowercase sigmabot III when more than 2 sections are present.

It has been 206 days since the outbreak of the latest dispute over date formats.

Recent edits

A string of edits by Jc3s5h and JMF. introducing and removing changes to Misplaced Pages:Manual of Style/Dates and numbers § Common mathematical symbols, raise issues that I believe should be discussed.

1. The most recent change, permalink/1247903136, has the comment This page does not cover matrix operations., however, I do not see anything in the article to support a restriction to numerical operations.
2. The most recent change reinstates the link to dot product, despite the comment.
3. There seems to be disagreement on the division sign.

The questions that I wish to raise are

1. Should that section mention {{tmath}} or <math>...</math>?
2. Are vector operations within the scope of the article? Regardless of the answer, the dot and cross products should be treated consistently.
3. Should there be two new rows for dot and cross product?
4. Should there be a row for tensor product?
5. Is obelus unhelpful since it has three forms?
6. Should the Division sign (U+00F7 ÷ DIVISION SIGN) be deprecated in favor of Slash (U+002F / SOLIDUS)?
7. Should U+2215 ∕ DIVISION SLASH be explicitly deprecated in favor of Slash?
8. Should the use of "x" and "*" as multiplication signs be explicitly deprecated in favor of U+00D7 × MULTIPLICATION SIGN?
9. Should that section show the LaTeX markup for characters in addition to the HTML character entity references?

-- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:52, 27 September 2024 (UTC)

1. I think the page should be devoted to general articles, and <math> should be reserved for advanced math and science articles.
2. Vector operations are not currently in the scope of the project page, and I'm not thrilled about adding them.
3. 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.
4. Tensor products should not be covered in this project page because they're too advanced.
7. I'm not willing to spend 5 or minutes figuring out what this line means.
8. The asterisk as a multiplication sign should be limited to articles about computer languages that use it as such.
9. LATEX should not be mentioned, since we don't use it in Misplaced Pages. This isn't a style manual for writing outside of Misplaced Pages.

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 U+00D7 × MULTIPLICATION SIGN over x, for biology as well as math but maybe that needs debate.

𝕁𝕄𝔽 (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 Misplaced Pages. We use points as decimal separators also, and we use commas 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.
• <math>x</math> (i.e., ${\displaystyle x}$) looks different from ''x'' (i.e., x), and those look different from {{math|''x''}} (i.e., x), 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).

—⁠ ⁠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. — 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 integration instead. —⁠ ⁠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 looks more like a superscript than a binary operator consistent with +, −, = and so on).

I don't think we should feel responsible for how Misplaced Pages is rendered in all possible fonts. We should remember that everyone is supposed to be able to edit Misplaced Pages 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 "-", "–", "—", and "−", and to not use italics for the numbers in that formula, although I support those instructions. —⁠ ⁠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 Misplaced Pages. Other editors who care about typography and MoS can clean up the markup and character choices later. Misplaced Pages is a collaborative project. 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. 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. 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 (talk) (contributions) 14:28, 12 November 2024 (UTC)

Ah, but which came first - the * key, or its use in mathematical expressions? Forty-some years ago, I was taught that in computer code, the * character was chosen to avoid confusion with the letter x, since the × did not exist in either of the character sets that were in use at the time - ASCII and EBCDIC. It's the same with / vs. ÷ and indeed - vs. −. --Redrose64 🌹 (talk) 18:15, 12 November 2024 (UTC)

* 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 * 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 * - 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 *, - and / but not +. + 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. * looked the most like x without being a letter, so it got the job.  Stepho  talk  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. * has been used, in math, to mean multiplication for three hundred years. See the bottom of p. 66 of . EEng 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). --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 set of the IBM 704, which replaced the older Percent (%) and Lozenge (U+2311 ⌑ SQUARE LOZENGE) with parentheses. -- Shmuel (Seymour J.) Metz Username: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.

-- 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? 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. EEng 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. -- 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 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 MapReader. NebY (talk) 14:56, 20 October 2024 (UTC)

  Between May 1966 and 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. --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? 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). Gawaon (talk) 16:37, 21 October 2024 (UTC)

  It is indeed a matter of internal consistency and it does look bad, as 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? -- Jmc (talk) 18:47, 21 October 2024 (UTC)

  From Misplaced Pages: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 (talk) (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. 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 Misplaced Pages: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 Misplaced Pages:Manual of Style/Television#Episode listing. Articles are often titled <show> season <n> where n is a digit, never a word, in accordance with Misplaced Pages:Naming conventions (television)#Season articles. Sampling our WP:Featured articles#Media, I see the same treatment in titles, infoboxes, and listings.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. NebY (talk) 08:20, 23 October 2024 (UTC)

  I agree, a small addition to MOS:NUMERAL might be a good thing. 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. 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" or "3rd century BC" 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 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.)  — SMcCandlish ☏ ¢ 😼  15:04, 24 November 2024 (UTC)

μs vs us

Which style I should use for micro seconds? Does μs relative to "Do not use precomposed unit symbol characters"? 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.  Stepho  talk  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.  — SMcCandlish ☏ ¢ 😼  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? —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.  Stepho  talk  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. —DocWatson42 (talk) 07:40, 4 November 2024 (UTC)

  Ah, the mysterious East. EEng 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 February 24 or February 24, 2024, then without doubt the right format is Wednesday, February 24 or Wednesday, February 24, 2024.
    • According to "Elite editing" (whoever they may be -- search the text "inverted style" on that page), the corresponding answers for 24 February and 24 February 2024 are Wednesday, 24 February and Wednesday, 24 February 2024. To me that does seem right -- 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. EEng 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.  Stepho  talk  09:18, 4 November 2024 (UTC)

Okay—will do. Thank you both. ^_^ —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.

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.  — SMcCandlish ☏ ¢ 😼  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, Number 57 23:49, 5 November 2024 (UTC)

• MOS:PERCENT says "omit space".  Stepho  talk  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? Number 57 00:21, 6 November 2024 (UTC)

  Apologies, I missed the "point" word in your question.  Stepho  talk  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. EEng 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. 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. Tony (talk) 11:10, 8 November 2024 (UTC)

  Absolutely. When it comes to peepee, always space it . EEng 21:36, 8 November 2024 (UTC)

  Yes, "%" is an ISO standard unit symbol. Dondervogel 2 (talk) 12:45, 8 November 2024 (UTC)

  What is it the unit of? 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. --Redrose64 🌹 (talk) 19:58, 8 November 2024 (UTC)

  It's used widely in election infoboxes where there isn't space to write it out. Number 57 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 (%). 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. Dondervogel 2 (talk) 22:16, 8 November 2024 (UTC)

  I found this in NIST Special Publication 811

  • In keeping with Ref. , 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 . 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. Dondervogel 2 (talk) 22:38, 8 November 2024 (UTC)

  there is always a space between numerical value (e.g., 35) and the percentage symbol (%) – Maybe in NIST-world, but not here on Misplaced Pages (see MOS:PERCENT), so I don't see how any of that helps us with the issue at hand. EEng 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. 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? EEng 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? 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 ml". That the spelled-out equivalent "approximately", like the spelled out "percent", is spaced apart from the numeral is irrelevant.  — SMcCandlish ☏ ¢ 😼  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 × (“1 m × 3 m × 6 m, not 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: {{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 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: Misplaced Pages talk:Manual of Style/Dates and numbers/Archive 145#Repeating units in ranges and dimensions, where the potential for confusion with actually 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. — HTGS (talk) 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. 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.  Stepho  talk  22:40, 11 November 2024 (UTC)

No, what Dvogel means is you'd write that a certain phone measures 146 x 71.5 x 7.65 mm. Having clarified that, I'm bound to say that that would, of course, confuse 99% of our readers. EEng 22:47, 11 November 2024 (UTC)

Gotcha. As well as confusing most readers, it would also be different to 1 by 3 by 6 m, which is allowed.  Stepho  talk  23:30, 11 November 2024 (UTC)

To be clear for those playing along at home, while the canonical formuations are 1 m by 3 m by 6 m and 1 m x 3 m x 6 m, MOS currently makes an exception allowing 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 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? EEng 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. 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. Dondervogel 2 (talk) 23:42, 11 November 2024 (UTC)

one could also write 146 x 71.5 x 7.65 mm, but then we have a length, not a volume – Formally perhaps, but you could say the pretty much the same about 146 by 71.5 by 7.65 mm, and yet we allow it. No one will think that 146 x 71.5 x 7.65 mm means the length 79.86 m (i.e. 79860 mm). In context readers will understand it for what it is. I'd like to hear what others think about my proposal. EEng 23:56, 11 November 2024 (UTC)

Seconded EEng's proposal - simple and clear.  Mr.choppers | ✎  04:36, 14 November 2024 (UTC)

EEng is, of course, correct. At {{convert}} we sometimes are asked how the duplicate mm units can be removed to save space (the trick is to use xx in convert) and we tell them that omitting repeated units is ok if space is limited. May as well make it official. Johnuniq (talk) 05:51, 14 November 2024 (UTC)

EEng is, of course, correct. – Of course -- even Dondervogel says so. EEng 06:37, 14 November 2024 (UTC)

I also support the proposal.  Stepho  talk  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. Toadspike 17:31, 18 November 2024 (UTC)

:( — HTGS (talk) 23:34, 18 November 2024 (UTC)

• It's tiresome to have to write (and read) units multiple times when multiplication signs are used. Tony (talk) 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. — HTGS (talk) 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 Germany or New Zealand, automobile and bike wheels are universally referred to by inches; rim diameters are expressly 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.  Mr.choppers | ✎  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 this that use both metric and imperial/American units for bike wheels and tires. Whether the convert template handles them correctly is another issue. Donald Albury 17:43, 13 November 2024 (UTC)

On the matter of wheel sizes, not all are inches. See 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. --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.  Mr.choppers | ✎  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. Avi8tor (talk) 11:40, 14 November 2024 (UTC)

@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.  Mr.choppers | ✎  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. 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. Tony (talk) 07:30, 22 November 2024 (UTC)

  I thought that "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. Dondervogel 2 (talk) 22:06, 22 December 2024 (UTC)

RfC Indian numbering conventions

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.

(non-admin closure) Soni (talk) 22:02, 24 December 2024 (UTC)

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

---

I am revisiting an issue that was last brought up 6 years ago 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 Misplaced Pages'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". Kurzon (talk) 16:38, 16 November 2024 (UTC)

What's the common usage in english? 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 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.

--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. Kurzon (talk) 17:15, 16 November 2024 (UTC)

We use meters over feet? Where?

In non-scientific articles with strong ties to the United States, the primary units are US customary (pounds, miles, feet, inches, etc.)

Aaron Liu (talk) 17:50, 16 November 2024 (UTC)

You get extra points for saying "US customary" and not "Imperial". 😉 Isaac Rabinovitch (talk) 18:20, 16 November 2024 (UTC)

imperial :3 Aaron Liu (talk) 18:30, 16 November 2024 (UTC)

I agree with Kurzon, do not use "crore", use "millions". Misplaced Pages is for a worldwide audience. 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. Aaron Liu (talk) 18:19, 16 November 2024 (UTC)

Except we don't favor meters over feet — we use both. That's what the 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 international unit is also used. Isaac Rabinovitch (talk) 18:18, 16 November 2024 (UTC)

We already make an exception for 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 rupees?). 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. 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. Aaron Liu (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). 35.139.154.158 (talk) 18:21, 16 November 2024 (UTC)

  @Kurzon: I did advise you not to jump straight for a full-blown thirty-day formal RfC without first exhausting the suggestions at WP:RFCBEFORE. --Redrose64 🌹 (talk) 18:39, 16 November 2024 (UTC)

This RfC is clearly improperly formatted, 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. 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. Aaron Liu (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 ENGVAR. I am unsure where I sit on this issue. I would like to see some Indian editors weigh in on this. Toadspike 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.  Mr.choppers | ✎  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.) Toadspike 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.

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. Aaron Liu (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. Toadspike 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 require the use of short-scale even though long-scale hasn't entirely died out in the British Isles. 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. Aaron Liu (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. For an international encyclopedia, using vocabulary common to all varieties of English is preferable - to the point of being paramount. 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. SchreiberBike | ⌨  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. Toadspike 13:56, 17 November 2024 (UTC)

• Allow crore, lakh per SchreiberBike, and with the same caveats. Dondervogel 2 (talk) 00:03, 17 November 2024 (UTC)
• Allow ScreiberBike, per my comments above. Aaron Liu (talk) 01:20, 17 November 2024 (UTC)
• Allow ScreiberBike. But see also Misplaced Pages: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" — Preceding unsigned comment added by Asteramellus (talk • contribs) 00:30, 18 November 2024 (UTC)
• Allow crore, lakh and Indian numbering system, but always, 1) link it upon first use in every section where it appears, 2) include what it is a measure of (rupees can not be assumed), 3) also include conventional numbering using template {{convert}}—i.e., don't convert yourself, and 4) allow it only in articles about the subcontinent. Mathglot (talk) 23:11, 18 November 2024 (UTC)

  Hm; was very surprised to notice that the {{convert}} template does not currently support lakhs and crores. I think it should, and started a discussion about that. If you wish to comment, please go to Module talk:Convert#Indian numbering system: lakhs and crores. Thanks, 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. --Redrose64 🌹 (talk) 22:52, 19 November 2024 (UTC)

  The {{lakh}} and {{crore}} templates make more sense than overloading {{convert}}.  Stepho  talk  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.  Mr.choppers | ✎  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. Avgeekamfot (talk) 09:50, 20 November 2024 (UTC)

  What does "widespread" mean? Aaron Liu (talk) 12:17, 20 November 2024 (UTC)

Notified: Misplaced Pages talk:Manual of Style/India-related articles. jlwoodwa (talk) 01:04, 21 November 2024 (UTC)

• Allow, but always ... exactly as Mathglot laid out above (other than, per Stepho-wrs and Redrose64, {{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.  — SMcCandlish ☏ ¢ 😼  11:55, 21 November 2024 (UTC)
• Allow when appropriate, under conditions set out by ScreiberBike. Also, this RfC does not meet WP:RFCNEUTRAL. ThatIPEditor 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. Tony (talk) 07:32, 22 November 2024 (UTC)

  I don't get what native/non-native speakers have to do with the issue. Aaron Liu (talk) 12:21, 22 November 2024 (UTC)

• Allow per ScreiberBike for South Asian articles. 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 {{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. — 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 Misplaced Pages. The Indian comma would be much worse. 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 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.  — SMcCandlish ☏ ¢ 😼  14:49, 24 November 2024 (UTC)

  “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’. — HTGS (talk) 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. Aaron Liu (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. — HTGS (talk) 03:18, 29 November 2024 (UTC)

  Yes, that or add spelling that says "colour" is what I'm saying. Aaron Liu (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. Aaron Liu (talk) 04:11, 29 November 2024 (UTC)

  On this attempt at a color 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 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.  — SMcCandlish ☏ ¢ 😼  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. — HTGS (talk) 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 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 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 should be the rule, but it'll be hard to get there.)  — SMcCandlish ☏ ¢ 😼  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. 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. 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. Aaron Liu (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. Stepho  talk  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". 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.  Stepho  talk  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/search/?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 :)  Stepho  talk  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. — HTGS (talk) 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. Tony (talk) 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. Dondervogel 2 (talk) 12:49, 29 November 2024 (UTC)

  Perhaps some are not aware but English Misplaced Pages is heavily used in India. The Top 50 Report from 2023 had five items about Indian movies and movie stars. The latest week's most viewed 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. SchreiberBike | ⌨  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 In non-scientific articles with strong ties to the United States India, the primary units are US customary (pounds, miles, feet, inches, etc.) 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. --𝕁𝕄𝔽 (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. Chaotic Enby (talk · 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? Alaexis_¿question? 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. SchreiberBike | ⌨  20:50, 8 December 2024 (UTC)

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

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! — Preceding unsigned comment added by Masterhatch (talk • contribs)

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.). --𝕁𝕄𝔽 (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 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 even if you're sure you've got a good reason and don't think there should be resistance.

The STYLEVAR process actually sometimes (namely when there's clearly no firm consensus in favor of the status quo ante, either) overrides the usual Misplaced Pages 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 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 status quo; how long is long enough; whether interruptions in the use of the alleged status quo have reset its tenure; whether this *VAR-imposed consensus discussion was followed when the alleged 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 the end of it, and we move on to something more productive.

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 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.)  — SMcCandlish ☏ ¢ 😼  12:02, 23 December 2024 (UTC)

But what would be the status quo ante in this case? Surely you can't mean the mixed BC/BCE style? Gawaon (talk) 08:56, 24 December 2024 (UTC)

Four questions

1. 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?
2. Can 12-hour clock be used with UTC time?
3. 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.
4. 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? --40bus (talk) 23:04, 21 December 2024 (UTC)

   I'd add a fifth question: why does Misplaced Pages not use ISO dates, i.e. yyyy/mm/dd? They are becoming more common internationally. Skeptic2 (talk) 00:02, 22 December 2024 (UTC)

   1. I wouldn't recommend it.
   2. Probably?
   3. That should be decided on a case-by-case basis.
   4. No benefit for the additional visual or semantic complexity; that's part of the appeal of the metric system, right?
   5. English-language sources never use this format, and the English Misplaced Pages bases its style on that of other English-language media.

   Remsense ‥ 论 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 Misplaced Pages entry List of date formats by country. You might be surprised.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". Remsense ‥ 论 23:36, 22 December 2024 (UTC)

1. 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.
2. 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.
3. 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.
4. 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.
5. 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  Stepho  talk  01:09, 22 December 2024 (UTC)

   (In terms of accuracy in my own answers, 2 out of 5 ain't bad right?) Remsense ‥ 论 01:11, 22 December 2024 (UTC)

Being OCD helps 😉  Stepho  talk  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! Remsense ‥ 论 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).

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. Kahastok talk 14:56, 22 December 2024 (UTC)

@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 – 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.) 𝕁𝕄𝔽 (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. 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 17:00 GMT (17:00 UTC) and I would like to see examples of that usage. Kahastok talk 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 Misplaced Pages), 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 – 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. 𝕁𝕄𝔽 (talk) 20:25, 22 December 2024 (UTC)

If you weren't aiming to be pedantic in the extreme, why bring it up? And in particular, why claim - specifically in the context of GMT vs UTC - that the time is normally given both ways: in the local and in the international notations in situations where time zone matters? 'Kahastok' talk 21:22, 22 December 2024 (UTC) s

My 2c:

1. 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.
   1. 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.
2. I was about to declare that UTC offsets 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?
3. 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 chains – all UK railway engineering has been done in metric since 1975. So no, MOS:RETAIN applies to UK articles too. Except articles under the aegis of Misplaced Pages:WikiProject UK Railways, of course. --𝕁𝕄𝔽 (talk) 15:43, 22 December 2024 (UTC)
4. I concur with Stepho's reply.
5. 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. 𝕁𝕄𝔽 (talk) 15:40, 22 December 2024 (UTC)

You say, 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? Kahastok talk 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. MapReader (talk) 04:05, 23 December 2024 (UTC)

Never mind that other countries that went metric changed our road signs just fine.  Stepho  talk  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.  Stepho  talk  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 Misplaced Pages sometimes chooses to depart from the SI, via MOSNUM. I don't believe MOSNUM permits this particular departure.

Dondervogel 2 (talk) 08:30, 23 December 2024 (UTC)

Remsense, one reason Misplaced Pages 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. 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? --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. --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. Remsense ‥ 论 00:20, 23 December 2024 (UTC)

Whaaaaat? Why would we want the least fun format on the weekend?  — SMcCandlish ☏ ¢ 😼  09:02, 23 December 2024 (UTC)

Year-first encourages us to meditate on the long term while many are less occupied at work. Remsense ‥ 论 08:59, 24 December 2024 (UTC)

My responses to these questions would be:

1. 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).
2. Meaningless, confused question. As Stepho-wrs explained, UTC is an offset, not a format. There's a standardized way of writing 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 "U+0040 @ COMMERCIAL AT", 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.
3. A Canada–US squabble over ordering: A) Who cares? We have {{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.
4. 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 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 W  3.7 A".
5. 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.

 — SMcCandlish ☏ ¢ 😼  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. Avi8tor (talk) 12:56, 29 December 2024 (UTC)

It isn’t however very readable, on articles of prose. 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. Remsense ‥ 论 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? --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. Dondervogel 2 (talk) 14:05, 22 December 2024 (UTC)

You can also consult our {{convert}} template which deals with all these edge cases: {{convert|10|cm|adj=on|abbr=on}} produces 10 cm (3.9 in), 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. Remsense ‥ 论 15:07, 22 December 2024 (UTC)

This is possible to output: {{convert|10|cm|adj=on|abbr=on}}, and it produces: ten cm (3.9 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,142857 m" would look ugly, so 1⁄7 m would be only option. --40bus (talk) 23:13, 22 December 2024 (UTC)

Do you have a real world example illustrating your concern? Dondervogel 2 (talk) 23:22, 22 December 2024 (UTC)

How would 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 1⁄7, which can mess with line height. It actually copy-pastes as 1⁄7, 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 <code>...</code> block!) I'm not convinced we should have that template at all, since the Internet has done just fine with 1/7 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 {{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).  — SMcCandlish ☏ ¢ 😼  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: patients' ages were five, seven, and thirty-two or ages were 5, 7, and 32, but not ages were five, seven, and 32.

This goes against the 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 Misplaced Pages style the odd one? -- RickyCourtney (talk) 04:14, 28 December 2024 (UTC)

The example shows it very well. Mixing both types in one sentence like ages were five, seven, and 32 looks very amateurish.  Stepho  talk  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. Remsense ‥ 论 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 one article on the topic: Kazakhstan’s Emergency Situations Ministry said that at least 29 people had survived, including two children … Kazakhstan’s transportation ministry said that the flight’s passengers included 37 Azerbaijani nationals, 16 Russians, six Kazakh citizens and three Kyrgyz nationals. … 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: 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: 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. 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. 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? 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. 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. Remsense ‥ 论 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. 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". 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, Misplaced Pages 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. MapReader (talk) 14:08, 28 December 2024 (UTC)

I'd say that 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 one and 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 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. 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 RickyCourtney would like to change the guidance to reverse that preference. Dondervogel 2 (talk) 08:58, 28 December 2024 (UTC)

62 passengers and 5 crew is certainly possible if we consider this as falling under the guideline. However, 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". 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: '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.  Stepho  talk  13:09, 28 December 2024 (UTC)

29 only has meaning to me in that it is comparable to 1. Remsense ‥ 论 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 in this article. As does Euronews. As does the Irish Mirror. 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.  Stepho  talk  22:44, 28 December 2024 (UTC)

@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: 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: 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 New York Times, Euronews and the Irish Mirror. -- RickyCourtney (talk) 15:58, 28 December 2024 (UTC)

But is more readable as it was. MapReader (talk) 18:01, 28 December 2024 (UTC)

My choice would be all numeric: 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: 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.  Stepho  talk  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. —Tenryuu 🐲 ( 💬 • 📝 ) 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. -- 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:

1. 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.
2. 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. 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? MapReader (talk) 15:51, 30 December 2024 (UTC)
• Agree with MapReader, this is standard. GiantSnowman 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." Jc3s5h (talk) 16:30, 30 December 2024 (UTC)
• There ain't nothin' wrong with September 2001. 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. EEng 21:51, 30 December 2024 (UTC)

• @Quindraco: You're about twenty years too late to change the guideline. --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." Quindraco (talk) 05:27, 7 January 2025 (UTC)

  Except you haven't shown it to be wrong in the first place. "Month Year" dates have always been taught to be correct in my experience. If you think about it, requiring "July, 1776" would also require "4 July, 1776". I have noticed that my computer's available date formats include a few oddities that I was always taught were flat out wrong. Is that where you are getting this idea?--User:Khajidha (talk) (contributions) 00:28, 9 January 2025 (UTC)

  Yep. Just checked. Windows has "Wednesday, 5 April, 2017" and "5 April, 2017" listed as date formats. Commas should only be used within the date when it is not in either "day-month-year" or "year-month-day" order. I've sent feedback about this, but I doubt that anything will be done about it.--User:Khajidha (talk) (contributions) 16:55, 9 January 2025 (UTC)

• The OP's complaint is, I regret to say, just so much WP:MISSSNODGRASSism. EEng 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. --Coolcaesar (talk) 06:38, 7 January 2025 (UTC)
• It's recognised to be standard usage in Canada. —Tenryuu 🐲 ( 💬 • 📝 ) 16:12, 7 January 2025 (UTC)
• "January 2018" is the official usage in Australia: https://www.stylemanual.gov.au/grammar-punctuation-and-conventions/numbers-and-measurements/dates-and-time ("Incomplete dates" section).  Stepho  talk  00:50, 9 January 2025 (UTC)
• Agree with those above; "September 2001" is perfectly acceptable. Peter coxhead (talk) 15:02, 9 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: Guardian, Bloomberg, Billboard, IFIMES, 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. Chessrat 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. -- Shmuel (Seymour J.) Metz Username: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. 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 Misplaced Pages 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. Fyunck(click) (talk) 09:38, 3 January 2025 (UTC)

  That sounds like a case of 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.) 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." Misplaced Pages 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

"century". Oxford Dictionaries. Archived from the original on December 30, 2019. Retrieved 20 January 2021.

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. — HTGS (talk) 03:28, 2 January 2025 (UTC)

+1 EEng 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 @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; Misplaced Pages has a duty to provide accurate information even if it does take a significant amount of work fixing this across various articles. Chessrat 16:15, 2 January 2025 (UTC)

How many years were there in the 1st century? Dondervogel 2 (talk) 18:27, 2 January 2025 (UTC)

100, obvs. 1 AD to 100 AD. Next question please? --Redrose64 🦌 (talk) 21:12, 2 January 2025 (UTC)

My question was in response to 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). 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 Misplaced Pages, however, and if anyone feels strongly enough about the current guidance being wrong, RfC is thataway. 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. 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. Chessrat 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? Gawaon (talk) 08:08, 3 January 2025 (UTC)

@Chessrat and 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 "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). --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. Chessrat 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! 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. Misplaced Pages should not take it upon itself to make up an exception. Dondervogel 2 (talk) 19:11, 4 January 2025 (UTC)

@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 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 Misplaced Pages 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”. — HTGS (talk) 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. 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. — HTGS (talk) 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 Misplaced Pages 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 Misplaced Pages 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 Reuters, The Telegraph, The Atlantic, The Guardian France 24, 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 Slate, the Washington Post, and 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 Misplaced Pages 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. Chessrat 09:03, 3 January 2025 (UTC)

So your suggested change would also affect many other articles such as our own sourced 19th century article. Fyunck(click) (talk) 10:08, 3 January 2025 (UTC)

Usage such as 20th century for 1900 - 1999 simply reveals the source as being unable to perform basic counting. Any such source is immediately rendered unreliable. --User:Khajidha (talk) (contributions) 13:06, 8 January 2025 (UTC)

I'm usually one to say that we should accept that language changes and that we in the language police should go along with it, but in this case, many, especially the mainstream press, looking for headlines, are wrong. Saying the first century has 99 years, is like saying 99 cents is sometimes a dollar. Sometimes a misused word becomes acceptable, but not in this case. SchreiberBike | ⌨  14:42, 8 January 2025 (UTC)

As per WP:RS (with the emphasis on reliable), I asked Mr Google when does the new century start, 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.

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 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.  Stepho  talk  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. 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. Chessrat 13:45, 3 January 2025 (UTC)

@Chessrat: the century beginning in XX01 is not 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. 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. 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. Hawkeye7 (discuss) 22:06, 3 January 2025 (UTC)

At least we can all agree that that would be the ugliest possible solution. — HTGS (talk) 08:26, 4 January 2025 (UTC)

@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. --Redrose64 🦌 (talk) 22:52, 3 January 2025 (UTC)

RfC on the wording of MOS:CENTURY

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: History and geography Language and linguistics When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

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. Chessrat 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. 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. —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". —Kusma (talk) 22:26, 3 January 2025 (UTC)

  In short, oppose change. —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. --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. 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? 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. 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. —Kusma (talk) 17:46, 4 January 2025 (UTC)

• Oppose. If this matters to you, convince the academic sources to adopt the change, then Misplaced Pages can follow. 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. 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). 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. — HTGS (talk) 19:22, 6 January 2025 (UTC)

  You seem to be saying the choice between a century (the first, whether AD or BC) of 99 or 100 years amounts to personal preference. Do you have credible sources showing they are equally valid? Dondervogel 2 (talk) 19:23, 7 January 2025 (UTC)

• Oppose treating both as acceptable This would lead to endless confusion. Peter coxhead (talk) 22:02, 5 January 2025 (UTC)
• Oppose change; century starts at ###1 and ends ###0 — Preceding unsigned comment added by Mr Serjeant Buzfuz (talk • contribs) 23:18, 5 January 2025 (UTC)
• Strongly oppose any change resulting in more than one definition of a century. The reasons seem self-evident, and others have spelt them out above. In a nutshell, such a change would be a retrograde step, against the spirit of the MOS. Dondervogel 2 (talk) 23:21, 5 January 2025 (UTC)
• Just use '00s. Why on Earth should MoS ever 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 Misplaced Pages, for this exact reason. It's consistent with how we refer to decades (see vs. ). It's universally understood. It avoids silly arguments like this one. Let's just do that. -- Tamzin (they|xe|🤷) 23:36, 5 January 2025 (UTC)

  And to put this in terms of what the wording should be, I would suggest something like

  Because phrases like the 18th century are ambiguous (sometimes used to mean 1700–1799, sometimes 1701–1800), phrases like 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 nth century would lead to different meanings.

  -- Tamzin (they|xe|🤷) 23:52, 5 January 2025 (UTC)

  Is this a joke? Sorry if I ruined it by asking. — HTGS (talk) 23:56, 5 January 2025 (UTC)

  No? From any descriptive point of view, there is no widely-accepted definition of "nth century". Some Wikipedians thinking there should 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, much as we do with ENGVAR. -- Tamzin (they|xe|🤷) 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–. 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 implies that the century starts with 1700, but not explicitly. — HTGS (talk) 03:05, 6 January 2025 (UTC)

  We should avoid use of "1900s" to mean anything other than 1900-1909. 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 like the Library of Congress does, or 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.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. — HTGS (talk) 23:52, 5 January 2025 (UTC)
• Oppose change; continue using "20th century" for 1901–2000 and "1900s" for 1900–1999. Doremo (talk) 03:48, 6 January 2025 (UTC)
• Oppose change - The n 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. Fieari (talk) 04:53, 6 January 2025 (UTC)

  Per the MOS, and as Dondervogel 2 most succinctly puts it above: We should avoid use of "1900s" to mean anything other than 1900-1909. — HTGS (talk) 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). Fyunck(click) (talk) 07:16, 7 January 2025 (UTC)

• Oppose treating them both as acceptable. I imagine this could lead to headaches concerning inclusion in categories, list articles, timelines, templates, etc. Photos of Japan (talk) 01:23, 8 January 2025 (UTC)
• Oppose change People have been getting it wrong for centuries (pun not intended) and will probably continue doing so for centuries. Intuition says that the year 2000 was the start of the new century but intuition is wrong. Just like people believing that light-years and parsecs are a measure of time (doing the Kessel run or otherwise) or trying to learn relativity, intuition is simply wrong. All authoritative sources for measuring time say that the new century starts in the year xx01. WP is only suppose to report on this. If we try to say that the year 2000 is the first year of the new century then we are actively entering the battle and are try to WP:RIGHTGREATWRONGS.  Stepho  talk  04:12, 10 January 2025 (UTC)
• Keep XX1 as the start of a decade, century, or any other unit of year. It sounds ridiculous to have only the first CE century be 99 years long while everything before and after it remains at 100. —Tenryuu 🐲 ( 💬 • 📝 ) 18:34, 10 January 2025 (UTC)

  I think they consider the 1st century BC to also have 99 years. Dondervogel 2 (talk) 19:15, 10 January 2025 (UTC)

It is high time to end this "minor imbecility":

When the encyclopedia of human folly comes to be written, a page must be reserved for the minor imbecility of the battle of the centuries--the clamorous dispute as to when a century ends. The present bibliography documents the controversy as it has arisen at the end of the 17th, 18th, and 19th centuries, as well as a few skirmishes in the quarrel that has begun to develop with the approach of the third millennium.

The source of the confusion is easy to discern; ever since learning how to write, we have dated our documents with year designations beginning with the digits 19. Obviously, when we must begin to date them starting with 20, we have embarked on a new century! Haven't we? The answer is no, we have not; we have merely arrived at the last year of the 20th century. As historians and others involved in measuring time continue to remind us, there was no year 0. In fact, there has never been a system of recording reigns, dynasties, or eras that did not designate its first year as the year 1. To complete a century, one must complete 100 years; the first century of our era ran from the beginning of A.D. 1 to the end of A.D. 100; the second century began with the year A.D. 101.

While the period 1900-1999 is of course a century, as is any period of 100 years, it is incorrect to label it the 20th century, which began January 1, 1901, and will end on December 31, 2000. Only then will the third millennium of our era begin.

Those who are unwilling to accept the clarity of simple arithmetic in this matter and who feel strongly that there is something amiss with the result have developed some impressively convoluted arguments to promote their point of view. Baron Hobhouse, studying some of these arguments as set forth in letters published in the Times of London during the first few days of January 1900, found "that many of the reasons assigned are irrelevant, many are destructive of the conclusion in support of which they are advanced, and that such as would be relevant and logical have no basis whatever to maintain them in point of fact." He was one of several observers of the fray at the end of the 19th century who predicted that the foolishness would recur with the advent of the year 2000, as people began to look for ways of demonstrating "that 1999 years make up 20 centuries."

As a writer stated in the January 13, 1900, Scientific American, "It is a venerable error, long-lived and perhaps immortal." The shortness of human life is also a factor; as a century approaches its end, hardly anyone who experienced the previous conflict is still living, so we are doomed to undergo another round.

Astronomers have been blamed for some of the confusion by their adoption of a chronology that designates the year 1 B.C. as 0 and gives the preceding years negative numbers, e.g., 2 B.C. becomes -1, 3 B.C. becomes -2, etc. This system permits them to simplify calculations of recurring astronomical events that cross the starting point of our era, such as series of solar eclipses and the apparitions of periodic comets. However, this scheme affects only the years preceding A.D. 1 and cannot be used as a justification for ending subsequent centuries with the 99th year.

Some argue that Dionysius Exiguus made a mistake in his determination of the year of Christ's birth when he devised our present chronology in the sixth century, and that the discrepancy allows us to celebrate the end of a century a year early. However, even though the starting point of our era may not correspond to the chronologist's intention, it is still the point from which we count our centuries--each of which still requires 100 years for completion.

Nevertheless, as many of the entries in this list (from p. 45 on) will indicate, plans to celebrate the opening of the 21st century and the third millennium at midnight on December 31, 1999, have become so widespread that anyone who tries to call attention to the error is disparaged as a pedant and ignored. Perhaps the only consolation for those intending to observe the correct date is that hotels, cruise ships, supersonic aircraft, and other facilities may be less crowded at the end of the year 2000.

Dondervogel 2 (talk) 18:04, 10 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: 1 year = 365.2422 d.) –LaundryPizza03 (dc̄) 04:48, 6 January 2025 (UTC)

Try this:

value	name
100 years	big
2 days	tiny
10 days	tiny
20 days	tiny
10 years	mid
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  Stepho  talk  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. –LaundryPizza03 (dc̄) 05:24, 6 January 2025 (UTC)

It is more obvious when you look at the wiki mark-up:

{|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
|}

The data-sort-value 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 -> 0.027379092558308 . The rest is just for display. Click on the up/down arrows to sort increasing, sort decreasing or return to original (unsorted) order.  Stepho  talk  05:35, 6 January 2025 (UTC)

Sure, why not. –LaundryPizza03 (dc̄) 02:10, 7 January 2025 (UTC)

1. Kondev, F. G.; Wang, M.; Huang, W. J.; Naimi, S.; Audi, G. (2021). "The NUBASE2020 evaluation of nuclear properties" (PDF). Chinese Physics C. 45 (3): 030001. doi:10.1088/1674-1137/abddae.

Category:

• Misplaced Pages requests for comment