Misplaced Pages

talk:Manual of Style/Dates and numbers: Difference between revisions - Misplaced Pages

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
< Misplaced Pages talk:Manual of Style Browse history interactively← Previous editContent deleted Content addedVisualWikitext
Revision as of 20:01, 24 March 2008 edit217.87.77.88 (talk) →Standardisation is a good thing← Previous edit Latest revision as of 18:58, 9 January 2025 edit undoDondervogel 2 (talk | contribs)Extended confirmed users17,441 editsm →RfC on the wording of MOS:CENTURY: forgot to sign 
Line 1: Line 1:
{{talkheader|sc1=WT:DATE|sc2=WT:MOSDATE}}
{{Calm}}
{{WikiProject banner shell|
{{WikiProject Manual of Style}}
}}
{{User:MiszaBot/config {{User:MiszaBot/config
|archiveheader = {{aan}}
|maxarchivesize = 150K
|maxarchivesize = 800K
|counter = 96
|algo = old(15d) |counter = 163
|minthreadsleft = 2
|archive = Misplaced Pages talk:Manual of Style (dates and numbers)/Archive %(counter)d
|minthreadstoarchive = 1
|algo = old(60d)
|archive = Misplaced Pages talk:Manual of Style/Dates and numbers/Archive %(counter)d
}} }}
{{User:HBC Archive Indexerbot/OptIn
{{Misplaced Pages talk:Manual of Style (dates and numbers)/Archive box}}
<!--{{Misplaced Pages talk:Manual of Style (dates and numbers)/Archive box B}}--> |target=Misplaced Pages talk:Manual of Style/Dates and numbers/Archive index
{{Misplaced Pages talk:Manual of Style (dates and numbers)/Archive box D}} |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}}


== General IT prefix discussion == == Recent edits ==


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.
The IEC prefixes were approved in January 1999. After nine years, virtually nobody uses them. ] is in wider use. When Steve Jobs introduced the MacBook Air (skinny notebook) at Macworld he did not use the term gibibyte once. The news reports give the RAM size as 2 gigabyte, 2GB or 2Gbyte. The Manual of Style should reflect what the outside world is doing. The computer industry and the publishing world have ignored the IEC prefixes. -- ] (]) 06:09, 17 January 2008 (UTC)


#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.
: Do you have any opinion on the topic that is being discussed here? — ] ]/] 13:02, 17 January 2008 (UTC)
#The most recent change reinstates the link to ], despite the comment.
:: Yes I do. A few peoples here are trying to get the Manual of Style to adopt an obscure method of measuring computer storage. This edit war has been going on for several years. You are arguing over the rules of the edit war. The real question is should the Manual of Style follow a standard that had not reached 1% adoption in the real world after 9 years. -- ] (]) 14:52, 17 January 2008 (UTC)
#There seems to be disagreement on the division sign.
::: Just let me extract the interesting parts of your text: "few people", "an obscure method of measuring computer storage", "war", "1% adoption", "real world". Hopefully people will realize how pointless this discussion is. Don't waste your time, don't let them trick you. As long as this topic is under tight control of certain individuals, you can't win. Again don't waste your time with facts. They shall be ignored, absolutely, without remorse. --] (]) 05:57, 2 February 2008 (UTC)
:::: You are wrong and do not attempt to misrepresent other editors with your incorrect anonymous rants about "certain individuals". ''']]''' 10:03, 2 February 2008 (UTC)


The questions that I wish to raise are
::: Whether manufacturers are using these units is irrelevant. Fact is that the units are used inconsistently. Sometimes they have a binary meaning, sometimes a decimal one. Many of the readers wil not be aware which meaning is applicable in a specific mention of the unit. Therefore it is the task of an encyclopedia to make sure the reader is able to draw the correct conclusion. This can be achieved by always adding a conversion to (or a confirmation of) a standardised and well documented unit. We achieved consensus to do it that way a while ago. According to the guidelines units from a primary source should come first. So the usage would be:
:::* with decimal meaning: 64 MB (61 MiB)
:::* with binary meaning: 64 MB (=MiB)
:::&minus;] (]) 19:42, 17 January 2008 (UTC)
:::: Fact, KB, MB, GB are defined by standards organisation to be power of two. Fact, some manufacturers use other meansing. Lets say for the sake of argument some manufacturers started using KiB but in a decimal sense, that would be inconsistent use, so what then? It's not *always* needed though, just disambiguate (if you need to at all) the first occurrence in an article. ''']]''' 22:18, 17 January 2008 (UTC)
::::: Regardless of how inconsistent sources are, a conversion to standard units would always tell the user unambiguously what the correct meaning is. I agree that if the same number is used several times, one conversion might be enough. But it is just a welcome service to the reader to convert every number at least once. &minus;] (]) 22:31, 17 January 2008 (UTC)
:::::: I'm just going to quote "Fact is that the units are used inconsistently" and "Regardless of how inconsistent sources are" then grin for a while because I find it funny. ;) Seriously though the JEDEC, who are the standard organisation for memory and who have majority consensus, do define kilobyte etc in their standard. So which standard body is the better one to choose, the one that has a tiny 0.5% use (no consensus) in the real world or the one that has the huge majority consensus? And then if there is any use that differs from the JEDEC standard then make a point of disambiguating it with exact numbers of bytes. ''']]''' 22:56, 17 January 2008 (UTC)
::::::: I see your point about fun: it ''is'' funny: the more inconsistent usage is, the more there is a need for conversions. ''You'' may know exactly in which cases a particular interpretation is standardised by JEDEC, most people have never even heard about JEDEC. Why not help them by addding a conversion? &minus;] (]) 23:03, 17 January 2008 (UTC)
:::::::: Because according to the JEDEC it's not inconsistent, it is powers of two in size. Following on from the above I could point to companies using KiB but in the decimal sense. Then I could say "inconsistent" and then you'd have to drop pushing for KiB to be used, to ape the arguments used by some IEC supporters for example. Pushing for a particular style of prefix isn't actually the point, as we'll see in a second. What happened is that some other "standards organisation" came along and invented a new term, but it's not used except by a microscopic minority. However the question isn't about what standards organisation is best or whatever, no matter how tempting that is it doesn't actually tackle the real issue and it just causes people to sit behind their preferred camp. Remember you cannot say IEC is consistent since it has been shown IEC is inconsistent with the consensus in the real world. Also remember you cannot say IEC is not ambiguous because of the companies that use KiB in the decimal sense and also because JEDEC define it to be not ambiguous. The question is, why advocate something that only has a tiny 0.5% support, i.e. doesn't have consensus? ''']]''' 23:09, 17 January 2008 (UTC)


#Should that section mention {{tl|tmath}} or {{tag|math}}?
: Well, a kilobyte appears to be 2 raised to the power 10 (=1,024) in most systems and one megabyte can be either 1,000 kilobytes or 1,024 kilobytes; it gets a bit difficult to determine how many bytes there are in a particular wiggit. Some system is need to sort it out. I've lost track of the arguments, what's your proposal to sort it out - I don't think ''context'' is a valid approach.] (]) 23:45, 17 January 2008 (UTC)
#Are vector operations within the scope of the article? Regardless of the answer, the dot and cross products should be treated consistently.
:: The most common use being power of two. The only non-ambiguous way which also doesn't use neogolisms, i.e. is consistent with consensus, would be the following: Follow JEDEC or be consistent with the sources relevant to the article. If something uses JEDEC specified prefixes but in a non-standard sense then use the units found in the source but disambiguate by stating the exact number of bytes in brackets. Otherwise (and rarely) if some other units are used (like IEC) in the article due to being consistent with sources then disambiguate with JEDEC. ''']]''' 00:00, 18 January 2008 (UTC)
#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 ==
:: Or we forget it all for now and just make sure the guideline stays as it is in its stable state. ''']]''' 00:02, 18 January 2008 (UTC)
::: There is some confusion on binary versus decimal units of computer storage. However the computer industry and the technical press do not think is significant enough to change to a new units system. Fnagaton is very generous to say that the IEC prefixes have 0.5% acceptance. The industry treats kibi and gibi as ]. It is not Misplaced Pages's mission to promote a failing standardization effort. If the IEC binary prefixes gain significant support Misplaced Pages could consider using them. -- ] (]) 01:55, 18 January 2008 (UTC)
:::: Now that's one horrible misuse of a quote. Did you think it applies because the headline looks fitting? I suggest you actually read this policy. It's also not legit (and I don't need any policy to back this up) to use arbitrary made up numbers like "0.5%" in a discussion. --] (]) 22:03, 2 February 2008 (UTC)
::::: 0.5% is not arbitrary and is not "made up".
::::::{| class="wikitable"
|-
! '''Historical use''' search terms
! Results
|-
| kilobyte -wikipedia
| 1,940,000
|-
| megabyte -wikipedia
| 6,190,000
|-
| gigabyte -wikipedia
| 3,640,000
|}
::::::Total: 11,770,000
::::::{| class="wikitable"
|-
! '''IEC''' Search terms
! Results
|-
| kibibyte -wikipedia
| 28,800
|-
| mebibyte -wikipedia
| 17,100
|-
| gibibyte -wikipedia
| 19,000
|}
::::::Total: 64,900
::::::Consensus for historical use: 99.449%
::::::''']]''' 22:51, 2 February 2008 (UTC)
::::::: It's good that you explain how this figure was determined. This shows that the value is less than useless. Many results may to a certain extent show that something is widely known. The opposite is not true. Lack of results does not prove anything. Not to mention that this method is still arbitrary because it excludes the short forms which are far more common in my experience. Of course it's obvious that MiB has more meanings than Mebibyte and MB has also many meanings in different areas. Last but not least, this method excludes not only results from wikipedia or citing wikipedia, it excludes any kind of result which mentions or links wikipedia which may have nothing to do with this topic. --] (]) 00:15, 3 February 2008 (UTC)
:::::::: The preponderance of evidence shows that real world consensus is against your point of view. What evidence have you given in reply? Nothing, no evidence, you've just written waffle about "less than useless". The numbers are facts that do not support your point of view so you are wrong again because when you claim "it's less than useless" does not make it so. Misplaced Pages is excluded for the very good reason that a while ago someone made many hundreds of changes to use kibibyte etc and that means including Misplaced Pages would contaminate real world results. Also Wikiepedia is excluded from the results to show '''real world use'''. You also showed a search earlier on that did "-wikipedia", unless you now want to retract your earlier post? Trying to do a search for the much shorter versions like MiB ("Men in Black" for example) is also much more likely to pickup use of those three letters that has nothing to do with computers so your point is not well thought out because your proposal would have less much meaningful results. ''']]''' 01:07, 3 February 2008 (UTC)


'Phase 1' or Phase one'? This appears to be a case that's not explicitly covered.
:::: It is Misplaced Pages's mission to provide clear and accurate information to the general readership. If unit like MB is met, it is never obvious what quantity this represents. Usage depends on the context (e.g. disk, memory chip, data tranfer). Many people do not know which is used when, and even less what JEDEC is and if it applies to the particular occurrence of the unit. The solution is giving a conversion to a world standard. Even if that standard not often used, it is still well documented and unambiguous&mdash;just what is needed to eliminate uncertainty. &minus;] (]) 09:33, 18 January 2008 (UTC)
::::: Woodstone, as explained above what you see as "never obvious" is a red herring because what you call "the world standard" is not actually a "world standard" and it is not unambiguous. The real question is this, why advocate something that only has a tiny 0.5% support, i.e. doesn't have consensus? ''']]''' 12:04, 18 January 2008 (UTC)
:::::: No, the real question is: how can we inform the reader clearly and unambiguously about the meaning of quanties given. Just using MB does not do that, because its meaning is context dependent. So what device are you proposing to achieve the goal of being informative. &minus;] (]) 12:41, 18 January 2008 (UTC)
::::::: Like I said above, express the exact number of bytes as disambiguation in brackets. For example 2KB (2<sup>11</sup> bytes) is the only unambiguous way of stating the number of bytes without using neologisms and it also shows that in this case it is using the binary context. ''']]''' 13:27, 18 January 2008 (UTC)
:::::::: No, "2 KB (2^11 bytes)" is not unambiguous at all because there is always the possibility of mistakes. In this case, I'd assume the editor forgot the "i" and typed KB instead of KiB. Or worse, maybe someone added (2^11 bytes) because he assumed 2 KB was meant to mean 2048 when in reality it's really 2000. You might think it's "obvious" from the context, but context can only provide a rule of thumb. In many cases, the editor was just careless and typed "KB" instead of "kB". Many people don't know that SI prefixes are case-sensitive and that 'K' is incorrect as abbrevation for kilo (1000, one thousand). Thus, a chain of errors and "well-meant" edits can cause the following: 2000 bytes -> 2kB -> 2KB -> 2048 bytes. Same applies to "bits". Last but no least, this kind of hint reinforces the idea that KB absolutely means 1024. Sometimes less is more. If you think writing "(2^11 bytes)" is useful at all, why don't you drop the "2 KB" completely? It's not common practice in Misplaced Pages to write the same twice in different words. --] (]) 21:13, 2 February 2008 (UTC)
::::::::: You are incorrect because "2 KB (2^11 bytes)" is not ambiguous and because it expresses exactly the number of bytes that are used. You are also incorrect because your "what if there is a mistake" scenarios are also irrelevant red herrings because as already stated in the guideline "...one must be certain... before disambiguation" and trying to throw out using a particular unit just because someone might edit an article incorrectly is no valid reason at all. Taking your point of view that would mean nobody changing anything because there might be a mistake somewhere. Thus your "many people" point is also irrelevant because if someone is not certain then they shouldn't be editing on a topic they are not certain about. Also changing KB to KiB when in the uncertain "many people" scenario you use is also wrong because the person is not sure what they are doing and could change something incorrectly. Dropping the "2 KB" completely is also not correct since as I have posted before consistency with the terms used in the reliable sources relevant to the subject is important. You are also wrong because disambiguation, "writing the same twice in different words", is very common. ''']]''' 21:24, 2 February 2008 (UTC)
(unindent) That makes sense. Perhaps more recognisable would be to use only multiples of 3 for decimal and of 10 for binary powers:
* with decimal meaning: 64 MB (64&times;10<sup>6</sup>&nbsp;bytes)
* with binary meaning: 64 MB (64&times;2<sup>20</sup>&nbsp;bytes)
&minus;] (]) 16:15, 18 January 2008 (UTC)
: I really like the way this is heading, if it can be made to work. If there were such a guideline, I wonder whether it would actually be followed though. I think it is worth trying. ] (]) 16:30, 18 January 2008 (UTC)
:: Yes using 2 and 10 notation would make it completely unambiguous and it also gives a very good hint as to what format is used for binary or more rarely decimal. Also it lets articles use the type of units that are used in the sources. Which is a bonus since maintaining consistency with sources as well as following the real world consensus is a really important issue for me and I suspect many others think the same. Of course as with disambiguation it need not be everywhere, just so that the article makes sense. ''']]''' 17:00, 18 January 2008 (UTC)
::: The suggestion appears to have some merit. Note: powers of three in decimal, e.g. 10<sup>3x</sup>, means that everything is rounded in thousands; and powers of ten in binary, e.g. 2<sup>10x</sup>, means that everything is rounded in kilobytes (=1,024).] (]) 17:11, 18 January 2008 (UTC)
:::: I'm not sure how many readers wil be comfortable with this notation. In any case, I think what is being suggested is that for the binary meaning of the prefixes, it should be written as a power of 2, where the exponent is a multiple of 10. For the decimal meaning of the prefix, it should be written as a power of ten, where the exponent is a multiple of 3. --] (]) 17:28, 18 January 2008 (UTC)
:::::: I'm not sure whether Gerry Ashton's comment relates to my comment above, or an early one. My comment related to a question by Fnagaton which has since been edited, so it reads differently now & is no longer a question. My interpretation of Woodstone's comment, was a sequence of thousands & kilobytes, e.g 0.02*10<sup>3</sup>, 0.2*10<sup>3</sup>, 2.0*10<sup>3</sup>, 0.02*10<sup>6</sup>, 0.2*10<sup>6</sup>, 2*10<sup>6</sup>, etc, and a similar sequence for kilobytes (sorry I'm too lazy to do the binary sequence in kilobyte sequences). But if someone wants to see it?] (]) 17:43, 18 January 2008 (UTC)


The AP Stylebook recommends using figures for sequences in its section on "Numbers":
Yes, of course. Very simple: keep the number as it is (no rounding needed) and convert, depending on context:
"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.
* KB to &times;2<sup>10</sup> bytes or &times;10<sup>3</sup> bytes
* MB to &times;2<sup>20</sup> bytes or &times;10<sup>6</sup> bytes
* GB to &times;2<sup>30</sup> bytes or &times;10<sup>9</sup> bytes (etc)
Furthermore, it is not very important if all editors follow up on the guidelines. There will always be volunteers that will add proper conversion. Having it in the MOS will hopelfully prevent reversions. We still have to find a way out of the occasional MB = 1024,000 bytes. &minus;] (]) 18:03, 18 January 2008 (UTC)
: How about: "This memory stick from company X is labeled as 1MB (1024&times;10<sup>3</sup>bytes)" ''']]''' 18:09, 18 January 2008 (UTC)
:: How about: "This memory stick from company X is labelled as 1MB (2<sup>10</sup>&times;10<sup>3</sup>bytes)" ''' (not "*" as above). ''] ]'', 14:03 ] ] (GMT).
::: or "This memory stick from company X is labelled as 1 ] (1.024 million ]s)" ] (]) 14:10, 1 February 2008 (UTC)
:::: No. These are the worst options. In one regard it fails as soon as you get to a ] and especially beyond because US and European billion differ. The next higher magnitude which will be common in 2-4 years (tera respectively tebi) has no layman equivalent. If you write "1 MB (2^30 bytes)" any sensitive reader would assume that 1 MB is always exactly 2^30 bytes. There is no reason to assume a unit would differ depending on context. The solution is very simple, use units correctly or don't use them at all. If a unit has supposedly more than one meaning, it is by definition not a U-N-I-T. unit comes from unity. No unity, no unit. Kindergarten logic suffices. --] (]) 06:07, 2 February 2008 (UTC)
::::: You are wrong 217.87.122.179 because the units are de facto standards used in the real world and Misplaced Pages is descriptive not prescriptive. To use neologisms that are very rarely used in the real world (<1%) only confuses the matter even further. ''']]''' 09:53, 2 February 2008 (UTC)
:::::: He is right in so far that the IT industry’s adoption of metric prefixes, beginning 40 years or so ago, in a different than standardised sense is the root of the problem. Only that made ambiguity possible. Separate binary prefixes should have been developed back then, but they weren’t, leaving us with the mess.
:::::: You are right that Misplaced Pages is descriptive – in intention at least, by its importance and influence nowadays, being part of the real world, it is defacto quite prescriptive! –, but you are also wrong, because its style guide, unlike encyclopaedic information, has to be prescriptive to some degree. MOS may very well choose to adopt a rule by reason that would not have been derived from observing common usage. IT prefixes used to be such a case, where MOS editors came to the conclusion that it’s better to diverge from common and source usage, adopting an international public standard instead to make the project less ambiguous and more homogenous. Some months ago this changed (after epic-length, tiresome discussions), because some article authors, like you, didn’t like to adapt their habits. The descriptivism myth evolved.
:::::: You are also wrong in that you didn’t respond to any of the points the IP user raised; just called him wrong, repeating your weak arguments once again. He does have at least one very valid argument: “There is no reason to assume a unit would differ depending on context.” — ] ] 14:07, 2 February 2008 (UTC)
::::::: The IP user and you are wrong because it is fallacious to try to claim something is "different than standardised sense" just because a so called standards body decides to produce something contrary to what is the de facto standard. You are also wrong because the MOS is not prescriptive beyond what is actually common sense. You are also wrong because I did respond to the "points" the IP user raised, you will note this is the case since I wrote "because the units are..." giving a perfectly valid and correct reason. What you claim is the IP user's "valid argument" is actually shown to be a red herring by the very fact that the units have well known use. You are also wrong because the arguments put forward by me are stronger than what you have put forward and just because you disagree doesn't mean you are correct. Actually I'm giving you the benefit of the doubt here because you have put forward no such counter argument, instead you have attempted to question my motives and claimed a valid logical reason is somehow "repeating your weak arguments" without giving any supporting evidence. You are also wrong in your summary of the history of this topic and I demand that you retract your misrepresentation about what you think my motives are. ''']]''' 18:39, 2 February 2008 (UTC)
:::::::: You are reacting on trigger words again instead of reading carefully and responding adequately. First came decimal metric prefixes (which I wrote about), then came bits and bytes (and octets and words), then came binary “adaptation” of SI prefixes in IT – with the side effect of capital '']'' which I welcome –, then came disambiguity, then came IEC prefixes, then came Misplaced Pages. Where am I wrong here?
:::::::: There is no such thing as common sense, never use it as an argument. The MOS is not prescriptive in the sense that it would say people what to do, but it’s prescriptive in the sense that it says what articles should look like in the end. (And yes, it’s often watered down in that regard, which I consider a failure.)<!-- Once descriptive findings have been publsihed, they’ll be interpreted in a prescriptive way.-->
:::::::: The IP users said, a unit with multiple meanings was not a unit by definition. You say that (he’s wrong and) the units under discussion were being used with multiple meanings, trying to prove your but actually also proving his point. His definition can’t be ''wrong'', it just may not match yours.
:::::::: The (here logical, not empirical) expectations of the readership are quite the opposite of a “red herring” argument in a discussion about our style guide! If the prefixes, when applied to bits and bytes, always were used in a binary sense (and decimal everywhere else), your point might stand, but they ain’t, e.g. in rates (''kbit/s'' etc.).
:::::::: I tried to limit my response (after I couldn’t suppress it completely), because I think everything has been said on the matter, although people still come to different conclusions, because their views about the role of Misplaced Pages and its MOS differ. (You try, intensional or not, to devalue the other position by calling it ''prescriptive'' and ''neological'', which aren’t bad things per se, neither is ''de facto''.) If I agreed with your presuppositions I would probably come to the same conclusion, because I don’t contest most of the facts you bring up again and again, thinking or at least implying that this was what needs to be discussed when actually we disagree on a higher level, which makes your points irrelevant – ''weak'' probably was an inappropriate or misleading term.
:::::::: You’re in no position to ''demand'' anything from me (nor anyone else here), but, please, feel free to correct or at least discredit my summary, my view of the process.
:::::::: Gee, I wish there was anything besides carnival outside so I hadn’t felt the temper to engage in this again. — ] ] 01:24, 3 February 2008 (UTC)
::::::::: You are incorrect because you are at fault here for not "reading carefully and responding adequately" (as you put it). This is because you misrepresent what I write and you attempted to misrepresent my motives in your summary of the history of this topic when you wrote "because some article authors, '''like you''', '''didn’t like to adapt their habits'''". You are utterly wrong to try to misrepresent what you think are my motives. You are also wrong when you say there is no such thing as common sense because common sense is a large part of building consensus. Next we get onto you misrepresenting what I write. This is because I point out his "argument" (from 06:07, 2 February 2008 (UTC)) is a red herring and yet you insist on trying to rewrite my point to mean something else entirely. Just so you are perfectly clear, what you wrote is rubbish because I never wrote what you claimed I wrote. You are using a ], so your "point" is irrelevant and false. ''']]''' 02:01, 3 February 2008 (UTC)
:::::::::: I’m sorry it took me so long to respond, but I had much more important, non-WP things to do lately. Actually, I’m just taking a break from them.
:::::::::: So you think I misunderstood you or your motives. Maybe I did, big deal, happens all the time. You wouldn’t even have noticed if I hadn’t paraphrased what I understood and remembered (“misrepresent” you call it), just like I noticed your misreading. It doesn’t help, though, that you don’t explain where and how I misunderstood exactly. I assume it’s only about the ''changing habits'' part.
:::::::::: Nobody denies that ''kilo'', ''mega'' and ''giga'' (at least) with ''bit'' or ''byte'' are often being used and understood in a binary sense instead of their classic, metric decimal one. Nobody denies that this occasionally results in ambiguity (in any imaginable way). Nobody is happy with the situation, although many take it as a given. Nobody intends a unit (or prefix) to have more than one meaning, although in practice (i.e. your ''de facto'') occasionally one does. The IP user raises this point to a defining quality of a unit, you pragmatically don’t and call this (intentionally) irrelevant to the discussion (“]”). Am I right so far?
:::::::::: My main argument, which you ignored, still stands: We have different ideas of the purpose and foundations of this style manual. Therefore we ''cannot'' come to the same conclusion! So every argument is moot until we agree on the basic principles.
:::::::::: Whenever you claim the MoS was descriptive not prescriptive you are right and wrong at the same time, because a descriptive observation once published becomes a prescriptive rule in the understanding of many. This is how grammar and orthography “rules” came to be (for most natural languages).
:::::::::: Anyhow, a suggestion for compromise for the time being, although I would much prefer consensus in the long run:
:::::::::: ''SI prefixes are decimal and do not need disambiguation in general, but when applied to bits or bytes (incl. words and octets) without composition with any other units (as in rates, e.g. kbit/s) their meaning has to be disambiguated (one possibility is the replacement by <del>IEEE</del><ins>IEC</ins> prefixes, which are always binary), except for RAM chips when used with a ] based on a power of 2 where they take a binary default meaning and only need disambiguation when having a decimal meaning.'' — ] ] 19:36, 21 February 2008 (UTC)
::::::::::: I can see you are continuing to misrepresent me because I did not ignore your argument, your "argument" is fallacious for the reasons I have already given above and previously on this topic. Your compromise is not good because it does not represent real world consensus. Your "compromise" chooses IEEE which you prefer, which is not a compromise at all, it is pushing your own point of view. For example it is disingenuous to say "SI prefixes are decimal" and not mention the fact that the JEDEC defines K = 2<sup>10</sup>, M = 2<sup>20</sup> and G = 2<sup>30</sup> when being used for semiconductor storage capacity and also because recent legal rulings have stated that despite what SI/IEEE/IEC claim the de facto standard is different. RAM chips commonly use the units KB, MB, GB in the binary sense, for example and this is defined in the JEDEC standard. If you really want to get into the whole "orthography" argument then you're going to be refuting your own point of view because orthography is to use correct spelling according to what is considered to be accepted (i.e. generally approved) and established use. In this case orthography easily refutes using the -bi prefixes because it is obvious they are not accepted and established use. ''']]''' 08:42, 22 February 2008 (UTC)
:::::::::::: Gosh, either my English is worse than I thought or productive discussion with you (on this subject) is close to impossible.
:::::::::::: I don’t care whether we use IEC prefixes for disambiguation. I just want to limit ambiguity inside and among WP articles. (Ambiguity outside WP is outside the scope of this style manual.) To achieve this we can either
::::::::::::# adopt something with mutual exclusive meanings (e.g. SI and IEC prefixes, despite ambiguous usage outside WP),
::::::::::::# disambiguate (SI prefixes) inline each and every time or
::::::::::::# specify in MoS where we assume which default meaning (for SI prefixes), that wouldn’t have to be disambiguated, and where it’s too dubious to choose a default.
:::::::::::: The current guideline does nothing to achieve the goal, uses only partially the second option. My suggestion for compromise does the third, although I very much prefer the first. Maybe I set the requirements for a binary meaning of SI prefixes higher than you would like, but with preferred numbers in the field of semiconductor storage capacity most cases would still be covered to your satisfaction. I see no good solution for file sizes, though, because files can be stored on different media (binary or decimal) and can be transmitted (decimal). — ] ] 17:10, 22 February 2008 (UTC)
::::::::::::: I note your continued misrepresentation and use of weak personal attacks, this shows that you are not interested in valid debate. You are also wrong because the current guideline fixes what you think is ambiguous by encouraging the exact number of bytes to be specified in the disambiguation or in footnotes. For example "256&nbsp;KB&nbsp;(256&times;2<sup>10 </sup>bytes)".
::::::::::::: The first option "adopt something with mutual exclusive meanings" ignores real world consensus and makes articles inconsistent with their sources and actually doesn't solve the problem of using -bi units that can also be ambiguous.
::::::::::::: The second option "disambiguate (SI prefixes) inline each and every time" is not logical since the purpose of disambiguation is not to include brackets (or similar inline text) after every number in an article, it is usually the case that only the first occurrence of any such number needs disambiguation.
::::::::::::: The third option "specify in MoS where we assume..." is only going to get my support if it follows the real world consensus, i.e. not use -bi. Otherwise it is just going to be pushing point of view against consensus.
::::::::::::: The best option, which you don't list, is to use the terms found in the majority of reliable sources relevant to an article. This means internal consistency for articles over and above consistency for the whole of Misplaced Pages. ''']]''' 17:33, 22 February 2008 (UTC)
:::::::::::::: Like I said, the current guideline, if anything, uses the second option. It’s the worst! It being basically optional doesn‘t make it any better. ''256 KB'' would default to binary meaning by my proposed compromise (in the context of semiconductor storage at least) and thus would only have to be diambiguated if it had a decimal meaning instead.
:::::::::::::: I didn’t deny that the first option would only be internally consistent. Unlike you I don’t consider this a huge problem. I tried to point that out earlier. IEC prefixes are always binary and thus unambiguous, even if you should find someone using them wrongly.
:::::::::::::: Read it as “disambiguate (SI prefixes) in each and every article” if you must.
:::::::::::::: Real world consensus is that IEC prefixes are ''one way'' to achieve disambiguity where needed; the real world isn’t just very often unambiguous. For symbols the little ''i'' is probably the least cumbersome, least space-taking and – like it or not – most established solution. If you don’t like the terms “kibibyte” etc. – I don’t – you may use “binary kilobyte” or something like that where needed.
:::::::::::::: What you call a best (or fourth) option is not solving the problem at all, because it would mostly result in SI prefixes being used with varying meaning. Every reader would have to make a (hopefully educated) guess. My proposal was to provide a rule of thumb for that guess in the MoS. I already tried (without success) to discuss our different views of the scope for consistency. — ] ] 10:11, 11 March 2008 (UTC)
::::::::::::::: To tie this thread with the new thread this demonstrates why Crissov is still wrong for the same reasons as above. ''']]''' 19:13, 24 March 2008 (UTC)


Similarly, chapter 9 of The Chicago Manual of Style advises using figures when referring to a sequence.
:::::::: The IP user raises only one valid point, that even more confusion will arise when larger memory becomes available. In respect of (computer) memories, in the real world units do change depending on context - read the discussions above: a million can mean 1024 x 1000 and 1024 x 1024 depending whether is a megabyte of storage on a hard drive, memory stick, etc - go and look at amazon.com. The IP user appears to be confused, it is not misuse of units in wikipedia that causes problems it is inconsistent use of units in the computer industry that causes the problems. Misplaced Pages MOS is attempting to add clarity to the confusion that already exits.] (]) 19:52, 2 February 2008 (UTC)
::::::: I've changed my view upon reflection. The computer industry uses megabytes, Gigabytes, etc, the difference in UK and US definitions of a billion is irrelevant as it is unlikely that billion will be used as a description of the number of bytes.] (]) 20:20, 2 February 2008 (UTC)
:::::::: Indeed, that's what I meant when I said earlier the point put forward "is actually shown to be a red herring". It's like saying "the sky is blue and that proves that I'm right about cell meiosis". ''']]''' 20:35, 2 February 2008 (UTC)
*''That'' difference is irrelevant everywhere, except perhaps nursing homes in the UK. ] ] 23:28, 2 February 2008 (UTC)


I propose adding similar explicit advice to this section of the MOS.
: Maybe you don't know that "billion" is not only an English word. Billion is still frequently mistranslated as "billion" when it actually means 10^9 in one (European) language and 10^12 in the other like French or German. The UK might have adopted the US meaning by now, that's not true for any other country. You see it's almost the same issue as Megabyte vs. Megabyte. One is 10^6 and the other is 2^20. Keep in mind that this neither the American nor the British Misplaced Pages, it is an international effort. As there is no official authority for the English language, really nobody can decide which meaning of billion is correct but it is trivial to avoid these few well-known sources of confusion. --] (]) 00:00, 3 February 2008 (UTC)
::::::::: No, you didn't mean that. If you read carefully, the term billion was only a part of argument. Calling it a "red herring" makes clear that you assume bad faith, especially your "sky is blue..." blah blah shows that you are interested in facts or any kind of useful discussion. There actually over 120000 Google hits for '"billion bytes" -wikipedia'. I don't know which formula Pyrotec used to determine his assumed probability but I'd think we can all agree that this isn't the right place for speculation about the future. For the record, a billion bytes is in US-American English equivalent to a gigabyte, that's why it's already in use. I was talking about Terabyte (tera means 10^12) which is less common for now and which has no well-known -illion equivalent. So it'd be called 1000 billion or a million million but nobody knows what's the marketing industry is going to establish. Nonetheless "billion bytes" is actually used despite the assumed low probability. <small>—Preceding ] comment added by ] (]) 20:56, 2 February 2008 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->
:::::::::: Yes I did mean that so do not presume to tell me what you think I really meant because when you do so you are misrepresenting me and what I wrote. Also your incorrect accusation of "bad faith" shows you have not presented a valid argument because the term "red herring" is actually referring to the logical fallacy, which your "argument" is actually using. This is also pointed out by Pyrotec as being irrelevant. ''']]''' 21:08, 2 February 2008 (UTC)
::::::::::: Okay, then I'm relieved that I could help in making clear what you actually meant because it wasn't obvious at least to me. I don't quite agree with your presumed definition of red herring but discussing this would be another one and off-topic anyway. --] (]) 21:58, 2 February 2008 (UTC)
:::::::::::: ] also known as irrelevant thesis or conclusion. You'll see what I wrote is correct. ''']]''' 22:43, 2 February 2008 (UTC)


-- ] (]) 20:10, 19 October 2024 (UTC)
: Not taking either side, but the Google test is worthless. As is citing '''voluntary standards''' (as are the IEEE's, IEC's, and JEDEC's) as examples of "policy". Voluntary standards are just that, and it's hardly surprising you can find standards which reflect common usage. Consider:
*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)
:: - 24,300,000
*: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.
:: - 1,520,000
*: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.
:: - 26,000,000
*: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)
:: - 6,800,000
*::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)
:: - 11,200,000
*:::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)
:: - 8,240,000
*::::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)
:: - 3,420,000
*:::::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)
:: - 1,660,000
*::::::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)
: Can these results be used to argue that preference should always be given to imperial units of measure, since apparently more English-speaking people will be familiar with them? Can they be used to decide on a case-by-case basis which units are preferable? Can you say that common use is universally more important than standardization in every case or vice versa? No matter how you concoct the Google Test argument, it is always flawed.
*::::::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)
: Experience with Misplaced Pages should tell you that no amount of dialog on this will ever settle the issue wholly in favor of or against IEC prefixes. There's zero editorial direction on this site, and unfortunately the MOS as a whole is more or less a farce (used merely when it is convenient in an argument), so fights like this will keep breaking out. I strongly suggest you look for a middle ground where the use of IEC prefixes is accepted in some contexts and the common prefixes are accepted in others. Pages like the one on floppy disks really do need some concise method to deal with the prefix ambiguity, and the IEC prefixes are one such way.
*:::::::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)
: Basically, the way the MOS currently reads is the only way it can read. In reality there's no such thing as standardization on Misplaced Pages, so that argument won't work. The current reading explains the history of the debate, lays out the facts (common use versus ambiguity) and doesn't take any strong position. The only change that might be useful is provision for changing prefixes to IEC variants where appropriate and '''discussed beforehand'''. This excludes contentious ''en masse'' changes, but still acknowledges that there are some circumstances in which utilization of IEC binary prefixes might be useful. (maybe also remove the mention of the JEDEC, which is utterly comical since their standards have nothing at all to do with standard prefixes for unit measures)
*:::::::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)
: You will never convince each other. You will not be able to defeat the common usage argument. You will not be able to defeat the ambiguity argument. You will never end this debate by brow beating the same tired and cyclical arguments into one another. I humbly suggest just leaving the dead horse alone and letting the editorial ebb and flow take its course. Otherwise you're just wasting your own time in neverending trite rhetoric. -- ] (]) 20:27, 11 February 2008 (UTC)
*::::::::I agree, a small addition to MOS:NUMERAL might be a good thing. ] (]) 17:00, 23 October 2024 (UTC)
:: Unfortunately the IP user from Germany (not you 74.160.99.252) but the other user from 217.87.122.179 above (and their other IPs in that ISP range) decided that instead of trying dialog they would vandalise , several talk pages including mine and an admin. Eventually leading to several semi-protects and range blocks. The ambiguity argument has been refuted since it relies on the false premise "nobody uses -bi in other ways except binary" because it has been shown that -bi has been used in the decimal sense. ''']]''' 20:39, 11 February 2008 (UTC)
::: I'm pretty sure 74.160.99.252 is the same person you're talking about. --] (]) 21:28, 11 February 2008 (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)


== Quick NBSP question == == μs vs us ==


Which style I should use for micro seconds? Does μs "Do not use precomposed unit symbol characters"? ] (]) 04:44, 30 October 2024 (UTC)
Under the NBSP section, the MoS states "In compound items in which numerical and non-numerical elements are separated by a space, a non-breaking space (or hard space) is recommended to avoid the displacement of those elements at the end of a line." and as an example, gives "19&amp;nbsp;kg" as an example. My question is, if I wrote out "19" as "nineteen", would I still put a non-breaking space in-between the number and the unit of measure? In other words, which would be correct: "nineteen&amp;nbsp;kg" or "ninteen kg"? Thank you. ] (]) 16:38, 19 February 2008 (UTC)
:That (nineteen kg) would breach ]. Also, if you prefer {{t1|nowrap}} to nbsps, you can use that. ] (]) 16:42, 19 February 2008 (UTC)
::Better use "nineteen kilogram", with a normal space. Full numbers go with full names. &mminus;] (]) 17:52, 19 February 2008 (UTC)
::: In other words, irrespective of the non-breaking space (which I do not have a view on) use either "19 kg" or "nineteen kilograms". (surely not "nineteen kilogram" ?) ] (]) 17:55, 19 February 2008 (UTC)
::::A normal space in "nineteen kilograms" (plural) will be just fine—a line break between those words won't look awkward or be hard to read. ] (]) 03:43, 21 February 2008 (UTC)


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


== Day, date month format ==
I don't think the current wording makes that clear at all.


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)
Followup. Suppose you have "is ''C''<sub>p</sub> = 38.171 J mol<sup>−1</sup> K<sup>−1</sup> at"
*] 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==
Tell me:
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)
#Where you think the current MoS rule "recommends" non-breaking spaces. How many? All seven spaces? only some of them? Five? One? Three?
*] 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)
#Where this should logically be allowed to break.
*: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)
#Whether they are different.
*::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'd say our screwball rules, read literally, clearly call for one nbsp in this case (before the J)—and that one is precisely at the place where it is most logical to allow a line break.


] 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?
You may well think that the rules call for more than that. Explain where, and explain why that is so in terms of the current rule.


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.
Now, don't peek at the coding until you've answered the parts above, and I'll put in the nbsp which to me seem absolutely essential: "is ''C''<sub>p</sub>&nbsp;= 38.171 J&nbsp;mol<sup>−1</sup>&nbsp;K<sup>−1</sup> at ..." Well, maybe not absolutely essential: there is an alternative for two of them; you can use a centered dot instead, but it should not be the dot on the line used in the ] from which I borrowed this expression.


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)
Obviously, there are a lot of people writing these rules who are incapable of grasping anything more complicated than "19 kg" when it comes to measurements, who might be blissfully unaware that people do use much more complicated numbers and much more complicated units than that. Our rules used to call for a nonbreaking space only in that situation, between a number in numerals and a ''symbol'' for a unit of measurement (metrologists like to distinguish these "symbols" from ordinary "abbreviations", which unlike the symbols are usually language-dependent and might change in the plural be followed by a dot or be italicized and things like that).
*Why was it changed, without discussion, to even apply to spelled-out names of units of measurement in any case, whether they are preceded by a number in words or by a number in numerals?
*And why hasn't it ever been changed to recommend non-breaking spaces in the places where it really matters, such as within a number itself (e.g., 14&amp;nbsp;3/16 in) and within the symbols for a unit (which are '''not''' "numerical and non-numerical elements ... separated by a space"), such as the "J&amp;nbsp;mol<sup>−1</sup>&amp;nbsp;K<sup>−1</sup>" in my example. ] (]) 10:43, 28 February 2008 (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)
::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?==
Well, I don't know what the page said when you read it but my own extrapolated conclusion from the current page text and my personal point of view is that the whole formula should be prevented from wrapping. However the current page text recommends using {{tl|nowrap}} for the more complex cases which doesn't work in your case since your formula contains characters that is interpreted by the MediaWiki template engine. So I would instead use the new {{tl|nowrap begin}} + {{tl|nowrap end}}, like this:
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)
<pre>
"is {{nowrap begin}}''C''<sub>p</sub> = 38.171 J mol<sup>−1</sup> K<sup>−1</sup>{{nowrap end}} at"
</pre>


: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)
Which renders this:
: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==
"is {{nowrap begin}}''C''<sub>p</sub> = 38.171 J mol<sup>−1</sup> K<sup>−1</sup>{{nowrap end}} at"
{{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'''.
Neat, isn't it?


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.
You can read up on line wrapping at the brand new how-to guide ].


--] (]) 22:10, 12 March 2008 (UTC) {{nac}} ] (]) 22:02, 24 December 2024 (UTC)
}}
<!-- ] 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.
== Concern: commas and 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)
] (or any other section I'm aware of) does not clarify that commas '''have to''' be inserted for full dates which are wiki-linked. Example; a comma automatically appears in ] ] (] ]</nowiki> here], note that it does not for ] ] ] and February 14 2008). In other words, if the date is linked, the comma is visible to viewers even though it is not edited into the context. So, can someone see the logic in ? To me, this is like placing the |right| to an image which already has a mark-up like |frame| or |thumb| which sets the image to the right by default. My proposal — the guideline '''should say''' that a comma does not need to be inserted for a correctly linked date. Is this understandable? ] <small>(] • ])</small> 02:52, 5 March 2008 (UTC)
:What's the common usage in english? ] (]) 16:45, 16 November 2024 (UTC)
: See also ]. Some people still don't realize a comma is added in <nowiki>] ]</nowiki> (] ]), and removed in <nowiki>], ]</nowiki> (], ]), even for IP editing. The revert was based on a misunderstanding. ] 03:03, 5 March 2008 (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.
:: So you agree that these things should be mentioned in the guideline? ] <small>(] • ])</small> 03:08, 5 March 2008 (UTC)
::--] (]) 17:00, 16 November 2024 (UTC)
::: I can agree with saying a comma does not need to be inserted with the <nowiki>] ]</nowiki> format, but I'm less clear on recommending it. No comma seems to confuse editors. With <nowiki>], ]</nowiki>, I think the comma should be removed and not restored, since MediaWiki removes it anyway for viewing, but editing solely for this would be a trivial edit. ] 03:30, 5 March 2008 (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)
:The guideline doesn't say that is HAS to be added, but it also doesn't say it HAS to be removed. If the comma is optional, the guideline probably should note that, but I don't think that should be a justification to remove them. Does having the comma there cause any actual problems? If not, when doing ], ], why remove the comma? It seems like a personal editing preference, and not one that needs to be "corrected" unless there is an actual reason to do so. ] (]) 03:35, 5 March 2008 (UTC)
:We use meters over feet? Where?
::This argument is a bit pointless. When a complete date is wikilinked, it will always display correctly&mdash;for the American style the comma will be inserted where it is not present. The opposite applies for British style, where the comma is deleted if present. This applies also for unregistered users. But mention should be made of this somewhere to prevent unnecessary editing. I had a discussion about this before (]) and still have the test in my ] (if anyone's interested be sure to switch of dates preferences beforehand). ]] 04:07, 5 March 2008 (UTC)
:{{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)
:::It's just like the image sample I cited: why add |right| if |thumbnail|, |frame|, etc., already does the job? It's past redundant. Therefore, the guideline should make note of this. Do we have an agreement? Can this be indicated in the guideline now? ] <small>(] • ])</small> 04:17, 5 March 2008 (UTC)
::You get extra points for saying "US customary" and not "Imperial". 😉 ] (]) 18:20, 16 November 2024 (UTC)
::::I'd link to see an alternative way of formatting dates than using double brackets (<nowiki>]</nowiki>). The problem I see lies in there not being consensus on how dates should appear (American vs international), leading to a system where user preferences can be set to recognise and format all dates marked in a certain way. Fine, up to a point. However, in using the article linking mechanism, dates are being linked left right and centre, when there is no real reason to - many dates in articles have no great historical significance, and do not even warrant a mention in the linked date article. Nevertheless, there appear to be editors who spend most of their time manually making these links. This labour-intensive and overlinking to dates and years articles (just check their backlinks and you will see what I mean - there are well in excess of 20,000 articles ] alone), and the paranoïa apparently associated with it drives me nuts. ] (]) 05:15, 5 March 2008 (UTC)
:::{{smalldiv|1=imperial :3 ] (]) 18:30, 16 November 2024 (UTC)}}
:::::You're absolutely right. There should as well be a section on which layout is preferred. That'll be hard to decide, albeit there really isn't a standard preference, it'll have to be one or the other. ] <small>(] • ])</small> 05:34, 5 March 2008 (UTC)
:I agree with ], do not use "crore", use "millions". Misplaced Pages is for a worldwide audience. ] (]) 18:03, 16 November 2024 (UTC)
::::::What we should not be doing is what you did in your original post, Sesshomaru. Don't link February to the article on the month, link 14 (meant to be the day of the month) to article on the year AD 14 and 2008 to article on the year AD 2008. That's already covered in the MoS, isn't it?
::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)
::::::Our standard "look and feel" is the results we get from dates properly formatted for user preferences. There is no preference from among those options, if that's what you are talking about. It is best to enter it the way it appears, but the missing or extra comma we are talking about there won't make much difference in the results, and in not in itself reason to edit an article.
:Except we don't favor meters over feet — we use both. That's what the ] is for.
::::::Yes, the software will fix some of the problems even for users who are not logged in. I used to think, after the software started acting that way, that it no longer mattered if a linked-for-preferences date was linked as <nowiki>"], " or "], "</nowiki>, but if I recall correctly, somebody pointed out some case in which it does make a difference. But maybe I just imagined that, I cannot tell you what it would be. ] (]) 15:18, 5 March 2008 (UTC)
: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)
:::::::Not quite sure if you're upset or bothered by anything Gene. I was making a simple point about the comma in those samples. In any case, shall I update this page per discussion or are there any opposing? Seems to be legit. However, I'll refrain from mentioning how dates should appear, American vs international-wise, since that would require a separate section. Agreed by all parties? ] <small>(] • ])</small> 16:55, 5 March 2008 (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)
::::::::If I understand your point, and going by what you were edit-warring about, we most certainly should not be saying '''not''' to use commas on the edit page, in places where they would normally appear in what readers see on the article page. Why in the world are you even asking for that? ] (]) 17:51, 5 March 2008 (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)
:::::::::Edit warring? What in the world are you talking about? ] <small>(] • ])</small> 18:04, 5 March 2008 (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)
::::::::::Okay, I take that back; not edit-warring. It was just a first impression, when you were complaining about someone's reversion of your edit removing commas from the Month DD, Year format. I don't think you have any cause for complaint; we should not be running around removing the commas. That's the point I'm trying to get across. ] (]) 18:31, 5 March 2008 (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)
:::::::::::Compromise: how about having the guideline say something like, "''commas for the <nowiki>] ]</nowiki> format do not need to be inserted since they are visible even without them in the edit.''"? Implying '''not''' to use commas no matter the circumstance is a tiny bit irrational, I guess. This makes sense? ] <small>(] • ])</small> 18:52, 5 March 2008 (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)
::::::::::::Okay. I'll do the compromised edit to the guideline tommorrow. Any additional comments? ] <small>(] • ])</small> 06:04, 8 March 2008 (UTC)
:This RfC is clearly improperly formatted, ]; thank you to our unregistered friend for pointing this out.
(deindent) Make sure to note that just because they are not needed is no reason to run around removing them from existing articles. ] (]) 21:13, 10 March 2008 (UTC)
::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)
:I think I know why you're saying this. You don't want the commas removed in pages that you heavily edited, like ]? Can I ask why? If someone has enough spare time on their hands, I don't see why they should not run around and get the job done. It's optional. Thoughts? ] <small>(] • ])</small> 21:28, 10 March 2008 (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)
::I'd have thought the reason is obvious. Do ''you'' want to see your watchlist explode ?? ;-) ]] 21:34, 10 March 2008 (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)
:::You're right, I don't. I see no point to it. I find it rather annoying, as it isn't needed or useful at all. If people have time on their hands, I'd rather them do something that actually improves the articles rather than just do such an extremely meaningless edit. It would be one thing if removing the commas actually fixes anything, but it doesn't. Even tag and go is more useful than stripping out the commas. Its about as pointless an edit as one can get. And, as TinyMark notes, it is another watchlist addition that gets to be doubly annoying when someone comes along, is editing, noticing there are none, and feels they need to fix it. I also find the code looks very ugly without the commas and I think it would be very confusing to anyone who doesn't understand that the commas are not needed (a good chunk of editors, I'd suspect). Maybe I'm an anal web developer, but I seriously abhor ugly code :P ] (]) 21:51, 10 March 2008 (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)
::::I don't really think the layman will assume that a comma is missing (that's what the preview button is for). But I see both of your points. What about the dates in pages that already have no commas? Are you two suggesting that the commas should be inserted because the layman will think they are missing and will "explode" one's watchlst? ] <small>(] • ])</small> 22:10, 10 March 2008 (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.
:::::If any article is already without commas, then no need to insert either. So my basic position is, if they are there, leave them there, if they aren't, leave them out, though if a newbie editor comes alongs and adds them because they think they are missing, no need to yell either (though feel free to undo and explain). Its kind of like referencing, I guess. If a valid referencing style is already in heavy use (such as Harvard referencing), don't run through and completely redo to your preferred referencing style (maybe using templates). In the case of citation styles, ] includes language regarding that:
:::(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? ==
::::::"''Any style or system is acceptable on Misplaced Pages so long as articles are internally consistent. You should follow the style already established in an article, if it has one; where there is disagreement, the style or system used by the first editor to use one should be respected.''"
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 ==
:::::Perhaps something similar would work here? ] (]) 22:26, 10 March 2008 (UTC)


#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 guess that could work, but what about '']''? Some dates there have a comma, others do not. And if someone comes along and removes the commas while doing other good faith edits, like I did , one should not or undo only the removal of the commas, as that seems to be a case of ]. So can we integrate what I just said into the guideline as well? ] <small>(] • ])</small> 22:37, 10 March 2008 (UTC)
#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 ==
:For Death Note, if we use the citation guideline, then whichever was used first should be kept and the rest changed to match. As for the Star Ocean issue, well, as has already been noted, removing wasn't necessary. The list was created with them (first editor to use), and that shouldn't have been changed. Your other good faith edit (only one other thing) was put back. ] (]) 01:09, 11 March 2008 (UTC)


Are any of these formats correct?
::So how should it be written in the guideline? I know what to include, but don't know how to phrase it. Any thoughts or suggestions? ] <small>(] • ])</small> 01:18, 11 March 2008 (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)
:::I think a slight modification of the quote from cite, retooled to dates, would be fine. So something like: "''Commas are not required to be used in full format American dates. Their inclusion or exclusion is a stylistic and editorial preference. Either style is acceptable so long as articles are internally consistent. You should follow the method already established in an article, so that if the article has dates with commas, then the commas should be left alone and new dates added to the article should have commas. If the dates in the article do not have commas, then they should not be added to existing dates and new dates should not have them. Where there is disagreement or the article currently has a mix of commas and no commas, then the earliest format used should be respected and the article changed to be consistent with that format.''" ] (]) 20:02, 11 March 2008 (UTC)


:In answer to your first question I suggest choosing between "a 10 cm blade" and "a ten-centimetre blade".
::::Sounds great! I noted that the ''Death Note'' page first used commas, then some were removed. I shall correct this problem soon. Okay, go ahead and update the guideline, would you? ] <small>(] • ])</small> 20:08, 11 March 2008 (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)
: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 ==
:::::The page is currently edit protected, so before I put in an editprotected request, does anyone else want to comment on this? ] (]) 04:04, 12 March 2008 (UTC)


How did we come to this guidance?
::::::Go for it. Seems we have concluded. ] <small>(] • ])</small> 20:09, 12 March 2008 (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}}}}.
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)


: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)
:::::::Added. I wasn't completely sure where to put it, so I put it in the section on full date formatting. If someone feels it should be positioned differently, feel free to shift around.] (]) 17:57, 13 March 2008 (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:
This has not been thought through. It is not necessary or even useful to have a different standard for articles that pertain to American topics. If I am editing a section of an article on a clearly British topic to correct a misspelled word, and then also see a mess like <nowiki>"happened on the 14<sup>th</sup> of Sept ]"</nowiki>, I can simply change it to <nowiki>"happened on ] ]"</nowiki>. If I see this in a section of an article on a clearly American topic, I would, according to these new instructions. need to:
:::::::*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.
*get out of edit mode on that section.
:::::::*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.
*view or edit the entire article, examining it to see if there are any dates in either of 2 formats, <nowiki>], ] or ] ]</nowiki>.
:::::::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.
*if there are none, pick one format and use it for the mess I found.
:::::::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?
*if all other dates are in one of those 2 formats, use that format to fix the messy date.
*if there are several dates in each format, spend half the afternoon digging through the revision history trying to find the revision that first introduced one of these 2 formats, and use that format to fix the other dates that were added since, and the messy date.


:::::::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)
If this strikes anyone as an unrealistic burden to throw on the back of editors who are trying to clean up articles on American topics, I agree and sympathize with you completely. Before the manga edit skirmish began, we had 2 formats: <nowiki>], ] or ] ]</nowiki>, for west of the Atlantic and east of it. I feel that adding a 3rd format and encouraging its use (just because it is known that the software will fix it for general display) detracts from Misplaced Pages. I will remove that recommendation from the guideline. An agreement between two editors doesn't constitute much of a consensus. ] (]) 18:19, 19 March 2008 (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)
:No one is saying anything about adding a 3rd format. The article already says you can use <nowiki>], ] or ] ]</nowiki>. The paragraph just clarifies that people shouldn't go around removing all the commas in an article because the comma isn't needed, nor should they be added in, rather as with sources, stick with the method already in use in the article. ] (]) 18:35, 19 March 2008 (UTC)
::::::But is more readable as it was. ] (]) 18:01, 28 December 2024 (UTC)
::::::My choice would be all numeric: {{tq|The aircraft was carrying 62 passengers. Of those, 37 people were citizens of Azerbaijan, 16 of Russia, six of Kazakhstan, and 3 of Kyrgyzstan. 4 minors were on board.}} No mental context switch required between numeric and spelt out words within closely related sentences — which could easily be a combined: {{tq|The aircraft was carrying 62 passengers. Of those, 37 people were citizens of Azerbaijan, 16 of Russia, six of Kazakhstan, and 3 of Kyrgyzstan — 4 minors were on board.}} <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">]&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 ==
::Your statement is completely incorrect. Nowhere does the guideline say that <nowiki>] ]</nowiki> is an acceptable format. Please remove that paragraph or allow me to remove it again. ] (]) 20:40, 19 March 2008 (UTC)
:::It is shown in the table lower in the page. Personally, I agree, but as other editors have used this guideline to say commas are not required and have removed them (and not just the case noted here), something should be added to clarify. The paragraph is an attempt to do so. Do you have another suggestion for a better way to deal with it? ] (]) 20:46, 19 March 2008 (UTC)


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:
::::I think you will see that I am on your side if you read the discussion "Commas in linked dates" in Archive 94 of this talk page. Back then I was afraid that including <nowiki>"] ]"</nowiki> in the table would lead to some editors to think that it was an acceptable format, but there was an insistence on leaving it in to provide a complete list of formats that the autoformatting software could or could not handle. You have shown that my fears were justified. The omission of the comma has come up several times, but a consensus to allow dropping it has never been achieved. My last comment in that discussion clearly shows that I opposed editing just to remove a comma from the British-style dates, so I wholeheartedly oppose removing them from American-style dates. The removal of commas from the manga article was not only a waste of time for that editor and a waste of Misplaced Pages resources, but turned into a further burden on those taking part in discussions here. I kept getting beat up about that table and the green check marks and red X's. If you want to support adding a couple of red X's to that table instead of the 2 wimpy asterisks, maybe we can get this cleared up. ] (]) 21:55, 19 March 2008 (UTC)


# 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.
:::::That might be a good idea, and I could see it being cleaner than the paragraph addition. I'd support making it clearer for sure. ] (]) 22:22, 19 March 2008 (UTC)
# 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)
::::::What do you think of the green checks and red X's that were in the table ? Never mind that the legend below it is inaccurate in this version. Would something like this work to show what formats are acceptable? ] (]) 01:20, 20 March 2008 (UTC)


:::::::I think that would work. It makes it clearer what formats are acceptable and much easier to quick read. ] (]) 01:23, 20 March 2008 (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)
*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 ==
== Whose turf? ==


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!
People are making changes in MOSNUM issues at the main MoS page, changing the wording there with respect to spelling out of numbers (which numbers are spelled out, adding "end of a sentence" stuff, etc.), then coming here and claiming in their edit summaries that this is an issue which needs to be discussed THERE, rather than HERE where it belongs. Lets make that clear at ], and move the discussion here where it belongs. It is nonsense like that which leads to the inconsistencies in various MoS pages which some editors like to complain about. ] (]) 16:23, 6 March 2008 (UTC)


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: , , , , .
:Note in particular that they have conducted that discussion there, relative to this quintessential "numbers style" issue, at that different forum, without even having the decency to post a notice here—the appropriate forum for the discussion in the first place—that that discussion was taking place. Then they hae changed the guidelines ''not only'' on that ] page, but on this ] page as well, without ever having discussed it here. ] (]) 16:59, 6 March 2008 (UTC)


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)
::Calm down, please. I'm sure it was an oversight, rather than a deliberate slight. People will ask questions about it there, because the content is on the main MOS page, and people will answer there, and discussions will crop up there. The oversight is failing to either move it here or notify here, and there's no need for it to end up a big row, which your tone feels like it's heading towards. ](]) 17:46, 6 March 2008 (UTC)
*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.
:Yes the subject needs to be talked about here before changes are made to the page. ''']]''' 12:21, 7 March 2008 (UTC)
::::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 changes that have been objected to now were reversions of a ''previous'' undiscussed change. We need to discuss reversions of undiscussed changes now? It happens that it was discussed, somewhere else, but there was no forward motion in the change that was made and objected to, merely a reversion. ](]) 12:53, 7 March 2008 (UTC)
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"
:::I reverted the change that has the edit summary starting with "Revert; see WT:MOS; it doesn't need to be discussed at WT:MOSNUM...". It makes the assumption that changes don't need to be discussed here when actually they do. ''']]''' 13:06, 7 March 2008 (UTC)


! Organisation !! URL !! 00 or 01
::::Furthermore, it the edits by ] which were reverted here were themselves a reversion of an earlier undiscussed change of the longstanding "ten" to "nine" by ]. ] (]) 17:50, 7 March 2008 (UTC)
|-
| 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


|}
Talk of "jurisdiction" is off-topic wikilawyering; content is at both places, discussion was there, consensus was there, broader readership and input is there. ] (]) 12:39, 14 March 2008 (UTC)


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?
== Misleading and difficult to parse advice about dates ==


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.
The guidance says:
*''Full dates, and days and months, are normally autoformatted by inserting double square-brackets, as for linking.''


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 find that to be misleading and difficult to parse. It can be interpreted as requiring square brackets around solitary days and solitary months. People often quote the MOS as requiring links to solitary years (a user has just now made this claim on my talk page). It takes effort to explain that the MOS does not require that. I think that the phrase above needs changing. It also need supplementing by a specific statement that it does not require links to fragments such as centuries, years, months, days etc. ] (]) 09:35, 7 March 2008 (UTC)
:The present phrasing is indeed deplorable; but in rephrasing, we do need to say more than "no fragments". We do autoformat ]; whether this is a good idea is another question, which should be decided by another appeal to the developers, not here (because this page can't solve it). ] <small>]</small> 16:16, 8 March 2008 (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)
::I agree with both your sentences. With regard to your first sentence, you are right, we need strong simple sentences that mention specific fragments. We could build on the negative sections that are already there. Would anyone like to propose wording?


*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)
::In addition, we probably need a full time bot to tackle these fragments that sometimes are merely annoying and sometimes actually break autoformatting. ] (]) 21:38, 11 March 2008 (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)
:::Does anybody have any suggested wording? ] (]) 09:29, 13 March 2008 (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 ] ==
::::I have fixed some of the grammar of this new entry. I do think you should have put up a draft here first. This way, we can avoid points of view seeping into the text. ] (]) 13:52, 13 March 2008 (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)
:::::In the absence of objections, I have eliminated the misleading and difficult to parse text. Explanations of the nuances does not appear to be effective, even many experienced editors make errors because nobody checks all date links in all preference modes. I have attempted to make it simple and shorter so that confused users can be directed to a directly worded appropriate bullet point about what is '''not''' required. ] (]) 13:55, 13 March 2008 (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)


It is high time to end this . ] (]) 18:57, 9 January 2025 (UTC)
::::::I know what you have tried to do, I simply thought that you should have brought the text here for discussion before implementing it. There were no objections to the principle of rewording the text; but the text itself had not been discussed. Other editors should have seen the text first. As it is, it needs the fixes in situ. ] (]) 14:04, 13 March 2008 (UTC)


== Sorting of numerical data with mixed units ==
:::::::I take your point, it is well made. Sorry about that. ] (]) 14:11, 13 March 2008 (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)
== Uncertainty vs. repeating decimal ==


:Try this:
I have just edited the ] article because it used parentheses to indicate a repeating decimal. For example, it used "3.3(3) × 10−4 m" to mean that the rightmost 3 repeats forever. I changed it to read "3.<span style="text-decoration: overline">3</span> {{e|−4}}&nbsp;m" because this notation is also used for repeating decimals, and it will not be confused with uncertainty.
{|class="wikitable sortable"

!value!!name
An example of an expression of uncertainty is in Seidelmann's ''Explanatory Supplement to the Astronomical Almanac'' (1992, p. 693) where the Newtonian constant of gravitation is given as 6.67259&nbsp;(85)&nbsp;{{e|-11}}&nbsp;m<sup>3</sup>kg<sup>-1</sup>s<sup>-2</sup>. A longer expression for the same thing would be 6.67259&nbsp;{{e|-11}} ±0.00085&nbsp;{{e|-11}}&nbsp;m<sup>3</sup>kg<sup>-1</sup>s<sup>-m<sup>3</sup>kg<sup>-1</sup>s<sup>-2</sup>.

I believe this guildeline should have a section added to specify that repeating decimals are expressed with overbars, not parentheses, to avoid confusion with an expresion of uncertainty. I also believe that it should have a section recommending that uncertainty should be expressed with ± notation rather than parentheses because people unfamiliar with this notation would not know the order of magnitude of the uncertainty. That is, in the previous example, it isn't obvious whether the uncertainty is ±0.00085&nbsp;{{e|-11}}, ±0.000085&nbsp;{{e|-11}}, or ±0.0000085&nbsp;{{e|-11}}.
--] (]) 19:22, 8 March 2008 (UTC)

: Good point. looks like sensible advice to me. ] (]) 19:32, 8 March 2008 (UTC)
::±8.5&nbsp;{{e|-15}} may be easier to read, as long as we're recommending; but the deprecations should include a caveat: 3.3(3) × 10−4 m would be fine, if ''it were clear'' what was meant. ] <small>]</small> 21:40, 8 March 2008 (UTC)
::: advocates use of parentheses in this way. And that would be fine if it were clear to everyone, but that's a big ''if'' isn't it? ] (]) 21:50, 8 March 2008 (UTC)

*Note above that the plus-or-minus sign requires a space, and en dashes or minus signs are required, not hyphens. ] ] 00:51, 9 March 2008 (UTC)
**Disputed, as invisible nonsense. ] <small>]</small> 16:19, 10 March 2008 (UTC)
***Is it the span tag to create the overbar that you dispute? If so, do you have a solution to the ambiguity? --] (]) 19:36, 10 March 2008 (UTC)
****No, I dispute the ''mandatory'' space around ± (we should do what is clearest in the circumstances), and the ''mandatory'' use of a endash instead of a hyphen in an exponent, where the difference is invisible to the reader. ] <small>]</small> 22:47, 10 March 2008 (UTC)
****The substantive question of ambiguity should be dealt with by suggesting explanatory phrases at first use of any of these notations. Any of them will be clear to some readers and unknown to others. ] <small>]</small> 22:49, 10 March 2008 (UTC)
*****I still feel we should recommend different typography for uncertainty vs. repeating decimals, but I think PMAnderson's suggestion to use explanatory phrases near the first use is wise. Since this is a matter of typography, it would be particularly difficult for readers who don't understand the convention to think of keywords to search for in their favorite search engine. --] (]) 23:23, 10 March 2008 (UTC)

The problem with overlines for repeating digits is that there are at least two variants and both have their issues.
# Inline CSS: <code>0.1&lt;span style="text-decoration:overline">37&lt;/span></code> – 0.1<span style="text-decoration:overline">37</span>
# Unicode: <code>0.13̅7̅</code> = <code>0.13&amp;#x305;7&amp;#x305;</code> (U+0305) or <code>0.13̄7̄</code> = <code>0.13&amp;#x304;7&amp;#x304;</code> (U+0304) – 0.13̅7̅ or 0.13̄7̄
— ] ] 20:30, 13 March 2008 (UTC)
: The span approach displays properly on Windows XP, both Internet Explorer 7 and Firefox. The unicode approach does not display properly in either case; it displays as a square after the 3 and the 7. --] (]) 02:35, 14 March 2008 (UTC)
:: Yes, the problem with the Unicode approach is its state of support, but the CSS approach is more fundamentally flawed in that the style, which conveys the information, is lost in plain-text environments, such as copy and paste, text or non-CSS browsers, search engines. Using a different HTML element that, unlike <code>span</code>, has a default styling only helps in few of these cases. Years ago I used a non-combining overline (or macron) in front of the first digit to repeat: <code>0.1¯37</code> – 0.1¯37. It doesn’t look as good, but is ]. One could also imagine using brackets or braces instead of parentheses: 0.1 or 0.1{37}, but I think this would be a WP-specific convention, which we try to avoid. — ] ] 09:09, 14 March 2008 (UTC)
:::I've never seen a non-combining overline before; I didn't even know this character existed. I suspect few people would know how to enter it. I think it would be just as much a WP-only convention as square brackes or curly braces. --] (]) 00:30, 22 March 2008 (UTC)

== large ranges of numbers ==

I'm not sure how to format a range of large rounded numbers. An article I saw expressed the figure of 'twenty to thirty thousand' as "20-30 000"
Since commas and not spaces are supposed to be used in large numbers, I changed it to "20-30,000". However, to me it still doesn't look right. Can anyone confirm this is probably the best way, or suggest an alternative??
Thanks a lot, ] (]) 03:51, 12 March 2008 (UTC)

:When this is discussed in style guides, the normal decision is that you should not abbreviate the first number. If your intention is ''20 000 to 30 000'', have exactly that, or ''20 000 – 30 000'' with a spaced en dash (which unfortuantely might look like a minus sign!). Spacing is a separate matter, much discussed recently. If you do not use spaces between the digits of a number, you should use an unspaced en dash: ''20,000–30,000''. This is all sound advice generally, but others here may have different advice more finely attuned to Misplaced Pages.
:Note that even in words the meaning has to be clearly presented. If your meaning is ''20,000–30,000'', in some contexts your words (spoken or written!) may need to be ''twenty thousand to thirty thousand'', without any shortening. One such context:
:<blockquote>The ion-emission drive enabled the craft to accelerate from twenty thousand to thirty thousand miles per hour in one week.</blockquote>
:Without the first ''thousand'', the meaning would be ambiguous. Both interpretations would be realistic. To disambiguate the other way, you might even need to have this:
:<blockquote>The ion-emission drive enabled the craft to accelerate from twenty miles per hour to thirty thousand miles per hour in one week.</blockquote>
:No wonder we invented figures, and abbreviations. :)
:–<font color="blue"><sub><big><big>''']'''</big></big></sub><sup>¡ɐɔıʇǝo</sup>N<small>oetica!</small></font><sup>]</sup>– 05:36, 12 March 2008 (UTC)
::Thanks a lot for your help ] (]) 11:11, 17 March 2008 (UTC)

== Non-breaking spaces ==

In the current version of this MOS page there is a section called "Non-breaking spaces" that talks a little about how to handle line wrapping. We now have a detailed technical how-to guide about line wrap handling at ].

I would like that the section "Non-breaking spaces" of this MOS page in some way link to ]. Perhaps as a "see also" link at the top of that section?

--] (]) 22:36, 12 March 2008 (UTC)

:Since no one protested I boldly went ahead and added "''See also: ] and ]''" to the top of the "Non-breaking spaces" section.
:--] (]) 15:35, 13 March 2008 (UTC)

Why was this raised on this page rather than at ], which gets broader attention? ] (]) 12:36, 14 March 2008 (UTC)

:SandyGeorgia: Oh, I see you misunderstood what I was asking. With "this MOS page" I meant "this Manual of Style page", that is ] = "MOSNUM". I see that my way of writing it wasn't very clear, sorry. I wanted to add those links to THIS page.
:But anyway, ] also has such a section so I asked the exact same thing there. So I did raise the question on both affected pages. :))
:--] (]) 16:24, 14 March 2008 (UTC)

== Remove edit blocking please ==

The page has been blocked from editing since 6 March.

* Edit blocking of pages should only be used if there are many editors doing bad things. If there are only a few editors doing bad things, then the target should be those editors, not the page.

* Edit blocking should only remain in place if the bad things would still happen without it.

I do not see any justification for the edit block today. Please remove it. ] (]) 09:27, 13 March 2008 (UTC)

:That's a good suggestion, Lightmouse. Unfortunately, when the protection was applied it locked in an edit that made a guideline inconsistent with the corresponding guideline at ]. The protection explicitly does not aim to endorse or entrench that edit. Since the content of the edit was undiscussed and non-consensual, and contradicts ], reverting it would be a Good Thing. Don't be surprised if such a Good Thing happens, at the first opportunity.
:–<font color="blue"><sub><big><big>''']'''</big></big></sub><sup>¡ɐɔıʇǝo</sup>N<small>oetica!</small></font><sup>]</sup>– 09:58, 13 March 2008 (UTC)

::That would not surprise me at all. What surprises me is the edit block. ] (]) 10:27, 13 March 2008 (UTC)
:::Yes, I'm sure it raised more than a few eyebrows. We'll see. Let's just continue to act in good faith, with respect for discussion and consultation towards consensus.
:::–<font color="blue"><sub><big><big>''']'''</big></big></sub><sup>¡ɐɔıʇǝo</sup>N<small>oetica!</small></font><sup>]</sup>– 10:40, 13 March 2008 (UTC)
::::I agree with these calls for the block to be removed. It might have been appropriate for a few days to allow things to cool down, but it's unacceptable for a longer period. We need to agree here on a strategy to avoid the revert-wars. This need should not stand in the way of an immediate unblocking: the issues should probably go to arbitration while other ongoing issues are dealt with in MOSNUM. ] ] 12:22, 13 March 2008 (UTC)
:::::Even though I see no resolution in sight, I do think that we can all be civil here. Do not keep on reverting, discuss it here or ], otherwise I won't hesitate to protect this again. ] (]) 12:31, 13 March 2008 (UTC)
::::::Thanks Woody. In fact, the issue has been discussed extensively at ] recently. Any proposal for change to the version that had been in place for several months should indeed be raised there, or here if the proposer prefers.
::::::–<font color="blue"><sub><big><big>''']'''</big></big></sub><sup>¡ɐɔıʇǝo</sup>N<small>oetica!</small></font><sup>]</sup>– 10:08, 14 March 2008 (UTC)

== Ga, Ma, ka preferred to bya, mya, tya ==

] danced around the question, but never quite addressed the question of whether to discourage use of mya, focussing instead on discouraging MYA. Everyone seemed to prefer ka, Ma, Ga although there was some confusion over capitalization (SI usage for multipliers is quite unambiguous: k for kilo, M for mega, G for giga, T for tera, but it seems this wasn't universally grasped). Once archived, the discussion ended without addressing it. As phrased now, it leaves the impression that mya is an equally desirable choice to Ma, yet I don't believe that was the intention of those discussing the question. Reopen? ] (]) 07:40, 14 March 2008 (UTC)

:I prefer to spell it out in full as "million years ago" wherever it occurs in the article, and use Ma where abbreviation is necessary (e.g. in taxobox fossil ranges). I feel this looks smarter and saves people translating it in their heads each time they see it. I agree that mya is obsolete though. That said, I've not got a very firm opinion yet... '']''&nbsp;'''<small>]</small>''' 08:36, 14 March 2008 (UTC)
::My feeling from working with a number of geophysicists is that ''Ma'' is preferable, and I'm quite willing to agree to a prescription here that it should be preferred. I can't agree with Verisimilus that the whole three-word phrase should be trotted out many times in an article, unless used only twice or three times, perhaps: tedious to read. Besides, the fact of the abbreviation itself helps to focus the readers' minds. ] ] 08:47, 14 March 2008 (UTC)

The present text reads {{cquote|:*Abbreviations indicating long periods of time ago—such as '']'' (before present), as well as various ]-based units such as Ka (kiloannum) and kya (thousand years ago), Ma (megaannum) and ] (million years ago), and ] (gigaannum or billion years ago)—are given as full words and wikilinked on first occurrence.
::*'''BP:''' Do not convert other notations to BP unless you are certain of what you are doing. In some contexts the unit BP is actually defined as "years before 1950 CE/AD", not "years before the literal present", and the conversion may introduce an error if the date being converted is not a wide approximation (''18,000&nbsp;BP'') but a more narrow one or an actual known year. BP years are given as ''18,000&nbsp;BP'' or spelled out as ''18,000 years before present'' (not ''18,000&nbsp;YBP'', ''18,000 before present'', ''18,000 years before the present'', etc.)}}

I would suggest a change to read {{cquote|:*Abbreviations indicating long periods of time ago—such as '']'' (before present), as well as various ]-based units such as Ka (kiloannum), Ma (megaannum)and ] (gigaannum or billion years ago) are given as full words and wikilinked on first occurrence. Where older source quotations use the now-deprecated abbreviations ] (thousand years ago), ] (million years ago), or ] (billion years ago) this should be explained to the reader as in ''"a measured Libby radiocarbon date of 35.1&nbsp;]" (million years ago, 35.1&nbsp;] in modern usage) had to be calibrated against then newly available ] dating references in order to estimate a Cambridge standardized date of 30.2&nbsp;] ].''
::*'''BP:''' Do not convert other notations to BP unless you are certain of what you are doing. In some contexts the unit BP is actually defined as "years before ]", not "years before the literal present", and the conversion may introduce an error if the date being converted is not a wide approximation (''18,000&nbsp;BP'') but a more narrow one or an actual known year. BP years are given as ''18,000&nbsp;BP'' or spelled out as ''18,000 years before present'' (not ''18,000&nbsp;YBP'', ''18,000 before present'', ''18,000 years before the present'', etc.)
::*'''Caution''': Some source materials will indicate whether a date is calibrated or not simply by a change in capitalization. This is often a source of confusion for the unwary user. }}

Would something like this work for us? ] (]) 17:37, 14 March 2008 (UTC)

:Is it really necessary to wikilink each term if you've explained what it means? I find excessive links distracting. What more could a user want to know about "mya" than what it means? '']''&nbsp;'''<small>]</small>''' 18:18, 14 March 2008 (UTC)
::Fair enough. I had them each wikilinked to ] anyhow, the one time should be enough.] (]) 19:53, 14 March 2008 (UTC)

Now we have {{cquote|:*Abbreviations indicating long periods of time ago—such as '']'' (before present), as well as various ]-based units such as ka (kiloannum), Ma (megaannum) and Ga (gigaannum) are given as full words <s>and wikilinked</s> on first occurrence. Where older source quotations use the now-deprecated abbreviations ] (thousand years ago), ] (million years ago), or ] (billion years ago) this should be explained to the reader, as in ''"a measured Libby radiocarbon date of 35.1&nbsp;kya" (thousand years ago, or 35.1&nbsp;ka in modern usage) had to be calibrated against then newly available ] dating references in order to estimate a Cambridge standardized date of 30.2&nbsp;ka ] cal.''
::*'''BP:''' Do not convert other notations to BP unless you are certain of what you are doing. In some contexts the unit BP is actually defined as "years before ]", not "years before the literal present", and the conversion may introduce an error if the date being converted is not a wide approximation (''18,000&nbsp;BP'') but a more narrow one or an actual known year. BP years are given as ''18,000&nbsp;BP'' or spelled out as ''18,000 years before present'' (not ''18,000&nbsp;YBP'', ''18,000 before present'', ''18,000 years before the present'', or similar.)
::*'''Caution''': Some source materials will indicate whether a date is calibrated or not simply by a change in capitalization. This is often a source of confusion for the unwary user. }}

Absent further comment, I'll make the above change in a day or two.] (]) 18:10, 17 March 2008 (UTC)

:''emend'': strike "and wikilinked"; RC only gd 4 ¬50000a. --'']''&nbsp;'''<small>]</small>''' 19:56, 17 March 2008 (UTC)<sup>(no kb!)</sup>
::How on earth did I miss that??? Good catch!] (]) 21:56, 17 March 2008 (UTC)
{{checkmark}} Done. ] (]) 18:00, 18 March 2008 (UTC)

== <nowiki>{{delimitnum}}</nowiki> template ==

:''<u>Note that if this section becomes structurally complex, with many different sub-discussions and threads, I will, where necessary to avoid confusion, take the liberty of rearranging things here after-the-fact (after people have responded). However, I will do so in ways that makes it clear who was responding to what. I think this will be necessary to keep this topic organized and understandable</u>.''

I thought everyone would be interested to know that another of our regular editors, ] visited '']'' and saw all my cumbersome code (like <font color ="maroon"><code><nowiki>6.022<span style="margin-left:0.25em">464<span style="margin-left:0.25em">79</span></span>(30)&amp;nbsp;</nowiki></code>×<code><nowiki>&amp;nbsp;10<sup>23</sup>&amp;nbsp;kg</nowiki></code></font color>), which was all just for generating numbers like

{{cquote| {{delimitnum|6.02246479|30|23|kg}} }}

So he created a template, ], and now all editors need to code is <font color ="maroon"><code><nowiki>{{delimitnum|6.02246479|30|23|kg}}</nowiki></code></font> to accomplish the exact same thing. This is the issue many of us discussed ]. In a nutshell though, this template parses as follows:

'''<nowiki>{{ template name | significand–delimiting | uncertainty | base–ten exponent | unit symbol}}</nowiki>'''

The advantage of this template is twofold: values with long strings of digits to the right of the decimal marker will 1) now be delimited with thin gaps (so they are ''much'' easier to parse), and 2) the spaces aren’t characters so the values can be copied and pasted into programs like Excel, where they will be treated as true numbers.

The '']'' article (first paragraph) and '']'' (throughout, with 2&nbsp;kB of savings) have both been updated with this template.

What Zocky did is quite an accomplishment because other template authors said a function this complex couldn’t properly be done with a ] and really required a ] (]). Indeed, the effort was not at all trivial; Zocky invested a great deal of effort to get the template bug free. In fact, I created a special proof-checking sandbox ] to assist him in his effort.

As far as I know, it should be extraordinarily simple to convert articles that use Zocky’s template to one that uses the parser function once it becomes available; perhaps just a global search & replace to exchange a pipe (|) for a colon (:).

My main purpose here is to alert you all to this parallel effort (a template vs. a parser function) and to let you know it is now available for use. Perhaps now would be a good time to begin discussing a formal MOSNUM policy regarding the use of the template. I propose the following:<br><br>

::<hr/>
::Per ], numeric values <u>''must''</u> <span style="margin-left:0.15em"> have</span> the integer portions of their significand (the digits to the left of the decimal marker) delimited with commas and the decimal marker must be a ] (.), e.g. <b>1,234.567</b>. Further now, the use of the ] ]/] (]) is “encouraged” and is the “preferred” method for delimiting numeric strings with five or more digits in the fractional portion of the ] (the digits to the right of the decimal marker). The use of <nowiki>{{delimitnum}}</nowiki> delimits values like <b><font color ="maroon"><code>6.022461342</font color></code></b> so they have the following appearance: <b>6.022<span style="margin-left:0.25em">461<span style="margin-left:0.2em">342</span></b></b> (making them easier to parse) ''and'' simultaneously retains their functionality as ]-pasteable numeric values.<p><!--

-->In<sup>&nbsp;</sup>furtherance of this policy, the fractional portion of significands may <u>no longer</u> be delimited using either spaces or ]s (e.g. coding <b><font color ="maroon"><code>0.187&amp;nbsp;985&amp;nbsp;755</font color></code></b> or <b><font color ="maroon"><code>0.187 985 755</font color></code></b> to produce <b>0.187&nbsp;985&nbsp;755</b>) because such text strings can break at line-end ]s and/or are not treated as numeric values when pasted into Excel. Values such as these should be irreversibly “upgraded” via use of <nowiki>{{delimitnum}}</nowiki>. “Irreversibly” means that it is impermissible to convert a value that is delimited with <nowiki>{{delimitnum}}</nowiki> to a simple, non-delimited numeric string.<p><!--

-->Further,<sup>&nbsp;</sup>numeric equivalencies that can wrap between the value and its unit symbol (e.g. <b>75.2&nbsp;kg</b></b>), as well as numeric values expressed in scientific notation (e.g. <b>15.25&nbsp;×&nbsp;10<sup>6</sup></span></b>) that were neither created with the ] template nor unified with a non-breaking space and can therefore wrap on either side of its times symbol (×), should be “upgraded” via either 1) the use of ]s, 2) use of the ] template, or 3) use of ]—''exclusively so'' if the value has 5+ fractional-side digits.
::<hr/><br>

The effect of this proposed policy, if adopted, is that new editors who don’t know of the template/parser function or how to use it wouldn’t be doing anything “wrong” when they write “3,210.123456”. Existing, hand-entered values like this, which meet the proposed MOSNUM policy, would be considered as acceptable (though not ideal) and may be irreversibly upgraded. Articles like ], which 1) uses non-Excel-pasteable non-breaking spaces, and 2) also improperly leaves single dangling digits (like this example: '''0.187&nbsp;985&nbsp;755&nbsp;2'''), would formally be considered as “incorrect” and ''should'' be irreversibly upgraded.

] (''])'' 22:42, 14 March 2008 (UTC)

:I tried this out in the sandbox and the first attempt failed:
:*<nowiki>{{delimitnum|1234567.7654321| |12}}</nowiki>
:*with template functioning: {{delimitnum|1234567.7654321| |12}}
:*renders to me in IE7 like 1,234,567.765 4321 096 × 10<sup>12</sup> (with spurious 096 inserted)
:&minus;] (]) 22:47, 14 March 2008 (UTC)

:: There's a limit to significant digits and precision in WPs math magic words. The example in the documentation works with 13 digits, but too many digits will break the template:
::*<nowiki>{{delimitnum|1579800.2987281}}</nowiki>: {{delimitnum|1579800.2987281}}
::*<nowiki>{{delimitnum|1579800.29872801}}</nowiki>: {{delimitnum|1579800.29872801}}
::*<nowiki>{{delimitnum|0.2987281}}</nowiki>: {{delimitnum|0.2987281}}
::*<nowiki>{{delimitnum|0.29872801}}</nowiki>: {{delimitnum|0.29872801}}
::Woodstone's example has 14 digits. A different issue:
::*<nowiki>{{delimitnum|1.000001}}</nowiki>: {{delimitnum|1.000001}}
:: ] 23:00, 14 March 2008 (UTC)

::* Indeed. The template sometimes has problems beyond twelve digits—particularly if lots of them are in the integer portion of the signficand, which will be a rare occurance indeed. Still, it is a potential problem and certainly is a legitimate issue to discuss. This was a known inadequacy of the template-based method that was foreseen. Note however, that maybe 95% of the time, values will be a single digit in the integer portion and most of the digits will be in the fractinoal side. It could be that this might be enough of a problem that it can’t be considered as “ready for prime time.” However the '']'' is likely very representative of the kind of article that will be using this and has encountered no difficulties. ] (''])'' 23:21, 14 March 2008 (UTC)
:::: There is still a problem with a single digit in the integer portion: <nowiki>{{delimitnum|1.01}}</nowiki> = {{delimitnum|1.01}}, <nowiki>{{delimitnum|1.001}}</nowiki>: {{delimitnum|1.001}}. This can be fixed, though, as it's not a fundamental limitation (like 13-14 digits). ] 23:38, 14 March 2008 (UTC)

* I can see that the template may be too buggy. I noticed that while in preview mode while making my edits, all my examples were working fine but no longer worked after I saved the page. <strike>I believe what was occurring is that previous wonked-out examples (for instance, Woodstone’s examples weren’t parsed as he intended), and your 14-digit values left the template on the fritz.</strike> I can’t defend this behavior. As you can see from ], it worked great there. I don’t know whether to pull this proposal. Please see ], which really exersized the template (I think). ] (''])'' 23:27, 14 March 2008 (UTC)

* Clearly, given that there are still some problems with some values, I’m withdrawing my proposal that the template be formally made available for general use. Zocky and I both worked hard to proof-check the template and thought it had been thorougly wrung out. I can now see it wasn’t. I’ll continue to use it in ] as it works damn nicely there. However, I am rather expert in its use and pay particularly close attention to the numbers when I use the template. It clearly can't be put into the hands of general users until it can reliabily work with ≤12 digits. I know Zocky has put so much work in this too.

: Show below is what it ''does'' do rather well now (at least in "Show preview" mode. I’ll see how they look when I click “Save page” here…

'''NOTE: THE BELOW MAROON EXAMPLES USE A MONOSPACED <nowiki><code></nowiki> FONT. THERE ARE NO SPACES INSERTED BETWEEN BLANK VERTICAL SEPARATORS (|) OR “PIPES”''' (adviso added later by ] (''])'' 21:22, 15 March 2008 (UTC))

<font color ="maroon"><code><nowiki>{{delimitnum|12345.6789012}}</nowiki></code></font color> → {{delimitnum|12345.6789012}}<br>
<font color ="maroon"><code><nowiki>{{delimitnum|12345.6789012||12|}}</nowiki></code></font color> → {{delimitnum|12345.6789012||12|}}<br>
<font color ="maroon"><code><nowiki>{{delimitnum|12345.6789012||12|Hz}}</nowiki></code></font color> → {{delimitnum|12345.6789012||12|Hz}}<br>
<font color=maroon><code><nowiki>{{delimitnum|6.02214179|30|23|kg}}</nowiki></code></font color> → {{delimitnum|6.02214179|30|23|kg}}<br>
<font color=maroon><code><nowiki>{{delimitnum|1579800.298728}}</nowiki></code></font color> → {{delimitnum|1579800.298728}}<br>
<font color=maroon><code><nowiki>{{delimitnum|1.356392733||50|Hz}}</nowiki></code></font color> → {{delimitnum|1.356392733||50|Hz}}<br>
<font color=maroon><code><nowiki>{{delimitnum|0.45359237|||kg}}</nowiki></code></font color> → {{delimitnum|0.45359237|||kg}}<br>
<font color=maroon><code><nowiki>{{delimitnum|6.022461}}</nowiki></code></font color> → {{delimitnum|6.022461}}<br>
<font color=maroon><code><nowiki>{{delimitnum|6.0224613}}</nowiki></code></font color> → {{delimitnum|6.0224613}}<br>
<font color=maroon><code><nowiki>{{delimitnum|6.02246134}}</nowiki></code></font color> → {{delimitnum|6.02246134}}<br>
<font color=maroon><code><nowiki>{{delimitnum|6.022461342345}}</nowiki></code></font color> → {{delimitnum|6.022461342345}}<br>
<font color=maroon><code><nowiki>{{delimitnum|1579800.298728|||}}</nowiki></code></font color> → {{delimitnum|1579800.298728|||}}<br>
<font color=maroon><code><nowiki> {{frac|{{delimitnum|1.602176487||–19|}}}}</nowiki></code></font color> → {{frac|{{delimitnum|1.602176487||–19|}}}}<br>

:] (''])'' 23:51, 14 March 2008 (UTC)

Zocky, Here’s additional examples, most of which doesn’t work:

<font color=maroon><code><nowiki>{{delimitnum|1.01}}</nowiki></code></font color> → {{delimitnum|1.01}} (I note that no one would use this template to delimit a number that doesn’t need delimiting)<br>
<font color=maroon><code><nowiki>{{delimitnum|1.00001}}</nowiki></code></font color> → {{delimitnum|1.00001}}<br>
<font color=maroon><code><nowiki>{{delimitnum|1.10001}}</nowiki></code></font color> → {{delimitnum|1.10001}}<br>
<font color=maroon><code><nowiki>{{delimitnum|1.11001}}</nowiki></code></font color> → {{delimitnum|1.11001}}<br>
<font color=maroon><code><nowiki>{{delimitnum|1.11201}}</nowiki></code></font color> → {{delimitnum|1.11201}}<br>
<font color=maroon><code><nowiki>{{delimitnum|1.11231}}</nowiki></code></font color> → {{delimitnum|1.11231}}<br>
<font color=maroon><code><nowiki>{{delimitnum|1.11232}}</nowiki></code></font color> → {{delimitnum|1.11232}} (this one doesn’t end with a 1 and works)<br>
<font color=maroon><code><nowiki>{{delimitnum|0.29872801}}</nowiki></code></font color> → {{delimitnum|0.29872801}}<br>
<font color=maroon><code><nowiki>{{delimitnum|0.29872821}}</nowiki></code></font color> → {{delimitnum|0.29872821}} (this one doesn’t end with an 01 and does work)

] (''])'' 00:03, 15 March 2008 (UTC)

: OK, I thought just showing the problem with 1.01 would be enough illustration, but apparently not given the above examples. The problem can manifest itself in various ways with any group of three starting with a 0. It doesn't just happen with numbers ending in '1', and it's not just a symptom of numbers too short to delimit. ] 01:41, 15 March 2008 (UTC)
:<nowiki>{{delimitnum|1.0001}}</nowiki>: {{delimitnum|1.0001}}
:<nowiki>{{delimitnum|1.00001}}</nowiki>: {{delimitnum|1.00001}}
:<nowiki>{{delimitnum|1.00101}}</nowiki>: {{delimitnum|1.00101}}
:<nowiki>{{delimitnum|1.00102}}</nowiki>: {{delimitnum|1.00102}}
:<nowiki>{{delimitnum|1.000001}}</nowiki>: {{delimitnum|1.000001}}
:<nowiki>{{delimitnum|1.000002}}</nowiki>: {{delimitnum|1.000002}}

:* I understood that Gimmetrow. I appreciate that you’re in this with us trying to figure out its current limitations. Thanks. In my last example above, I made a it a point to show that a number that finally didn’t end with 01 would work. Clearly, it has a problem with anything ending in an 01. But the bugs don’t end there. I just added a over 200 new progressions to my test sandbox in a special section titled ]. Please check it out. You can see where it’s having problems and maybe that will guide you in other directions. As you will see there, I tried all 100 progressions that end with two-digit groupings from 00–99. I also added 100 progressions with three-digit groupings from 000–099. It shows that numbers ending with two-digit groupings like 25 or three-digit groupings like 026 can be a problem. The patterns are unobvious. Maybe someone who ''really'' understands templates can discern a pattern. ] (''])'' 02:47, 15 March 2008 (UTC)
::* One problem (the spurious 09x) is roundoff error in the math used to separate the digits. The other problems appear to be: two digit groups with "0" (07) are evaluated as 7 rather than 70 (so treated as a single digit), and a first group of 000 loses the decimal point. ] 02:59, 15 March 2008 (UTC)

:::* Thanks Gimmetrow. Hopefully all this will assist Zocky. That is, if he isn’t sick to death of this exceedingly complex template. Are you out there Zocky?<br><br><small>''*crickets chirping*''<br><br></small><p>Let me know if I can be of further assistance. ] (''])'' 04:17, 15 March 2008 (UTC)

::::I'm not very proficient with template magic, but may I suggest to do it character based instead of math based? That would avoid problems with number of digits and 01 being seen as 1, or groups of 000 being overlooked. It would place restrictions on the input, such as forbidden commas or spaces, but that would not be a problem in my view. &minus;] (]) 13:35, 15 March 2008 (UTC)
:::::Unfortunately, we can't make it character-based with a template, because we don't have the appropriate parser functions. I made a general template for this kind of spacing, {{tl|spaced}}, which can be used to space anything: {{spaced|2.333|342|2123|×|10<sup>23</sup>|kg|per|square|microfortnight}}. That's a good workaround for numbers that need more precision than parser functions can handle, but it's awkward, especially for the powers of ten.
:::::As for the bugs, the missing . is easy to fix, so I'll go and do that now. I'll also look into the other reported bug and get back to you. ] | ] 14:42, 15 March 2008 (UTC)
:::::I've fixed two more bugs - the missing leading 0 in 1.01, and the 099 additions that were caused by rounding errors in the parser functions. Any more problems? ] | ] 15:47, 15 March 2008 (UTC)

::::Starting to look good. My 14 digit example above works as well now. To even improve more on size of numbers, would it be an alternative to split the integer and mantissa part into separate arguments? So the template would be like <nowiki>{{formatnum|integer|mantissa|accuracy|exponent|unit}}</nowiki>. &minus;] (]) 17:22, 15 March 2008 (UTC)

:''(unindented)''

* All: I created an all new section of ] with all ] of <u>]</u>, ], and ] groupings. I was ''really'' tempted to just declare that this is good to go but knew we would have been making the judgment based largely on what we see in the sandbox. I knew better than that and added all possible combinations I can think of which might cause rounding errors. I’m glad I did too because two-digit groups following 5 thru 9 still suffer from rounding errors (with trailing “9”s). Three and four-digit groups are all good though! To see what I’m talking about, go to the two-digit groupings section (click the underlined “two” link, above), and search on the value&nbsp;<font color=maroon><code>0.12501</code></font color>. ] (''])'' 20:10, 15 March 2008 (UTC)<br><br>

* That was fast. All those have apparently been fixed. Please now search ] for all occurrences of these (in both maroon input values and the black output values):<p><!--

--><font color=maroon><code>0.125019</code></font color><br><!--
--><font color=maroon><code>0.125069</code></font color><br><!--
--><font color=maroon><code>0.125101</code></font color><br><!--
--><font color=maroon><code>0.125241</code></font color><br><!--
-->and<br><!--
--><font color=maroon><code>0.125569</code></font color><br><!--
--><font color=maroon><code>0.125597</code></font color><br><!--
--><font color=maroon><code>0.125601–0.125603</code></font color><br><!--
--><font color=maroon><code>0.125629–0.125631</code></font color><br><!--
--><font color=maroon><code>0.125735–0.125741</code></font color><p><!--

-->] (''])'' 21:52, 15 March 2008 (UTC)
===Section start===

{{delimitnum|100000.000001}}
===Section end===
the above result comes out of <nowiki>{{delimitnum|100000.000001}}</nowiki><br>
showing to me as 1.0E+5.000001

I had to insert a subsection here because this behaviour is very erratic. I have seen it only happening at the beginning of a section at the beginning of a line with nothing following. Probably not important, but you never know what is lurking behind. &minus;] (]) 21:56, 15 March 2008 (UTC)

:* It seems to randomly display as 100,000.000 half the time and as 1.0E+5.000 the other half for me (on Safari). ] (''])'' 05:25, 16 March 2008 (UTC)

* I created an Excel spreadsheet to help me identify breaks in the progression. Here is a more concise list:<p><!--

--><font color=maroon><code>0.125013</code></font color><br><!--
--><font color=maroon><code>0.125021</code></font color><br><!--
--><font color=maroon><code>0.125041</code></font color><br><!--
--><font color=maroon><code>0.125048</code></font color><br><!--
--><font color=maroon><code>0.125069</code></font color><br><!--
--><font color=maroon><code>0.125075</code></font color><br><!--
--><font color=maroon><code>0.125097</code></font color><br><!--
--><font color=maroon><code>0.125101–0.125104</code></font color><br><!--
--><font color=maroon><code>0.125124</code></font color><br><!--
--><font color=maroon><code>0.125131</code></font color><br><!--
--><font color=maroon><code>0.125153</code></font color><br><!--
--><font color=maroon><code>0.125186</code></font color><br><!--
--><font color=maroon><code>0.125208</code></font color><br><!--
--><font color=maroon><code>0.125214</code></font color><br><!--
--><font color=maroon><code>0.125236</code></font color><br><!--
--><font color=maroon><code>0.125241</code></font color><br><!--
--><font color=maroon><code>0.125263–0.125271</code></font color><br><!--
--><font color=maroon><code>0.125291</code></font color><br><!--
--><font color=maroon><code>0.125298</code></font color><br><!--
--><font color=maroon><code>0.125319</code></font color><br><!--
--><font color=maroon><code>0.125325</code></font color><br><!--
--><font color=maroon><code>0.125346</code></font color><br><!--

--><font color=maroon><code>0.125353</code></font color><br><!--
--><font color=maroon><code>0.125375–0.125381</code></font color><br><!--
--><font color=maroon><code>0.125402–0.125408</code></font color><br><!--
--><font color=maroon><code>0.125431–0.125436</code></font color><br><!--
--><font color=maroon><code>0.125457</code></font color><br><!--
--><font color=maroon><code>0.125485</code></font color><br><!--
--><font color=maroon><code>0.125492</code></font color><br><!--
--><font color=maroon><code>0.125513</code></font color><br><!--
--><font color=maroon><code>0.125520</code></font color><br><!--
--><font color=maroon><code>0.125541–0.125547</code></font color><br><!--
--><font color=maroon><code>0.125568</code></font color><br><!--
--><font color=maroon><code>0.125575</code></font color><br><!--
--><font color=maroon><code>0.125596–0.125603</code></font color><br><!--
--><font color=maroon><code>0.125624–0.125631</code></font color><p><!--

-->The list goes on but if this all gets fixed, I suspect everything after this will too. ] (''])'' 22:56, 15 March 2008 (UTC)<br><br>

* For convenience, I’ve here provided a triple-view of some of the above. They parse as follows:<p><!--
--><font color=maroon><code>input</code></font color> → live template return / (<font color=green>at time of this posting</font color>)<p><!--

--><font color=maroon><code>0.125402</code></font color> → {{delimitnum|0.125402}} / (<font color=green>0.125 402</font color>) {{unicode|✓}} The following are all supposed to end with three-digit groups<br><!--
--><font color=maroon><code>0.125403</code></font color> → {{delimitnum|0.125403}} / (<font color=green>0.125 402</font color>)<br><!--
--><font color=maroon><code>0.125404</code></font color> → {{delimitnum|0.125404}} / (<font color=green>0.125 403</font color>)<br><!--
--><font color=maroon><code>0.125405</code></font color> → {{delimitnum|0.125405}} / (<font color=green>0.125 404</font color>)<br><!--
--><font color=maroon><code>0.125406</code></font color> → {{delimitnum|0.125406}} / (<font color=green>0.125 405</font color>)<br><!--
--><font color=maroon><code>0.125407</code></font color> → {{delimitnum|0.125407}} / (<font color=green>0.125 407</font color>) {{unicode|✓}}<br><!--
--><font color=maroon><code>0.125408</code></font color> → {{delimitnum|0.125408}} / (<font color=green>0.125 407</font color>)<br><!--
--><font color=maroon><code>0.125431</code></font color> → {{delimitnum|0.125431}} / (<font color=green>0.125 43</font color>)<br><!--
--><font color=maroon><code>0.125432</code></font color> → {{delimitnum|0.125432}} / (<font color=green>0.125 431</font color>)<br><!--
--><font color=maroon><code>0.125433</code></font color> → {{delimitnum|0.125433}} / (<font color=green>0.125 433</font color>) {{unicode|✓}}<br><!--
--><font color=maroon><code>0.125434</code></font color> → {{delimitnum|0.125434}} / (<font color=green>0.125 433</font color>)<br><!--
--><font color=maroon><code>0.125435</code></font color> → {{delimitnum|0.125435}} / (<font color=green>0.125 434</font color>)<br><!--
--><font color=maroon><code>0.125436</code></font color> → {{delimitnum|0.125436}} / (<font color=green>0.125 436</font color>) {{unicode|✓}}<br><!--
--><font color=maroon><code>0.1235436</code></font color> → {{delimitnum|0.1235436}} / (<font color=green>0.123 543 599</font color>) This one is supposed to end with the four-digit group “5436”<br><!--
--><font color=maroon><code><nowiki>0.29872821</nowiki></code></font color> → {{delimitnum|0.29872821}} / (<font color=green>0.298 728 209</font color>) This one is supposed to end with the two-digit group “21”<p><!--

-->Most of this data was discovered at ] in the newly added section with ], which displays all possible variations of numbers ending in ], ], and ] groupings.<p><!--

-->] (''])'' 00:34, 16 March 2008 (UTC)

Greg, this looks very promising. Pleasing to see that the MOS requirements for the spacing of the × are observed by the template (although the + sign seems to be squashed, but is of course relatively uncommon). ] ] 02:08, 16 March 2008 (UTC)

:Thanks Tony. I’m not trying to be difficult, but what plus sign? ] (''])'' 03:01, 16 March 2008 (UTC)

My overall impression here is that the fundamental way of working in the template is too vulnerable. If so many special cases need to be distinguished and remedied, we can never be sure the output will be dependable. You never reacted to my suggestion above to split the integer and fractional part in the input to the template. So it would be like <nowiki>{{formatnum|integer|mantissa|accuracy|exponent|unit}}</nowiki>. With an example of use <nowiki>{{formatnum|1000|.0001}}</nowiki> (note the dot). This would allow easier manipulation of the fractional part and double the maximum number of digits. Also, as remarked by above by Tony, a leading explicit "+" sign should be maintained. &minus;] (]) 09:14, 17 March 2008 (UTC)

* Woodstone, I tend to agree with you; it doesn’t look very promising that anyone—even Zocky—can overcome the fundamental limitations of templates. Perhaps in the future, templates will have access to character-based parser functions. Unless Zocky pulls a rabbit out of the hat on this one, it seems the template-based version of <nowiki>{{delimitnum}}</nowiki> won’t be something that can be put into the hands of the general editing community. However, it will only be a short time before one of our behind-the-scenes developers delivers a ]-based ] by the same name. As it will use character-based (not math-based) delimiting, it is a ''much'' simpler process. I heard yesterday from the developer that the magic word is done but he isn’t happy with the look of the code. “Programmers,” you see; they like tight code.<br><br><!--

-->In response to your above statement: ''“Also, as remarked by above by Tony, a leading explicit "+" sign should be maintained”'', I assume you mean a default + sign should precede positive base-ten exponents (e.g. {{e|+9}}). I’m sure there are different ways to format scientific notation. However, the way it has been implemented here is a very common and exceedingly professional way to do it; both the NIST and BIPM, for instance, format scientific notation the exact same way (see and ). As you can see, both default to omitting the utterly unnecessary + sign in front of positive base-ten exponents. This reality is acknowledged in Misplaced Pages’s own '']'' and '']'' articles as well as the ] and ] templates. Coding <font color=maroon><code><nowiki>{{e|9}}}</nowiki></code></font color> and <font color=maroon><code><nowiki>{{subst:e|9}}</nowiki></code></font color> omits the preceding + sign and returns {{e|9}}. I note however, that the <nowiki>{{e}}</nowiki> template doesn’t properly add spaces on each side of the × sign (see the above-linked NIST site, as well as for examples of proper formating in this regard). This oversight was addressed with <nowiki>{{delimitnum}}</nowiki>, which takes care of delimiting both the integer and fractional sides of the significand, and handles uncertainty, and base-ten exponents, and the unit symbol. One-stop shopping for expressing numeric equivalencies.<br><br><!--

-->Don’t despair though, if a user ''really'' has a “thing” for the unnecessary + sign and doesn’t care if he or she is flouting the BIPM and NIST, they can always code <font color=maroon><code><nowiki>{{delimitnum|1.567892||+9|kg}}</nowiki></code></font color> to obtain {{delimitnum|1.567892||+9|kg}}, just as can currently be done with the existing <nowiki>{{e}}</nowiki> template. You can put ''anything'' in these templates, including {{delimitnum|2.468||] “]” ] 9|kg}}. In my opinion though, the practice of using the plus sign in front of positive exponents should be generally discouraged by official MOSNUM policy unless it is being used in Misplaced Pages articles on advanced mathematical concepts where the distinction must be emphasized for some reason.<br><br><!--

-->Note that every single aspect of this template was debated for a ''long'' time by many users—including Tony—here at ] and everyone was quite pleased with the proposal. It seems to me that ''that'' was the time for appearance issues like adding a + in front of positive exponents to be raised so all the others could weigh in on the subject. Does it strike either you or Tony that now is the time to try to change things <u>after</u> all that discussion has transpired (and after a near-unanimous consensus has already been achieved)? There were one or two things I might have changed after-the-fact on this template myself but I was disinclined to even head down that path since I am entrusted with shepherding the group’s consensus decision through to completion in good faith. ] (''])'' 17:10, 17 March 2008 (UTC)

:Actually I was referring to an explicit "+" for the whole number. Entering <nowiki>{{delimitnum|+123}}</nowiki> results in "123" without "+" sign. But I now realise the problem can be circumvented by entering <nowiki>+{{delimitnum|123}}</nowiki>. This trick should be added to the description of the template (whenever it comes to releasing it). &minus;] (]) 10:49, 18 March 2008 (UTC)

===Sandbox moved===
All: I moved the proof-checking sandbox to ]. ] (''])'' 23:06, 17 March 2008 (UTC)

===Deadly failure===
I think I found a deadly failure of this concept for the template (using arithetic for formatting). Look at:
* <code><nowiki>{{delimitnum|1.1200|25}}</nowiki></code>
* which should lead to 1.1200(25),
* but with current methods would come out like 1.12(25) (my hard coding)
* or from the current template as {{delimitnum|1.1200|25}} (for me now mysteriously looking like 1.012(25))
The problem is that in such cases the trailing zeroes are significant. Leaving them out changes the meaning of the accuracy indicator.<br>
&minus;] (]) 09:27, 19 March 2008 (UTC)

:* Thanks Woodstone. I’ll copy this to the top of the sandbox to ensure it is noticed. ] (''])'' 18:29, 20 March 2008 (UTC)

:* I posted it over on the sandbox. I doubt that a math-based template can do anything about this one. The upcoming character-based magic word should be able to properly digest it. But just to make sure this issue is dealt with, I notified the developer of the magic word than trailing zeros in the significand shouldn’t be truncated if the uncertainty pipe has a value in it. ] (''])'' 18:53, 20 March 2008 (UTC)
:::In my opinion, numbers should never be truncated. Just use whatever digits the editor supplies. &minus;] (]) 09:18, 24 March 2008 (UTC)

::*It's not impossible to overcome this type of thing with templates (look at {{tl|rnd}} for example) but if there's a magic word in the works, might we not just be happy to hold our breath? <span title="Representation in the International Phonetic Alphabet (IPA)" class="IPA">]]]]</span> 03:49, 24 March 2008 (UTC)

:::In template "rnd" this can be achieved because the number of digits is an explicit parameter. Requiring that in this case would make the template less usable.&minus;] (]) 09:18, 24 March 2008 (UTC)

== Trials and disambiguations ==

Opinions are invited on how best to disambiguate the megabyte at ]. I would like to avoid an unnecessary strand, so please reply directly on the ] and not here. Thanks. ] (]) 17:31, 16 March 2008 (UTC)

== proposed change to wording of "Binary prefix" ==

The text reads

*There is no consensus to use the newer IEC-recommended prefixes in Misplaced Pages articles to represent binary units. There is consensus that editors should not change prefixes from one style to the other, especially if there is uncertainty as to which term is appropriate within the context—one must be ''certain'' whether "100&nbsp;GB" means binary not decimal units in the material at hand before disambiguation. When this is certain the use of parentheses for binary prefixes, for example "256&nbsp;KB&nbsp;(256&times;2<sup>10 </sup>bytes)", is acceptable, as is the use of footnotes to disambiguate prefixes. Use of IEC prefixes is also acceptable for disambiguation (256 ]). When in doubt, stay with established usage in the article, and follow the lead of the first major contributor. Prefixes in directly quoted passages are never changed; if explanation is necessary, use a more exact measurement in square brackets.

The way I read it there was never an intention to imply one form of disambiguation was preferred over the other, but it can be interpreted that way. To make this clear I propose changing the words "Use of IEC prefixes is also acceptable for disambiguation (256 ])" to "Use of IEC prefixes is equally acceptable for disambiguation (256 ])". ] (]) 07:35, 18 March 2008 (UTC)

:I disagree. The intention of the discussions when the guideline was updated was to specifically state there is no consensus to use IEC prefixes and that is what it says. There isn't any confusion because it does mention "disambiguation". Actually I think IEC prefixes should not be supported at all in MOSNUM and the bit which says "Use of IEC prefixes is also acceptable for disambiguation" should be removed because it is pushing a failed standard and because stating the exact number of bytes is perfectly good for disambiguation or footnotes without needing extra options. ''']]''' 09:54, 18 March 2008 (UTC)

:I second Fnagton. Misplaced Pages should reflect real world usage, not try to enforce a failed push for change of standards. Likewise, the current wording was specifically crafted to allow for people who want to use IEC notation in newer articles to do so, while protecting articles whose notation is not IEC. It was IEC notation that was given undue weight in the recent past, which is what lead to the current wording - which was done by consensus I might add. --] (]) 15:25, 18 March 2008 (UTC)

:: Yes there was consensus for the present wording, but what I am questioning is the interpretation. Was there a consensus to deprecate use of the IEC prefixes? I see no evidence of such a consensus. What happened is this:
::*On 26 January Fnagaton made , citing a ] for justification. As best I recall, the discussion in question centred around a way to disambiguate the megabyte by means of exact numbers of bytes. There was consensus (which I supported) to permit this kind of disambiguation but no consensus to prefer it over the use of IEC prefixes. I therefore followed Fnagaton's change by that use of KiB, MiB etc was also acceptable.
::I did not interpret the words then to imply that either one is preferred - if I had done I would have made a case at the time for giving the two options equal weight. That is what I am doing now because I see ''now'' that the words are being interpreted in this way. ] (]) 17:08, 18 March 2008 (UTC)

:: I second Thunderbird2. I see no reason that IEC Binary Prefixes (Ki, Mi, etc) should be deprecated and IMO the short length of IEC Binary Prefixes makes them preferred to other forms of disambiguation (i.e., MiB is better than either 1,048,576 bytes or 2<sup>20</sup> bytes) ] (]) 17:40, 18 March 2008 (UTC)

::: Using MiB is not better than 2<sup>20</sup> because MiB can be ambiguous (this has been shown before) and it is pushing a term which has very limited use in the real world. Thunderbird, the "There is no consensus to use the newer IEC-recommended prefixes in Misplaced Pages articles to represent binary units" comes from previous discussions when the guideline was last changed and this can be found in the talk page history. Changing the guideline to say "is equally acceptable" goes against the spirit of what was discussed at the time because the consensus is leaning away from using IEC prefixes. If you look at the guideline from about two years ago you'll see it is very pro -bi prefixes, now it is not because a small minority of people were making thousands of robot like changes to convert all prefixes to binary IEC prefixes and this really annoyed a lot of people. ''']]''' 17:51, 18 March 2008 (UTC)

* Thunderbird’s proposal to disambiguate by means of a footnote () makes a lot of sense to me. I note too that his proposal was acceptable to Fnagaton at that time. Has something changed since then? As I stated earlier, representing a unit of measure using symbols that aren’t generally recognized by an article’s readership is no good at all. IMO, the original MOSNUM policy on this issue was in error and far too rapidly embraced—or at least accommodated—the IEC proposal because of its perceived merits. That was unwise. Misplaced Pages, vis-a-vis MOSNUM, should have waited to see if the practice was adopted by at least one influential computer magazine before taking up the cause too. It is not uncommon for otherwise meritorious proposals by influential organizations like the IEC to When that happens, early adopters find themselves out in the snow all by themselves, waving the ] banner.<p>It is generally recognized that transistorized memory like RAM is always measured in binary units. There is no need to use unit symbols that are unfamiliar to a knowledgeable reader for RAM, nor is there even a need to disambiguate. Thunderbird’s proposal is appealing to me because hard drives are a different matter; they’re huge cesspools of mechanical storage and the manufacturer broke away from binary math in their “horsepower race.” It is articles on hard drives, for instance, that could benefit from disambiguation. Thunderbird’s proposal accomplishes that end, and further, doesn’t rely on the use of unfamiliar symbols that readers never encountered before until they land on Misplaced Pages. ] (''])'' 19:11, 18 March 2008 (UTC)

::For the record, it is an urban myth that HDD manufacturers broke away from binary math in their “horsepower race.” The evidence is that HDD manufacturers always used M in its common decimal meaning. ] (]) 19:42, 18 March 2008 (UTC)

:Using a footnote is fine as long as the footnote does not use the IEC prefixes because those prefixes can be ambiguous for example and also because it introduces prefixes that are not widely used in the real world. Having the footnote specify the exact number of bytes, in power notation if brevity is needed, is fine by me. I actually prefer power notation for disambiguation or footnotes because the powers give a very good example if it is decimal or binary. ''']]''' 19:30, 18 March 2008 (UTC)

::* Which is what his proposal does, yes? He suggested the following for disambiguation (I took the liberty of changing his example of “SCSI transfer speeds” to “hard drive storage”):

::::* when applied to computer memory (RAM or cache) the quantities KB, MB and GB are defined as
::::**1 KB = 1024 B
::::**1 MB = 1024 KB
::::**1 GB = 1024 MB

::::* when applied to data transfer the quantities KB and MB are defined as
::::**1 KB = 1000 B
::::**1 MB = 1000 KB

:::I know that T-bird still embraces the use of Kib, but at least the above seems to currently satisfy everyone. I like it because it 1) doesn’t use symbols that aren’t widely recognized, 2) clarifies ambiguity, and 3) does so as a footnote and therefore doesn’t clutter the meat of the article. Good, yes? ] (''])'' 19:51, 18 March 2008 (UTC)

::::Apart from propsing that the text is changed to say "Use of IEC prefixes is equally acceptable" which I don't support. IEC prefixes should not be pushed into being used when they are not used by the sources relevant to an article. Which is why I propose removing any mention of the IEC prefixes for disambiguation. ''']]''' 20:24, 18 March 2008 (UTC)

::I suggest 2<sup>20</sup>B is just as unknown to many users as MiB. I also challenge that there is any ambiguity about IEC Decimal Prefixes, unknown to some, perhaps, but ambiguous - how? Rather than a footnote, I think an inline link might be the best solution to disambiguation, something like 256 "MB" (]) where disambiguation is necessary. ] (]) 19:42, 18 March 2008 (UTC)

::: That's not accurate because 2<sup>20</sup> is better understood since raising one number to the power of another number is mathematical in nature. The -bi prefixes can be ambiguous because it has been shown how some people in the real world have used them in the decimal sense. Using numbers to express the number of bytes is less ambiguous than using the IEC prefixes. Since reducing ambiguity is the stated aim of some here then that logically means '''not using''' IEC prefixes '''and instead''' stating the number of bytes. ''']]''' 20:16, 18 March 2008 (UTC)
:::: Just because someone has used some term wrongly once doesn’t make it ambiguous. SI prefixes became ambiguous for bits and bytes, because many people used them wrongly, which eventually was standardized later (by other organisations of course).
:::: Like pretty much everything else, I’ve said that in the currently first section of this page already. Anyhow, I’ll repeat (and slightly modify) my suggestion:
:::: Say in MOSNUM that binary meaning of SI-like prefixes is the default for bits, bytes and words in – list perhaps incomplete: – semiconductor storage and file sizes, decimal meaning is the default for other storage (e.g. magnetic and optical) as well as speeds, otherwise it’s ambiguous. In deviating cases (e.g. decimal RAM, binary rates) disambiguation is needed. IEC prefixes are one way of disambiguation. IEC symbols are unproblematic (just an added ''i'' and best accepted in “real world”), but ''binary kilobyte'' is preferred to ''kibibyte'' in prose, thus it can also be contrasted with ''decimal kilobyte''.
:::: Overall make the section more general on disambiguation needs, which are mentioned in the parent section. — ] ] 23:29, 18 March 2008 (UTC)

::::: "Happen once"? Well that's a gross understatement. The -bi prefixes can be ambiguous, fact. Disambiguation using IEC prefixes is not needed because the IEC prefixes can be ambiguous and there are other methods that are more accurate. For example, the only completely non-ambiguous way to disambiguate is to state the number of bytes either in full or using power notation. ''']]''' 00:10, 19 March 2008 (UTC)

:::::: You haven't provided any actual examples of such occurences, nor provided any indication that they are common enough to actually be an issue of any kind. It would probably also be a good idea to demonstrate that raw numbers of bytes (which take some mental gymnastics for most readers, including myself, to convert into something they can make sense of) are easier to understand than an unambiguous term linked directly to a definition of that term. — ] ]/] 01:57, 19 March 2008 (UTC)

::::::: "''You haven't provided any actual examples of such occurences''" - Yes I , so you are wrong. As for "being an issue" it is up to you to show that what you think are issues with kilobyte are enough to warrant needing to use -bi prefixes and you have not done so. The -bi prefixes can be ambiguous, that is a fact. So stop pushing for those prefixes to be used when there already exist better methods to disambiguate. ''']]''' 10:56, 19 March 2008 (UTC)

::* Tom, the IEC’s proposal makes rational sense. But if readers of computer magazines and computer Web pages have never encountered a term before, we are subverting the very purpose of Misplaced Pages when we use unfamiliar language: to effectively and clearly present information to the reader with minimum confusion. Representing units of measure using symbols that many readers have never encountered before until they land on Misplaced Pages is a poor practice that has been measured at 2.6&nbsp;]. It should therefore be avoided in my opinion. ] (''])'' 20:10, 18 March 2008 (UTC)

It never fails to amuse me to see well-meaning but misguided people thinking that they are too smart to use standards that someone else wrote. ] should not be regarded as a thing we want in WP. If you really think the standard is broken, get involved with the standards track, don`t hide out on WP and snipe at it. There`s no reason we can`t use the standard. The fact that some readers will encounter new information while reading a WP article should hardly frighten us, that`s what they are here for. Just wikilink the first usage of the unit and move on.] (]) 05:05, 19 March 2008 (UTC)

:Well that's a silly thing to write since Misplaced Pages does not blindly follow the standards organisations and instead usually makes the wise choice that it follows the real world consensus. ''']]''' 10:52, 19 March 2008 (UTC)
::I'll assume that was intended as ] and move on. The above discussion can hardly be construed as "blindly follow" the standard: it is a reasonable, informed debate. It is not, however, remotely close to the years of discussion that go into crafting an ]. Having worked as editor on a number of other ] standards (1109, 1154 and others), I can attest that every word of them is subject to sweat, debate, compromise, and bargaining by people who are constantly trading off in their minds the interest of the standard against the interest of their employers in having a viable competitive position. The tension in that process works to make the standard the best that can actually be implemented. None of it is just casually tossed off.
::The JEDEC standard already makes provisions for the imprecise popular usage, we can use those provisions. Nothing I've seen here or elsewhere suggests a substantive difficulty in using the standard, simply reluctance to adopt precise language in a large number of articles, leading to a lack of concensus. That's something that has been addressed many times before on WP, it can be done again. Can anyone point out a specific case where the standard ''cannot'' work? ] (]) 15:32, 19 March 2008 (UTC)

:::You did just try to insinuate editors here are "misguided people" with your "05:05, 19 March 2008" comment, so look at your own comment for not being civil. Your summary of what is going on here is entirely wrong because it isn't "misguided people thinking that they are too smart to use standards that someone else wrote" (which is another slur from you) and isn't a case of "not invented here". You then try to use the fallacious point about getting involved with the sdtandards process. That is why your comment is silly. The effort that goes into creating standards has nothing to do with the topic. The -bi prefixes are not as precise as stating the exact number of bytes because the -bi prefixes can be ambiguous. When a "standard" is made and after ten years the majority of the real world still ignores it ipso facto the standard has failed. The "standard" doesn't work because it has only gained very limited use in the real world, therefore pushing for it to be used in Misplaced Pages goes against what Misplaced Pages is about. That is your substantive reason where the "IEC/SI standard" cannot work and that is why the "IEC/SI standard" cannot be used here. ''']]''' 16:16, 19 March 2008 (UTC)
::::I could have been clearer in my phrasing. I should perhaps have chosen "well intentioned people engaged in a misguided effort"". It's spilt milk now. We all do it at times, that's why it's amusing. It's a simple human foible. I still contend that it is ''precisely'' a case of ]. What's going on is an attempt to create an alternative standard to serve the same function as an existing one. I'll not address the question of whether that is a worthy goal, I just contend that if the effort is to be pursued, WP isn't the place for it. This isn't ''wikitechnicalstandardsdevelopmentforum''. Just adopt an extant, unambiguous standard and I'll be content - I'm not particularly fond of this one, but I still haven't seen an example of a case where it ''cannot'' be made to work. Got an article as an example?] (]) 17:59, 19 March 2008 (UTC)

:::::Well you are wrong becaise it is not a case of "not invented here" for me because it has always been my position that Misplaced Pages follow the example given by the majority of reliable sources relevant to the topic. Do not try to second guess my motives. It is not about creating another standard because it is about following the example set by those that supply the reliable sources that each article is attached to. The IEC/SI prefixes are not unambiguous by the way and that is a fallacious argument. The only unambiguous standard is to explicitly state the exact number of bytes using power notation if brevity is required. The example of where it cannot work has already been given in my previous comments above. As for a specifc article that is irrelevant because the reasons I gave in my previous comment apply to all articles related to this topic that have the majority of reliable sources which use kilobyte/megabyte/gigabyte/KB/MB/GB. ''']]''' 18:11, 19 March 2008 (UTC)

:::::: Reliable sources do not use KB etc in their binary sense because the notation is ambiguous. Reliable sources do not use ambiguous units. ] (]) 18:22, 19 March 2008 (UTC)

::::::: You are wrong and you demonstrate that you do not understand what "reliable source" actually means. You need to read ]. The majority of reliable sources relevant to the articles in Misplaced Pages use the terms kilobyte/megabyte/gigabyte/KB/MB/GB in the binary sense when they are talking about powers of two numbers. ''']]''' 19:17, 19 March 2008 (UTC)

=====Rationale underlieing the hybrid proposal=====
* It seems that there are some new editors weighing in here who may not have participated in—or read—where this started on ]. So it’s worth repeating myself.<p><!--

-->Just because a new word, term, unit of measure, or a ''symbol'' for a unit of measure is proposed by an influential organization, doesn’t mean it automatically becomes widely accepted and recognized. The ] once proposed that expressions like “ppm” (parts per million) be replaced with a new unit called the ]. Notwithstanding that it was arguably a ''great'' idea, in 2004, a report to the ] (a committee that makes recommendations to the BIPM, which oversees the SI) stated that response to the proposal of the uno ''“had been almost entirely negative”'' and the principal proponent ''“recommended dropping the idea.”'' The IUPAP proposal on the uno wasn’t the first one to go down in flames for lack of adoption and it won’t be the last. It doesn’t matter if an IEC proposal for “KiB” is a good one, it has to be widely adopted and recognized before encyclopedias can use it. And so far, it hasn’t been widely adopted and appears destined to join the scrap heap of other proposals that had merit but just didn’t catch on for some reason.<p><!--

-->Yes, people come to Misplaced Pages to learn—''more about a subject;'' you don’t use unfamiliar language, terminology, and units of measure that no other encyclopedias use. How do encyclopedias decide what terms to use? Encyclopedias use terminology that a typical reader who will be visiting that article already recognizes or ''should'' recognize in order to sufficiently understand the subject and be able to absorb what they read elsewhere on the subject. Misplaced Pages can’t be be using future-talk (why not “kilocochranes”) just because “it’s a good idea” when hardly anyone except a few Misplaced Pages authors and people who helped write the damned proposal know what it means. Misplaced Pages authors can’t start thinking of themselves as coming from the United Federation of Planets who will use Misplaced Pages as a venue to take every good idea from the future and turn it into a standard that it clearly isn’t. Misplaced Pages must ''reflect'' common language usage, not try to promote change.<p><!--

-->As for the allegation that some editors here fear the use of “KiB” because it “wasn’t invented here”, well, neither was “MB” or “KB” or any other SI prefix that was appropriated from the SI by the pioneers of computers. All that pioneering was done long ago by people who had nothing to do with Misplaced Pages, long before most editors weighing in here on this forum were even born. So an assertion that opponents of “KiB” and “MiB” have an issue with “not invented here” is just a metric ton of weapons-grade bullonium and I’ll have none of it. It was nothing more than a specious attempt to bait others. So I will ignore that particular author from hereon since 1) his position on the subject is misguided, 2) he isn’t properly arguing his point here in a fashion that can possibly be considered as constructive, and 3) he obviously can’t be reasoned with<p><!--

-->There is only ''one'' valid metric to evaluate whether terms like “KiB” and “MiB” should be used here on Misplaced Pages: Is it widely used by trade magazines, general-circulation books, brochures, advertisements, owners manuals, etc. Clearly the answer is no. And that’s why the terms aren’t used by other encyclopedias. Whereas Misplaced Pages and other encyclopedias might ''explain'' these terms in an article like ], they don’t routinely used them to denote numerical equivalencies in other articles. Why? To avoid confusing readers. It doesn’t matter if they can click on a disambiguation link; the reader is effectively being expected to remember unfamiliar language that will only be encountered on Misplaced Pages. That is just <u>''so''</u> unwise. Current MOSNUM policy allowing the use of these terms is in error and should be changed.<p><!--

-->MOSNUM already has an exceedingly practical policy, here at ] that clearly can be of some utility in concluding this debate. It reads:

{{cquote|In scientific articles, use the units employed in the current ] on that topic. This will usually be ], but not always; for example, ] are often used in relativistic and quantum physics, and ] should be quoted in its most common unit of (]/])/] rather than its SI unit of s<sup>−1</sup>.}}

:It’s time for proponents of “KiB” and “MiB” to familiarize themselves with that policy, ponder the wisdom behind writing it, and consider its implications. ] (''])'' 19:04, 19 March 2008 (UTC)

* '''P.S.''' Thunderbird had a perfectly workable solution when he suggested the use of a <nowiki><ref></nowiki> note. (I took the liberty of changing his example of “SCSI transfer speeds” to “hard drive storage”). The note could read something like:

::* when applied to computer memory (RAM or cache) the quantities KB, MB and GB are defined as
::**1 KB = 1024 B
::**1 MB = 1024 KB
::**1 GB = 1024 MB

::* when applied to hard drive storage, the quantities KB and MB are defined as
::**1 KB = 1000 B
::**1 MB = 1000 KB

: Why not use that proposal? ] (''])'' 19:07, 19 March 2008 (UTC)

:: As Greg points out I have no objection to the use of this form of disambiguation. No, I ''support'' this kind of disambiguation wherever it is used. I just think that it is unlikely to be popular, because it is hard work to explain every time exactly which kind of MB you are talking about. We should let natural selection play its role here. ] (]) 19:28, 19 March 2008 (UTC)

===The case for equal status===
There was no consensus for Fnagaton’s change of 26 Jan because the possibility of deprecating the MiB and its cousins had not previously been raised on the talk page.
My edit (also 26 Jan) established what I saw as equal preference for the two forms of disambiguation (though others have interpreted it differently). That’s way changing “also preferable” to “equally preferable” only clarifies the intended meaning without changing it. We seem to all agree that disambiguation is desirable, but clearly there is little agreement on how that should be achieved. The two main contenders are a) use of IEC prefixes for binary powers (eg MiB) and b) use of exact numbers of bytes using powers (eg 2<sup>20</sup>or 1024<sup>2</sup>). My opinion is that these two options should be given equal preference here, and this is why:
* Clearly there is reluctance amongst editors to use MiB to disambiguate, and rightly so. It is unfamiliar to many, and it will take some getting used to.
* I maintain there will be similar reluctance to use exact numbers of bytes. This is partly because expressions like 2<sup>20</sup> may also be unfamiliar to some, and partly because of the sheer effort required to type it all out.
The only way to find out which is preferred is to give them equal status here. ] (]) 19:23, 19 March 2008 (UTC)

* T-bird, well, now I see why you two are so animated and are the principal combatants here. No one like’s to have another editor wade in and change someone’s work without so much as a “hello” on a talk page. Now that there is a head of steam on this debate, I suggest we not quit until a consensus has been reached on how to resolve this once and for all for all articles. Misplaced Pages needs some standardization in its computer-related articles and currently doesn’t. That’s not good. I am ''absolutely convinced'' there is common ground that can clarify ambiguity where it exists, and which 1) doesn’t use unfamiliar units of measure, and 2) requires a minimum of clicking on links and loading in new pages. Whatever that consensus is, it should be more than a gentlemens’ agreement; it should be memorialized in an official MOSNUM policy. ] (''])'' 19:34, 19 March 2008 (UTC)

:Thunderbird2, what you propose (about mentioning IEC prefixes with equal weight) gives editors who prefer one style to force it into articles regardless of what is used in the reliable sources for that article, that is wrong. The only way is to follow the reliable sources from the real world and then disambiguate by stating the exact number of bytes with power notation if needed. Stating the exact number of bytes gives no Misplaced Pages preference or personal bias to any system, that is the only completely fair option. What it does do is makes sure the real world consensus is reflected. The real world consensus, just so you are left with no doubt, is to '''not use''' the -bi prefixes. It is clear in the real world that IEC prefixes do not have "equal weight" so Misplaced Pages must not enforce "equal weight" for those prefixes either. Otherwise it is like Misplaced Pages having "affirmitive action" to help support the minority prefixes, which is not going to be tollerated. It is not the job of Misplaced Pages to support failing standards. ''']]''' 19:35, 19 March 2008 (UTC)

:Also I object to disingenuous accusation that my change had not been discussed. It was discussed as the change clearly to the discussion. I was also implementing another editor's suggestion that had been talked about. I say disingenuous accusation because I also explained to you at the time where it had been disucssed on your talk . So you do know it was discussed because I told you so I demand that you retract what you wrote. ''']]''' 19:56, 19 March 2008 (UTC)

:: I don't recall saying there had been no discussion. ] reached a consensus, which I supported, for quoting an exact number of bytes for disambiguation, not for deprecating IEC prefixes for the same purpose. ] (]) 22:16, 19 March 2008 (UTC)

::: Removing the IEC prefixes for disambiguation from the guideline is the logical result of only needing to state the exact number of bytes and following real world consensus. This is because the IEC prefixes can be ambiguous and stating the exact umber of bytes is the only unambiguous way of expressing the number of bytes. Putting it another way, since the IEC prefixes can be ambiguous then there is no point having them as a choice for disambiguation because as you agree there is no point using what can be ambiguous terms for disambiguation. As Woodstone says "Having it in the MOS will hopelfully prevent reversions" which is what happened when I made the change the editor propsed. As already explained on your talk page, you know this, so stop trying to misrepresent the situation. ''']]''' 23:32, 19 March 2008 (UTC)

::::Although I agree that the IEC prefixes have not caught on, and that is a good reason to minimize their use in Misplaced Pages, they are not ambiguous. The example Fnagaton gave earlier of alleged ambiguity was of some post to some obscure open-source software project; just because you can find one clueless programmer, that does mean a set of units is ambiguous. If we want to ban something for ambiguity, let's ban something really ambiguous, like ''12:00 PM'' or ''midnight''. --] (]) 00:06, 20 March 2008 (UTC)

:::::It means that the IEC units '''can''' be ambiguous and it has been shown how they are used in the decimal sense, something the user above had claimed to have never seen before. Since the mistake of using IEC prefixes has been shown the prefixes can therefore be ambiguous. It doesn't matter if the incorrect use is rare or not, the fact remains that stating the exact number of bytes is the least ambiguous way of disambiguation when compared with IEC prefixes. Since removing ambiguity is the goal then prefixes which can be ambiguous are not to be used in disambiguation which leaves the option of explicitly stating exactly the number of bytes. There is no way ''12:00 PM'' or ''midnight'' is ambiguous either because they are twelve hours apart and PM means ''post meridiem'' which means after noon and noon is obviously the middle of the day, generally speaking. ''']]''' 00:28, 20 March 2008 (UTC)

::::::Fortunately ] already rules out 12 am and 12 pm; ] agrees, saying that --] (]) 04:25, 20 March 2008 (UTC)

:* Noted. Let’s move on. ] (''])'' 19:59, 19 March 2008 (UTC)

:* It was my fault for misinterpreting what you wrote T-bird. ] (''])'' 23:00, 19 March 2008 (UTC)

* Why is this complex? Misplaced Pages should use the units employed in the current scientific literature on that topic. In this case, that means only '''KB''', '''MB''', '''GB''', etc. If it’s an article on hard drives, there can be a <nowiki><ref></nowiki> note at the first occurrence of “GB” explaining that it means decimal math. This would effectively be a wholesale adoption of the way current advertisements for hard drives handle the disambiguation. This is just ''one'' way to handle the problem; if there are a better ways to accomplish this end, let’s see them. ] (''])'' 19:51, 19 March 2008 (UTC) '''P.S.''' Real life calls and I’ve got something to do for the rest of the afternoon. I’ll check back and see if things have degraded to the point where we are questioning each others parenthood. ;-). ] (''])'' 20:05, 19 March 2008 (UTC)

** There are currently no better ways that are compatible with the Misplaced Pages way of doing things that I can think of. And compatibility with Misplaced Pages is the important issue here, not what some standards body seems to think is important. ''']]''' 20:08, 19 March 2008 (UTC)

* Fnagaton, if you are interested in resolving this issue across all of Misplaced Pages’s computer-related articles, may I suggest that you craft a proposed policy that you hope would be adopted by MOSNUM? I find that this sort of thing is the most difficult of all text I ever write on Misplaced Pages. I know it’s quite a challenge because to be successful, it needs buy-in from parties with widely divergent views on this matter. It seems though, that you, T-bird, and I have identified some common ground to build upon. I suspect the first step in this proposal procedure would be to not invite a straight “'''Support'''” / “'''Oppose'''” “vote”, but rather, to go first to discussion with the expectation that your first draft will evolve.<p><!--

-->I think you’ve got a superb ally in this effort: MOSNUM itself. MOSNUM’s own policy on units of measure (]), requires that editors should use the units employed in the current scientific literature on that topic. Thus, current MOSNUM policy, which permits the use of the IEC “…iB” unit symbols, makes MOSNUM in conflict with itself. The IEC units, like “KiB” are absolutely unambiguous in their definitions; that much is clear. But virtually no computer magazines nor any other encyclopedia routinely use them. Thus, they are poorly recognized by the typical reader. That much too, is clear. ] (''])'' 05:40, 20 March 2008 (UTC)


====Proposed policy on disambiguating bytes====
=====First draft for consideration=====
:I'll give it a go. Considering what you say about Misplaced Pages wisely following the example of the real world and ignoring the standards organisations when needed. Also considering what was said about not supporting one style of prefixes over another especially when that style is obviously in the minority. Considering what was also said about not hinting about deprecating one style. And considering what you say about the use of units employed in the current scientific literature. The only logical and fair conclusion is to remove reference to any hint of support for any of the standards organisation styles at all and make it clear that the units must defer to the sources for the article which will then logically defer to what is the real world consensus. In doing so all the text about "no consensus for using IEC prefixes" is removed as is the text explaining the history of the prefixes. This is because the respective articles already contain the history of these prefixes. The guideline says "without using any other prefix styles" specifically to stop any editor using their own preferred choice of prefixes for disambiguation and to avoid any kind of bias from individual editors. Also gone is the text about not changing from one style to the other and keeping with the original style, this is important because it allows articles to naturally change over time to reflect what is the consensus in the real world if the sources for that article considerably change from using KB to KiB for example. This is also to try to remove what is seen as a Misplaced Pages guideline pushing any one standard over another and to remove any bias coming from Misplaced Pages. The guideline then becomes a series of examples of what to do for disambiguation, wikilinking and footnotes. So it would result in something like this:

:<nowiki>{{Quantities of bytes}}</nowiki>
:Editors must use the units/prefixes employed in the sources used by the article. Editors must be ''certain'' whether the units/prefixes are binary or decimal in the material at hand before disambiguation. When this is certain the use of parentheses to disambiguate the number of bytes without using any other prefix styles is acceptable as is the use of footnotes and wikilinking. The rule of thumb for disambiguation is keep the number as it is in the sources (no rounding needed) and state the number of bytes in full or with power notation depending on context and brevity.
:* KB to &times;2<sup>10</sup> bytes or &times;10<sup>3</sup> bytes
:* MB to &times;2<sup>20</sup> bytes or &times;10<sup>6</sup> bytes
:* GB to &times;2<sup>30</sup> bytes or &times;10<sup>9</sup> bytes (etc)
:For example, article text which is "256&nbsp;KB" should be disambiguated as "256&nbsp;KB&nbsp;(256&times;2<sup>10</sup>bytes)".

:Disambiguation text for footnotes can contain prefixes but these prefixes must still be consistent with the sources used in the article and the lowest prefixed number of bytes must be stated in full or power notation for brevity. For example:
:* When applied to computer memory (RAM or cache) the quantities KB, MB and GB are typically defined as:
:**1 KB = 1024 B
:**1 MB = 1024 KB
:**1 GB = 1024 MB

:* When applied to hard drive storage, the quantities KB, MB and GB are typically defined as:
:**1 KB = 1000 B
:**1 MB = 1000 KB
:**1 GB = 1000 MB

: This system allows for the rare types of storage media (very very rare but they do exist somewhere) which may use the calcuation "1MB = 1024000 bytes".
:* This storage media uses a rare prefix style:
:**1 KB = 1000 B
:**1 MB = 1024 KB
:**1 GB = 1024 MB

:When wikilinking prefixes use the wikilink that points exactly to the respective prefixes used in the article, for example: "KB" becomes "]" , "KiB" becomes "]" and "kilobyte" becomes "]" etc.

:Measures that typically use decimal multiples:
:* Capacities of ] drives, ]s, some ]s, etc.
:* ] and ] speeds

:Measures that typically use binary multiples:
:* ] and ] sizes
:* ]s, some floppy drives, etc.
''']]''' 08:58, 20 March 2008 (UTC)

=====Suggested tweak=====
:: More general: <blockquote style="border-left: thick solid">
<nowiki>=== Ambiguous units ===</nowiki><br>
Disambiguation is necessary whenever a unit has more than one definition and the context of the article does not suffice to select the intended meaning.

Editors must be certain which kind of meaning (e.g. binary or decimal for SI-like prefixes with bits and bytes) is intended in the material at hand before disambiguation. The explanation can be done by the use of footnotes, wikilinking, parentheses containing exact numbers, possibly in power notation, without ambiguous units, or by employing "unit qualifiers" (e.g. ''binary megabyte'' or ''nautical mile''). The rule of thumb for disambiguation is to keep the number as is without rounding and decide on an option depending on context and brevity.
For example, article text which is "4&nbsp;KB" may be disambiguated as "4&nbsp;KB&nbsp;(4×;2<sup>10</sup> byte)".

Explain deviations from defaults in footnotes, e.g. rare types of storage media may use the calcuation "1MB = 1024000 bytes":
: ''This storage media uses a rare prefix style: 1 KB = 1000 B, 1 MB = 1024 KB, 1 GB = 1024 MB.''

<nowiki>==== Defaults and possibilities ====</nowiki><br>
Bits and bytes:
* When applied to semiconductor storage (e.g. RAM or cache) and file sizes, the prefixes K, M and G for bits and bytes are typically defined as the powers of 1024 (= 2<sup>10</sup>.
* When applied to hard drive storage and speeds, the prefixes K, M and G for bits and bytes are typically defined as the powers of 1000 (= 10<sup>3</sup>).
* The prefixes Ki, Mi and Gi for bits and bytes are always defined as the powers of 1024 (= 2<sup>10</sup>).
Miles:
...
Pounds and ounces:
...
Tons:
...

</blockquote> — ] ] 13:17, 20 March 2008 (UTC)

=====Discussion=====
: Crissov I do not support to your changes because you have inserted your own point of view with repeated references to "Ambiguous units" and "SI-like prefixes" etc. You also added various other terms such as "without ambiguous units" which means you are trying to make it possible to add IEC prefixes to articles that do not have them and that is against one of the goals of the guideline and what Greg was saying. The guideline is not for your biased point of view and should be as neutral as possible, you are making it less neutral with that kind of language. ''']]''' 14:58, 20 March 2008 (UTC)

:: I support Crissov's proposal. He will be the first to acknowledge that it needs some refinement, but it is a step in the right direction. ] (]) 15:45, 20 March 2008 (UTC)

::: Then we don't have consensus. It is a step backwards and nothing in it can be used because it is too biased. ''']]''' 15:59, 20 March 2008 (UTC)

:''(unindented)''

I've been trying to understand Fnagaton's reluctance to accept what appears to me an innocuous change. Reading the existing text through carefully, it occurs to me that it could be based on a misunderstanding. The relevant paragraph reads (verbatim):

*There is no consensus to use the newer IEC-recommended prefixes in Misplaced Pages articles to represent binary units. There is consensus that editors should not change prefixes from one style to the other, especially if there is uncertainty as to which term is appropriate within the context—one must be ''certain'' whether "100&nbsp;GB" means binary not decimal units in the material at hand before disambiguation. When this is certain the use of parentheses for binary prefixes, for example "256&nbsp;KB&nbsp;(256&times;2<sup>10 </sup>bytes)", is acceptable, as is the use of footnotes to disambiguate prefixes. Use of IEC prefixes is also acceptable for disambiguation (256 ]). When in doubt, stay with established usage in the article, and follow the lead of the first major contributor. Prefixes in directly quoted passages are never changed; if explanation is necessary, use a more exact measurement in square brackets.

I interpret this to mean ('''implied''' words in '''bold''')

*There is no consensus to use the newer IEC-recommended prefixes in Misplaced Pages articles to represent binary units. There is consensus that editors should not change prefixes from one style to the other, especially if there is uncertainty as to which term is appropriate within the context—one must be ''certain'' whether "100&nbsp;GB" means binary not decimal units in the material at hand before disambiguation. When this is certain the use of parentheses for binary prefixes, for example "256&nbsp;KB&nbsp;(256&times;2<sup>10 </sup>bytes)", is acceptable, as is the use of footnotes to disambiguate prefixes. Use of IEC prefixes is also ('''equally''') acceptable for disambiguation '''i.e., 256 KB''' (256 ]). When in doubt, stay with established usage in the article, and follow the lead of the first major contributor. Prefixes in directly quoted passages are never changed; if explanation is necessary, use a more exact measurement in square brackets.

In other words, the (permitted) role of KiB is to disambiguate KB, not to replace it. Is that also how others read it? ] (]) 16:15, 20 March 2008 (UTC)

:There isn't any misunderstanding on my part. I've said this before but I will say it again. IEC Prefixes are not equally used in the real world, therefore it is not Misplaced Pages's place to try to force them to be equal in the guideline. There are two choices. 1) Remove all attempts at pushing IEC prefixes in the guideline by agreeing to not use any biased wording, my proposal does not contain biased wording whereas Crissov's does use biased wording and POV. 2) Leave the guideline as it is which clearly says "There is no consensus to use the newer IEC-recommended prefixes". KiB should not even be used to disambiguate KB for the reasons already given above regarding the potential for ambiguity and the fact that stating the number of bytes is the least ambiguous method. ''']]''' 16:39, 20 March 2008 (UTC)

:: In that case I remain as puzzled as ever. Are you suggesting that "256&times;2<sup>10 </sup>bytes" is more common than "256 KiB"? ] (]) 16:51, 20 March 2008 (UTC)

::: It is because I agree with Greg's (19:04, 19 March 2008 (UTC)) comment that using unfamiliar IEC prefixes to denote (or disambiguate) the well known terms such as KB is more confusing to the readers and going by other related Misplaced Pages guidelines it is also unwise to try to advocate using those IEC prefixes when the article does not. I also agree that explaining the exact number of bytes is the least biased option and is the option that is least confusing to the reader who is looking to be educated about the exact size of 64 KB in a specific context, for example. So that's why anything that softens the guideline to try to allow equal standing to the minority prefixes does not get my support. I'm all for a completely neutral guideline as my proposed text shows because that fits with other Misplaced Pages guidelines about letting the real world consensus decide. It's about being consistent with the sources. ''']]''' 17:01, 20 March 2008 (UTC)

::::I oppose Fnagaton's proposed wording because it includes the sentence "Editors must use the units/prefixes employed in the sources used by the article." This is unwise because
::::*no one editor is likely to have access to all or most of the sources, so only the select few who have access to most of the sources can edit the article
::::*most of the sources might be old and use outdated units, such as angstroms
::::*most of the sources might use specialized units, while more generally understood units might be more suitable for an encyclopedia. --] (]) 17:11, 20 March 2008 (UTC)

:::::* A fallacious objection because my proposed text says one must be certain before making changes. If you are not certain don't edit the article and instead leave it to someone else who is better equipped to make the changes. This is standard editing etiquette. Also to refute your other points, going back to what Greg said the units used in articles must be consistent with those used by the sources because that makes the reader less confused. It doesn't matter if the units used in the sources are against what the standards body you prefer says, what matters is being consistent with the literature/reliable sources relevant to the article. Put simply it is not your judgement call what might be better understood units. Lastly, and most importantly, it is not unwise at all. In fact it is very wise because it basically says what the parent MOS entries say about being consistent with the sources of the article. ''']]''' 17:25, 20 March 2008 (UTC)

:::::::A person may be thoroughly equipped to edit an article without having access to the specific works in the reference list. For example, an article might cite five roughly equivalent textbooks, and an editor might have access to only two of them (plus three others that are not on the reference list). An editor should not have to consult most of the works in the list just to decide which unit to use. To require otherwise constitutes article ownership.

:::::::I do not mean to suggest someone should pick one publication of a standards body and use it, even though that standard has been widely ignored by practicioners in the field. I do mean that the units used should be those generally used by modern sources in the field, even if a majority of the particular sources in the reference list happen to use some outdated or uncommon unit. --] (]) 17:39, 20 March 2008 (UTC)

* All, I am truly surprised at how much common ground there is between these two proposals. Fnagaton, it appears to me that Christoph and T-bird bought off on your entire basic framework of how to disambiguate bytes. The differences appear to be merely in some lead-in body text explaining the rationale and basis for the policy. What is gone from all of this is any reliance upon unfamiliar units such as “KiB”. This is a major step forward and the differences between these truly seem trivial to me. I can easily go in and draft a proposed fusion of this but believe it would be premature to do so. '''Let’s solicit more comments from others.'''<p><small>''(*sound of crickets chirping*)''</small><p> ] (''])'' 17:09, 20 March 2008 (UTC)

*:Except the bits where it calls units "ambiguous" and rationale which is POV and the bits that open the doorway for adding IEC prefixes to articles that don't use them. The "KiB" is still there tucked away in the hidden meaning of "without ambiguous units". The wording needs to be neutral, not biased. I think it is a good time for the guideline to be changed because I don't particularly like "there is no consensus" bit as it has served its purpose to educate some users that they cannot use IEC prefixes everywhere and ignore the reliable sources. However the guideline needs to be changed for the better to avoid the situation happening again in the future. If anyone remembers the many bad vandalism changes Sarenne made you would know where I am coming from. ''']]''' 17:19, 20 March 2008 (UTC)

::* Common Fnagaton, I think we need more “assuming good faith” here. I may be wrong, but I believe he was calling it “ambiguous” because there are ''three'' meanings to “MB”: 1,000,000 bytes, 1,024,000 bytes, or 1,048,576 bytes. Thus, KB, MB, GB, etc. ''are'' ambiguous. That’s sort of a “well… ''duhh”'' fact here; otherwise, we wouldn’t be having this discussion, would we? Perhaps it would help to have an explicit clause saying that “unit symbols like “KiB” shall not generally be used to denote numeric equivalencies of computer storage since the terms are not well recognized.” If your suspicions are well founded, then someone will object to this proposal, no? Does anyone object to this? ] (''])'' 17:39, 20 March 2008 (UTC)

* Anyway... I'm going to be taking a break over Easter, so don't make any guideline changes while I'm gone. ;) ''']]''' 17:32, 20 March 2008 (UTC)

::* I’ve also spent more time reading the above discussion. The basic framework of your proposal is entirely sound but the premiss seems to be wrapped too much around the subject of ''revising'' articles. I understand this is the hot-button issue that started all this. However, the MOSNUM policy on disambiguating “MB” needs to start first with the general policy of how articles are supposed to be written in the first place, how articles are supposed to appear, and what methods are acceptable. ''Then'' it can advance on to issues of editing existing articles—what editing practices are recommended, permissible, and impermissible. This is the “hard part” of writing MOSNUM policy I was writing earlier about; you damn near have to have a legal mind to pull it off. It helps though, to start off simply and gain consensus on that first. The details of revising existing articles should fall into place easily once everyone has agreed to what the ideal practices are. ] (''])'' 17:59, 20 March 2008 (UTC)
::*Somebody asked: ''Are you suggesting that "256&times;2<sup>10 </sup>bytes" is more common than "256 KiB"? '' I would say, probably yes, although it's difficult to search for that. &mdash; ] ] 21:34, 20 March 2008 (UTC)

====Third, hybrid proposal====
All, I’m (Greg L) going to take a stab at a hybrid proposal for us to discuss. I’m going to start out short and simple for a variety of reasons: 1) it will keep me from getting too invested into my own work since there will be little of it, 2) I want to reserve the potentially more contentious issue of revising existing articles until after <strike>a consensus has been reached on where we want to go with new articles</strike> <small>''(Well, that didn’t happen)''</small>, and 3) I am going to use head-on, direct language to demonstrate that others have no hidden agendas to keep on using IEC terms like “MiB” as Fnagaton fears.<br><br>

<div style="background-color:honeydew; border:thin solid forestgreen; margin:0; padding:8pt 12pt;">
<strong style="font-size: 125%;">Binary prefixes in computer memory and storage</strong><br>
The 1999 ] proposal on ] (]), which introduced prefixes such as “KiB” to represent 1024 bytes (2<sup>10</sup>), “MiB” to represent 1,048,576 bytes (2<sup>20</sup>), etc., has not been widely adopted by the computing industry and trade magazines and is therefore unfamiliar to most readers. In acknowledgment of this reality, it is no longer permissible on Misplaced Pages to use IEC&nbsp;60027-2 binary prefixes in numerical equivalencies to denote the capacity of computer memory and storage. Unless they are being used in verbatim quoted text, terms like “KiB”, “MiB”, and “GiB”, generally speaking, should be used only in articles that describe IEC&nbsp;60027-2 directly.

As the terms “KB”, “MB”, “GB”, “TB”, etc. are ambiguous as to their magnitudes, disambiguation in articles may be required.

Generally speaking, it should be assumed that file size and transistorized computer memory (DRAM, SRAM, etc.) are quantified using binary mathematics as shown in the table below.

{|border="1" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f5f5f0; border: 2px #2F2F2F solid; border-collapse: collapse; font-size: 95%;"
|- |-
|data-sort-value="100"|100 years||big
! colspan="4" style="background:#535353" align="center"|<font color=white>BASE 2 BYTE PROGRESSIONS</font>
|- |-
|data-sort-value="{{#expr: 2/365.2422}}"|2 days||tiny
|style="background:#d9d9d3" align="center"|'''Value'''
|style="background:#d9d9d3" align="center"|'''In terms of<br>preceding<br>measure'''
|style="background:#d9d9d3" align="center"|'''Exponent'''
|style="background:#d9d9d3" align="center"|'''Bytes'''
|- |-
|data-sort-value="{{#expr: 10/365.2422}}"|10 days||tiny
|align="center"|1 KB
|align="center"|1024 B
|align="center"|2<sup>10</sup> bytes
|align="left"|1024 bytes
|- |-
|data-sort-value="{{#expr: 20/365.2422}}"|20 days||tiny
|align="center"|1 MB
|align="center"|1024 KB
|align="center"|2<sup>20</sup> bytes
|align="left"|1,048,576 bytes
|- |-
|data-sort-value="10"|10 years||mid
|align="center"|1 GB
|align="center"|1024 MB
|align="center"|2<sup>30</sup> bytes
|align="left"|1,073,741,824 bytes
|- |-
|data-sort-value="2"|2 years||small
|align="center"|1 TB
|align="center"|1024 GB
|align="center"| 2<sup>40</sup> bytes
|align="left"|1,099,511,627,776 bytes
|} |}
:Note that anything less than a year is NumDays/365. Of course, you can choose your own base unit.
…and so forth
: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)
Generally speaking, it should be assumed that hard drives—including solid-state models—are quantified using decimal mathematics as shown in the table below.
:::It is more obvious when you look at the wiki mark-up: <syntaxhighlight lang=wikitext>{|class="wikitable sortable"

!value!!name
{|border="1" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f5f5f0; border: 2px #2F2F2F solid; border-collapse: collapse; font-size: 95%;"
|- |-
|data-sort-value="100"|100 years||big
! colspan="4" style="background:#535353" align="center"|<font color=white>BASE 10 BYTE PROGRESSIONS</font>
|- |-
|data-sort-value="{{#expr: 2/365.2422}}"|2 days||tiny
|style="background:#d9d9d3" align="center"|'''Value'''
|style="background:#d9d9d3" align="center"|'''In terms of<br>preceding<br>measure'''
|style="background:#d9d9d3" align="center"|'''Exponent'''
|style="background:#d9d9d3" align="center"|'''Bytes'''
|- |-
|data-sort-value="{{#expr: 10/365.2422}}"|10 days||tiny
|align="center"|1 KB
|align="center"|1000 B
|align="center"|10<sup>3</sup> bytes
|align="left"|1000 bytes
|- |-
|data-sort-value="{{#expr: 20/365.2422}}"|20 days||tiny
|align="center"|1 MB
|align="center"|1000 KB
|align="center"|10<sup>6</sup> bytes
|align="left"|1,000,000 bytes
|- |-
|data-sort-value="10"|10 years||mid
|align="center"|1 GB
|align="center"|1000 MB
|align="center"|10<sup>9</sup> bytes
|align="left"|1,000,000,000 bytes
|- |-
|data-sort-value="2"|2 years||small
|align="center"|1 TB
|}</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)
|align="center"|1000 GB
::::Sure, why not. –] (]]) 02:10, 7 January 2025 (UTC)
|align="center"|10<sup>12</sup> bytes
|align="left"|1,000,000,000,000 bytes
|}
…and so forth<br><br>

The challenge for editors who must use ambiguous units of measure and their symbols is to mitigate confusion, not contribute to it. Common sense will suffice in all but the rarest of circumstances. Disambiguation should be implemented in a fashion that avoids use of terminology that would be poorly recognized by the typical reader, is minimally obtrusive within the body text, entails a minimum of directing readers to separate articles, and which uses links in a way that best adheres to ]. Note the following examples:<br><br><hr/><hr/><p>

::The original Macintosh had 128 ]<sup><font color=blue></font></sup> of ]. The next version, informally known as the “Fat Mac,” had 512&nbsp;KB of RAM. Lorem ipsum dolor sit amet, maecenas eligendi tincidunt aenean, sit et hac hendrerit massa, morbi maecenas nec vel auctor. Aliquam sit, tincidunt justo arcu neque eu mi fames. Vitae tellus suspendisse sed sit, dapibus ante purus erat non dui vivamus, dolor ultricies maecenas lacus luctus nunc, integer cursus tellus, anim a sem.<p><p>

::<p style="font-size: 150%;">Notes</p><hr/><p>
:::1.&nbsp;&nbsp;&nbsp;<font color=blue>'''^'''</font>&nbsp;&nbsp;Throughout this article, “KB” equals 1024&nbsp;bytes.
<hr/><hr/>

<br><br><hr/><hr/><p>

::The ] ''Cheetah 15K.5'' ST373455LW, “80&nbsp;]”<sup><font color=blue></font></sup> ] had an actual formated capacity of 73.4&nbsp;GB and could hold a 2-hour, compressed HD movie with a file size of up to 68.3&nbsp;GB.<sup><font color=blue></font></sup> Lorem ipsum dolor sit amet, maecenas eligendi tincidunt aenean, sit et hac hendrerit massa, morbi maecenas nec vel auctor. Aliquam sit, tincidunt justo arcu neque eu mi fames. Vitae tellus suspendisse sed sit, dapibus ante purus erat non dui vivamus, dolor ultricies maecenas lacus luctus nunc, integer cursus tellus, anim a sem.<p><p>

::<p style="font-size: 150%;">Notes</p><hr/><p>
:::1.&nbsp;&nbsp;&nbsp;<font color=blue>'''^'''</font>&nbsp;&nbsp;One gigabyte, or GB, equals one billion bytes when referring to hard drive capacity.<p>
:::2.&nbsp;&nbsp;&nbsp;<font color=blue>'''^'''</font>&nbsp;&nbsp;When used as a measure of actual digital file capacity, “GB” equals 2<sup>30</sup> or 1,073,741,824&nbsp;bytes.
<hr/><hr/><br>

Existing articles that use the IEC&nbsp;60027-2 prefixes should be brought into compliance with this policy. Two imperatives must be met when revisions are made: 1) all changes ''must'' be correct so the articles remain accurate, and 2) courtesy should be afforded to editors who are currently shepherding an affected article or had recently greatly expanded an affected article. If you abide by expected etiquette and treat other editors as you would hope to be treated, all should go smoothly.

As regards, point #1 above (accuracy), ''read the existing text'' and ''research your material'' before making changes. As regards point #2 above (courtesy), post a message on the talk page of the article as well as the talk page of the shepherding editor. In that message, bring this MOSNUM policy regarding proper use of IEC&nbsp;60027-2 prefixes to the editor’s attention and allow him or her a reasonable opportunity to update the article. Observing this second point has the dual virtues of keeping editing Misplaced Pages a fun hobby for all of us, and best ensures articles remain factual and correct.</div>
<br>

That is my proposal. The rationale underling this proposal is encapsulated ]. Comments please. ] (''])'' 00:49, 21 March 2008 (UTC)

=====Support or oppose=====
'''Support, MOSNUM adoption of ]:'''<br>
Please sign with # <nowiki>~~~~</nowiki>
#'''Support''' For reasons outlined ''].'' <small>] (''])'' 05:56, 23 March 2008 (UTC)</small> Extensive discussions have reached a point where the views of those who are most animated about this are clear as glass and their positions have only hardened. We’ll now see how others feel and, hopefully, they’ll join into the discussion too. ] (''])'' 18:35, 23 March 2008 (UTC)
#'''Support''' In the interests of trying to build consensus I support Greg's proposal. It clearly states what is acceptable and what is not. ''']]''' 15:16, 24 March 2008 (UTC)
#'''Support'''—I've read the proposal and am acquainted with the preceding debate. Although it's not my field, I find the proposal to be eminently sensible and a workable solution to a long-standing issue. ] ] 06:54, 23 March 2008 (UTC)
#'''Support''' This explains the meaning of a unit whose value is debatable in the context in which it is used, mirroring the real life applications of it. ] (]) 22:46, 23 March 2008 (UTC)
#'''Support''' As Rilak says mirroring real life is a good reason. ] (]) 13:00, 24 March 2008 (UTC)
'''Oppose, the proposed policy should not be adopted''':<br>
Please sign with # <nowiki>~~~~</nowiki>
#'''Oppose''' at least until actual discussion of this can occur. ], and voting is not a substitute for discussion. Attempting to ram this through with a rapid vote will only breed enmity and cause this topic to come up again (and again, and again) in the future. — ] ]/] 07:43, 23 March 2008 (UTC)
#'''Oppose''' especially because it is absolutely unclear from the messy box above what is actually being proposed. Also, I don't see anything wrong with using the IEC prefixes for disambiguation. &minus;] (]) 18:57, 23 March 2008 (UTC)
#'''Oppose''' polling at this stage. We need to discuss. WHoever put this together didn't even include a section for "comments". I'll fix that... ](]) 19:05, 23 March 2008 (UTC)
#'''Oppose''' deprecation of unambiguous IEC prefixes. The proposal does not address the fundamental ambiguity inherent in the megabyte and its cousins. The tables work fine in simple articles with a clear separation between the discussion of RAM and hard drive storage. But any attempt to describe transfer of data from one medium to another would quickly become incomprehensible because the MB would have to change its meaning half-way through a sentence. We are trying to produce unambiguous articles here and the IEC is trying to help us. ] (]) 13:47, 24 March 2008 (UTC)
#'''Oppose''' deprecation of unambiguous IEC prefixes. The arguments in favor of deprecation are fallacious. ] (]) 15:04, 24 March 2008 (UTC)

'''Discussion'''<br/>
#'''Comment''' I am very troubled by the section saying that current articles "should" be brought into compliance. I haven't time right now to articulate a clear explanation of what I mean, but there are several issues with that section. It also seems to ''completely'' deprecate the IEC prefixes, which while I agree are silly, and rarely (not never) used in real-world and/or everyday situations, are not worth effectively banning. ](]) 19:05, 23 March 2008 (UTC)
#* Well, your newly added “comments” section is what the ] (right below, there ↓) was for. But that’s fine SamBC, we now have a fresh place to start. If the last two paragraphs of the proposal was deleted, would that change your vote? ] (''])'' 20:01, 23 March 2008 (UTC)
#'''Comment''' I support the use of these tables for disambiguation by consensus on individual articles. I strongly oppose any proposal that prefer ambiguous units over unambiguous ones. ] (]) 13:38, 24 March 2008 (UTC)
#'''Comment''' There is no evidence that the general public has anymore knowledge of the meaning of MB than the meaning of MiB. As Morrison noted 40 years ago we practitioners are aware of a potential ambiguity in K between 1,000 and 1,204, but there is no evidence that such knowledge exists in the general public. So to deprecate one poorly unknown symbol in favor of another is not justified. ] (]) 15:04, 24 March 2008 (UTC)
#'''Comment''' That is not exactly the argument Tom94022. The actual argument is that the evidence is clear that the general public do see KB/MB/GB more than the IEC prefix versions. Secondly the proposed guideline is not about "deprecation of IEC prefixes", the guideline is about making sure the biased POV of some editors does not spill into the guideline and editing articles. According to the proposed guideline if there is an article where its sources use a lot of IEC prefixes then yes that article will naturally use binary prefixes. ''']]''' 15:21, 24 March 2008 (UTC)
#*The proposal says that articles shouldn't use IEC prefixes except in verbatim quoted text, unless they are ''about'' the IEC prefixes or related topics. The final two paragraphs, which is has been suggested be removed, also say that existing articles using the IEC prefixes should be "fixed". Sounds like deprecation to me, if not more than deprecation. Saying IEC prefixes should be used wherever they are clearly meant ''is'' biased, but so is saying they ''mustn't'' be used, which is what the proposal seems to be saying, and will be taken to mean. ](]) 15:46, 24 March 2008 (UTC)
#**"articles shouldn't use IEC prefixes except in verbatim quoted text, unless they are ''about'' the IEC prefixes or related topics" - So that means the proposal does not deprecate IEC prefixes. In fact the proposal supports use of IEC prefixes where they should be used as shown by the article sources. ''']]''' 16:22, 24 March 2008 (UTC)
#'''Comment''' Thunderbird2 the proposal does address those concerns about "becomming incomprehensible" as you put it. If you can show me an article that is "incomprehensible" (as you put it) then I'll show you a way within the scope of the proposed guideline that will make the article understood. If you cannot show an article then I think your objection can be changed to a support. ''']]''' 16:28, 24 March 2008 (UTC)
#'''Comment''' At the risk of giving it the "kiss of death", I support Woodstone's proposal. ] (]) 17:34, 24 March 2008 (UTC)
#'''Comment''' As editors, I think some of us have become too familiar and comfortable with terms like “KiB” and “GiB.” Any honest assessment of reality would show that most readers have ''never'' encountered such terms before; not in any computer magazine off the newsstand, nor any owners manual for ''any'' piece of computer equipment, nor any advertisement. It doesn’t matter if using these unfamiliar terms makes lives of Misplaced Pages editors easier because such units have scientific and logical purity. We should use the terminology and methods of disambiguating used in the real world since this is what our readers are accustomed to and comfortable with. The editors and authors of ''MacWorld'' or ''PCWorld'' write about RAM, hard drives, file sizes, etc. each month and manage to do so in a way that is clear enough for the average reader. So too does every single one of the manufactures who advertise in these magazines. Arguments here that we need to go beyond these real-world communication techniques and use methods that most readers only encounter on Misplaced Pages amounts to nothing more than trying to solve a problem that exists only in our imaginations. Misplaced Pages should follow the communications practices observed by influential computer periodicals and other encyclopedias. Just because “the IEC says to” isn’t good enough. we’re suppose to write “75&nbsp;%” (with a space) but you don’t see Misplaced Pages following that standard do you? ] is to wisely use the convention readers are accustomed to: “75%”. ] (''])'' 19:15, 24 March 2008 (UTC)

===== Alternative Proposals =====

I propose a balanced formulation as follows:
{| class="wikitable"
|<b>Binary prefixes</b><br>
<nowiki>{{Quantities of bytes}}</nowiki><br>
Quantities of bits or bytes in computing are sometimes expressed in ] (powers of 2) and sometimes in ] (powers of ten). As a consequence there are two different de facto standards for using symbols K, M, G (representing prefixes kilo-, mega- and giga-, respectively), one in powers of 1024 (2<sup>10</sup>), and the other as in the SI prefixes, using powers of 1000 (10<sup>3</sup>). To attempt to resolve this ambiguity, the ] introduced new prefixes including ''kibi-'', ''mebi-'', ''gibi-'', and symbols such as Ki, Mi, Gi in 1999 to specify ''binary'' multiples of a quantity. These replacements for the historical units have gained only limited acceptance outside the standards organizations. Most publications, computer manufacturers and software companies continue to use the historical binary units (KB, MB, GB). Note that the prefix for 1000 is a lowercase "k"; some publications use an uppercase "K" to indicate the prefix for 1024.

There is no consensus to use the newer IEC-recommended prefixes in Misplaced Pages articles to represent binary units. There is consensus that editors should not change prefixes from one style to the other, especially if there is uncertainty as to which term is appropriate within the context: one must be ''certain'' whether a quantity means binary not decimal units in the material at hand before disambiguation. When this is certain, values from sources can be disambiguated in brackets using explicit bit or byte quantities, or IEC prefixes. For example:
* "597&nbsp;MB&nbsp;(597&times;2<sup>20</sup>&nbsp;bytes)" or
* "597&nbsp;MB&nbsp;(597&nbsp; MiB)" or
* "626&nbsp;MB&nbsp;(626&times;10<sup>6</sup>&nbsp;bytes)" or
* "626&nbsp;MB&nbsp;(597&nbsp; MiB)"

When in doubt, stay with established usage in the article, and follow the lead of the first major contributor. Prefixes in directly quoted passages are never changed. Alternatively, footnotes may be used to indicate the right interpretation of the units given.
|}
&minus;] (]) 17:20, 24 March 2008 (UTC)

=====Discussion of hybrid proposal=====
The proposal does not provide for using KiB and the like within quotations. --] (]) 01:03, 21 March 2008 (UTC)

* <strike>Exactly. And why is that the case? In part, because the proposal includes the following text: ''“Disambiguation should be implemented in a fashion that avoids use of terminology that would be poorly recognized by the typical reader.”''<p>Gerry, there is no point relying upon a term that is unambiguous in its definition ''but is unknown by most readers''. When that’s the case, the purported reason for adding the parenthetical—to explain—does nothing of the sort and is effectively just asking the reader to remember unfamiliar terminology that will only be encountered on Misplaced Pages. Please enumerate for me, all the computer magazines that routinely use “GiB.” Encyclopedias use terminology that a typical reader who will be visiting that article already recognizes or should recognize in order to sufficiently understand the subject and be able to absorb what they read elsewhere on the subject. This is the central tenet of this proposal. You’ve made your feelings clear but we will just have to agree to disagree if you feel otherwise Gerry. ] (''])'' 01:35, 21 March 2008 (UTC)

* '''P.S.''' When you wrote “…KiB ''and <u>the like</u>''…” what exactly are you referring to? I think I used all the good alternatives in my proposed examples above. Are there some other good ones (besides IEC&nbsp;60027-2 binary prefixes) we should know about? If so, make them known and we’ll add them to the above examples. As long as it’s a well recognized term, it is suitable for use as a parenthetical explanation intended to clarify. ] (''])'' 01:45, 21 March 2008 (UTC)</strike>

::It is generally considered improper to change a quotation. If we wish to quote someone who chose to use KiB, or any of the other IEC binary prefixes, we have to keep the unit in the quote. Your reply seems to have nothing to do with this situation. --] (]) 02:31, 21 March 2008 (UTC)

::* D’oh! A thousand pardons, I misunderstood what you wrote although it was perfectly clear. For some crazy reason, I thought you were proposing to disambiguate as follows “The hard drive has a formated capacity of 73.4&nbsp;GB (68.3&nbsp;GiB).” In other words, I thought you were proposing to use the term in ''parentheses''. To be conservative with space here and keep things tidy, I’ll go back up and add some wording to address this oversight. Let it hereby be known to all that my first draft of the hybrid proposal did not address this issue of quoted text until Gerry correctly pointed out the omission. ] (''])'' 03:28, 21 March 2008 (UTC)

* If anyone else has a comment to add here over the next 24 hours, you may have to take care to write with extraordinary clarity so even I can understand your point. Judging from the above, it is clear my mind isn’t hitting on all two cylinders. ] (''])'' 03:52, 21 March 2008 (UTC)

* What is this a hybrid ''of'', and in what sense? It is simpler to just describe what you intend to change from the existing guidance: '''never use IEC prefixes unless you are forced to do so, and disambiguate with footnotes'''. I suppose that is the logical conclusion of the long, brutal "process" we have seen on this issue up to this point. I am not sure how you think you are avoiding the matter of existing articles in any way; your proposal basically spells out that IEC prefixes must be purged. This is a proposal that would effectively eliminate the IEC prefixes from Misplaced Pages, period. No sense in dancing around that. Previous proposals have generally not gone that far because their authors realized how much opposition there was to that idea. And what is this about "hidden agendas"? — ] ]/] 04:45, 21 March 2008 (UTC)

:* It’s a hybrid in the sense that I was trying to capture elements from Fnagaton’s proposal of 08:58, 20 March 2008 (UTC) and Christoph Päper’s 13:17, 20 March 2008 (UTC) proposal. The “hidden agenda’s” issue arose from a 17:19, 20 March 2008 (UTC) posting by Fnagaton who wrote ''“Except the bits where it calls units "ambiguous" and rationale which is POV and the bits that open the doorway for adding IEC prefixes to articles that don't use them.”'' That, in context with prior writings up to that point, indicated to me that Fnagaton was skeptical about wording that might allow use of the IEC units because he felt that if given an open door, some editors ''would.'' However, it was my feeling that this concern was unwarranted and there were no hidden agendas to exploit loopholes as he feared. My interpretation of Christoph’s use of the term “ambiguous” was that he was simply trying to describe the obvious: that terms like “MB” and “GB” ''are'' ambiguous, and that is why we need to disambiguate them somehow. Please take note of how I explicitly acknowledged the ambiguity of “MB” and “GB” in my proposed hybrid, or merged, version.<p>As for your statement, ''“I am not sure how you think you are avoiding the matter of existing articles in any way,”'' I’m not trying to and I haven’t the fogiest idea how you could come to that conclusion if you had read my proposal in full. I ''clearly'' stated as much in the preamble leading into the proposal, which reads as follows:

:::{{quotation|All, I’m (Greg L) going to take a stab at a hybrid proposal for us to discuss. I’m going to start out short and simple for a variety of reasons: 1) it will keep me from getting too invested into my own work since there will be little of it, 2) I want to reserve the potentially more contentious issue of revising existing articles until after a consensus has been reached on where we want to go with new articles, and 3) I am going to use head-on, direct language to demonstrate that others have no hidden agendas to keep on using IEC terms like “MiB” as Fnagaton fears.}}

::…and then ''concluded'' with this text:

:::{{quotation|Given this policy, current articles that use the IEC 60027-2 prefixes…}}

::Between the preamble and the last sentence, which I cut off right in the middle with the ellipsis, it should be abundantly clear that I fully well intend to address how to handle current articles—''after'' we have reached an agreement on the basic principals here. Otherwise, we’re fritting away on details when we haven’t reached an agreement on the essential elements of what we’re trying to accomplish.

::As for your ''“your proposal basically spells out that IEC prefixes must be purged”'', well said. I perceived there was a whole bunch of beating around the bush in the above discussions and it was time for all that to end. If I’m going to spend ''hours'' on this issue, I’m not going to waste anyone’s time by using U.N.-style, ambiguous diplo-speak that can be interpreted any way one wants. I think what I’ve got explains the rationale clear as glass and then goes on to implement that rationale precisely as one would expect. No beating around the bush. Yes?

::The IEC prefixes are damned poor units of measure to use in numerical equivalencies describing the capacity of computer memory and storage. Why? While they certainly have the virtue of absolutely unambiguous definitions, ''they are unrecognized by most readers'' and this makes them entirely unsuitable for any encyclopedia. When editors use them, we are effectively just asking the reader to remember unfamiliar terminology that will only be encountered on Misplaced Pages. Encyclopedias use terminology that a typical reader who will be visiting that article ''already'' recognizes—or ''should'' recognize—in order to sufficiently understand the subject and be able to absorb what they read elsewhere on the subject. Misplaced Pages must reflect common language usage, not try to promote change by prematurely adopting proposed units of measure that no other encyclopedia, computer magazine, or computer-equipment manufacturer uses. Current MOSNUM policy is clear: “In scientific articles, use the units employed in the current scientific literature on that topic.” It was an error to have allowed the IEC&nbsp;60027-2 prefixes be used here in Misplaced Pages before first waiting for them to become widely adopted in the industry.

::Aluvus, the proposal isn’t anything other than what it seems to be on the surface. If you disagree with it, say so. Please argue with the ''proposal'', not the process that brought about the proposal; it’s still a work in progress—a draft. But if you disagree with it, please then explain why using terms that aren’t well recognized by readers and aren’t generally used in the industry is such a good practice to embrace. If your disagreement goes even deeper than that, and you disagree with its basic premiss and the facts underlying it, please enumerate for us, all the computer magazines, owners manuals, and advertisements that routinely use “GiB” instead of “GB”. If you’ve got a suggestion to improve what’s already here, as Gerry Ashton did, let’s hear it. If you are in basic agreement with the policy as it applies to ''new'' articles but have reservations about its implications for existing ones, say so; we haven’t even gotten to that stage yet. ] (''])'' 06:17, 21 March 2008 (UTC)

:::In the interests of trying to build consensus I support Greg's (with the tweaks). This is because 1) It closes the doorway for some users wanting to sneak in IEC prefixes where they are not being used by article sources, therefore is helps to maintain consistency with real world consensus. 2) It contains much less POV. 3) It improves upon the current guideline a great deal. 4) I agree there has to be no beating around the bush that IEC prefixes must be purged because they are unrecognised by most readers which makes them completely unsuitable for Misplaced Pages. And now I really do start my Easter break. ;) So I will be out of action for a while. But please can we use the term "mathematics" and not "math" in the proposal? :) I appreciate the time you have spent on this subject Greg, it is not an easy choice of guideline to debate. ''']]''' 08:26, 21 March 2008 (UTC)

:::* Thanks Fnagaton, the two sentences in the draft proposal that used to read similarly to this one: ''“Generally speaking, it should be assumed that file size and transistorized computer memory (DRAM, SRAM, etc.) are quantified in binary math”'' now end with ''“…are quantified using binary mathematics.”'' ] (''])'' 17:04, 21 March 2008 (UTC)

:::While I really appreciate the polemic that rehashes the exact same arguments we have seen on this page dozens of times, it has nothing to do with anything. I am getting the distinct impression that you have stumbled on this issue, did not read any previous discussion (and I don't blame you; it is really, truly horrible), and now believe you come to us with the One True Solution to this matter. But what I think you have missed entirely is that the "beating around the bush" and complexity of this issue arise because ''people disagree about how it should be handled''. There are people that want to eliminate IEC prefixes from the project entirely, and people that want them used in every appropriate context, and people that fall in between. The "beating around the bush" comes from ''compromises'', not all of which were wise, that were meant to secure some kind of relative peace.

:::One of the major roadblocks seen in previous discussion is '''people that answer specific comments with rambling, off-topic polemics'''. It has stalled numerous discussions, and actually led to at least one editor entirely leaving the project out of disgust. If you genuinely want to help "solve" this issue, please avoid that tactic. It does not do anyone any good.

:::But back to the original topic. There is no hidden agenda in my previous comment, if that is what you are hunting for. Your original description of this proposal was completely unclear as to ''what the proposal was'', (these tend to pile up, and a brief summary is very valuable) and indicated you thought you had somehow put off dealing with the issue of existing content. But that makes no sense; your proposal says, in short, "never use IEC prefixes". That seems to speak pretty clearly to the matter of existing content.

:::I consider this proposal less bad than many that have come before, and an improvement on the current guidance. That is only because I dislike the "split the baby in half" solutions, and because there is a possibility that this would actually settle the matter for more than a month. But your little tirade was certainly not endearing. — ] ]/] 06:29, 22 March 2008 (UTC)

* All: Let’s wait two or three more days for additional comments on the current portion of the draft proposal, which addresses the fundamental principals of this issue and where we want to go with new articles. ''Then'' we’ll go onto the issue of how to handle current articles; there’s no avoiding it. Note that I have never had a hand in writing any of the computer-related articles; I just happened upon a few (where I saw “MiB” and didn’t know what it meant). Accordingly, I have only the most general idea of the hot-button issues editors must be facing when an article is revised by another. I ask that between now and then, you be thinking about what it is about the current revision process that most needs fixing and what you’d like to see in a formal policy. ] (''])'' 18:31, 21 March 2008 (UTC)


* '''P.S.''' At the end of the current proposed policy, in the form of a hidden editors note, is notional verbiage for bringing current articles into compliance with this policy. It’s a starting point for what I’m thinking about at the moment anyway. I hope to receive input from you all. To see the notional text, to go to edit mode in the relevant section. Scroll down about half way in the edit window to find it. ] (''])'' 21:38, 21 March 2008 (UTC)

*I '''oppose''' any proposal deprecating use of the IEC units. The current wording on them is already quite negative and I see no reason to totally ban them. They are still a professionally recognised standard and an excellent way of disambiguation. The current text was reached after long discussions and should not be upset quickly without a very clearly established wide consensus. &minus;] (]) 15:01, 22 March 2008 (UTC)

*Heavens, I'm trying to work out why Alvulus is being so hostile towards Greg L and his proposal. The use of language such as "ram this through" is degrading the debate. I see no reason why the vote is premature; Alvulus, you can have your say here, if you want to, but please be more measured and depersonalise the issue. ] ] 08:24, 23 March 2008 (UTC)

=== There is no basis for a policy that deprecates Binary SI units ===
Am I missing something, but since, (MOSNUM:Which system to use), requires that editors should use the units employed in the current scientific literature on that topic and since the IEEE Computer Society is one of the leading such publisher of such literature, deprecation seems to be in violation of stated policy and more the POV of a rabid editors such as Fnagaton. This whole thread started when Tbird tried to clarify the existing policy allowing Binary SI units since Fnagton had turned the policy on its head, misinterpreting the plain language of the existing policy to not allow Binary SI units. I for one will not support any policy that deprecates Binary SI units. ] (]) 00:17, 22 March 2008 (UTC)

* ''P-u-h-l-e-e-ze''! Who are you trying to kid? Do you think the rest of us here are not going to read and parse the logic of what you just wrote? The goal in all technical writing is to clearly communicate to the intended audience with minimal confusion. Do you really expect us to believe that the typical reader of the computer-related articles here on Misplaced Pages are members of Institute of Electrical and Electronics Engineers or the International Electrotechnical Commission? That’s a metric ton of weapons-grade bullonium and you know it Tom. Other encyclopedias don’t routinely use the IEC&nbsp;60027-2 binary prefixes in numerical equivalencies to denote the capacity of computer memory and storage for one reason only: <u>because such symbols aren’t used in the computer industry or their packaging, manuals, or advertising, nor do any general-circulation computer magazines use them</u>. Consequently, the terms are unfamiliar to the typical general-interest reader. This much is just too obvious.<p><!--

-->Finally, as to your characterization of Fnagaton as a “rabid” editor pushing a POV, I suggest you go cool off in a corner somewhere and come back when you have something to add that can remotely be considered as constructive. ] (''])'' 02:22, 22 March 2008 (UTC)

::# Software and research papers use them.
::# Fnagaton should have been blocked with Sarenne. — ] 04:05, 22 March 2008 (UTC)

:::Your repeated misrepresentation, threats about blocking and personal attacks show that you are continuing use harassment against me instead of tackling the issue. The fact remains you are in the wrong so stop using personal attacks otherwise I will be forced to report you again. ''']]''' 11:05, 23 March 2008 (UTC)

::Please be respectful toward other editors. Tom is correct that the IEEE-CS is one of the leading publishers of scientific articles related to communications and computing (the IEEE as a whole may even be ''the'' leading such publisher), and ''that'' (not society membership) is relevant to the standard set out in the "Which system to use" text that you yourself have previously cited. I do not know what units are the most common in IEEE-CS papers.

::And while I am not singling anyone out, it is a factual statement that a number of editors have been pretty rabid about removing IEC units from the encyclopedia, and some of them have in fact misinterpreted or misrepresented the contemporary wording of MOSNUM to be more strongly anti-IEC than was intended. Virtually any time anything related to binary units is brought up on this page, we hear the refrain of "IEC units must be banned", and then an argument usually ensues. — ] ]/] 06:49, 22 March 2008 (UTC)

* Omegatron, Regarding point #1, I’m sure that’s true. But you know as well as I do why that’s not enough. As for point #2, that’s water under the bridge and is no relevance to moving forward with developing a MOSNUM policy that makes better sense than what we currently have. ] (''])'' 04:13, 22 March 2008 (UTC)

::Greg L, since when do "packaging, manuals, advertising or general-circulation computer magazines" constitute scientific literature? I don't believe the standard is the knowledge of the general purpose reader; my wife, for example, college educated and a competent computer user doesn't know the difference between byte and bit, much less MB vs MiB vs 2<sup>20</sub>B. And given her college experience, she well knows kilo = 1,000. All technical articles run into this problem and need linkages and/or footnotes to help such users. If an editor chooses to use Binary SI prefixes either as first article or for disambiguation, IMO, a link is the best way to clarify the meaning for the "general purpose reader." BTW, I think what i wrote is rather straight forward and doesn't need any parsing, perhaps u should cool down. Also, since at least Omegatron, TBird2 and I don't support deprecating, there is no consensus to change the currently posted MOS, agree? ] (]) 05:25, 22 March 2008 (UTC)

:::The SI system usually comes under consideration when debating policy here, but WP is under no obligation to follow it. SI is made for numerous modes and registers, whereas WP is purely online and for a wide range of readers. ] ] 07:56, 22 March 2008 (UTC)

::* You’re taking the “scientific literature” term far too literally Tom. It means the real-world writings the typical Misplaced Pages reader will likely encounter elsewhere and that obviously doesn’t mean draft standards and policy papers from the International Electrotechnical Commission; that much is just common sense as it applies to “communicating with the intended audience.” The lead-in to the draft proposal laid out the premiss for the policy clearly enough: ''“The 1999 ] proposal on ] (]) … has not been widely adopted by the computing industry and trade magazines and is therefore unfamiliar to most readers.”'' In this context “real world” as it applies to our typical reader obviously means all the brochures, data sheets, advertisements, owners manuals, and magazines one encounters in real life.<p><!--

-->Note footnote #1 in the ‘Seagate’ example; I lifted that text verbatim right off the Seagate data sheet for that hard drive. That’s how the “real world” disambiguates the term “GB.” That’s what readers are exposed to in real life. Few knew here at MOSNUM when we permitted use of the IEC&nbsp;60027-2 prefixes that Misplaced Pages would effectively be marching off into the snow proudly blowing our “Follow Me!” kazoos, only to find that no one else in the industry nor any other encyclopedia or magazine was inclined to even look out of their cabin windows at us on this one. Misplaced Pages is alone on this and it’s unwise to continue to embrace such a failed policy.<p><!--

-->Now, having read your argument above, as well as your “straight forward” words on topics as varied as describing another editor being “rabid”, I think you’ve made your feelings abundantly clear here. You believe explaining the magnitude of values using terms like “GiB” is a good idea and you won’t be changing your mind any time soon. I’ll assume we can mark you down in the “Don’t like this proposal” column. Fair enough? ] (''])'' 09:23, 22 March 2008 (UTC)

:::: You can mark me down as opposing this proposal and any other that deprecates SI Binary Prefixes. By my count there are now four editors so inclined. BTW, you really do need to cool off, "''... marching off into the snow proudly blowing our “Follow Me!” kazoos ...''" - give me a break. 22:42, 22 March 2008 (UTC) <small>—Preceding ] comment added by ] (] • ]) </small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->

::::* I’m not at all upset up on this. Your unfounded suggestion that I am does not establish you as the wise, cool-headed voice of reason here Tom. I simply think your position on this is unwise and the current policy does readers of Misplaced Pages a disservice. Note that I haven’t written any computer articles here on Misplaced Pages so I don’t have a vested interest in this as an editor. I subscribe to several computer magazines and daily read on-line computer magazines. The first time I encountered the IEC prefixes was here on Misplaced Pages. This is obviously my personal opinion, but my reaction that first time was to to bury my head and say “Oh, geeze” to myself. Embarrassment. ] (''])'' 23:33, 22 March 2008 (UTC)

:::::Tom is correct that your rhetoric and dismissive attitude are not helpful (nor are they new to discussions of this issue). It would be much more productive if you put less effort into denigrating opposing viewpoints and more effort into explaining how advertising is "scientific literature". Additionally, not having worked on any computer articles in the project is not the positive you seem to think it is; if anything, it suggests you may not have had to actually deal with this issue in a meaningful way and undercuts your "I am absolutely right" stance. There are certainly people whose opinion on this issue is colored by their experience editing a subset of Misplaced Pages's computing articles, but that does not somehow turn a complete lack of experience into a positive. — ] ]/] 01:55, 23 March 2008 (UTC)

:::::* We’ll have to agree to disagree on how one argues a point Aluvus. There is a big difference between attacking the individual and exposing the shortcomings in his arguments. That how debate is accomplished; you know that as much as I do. I can’t help it if my choosing to avoid authoring Misplaced Pages articles on computers doesn’t impress anyone; the point is, I’m am not coming into this debate with an agenda to protect prior work. As for “scientific literature”, as I stated before, I withdrew that verbiage from the proposal over 24 hours ago (see the below post) as it just detracts from the obvious point: the IEC prefixes are unfamiliar terms to the typical reader and only adds to confusion. Efforts to obfuscate on this, as others have done by rhetorically asking “what magazines?” (what parallel universe?) will prove unsuccessful in overcoming this obvious reality. Trying to “have it both ways,” as you pointed out, doesn’t work and continued use of terms like “GiB” doesn’t make Misplaced Pages look proffesional, it makes Misplaced Pages look foolish IMO. You previously stated that my latest proposal was the “least bad” one you’ve seen advanced so far. Does that mean you are disposed to support it in an up-or-down vote? ] (''])'' 03:19, 23 March 2008 (UTC)

::::::You do not get to "agree to disagree" your way out of ]. And rhetoric about kazoos does not expose the shortcomings in any argument but your own. The entire thrust of your argument appears to be "it is obvious that using IEC prefixes is bad", but the very fact that there is disagreement here should indicate to you that '''that is not obvious''' to all parties. Numerous variations of that same tactic, often combined with the same dismissive attitude, have been tried on this page in the past, and they have consistently served to lower the level of the discourse. One of the primary reasons that discussions of this issue have repeatedly broken down is that people have dismissed out of hand any viewpoints they don't agree with, which makes it difficult or impossible to build genuine consensus. And as a final note, it is inappropriate to attempt to pressure me into voting in your favor, and also inappropriate to call a poll on a proposal that by all appearances is still in flux and has not been discussed. — ] ]/] 08:15, 23 March 2008 (UTC)

::::::* I don’t think I am being uncivil at all. If one reads ] (as I just did). It says ''“ is calling someone a "crank" "moron" or "POV-pusher", among others.”'' It further specifically defines it as ''“personally targeted''” attacks. I have consistently only gone so far as to ridicule some others’ ''arguments'', not them personally. That is “debate.” I am now taking deep interest in your lack of taking a balanced position throughout this debate. It comes across as having a strong position on this matter while trying to appear that you aren’t. Tom94022 in his 00:17, 22 March 2008 (UTC) post said ''“ POV of a <u>rabid</u> editors such as Fnagaton”'' (my emphasis). <u>That was so ''clearly'' a prohibited and over-the-line, direct personal attack on another editor and was absolutely unwarranted.</u> And I responded (politely) to it. Yet you attacked me for admonishing Tom about his personal attack! In fact, you wrote ''“And while I am not singling anyone out, it is a factual statement that a number of editors have been pretty rabid about…”''. In other words, you called another editor rabid and hid behind the apron strings of civility by stating ''“I am not singling anyone out…”'' when it was obvious that the individual being targeted was Fnagaton.<p>I’ve noted a strong tendency on this page for you to 1) argue about “how” issues are debated here rather than the substance, and 2) for you to attempt to craft language that looks balanced and measured but really isn’t. You accused me of being uncivil when I clearly haven’t and yet defended and even participated via proxy in the most extreme practices of it. I am done arguing with you about "how” people make their points here—particularly when you try to use slight-of-hand to engage in personal attacks yourself. I will no longer be baited by your diversions. Please stick to arguing on the points. 19:43, 23 March 2008 (UTC)

:::::::The nutshell description of ] is: "Participate in a respectful and civil way. Do not ignore the positions and conclusions of others. Try to discourage others from being uncivil, and be careful to avoid offending people unintentionally." When you write ''"P-u-h-l-e-e-ze! Who are you trying to kid? Do you think the rest of us here are not going to read and parse the logic of what you just wrote?"'' or ''"metric ton of weapons-grade bullonium"'' or ''"come back when you have something to add that can remotely be considered as constructive"'', that is not a civil or polite way to deal with people. Ridiculing arguments '''is not civil''' and is the crux of why this issue has still not been resolved. I do not claim to be balanced or neutral on this or any other disagreement, but I am damn tired of seeing months-long angry arguments about it that go nowhere or turn into wars of attrition. I will think on what I have previously written; I would encourage you to do the same. — ] ]/] 23:02, 23 March 2008 (UTC)

:::::::*Aluvus, I am quite disgusted with all this arguing with you about "how” people make their points here since recent history on this page shows that you have a far from stellar record in the “civility” department by flat out stating that other editors have been “rabid” and pushing a POV. That is absolutely prohibited behavior. As I stated before, I am entirely disinterested in engaging in all this name calling and I will no longer be baited by these diversions. Please stick to arguing on the merits of the proposal. You seem to be suggesting that the only reason people oppose deprecating IEC prefixes all boils down to “Greg L is a poopy-head in his advocacy and if it weren’t for that, I might support his proposal.” While that ''might'' be the case, mark me down as a skeptic on that one. Why don’t you just admit that you like the IEC units and don’t agree with any policy that calls for them to be removed from Misplaced Pages? I would ''very'' much appreciate a statement like that than have to endure any more of your games. Now please take your parting shot below and make it a good one as I will no longer be responding directly to you; it is clearly unproductive and fruitless. Goodbye. ] (''])'' 01:49, 24 March 2008 (UTC)

::::::::Attacking me does not accomplish anything. People oppose deprecating the IEC prefixes because they think the IEC prefixes are useful. Your berating those people seems to have done little to change their minds. If anything, it has simply made them oppose you more strongly, ''just like every time someone else has tried the same tactic before''. I have tried to encourage you to actually engage people in discussion, or at the very least to direct your rhetoric at me instead of other participants, so that this might finally be settled. Because I can assure you, if you continue to belittle opposing viewpoints and tell people they should "admit" that they disagree with you, the people with opinions on this issue will just dig in their heels yet again (some of them already have; did you notice?). That usually leads to a protracted, mostly silly fight that in turn leads (at best) to a problematic compromise built on weak consensus, and then a few weeks or months later there is a new spark and the cycle begins again. This has happened over and over again.

*I for one am tiring of this belligerent, hysterical, personalised approach, Alvulus: I must ask you to ''desist'' and to show more collaborative spirit. As far as I can see, Greg has done a fine job in trying to find a solution to this issue, and has shown a good deal more talent and imagination than you, who've done nothing but inject negative sentiment into the discourse. I can't find a scrap of your previous post that I agree with, and as for the edit summary—that's just ramping up you hysteria. STOP IT, please. ] ] 06:03, 24 March 2008 (UTC)
::::::::You have an opportunity to build a stronger consensus and a lasting policy; stop wasting it. — ] ]/] 05:34, 24 March 2008 (UTC)
::::::::I agree with Tony that the behaviour of Aluvus is completely unacceptable and disruptive. Aluvus is being uncivil. Aluvus should strike his comments from the page and apologise to everyone and specifically to Greg, Tony and myself. ''']]''' 15:37, 24 March 2008 (UTC)

* All: I realize now that quoting “use what’s in the scientific literature” is an ineffective and unpersuasive argument so I deleted it from the proposal. It was pulling the thrust of the predicate off track. As you can see, it now focuses exclusively on the “well… ''duhhhh”'' point, which is that if it’s not recognized by the typical reader and isn’t used in the real-world popular press and even the computer industry, it’s clearly of no value in an encyclopedia.<p><!--

-->I also added proposed text that specifically addresses how to deprecate the IEC&nbsp;60027-2 prefixes from existing articles. I added this because I saw in some of Fnagaton’s writings that this has been a hot-button issue. I don’t know if this is of any real value, but it’s a starting point to build off from (or discard) and is now available for comment. My main motivation for adding it was so that this proposed policy directly addresses the subject of deprecating existing articles and can’t be interpreted as applying only new ones.<p><!--

-->Aluvus: I much enjoyed your 06:29, 22 March 2008 (UTC) post in which you stated…

::{{quotation|I consider this proposal less bad than many that have come before, and an improvement on the current guidance. That is only because I dislike the "split the baby in half" solutions, and because there is a possibility that this would actually settle the matter for more than a month.}}

:Although a damn funny way to characterize it, I can see the truth behind it; I suppose that’s what makes it humorous. I hope you still support helping to put this issue to rest once and for all. ] (''])'' 09:53, 22 March 2008 (UTC)

:Checking the history Omegatron made this to the guideline without talking about it here first. The changes are clearly pushing his POV and ignores consensus. The user then started to edit war when his change was reverted and made personal attacks and threats about using blocks to try to make sure his version stayed on the project page. These bad faith actions are documented in the ANI . ] (]) 12:35, 22 March 2008 (UTC)

:: I'm allowed to change the guideline without talking about it first. If you have a problem with my edits, you can then change them to make a compromise version that you agree with, or you revert them ''and then discuss your reversion''. After discussion, we understand where each other is coming from and try to change it again, while working together. This is how editing works. See ] and ]. You don't just revert war everything back to your preferred version and claim that it represents community consensus.

:: And I seriously hope no one's trying to "deprecate" the standardized prefixes on WP. Please don't start that endless argument again. Sarenne was banned for pushing his POV all over the project, and you will be too. There is no site-wide consensus on use of prefixes, so they are decided on an article-by-article basis. In some articles they are appropriate and serve a useful purpose (], ]); in others it is acceptable to use the ambiguous units because they are familiar to that particular field (]). — ] 15:11, 22 March 2008 (UTC)

::What do Omegatron's edits more than 3 months ago have to do with anything, Fnagaton? — ] ]/] 17:44, 22 March 2008 (UTC)

:::What do Omegatron's pathetic threats about "should have been blocked with Sarenne" have to do with this topic? They do not have anything to do with the topic of course, they are personal attacks and must stop.''']]''' 11:58, 23 March 2008 (UTC)

::::Two wrongs do not make a right. — ] ]/] 23:02, 23 March 2008 (UTC)

:::::Now you are using misrepresentation because what I have done is not wrong by any stretch of the imagination, so I demand you retract what you posted because it is untrue insinuation. What I have done is show why Omegatron is wrong and produced a better argument which helped result in the guideline being changed to something he doesn't support. You and Omegatron are in the wrong here as demonstrated by Tony's comment above. ''']]''' 15:34, 24 March 2008 (UTC)

=== The current wording is good, but needs some fixes ===

I made some small changes to neutralize the section, but there are bigger changes to be made that I'm obviously not going to be bold about:

{{quote|There is consensus that editors should not change prefixes from one style to the other, especially if there is uncertainty as to which term is appropriate within the context}}

The consensus is not to be a ] and change everything to your preferred style. There is no reason why you can't change one style to another if there's a good reason to do so, as long as you aren't revert warring or going against the consensus on the talk page of the article you are editing.

{{quote|and follow the lead of the first major contributor.}}

Should be removed. This is inherently anti-consensus, as I've explained elsewhere. Without global consensus, you decide based on good reasons, not on arbitrary precedent.

{{quote|These replacements for the historical units have gained only limited acceptance outside the standards organizations. Most publications}}

This is biased ("only limited acceptance") and implies a level of certainty that can't exist. How do you define "acceptance"? Most ''what'' publications? Do multiple copies of the same publication count? I'm pretty certain most hard drive manufacturer publications use the standard prefixes. Who tallied them all up? What about software? What about the myriad Linux servers hosting all of the web pages you view? I see IEC prefixes on a daily basis. Should we go with your personal experience or mine? — ] 15:48, 22 March 2008 (UTC)

: I support the changes just made by Omegatron. ] (]) 16:02, 22 March 2008 (UTC)

: I support the changes just made by Omegatron. ] (]) 16:47, 22 March 2008 (UTC)

: I oppose the changes <small>—Preceding ] comment added by ] (] • ]) 06:29, 23 March 2008 (UTC)</small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->

: I oppose the changes for the reasons stated below by DavidPaulHamilton: The changes to the main page split the baby in half by using prefixes that are unknown to the general population. ] (''])'' 18:42, 23 March 2008 (UTC)

::And what specifically do you disagree with? Bearing in mind that the points he raises here and the changes he actually made are quite different, of course. — ] ]/] 07:22, 23 March 2008 (UTC)

:: The changes to the main page split the baby in half by using prefixes that are unknown to the general population. ] (]) 09:29, 23 March 2008 (UTC)

::* So why, David, don’t you also make your feelings known ] on ]? ] (''])'' 18:53, 23 March 2008 (UTC)

:::The existing wording ''already'' did those things, so you have not provided any reason to oppose Omegatron's changes specifically. Omegatron's changes were minor wording tweaks that had no impact on what the guidance actually tells people to do. In what way was the previous wording superior? — ] ]/] 22:10, 23 March 2008 (UTC)

* Omegatron: You’re setting an unnecessarily high hurdle when you challenge opponents of your view to enumerate every single publication on Earth that uses one style or another. Clearly, a ''common-sense'' test should suffice and any quick inventory of the general-interest on-line and in-print computer publications demonstrates that “GiB” isn’t currently being used and that’s why such terms are unfamiliar to most readers. The test shouldn’t be what policy best makes a few Misplaced Pages editors happiest, it should only be whether or not Misplaced Pages is best serving the interests of its readers.<p><!--

-->And please leave the formatting and style of the proposal alone. When you deleted all the horizontal rules and made sections ''within'' the proposal their own “====” article sections, it made it ''even harder'' to discern where the proposal starts and ends, which is already hard enough given the length of some of these threads. ] (''])'' 18:48, 22 March 2008 (UTC)

: '''Oppose''' - Omegatron's changes to the guideline and those talked about here (as Aluvus said they are quite different) are not an improvement. A couple of direct questions to Omegatron. 1) Why do you make changes to the guildeine without talking about them first? 2) Are you interested in seeing a fair and balanced guideline? ''']]''' 11:00, 23 March 2008 (UTC)

:: Let’s try to find some common ground, and tackle this one step at a time. The first edit Omegatron made was an attempt to remove the POV from the opening sentence, which right now reads:
::* In computing, where ] (powers of 2) are often more useful than ] (powers of ten), the de facto standard for ]es and symbols (collectively, "units") is to use ''kilo-'', ''mega-'', ''giga-'', with symbols K, M, G, where each successive prefix is multiplied by 1024 (2<sup>10</sup>) rather than ]'s 1000 (10<sup>3</sup>). To attempt to resolve this ambiguity …

:: This gives the unwarranted impression that the binary use is more common than decimal. I don't recall Omegatron's precise phrasing, so I'm going to attempt my own. How about:
::* In some fields of computing, ] (powers of 2) are more useful than ] (powers of ten). In others the reverse is true. As a consequence there are two different de facto standards for defining symbols K, M, G (representing prefixes kilo-, mega- and giga-, respectively), one in powers of 1024 (2<sup>10</sup>), and the other following the SI prefixes convention using powers of 1000 (10<sup>3</sup>). To attempt to resolve this ambiguity …

:: Constructive comments are requested from, and a happy Easter is wished to, all at MOSNUM. ] (]) 13:36, 23 March 2008 (UTC)

::: I want Omegatron to answer the questions put to him first before I respond to your points Thunderbird2 because the conclusion from what you posted is contingent on what he writes. ''']]''' 16:40, 23 March 2008 (UTC)

::::Your first question is a red herring, as it always has been; no one is obligated to get permission on Talk before making minor changes. The second one should be easy for you to resolve yourself by ]. So no, nothing of any importance really hinges on those questions. If you have an opinion on what Thunderbird2 has written, you may as well get on with it. — ] ]/] 22:10, 23 March 2008 (UTC)

:::::I'm asking Omegatron, not you Aluvus. Unless you are now admitting you and Omegatron are one and the same? As for your answers they are easily demonstrated to be wrong. Firstly look at the header of the project page "Edit this page through consensus, '''discussing proposed changes on the talk page first'''." Since the changes he made were not minor, as demonstrated by the fact that you are wrong when you say "no one is obligated to get permission on Talk before making minor changes". Secondly, assumption of good faith is not the catch all answer to everything and my question is a valid concern about what Omegatron wants to see in the guideline. So my questions stand for Omegatron to answer. As I say my responce to Thunderbird2 is contingent on what what Omegatron writes in reply. Depending on what he writes another couple of questions may also be needed. ''']]''' 15:13, 24 March 2008 (UTC)

:::For reference, this was actually the second edit he made, and the appropriate diff is . — ] ]/] 22:10, 23 March 2008 (UTC)

::::Omegatron made three quick , not just the one you linked. ''']]''' 15:13, 24 March 2008 (UTC)

=== Standardisation is a good thing ===

I was asked to come here and comment by Greg L, probably since I am an old software engineer and not a mathematician. But he is not going to like my answer:

I grew up and still live in Sweden, where as far as I know we switched to SI units for most measurements already in the 1800s, an switched to SI notation for date and time somewhere mid 1900s or so. Since they are not ambiguous and can more easily be handled by computers, such as sorting and converting them. The Japanese and many other countries did the same modernisation long ago too.

So when I write date and time I write 2008-03-23, 18:00. I do not write 23 March 2008, 6 p.m., or should that be 6 a.m.? And if I use the old Swedish notation 6 f.m./e.m. then I guess most of you have no idea of what that means, right? See, a.m./p.m. is even language specific! See the benefits of standardisation?

So basically, I disagree with Greg. I like the new SI units ] for 2<sup>30</sup> bytes. Since it is less ambiguous. I just wish we had a non-ambiguous unit for 10<sup>9</sup> bytes too, but currently we don't.

When we use GiB in articles then we need to put a footnote or paranthesis explaining that 1 GiB = 2<sup>30</sup> bytes = 1,073,741,824 bytes, since as you people have mentioned here many readers do not know what it means. But if we use GB then we have to put a footnote anyway to tell which GB we mean. So there really isn't much difference. So I say we are an encyclopaedia and should go with the best possible notation, at least as long as it is reasonably easy to understand. (I would ''not'' like to see room temperature written in Kelvin...)

--] (]) 2008-03-23, 02:16 (UTC)

:Okay, with the risk of starting a flame war: I feel I have to say something very unpleasant. I think Greg L or someone posing as him is trying to "]" on this. (Perhaps to make Greg look bad? So it might be someone opposed to him. Conspiracies galore! Now it suddenly feels more like fun than unpleasant. #:))
:Seemingly while he still thought I preferred GB over GiB "he" left on my talk page. Note that he is asking me to come vote in his favour when the time comes, and asks me for others that might have the same point of view. And especially note that the edit is done by an IP user so will not be visible in Greg L's "user contributions", still he went to the trouble of manually adding his full signature.
:Please try to stick to logical arguments instead of trying to stuff ballots on this, whoever you were that left that edit. Okay?
:Although GiB vs GB is perhaps more a matter of personal taste than logical arguments so it is a tricky case. (Since the logical arguments there are goes both ways, so no side has a clear advantage.)
:--] (]) 03:50, 23 March 2008 (UTC)

: David, the issue here is context. If I told you my computer has 3 GB of memory, would you (or ''anyone on the planet'', for that matter) believe that I am saying that I have 3,000,000,000 bytes of memory? No, of course not. "GB", in the context of memory, is always, 100% of the time, understood to be in powers of two.

: Misplaced Pages's responsibility to the world is to present the world ''as it is'', not as we as individuals want it to be. We as people with the goal of writing a great encyclopedia are naturally idealistic, but the content we produce must be pragmatic and realistic. This means that we don't push our views on our readers; this extends to what we as individuals may think the "right" unit of measurement is, or what the "right" spelling of a word is. The guidelines, as it stands now, encourages the use of the unit of measurement that's common within its field. In our computing articles, we tend towards KB, MB, etc.; this is very similar to how articles on American topics are going to present measurements gasoline in gallons and distance in miles. In terms of serving our most likely readers in any given topic, this works out very well, because it has the highest chance of understanding. <span style="color:blue;font-weight:bold;font-family: Monotype Corsiva;"> ] ]</span> 04:48, 23 March 2008 (UTC)
::While that may be correct, in principle, I don't think it applies here. Advertising and other informal communications often use slang and loose, ambiguous terminology. On the other hand, we are a formal reference work, and owe it to our readers to be ''technically correct''. We use words according to their dictionary definition, not according to their informal usage. In the case of technical terminology, the major standards organizations write the dictionaries, and they have stated unequivocally that "mega" means 10<sup>6</sup> and ''only'' 10<sup>6</sup>, and that the only technically correct way of representing 2<sup>20</sup> with a prefix is to use the prefix "mebi". As with many words, informal and technically incorrect usage of words is common, but it is not appropriate for a formal reference work, even if common. "Representing the world as it is" would simply mean stating in the ] article that in common usage, the decimal terminologies often ''are'' used to represent binary values. But we should not follow this example, because of the simple fact that it is not correct, based on the definitions of the terms set by those authorities tasked with defining them. We should not knowingly present incorrect or ambiguous information, even if the practice is a common one. ] <small><sup>]</sup></small> 08:56, 23 March 2008 (UTC)

:::The "technically correct" argument is not the Misplaced Pages way of writing articles because "technically correct" is actually decided by real world consensus and Misplaced Pages does not always follow what a "standards organisation" says. Misplaced Pages wisely make the choice that real world consensus trumps standards bodies, see my talk page for an excellent example. Also your statement is not accurate because the JEDEC, which is a standards organisation, does state that mega and kilo use powers of two. So the only sensible option is for Misplaced Pages to use what is commonly used in the real world because that is the most widely understood, this means for the majoirty of articles that IEC prefixes should not be used. This is a natural function of real world use and wanting to be widely understood by the majority of people and has nothing to do with being for or against any particular "standard body" per se. ''']]''' 11:11, 23 March 2008 (UTC)
:::: I repeat myself: The question is not whether IEC prefixes are used frequently, but whether they are used frequently ''in publications that try to be unambiguous'', because that is what we (or most of us) want to be. The IEC symbols are certainly the most popular ones in these cases. (I have seen ''BB'' once, for ''billion bytes'', but nothing else. Subscripts have been suggested here: ''GB<sub>16</sub>''.) The IEC names are not as frequent as the symbols in my experience and they sound ugly, that is why I suggested the self-explanatory term ''binary megabyte'' (in contrast to ''decimal megabyte'' where necessary) instead. The added ''i'' does not seriously obfuscate the unit, it just gives more exact information to the knowledged reader while others would (hopefully) read it as if the ''i'' was not there.
:::: I have never concealed my preference for simple and straight guidelines even if they were specific to Misplaced Pages. Allowing a binary meaning for SI prefixes in certain contexts – i.e. semiconductor storage capacity and perhaps file sizes – was already a step of mine towards compromise. I suggested to specify defaults in MOSNUM, so not every page needed explanatory footnotes. Footnotes, by the way, are not a desirable thing in neither encyclopaedias nor hypertext, (hyper)links are more appropriate and sufficient.
:::: I started off by criticising Fnagaton’s proposal, but soon found that to be less explicit than writing a counter proposal, because his one was too anti-IEC, although overall sounder than I expected based on his hostile, uncompromising attitude exposed in Talk several times (with like responses of course). I tried to make it more general (to also apply to tons, pounds etc.), too, which probably lead to it being perceived as not precise enough. — ] ] 20:29, 23 March 2008 (UTC)
::::: You repeat yourself yet you are still wrong for exactly the same reasons I have already given. My proposal is not anti-IEC. Not once does my proposal say "do not to use IEC prefixes". I'll give you a chance though, if you can prove where my proposal is specifically "anti-IEC" then you'll get an apology. If you cannot then you admit you are wrong and I expect you to retract what you just wrote. My proposal uses the most clear and precise way to disambiguate prefixes which is to use mathematics to make it completely unambiguous about the exact number of bytes being used in a particular situation. It also does it in such a way without advocating any particular prefix system, therefore removing any chance that personal bias of the editor is in the guideline. Also I demand you retract you untrue allegations about "hostile, uncompromising attitude" because I present a clear argument and I do not resort to the kind of personal attack you have just demonstrated to try to score points. ''']]''' 15:54, 24 March 2008 (UTC)
:::::: You are right, your proposal does not say “do not use IEC prefixes”, because it does not mention them at all! That is pretty ''anti'' in my book. Instead you write “Editors must use the units/prefixes employed in the sources used by the article.” As I have shown that would only be a good recommendation, ''if'' those sources were disambiguating (inline), which most do not.
:::::: I repeated myself, because neither you nor anyone else has countered that point. The section ] ended with my notion that “real world consensus is that IEC prefixes are ''one way'' to achieve disambiguity where needed”.
:::::: Your constant calling people wrong and demanding retreats constitute the hostility, your unwillingness to accept IEC prefixes ''at all'' – direct quotes you cannot touch – constitutes the uncompromising attitude. It does not matter for the reception whether you perceive or mean it like that. — ] ] 18:32, 24 March 2008 (UTC)
::::::: Not mentioning something is not "anti" that something, it is also not "for" that something. It is neutral, it is unbiased. So you admit you are wrong. When are you going to retract what you wrote? You are also wrong in your last paragraph, when people are wrong it is more polite to tell them as opposed to the kind of personal attacks you resort to. Also when someone writes something that is not true, like you have been doing, then they should retract it and there is no harm in pointing that out. You are making the mistake of confusing "uncompromising position" with "not accepting rubbish". It is easy to demonstrate you are wrong here because the fact is I made a proposal, then Greg comes along and makes another proposal. What do I do? I support his proposal. If I had an "uncompromising position" as you claim then I would not have supported it. You are therefore claiming and writing rubbish. Q.E.D. By repeating such baseless accusations you are also being uncivil, disruptive and making personal attacks. What you wrote has been countered or has nothing relevant to start with, for example when you wrote the "least space-taking solution..." post that uses entirely irrelevant POV which ignores what was already said before. It is easily demonstrated that the -bi prefixes are not the "most established solution" as you claimed. You are also using misrepresentation because what you wrote about "your unwillingness to accept IEC prefixes ''at all''" is completely untrue, so I also demand that you retract that. I have no problem with IEC prefixes being used if that is the consensus as shown the the sources used in an article, the fact is for the majority of articles that is not thee case. Stop with the personal attacks right now, this is not the first time I've had to point this out to you. If you cannot be civil and debate the actual topic then I suggest you take a break and do not post here on this topic. As the flow of that discussion shows your "solution" is not a viable solution, for the reasons given at the time and by the fact that you made a comment 18 days (!!!) after the last post in the thread had been made and you did not even think to put a note on the involved editors talk pages, so there was little point going over what you kept on repeating. You will not get your own way on every single post that you make. Just so you are clear, telling someone they are wrong is not a personal attack. If you react badly to being told you are wrong then you have two viable choices. 1) Don't be wrong. 2) Don't post on Misplaced Pages. The choice you make, using personal attacks, is not a viable option. ''']]''' 19:03, 24 March 2008 (UTC)

Why are you wasting your precious time with this guy? I've seen walls which were more flexible and intelligent. --] (]) 20:01, 24 March 2008 (UTC)

== Years ==

'''Start of discussion moved from Lightmouse talk page'''<br>
You had best stop un-bracketing years until you get some consensus. I'm reporting this to ]. ] <sup>'']''</sup> 12:59, 20 March 2008 (UTC)

:You were already blocked once for this activity. STOP IT. ] <sup>'']''</sup> 13:03, 20 March 2008 (UTC)

::Right I don't know what is going on here but please stop for now. Contribute to the discussion on the but stop delinking the dates. ] | ] 13:10, 20 March 2008 (UTC)

:::As I understand it, the place to debate policy on dates is ]. Feel free to raise it there. ] (]) 13:13, 20 March 2008 (UTC)

::::First rule: Don't cop an attitude with an admin. ] <sup>'']''</sup> 13:17, 20 March 2008 (UTC)

::::That's fine I don't care. Lightmouse I do not wish to debate the policy. I only wish to make sure that you actually have concensus for your changes. Can you point me to the discussion that shows this please. ] | ] 13:20, 20 March 2008 (UTC)

:::::At the very least, the user did not get consensus from anyone to clobber the "year in baseball" template entries. ] <sup>'']''</sup> 13:41, 20 March 2008 (UTC)
Lightmouse, you continued making controversial edits after you've been contacted abouts this. I've withdrawn your AWB approval for duration of discussion at ]. Please respond there. ]<sup>(])</sup> 14:02, 20 March 2008 (UTC)
::::::Baseball Bugs, I am not sure what 'cop an attitude' means but that phrase along with the word 'defiant' used elsewhere sounds like an accusation of incivility. I have no incivil intentions in my responses. I try to be polite and expect the same from others. Please assume good faith.

::::::There are popular misconceptions about date links so it does not surprise me that it is being questioned. I would prefer not to describe the policy here. Quite apart from anything else, you may not feel comfortable with what I say about it. There are plenty of other editors there that have extensive experience with this issue at ]. I would be happy to see you there. I hope that helps. ] (]) 14:36, 20 March 2008 (UTC)
'''End of discussion moved from Lightmouse talk page'''

*Hard to discern what this is about. If Lightmouse is delinking trivial chronological itmes, such as ''1998'' and ''1970s'' and ''20th century'', I applaud it. He has the weight of MOS behind him. Read the guidelines, please.] ] 02:57, 23 March 2008 (UTC)

:: I randomly selected about 25 of Lightmouse's recent edits of this nature, and they all seem well within current date policy to me. <span style="color:blue;font-weight:bold;font-family: Monotype Corsiva;"> ] ]</span> 04:25, 23 March 2008 (UTC)

::: I have the impression that Lightmouse was, as usual, implementing MOSNUM consensus, when an admin over-reacted to a change that was not to his liking. The discussion of the entire non-incident is archived . ] (]) 15:31, 23 March 2008 (UTC)

:::: I've just noticed that Lightmouse has not done any editing since . I hope he is just taking an Easter break. ] (]) 15:36, 23 March 2008 (UTC)

:::::I have been watching the discussion. I appreciate the contributions made by all. I would appreciate your further assistance in getting my AWB approval reinstated. See the statement above by MaxSem (''I've withdrawn your AWB approval for duration of discussion at ]'') and my request for reinstatement at ].
:::::] (]) 11:03, 24 March 2008 (UTC)

== ] (aka Standard Form) discussion ==

There's a discussion at ] about the prescribed formatting of exponential notation/scientific notation/standard form. Just to make sure interested folks know. ](]) 22:02, 21 March 2008 (UTC)

== Delimitnum revisited ==

I am no mathematician, but I am a crazy software engineer and researcher that like to think outside the box. Or rather look at problems from many angles, like for instance backwards.

So {{tl|delimitnum}} did get a "deadly failure". (See discussion in an earlier section.)

So lets do it the other way around. Instead of chopping up a number using maths and put in commas etc, instead lets put the number together only using strings and no maths.

Here is a basic example:

:<code><nowiki>{{dnum|1|.|123|45|x|10|25|kg}}</nowiki></code>

Which would render something like this :

:1.123 45 × 10<sup>25</sup> kg

And a monster example:

:<code><nowiki>{{dnum|-|1|500|000|.|123|45|(30)|x|10|25|kg}}</nowiki></code>

Which would render something like this :

:&minus;1,500,000.123 45(30) × 10<sup>25</sup> kg

{{delimitnum|-150000.12345|30|25|kg}}

Such numbers should be pretty simple to input since the user only has to input normal dashes "-" and a normal "x", not the special maths symbols. I let them input the base 10 too, since that makes the input more readable and is more flexible. Oh and this of course means that inputting "+" and "000" is no problem either, they will not be dropped when the number is rendered, since it isn't a number that is rendered but rather a string.

I think I know how to code up such a template. The only maths involved here would be to detect that the string "(30)" is not a number, since it seems you guys don't want any spacing between the 45 and the (30). But if you allow a spacing there the template code gets much simpler.

With spacing I of course do not mean "spaces" but the narrow spacing trick mentioned before that makes the numbers copy-and-pasteable to other programs.

Would such a template be useful?

--] (]) 23:43, 22 March 2008 (UTC)

* David, it’s great to hear from someone who’s really interested in what {{tl|delimitnum}} has to offer. As you’ve no-doubt witnessed at the ], using math-based parser functions within a template is a recipe for banging one’s head against a wall. Your proposal sounds like it would be perfectly workable. As you may also have seen on the initial proposal, here on ], the delimiting is done with <nowiki><span></nowiki> tags. That itself shouldn’t be a problem except that spans following the digit 1 are specified slightly narrower so they have the same visual appearance. The ]-based version of {{tl|delimitnum}} will use character-based parser functions as you are proposing. With any luck, we should have it within about a week. Since it will used character-based parsing, it will be imune from rounding issues. For instance, <font color=maroon><code><nowiki>{{delimitnum|1.1200|25||kg}}</nowiki></code></font color> will return 1.1200(25)&nbsp;kg, not 1.12(25)&nbsp;kg.<br><p>Where I could ''really'' use some support right now is on an issue of computer nomenclature. It involves abandoning the use of terms like “250&nbsp;GiB file size” and proposes to adhere to the better-recognized units (e.g. “250&nbsp;GB file size”). What do you think about ] and ] (in light green)? ] (''])'' 00:23, 23 March 2008 (UTC)

::Ah okay. So the {{tl|delimitnum}} magic word is not that far away. Right, then no use in spending time on making a template for it. I noticed some days ago that you were banging your head in the wall with {{tl|delimitnum}}, just had to think for some day what to say.
::Ok, I'll take a look at the GB vs GiB issue although I have to admit I dislike style issues. I am a software engineer, not a stylist. But I guess in the GiB issue you need some engineers.
::--] (]) 01:21, 23 March 2008 (UTC)

Silly, I always forget to ask this, been thinking about it for days: Greg L: Why didn't you use ] to render the numbers? It does have text output for simpler formulas. Or does it render the text to bad?

--] (]) 01:30, 23 March 2008 (UTC)



* David, the biggest advantage of the upcoming magic word is it will automate the job of a grouping the digits. Many users will simply forget that you don’t leave a single dangling digit, like 1.234 456 8. No matter what the editor inputs, the <nowiki>{{delimitnum}}</nowiki> magic word knows to parse as follows:

<span style="margin-left:1em">2.1<br><!--
--><span style="margin-left:1em">2.12<br><!--
--><span style="margin-left:1em">2.123<br><!--
--><span style="margin-left:1em">2.1234<br><!--
--><span style="margin-left:1em">2.123<span style="margin-left:0.25em">45</span><br><!--
--><span style="margin-left:1em">2.123<span style="margin-left:0.25em">456</span><br><!--
--><span style="margin-left:1em">2.123<span style="margin-left:0.25em">4567</span><br><!--
--><span style="margin-left:1em">2.123<span style="margin-left:0.25em">456<span style="margin-left:0.25em">78</span><br><!--
--><span style="margin-left:1em">2.123<span style="margin-left:0.25em">456<span style="margin-left:0.25em">789</span><br><!--
--><span style="margin-left:1em">2.123<span style="margin-left:0.25em">456<span style="margin-left:0.25em">7890</span><br><!--
--><span style="margin-left:1em">2.123<span style="margin-left:0.25em">456<span style="margin-left:0.25em">789<span style="margin-left:0.25em">01</span><br><!--
--><span style="margin-left:1em">2.123<span style="margin-left:0.25em">456<span style="margin-left:0.25em">789<span style="margin-left:0.25em">012</span><br><!--
--><span style="margin-left:1em">2.123<span style="margin-left:0.25em">456<span style="margin-left:0.25em">789<span style="margin-left:0.25em">0123</span>

: Regarding the use of MediaWiki TeX, I do if it’s absolutely necessary, such as for <math>V = \sqrt{\frac {{K_b\over 2} \cdot T}{{m\over 2}}}</math><p>But for straightforward numeric equivalencies, like this:

{{cquote|…the quantity known as the ], is an experimentally determined value that is currently measured as being {{delimitnum|6.02214179|30|23|}} atoms (2006 CODATA value).}}

:…I use either hand coding or the <nowiki>{{delimitnum}}</nowiki> template to avoid the change in text associated with <nowiki><math></nowiki>, which interrupts the reading flow. Regards. ] (''])'' 02:54, 23 March 2008 (UTC)

::1: Ah, I didn't know about how to handle those dangling digits. We delimit numbers differently in my country (Sweden). So yeah, automating it is nice. He, come to think of it, that puts that magic word into trouble, since preferably it should be able to delimit numbers in the right way on all the different language Wikipedias. That coder has a big task ahead of him... Or of course, he could be "lazy" and just do English delimiting and the other languages have to do hand delimiting. Ehm, perhaps I should code a {{tl|dnum}} template for my language instead.
::2: I think you might have misunderstood what I meant by using MediaWiki TeX. The default is that it outputs text, not images, for simpler "formulas". So it doesn't interrupt the reading flow as you thought. Perhaps you have set TeX to only show images in your Misplaced Pages user preferences?
::--] (]) 03:19, 23 March 2008 (UTC)

::* Regarding your point #1 above, Americans don’t usually delimit the fractional side of the significand. Professionally done work does and the only proper way I know originally came from the ISO and is done as illustrated and . Here is the NIST’s , their and their .<P>As for your point #2, I don’t understand. I’ve set my Wiki prefs to “Recommended for modern browsers” and it shows the above example as large symbols. You seem to be suggesting that simple formulas show as straight text. Please provide an example. I am inclined though, to continue to use hand-coded text or use of magic words and templates, as I am certain what the appearance will be for all readers irregardless of their browser and user prefs. ] (''])'' 05:02, 23 March 2008 (UTC)

::*'''P.S.''' If by ''“ differently in my country”'' you mean, the Euro-way: narrow spaces on both sides of the decimal marker, and the decimal marker is a ''comma'', not a full-stop, then yes, it’s done differently in America. And that’s the convention the en.Misplaced Pages standardized upon: comma delimiting to the left of the decimal marker, which is a full a full-stop. The magic word does not even ''pretend'' to change any of that; advocating to do so just would never happen. All it does is add much-needed narrow-space delimiting to the fractional side of the decimal marker. ] (''])'' 05:25, 23 March 2008 (UTC)

::::2: Ah, the point is moot. I tested my user settings for math (MediaWiki TeX rendering). As I remembered I can get it to show as HTML for simple formulas and as PNG when more complex. But in both cases it doesn't delimit numbers. So 123456789.123456789 just shows up like this when using TeX: <math>123456789.123456789</math> So doesn't help us at all. (Of course, I might be using TeX the wrong way.)
::::1: Well, the way I learnt to delimit numbers in school in Sweden is like this:
::::* English: 1,234,567.123 456
::::* Swedish1: 1 234 567,123456
::::* Swedish2: 1.234.567,123 456 or was it 1.234.567,123456
::::My bank statements and my Swedish MS Windows use Swedish 1, and that is the more common way we do it. I have mostly seen Swedish 2 in really old printed matter, as in early 1900s and older.
::::I also took a quick look at the Swedish Misplaced Pages, and there MediaWiki TeX clearly is set to use the decimal comma ",".
::::See what I mean with that the delimitnum magic word will need localisation if to be used in other language Wikipedias? I am not advocating to change the delimiting in English Misplaced Pages, why would I? But magic words are part of the MediaWiki software and as such is supposed to work on all language Wikipedias. And that is why I mentioned it since you seem to be in contact with the dev that is coding that magic word.
::::--] (]) 06:07, 23 March 2008 (UTC)

::::* Yes. I understand enough about the details of the magic word to know that it should be almost trivial to customize it for any language. The hard part is all the parsing logic and the rules governing span width. I was familiar with Swedish1 (and a variant that delimits the same way on the fractional side too). I didn’t know about Swedish2. I like Misplaced Pages because it is such an awesome way to learn. It’s my bed time. Bye. ] (''])'' 06:14, 23 March 2008 (UTC)

::::::Yeah, I agree. Since using narrow spaces seems to be the most popular in most languages it should be trivial to switch between using a decimal "." or ",". And narrow spaces is anyway the delimiting that has the lowest risk of misunderstanding. Anyway, sleep well. Bedtime for me too I think.
::::::--] (]) 06:26, 23 March 2008 (UTC)

Latest revision as of 18:58, 9 January 2025

This is the talk page for discussing improvements to the Manual of Style/Dates and numbers page.
Shortcuts
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 
Peace dove with olive branch in its beakPlease 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:
WikiProject iconManual of Style
WikiProject iconThis 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
Note icon
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.
Note icon
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.

Archiving icon
Archives
General Binary prefixes Years and dates See also

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 205 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.
  6. I'm not willing to spend 5 or minutes figuring out what this line means.
  7. The asterisk as a multiplication sign should be limited to articles about computer languages that use it as such.
  8. 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., x {\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)

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

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

It is high time to end this "minor imbecility". Dondervogel 2 (talk) 18:57, 9 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: