Wikipedia talk:Manual of Style/Dates and numbers: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
→‎The case for equal status: “in their definitions”
 
Line 1: Line 1:
{{talkheader|sc1=WT:DATE|sc2=WT:MOSDATE}}
{{WikiProject Manual of Style}}
{{Calm}}
{{User:MiszaBot/config
{{User:MiszaBot/config
|archiveheader = {{aan}}
|maxarchivesize = 150K
|maxarchivesize = 800K
|counter = 95
|algo = old(15d)
|counter = 162
|minthreadsleft = 2
|archive = Wikipedia talk:Manual of Style (dates and numbers)/Archive %(counter)d
|minthreadstoarchive = 1
|algo = old(60d)
|archive = Wikipedia talk:Manual of Style/Dates and numbers/Archive %(counter)d
}}
}}
{{User:HBC Archive Indexerbot/OptIn
{{Wikipedia talk:Manual of Style (dates and numbers)/Archive box}}
<!--{{Wikipedia talk:Manual of Style (dates and numbers)/Archive box B}}-->
|target=Wikipedia talk:Manual of Style/Dates and numbers/Archive index
{{Wikipedia talk:Manual of Style (dates and numbers)/Archive box D}}
|mask1=Wikipedia talk:Manual of Style/Dates and numbers/Archive <#>
|mask2=Wikipedia talk:Manual of Style/Dates and numbers/Archive zero
|mask3=Wikipedia talk:Manual of Style/Dates and numbers/Archive B<#>
|mask4=Wikipedia talk:Manual of Style/Dates and numbers/Archive D<#>
|leading_zeros=0
|indexhere=yes }}
{{Wikipedia talk:Manual of Style/Dates and numbers/Archive box}}
{{tmbox|image=[[File:Ambox humor.svg|30px|link=|alt=]] |text=It has been '''{{age in days|2023|12|7}} days''' since the outbreak of the latest dispute over date formats.|small=yes}}


== General IT prefix discussion ==
== Revisions to MOS:SEASON ==


{{ping|Premeditated Chaos|Gog the Mild|Mike Christie|SchroCat|FrB.TG}} I've made several changes to [[MOS:SEASON]] following our discussion on [[Wikipedia:Featured article candidates/Oyster dress/archive1]]. Hopefully the revised guideline is clearer, but please do feel free to edit further. Also thanks to @[[User:Gawaon|Gawaon]] for helping clean up the text. [[User:Edge3|Edge3]] ([[User talk:Edge3|talk]]) 19:37, 2 March 2024 (UTC)
The IEC prefixes were approved in January 1999. After nine years, virtually nobody uses them. [[Esperanto]] 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. -- [[User:Swtpc6800|SWTPC6800]] ([[User talk:Swtpc6800|talk]]) 06:09, 17 January 2008 (UTC)
:I think the guidance for magazine issues could be clearer. For example, [https://www.amazon.com/Startling-Stories-H-Beam-Piper/dp/0983953228 this] is the Summer 2012 issue of ''Startling Stories''; it would go against usage in reliable sources not to capitalize that. Can we restore the ''Quarterly Review'' example? On the other hand, if you're simply talking about an issue that came out in the (northern hemisphere) summer of 2012, there's no reason to say "summer 2015 issue" as you now have it; it would usually be better to say "mid-2015" instead. [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 20:24, 2 March 2024 (UTC)
::I removed ''[[Quarterly Review]]'' because it hasn't been published since 1967, so "Summer 2015" is factually incorrect. I suppose you could change it to a historically correct example, such as "Summer 1966". But going to the crux of our issue, Amazon really isn't a reliable source because the product description page was written by the publisher of ''Startling Stories'', so it's not independent. [[MOS:CAPS]] looks at usage in "''independent'', reliable sources" (emphasis added). [[User:Edge3|Edge3]] ([[User talk:Edge3|talk]]) 20:33, 2 March 2024 (UTC)
:::See [[Wikipedia_talk:Manual_of_Style/Dates_and_numbers/Archive_161#Magazine_issue_dates|this archived discussion]] for numerous examples from reliable sources, and in particular see {{u|NebY}}'s comment at the end. The few counter-examples given look to me like cases where the writer was not referring to an issue titled that way, so I'm not even sure all of them are counter-examples. [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 20:37, 2 March 2024 (UTC)
::::Oh interesting! I didn't realize you had previously brought up this issue in 2022. Thanks for sharing it now.
::::I think we're always going to find cases where one publication uses capital letters, and others use lower case. For example, [https://ssir.org/issue/summer_2015 Stanford Social Innovation Review] refers to its own "summer 2015 issue" (lower case) in running text, even when the issue is titled "Summer 2015". [[User:Edge3|Edge3]] ([[User talk:Edge3|talk]]) 20:57, 2 March 2024 (UTC)
:::::Yes, there are certainly exceptions, but there was a strong preponderance of evidence in those examples -- unanimity for genre examples, and majority for others. Given that the previous discussion was closed with a consensus to retain the capital letters for magazine seasonal issues, would you mind reverting that part of your changes while this discussion continues? I think, given the previous discussion, we'd need to demonstrate a new consensus before we could make the change you've made. [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 21:10, 2 March 2024 (UTC)
::::::I'd be happy to, but my concern about the historical inaccuracy of "''Quarterly Review'', Summer 2015" still applies. Do you have a specific example that you like better than that? [[User:Edge3|Edge3]] ([[User talk:Edge3|talk]]) 21:18, 2 March 2024 (UTC)
:::::::How about one of the first two given in that earlier discussion? Either "Spring 1942, ''Tales of Wonder''" or "''Science Fiction Quarterly'', Summer 1942" depending on whether you prefer an example with the date before the title or vice versa. [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 21:31, 2 March 2024 (UTC)
::::::::Mostly these examples seem to be treated as titles, meaning that the usual rules of title case are applied, and so every major word is capitalized. No surprise here. Only the "summer 2015 issue" example mentioned by Edge3 is not title-cased, hence no capital letters. It would be odd to talk about "the Summer 2015 Issue of ''Whatever Magazine''" or "the Summer 2015 issue of ''Whatever Magazine''". No, this is running text and so lowercase letters are called for: "the summer 2015 issue of ''Whatever Magazine''". But when the issue date is mentioned as part of the title, title case is fine: "''Whatever Magazine'', Summer 2015". [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 21:54, 2 March 2024 (UTC)
:::::::::I agree. Perhaps two examples, so that those cases can be distinguished? [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 22:00, 2 March 2024 (UTC)
::::::::::I've added the examples per both of your comments. Feel free to revise further. [[User:Edge3|Edge3]] ([[User talk:Edge3|talk]]) 22:07, 2 March 2024 (UTC)
:::::::::::Actually, looking back at the list of examples from the 2022 discussion, it seems many of the running text examples also use upper case, so I'm not sure I fully agree with that part. My main concern was that we keep an example using title case as that's helpful when (as has happened to me) someone contests that. Personally I think it would be OK to have "the Fall 1943 issue of ''Thrilling Wonder Stories''" which is certainly supported by reliable sources, and if you truly mean "the issue that came out that summer" that in itself is a violation of SEASON and should be rephrased. But let's wait and see what others think. [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 22:15, 2 March 2024 (UTC)
After reviewing some more examples I've [https://en.wikipedia.org/w/index.php?title=Wikipedia%3AManual_of_Style%2FDates_and_numbers&diff=1216973122&oldid=1216834609 removed] the "running text" part. It doesn't correspond to the usage in the sources I have. I'm aware that we don't always comply with the usage in other sources, but I think we need more of a consensus to vary from that usage than we have here. [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 01:44, 3 April 2024 (UTC)


:I believe the exception makes sense and have reverted your proposed change. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 09:00, 3 April 2024 (UTC)
: Do you have any opinion on the topic that is being discussed here? — [[User:Aluvus|<font style="background: #3371A3" COLOR="#FFFFFF">Aluvus</font>]] [[User talk:Aluvus|t]]/[[Special:contributions/Aluvus|c]] 13:02, 17 January 2008 (UTC)
:: 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. -- [[User:Swtpc6800|SWTPC6800]] ([[User talk:Swtpc6800|talk]]) 14:52, 17 January 2008 (UTC)
::: 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. --[[Special:Contributions/217.87.122.179|217.87.122.179]] ([[User talk:217.87.122.179|talk]]) 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". '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 10:03, 2 February 2008 (UTC)


== idea to help prevent disruptive invocation of WP:ERA ==
::: 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;[[User:Woodstone|Woodstone]] ([[User talk:Woodstone|talk]]) 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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;[[User:Woodstone|Woodstone]] ([[User talk:Woodstone|talk]]) 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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;[[User:Woodstone|Woodstone]] ([[User talk:Woodstone|talk]]) 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? '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 23:09, 17 January 2008 (UTC)


As written, it is quite easy for editors to misuse this policy to disrupt an article in which they have no interest beyond the imposition of their preferred era style. I see that this policy [[Wikipedia_talk:Manual_of_Style/Archive_226#MOS:ERA:_dispute_over_what_"established_era_style"_means|has been debated ''ad nauseam'' in the past]], and that this problem might not be as easy to fix as I had initially assumed. Nevertheless, I have a proposal. The sentence at issue is the following:
: 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.[[User:Pyrotec|Pyrotec]] ([[User talk:Pyrotec|talk]]) 23:45, 17 January 2008 (UTC)
:: 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 00:00, 18 January 2008 (UTC)


<blockquote>{{green|An article's established era style should not be changed without reasons specific to its content; seek consensus on the talk page first (applying [[Wikipedia:Manual of Style#Retaining existing styles|Wikipedia:Manual of Style § Retaining existing styles]]) by opening a discussion under a heading using the word ''era'', and briefly stating why the style should be changed.}}</blockquote>
:: Or we forget it all for now and just make sure the guideline stays as it is in its stable state. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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 [[Wikipedia: Wikipedia is not for things made up one day| something the IEC made up one day]]. It is not Wikipedia's mission to promote a failing standardization effort. If the IEC binary prefixes gain significant support Wikipedia could consider using them. -- [[User:Swtpc6800|SWTPC6800]] ([[User talk:Swtpc6800|talk]]) 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. --[[Special:Contributions/217.87.122.179|217.87.122.179]] ([[User talk:217.87.122.179|talk]]) 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%
::::::'''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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. --[[Special:Contributions/217.87.122.179|217.87.122.179]] ([[User talk:217.87.122.179|talk]]) 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. Wikipedia 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 Wikipedia 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 01:07, 3 February 2008 (UTC)


The problem, as I see it, is that it is entirely unclear what constitutes {{green|reasons specific to its content}}. None of the previous proposals for clarification seemed to go anywhere in past discussions, which I am sure no one wants to revisit. But what if, instead of seeking a positive characterization, we modified the language to instead include a negative prohibition. I have in mind something along the lines of the following:
:::: It is Wikipedia'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;[[User:Woodstone|Woodstone]] ([[User talk:Woodstone|talk]]) 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? '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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;[[User:Woodstone|Woodstone]] ([[User talk:Woodstone|talk]]) 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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 Wikipedia to write the same twice in different words. --[[Special:Contributions/217.87.122.179|217.87.122.179]] ([[User talk:217.87.122.179|talk]]) 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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;[[User:Woodstone|Woodstone]] ([[User talk:Woodstone|talk]]) 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. [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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).[[User:Pyrotec|Pyrotec]] ([[User talk:Pyrotec|talk]]) 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. --[[User:Gerry Ashton|Gerry Ashton]] ([[User talk:Gerry Ashton|talk]]) 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?[[User:Pyrotec|Pyrotec]] ([[User talk:Pyrotec|talk]]) 17:43, 18 January 2008 (UTC)


<blockquote>Reasons that contradict the earlier policy language stating that {{green|The default [[Calendar era|calendar eras]] are [[Anno Domini]] (BC and AD) and [[Common Era]] (BCE and CE). {{em|Either convention may be appropriate for use in Wikipedia articles}} depending on the article context.}} are to be {{em|disregarded}} in article talk space discussion. It is a violation of [[WP:SPURIOUSPROTECT]] to invoke a policy only to litigate against that very policy. Consensus as to what constitutes relevant article context must be established with {{em|reasons specific to the subject matter}} of the article itself.</blockquote>
Yes, of course. Very simple: keep the number as it is (no rounding needed) and convert, depending on context:
* 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;[[User:Woodstone|Woodstone]] ([[User talk:Woodstone|talk]]) 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)" '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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). ''[[User:Rich Farmbrough|Rich]] [[User talk:Rich Farmbrough|Farmbrough]]'', 14:03 [[1 February]] [[2008]] (GMT).
::: or "This memory stick from company X is labelled as 1 [[megabyte|MB]] (1.024 million [[byte]]s)" [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 14:10, 1 February 2008 (UTC)
:::: No. These are the worst options. In one regard it fails as soon as you get to a [[billion]] 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. --[[Special:Contributions/217.87.122.179|217.87.122.179]] ([[User talk:217.87.122.179|talk]]) 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 Wikipedia is descriptive not prescriptive. To use neologisms that are very rarely used in the real world (<1%) only confuses the matter even further. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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 Wikipedia 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.” — [[User:Crissov|Christoph]] [[User talk:Crissov|Päper]] 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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 ''[[kilo|k]]'' which I welcome –, then came disambiguity, then came IEC prefixes, then came Wikipedia. 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 Wikipedia 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. — [[User:Crissov|Christoph]] [[User talk:Crissov|Päper]] 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 [[straw man]], so your "point" is irrelevant and false. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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 (“[[ignoratio elenchi|red herring]]”). 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 [and?] when used with a [[preferred number#Computer engineering|preferred number]] based on a power of 2 where they take a binary default meaning and only need disambiguation when having a decimal meaning.'' — [[User:Crissov|Christoph]] [[User talk:Crissov|Päper]] 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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). — [[User:Crissov|Christoph]] [[User talk:Crissov|Päper]] 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 Wikipedia. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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.[http://xkcd.com/394/]
:::::::::::::: 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. — [[User:Crissov|Christoph]] [[User talk:Crissov|Päper]] 10:11, 11 March 2008 (UTC)


My hope is that this, or something like it, would reduce the number of disruptive interventions by editors not actually there to improve the article under discussion. It would, at minimum, make it much more difficult for editors (whether involved in the development of the article or not) to effectively shut down discussion with a wall of irrelevant considerations likely recycled from previous such debates.
:::::::: 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. Wikipedia MOS is attempting to add clarity to the confusion that already exits.[[User:Pyrotec|Pyrotec]] ([[User talk:Pyrotec|talk]]) 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.[[User:Pyrotec|Pyrotec]] ([[User talk:Pyrotec|talk]]) 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". '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 20:35, 2 February 2008 (UTC)
*''That'' difference is irrelevant everywhere, except perhaps nursing homes in the UK. [[User:Tony1|<font color="darkgreen">'''Tony'''</font >]] [[User_talk:Tony1|<font color="darkgreen">(talk)</font >]] 23:28, 2 February 2008 (UTC)


Thoughts, suggestions, criticisms all most welcome! My goal here is just to limit disruptive editing. (The best solution, of course, would be for the MOS to just pick one or the other of these interchangeable styles. But apparently we can't have nice things.)
: 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 Wikipedia, 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. --[[Special:Contributions/217.87.122.179|217.87.122.179]] ([[User talk:217.87.122.179|talk]]) 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 [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/217.87.122.179|217.87.122.179]] ([[User talk:217.87.122.179|talk]]) 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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. --[[Special:Contributions/217.87.122.179|217.87.122.179]] ([[User talk:217.87.122.179|talk]]) 21:58, 2 February 2008 (UTC)
:::::::::::: [[Red herring fallacy]] also known as irrelevant thesis or conclusion. You'll see what I wrote is correct. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 22:43, 2 February 2008 (UTC)


Cheers, [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 16:38, 23 March 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:
:Do you have examples of this disruptive editing you speak of, by editors who have actually read the guideline? --[[User:Trovatore|Trovatore]] ([[User talk:Trovatore|talk]]) 16:59, 23 March 2024 (UTC)
:: [http://www.google.com/search?q=mile+-wikipedia mile -wikipedia] - 24,300,000
::Hi @[[User:Trovatore|Trovatore]],
:: [http://www.google.com/search?q=kilometer+-wikipedia kilometer -wikipedia] - 1,520,000
::Yes I do, and I notified them on their talk page, detailing my objections to their editing practice, and offering a chance to provide a more sympathetic account. This was more than two weeks ago, however, and they have not responded or made any other edits since. Anyone who wants can find this through my edit history, but I would prefer to keep this discussion at the policy level. If it goes nowhere, I will consider ANI (it's not their first offense), but I'd much rather just amend the language here to help prevent it from happening again by clarifying the language of the policy. Pursuing sanctions on a case by case basis just eats up more of everyone's time.
:: [http://www.google.com/search?q=inch+-wikipedia inch -wikipedia] - 26,000,000
::To the second part of your question: yes, and this is the problem. I changed BC to BCE throughout an article (two, actually). I thought this was just a copy edit, and I explicitly described what I was doing in my edit description. According to WP:ERA, however, anyone can come in at any time in the future and change it back – with no content-specific justification – unless there was first a talk page consensus established under the heading "era". Since hardly anyone is familiar with the policy, this empowers drive-by editors to selectively revert per WP:ERA and then throw up roadblocks to any actual effort to engage in a collaborative discussion.
:: [http://www.google.com/search?q=centimeter+-wikipedia centimeter -wikipedia] - 6,800,000
::In the archived discussion to which I link above, no consensus was reached with respect to limiting this policy-protected right to revert (not with respect to article-involvement, stability, or time-frame). The intention of my suggestion here is to instead insist that any discussion subsequent to such a revert be kept narrowly focused on the actual article and its context, per the policy as currently written. Anyone who doesn't care enough to engage on these terms could then be easily reverted by anyone who cares enough to provide a context-specific justification for changing it back on the talk page—subject, of course, to the normal policy on consensus.
:: [http://www.google.com/search?q=pound+-wikipedia pound -sterling -wikipedia] - 11,200,000
::Cheers, [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 18:15, 23 March 2024 (UTC)
:: [http://www.google.com/search?q=kilogram+-wikipedia kilogram -wikipedia] - 8,240,000
:::Why did you change from BC to BCE in the first place? [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 18:24, 23 March 2024 (UTC)
:: [http://www.google.com/search?q=acre+-wikipedia acre -wikipedia] - 3,420,000
::::Per current policy, that's a discussion to be conducted on that article's talk page in terms specific to its subject matter and the relevant context. [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 19:02, 23 March 2024 (UTC)
:: [http://www.google.com/search?q=square+kilometer+-wikipedia square kilometer -wikipedia] - 1,660,000
:::::The best way to avoid disruptive editing on ERA is not to change the era style without getting the change agreed on the Talk page first. And in fact, where there is a consistent era style in the article, a lot of effort can be saved by leaving the existing era style in place. [[User:Sweet6970|Sweet6970]] ([[User talk:Sweet6970|talk]]) 17:04, 24 March 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.
::::::Hi @[[User:Sweet6970|Sweet6970]],
: Experience with Wikipedia 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.
::::::I am not proposing that we remove the requirement of prior discussion, which would be a policy change. The issue I raise concerns the current policy-restricted scope of the required talk page discussion.
: Basically, the way the MOS currently reads is the only way it can read. In reality there's no such thing as standardization on Wikipedia, 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)
::::::Per the explicit assumptions of this policy, there are two acceptable styles, and at least sometimes there are good reasons to make a change in one direction or the other. (It was an option to simply forbid such changes; this did not achieve consensus.)
: 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. -- [[Special:Contributions/74.160.99.252|74.160.99.252]] ([[User talk:74.160.99.252|talk]]) 20:27, 11 February 2008 (UTC)
::::::It is also a fact that editors, whether aware of this policy or not, believe they have such good reasons.
:: 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 [http://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Incidents#Problem_with_anonymous_user_evading_2_week_block_using_multiple_ip.27s_and_engaging_in_edit_warring. ANI], 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 20:39, 11 February 2008 (UTC)
::::::My point is that, any argument that, if sound, would apply just as much to all articles as to the article in question is, for this reason, in contradiction with this very same policy, which states that there are actually two at least more-or-less equally acceptable practices.
::: I'm pretty sure 74.160.99.252 is the same person you're talking about. --[[Special:Contributions/85.25.12.31|85.25.12.31]] ([[User talk:85.25.12.31|talk]]) 21:28, 11 February 2008 (UTC)
::::::Therefore any such argument should be disregarded in that context. Because, again, any ''universal'' argument to adopt one style over the other is an argument that violates this same policy's stipulation that talk page discussion be conducted in terms ''specific'' to the content of the article.
::::::If anyone does have such an argument in favor of either style, I suppose I should add, I would be happy to see it prevail so that the MOS could be revised to simply stipulate which to use. Until then, however – and since, apparently, the normal bold policy and consensus procedure are insufficient for this weirdly charged issue – we must work with what we have. And that is what I take myself to be doing.
::::::My proposed rewording of the current policy, if I understand it correctly, only makes explicit what is already included, but which is less than immediately apparent as currently articulated.
::::::If there is a flaw in my reasoning – or if there is some other justification for not drawing attention to this implication of the policy – could someone please explain?
::::::Cheers, [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 18:19, 24 March 2024 (UTC)
:::::::{{u|PatrickJWelsh}} I think you have rather fundamentally misunderstood WP:ERA. For there to be an "established style", there does not have to have been "a previous discussion under the heading 'era'". If all occurrences (or the overwhelming majority) were BC before you changed it, then that ''was'' the established style, and your edit violated WP:ERA. --[[User:Trovatore|Trovatore]] ([[User talk:Trovatore|talk]]) 04:48, 25 March 2024 (UTC)
::::::::That's what I fear as well. It sounds like the needlessly disruptive type of edit which WP:ERA is meant to avoid. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 08:04, 25 March 2024 (UTC)
:::::::::No need for fear! I most definitely violated ERA with my edits. This policy is a very specific exception to the usual [[WP:BRD]], of which I was not aware. Once made aware, however, I attempted to engage in the requisite discussion.
:::::::::For a variety of reasons, I do think that this is a bad policy we would all be better off without. All of my remarks, however, accept it as given. The amended wording that I propose would not change that I violated the policy. It would only, if it works I suppose, have kept the talk page discussion focused on what was best for the article in question.
:::::::::My intention is only to make it more burdensome to invoke this policy in order to pursue what is, apparently, for some people a culture war issue, but which interferes with making Wikipedia a better encyclopedia.
:::::::::I assume this weird exception to standard practices was implemented in order to prevent folks overly passionate about era styles from causing pointless disruption. It's specificity, however – not just talk page discussion, by talk page discussion under a specific heading! – makes it ripe for abuse. So, in the spirit of the policy itself, let's do our best to minimize that on the terms of the policy itself.
:::::::::Cheers, [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 14:51, 25 March 2024 (UTC)
:::::::I don’t see any reason to change the current wording. It says that the era style should not be changed without discussion, and that the reasons used in the discussion should be specific to the article. You say {{tq|The problem, as I see it, is that it is entirely unclear what constitutes reasons specific to its content.}} Well, being realistic, there probably are very few such reasons. This means that once a style is established, it is likely to stay. [[User:Sweet6970|Sweet6970]] ([[User talk:Sweet6970|talk]]) 13:11, 25 March 2024 (UTC)
::::::::You seem to be arguing against the policy itself. No?
::::::::It is stipulated that there are some. This is a discussion about the proper procedure in the event of a disagreement. [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 14:55, 25 March 2024 (UTC)
:::::::::No reasons are ‘stipulated’. And no, I am not arguing against the policy, as such. I am just pointing out the way it works out in practice. [[User:Sweet6970|Sweet6970]] ([[User talk:Sweet6970|talk]]) 16:11, 25 March 2024 (UTC)
::::::::::No specific reasons are stipulated as decisive in either direction (which is part of why it is a poor policy). It does however stipulate that there in some cases some such reasons. Otherwise the policy would instead state that once established, era style should never be changed. Which it does not. If you think it should, by all means advance such a proposal. It's less good of a solution than deciding on one style to be preferred by default, but it would address my concern about disruptive edits. [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 16:28, 25 March 2024 (UTC)
*I endorse most of the comments above that are not by [[User:PatrickJWelsh|Patrick J. Welsh]]. I'd just add that the level of invalid changes of era, and spats over them, seems a good deal lower than a few years ago, and that most people starting them are pretty clearly unaware of [[WP:ERA]]. Many think, or claim to think, that BCE/CE are the preferred or mandated style. [[User:Johnbod|Johnbod]] ([[User talk:Johnbod|talk]]) 13:25, 25 March 2024 (UTC)
* I would support removing the {{tqd|"by opening a discussion under a heading using the word ''era'', and briefly stating why the style should be changed"}}. I think a talk page discussion with the heading "BC vs. BCE" with a lengthy opening comment would be just fine, if it led to consensus to change the established style. I would not support adding additional language about which arguments are acceptable in such discussions. [[User:Firefangledfeathers|Firefangledfeathers]] ([[User talk:Firefangledfeathers|talk]] / [[Special:Contributions/Firefangledfeathers|contribs]]) 14:55, 25 March 2024 (UTC)
*:Hi @[[User:Firefangledfeathers|Firefangledfeathers]],
*:I am concerned that requiring that a discussion take place under any ''specific'' header makes this policy subject to abuse by those passionate about era styles for reasons unrelated to any specific article. Is there any reason not simply to require prior talk page discussion?
*:I'm also inclined to think that the policy should not specify whether the initial justification be brief or lengthy. This is subjective, and I would expect it to be ignored with impunity. For that reason, however, I don't think it particularly matters.
*:Cheers, [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 15:09, 25 March 2024 (UTC)
*::I agree. I only brought up "BC vs. BCE" as an example of a perfectly adequate heading that would be inappropriate under the current rule. Again, my preferred outcome here is removing {{tqd|"by opening a discussion under a heading using the word era, and briefly stating why the style should be changed"}}. [[User:Firefangledfeathers|Firefangledfeathers]] ([[User talk:Firefangledfeathers|talk]] / [[Special:Contributions/Firefangledfeathers|contribs]]) 15:13, 25 March 2024 (UTC)
*:::Oh, I misunderstood! That does not go as far as I would like, but I do believe it would be an improvement.
*:::I will add that my ideal outcome, whatever the best means to achieve it, would be to redirect editors with a strongly held universal preference away from individual articles to instead hash things out at the Village Pump.
*:::If policy allowed, I would strongly support reopening a RfC on revising the MOS in either direction with the further stipulation that, should there be no consensus, it be decided by the coin toss of an uninvolved admin.
*:::The two styles are interchangeable. It's frankly embarrassing that we can't just pick one so that we can all get on with making Wikipedia a better encyclopedia. [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 15:39, 25 March 2024 (UTC)
*::::That won't happen, and for the same reason that we don't postulate that all of Wikipedia be written in American (or British, or whatever) English. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 16:00, 25 March 2024 (UTC)
*:::::There is no intrinsic difficulty preventing the MOS from taking a stance. Doing so is a large part of the point of having such a thing at all. What I'm proposing, however, is a clarification of what is already there. [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 16:38, 25 March 2024 (UTC)
*::::Some of us have participated in several discussions on this subject, and we know from experience that they are a waste of our virtual breath. The question is not going to be resolved in the foreseeable future. [[User:Sweet6970|Sweet6970]] ([[User talk:Sweet6970|talk]]) 16:14, 25 March 2024 (UTC)
*:::::Sorry? In any case, please don't feel obliged to waste any further breath. [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 16:39, 25 March 2024 (UTC)
*::::::You're not the first person to think that there should be a project wide standard for this, but developing a community-wide consensus has not happened. What is currently in the MOS is a compromise, and until something shifts it is going to be around for a while. [[User:MrOllie|MrOllie]] ([[User talk:MrOllie|talk]]) 17:14, 25 March 2024 (UTC)
*:::::::Hi @[[User:MrOllie|MrOllie]],
*:::::::Yes, I understand and accept that, however unfortunate.
*:::::::As best I understand it, however, the language of this compromise policy already excludes from article-specific discussion such general reasons such as "this is standard", "this is traditional", or "this is more neutral".
*:::::::If my understanding is correct, then making this explicit in the wording of the policy might help prevent talk page discussions from devolving into an irrelevant culture war debate.
*:::::::Cheers, [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 17:29, 25 March 2024 (UTC)
*::::::::I think the best approach to pursue here is simply not to start any talk page discussions on the subject. If the current era style used in an article is inconsistent, you are free to clean it up anyway. But if there is a clear dominance of one or the other style detectable, just clean up whatever inconsistencies remain. That's the best usage of everybody's time. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 17:58, 25 March 2024 (UTC)
*:::::::::You're almost certainly right that it is a waste of time to argue about anything so trivial. The current policy, however, says that that is what you must do if you think a change should be made. Which some people do.
*:::::::::If you want to propose a policy change to "always retain established style per first use of either convention", I would reluctantly support that as at least better than what we currently have. [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 18:16, 25 March 2024 (UTC)
*::::::::::Just act is if that already is the rule (I think it essentially is, for most practical purposes), and you won't go wrong. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 20:08, 25 March 2024 (UTC)
*:I could get on board with adding something like "or another expressive heading" after "using the word ''era''". I decidedly ''don't'' think that the requirement for a preceding talk page discussion should be dropped. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 16:03, 25 March 2024 (UTC)
*:{{ping|PatrickJWelsh}} The first post in this thread fails to state when the language being complained about was first put into the policy. Obviously the language does not apply to any consensus reached on any talk page before the language first appeared in the guideline. [[User:Jc3s5h|Jc3s5h]] ([[User talk:Jc3s5h|talk]]) 17:26, 25 March 2024 (UTC)
*::Hi @[[User:Johnbod|Johnbod]],
*::Yes, thanks, I hadn't thought about that, but it makes sense (no ''ex post facto''). I would support adding the qualifier "before [date]" to the language in order to prevent particularly egregious abuse of the policy.
*::Cheers, [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 17:45, 25 March 2024 (UTC)
*::: I just looked up the bit that it looks like you two are talking about; it says {{xtg|[...]by opening a discussion under a heading using the word ''era''[...]}}. I don't think that was ever meant to be a legalistic requirement; it's just a helpful hint to open a discussion that other discussants can easily understand and join. If we're talking about it as something that has to be grandfathered to take into account earlier discussions, then it's just being misinterpreted and we should remove it. The intent is just, if you want to change the era style away from an established one, you need consensus first. --[[User:Trovatore|Trovatore]] ([[User talk:Trovatore|talk]]) 19:57, 25 March 2024 (UTC)
:Patrick J. Welsh [https://en.wikipedia.org/w/index.php?title=Aristotle&diff=prev&oldid=1190982893 changed BC to BCE] on the Aristotle article, [[User:Crumpled_Fire|Crumpled Fire]] [https://en.wikipedia.org/w/index.php?title=Aristotle&diff=prev&oldid=1207992992 reverted], Patrick J. Welsh [https://en.wikipedia.org/w/index.php?title=Aristotle&diff=prev&oldid=1208157856 changed BC to BCE again], Crumpled Fire [https://en.wikipedia.org/w/index.php?title=Aristotle&diff=prev&oldid=1208179971 reverted again], and it was discussed .[https://en.wikipedia.org/wiki/Talk:Aristotle#Era on the talk page] with participants Patrick J Welsh, [[User:Andrew_Lancaster|Andrew Lancaster]], Crumpled_Fire, Peter Gulutzan (i.e. me), [[User:86.6.148.125|86.6.148.125]]. Patrick J. Welsh also posted what looks like a warning on [https://en.wikipedia.org/wiki/User_talk:Crumpled_Fire#disingenuous_application_of_WP:ERA Crumpled Fire's talk page]. I continue to support the reversion, and will support any other reasonable actions that might persuade Patrick J. Welsh to stop, or at the least to ping all participants when moving to a new forum. By the way, WP:ERA is not a policy but a guideline, as is [[WP:TALKHEADPOV]]. [[User:Peter Gulutzan|Peter Gulutzan]] ([[User talk:Peter Gulutzan|talk]]) 19:42, 25 March 2024 (UTC)
::Hi @[[User:Peter Gulutzan|Peter Gulutzan]],
::I quote myself from the talk page discussion:
::<blockquote>Thanks for weighing in! The emerging consensus does seem to be "what is wrong with you people and why are you arguing about this?"...Cheers, [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 5:26 pm, 18 February 2024, Sunday (1 month, 6 days ago) (UTC−6)</blockquote>
::And then I dropped the matter and left it BC/AD.
::I am not here to change the style of the Aristotle article back to what I consider a very slightly preferable convention. The policy is correct in stating that both conventions are fine.
::What I am attempting to do is to raise the barrier to entry for people who do not care about the article in question, but are just gunning for a fight.
::Please do share here any considerations you might have in response to the concerns I raise above. If your problem, however, is with my individual editorial conduct, it would probably be more appropriate to raise that on my talk page.
::Cheers, [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 20:10, 25 March 2024 (UTC)
:::I don't see any need to raise barriers to entry. People care about articles for different reasons, it isn't up to us to [[WP:AGF|question people's motivations]]. [[User:MrOllie|MrOllie]] ([[User talk:MrOllie|talk]]) 20:36, 25 March 2024 (UTC)
::::No kidding. [[User:Masterhatch|Masterhatch]] ([[User talk:Masterhatch|talk]]) 20:53, 25 March 2024 (UTC)
::::Hi @[[User:MrOllie|MrOllie]],
::::I should not have expressed myself that way. In both this discussion and in the Aristotle discussion I have made a conscious effort to avoid imputing bad faith motives to individual participants, and doing so in this more general way did no one any favors. I apologize to all concerned.
::::With respect to "barriers to entry" I should clarify that the only barrier I am proposing is that participants in a discussion about changing era style provide reasons more specific to the article in question than those general reasons that have been proposed and that have failed to achieve consensus in a more general forum. For what less than this could {{green|reasons specific to its content}} be construed to mean?
::::That said, however, I am satisfied that I have had my say, and I acknowledge that I appear to persuaded precisely no one that this is, in fact, a little bit of a problem that we could easily do a little bit to fix. So, unless someone speaks up in support of this or a related proposal, I will drop the matter. (On pain of rank hypocrisy!)
::::I am glad that this discussion appears to have at least resulted in a consensus to clarify that the talk page header does not literally need to be "era". If no one else makes the change, I'll swing back around and implement the language suggested by Gawaon and link to this thread in the edit description.
::::Cheers, [[User:PatrickJWelsh|Patrick J. Welsh]] ([[User talk:PatrickJWelsh|talk]]) 23:49, 25 March 2024 (UTC)
:::::The current text does not say that the header must be merely "era". "Change era style from BC to BCE" and other headers {{tq|q=y|using the word era}} would also be compliant. [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 13:54, 26 March 2024 (UTC)


== Seasons in magazine titles in running text ==
== Don't wikilink units in infoboxes & tables? ==


{{u|Dondervogel 2}} reverted [https://en.wikipedia.org/w/index.php?title=Wikipedia%3AManual_of_Style%2FDates_and_numbers&oldid=prev&diff=1217014392 this edit] of mine, which removed the bolded text in the sentence below, about the use of seasons in magazine titles:
This change was just made (change in bold):
<blockquote>
*In tables and infoboxes, use unit symbols and abbreviations; do not spell them out. '''They should not be internally linked with wikipedia pages.'''
</blockquote>


:They are capitalized when part of the title of a work ({{xt|''Science Fiction Quarterly'', Summer 1942}})''', except when referring to a seasonal edition in running text ({{xt|the summer 1942 issue of ''Science Fiction Quarterly''}})'''.
Why not? Was this change discussed anywhere? <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Gerry Ashton|Gerry Ashton]] ([[User talk:Gerry Ashton|talk]] • [[Special:Contributions/Gerry Ashton|contribs]]) 18:42, 13 February 2008 (UTC)</small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->


The example was added about a month ago without much discussion; see further up this talk page. I removed it for two reasons:
added line - is there a better way to phrase it. [[User:CorleoneSerpicoMontana|CorleoneSerpicoMontana]] ([[User talk:CorleoneSerpicoMontana|talk]]) 21:25, 13 February 2008 (UTC)
# Sources that discuss magazines mostly do capitalize the season name even in running text; and
# The use of the lower-case season in this way is against the advice of SEASON in any case, since if we're not using the formal title of the issue, "Summer 1942", then we should be avoiding the use of season names.


It appears that the sources capitalize in this way when they are referring to a specific issue that has that title. I started to compile a list of usage by source, but it's easier to simply go to Google Books and search for "the summer 2019 issue". The first fifteen results have ten with "Summer" and five with "summer". I think the example that Dondervogel 2 reinstated should be removed again: it advises a usage that doesn't agree with what reliable sources do; it makes no allowance for the writer wishing to refer to a specific issue with that formal title; and it conflicts with the main point of SEASON. [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 10:32, 3 April 2024 (UTC)
: I don't understand the need for this change. Please explain. [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 21:31, 13 February 2008 (UTC)


::I'm opposed to this change. In infoboxes and tables, space is at a premium, so there no room to explain units. Hence, the need for wikilinks is greater than in the text of articles, not less. --[[User:Gerry Ashton|Gerry Ashton]] ([[User talk:Gerry Ashton|talk]]) 22:00, 13 February 2008 (UTC)
:My point is that "summer" in "the summer 1942 issue" is not a proper noun, so I see no reason to capitalise. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 18:13, 3 April 2024 (UTC)
::I agree it's not a proper noun. The reason it's capitalized is that it's part of the formal title of that issue of the magazine. The example in the first half of the sentence uses upper case; if a writer is referring to that issue of the magazine, they can use the title of the issue if they wish -- and from a look in Google Books it's evident that's what most writers do. [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 18:45, 3 April 2024 (UTC)
:::Instead of removing it, I've now replaced it with text saying "if a mention of a seasonal edition does not capitalize the season name, avoid using the season name because of the ambiguity". That avoids implying that it should always be capitalized or always uncapitalized in running text, and also avoids giving an example that uses a lower-case season name. [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 10:36, 4 April 2024 (UTC)
::::I have reverted that, since I don't think it's an improvement. It's totally unclear what's meant by "a mention" (in Wikipedia? in a RS?) and "avoid using" is not useful advice if you don't know how else to refer to the issue in question. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 11:47, 4 April 2024 (UTC)
::::Personally I think that when such an issue identifier is mentioned in running text it's often unclear whether it's indeed part of the title (which calls for capitalization) or just a generic identifier similar to "the second issue of 1942". Maybe because of this ambiguity, we could simply allow either capitalization and write something like "except that seasonal editions may be lower-cased in running text ({{xt|the Summer/summer 1942 issue of ''Science Fiction Quarterly''}})"? [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 11:52, 4 April 2024 (UTC)
:::::My main concern is that the prior wording forbade the use of upper case in running text, so that would work for me. Is it a problem that the example you give uses "summer", which we're trying to avoid recommending? We do say it's "appropriate when it is part of a conventional name or designation"; I think here the "conventional name" would be the magazine issue's title, and that would be upper case. I think the usages one can see of lower case "summer 2019 issue of" in Google Books are season references of the type we discourage. But other than that your wording seems good to me. [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 11:57, 4 April 2024 (UTC)
::::::I've gone ahead and made the change to your wording. [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 12:05, 6 April 2024 (UTC)
:::::::I object to the change because if "the Summer 1942 Issue" is interpreted as a part of the title, then "Issue" would also be capitalised. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 12:33, 6 April 2024 (UTC)
::::::::I don't think we can say "issue" is part of the title; the phrase "Summer 1942" will typically appear on the cover and contents page and sometimes the masthead of a magazine, but it is never accompanied by the word "issue". [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 12:56, 6 April 2024 (UTC)
::::::::I don't think that's true. The magazine cover will probably just say something like "Science Fiction Quarterly – Summer 1942", the magazine title being the main title, and the issue identifier something like the subtitle. The word "issue" probably won't appear on the cover and so is not part of the title. (I had already largely written this when {{u|Mike Christie}}'s comment appeared, so I'll let it stand despite the repetition.) [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 12:58, 6 April 2024 (UTC)
:::::::::I fully agree the word "issue" is not normally considered part of the title, in which case it should not be capitalised. My point is that if "issue" is not part of the title, then neither is "summer 1942". It's just text describing which issue we are referring to. Just because "Summer 1942" can be part of the title, as in ''Science Fiction Quarterly, Summer 1942'', does not imply it always is. It depends on the construction. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 14:25, 6 April 2024 (UTC)
::::::::::I think it's the other way round -- the only difference between the two constructions (the writer is using the title of the issue vs. the writer is mentioning the time of year when the issue appeared) is the capitalization. If it's capitalized, the writer is using the issue's title. The revised wording suggested by Gawaon allows for both, which is in line with actual usage in the sources. [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 14:28, 6 April 2024 (UTC)
:::::::::Indeed. "Summer 1942" is how the publisher named the issue, as well as being how others refer to it. It may or may not bear any particular relationship to the season in which it was actually published or even indicate when it could be taken off sale and returned. [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 14:43, 6 April 2024 (UTC)
::::::::::Sounds like I am in a minority of one. For that reason I withdraw my objection. [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 18:43, 6 April 2024 (UTC)
:::::::::::I agree with @[[User:Dondervogel 2|Dondervogel 2]] that we should default to lower-case in running text. Let's consider a non-season example. Our MOS would recommend using {{xt|Science Fiction Quarterly, Third Edition}} when referring to the edition as a title, but on the other hand we would state {{xt|third edition of Science Fiction Quarterly}} in running text. I don't see a compelling reason to do anything differently just because we're now dealing with a season name.
:::::::::::For what it's worth, I initiated the discussion above because of [[Wikipedia:Featured article candidates/Oyster dress/archive1|an MOS discussion at the 'Oyster dress' FAC]], which actually concerned a fashion collection rather than a periodical title. Over there I was a so-called "minority of one". Just as an FYI to you, Dondervogel 2, that you're not alone in your position. I maintained my objection in that discussion because I could not find an MOS-based reason to support capitalization despite my best efforts.
:::::::::::I like the wording that @[[User:Gawaon|Gawaon]] and @[[User:Mike Christie|Mike Christie]] added. It gives flexibility based on how reliable sources handle capitalization. However, I do have two recommended changes.
:::::::::::# The new text currently states {{xt|the Summer/summer 1942 issue}}, but in the MOS we usually provide separate instances of an example to avoid ambiguity. We're not telling people to actually write down {{xt!|Summer/summer}}; we want them to pick one or the other. So I think the text should be fully expanded to say "{{xt|the summer 1942 issue of ''Science Fiction Quarterly''}} or {{xt|the Summer 1942 issue of ''Science Fiction Quarterly''}}". But this also might unnecessarily lengthen the guideline so I'd appreciate thoughts from others.
:::::::::::# It also might be helpful to remind editors of [[MOS:CAPS]], which looks for a "substantial majority" of such sources to support capitalization. Of course, "substantial majority" is still an imprecise term so I don't know how helpful it would be on the more contentious cases.
:::::::::::[[User:Edge3|Edge3]] ([[User talk:Edge3|talk]]) 05:01, 7 April 2024 (UTC)
::::::::::::For #1, a shorter magazine title would help. How about "{{xt|the summer 1985 issue of ''Interzone''}} or {{xt|the Summer 1985 issue of ''Interzone''}}"? [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 10:57, 7 April 2024 (UTC)
:::::::::::::Fine with me. But we should probably keep the capitalized form first. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 11:28, 7 April 2024 (UTC)
::::::::::::::I tried to incorporate my changes for #1 and #2, along with the feedback here. See [https://en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style/Dates_and_numbers&diff=prev&oldid=1217823219 edit]. It's a somewhat complex change, so feel free to revise further! [[User:Edge3|Edge3]] ([[User talk:Edge3|talk]]) 02:38, 8 April 2024 (UTC)
:::::::::::::::I have partially reverted that since it's not what we agreed on and would put an undue burden on editors, who cannot be expected to research "substantial majority" distributions for every issue title they mention. Let's keep it simple and allow both case forms ''without prejudice''. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 05:19, 8 April 2024 (UTC)
::::::::::::::::I agree. I've changed the date for the ''Interzone'' example to 1985, since we might as well use an issue that really appeared as an example. [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 10:08, 8 April 2024 (UTC)
:::::::::::::::::I was trying to address my point #2 above to give guidance on when to capitalize. You both haven't talked about it yet so I'm happy to hear feedback. [[User:Edge3|Edge3]] ([[User talk:Edge3|talk]]) 14:46, 8 April 2024 (UTC)
{{od}}I don't know that there's anything useful we can add on when to capitalize. It seems that in running text the seasons are more often capitalized than not, but as discussed above I think the only way to tell the writer's intent is from the capitalization -- that is, we're not going to be able say "if your sentence is like <this> then capitalize". I suppose we could say something like "if you mean to refer to the issue by its title, capitalize; otherwise if you are referring to the season of the year when the issue appears, then do not capitalize", but that seems a bit wordy. I think the lower-case usage does run into a problem with the main reason for SEASON in the first place so ideally we wouldn't mention it at all, but then we'd have to say something like "northern summer" which is just not how the sources do it -- they assume the context is the location where the magazine is published. [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 15:11, 8 April 2024 (UTC)


::: I agree with Gerry Ashton. [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 22:09, 13 February 2008 (UTC)
:Let's not overcomplicate this. The current wording works. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 16:35, 8 April 2024 (UTC)
::The current wording may be fine for seasonal periodicals, but it still doesn't give clear guidance in other cases. Specifically for fashion-related articles, a majority of sources use lowercase, but our WP articles still capitalize based on a previous interpretation of the MOS. The phrasing "''may'' be lower-cased" is permissive, while [[MOS:CAPS]] provides an explicit test: avoid capitalization unless supported by a "substantial majority" of sources. [[User:Edge3|Edge3]] ([[User talk:Edge3|talk]]) 17:10, 8 April 2024 (UTC)
:::Uh, seasonal periodicals is what the wording is all about, so where shouldn't it be fine? [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 06:05, 9 April 2024 (UTC)
::::Edge3, if you're talking about fashion shows such as the Spring/Summer 2006 collection at which ''[[Neptune (Alexander McQueen collection)|Neptune]]'' was shown, then I'd say the sources show exactly the same variation that source about magazines do -- when the writer is referring to the show by what they regard as the formal title they use the upper case version; when they are referring to the season they use lower case. Just as with magazines, the capitalization is what tells you their intention -- the fact that both occur doesn't mean one is right and one is wrong; it just distinguishes the two usages. Pinging {{u|Premeditated Chaos}} as I know this discussion began on one of her FACs. [[User:Mike Christie|Mike Christie]] ([[User_talk:Mike Christie|talk]] - [[Special:Contributions/Mike_Christie|contribs]] - [[User:Mike Christie/Reference library|library]]) 11:00, 9 April 2024 (UTC)
:::::Mike, while I appreciate the ping, I'm not interested in participating in this discussion. Edge3 has consistently shown that he has no interest in listening to the opinions of other editors, as indicated by his single-minded dismissal of the clear consensus from something like a half-dozen-plus editors (including FAC coords!) who showed up at the Oyster dress FAC to tell Edge3 that his interpretation was incorrect.
:::::I'll repeat the argument I made when Edge3 showed up at my next FAC to complain that I wasn't following the arbitrary change he made to MOS:SEASONS, despite the fact that the capitalization was actually correct under his arbitrary brand-new wording.
::::::"Season names are generally not capitalized (a hot summer), except when personified (Old Man Winter) '''or when part of a formal name'''". A fashion season such as "Autumn/Winter 2008" or "Resort 2014" is a formal name for a particular period in the industry, so it is capitalized. Other editors clearly agreed with this interpretation in the last discussion, so although the MOS wording may have changed, the reality underpinning my reasoning has not.
:::::I do not see the point in participating in a discussion with someone who has decided that consensus is irrelevant unless it's in his favor, who feels he can arbitrarily rewrite the MOS whenever consensus does not go his way, and who feels he can interpret his brand-new wording however he wants even when it actually supports my position ''despite'' his rewrites. I have zero intention of altering the capitalization for fashion seasons unless there is a strong consensus for this change from editors who are not Edge3. I am deliberately not watching this page, will not be reading any replies, and do not wish to be pinged back here to this or any further discussion on the topic, because I find attempting to speak to Edge3 on this topic exhausting and frustrating, and I would prefer to do literally anything else with my time than argue about capital letters. &spades;[[User:Premeditated Chaos|PMC]]&spades; [[User_talk:Premeditated Chaos|(talk)]] 11:46, 9 April 2024 (UTC)


== Numbers ==
::::I'd rather see links to unit articles in the text but if the unit does not appear in the text & needs linking, why not link from an infobox or table? Generally, yes, in tables & info boxes should use abbreviations but not always, obvious examples are where the abbreviation is not well recognised, could easily be misread or doesn't even exist. Shall we not look into a rephrasing of the whole point? <span title="Representation in the International Phonetic Alphabet (IPA)" class="IPA">[[User:Jimp|J]][[Special:Contributions/Jimp|ɪ]][[User talk:Jimp|m]][[wikt:User:Jimp|p]]</span> 02:53, 14 February 2008 (UTC)
Under the [[Wikipedia:Manual of Style/Dates and numbers#Numbers|Numbers]] section, it states:


"Generally, in article text:
:::::re-worded. This comes from working with alot of sports infoboxes where the weights and heights are detailed in both imperial and metric systems. [[User:CorleoneSerpicoMontana|CorleoneSerpicoMontana]] ([[User talk:CorleoneSerpicoMontana|talk]]) 08:40, 14 February 2008 (UTC)


Integers from zero to nine are spelled out in words."
:::::: Can you point us to a specific example that causes a problem? Then we can try to help you solve it. [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 09:02, 14 February 2008 (UTC)


I wonder why is "from zero to nine" instead of "from zero to ten"? We humans have ten fingers, we learn how to count from one to ten since we were little kids. If we learn a foreign language, the first thing we learn is words like hello, thank you, good bye, and count from one to ten. It doesn't make sense that only integers from zero to nine shoulde be spelled out in words. It should be integers from one to ten. [[Special:Contributions/120.16.218.233|120.16.218.233]] ([[User talk:120.16.218.233|talk]]) 17:18, 13 April 2024 (UTC)
::::::The articles from the UK, and Australia at least work in st, lb, & kg, along with ft, in & m. I don't believe the need to be linked as it only makes the infobox garish. The units themselves are described in metric and imperial units and it seems that were someone not used to using either system, which frankly seems unlikely they can go through the search feature. This is a small problem as it is only a very small percentage that currently link units. [[User:CorleoneSerpicoMontana|CorleoneSerpicoMontana]] ([[User talk:CorleoneSerpicoMontana|talk]]) 09:08, 14 February 2008 (UTC)


:Yes, but cats have nine lives, so it makes perfect sense actually. [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 17:19, 13 April 2024 (UTC)
:::::::See: [[Wikipedia:Only make links that are relevant to the context]] ''"What generally should not be linked" "Plain English words, including common units of measurement."'' [[User:Lightmouse|Lightmouse]] ([[User talk:Lightmouse|talk]]) 10:30, 14 February 2008 (UTC)


::LOL. You must be joking. [[Special:Contributions/120.16.218.233|120.16.218.233]] ([[User talk:120.16.218.233|talk]]) 17:21, 13 April 2024 (UTC)
:::::::: My view is that non-SI units should be linked somewhere in the article, and preferably on first use. If they are linked outside the infobox, there is no need to do so again inside it. [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 17:55, 14 February 2008 (UTC)
:::...weren't you? [[User:GiantSnowman|Giant]][[User talk:GiantSnowman|Snowman]] 17:23, 13 April 2024 (UTC)
:::::::::Depends on the unit. ''Rods'' and ''perches'' should be linked, simply as rare words, independently of this guideline; linking [[ton]] is one way to deal with ambiguity (although explanation, perhaps in a footnote, would be better). But linking ''foot'' is as unnecessary as linking ''leg''. [[User:Pmanderson|Septentrionalis]] <small>[[User talk:Pmanderson|PMAnderson]]</small> 03:17, 15 February 2008 (UTC)
::::Nope. I really think that in article text, integers from zero to ten should be spelled out in words (i.e. ten years ago not 10 years ago). [[Special:Contributions/120.16.218.233|120.16.218.233]] ([[User talk:120.16.218.233|talk]]) 17:28, 13 April 2024 (UTC)
::::::::::
:We don't say that "only integers from zero to nine shoulde be spelled out in words". We do say that {{tq|Integers greater than nine expressible in one or two words may be expressed either in numerals or in words}} and proceed to qualify that in several ways, allowing for either "10" or "ten" to be used as appropriate. [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 17:39, 13 April 2024 (UTC)
::::::::::In that line, the "stone" as a unit of measure mentioned by CorleoneSerpicoMontana is a rare word to most native speakers of English, let alone to almost all of the many readers we have who are not native speakers of English.
:I’ve thought this for a long time, so agree with you. Numbers expressed as words are easier to read and don’t visually interrupt a sentence in the same way as does sticking figures in the middle of it. IMHO figures should only be used when multiple words are needed to express the quantity. [[User:MapReader|MapReader]] ([[User talk:MapReader|talk]]) 18:59, 13 April 2024 (UTC)
::::::::::But to say that in infoboxes and tables, units should not be linked is nonsense. There are many SI units which should be linked as well (how many of you understand joules and katals and kelvins and luxes and becquerels well?), as well as hundreds of Fred Flintstone non-SI metric units, English units, and units of a number of other old systems of measurement from all over the world. "Infoboxes and tables" include more than those just listing an athlete's height an weight. They use all sorts of strange and uncommon units.
::"Numbers expressed as words are easier to read". My experience is the opposite. I find it much easier to express numbers as numerals always. I only express them in words when English convention says Thou Must Use Words For Small Numbers but I never liked it. Mind you, I spend most days writing software and doing engineering stuff, so I may not represent the typical reader. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 11:07, 14 April 2024 (UTC)
::::::::::Like Pmanderson/Septentrionalis says, there is usually not any real need to link feet. There is also not any good reason to link inches or meters or kilograms. But pounds often need to be linked for disambiguation purposes, especially in the thousands of articles we have using both the [[pound (mass)|pound]] and the [[pound-force|pound]], as well as to disambiguate both of them from the various currencies of the same name). But even for pounds, when it is a listing of a persons height and weight, there is no crying need for any link. We aren't going to be thinking these are [[pounds sterling]] nor wondering what they are in terms of euros, and while some miseducated science-trained people might be confused enough to think they are [[pounds-force]], that's their problem not ours. One little link isn't going to remedy their miseducation, if they've already ignored the evidence of the conversion to kilograms rather than newtons and everythig else.
:::Agreed. We should be looking to REDUCE the instances of "numbers as words", not increase them. --[[User:Khajidha]] ([[User talk:Khajidha|talk]]) ([[Special:Contributions/Khajidha|contributions]]) 17:19, 17 April 2024 (UTC)
::::::::::I agree with Gerry Ashton's point that linking of units is slightly more necessary in infoboxes and tables than in running text. Furthermore, linking in text should not necessarily preclude linking on first appearance in boxes and tables, nor vice versa. For one thing, it isn't always clear which comes "first" in everybody's reading habits, and boxes and tables are likely to be considered in isolation without even reading the text by some, while others will be reading the text and paying little attention to everything else. [[User:Gene Nygaard|Gene Nygaard]] ([[User talk:Gene Nygaard|talk]]) 14:23, 29 February 2008 (UTC)
:While I have no strong preference one way or the other, adding ''ten'' to the numbers for which words are preferred would be fine with me. ''Ten'' is indeed just one more character than ''10'', so it's the number easiest to spell out. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 19:25, 13 April 2024 (UTC)
:Some other style guides:
:*The ''BBC News Style Guide'' has "For the most part, we use words for single-figure numbers, digits for anything above nine (ie eight, nine, 10, 11)" followed by various exceptions.[https://www.bbc.co.uk/newsstyleguide/numbers]
:*The ''Guardian and Observer style guide'' has "Spell out from one to nine; numerals from 10 to 999,999 ...."[https://www.theguardian.com/guardian-observer-style-guide-n]
:*According to this 2005 discussion here in [[WT:MOSNUM]], [[Wikipedia talk:Manual of Style/Dates and numbers/Archive 25#Numbers written as words]], the ''Chicago Manual of Style'' has (or had) "According to Press style, the following are spelled out in ordinary text: Whole numbers from one through ninety-nine; Any of these followed by hundred, thousand, million, etc."
:*According to the same discussion, the ''Oxford Style Manual'' (2003) had "In non-technical contexts, OUP style is to use words for numbers below 100."
:*Fowler's Modern English Usage (4th edn) has "Figures should be used when the matter consists of a sequence of stated quantities [e.g.] ''The past 12 months show an increase of 5 tons''" and "In descriptive matter, numbers under 100 should be in words, but write ''90 to 100'', not ''ninety to 100''."
:I haven't tried a proper search in MOSNUM's history – I doubt a straightforward Wikiblame search would help – but it looks as if the core one-to-nine rule's been stable since [[Wikipedia talk:Manual of Style/Dates and numbers/Archive 73#Proposed revision of "Numbers in words"]] in 2007. [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 20:26, 13 April 2024 (UTC)
:'''Proposal''' The IP user brought up an interesting point. Why "from zero to nine"? Why not "from zero to seven, eight, ten, or eleven"? I propose that we change the rule to "Integers from zero to twenty are spelled out in words". If we can express a number in a single, simple English word, then use the English word. If more than one word or a hyphen is involved (e.g. twenty-one, one hundred and one), use the numerals. [[User:N. Mortimer|N. Mortimer]] ([[User talk:N. Mortimer|talk]]) 00:32, 14 April 2024 (UTC)
::'''Against''' - Existing form (words for single digits, numerals for more) works fine. Examples for each:
::# There 14 reasons to object.
::# There are fourteen reasons to object.
::The numeral form is so much more compact, quicker to type, quicker to read, requires less effort to understand and the quirks of spelling for 11-19 are avoided for our English as a second language audience (why is 11,12 different to 13-19; why is 13-19 different to 23-29, etc?). Keep it simple. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 01:53, 14 April 2024 (UTC)
:::So you also support my proposal of adding "ten" to the mix? Thank you. Ten is a very simple word, I think all people with a basic understanding of English know this word.
:::By the way, even if we use "14" instead of "fourteen" in your sentence example, we can't really omit the "are", but I agree with you that numbers greater than ten should be written in the numeral form. [[Special:Contributions/120.16.218.233|120.16.218.233]] ([[User talk:120.16.218.233|talk]]) 09:57, 14 April 2024 (UTC)
::::Oops, I forgot to type in "are" for the first example. My mistake.
::::Oh dear, it looks like only 1 of us knows how to count up to 2. "10" is not a single digit, so "words for single digits, numerals for more" means I support "10", not "ten". <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 10:22, 14 April 2024 (UTC)
:::::Why don't you support "ten"? "Ten" is shorter than "three", "seven" or "eight". People like to group things in even numbers, not odd numbers (because they are odd 😂). [[Special:Contributions/120.16.218.233|120.16.218.233]] ([[User talk:120.16.218.233|talk]]) 23:59, 14 April 2024 (UTC)
::::::Because "10" is not a single digit. Am I saying this wrong? Should I type slower? Should I use words with one syllable or less? <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 00:31, 15 April 2024 (UTC)
:::'''No.''' Spelling out such simply words is already ''allowed'', it shouldn't be ''required''. It's very hard to see why 17 should be treated differently than 27, and if this rule were adapted, it would logically have to apply to ''thirty'', ''forty'' etc. as well. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 04:43, 14 April 2024 (UTC)
::::Yes, it should logically apply to thirty, forty etc. And the reason is obvious; single spelled words are easier to read than interrupting a sentence with digits, but that advantage weakens when multiple words are required to spell out a number. [[User:MapReader|MapReader]] ([[User talk:MapReader|talk]]) 06:40, 14 April 2024 (UTC)
:::::Actually, I find "The applicants' ages ranged from seventeen to seventy" harder and less convenient to read than "The applicants' ages ranged from 17 to 70". Especially, in latter sentence the numbers stand out, making them very easy to detect when one skims a text quickly, which is not the case in the former sentence. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 07:02, 14 April 2024 (UTC)
::::::That's why we should make "ten" the cut-off point:
::::::Zero
::::::One
::::::Two
::::::Three
::::::Four
::::::Five
::::::Six
::::::Seven
::::::Eight
::::::Nine
::::::Ten
::::::11
::::::12
::::::13.... [[Special:Contributions/120.16.218.233|120.16.218.233]] ([[User talk:120.16.218.233|talk]]) 10:03, 14 April 2024 (UTC)
::'''No.''' As spelt out in the very next sentence after {{tq|q=y|Integers from zero to nine are spelled out in words}}, we already allow that {{tq|q=y|Integers greater than nine expressible in one or two words may be expressed either in numerals or in words}}, both subject to and extended by the following {{tq|notes and exceptions}}. This is appropriately flexible; the mere fact that single words exist for some numbers does not meant they are always the best way for readers to take in quantitative information, even when reading the text closely rather than skimming it for key points – as many encyclopedia readers do. Our manual is in keeping here with at least some other major style guides, and has served as stable guidance and a sound reference point for Wikipedia editors for many years. [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 18:02, 17 April 2024 (UTC)
== "[[:Mos:DOB]]" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] ==
[[File:Information.svg|30px]]
The redirect <span class="plainlinks">[//en.wikipedia.org/w/index.php?title=Mos:DOB&redirect=no Mos:DOB]</span> has been listed at [[Wikipedia:Redirects for discussion|redirects for discussion]] to determine whether its use and function meets the [[Wikipedia:Redirect|redirect guidelines]]. Readers of this page are welcome to comment on this redirect at '''{{slink|Wikipedia:Redirects for discussion/Log/2024 April 25#Mos:DOB}}''' until a consensus is reached. <!-- Template:RFDNote --> <span style="background-color: #FFCFBF; font-variant: small-caps">[[User:Utopes|Utopes]] <sub>('''[[User talk:Utopes|talk]]''' / '''[[Special:Contributions/Utopes|cont]]''')</sub></span> 21:59, 25 April 2024 (UTC)


== Hyphenation in spelled-out fractions ==
== Quick NBSP question ==


Per [[MOS:FRAC]]: {{xt|Spelled-out fractions are hyphenated}}.
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. [[User:Dlong|Dlong]] ([[User talk:Dlong|talk]]) 16:38, 19 February 2008 (UTC)
:That (nineteen kg) would breach [[WP:MOSNUM]]. Also, if you prefer {{t1|nowrap}} to nbsps, you can use that. [[User:SandyGeorgia|Sandy<font color="green">Georgia</font>]] ([[User talk:SandyGeorgia|Talk]]) 16:42, 19 February 2008 (UTC)
::Better use "nineteen kilogram", with a normal space. Full numbers go with full names. &mminus;[[User:Woodstone|Woodstone]] ([[User talk:Woodstone|talk]]) 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" ?) [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 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. [[User:Neonumbers|Neonumbers]] ([[User talk:Neonumbers|talk]]) 03:43, 21 February 2008 (UTC)


Should this always be so? I noticed [[One half]] doesn't abide in its title, and there are potential ambiguities in use. [[User:Remsense|<span style="border-radius:2px 0 0 2px;padding:3px;background:#1E816F;color:#fff">'''Remsense'''</span>]][[User talk:Remsense|<span lang="zh" style="border:1px solid #1E816F;border-radius:0 2px 2px 0;padding:1px 3px;color:#000">诉</span>]] 05:54, 18 May 2024 (UTC)


:See existing (but closed) discussion at [[Talk:One half]], on a failed proposal to move it to one-half. In particular, there, {{u|jacobolus}} wrote {{tq|MOS:FRAC is straight up wrong here, and should be changed. Whether to add a hyphen depends on the grammatical context.}} Some others (myself included) agreed. —[[User:David Eppstein|David Eppstein]] ([[User talk:David Eppstein|talk]]) 06:03, 18 May 2024 (UTC)
I don't think the current wording makes that clear at all.
::Right, it seems to make more sense to add a hyphen when they are used as modifier (adjective), but not when used as noun. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 07:04, 18 May 2024 (UTC)
::On this basis there is clearly no consensus for the rule as stated, so I removed it until there is agreement on what it should be replaced by. My view is that of Gawaon. For example
::* A one-half octave is one half of an octave.
::* Seven eighths of a mile is 1,540 yards.
::* Three tenths of a kilometre is 300 m.
::[[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 10:29, 18 May 2024 (UTC)
:::"Hyphenate a spelled-out fraction used as a modifier" or similar seems like a fine rule to include. –[[user:jacobolus|jacobolus]]&nbsp;[[User_talk:jacobolus|(t)]] 16:32, 18 May 2024 (UTC)
::::I had [[WP:BOLD]]ly edited the page and suggested the following wording: "Spelled-out fractions are hyphenated before a noun ({{xt|They won a two-thirds majority}}), but not when used stand-alone ({{xt|The distance was seven eighths of a mile}})." That change was reverted so it seems more discussion is needed. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 16:50, 18 May 2024 (UTC)
:::::FWIW, the latest [[Fowler's Modern English]] describes real-world usage of the hyphen as "chaos", notes it's on the wane "even in British English", identifies some main uses (creating a single unit of meaning (dry-clean); phrases in front of nouns (up-to-date record, well-known man); with prefixes (ex-husband, re-cover); in lists (two- or three-fold); to avoid misinterpretation (extra-marital sex); with phrasal verbs, as a mistake; in printing,to break a word) but doesn't address this question directly.
:::::{{tq|Two-thirds majority}} fits Fowler's first and second usages; I think {{tq|seven-eighths of a mile}} fits Fowler's first, a single unit of meaning, especially considering its other representations (0.875, {{sfrac|7|8}}). [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 17:20, 18 May 2024 (UTC)
*I don't think I've got the energy to stick with this discussion, but let me point something out. In {{tq|he walked three quarters of a mile}}, I'm not sure the phrase "three quarters" is a fraction; seems to me it's 3 quarters, if you get my meaning. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 17:14, 18 May 2024 (UTC)
*:I do, but though that works in {{tq|I ate three quarters of the [[Pizza quattro stagioni|quattro stagioni]] (but not the mushrooms)}} or even {{tq|he ran three quarters of the mile (but walked the third one)}}, by itself {{tq|he walked three quarters of a mile}} is no more than {{tq|he walked {{sfrac|3|4}} mile}}. [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 17:41, 18 May 2024 (UTC)
*:: Just throwing this out: "he played three quarters of the basketball game" (it has four quarters), versus "he watched three-quarters of the movie". Just wondering. [[User:Bubba73|Bubba73]] <sup>[[User talk:Bubba73|You talkin' to me?]]</sup> 04:56, 20 May 2024 (UTC)
*:::Would you really write them differently? I would tend to write them the same (both without a hyphen). [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 05:22, 20 May 2024 (UTC)
*::::What would you say if the sentence is, "he played in three quarters of the basketball game"? To me, that reads that he played in at least part of each of three quarters of the games (say, from the middle of the second quarter to the middle of the fourth quarter), but not necessarily for a full three-quarters of the games. A bit contrived, but edge cases test rules. [[User talk:Donald Albury|Donald Albury]] 16:54, 20 May 2024 (UTC)
*:::::True, I'd say that "he played in three quarters of the basketball game" might mean that he played less compared to "he played three quarters of the basketball game", which is more likely to give the total length of his play. However, I'd say if the use or non-use of a hyphen should depend on such subtleties, we're overcomplicating things. According to the rule I favour, no hyphen should be used in either case. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 17:19, 20 May 2024 (UTC)
*:Would it make a difference with fourths instead of quarters? —[[User:David Eppstein|David Eppstein]] ([[User talk:David Eppstein|talk]]) 18:22, 18 May 2024 (UTC)
*::Not sure. To be honest, I was quite sleep-deprived when I made that post and I'm not sure now how exactly I thought it would clarify anything. :( What about the case of "one half"? There's no "one twoth". [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 07:02, 19 May 2024 (UTC)
*:::"One half" is somewhat an exception because it is used so commonly (cf. {{xt|first, second, third}}, instead of {{!xt|oneth, twoth, threeth}}). The same goes for "one quarter" (though "one fourth" is an accepted alternative). I don't see anything wrong with the phrase "three quarters of a mile", that's just 3*(1/4) mi = 3/4 mi. <span class="nowrap">~~[[User:lol1VNIO|lol1]][[Special:contribs/Lol1VNIO|<span style="color:#D11D13">VNIO</span>]] (<small>I made a mistake?</small> '''[[User talk:lol1VNIO|<span style="color:#006400">talk to me</span>]]''')</span> 10:28, 19 May 2024 (UTC)
*::::I didn't say there's anything wrong with it. I was just pointing out, since this discussion is nominally about fractions, that it may not be clear that "three quarters" (and so on) actually is a fraction. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 20:34, 19 May 2024 (UTC)
*:::::I think it's clear that a "quarter" is 1/4. A quarter of an hour is 15 min. A quarter of a dollar is 25 cents. I'm sorry, I'm not sure where the confusion lies. <span class="nowrap">~~[[User:lol1VNIO|lol1]][[Special:contribs/Lol1VNIO|<span style="color:#D11D13">VNIO</span>]] (<small>I made a mistake?</small> '''[[User talk:lol1VNIO|<span style="color:#006400">talk to me</span>]]''')</span> 09:01, 20 May 2024 (UTC)
*::::::Well, since you press the point: no, it's not clear. "Three quarters" might be a fraction (3/4), or it might be three times a fraction (3{{middot}}1/4), but not itself a fraction. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 09:25, 20 May 2024 (UTC)
*:::::::3/4 and 3(1/4) are both the same, just expressed differently. One can choose interpret "three quarters" as the former and the problem would be solved. <span class="nowrap">~~[[User:lol1VNIO|lol1]][[Special:contribs/Lol1VNIO|<span style="color:#D11D13">VNIO</span>]] (<small>I made a mistake?</small> '''[[User talk:lol1VNIO|<span style="color:#006400">talk to me</span>]]''')</span> 09:28, 20 May 2024 (UTC); edited 09:31, 20 May 2024 (UTC)
*::::::::*{{tq|3/4 and 3(1/4) are both the same, just expressed differently}}{{snd}}Wow, and to think I spent all that money on a degree in applied math from Harvard, and they never taught me that. If what you're saying is really true, then I'm going to ask for my money back! Next you'll be telling me that (1/x){{middot}}x{{nbsp}}={{nbsp}}1.
*::::::::*{{tq|One can choose interpret "three quarters" as the former}}{{snd}}You're contradicting yourself. If the two things are the same, then choosing between them makes no sense, since (says you) they're both the same -- there's no choice to be made. But they're ''not'' the same. That's the point. One's a fraction and one is an integer times a fraction, in which case the question of "how to write fractions" doesn't apply to it.
*::::::::[[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 09:51, 20 May 2024 (UTC)
*:::::::::Are you saying that "one eighth" is a fraction, but "three eighths" isn't? That would be a highly original interpretation of "fraction". [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 10:04, 20 May 2024 (UTC)
*::::::::::No. ''If'' we interpret "three eighths" not as a fraction, but rather as an integer followed by a fraction, then "one eighth" is also not a fraction. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 17:49, 20 May 2024 (UTC)
*:::::::::How silly of me! All those Aristotlean logic I learned for nothing! <span class="nowrap">~~[[User:lol1VNIO|lol1]][[Special:contribs/Lol1VNIO|<span style="color:#D11D13">VNIO</span>]] (<small>I made a mistake?</small> '''[[User talk:lol1VNIO|<span style="color:#006400">talk to me</span>]]''')</span> 10:06, 20 May 2024 (UTC)
*::::::::::All those grammar, too! [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 17:49, 20 May 2024 (UTC)
*::::::::Not necessarily. The fraction 3/4 can be seen as indicating a cohesive part. While 3(1/4) would equal the same amount, it might not be a single "thing". For example, imagine a cake cut into 8 equal parts (labeled 1-8 in clockwise fashion). If I eat pieces 1-6, then I can be said to have eaten 3/4 of the cake and also to have eaten 3 of the quarters of the cake. However, If I eat pieces 2-4 and 6-8, then I can be said to have eaten 3/4 of the cake but not to have eaten 3 of the quarters of the cake. --[[User:Khajidha]] ([[User talk:Khajidha|talk]]) ([[Special:Contributions/Khajidha|contributions]]) 15:34, 20 May 2024 (UTC)
*::::::::: ^ This guy gets it. [[User:EEng#s|<b style="color:red;">E</b>]][[User talk:EEng#s|<b style="color:blue;">Eng</b>]] 17:49, 20 May 2024 (UTC)
*:::::::::I think rarely in articles, you would dig into the nitty-gritty of ''how'' it came to 3/4. In the original example ({{tq|he walked three quarters of a mile}}), no reader would be perplexed as to if he walked {{tq|three (quarters of a mile)}} or {{tq|(three quarters) of a mile}}. If you really want to specify that he either walked in quarter miles, taking breaks along the way, or walked 0.75 miles in one go, then say it.
*:::::::::In User:Khajidha's example, there is a fraction in both cases: {{tq|said to have eaten 3/4 of the cake and also to have eaten 3 of the quarters of the cake}} (here, 3/4 is "three quarters"); and {{tq|have eaten 3/4 of the cake but not to have eaten 3 of the quarters of the cake}} (also 3/4 aka "three quarters"). So "three quarters" ''is'' a fraction either way. <span class="nowrap">~~[[User:lol1VNIO|lol1]][[Special:contribs/Lol1VNIO|<span style="color:#D11D13">VNIO</span>]] (<small>I made a mistake?</small> '''[[User talk:lol1VNIO|<span style="color:#006400">talk to me</span>]]''')</span> 19:42, 20 May 2024 (UTC)
*:::::::::I.e., basically what ''Chicago'' is saying in the passage I quoted below? (And using the same example, incidentally!) [[User:Graham11|Graham]] ([[User talk:Graham11|talk]]) 03:19, 21 May 2024 (UTC)
*:::As for "used stand-alone", that is when the [[denominator]] of the fraction is not an [[attribute (grammar)|attribute]], that's when it shouldn't be hyphenated (according to the discussion). An attribute is optional, so if you remove it, it still makes grammatical sense. For example, {{xt|They won a '''three-quarters''' majority}} (not standalone), if you remove "three-quarters", it makes grammatical sense; whereas {{xt|They won a majority of '''three quarters'''}} (standalone), if you remove "three quarters", it makes no sense. Thus, NebY's example above ({{!xt|seven-eighths of a mile}}) should not be hyphenated because there, the attribute is "of a mile". <span class="nowrap">~~[[User:lol1VNIO|lol1]][[Special:contribs/Lol1VNIO|<span style="color:#D11D13">VNIO</span>]] (<small>I made a mistake?</small> '''[[User talk:lol1VNIO|<span style="color:#006400">talk to me</span>]]''')</span> 10:49, 19 May 2024 (UTC)
*::::That was my proposal (also suggested by others), and I still think it makes a lot of sense and reflects widespread usage fairly well. {{u|EEng}}, if you think the used wording was unclear, maybe you have a suggestion on how to improve it? [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 11:21, 19 May 2024 (UTC)
*:::::We could explain it linguistically and note that hiding attributes would still make grammatical sense: {{tq|Spelled-out fractions are hyphenated when it is used as an [[attribute (grammar)|attribute]] ({{xt|They won a two-thirds majority}}), but not when used stand-alone ({{xt|The distance was seven eighths of a mile}}). Rule of thumb: hyphenate if removing the fraction would still make grammatical sense.}} Instead of "when used stand-alone", we could dig deeper into linguistics and say "when the [[denominator]] is used as the [[head (linguistics)|head noun]] of the phrase", but I doubt that would be any more clear. <span class="nowrap">~~[[User:lol1VNIO|lol1]][[Special:contribs/Lol1VNIO|<span style="color:#D11D13">VNIO</span>]] (<small>I made a mistake?</small> '''[[User talk:lol1VNIO|<span style="color:#006400">talk to me</span>]]''')</span> 11:50, 19 May 2024 (UTC); edited 11:58, 19 May 2024 (UTC)
*::::::Hmm. I might not hyphenate if the emphasis was on the denominator, but that's a more narrow exception and perhaps more traditionalist. [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 12:18, 19 May 2024 (UTC)
*::::::The suggested wording sounds fine for me. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 13:05, 19 May 2024 (UTC)
*::::::Lol1VNIO's suggestion makes sense to me too. I would just replace "when it used" with "when used". [[User:Dondervogel 2|Dondervogel 2]] ([[User talk:Dondervogel 2|talk]]) 18:56, 19 May 2024 (UTC)


:If we were writing here for ''The New Yorker'' or some other highfalutin publication, we could, perhaps, follow a more complex style, but in the encyclopedia anyone can edit, simple rules are better. It's like the comma after a mdy date. Sometimes there is no need for a comma after ''May 20, 2024'', but it is so much easier to always use it and it doesn't hurt anything. Let's stick with the hyphen in written out fractions. [[One half]] may or may not be correct, but we can live with some inconsistency. &nbsp;[[User:SchreiberBike|SchreiberBike&nbsp;]]&#124;[[User talk:SchreiberBike#top|&nbsp;⌨&nbsp;]] 11:36, 20 May 2024 (UTC)
Followup. Suppose you have "is ''C''<sub>p</sub> = 38.171 J mol<sup>−1</sup> K<sup>−1</sup> at"


I would agree with others that I don't think it makes sense to hyphenate fractions where they are being used as compound modifiers. However, to maintain consistency with [[MOS:HYPHEN]], I would suggest that we further specify that we only use hyphens with fractions where it is being used as an ''attributive'' or ''substantive'' modifier (which is what I think most of us have in mind anyway) rather than a ''predicative'' modifier. [[User:Graham11|Graham]] ([[User talk:Graham11|talk]]) 04:27, 20 May 2024 (UTC)
Tell me:
#Where you think the current MoS rule "recommends" non-breaking spaces. How many? All seven spaces? only some of them? Five? One? Three?
#Where this should logically be allowed to break.
#Whether they are different.


:That matches my intuition. —[[User:David Eppstein|David Eppstein]] ([[User talk:David Eppstein|talk]]) 08:10, 20 May 2024 (UTC)
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.
:Our manual of style has to be plain and direct, providing easily understood guidance to all editors who need it, not only those who are trained in the use of high-falutin' terms like attributive, substantive, predicative and modifier. [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 11:19, 20 May 2024 (UTC)
::Are you proposing that we amend [[MOS:HYPHEN]]? [[User:Graham11|Graham]] ([[User talk:Graham11|talk]]) 03:07, 21 May 2024 (UTC)


The Australian style guide says {{tq|Use a hyphen in fractions written out in words (eg two-thirds).}} I oppose any change to the MOS. [[User:Hawkeye7|<span style="color:#800082">Hawkeye7</span>]] [[User_talk:Hawkeye7|<span style="font-size:80%">(discuss)</span>]] 04:46, 20 May 2024 (UTC)
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.


:What's "the Australian style guide"? Anyway, our old rule stating the same has already been thrown out. The question is now what to replace it with. [[User:Gawaon|Gawaon]] ([[User talk:Gawaon|talk]]) 05:24, 20 May 2024 (UTC)
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 [[Fluoromethane|actual article]] from which I borrowed this expression.
::That's [https://stylemanual.com.au/contents/editing/numbers-and-units/numbers#/fractions-and-ordinal-numbers here], along with {{tq|Write fractions in full in running text, and use a hyphen}}. The Australian govenment's style manual has {{tq|Hyphens link parts of a fraction.}}[https://www.stylemanual.gov.au/grammar-punctuation-and-conventions/punctuation/hyphens] [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 10:33, 20 May 2024 (UTC)
The BBC News Style Guide has simply {{tq|three-quarters (and other fractions)}}.[https://www.bbc.co.uk/newsstyleguide/h] [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 10:22, 20 May 2024 (UTC){{pb}}
Purdue has a collection of style guides; I only found {{tq|Use a hyphen with compound numbers: forty-six, sixty-three, Our much-loved teacher was sixty-three years old.}}[https://owl.purdue.edu/owl/general_writing/punctuation/hyphen_use.html] [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 10:44, 20 May 2024 (UTC)


:That's not really relevant to fractions. [[User:Graham11|Graham]] ([[User talk:Graham11|talk]]) 03:04, 21 May 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).
::It is relevant when the only guidance on compund numbers is to hyphenate; that includes fractions. Back in 2007, we stated it as {{tq|Spelled-out two-word numbers from 21 to 99 are hyphenated (fifty-six), as are fractions (seven-eighths)}}[https://en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style/Dates_and_numbers&oldid=147967210#Hyphenation] (it may have been on some other MOS page before then). [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 15:48, 23 May 2024 (UTC)
*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?
{{pb}}
*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. [[User:Gene Nygaard|Gene Nygaard]] ([[User talk:Gene Nygaard|talk]]) 10:43, 28 February 2008 (UTC)
{{u|Graham11}} reports ''[[The Chicago Manual of Style]]'' {{tq|also prescribes the hyphenated form, even when the term is used as a noun}}.[https://en.wikipedia.org/w/index.php?title=Talk:One_half&diff=prev&oldid=1224402775] [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 17:35, 20 May 2024 (UTC)
:The most relevant passage is 9.14: {{tq2|9.14 '''Simple fractions.''' Simple fractions are spelled out. For the sake of readability and to lend an appearance of consistency, they are hyphenated in noun, adjective, and adverb forms. In the rare event that individual parts of a quantity are emphasized, however, as in the last example, the expression is unhyphenated. See also 7.89, section 1, under fractions, simple. For decimal fractions, see 9.19.<p>{{hanging indent|{{resize|90%|She has read three-fourths of the book.}}}}{{hanging indent|{{resize|90%|Four-fifths of the students are boycotting the class.}}}}{{hanging indent|{{resize|90%|I do not want all of your material; two-thirds is quite enough.}}}}{{hanging indent|{{resize|90%|A two-thirds majority is required.}}}}{{hanging indent|{{resize|90%|''but''}}}}{{hanging indent|{{resize|90%|We divided the cake into four quarters; I took three quarters, and my brother one.}}}}}} [[User:Graham11|Graham]] ([[User talk:Graham11|talk]]) 03:17, 21 May 2024 (UTC)
::Thanks for that. In short, ''Chicago'' supports our {{tq|Spelled-out fractions are hyphenated}} with one minor exception. [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 15:41, 23 May 2024 (UTC)
''[[Collins English Dictionary]]'s'' entry for ''two-thirds'' begins with {{tq|two-thirds of}}.[https://www.collinsdictionary.com/dictionary/english/two-thirds] [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 17:48, 20 May 2024 (UTC){{pb}}
''Merriam-Webster'' online gives for three-quarters {{tq|Three-quarters of the class will be going on the trip}} and {{tq|three-quarters of an hour}}, plus many "Recent Examples on the Web", each using {{tq|three-quarters of}}, hyphenated: {{tq|nearly three-quarters of those using the feature}} (WSJ); {{tq|three-quarters of lawmakers}} (Anchorage Daily News); {{tq|three-quarters of a percentage point}} (Los Angeles Times) and more.[https://www.merriam-webster.com/dictionary/three-quarters] [[User:NebY|NebY]] ([[User talk:NebY|talk]]) 18:06, 20 May 2024 (UTC)


== "Full, unambiguous signifier" for currencies ==


Do we have a list somewhere of "full, unambiguous signifier[s]" for currencies? [[MOS:CURRENCY]] links to [[List of circulating currencies]], but nowhere can we find "A$" or "US$" there, which MOS:CURRENCY recommends us to use. [[User:LightNightLights|LightNightLights]] ([[User talk:LightNightLights|talk]] • [[Special:Contributions/LightNightLights|contribs]]) 10:41, 18 May 2024 (UTC)
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:
<pre>
"is {{nowrap begin}}''C''<sub>p</sub> = 38.171 J mol<sup>−1</sup> K<sup>−1</sup>{{nowrap end}} at"
</pre>


:{{ping|LightNightLights}} See [[Currency symbol#List of currency symbols currently in use]]. That article deviates heavily from the [https://openknowledge.worldbank.org/bitstream/handle/10986/33367/33304.pdf?sequence=4 World Bank Group's editorial guide] (p. 134) that lists uncommon symbols like $A. <span class="nowrap">~~[[User:lol1VNIO|lol1]][[Special:contribs/Lol1VNIO|<span style="color:#D11D13">VNIO</span>]] (<small>I made a mistake?</small> '''[[User talk:lol1VNIO|<span style="color:#006400">talk to me</span>]]''')</span> 11:25, 19 May 2024 (UTC)
Which renders this:
:{{ping|LightNightLights}} I've just discovered that templates that are titled after [[ISO 4217]] codes standardize the signifiers on enwiki. Use {{tl|AUD}}, {{tl|CAD}}, {{tl|USD}} etc. or {{tlp|Currency|value|code}} with codes at [[Module:Currency/Presentation]] <span class="nowrap">~~[[User:lol1VNIO|lol1]][[Special:contribs/Lol1VNIO|<span style="color:#D11D13">VNIO</span>]] (<small>I made a mistake?</small> '''[[User talk:lol1VNIO|<span style="color:#006400">talk to me</span>]]''')</span> 15:39, 19 May 2024 (UTC); edited 16:52, 19 May 2024 (UTC)

::@[[User:Lol1VNIO|Lol1VNIO]] Thank you. I do not consider myself as someone who writes or contributes to style manuals so I do not know the answers to these questions, but:
"is {{nowrap begin}}''C''<sub>p</sub> = 38.171 J mol<sup>−1</sup> K<sup>−1</sup>{{nowrap end}} at"
::* Should [[MOS:CURRENCY]] link to {{slink|Currency symbol|List of currency symbols currently in use}}?

::* Should MOS:CURRENCY recommend editors to use the templates (instead of checking a list?) in the MOS?
Neat, isn't it?
::[[User:LightNightLights|LightNightLights]] ([[User talk:LightNightLights|talk]] • [[Special:Contributions/LightNightLights|contribs]]) 18:03, 20 May 2024 (UTC)

:::{{ping|LightNightLights}} The guide already links to Currency symbols, specifically to #dollar variants, though a link to the page after "full, unambiguous signifier" wouldn't be a bad idea. As for templating every currency, not really. It makes sense in some ({{currency|100|THB}}) but others you can just enter on your keyboard. Often, you're familiar with a set of currencies that you don't need to look up, anyway. <span class="nowrap">~~[[User:lol1VNIO|lol1]][[Special:contribs/Lol1VNIO|<span style="color:#D11D13">VNIO</span>]] (<small>I made a mistake?</small> '''[[User talk:lol1VNIO|<span style="color:#006400">talk to me</span>]]''')</span> 20:15, 20 May 2024 (UTC)
You can read up on line wrapping at the brand new how-to guide [[Wikipedia:Line break handling]].
::::@[[User:Lol1VNIO|Lol1VNIO]] I swear that I fully read MOS:CURRENCY multiple times, but I didn't notice the Currency symbols link. I am not sure how to correctly add the link after "full, unambiguous signifier", so I am okay with you adding it. [[User:LightNightLights|LightNightLights]] ([[User talk:LightNightLights|talk]] • [[Special:Contributions/LightNightLights|contribs]]) 10:24, 21 May 2024 (UTC)

:::::Perhaps add suggestions to consider using {{tlx|currency}}, {{tlx|USD}} and similar. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">[[User:Stepho-wrs|'''&nbsp;Stepho&nbsp;''']]&nbsp;<span style="font-size:xx-small; vertical-align:top">[[User Talk:Stepho-wrs|talk]]&nbsp;</span></span> 06:11, 24 May 2024 (UTC)
--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|talk]]) 22:10, 12 March 2008 (UTC)

== DWT ==

The shipping term ''deadweight ton'' refers to a long ton (2240 lb) of [[tonnage|deadweight]]. It is abbreviated as "DWT". A similar term, ''deadweight tonne'', refers to the same but this time in tonnes (1000 kg). The problem is that it seems that the same abbreviation, "DWT", is used. [http://www.unc.edu/~rowlett/units/dictD.html Russ Rowlett's Dictionary of Units of Measurement] has this to say.

<blockquote>deadweight ton (dwt)<br/>a traditional unit of weight or mass used in the shipping industry. The deadweight tonnage of a ship is the difference between its weight when completely empty and its weight when fully loaded. This includes the weight of everything portable carried by the ship: the cargo, fuel, supplies, crew, and passengers. The deadweight ton is traditionally equal to the British ("long") ton of 2240 pounds (1016.047 kilograms). However, more and more often it is being taken to equal the metric ton (exactly 1000 kilograms, or 2204.623 pounds).</blockquote>

How do we go about dealing with the ambiguity? It has been [[Template talk:Convert#Support for bbl, long ton|suggested]], by [[User:Haus|Haus]], that we choose a standard for Wikipedia. Other means of disambiguation have also been suggested. So far four approaches have been considered. Symmetry would have us consider a fifth (I ''do'' like symmetry). Let me list them.

#Let "DWT" always stand for long tons of deadweight and spell ''deadweight tonne(s)'' out whenever necessary.
#Let "DWT" always stand for tonnes of deadweight and spell ''deadweight ton(s)'' out whenever necessary.
#Avoid the abbreviation, "DWT", altogether and always spell both terms out.
#Use "DWT&nbsp;(metric)" and "DWT&nbsp;(long)" for tonnes and long tons respectively of deadweight.
#Use "DWT<sub>metric</sub>" and "DWT<sub>long</sub>" for tonnes and long tons respectively of deadweight.

Here are some of the advantages and disadvantages that I see with these.

#This follows tradition. As far as I can tell, this is the most common meaning of "DWT". However, I've got only my own Googling to to support this and we're aware of the American dominance of the web. Also, as the decades, centuries ... millenia ... wear on ... Wikipedia is forever, right. The long ton meaning of "DWT" might fall out of favour.
#Against tradition & common use but may be forward-looking, this has the added advantage of naturally conforming to standard Wikipedia practice in which conversions to metric are generally given whereas conversions to avoirdupois are generally not and in which (in text as opposed to infoboxes) the units converted from are generally spelt out and the units converted to are generally abbreviated: in other words 2. allows "125 deadweight tons (127 DWT)" whereas with 1. we can only have either "125 DWT (127 deadweight tonnes)" or "125 deadweight tons (127 deadweight tonnes)". Of course, both 1. and 2. require that readers and editors be familiar with the Wikipedia standard — this may be a big ask.
#This avoids any possibility of ambiguity and is unbiased towards this or that system of measurement but means that we have to have a lot more text.
#This again avoids the ambiguity and bias. It allows both terms to be abbreviated. It makes it clear to those none too familiar with shipping that it is a long ton rather than a short ton (or even a metric ton) which is being refered to. However, it is kind of ugly especially if you're a conversion, e.g. "125 deadweight tons (127 DWT (metric))", even more so if you want to abbreviate both units, e.g. "125 DWT (long) (127 DWT (metric))".
#This has the advantages of 4. whilst avoiding the ugliness, however, it could be argued that a subscript is part of the symbol therefore "DWT<sub>metric</sub>" & "DWT<sub>long</sub>" could be seen as being symbols of our own invention.

So, what say you? What do we do here? My preference is going to 5. (I had been keen on 4. until I started typing examples out & saw how it looks). <span title="Representation in the International Phonetic Alphabet (IPA)" class="IPA">[[User:Jimp|J]][[Special:Contributions/Jimp|ɪ]][[User talk:Jimp|m]][[wikt:User:Jimp|p]]</span> 07:29, 4 March 2008 (UTC)

: Just to point out that we're not the only ones having difficulties with this, the [[United States Government Printing Office|GPO]] uses [http://www.gpoaccess.gov/stylemanual/2000/chapter_txt-9.html inconsistent deinitions] where "ton=long ton," "t=metric ton (or tonne)," but "dwt"="deadweight ton." My inclination is also orbiting #4 and #5 above. On the surface, it seems that a clever use of wikilinks could be used to stave off confusion, but it seems to work poorly on long pages with many uses of the forms "[[Deadweight tonnage (metric)|DWT<sub>metric</sub>]]" & "[[Deadweight tonnage|DWT<sub>long</sub>]]" Cheers. <span style="font-family:Bradley Hand ITC;">[[User:Haus|<font style="color:Blue;"><font size="+2">H</font>aus</font>]]<sup style="font-size : 6pt ;">[[User_talk:Haus|<font style="color:Green;">Talk</font>]]</sup></span> 15:05, 4 March 2008 (UTC)

::Overall I too would prefer #4 or #5 (the latter being better due to being prettier). It should be remembered however that the problem of ambiguity also extends to sources - for instance [http://www.faktaomfartyg.se/ this] very useful website lists a DWT figure for mosts ships but I've no idea whether they're in tons or tonnes (presumably the metric ones, but is that an assumption I can make?). -- [[User:Kjet|Kjet]] ([[User talk:Kjet|talk]]<span style="font-weight:bold;">&nbsp;·</span> [[Special:Contributions/Kjet|contribs]]) 15:32, 4 March 2008 (UTC)

:::Of course, your linking could go like this "[[Deadweight tonnage|DWT]]<sub>[[tonne|metric]]</sub>" & "[[Deadweight tonnage|DWT]]<sub>[[long ton|long]]</sub>" but, yes, disambiguation via links is problematic not only for the reason mentioned above but also because it requires the reader to click on the link (unless they're familiar with the tool-tip-hover-over trick), which can be a great distraction and which will be impossible if you're sitting on the train with a copy of the article you'd printed during lunch. <span title="Representation in the International Phonetic Alphabet (IPA)" class="IPA">[[User:Jimp|J]][[Special:Contributions/Jimp|ɪ]][[User talk:Jimp|m]][[wikt:User:Jimp|p]]</span> 16:23, 4 March 2008 (UTC)

::::My two cents.
::::Avoid "DWT" entirely. Spell out deadweight when appropriate.
::::*For what it's worth, you also see "dwt tons"; the "t" at the end of dwt doesn't even have to come from "tons" or "tonnage" in any flavor; rather, some look it as the "wt" being a common abbreviation of "weight" with a d stuck in front to identify "deadweight".
::::Any discussion of using "tonne" is inappropriate without also considering American English, where it is a metric ton not a "tonne", and French, where ''tonne'' is as ambiguous as ton is in English.
::::What is needed with all the ton of different "tons" used in shipping is more clarity in what is being measured. More clarity on the meaning of "light weight" and various other things used as well as dead weight. More clarity on basics such as whether the measurement is a measurement of volume or one of mass. For example, what do we do with submarines? Their surface displacement is a normal measurement of mass, but their dived displacement is essentially a measure of volume: [[Archimedes' principle]], a floating object displaces its mass and a submerged object displaces its volume.
::::It is truly unfortunate that the BIPM and other standards agencies consider any tons acceptable for use with SI, and doubly unfortunate that they choose to specify a symbol for it (t) that is also used for long tons or for short tons.
::::*Therefore, let's just stick with unambiguous [[megagram]]s (Mg), [[gigagram]]s (Gg), [[teragram]]s (Tg) and the like for the units. [[User:Gene Nygaard|Gene Nygaard]] ([[User talk:Gene Nygaard|talk]]) 18:45, 4 March 2008 (UTC)

:::::To be more specific on my first point. I especially mean not to use "DWT" (nor the more appropriate lowercase "dwt") as a ''symbol for a unit of measure''. It is less objectionable to use it as part of the identification of the quantity being measured, but you should not have a number followed by "dwt" used as a unit symbol, whether standing alone or the subscripted suggestions above. It's part of the general rules about not attaching information to the units of measure, and especially not to the metric units. Using something like psia or psig is frowned upon for the same reasons.
:::::*''Unacceptable:'' The ship is 9,400 dwt<sub>long</sub> (9,400 dwt<sub>metric</sub>)
:::::*''Acceptable:'' The ship has a dwt of 9,400 long tons (9,550 t) [at least on first use in an article, I'd say that it is better to spell out "deadweight tonnage" than to use "dwt" in this case]
::::: [[User:Gene Nygaard|Gene Nygaard]] ([[User talk:Gene Nygaard|talk]]) 18:55, 4 March 2008 (UTC)

::::::So, we have a sixth option.
:::::::{|
|-
|valign=top|6.&nbsp;||Don't use "DWT", use "dwt". However, "dwt" is an abbreviation of "deadweight" ''not'' "deadweight tonne" or "deadweight ton". Neither use "deadweight tonne" nor "deadweight ton" but treat "deadweight" like "height", "length", "speed", etc.
|}
::::::Of course, "dwt" (lower case) is the symbol for the obsolete pennyweight (here's another example of "wt"'s standing for "weight" ... also "cwt") but if (when we're talking about deadweight tonnage) we're not using "dwt" as a symbol for a unit of measure, there can be no confusion.
::::::One must admit that Gene's approach is the easiest to comprehend as it follows the norms of English — "The ship has a dwt of 9,400 long tons (9,550 t) and the captain has a height of 6 foot 2 inches (188 cm)." We'd also avoid the temptation to use the fancy unconventional linking I suggested above (linking "DWT" to ''Tonnage'' and the subscripts to articles on their respective unit).
::::::Gene, I suppose this means that the likes of "bhp", "shp", etc. is also frowned on.
::::::<span title="Representation in the International Phonetic Alphabet (IPA)" class="IPA">[[User:Jimp|J]][[Special:Contributions/Jimp|ɪ]][[User talk:Jimp|m]][[wikt:User:Jimp|p]]</span> 01:14, 5 March 2008 (UTC)
:::::::I like the #5 option. I wouldn't use dwt because of the pennyweight measurement. &mdash;<span style="border:1px solid black;padding:1px;">[[User:MJCdetroit|<font color="#0000CD">'''MJC</font ><font color="#FF0000">detroit'''</font >]]</span> [[User_talk:MJCdetroit|<sup><font color="green">(yak)</font></sup>]] 02:00, 5 March 2008 (UTC)

::::::::Trying to distinguish "dwt" meaning ''deadweight'' from "DWT" meaning ''deadweight metric tons'' (or ''deadweight long tons'', whatever) is just sheer lunacy. We have enough articles tainted by Wikipedia usage already, without having to create a new way of accomplishing this.
::::::::And worrying about a unit the Brits—and by extension, most or all of the Commonwealth—outlawed over 129 years ago (as of 1 Jan 1879, together with its pound, while retaining its ounce as an official exception to metric conversion in the 21st century), is not far behind. Especially when it is <sup>3</sup>&frasl;<sub>1960000</sup> as large; anyone who thinks for more than a millisecond that these ships might be weighed in pennyweights probably ought not be allowed to use an encyclopedia in the first place.
::::::::These are '''not''' different units of measure. We ''should not have'' different unit symbols depending on the particular application in which they are being used. These proposals are like using "French degrees Celsius" and '''inventing''' a Wikipedia symbol <sup>F</sup>C for them in articles related to France, and "Swedish degrees Celsius with a symbol <sup>S</sup>C for them in articles related to Sweden. [[User:Gene Nygaard|Gene Nygaard]] ([[User talk:Gene Nygaard|talk]]) 14:46, 5 March 2008 (UTC)
::::::::: I'd be interested in seeing a reference which defines "dwt" as "deadweight" and not "deadweight tons" or "deadweight tonnage." Various forms including "DWT," "dwt," "d.w.t." are used to indicate "deadweight tons" or "deadweight tonnage" at the [http://www.gpoaccess.gov/stylemanual/2000/chapter_txt-9.html GPO] as I mentioned earlier, [http://dictionary.reference.com/browse/dwt 6 dictionaries] and the three industry-specific technical manuals I have at hand. <span style="font-family:Bradley Hand ITC;">[[User:Haus|<font style="color:Blue;"><font size="+2">H</font>aus</font>]]<sup style="font-size : 6pt ;">[[User_talk:Haus|<font style="color:Green;">Talk</font>]]</sup></span> 15:05, 5 March 2008 (UTC)
←''outdent''←
Weighing ships in pennyweights ... hilarious. No, anyone with half a brain could tell the difference. My concern, however, was that a template can't. <span title="Representation in the International Phonetic Alphabet (IPA)" class="IPA">[[User:Jimp|J]][[Special:Contributions/Jimp|ɪ]][[User talk:Jimp|m]][[wikt:User:Jimp|p]]</span> 15:50, 5 March 2008 (UTC)

:Not much different from the half-baked notion that we should not use "kt" as a symbol for the unit of speed for those same ships, because somebody might confuse it with a symbol for non-SI and not-acceptable-for-use-with-SI units of energy, is it?

:I realize where you are coming from. My main point is that a template for converting measurements should not be concerning itself with what those units are being used to measure. It is the same "tons" that are used for "light weight" of a ship as for "deadweight" of a ship, the those same tons are also used for "standard displacement" and for "full load displacement" and various other weights. Two or three different units all called "tons", to be sure, (plus a ton of other tons measuring volume and energy and force and power and whatever) but not 15 or 24 or whatever different units of mass.

:But for those who do not realize where you are coming from, let me explain. [[User:Jimp]] is the ''one and only person'' on the planet Earth who is capable of editing the monster template {{tl|convert}}. It can do lots and lots of different things, most of them quite well. It also does many other things very poorly. But it is so bloated, so convoluted, that nobody other than its chief creator (at least since the early days as a simple template) can figure out how to fix it if it isn't working as well as it should. He has total control; no fixes can be made without going through him, even if the template weren't "[[Wikipedia:Page protection|protected]]". Even ordinary users would have to study it for the equivalent of a 6-semester hour college course in order to be able to understand its intricacies and use that black box well in all situations. To show just the tip of the iceberg:
:*The [[:Category:Subtemplates of Template Convert]] has 1,024 articles.
:*Special:All pages for the template namespace has somewhere in the neighborhood of 3,033 subpage templates and subpage template redirects under the main convert template.
:*Yet, despite all this complexity (or perhaps more properly ''because'' of this unbelievable complexity), you can
::Apparently convert nautical miles to [[siemens (unit)|siemens]] per [[tesla (unit)|tesla]]:
::*<nowiki>{{convert|1347|nmi|S/T}} </nowiki> &rarr; {{convert|1347|nmi|S/T}}
::*#That's not an accurate conversion, of course. And in any case, even when you figure out that the "S/T" symbol isn't intended to represent siemens per tesla (whose dimensions are the inverse of those of acceleration, L<sup>−2</sup>&nbsp;T), you still have the problem that despite its overwhelming complexity, the convert black box does no [[dimensional analysis]] of the units, and lets you blithely convert apples to oranges. Perhaps not literally, or I just don't know the symbols for {{convert|1347|apple|orange}}, one of the few missing on that Special:All pages list. But, in this case, the eguivalent nautical miles (dimensions: L) to short tons (dimensions: M) does not produce an error message, unlike the attempt to literally convert from apples.
::*#What that "S/T" is intended to represent indicates a significant need to expand the scope of the current discussion beyond the original "DWT" issue.
::Or, suppose you have a product with nutritional information "per 12 ounces" and you want to convert it. Using <nowiki>"per {{convert|12|oz|mL|disp=/|sp=us}})"</nowiki> looks reasonable, doesn't it?
::*If you want to see what happens, go look at the [[Sparks (drink)|article]] where I added exactly that conversion 3½ months ago. It is still there as I write this.
::*Once again, bitten by a failure to do dimensional analysis.
:Furthermore, the template has a strong bias against the use of [[WP:ENGVAR|American English]], requiring explicit addition of a parameter (sp=us) to achieve it. Yet, when it comes to "metric tons", that parameter doesn't work. Instead, the spelling setting is ignored and what is spelled out depends on the unit parameters used.
:Maybe this discussion should instead branch out to a more general discussion of whether or not the use of complicated black boxes of this sort is appropriate on Wikipedia. [[User:Gene Nygaard|Gene Nygaard]] ([[User talk:Gene Nygaard|talk]]) 17:18, 5 March 2008 (UTC)

::I sympathise with Gene's statement that "a template for converting measurements should not be concerning itself with what those units are being used to measure" as a logical consequence of "the general rules about not attaching information to the units of measure", which, in turn, seem quite reasonable to me especially when looked at from the point of view of comprehensibility. However, if people are going about breaking these rules we either have to enforce them or work around the situation. Now, I was lead to believe that the terminology "deadweight tons", either long or metric, was what is in use and started to add such a work-around to {{tl|convert}}. If instead we could somehow get editors to follow those aforementioned rules against this type of terminology, I'd be more than happy to trim the deadweight out of the black box. "1000 tons of deadweight" is a whole lot easier to comprehend to those unfamiliar with shipping terminology than "1000 deadweight tons" (better still if we specify what flavour of ton we mean). As for "DWT", "dwt", "d.w.t." or however you write it; if we can't make up our minds on what it's meant to stand for, why don't we just ban it? Thus a seventh option:
:::{|
|-
|valign=top|7.&nbsp;||Do not attach information to units of measure. Therefore don't use "deadweight (long/metric) ton(ne)(s)". Treat "deadweight" like "height", "length", "speed", etc. Don't abbreviate "deadweight", always spell it out.
|}
::As for Gene's comments regarding <nowiki>{{convert}}</nowiki>, some of them he has already voiced on the template's talk page and I have responded there; but, for those who might not feel like searching the template's talk archive, let me breifly recap. To that which we haven't yet covered there I'll respond here but again briefly, let more detailed discussion be carried out there.
::Others can and have edited the monster (including Gene), though, yes, anything more than minor edits would require more patience in getting familiar with a rather complex template than most editors probably have. It is complex, it was, however, never my intention to make it so complex that I'd be the only one editing. If there is a significantly simpler way to get it to do what it does without increasing the pre-expand size, I'll be happy to see it replace the current version. I'd be only too happy to relinquish my "total control".
::The lack of dimensional analysis is a down fall in the template. If this is a real problem, it could be fixed. Fixing it would, of course, require more code & therefore more complexity. I was aware of this as I wrote the template but I thought "Garbage In, Garbage Out" — if you try to convert litres per hundred kilometres to hectares, expect nonsense. I left it up to the template users to know what they're doing. Yes, unfortunately, this means that an editor might plug in <code>oz</code> hoping for fluid ounces but get avoirdupois instead. Then there's "PS" which the template takes to be metric horsepower as opposed to petaseimens and "S/T", mentioned by Gene, for short tons.
::The template has a bias against ... [[WP:ENGVAR|? ... American English. How is it strong? What are our options? Unless we make it such that there is no default, requiring explicit addition of the <code>sp</code> parameter either way (which would benifit nobody); the bias has to go one way or other. I cannot see how a bias against American spelling is any worse than a bias against the way the rest of us spell.
::Connect the whether the template gives "tonne(s)" or "metric ton(s)" to the spelling parameter, that could be done easily enough. It hadn't occured to me. I guess I think of "tonne(s)" and "metric ton(s)" to be completely different terms rather than simply different spellings of the same term.
::Maybe a more general discussion of whether or not the use of complicated black boxes of this sort is appropriate on Wikipedia is in order. Maybe it should find its own section. Maybe ''this'' discussion should get back to how we want to deal with expressing deadweight tonnage.
::<span title="Representation in the International Phonetic Alphabet (IPA)" class="IPA">[[User:Jimp|J]][[Special:Contributions/Jimp|ɪ]][[User talk:Jimp|m]][[wikt:User:Jimp|p]]</span> 07:47, 6 March 2008 (UTC)
::: The only difficulty with #7 is that it inhibits succinctness. "DWT" occurs over 15 times in articles like [[Bulk carrier]] and [[Oil tanker]]. (There either are or will be lists where the term will be used many, many more times.) Reading back over this thread, an approach of "define it, then use it" emerges. In [http://en.wikipedia.org/w/index.php?title=Oil_tanker&diff=196263786&oldid=196141051&theResponse=%3Conlyinclude%3E%7B%7B%23ifeq%3A%7B%7BBASEPAGENAME%7D%7D%7CPeer+review%2FOil+tanker%7C%7E%7E%7E%7E%7D%7D%3C%2Fonlyinclude%3EThe+following+suggestions+were+generated+by+a+semi-automatic+%5B%5BUser%3AAndyZ%2Fpeerreviewer%7Cjavascript+program%5D%5D%2C+and+might+not+be+applicable+for+the+article+in+question. this edit], I worked a short definition into the first use in the article: "coastal tankers of a few thousand [[long ton]]s of [[deadweight]] (DWT) to the mammoth supertankers of 650,000&nbsp;DWT." Any feelings? <span style="font-family:Bradley Hand ITC;">[[User:Haus|<font style="color:Blue;"><font size="+2">H</font>aus</font>]]<sup style="font-size : 6pt ;">[[User_talk:Haus|<font style="color:Green;">Talk</font>]]</sup></span> 11:51, 6 March 2008 (UTC)

== Prices are numbers too ==

We often don't bother to give numbers to four [[significant figures]], and, wishing to avoid pedantry and the wasting of space, I therefore changed

:''for US$19.99, £12.99 in the UK or AU$24.99 in Australia''

to

:''for US$20, £13 in the UK or AU$25 in Australia''

in [http://en.wikipedia.org/w/index.php?title=IPod_touch&diff=195011755&oldid=194903433 this edit]. Realizing that this might be controversial, I immediately announced the change on [[Talk:IPod_touch#How_I.27ve_reduced_precision|the talk page of this popular article]]. To my surprise, it got just one (unfavorable) response. What do you people think? -- [[User:Hoary|Hoary]] ([[User talk:Hoary|talk]]) 10:04, 4 March 2008 (UTC)

For some purposes exact numbers are preferable, and for others they are unnecessary. Unnecessarily reducing the accuracy of data can make it less useful to some people. In the case of prices, the difference between £12.99 and £13 is negligible; but there is no advantage in changing £12.99 to £13. If you are writing an article and you want to say £13 instead of £12.99, fine; but don't edit other people's work to make this change as you just annoy people and potentially make the data less useful.--[[User:Toddy1|Toddy1]] ([[User talk:Toddy1|talk]]) 19:19, 4 March 2008 (UTC)

:I am trying to think of when it would be necessary to quote the cents/pence/koupek... As [[WP:NOT#DIRECTORY]], we are discouraged from putting retail prices except when they are historically relevant. Use of the units after the decimal place appears to matter the most from the sales ([[price point|price pointing]]) perspective for any given product, although occasionally one may be called upon to cite a historical high or low [[share price]] or discuss the psychological impact of this type of price pointing in same, but generally the simplicity of $13 over $12.99 within wikipedia is a clear advantage, AFAICT. [[User:Ohconfucius|Ohconfucius]] ([[User talk:Ohconfucius|talk]]) 03:57, 5 March 2008 (UTC)

== The size of a thousand ==

<blockquote>[[Decimal separator#Thousands separator|Commas]] are used to break the sequence every three places left of the decimal point; spaces or dots are never used in this role (''2,900,000'', not ''2 900 000'').</blockquote>

says the manual under the heading ''[[WP:MOSNUM#Large numbers|Large numbers]]''. We ''do'' intend this to start a 1,000, don't we? I'm suggesting we tighten the language to make it clear what exactly we mean by ''large''. Are we considering numbers in the range of 10,000&nbsp;>&nbsp;''x''&nbsp;≥&nbsp;1,000 to be large here? <span title="Representation in the International Phonetic Alphabet (IPA)" class="IPA">[[User:Jimp|J]][[Special:Contributions/Jimp|ɪ]][[User talk:Jimp|m]][[wikt:User:Jimp|p]]</span> 14:36, 4 March 2008 (UTC)

== Concern: commas and dates ==

[[MOS:DATE#Dates]] (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 [[February 14]] [[2008]] ([http://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style_%28dates_and_numbers%29&diff=prev&oldid=195954809 see the linked <nowiki>[[February 14]] [[2008]]</nowiki> here], note that it does not for [[February]] [[14]] [[2008]] 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 [http://en.wikipedia.org/w/index.php?title=List_of_Star_Ocean_EX_episodes&diff=next&oldid=195749584 this revert]? 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? [[User:Sesshomaru|Lord Sesshomaru]] <small>([[User talk:Sesshomaru|talk]] • [[Special:Contributions/Sesshomaru|edits]])</small> 02:52, 5 March 2008 (UTC)
: See also [[Wikipedia_talk:Manual_of_Style_%28dates_and_numbers%29/Archive_94#Commas_in_linked_dates]]. Some people still don't realize a comma is added in <nowiki>[[February 14]] [[2008]]</nowiki> ([[February 14]] [[2008]]), and removed in <nowiki>[[14 February]], [[2008]]</nowiki> ([[14 February]], [[2008]]), even for IP editing. The revert was based on a misunderstanding. [[User_talk:Gimmetrow|''Gimmetrow'']] 03:03, 5 March 2008 (UTC)
:: So you agree that these things should be mentioned in the guideline? [[User:Sesshomaru|Lord Sesshomaru]] <small>([[User talk:Sesshomaru|talk]] • [[Special:Contributions/Sesshomaru|edits]])</small> 03:08, 5 March 2008 (UTC)
::: I can agree with saying a comma does not need to be inserted with the <nowiki>[[February 14]] [[2008]]</nowiki> format, but I'm less clear on recommending it. No comma seems to confuse editors. With <nowiki>[[14 February]], [[2008]]</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. [[User_talk:Gimmetrow|''Gimmetrow'']] 03:30, 5 March 2008 (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 [[February 14]], [[2008]], 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. [[User:Collectonian|Collectonian]] ([[User talk:Collectonian|talk]]) 03:35, 5 March 2008 (UTC)
::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 ([[User_talk:TinyMark/Archive_2#a_note_re:_dates|here]]) and still have the test in my [[User:TinyMark/sandbox|sandbox]] (if anyone's interested be sure to switch of dates preferences beforehand). [[User:TinyMark|<small>TINY</small>]][[User talk:TinyMark|<span style="color:green">MARK</span>]] 04:07, 5 March 2008 (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? [[User:Sesshomaru|Lord Sesshomaru]] <small>([[User talk:Sesshomaru|talk]] • [[Special:Contributions/Sesshomaru|edits]])</small> 04:17, 5 March 2008 (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 [http://en.wikipedia.org/w/index.php?title=Special:Whatlinkshere/January_1&limit=500&from=15640386&back=15103399 linked to] [[January 1]] alone), and the paranoïa apparently associated with it drives me nuts. [[User:Ohconfucius|Ohconfucius]] ([[User talk:Ohconfucius|talk]]) 05:15, 5 March 2008 (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. [[User:Sesshomaru|Lord Sesshomaru]] <small>([[User talk:Sesshomaru|talk]] • [[Special:Contributions/Sesshomaru|edits]])</small> 05:34, 5 March 2008 (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?
::::::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.
::::::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>"[[January 15]], [[1961]" or "[[January 15]], [[1961]"</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. [[User:Gene Nygaard|Gene Nygaard]] ([[User talk:Gene Nygaard|talk]]) 15:18, 5 March 2008 (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? [[User:Sesshomaru|Lord Sesshomaru]] <small>([[User talk:Sesshomaru|talk]] • [[Special:Contributions/Sesshomaru|edits]])</small> 16:55, 5 March 2008 (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? [[User:Gene Nygaard|Gene Nygaard]] ([[User talk:Gene Nygaard|talk]]) 17:51, 5 March 2008 (UTC)
:::::::::Edit warring? What in the world are you talking about? [[User:Sesshomaru|Lord Sesshomaru]] <small>([[User talk:Sesshomaru|talk]] • [[Special:Contributions/Sesshomaru|edits]])</small> 18:04, 5 March 2008 (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. [[User:Gene Nygaard|Gene Nygaard]] ([[User talk:Gene Nygaard|talk]]) 18:31, 5 March 2008 (UTC)
:::::::::::Compromise: how about having the guideline say something like, "''commas for the <nowiki>[[February 14]] [[2008]]</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? [[User:Sesshomaru|Lord Sesshomaru]] <small>([[User talk:Sesshomaru|talk]] • [[Special:Contributions/Sesshomaru|edits]])</small> 18:52, 5 March 2008 (UTC)
::::::::::::Okay. I'll do the compromised edit to the guideline tommorrow. Any additional comments? [[User:Sesshomaru|Lord Sesshomaru]] <small>([[User talk:Sesshomaru|talk]] • [[Special:Contributions/Sesshomaru|edits]])</small> 06:04, 8 March 2008 (UTC)
(deindent) Make sure to note that just because they are not needed is no reason to run around removing them from existing articles. [[User:Collectonian|Collectonian]] ([[User talk:Collectonian|talk]]) 21:13, 10 March 2008 (UTC)
:I think I know why you're saying this. You don't want the commas removed in pages that you heavily edited, like [[List of Star Ocean EX episodes|List of ''Star Ocean EX'' episodes]]? 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? [[User:Sesshomaru|Lord Sesshomaru]] <small>([[User talk:Sesshomaru|talk]] • [[Special:Contributions/Sesshomaru|edits]])</small> 21:28, 10 March 2008 (UTC)
::I'd have thought the reason is obvious. Do ''you'' want to see your watchlist explode ?? ;-) [[User:TinyMark|<small>TINY</small>]][[User talk:TinyMark|<span style="color:green">MARK</span>]] 21:34, 10 March 2008 (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 [[User:Collectonian|Collectonian]] ([[User talk:Collectonian|talk]]) 21:51, 10 March 2008 (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? [[User:Sesshomaru|Lord Sesshomaru]] <small>([[User talk:Sesshomaru|talk]] • [[Special:Contributions/Sesshomaru|edits]])</small> 22:10, 10 March 2008 (UTC)
:::::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, [[Wikipedia:Citing sources]] includes language regarding that:

::::::"''Any style or system is acceptable on Wikipedia 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.''"

:::::Perhaps something similar would work here? [[User:Collectonian|Collectonian]] ([[User talk:Collectonian|talk]]) 22:26, 10 March 2008 (UTC)

I guess that could work, but what about ''[[Death Note]]''? 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 [http://en.wikipedia.org/w/index.php?title=List_of_Star_Ocean_EX_episodes&diff=prev&oldid=195749584 here], one should not [http://en.wikipedia.org/w/index.php?title=List_of_Star_Ocean_EX_episodes&diff=next&oldid=195749584 revert blindly] or undo only the removal of the commas, as that seems to be a case of [[Wikipedia:Ownership]]. So can we integrate what I just said into the guideline as well? [[User:Sesshomaru|Lord Sesshomaru]] <small>([[User talk:Sesshomaru|talk]] • [[Special:Contributions/Sesshomaru|edits]])</small> 22:37, 10 March 2008 (UTC)

: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. [[User:Collectonian|Collectonian]] ([[User talk:Collectonian|talk]]) 01:09, 11 March 2008 (UTC)

::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? [[User:Sesshomaru|Lord Sesshomaru]] <small>([[User talk:Sesshomaru|talk]] • [[Special:Contributions/Sesshomaru|edits]])</small> 01:18, 11 March 2008 (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.''" [[User:Collectonian|Collectonian]] ([[User talk:Collectonian|talk]]) 20:02, 11 March 2008 (UTC)

::::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? [[User:Sesshomaru|Lord Sesshomaru]] <small>([[User talk:Sesshomaru|talk]] • [[Special:Contributions/Sesshomaru|edits]])</small> 20:08, 11 March 2008 (UTC)

:::::The page is currently edit protected, so before I put in an editprotected request, does anyone else want to comment on this? [[User:Collectonian|Collectonian]] ([[User talk:Collectonian|talk]]) 04:04, 12 March 2008 (UTC)

::::::Go for it. Seems we have concluded. [[User:Sesshomaru|Lord Sesshomaru]] <small>([[User talk:Sesshomaru|talk]] • [[Special:Contributions/Sesshomaru|edits]])</small> 20:09, 12 March 2008 (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.[[User:Collectonian|Collectonian]] ([[User talk:Collectonian|talk]]) 17:57, 13 March 2008 (UTC)

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 [[1777]]"</nowiki>, I can simply change it to <nowiki>"happened on [[14 September]] [[1777]]"</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:
*get out of edit mode on that section.
*view or edit the entire article, examining it to see if there are any dates in either of 2 formats, <nowiki>[[July 4]], [[1776]] or [[July 4]] [[1776]]</nowiki>.
*if there are none, pick one format and use it for the mess I found.
*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.

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>[[July 4]], [[1776]] or [[4 July]] [[1776]]</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 Wikipedia. I will remove that recommendation from the guideline. An agreement between two editors doesn't constitute much of a consensus. [[User:Chris the speller|Chris the speller]] ([[User talk:Chris the speller|talk]]) 18:19, 19 March 2008 (UTC)

:No one is saying anything about adding a 3rd format. The article already says you can use <nowiki>[[July 4]], [[1776]] or [[July 4]] [[1776]]</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. [[User:Collectonian|Collectonian]] ([[User talk:Collectonian|talk]]) 18:35, 19 March 2008 (UTC)

::Your statement is completely incorrect. Nowhere does the guideline say that <nowiki>[[July 4]] [[1776]]</nowiki> is an acceptable format. Please remove that paragraph or allow me to remove it again. [[User:Chris the speller|Chris the speller]] ([[User talk:Chris the speller|talk]]) 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? [[User:Collectonian|Collectonian]] ([[User talk:Collectonian|talk]]) 20:46, 19 March 2008 (UTC)

::::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>"[[May 15]] [[2005]]"</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 Wikipedia 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. [[User:Chris the speller|Chris the speller]] ([[User talk:Chris the speller|talk]]) 21:55, 19 March 2008 (UTC)

:::::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. [[User:Collectonian|Collectonian]] ([[User talk:Collectonian|talk]]) 22:22, 19 March 2008 (UTC)

::::::What do you think of the green checks and red X's that were in the table [http://en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style_%28dates_and_numbers%29&oldid=189990499 here]? Never mind that the legend below it is inaccurate in this version. Would something like this work to show what formats are acceptable? [[User:Chris the speller|Chris the speller]] ([[User talk:Chris the speller|talk]]) 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. [[User:Collectonian|Collectonian]] ([[User talk:Collectonian|talk]]) 01:23, 20 March 2008 (UTC)

== Whose turf? ==

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 [[Wikipedia talk:Manual of Style#Lack of jurisdiction]], 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. [[User:Gene Nygaard|Gene Nygaard]] ([[User talk:Gene Nygaard|talk]]) 16:23, 6 March 2008 (UTC)

: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 [[WP:MOS]] page, but on this [[WP:MOSNUM]] page as well, without ever having discussed it here. [[User:Gene Nygaard|Gene Nygaard]] ([[User talk:Gene Nygaard|talk]]) 16:59, 6 March 2008 (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. [[User:Sambc|SamBC]]([[User talk:Sambc|talk]]) 17:46, 6 March 2008 (UTC)

:Yes the subject needs to be talked about here before changes are made to the page. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 12:21, 7 March 2008 (UTC)

::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. [[User:Sambc|SamBC]]([[User talk:Sambc|talk]]) 12:53, 7 March 2008 (UTC)

:::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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 13:06, 7 March 2008 (UTC)

::::Furthermore, it the edits by [[User:Centrx]] which were reverted here were themselves a reversion of an earlier undiscussed change of the longstanding "ten" to "nine" by [[User:Tony1]]. [[User:Gene Nygaard|Gene Nygaard]] ([[User talk:Gene Nygaard|talk]]) 17:50, 7 March 2008 (UTC)

Talk of "jurisdiction" is off-topic wikilawyering; content is at both places, discussion was there, consensus was there, broader readership and input is there. [[User:SandyGeorgia|Sandy<font color="green">Georgia</font>]] ([[User talk:SandyGeorgia|Talk]]) 12:39, 14 March 2008 (UTC)

== Misleading and difficult to parse advice about dates ==

The guidance says:
*''Full dates, and days and months, are normally autoformatted by inserting double square-brackets, as for linking.''

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. [[User:Lightmouse|Lightmouse]] ([[User talk:Lightmouse|talk]]) 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 [[2 April]]; 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). [[User:Pmanderson|Septentrionalis]] <small>[[User talk:Pmanderson|PMAnderson]]</small> 16:16, 8 March 2008 (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?

::In addition, we probably need a full time bot to tackle these fragments that sometimes are merely annoying and sometimes actually break autoformatting. [[User:Lightmouse|Lightmouse]] ([[User talk:Lightmouse|talk]]) 21:38, 11 March 2008 (UTC)

:::Does anybody have any suggested wording? [[User:Lightmouse|Lightmouse]] ([[User talk:Lightmouse|talk]]) 09:29, 13 March 2008 (UTC)

::::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. [[User:Woody|Woody]] ([[User talk:Woody|talk]]) 13:52, 13 March 2008 (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. [[User:Lightmouse|Lightmouse]] ([[User talk:Lightmouse|talk]]) 13:55, 13 March 2008 (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. [[User:Woody|Woody]] ([[User talk:Woody|talk]]) 14:04, 13 March 2008 (UTC)

:::::::I take your point, it is well made. Sorry about that. [[User:Lightmouse|Lightmouse]] ([[User talk:Lightmouse|talk]]) 14:11, 13 March 2008 (UTC)

== the terabyte has become a unit of bandwidth ==

It seems that the [[terabyte]] is now a unit of bandwidth. Comments on the [[Talk:Terabyte#the_terabyte_is_not_a_unit_of_bandwidth|talk page]] are invited. [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 09:41, 7 March 2008 (UTC)

== Uncertainty vs. repeating decimal ==

I have just edited the [[Conversion of units]] 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.

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}}.
--[[User:Gerry Ashton|Gerry Ashton]] ([[User talk:Gerry Ashton|talk]]) 19:22, 8 March 2008 (UTC)

: Good point. [http://physics.nist.gov/cuu/Uncertainty/examples.html This] looks like sensible advice to me. [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 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. [[User:Pmanderson|Septentrionalis]] <small>[[User talk:Pmanderson|PMAnderson]]</small> 21:40, 8 March 2008 (UTC)
::: [http://www.bipm.org/en/si/si_brochure/chapter5/5-3-2.html#5-3-5 BIPM] 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? [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 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. [[User:Tony1|<font color="darkgreen">'''Tony'''</font >]] [[User_talk:Tony1|<font color="darkgreen">(talk)</font >]] 00:51, 9 March 2008 (UTC)
**Disputed, as invisible nonsense. [[User:Pmanderson|Septentrionalis]] <small>[[User talk:Pmanderson|PMAnderson]]</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? --[[User:Gerry Ashton|Gerry Ashton]] ([[User talk:Gerry Ashton|talk]]) 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. [[User:Pmanderson|Septentrionalis]] <small>[[User talk:Pmanderson|PMAnderson]]</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. [[User:Pmanderson|Septentrionalis]] <small>[[User talk:Pmanderson|PMAnderson]]</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. --[[User:Gerry Ashton|Gerry Ashton]] ([[User talk:Gerry Ashton|talk]]) 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̄
— [[User:Crissov|Christoph]] [[User talk:Crissov|Päper]] 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. --[[User:Gerry Ashton|Gerry Ashton]] ([[User talk:Gerry Ashton|talk]]) 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 [[ISO 8859-1|very safe]]. One could also imagine using brackets or braces instead of parentheses: 0.1[37] or 0.1{37}, but I think this would be a WP-specific convention, which we try to avoid. — [[User:Crissov|Christoph]] [[User talk:Crissov|Päper]] 09:09, 14 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, [[User:Chebyshev|Chebyshev]] ([[User talk:Chebyshev|talk]]) 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 Wikipedia.
: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>'''[[User_talk:Noetica |⊥]]'''</big></big></sub><sup>¡ɐɔıʇǝo</sup>N<small>oetica!</small></font><sup>[[User_talk:Noetica |T]]</sup>– 05:36, 12 March 2008 (UTC)
::Thanks a lot for your help [[User:Chebyshev|Chebyshev]] ([[User talk:Chebyshev|talk]]) 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 [[Wikipedia:Line break handling]].

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

--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|talk]]) 22:36, 12 March 2008 (UTC)

:Since no one protested I boldly went ahead and added "''See also: [[Wikipedia:Line break handling]] and [[Wikipedia:Manual of Style#Non-breaking spaces]]''" to the top of the "Non-breaking spaces" section.
:--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|talk]]) 15:35, 13 March 2008 (UTC)

Why was this raised on this page rather than at [[WP:MOS]], which gets broader attention? [[User:SandyGeorgia|Sandy<font color="green">Georgia</font>]] ([[User talk:SandyGeorgia|Talk]]) 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 [[Wikipedia:Manual of Style (dates and numbers)]] = "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, [[WP:MOS]] also has such a section so I asked the exact same thing there. So I did raise the question on both affected pages. :))
:--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|talk]]) 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. [[User:Lightmouse|Lightmouse]] ([[User talk:Lightmouse|talk]]) 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 [[WP:MOS]]. 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 [[WP:MOS]], 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>'''[[User_talk:Noetica |⊥]]'''</big></big></sub><sup>¡ɐɔıʇǝo</sup>N<small>oetica!</small></font><sup>[[User_talk:Noetica |T]]</sup>– 09:58, 13 March 2008 (UTC)

::That would not surprise me at all. What surprises me is the edit block. [[User:Lightmouse|Lightmouse]] ([[User talk:Lightmouse|talk]]) 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>'''[[User_talk:Noetica |⊥]]'''</big></big></sub><sup>¡ɐɔıʇǝo</sup>N<small>oetica!</small></font><sup>[[User_talk:Noetica |T]]</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. [[User:Tony1|<font color="darkgreen">'''Tony'''</font >]] [[User_talk:Tony1|<font color="darkgreen">(talk)</font >]] 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 [[WT:MOS]], otherwise I won't hesitate to protect this again. [[User:Woody|Woody]] ([[User talk:Woody|talk]]) 12:31, 13 March 2008 (UTC)
::::::Thanks Woody. In fact, the issue has been discussed extensively at [[WT:MOS]] 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>'''[[User_talk:Noetica |⊥]]'''</big></big></sub><sup>¡ɐɔıʇǝo</sup>N<small>oetica!</small></font><sup>[[User_talk:Noetica |T]]</sup>– 10:08, 14 March 2008 (UTC)

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

[[Wikipedia talk:Manual of Style (dates and numbers)/Archive 78]] 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? [[User:LeadSongDog|LeadSongDog]] ([[User talk:LeadSongDog|talk]]) 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... ''[[User:Verisimilus|Verisimilus]]''&nbsp;'''<small>[[User_talk:Verisimilus|T]]</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. [[User:Tony1|<font color="darkgreen">'''Tony'''</font >]] [[User_talk:Tony1|<font color="darkgreen">(talk)</font >]] 08:47, 14 March 2008 (UTC)

The present text reads {{cquote|:*Abbreviations indicating long periods of time ago—such as ''[[before present|BP]]'' (before present), as well as various [[annum]]-based units such as Ka (kiloannum) and kya (thousand years ago), Ma (megaannum) and [[mya (unit)|mya]] (million years ago), and [[Annum|Ga]] (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|BP]]'' (before present), as well as various [[annum]]-based units such as Ka (kiloannum), Ma (megaannum)and [[Annum|Ga]] (gigaannum or billion years ago) are given as full words and wikilinked on first occurrence. Where older source quotations use the now-deprecated abbreviations [[kya]] (thousand years ago), [[mya (unit)|mya]] (million years ago), or [[bya]] (billion years ago) this should be explained to the reader as in ''"a measured Libby radiocarbon date of 35.1&nbsp;[[annum|mya]]" (million years ago, 35.1&nbsp;[[annum|Ma]] in modern usage) had to be calibrated against then newly available [[stratigraphic]] dating references in order to estimate a Cambridge standardized date of 30.2&nbsp;[[Ma]] [[BP]].''
::*'''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-01-01]]", 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? [[User:LeadSongDog|LeadSongDog]] ([[User talk:LeadSongDog|talk]]) 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? ''[[User:Verisimilus|Verisimilus]]''&nbsp;'''<small>[[User_talk:Verisimilus|T]]</small>''' 18:18, 14 March 2008 (UTC)
::Fair enough. I had them each wikilinked to [[annum]] anyhow, the one time should be enough.[[User:LeadSongDog|LeadSongDog]] ([[User talk:LeadSongDog|talk]]) 19:53, 14 March 2008 (UTC)

Now we have {{cquote|:*Abbreviations indicating long periods of time ago—such as ''[[before present|BP]]'' (before present), as well as various [[annum]]-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 [[kya]] (thousand years ago), [[mya (unit)|mya]] (million years ago), or [[bya]] (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 [[stratigraphic]] dating references in order to estimate a Cambridge standardized date of 30.2&nbsp;ka [[BP]] 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 [[1950-01-01]]", 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.[[User:LeadSongDog|LeadSongDog]] ([[User talk:LeadSongDog|talk]]) 18:10, 17 March 2008 (UTC)

:''emend'': strike "and wikilinked"; RC only gd 4 ¬50000a. --''[[User:Verisimilus|Verisimilus]]''&nbsp;'''<small>[[User_talk:Verisimilus|T]]</small>''' 19:56, 17 March 2008 (UTC)<sup>(no kb!)</sup>
::How on earth did I miss that??? Good catch![[User:LeadSongDog|LeadSongDog]] ([[User talk:LeadSongDog|talk]]) 21:56, 17 March 2008 (UTC)
{{checkmark}} Done. [[User:LeadSongDog|LeadSongDog]] ([[User talk:LeadSongDog|talk]]) 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, [[User talk:Zocky|Zocky]] visited ''[[Kilogram]]'' 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, [[:Template:Delimitnum|<nowiki>{{delimitnum}}</nowiki>]], 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 [[Wikipedia_talk:Manual_of_Style_%28dates_and_numbers%29/Archive_94#Grouping_of_digits_after_the_decimal_point_.28next_attempt.29|here at Archive&nbsp;#94 of Talk:MOSNUM]]. 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 ''[[Natural logarithm]]'' article (first paragraph) and ''[[Kilogram]]'' (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 [[Help:Template|template]] and really required a [[Help:Parser function|parser function]] ([[Help:Magic words|magic word]]). 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 [[User:Greg_L#Delimitnum_sandbox|here on my talk page]] 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 [[Wikipedia:MOSNUM#Large_numbers|current MOSNUM policy]], 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 [[full stop]] (.), e.g. <b>1,234.567</b>. Further now, the use of the [[:Template:Delimitnum|<nowiki>{{delimitnum}}</nowiki>]] [[Help:Template|template]]/[[Help:Parser function|parser function]] ([[Help:Magic words|magic word]]) is “encouraged” and is the “preferred” method for delimiting numeric strings with five or more digits in the fractional portion of the [[significand]] (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 [[Microsoft Excel|Excel]]-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 [[non-breaking space]]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 [[word wrap]]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:E|<nowiki>{{e}}</nowiki>]] 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 [[non-breaking space]]s, 2) use of the [[:Template:Nowrap|<nowiki>{{nowrap}}</nowiki>]] template, or 3) use of [[:Template:Delimitnum|<nowiki>{{delimitnum}}</nowiki>]]—''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 [[Font size]], 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.

[[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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;[[User:Woodstone|Woodstone]] ([[User talk:Woodstone|talk]]) 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}}
:: [[User_talk:Gimmetrow|''Gimmetrow'']] 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 ''[[Kilogram]]'' is likely very representative of the kind of article that will be using this and has encountered no difficulties. [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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). [[User_talk:Gimmetrow|''Gimmetrow'']] 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 [[Kilogram]], it worked great there. I don’t know whether to pull this proposal. Please see [[User:Greg_L#Delimitnum_sandbox|this sandbox]], which really exersized the template (I think). [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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 [[Kilogram]] 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 [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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>

:[[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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)

[[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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. [[User_talk:Gimmetrow|''Gimmetrow'']] 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 [[User:Greg_L#Progressions_of_features_and_digits:|Progressions of features and digits]]. 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. [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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. [[User_talk:Gimmetrow|''Gimmetrow'']] 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. [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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;[[User:Woodstone|Woodstone]] ([[User talk:Woodstone|talk]]) 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. [[User talk:Zocky|Zocky]] | [[User:Zocky/Picture Popups|picture popups]] 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? [[User talk:Zocky|Zocky]] | [[User:Zocky/Picture Popups|picture popups]] 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;[[User:Woodstone|Woodstone]] ([[User talk:Woodstone|talk]]) 17:22, 15 March 2008 (UTC)

:''(unindented)''

* All: I created an all new section of [[User:Greg_L#Delimitnum_sandbox|Delimitnum sandbox]] with all [[User:Greg_L#3960-count_progression|3960 possible variations]] of <u>[[User:Greg_L#TWO-DIGIT_GROUPS_FOLLOWING_ALL_TEN_POSSIBLE_DIGITS_.2810_.C3.97_100.29|two]]</u>, [[User:Greg_L#THREE-DIGIT_GROUPS_.281_.C3.97_1000.29.3D|three]], and [[User:Greg_L#FOUR-DIGIT_GROUPS_.281_.C3.97_1000.29|four-digit]] 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>. [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 20:10, 15 March 2008 (UTC)<br><br>

* That was fast. All those have apparently been fixed. Please now search [[User:Greg_L#3960-count_progression|here]] 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><!--

-->[[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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;[[User:Woodstone|Woodstone]] ([[User talk:Woodstone|talk]]) 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). [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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. [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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 [[User:Greg_L#Delimitnum_sandbox|Delimitnum sandbox]] in the newly added section with [[User:Greg_L#3960-count_progression|3960 possible variations]], which displays all possible variations of numbers ending in [[User:Greg_L#TWO-DIGIT_GROUPS_FOLLOWING_ALL_TEN_POSSIBLE_DIGITS_.2810_.C3.97_100.29|two]], [[User:Greg_L#THREE-DIGIT_GROUPS_.281_.C3.97_1000.29.3D|three]], and [[User:Greg_L#FOUR-DIGIT_GROUPS_.281_.C3.97_1000.29|four-digit]] groupings.<p><!--

-->[[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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). [[User:Tony1|<font color="darkgreen">'''Tony'''</font >]] [[User_talk:Tony1|<font color="darkgreen">(talk)</font >]] 02:08, 16 March 2008 (UTC)

:Thanks Tony. I’m not trying to be difficult, but what plus sign? [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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;[[User:Woodstone|Woodstone]] ([[User talk:Woodstone|talk]]) 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 [[Help:Parser function|parser function]]-based [[Help:Magic words|magic word]] 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 [sic] 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 [http://physics.nist.gov/cgi-bin/cuu/Convert?exp=0&num=1&From=kg&To=hz&Action=Convert+value+and+show+factor NIST:Fundamental Physical Constants] and [http://www.bipm.org/en/si/si_brochure/chapter3/prefixes.html SI&nbsp;Brochure, Section 3.1]). As you can see, both default to omitting the utterly unnecessary + sign in front of positive base-ten exponents. This reality is acknowledged in Wikipedia’s own ''[[Scientific notation]]'' and ''[[SI_Prefixes#List_of_SI_prefixes|SI Prefixes]]'' articles as well as the [[:Template:SI multiples|<nowiki>{{SI multiples}}</nowiki>]] and [[:Template:E|<nowiki>{{e}}</nowiki>]] 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 [http://www.bipm.org/en/si/si_brochure/chapter5/5-3-2.html#5-3-5 SI&nbsp;Brochure: 5.3.5] 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||[[Tick|useless]] “[[Redundancy (engineering)|+]]” [[Braille|sign]] 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 Wikipedia 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 [[Wikipedia_talk:Manual_of_Style_%28dates_and_numbers%29/Archive_94#Grouping_of_digits_after_the_decimal_point_.28next_attempt.29|Archive&nbsp;#94 of Talk:MOSNUM]] 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. [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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;[[User:Woodstone|Woodstone]] ([[User talk:Woodstone|talk]]) 10:49, 18 March 2008 (UTC)

===Sandbox moved===
All: I moved the proof-checking sandbox to [[User:Greg L/Delimitnum sandbox]]. [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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;[[User:Woodstone|Woodstone]] ([[User talk:Woodstone|talk]]) 09:27, 19 March 2008 (UTC)

== Trials and disambiguations ==

Opinions are invited on how best to disambiguate the megabyte at [[DEC 3000 AXP]]. I would like to avoid an unnecessary strand, so please reply directly on the [[Talk:DEC_3000_AXP|talk page]] and not here. Thanks. [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 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 Wikipedia 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 [[kibibyte|KiB]]). 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 [[kibibyte|KiB]])" to "Use of IEC prefixes is equally acceptable for disambiguation (256 [[kibibyte|KiB]])". [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 09:54, 18 March 2008 (UTC)

:I second Fnagton. Wikipedia 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. --[[User:Wgungfu|Marty Goldberg]] ([[User talk:Wgungfu|talk]]) 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 [http://en.wikipedia.org/w/index.php?title=Wikipedia%3AManual_of_Style_%28dates_and_numbers%29&diff=187000997&oldid=186232283 this edit], citing a [[Wikipedia_talk:Manual_of_Style_%28dates_and_numbers%29#General_IT_prefix_discussion|talk page discussion]] 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 [http://en.wikipedia.org/w/index.php?title=Wikipedia%3AManual_of_Style_%28dates_and_numbers%29&diff=187012885&oldid=187000997 reinstating an explicit statement] 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. [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 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) [[User:Tom94022|Tom94022]] ([[User talk:Tom94022|talk]]) 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 Wikipedia 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 17:51, 18 March 2008 (UTC)

* Thunderbird’s proposal to disambiguate by means of a footnote ([http://en.wikipedia.org/w/index.php?title=Talk%3ADEC_3000_AXP&diff=199058946&oldid=198722522 ∆ here]) 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. Wikipedia, 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 [http://www.flightsim.com/review/cfs3-1/spitfire_in_storm3.jpg not do well at all.] When that happens, early adopters find themselves out in the snow all by themselves, waving the [[Esparanto]] 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 Wikipedia. [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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. [[User:Tom94022|Tom94022]] ([[User talk:Tom94022|talk]]) 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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? [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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" ([[Binary prefix|MiB]]) where disambiguation is necessary. [[User:Tom94022|Tom94022]] ([[User talk:Tom94022|talk]]) 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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. — [[User:Crissov|Christoph]] [[User talk:Crissov|Päper]] 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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. — [[User:Aluvus|<font style="background: #3371A3" color="#FFFFFF">Aluvus</font>]] [[User talk:Aluvus|t]]/[[Special:contributions/Aluvus|c]] 01:57, 19 March 2008 (UTC)

::::::: "''You haven't provided any actual examples of such occurences''" - Yes I [http://en.wikipedia.org/w/index.php?title=Talk:Binary_prefix&diff=prev&oldid=190479947 have], 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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 Wikipedia 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 Wikipedia is a poor practice that has been measured at 2.6&nbsp;[[Mental confusion|Mc]]. It should therefore be avoided in my opinion. [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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. [[Not invented here]] 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.[[User:LeadSongDog|LeadSongDog]] ([[User talk:LeadSongDog|talk]]) 05:05, 19 March 2008 (UTC)

:Well that's a silly thing to write since Wikipedia does not blindly follow the standards organisations and instead usually makes the wise choice that it follows the real world consensus. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 10:52, 19 March 2008 (UTC)
::I'll assume that was intended as [[WP:CIVIL|civil]] and move on. The above discussion can hardly be construed as "blindly follow[ing]" the standard: it is a reasonable, informed debate. It is not, however, remotely close to the years of discussion that go into crafting an [[open standard]]. Having worked as editor on a number of other [[IEEE]] 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? [[User:LeadSongDog|LeadSongDog]] ([[User talk:LeadSongDog|talk]]) 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 Wikipedia goes against what Wikipedia 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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 [[not invented here]]. 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?[[User:LeadSongDog|LeadSongDog]] ([[User talk:LeadSongDog|talk]]) 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 Wikipedia 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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. [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 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 [[Wikipedia:Reliable sources]]. The majority of reliable sources relevant to the articles in Wikipedia use the terms kilobyte/megabyte/gigabyte/KB/MB/GB in the binary sense when they are talking about powers of two numbers. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 19:17, 19 March 2008 (UTC)

* It seems that there are some new editors weighing in here who may not have participated in—or read—where this started on [[Talk:DEC_3000_AXP]]. 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 [[International Union of Pure and Applied Physics]] once proposed that expressions like “ppm” (parts per million) be replaced with a new unit called the [[Parts_per_notation#The_uno|uno]]. Notwithstanding that it was arguably a ''great'' idea, in 2004, a report to the [[International Committee for Weights and Measures]] (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 Wikipedia 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. Wikipedia can’t be be using future-talk (why not “kilocochranes”) just because “it’s a good idea” when hardly anyone except a few Wikipedia authors and people who helped write the damned proposal know what it means. Wikipedia authors can’t start thinking of themselves as coming from the United Federation of Planets who will use Wikipedia as a venue to take every good idea from the future and turn it into a standard that it clearly isn’t. Wikipedia 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 Wikipedia, 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 Wikipedia: 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 Wikipedia and other encyclopedias might ''explain'' these terms in an article like [[Byte]], 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 Wikipedia. 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 [[Wikipedia:Manual_of_Style_%28dates_and_numbers%29#Which_system_to_use|#Which&nbsp;system&nbsp;to&nbsp;use]] that clearly can be of some utility in concluding this debate. It reads:

{{cquote|In scientific articles, use the units employed in the current [[scientific literature]] on that topic. This will usually be [[SI]], but not always; for example, [[natural units]] are often used in relativistic and quantum physics, and [[Hubble's constant|Hubble's constant]] should be quoted in its most common unit of ([[Kilometre|km]]/[[Second|s]])/[[Megaparsec|Mpc]] 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. [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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? [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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. [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 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. [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 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. Wikipedia 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. [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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 Wikipedia 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 Wikipedia must not enforce "equal weight" for those prefixes either. Otherwise it is like Wikipedia having "affirmitive action" to help support the minority prefixes, which is not going to be tollerated. It is not the job of Wikipedia to support failing standards. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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 [http://en.wikipedia.org/w/index.php?title=Wikipedia:Manual_of_Style_%28dates_and_numbers%29&diff=prev&oldid=187000997 comment] clearly [http://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Manual_of_Style_%28dates_and_numbers%29&diff=185243554&oldid=185239968 links] 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 [http://en.wikipedia.org/w/index.php?title=User_talk:Thunderbird2&diff=prev&oldid=187014358 page]. So you do know it was discussed because I told you so I demand that you retract what you wrote. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 19:56, 19 March 2008 (UTC)

:: I don't recall saying there had been no discussion. [[Wikipedia_talk:Manual_of_Style_%28dates_and_numbers%29#General_IT_prefix_discussion|The 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. [[User:Thunderbird2|Thunderbird2]] ([[User talk:Thunderbird2|talk]]) 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 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 Wikipedia, 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''. --[[User:Gerry Ashton|Gerry Ashton]] ([[User talk:Gerry Ashton|talk]]) 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. '''[[User:Fnagaton|Fnag]][[User talk:Fnagaton|aton]]''' 00:28, 20 March 2008 (UTC)

::::::Fortunately [[WP:MOSNUM#Times|this guideline]] already rules out 12 am and 12 pm; [[NIST]] agrees, saying that [http://tf.nist.gov/general/misc.htm "the terms 12 a.m. and 12 p.m. are wrong and should not be used."] --[[User:Gerry Ashton|Gerry Ashton]] ([[User talk:Gerry Ashton|talk]]) 04:25, 20 March 2008 (UTC)

:* Noted. Let’s move on. [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 19:59, 19 March 2008 (UTC)

:* It was my fault for misinterpreting what you wrote T-bird. [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 23:00, 19 March 2008 (UTC)

* Why is this complex? Wikipedia 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. [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 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. ;-). [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 20:05, 19 March 2008 (UTC)

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

* Fnagaton, if you are interested in resolving this issue across all of Wikipedia’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 Wikipedia. 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 ([[Wikipedia:Manual_of_Style_%28dates_and_numbers%29#Which_system_to_use|#Which&nbsp;system&nbsp;to&nbsp;use]]), 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. [[User:Greg L|Greg L]] (''[[User_talk:Greg_L|my talk]])'' 05:40, 20 March 2008 (UTC)

Latest revision as of 06:11, 24 May 2024

WikiProject iconManual of Style
WikiProject iconThis page falls within the scope of the Wikipedia: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.
Note icon
This page falls under the contentious topics procedure and is given additional attention, as it closely associated to the English Wikipedia 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 Wikipedia'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 Wikipedia policies of Wikipedia's policy and guideline documents is available, offering valuable insights and recommendations.

Revisions to MOS:SEASON[edit]

@Premeditated Chaos, Gog the Mild, Mike Christie, SchroCat, and FrB.TG: I've made several changes to MOS:SEASON following our discussion on Wikipedia:Featured article candidates/Oyster dress/archive1. Hopefully the revised guideline is clearer, but please do feel free to edit further. Also thanks to @Gawaon for helping clean up the text. Edge3 (talk) 19:37, 2 March 2024 (UTC)[reply]

I think the guidance for magazine issues could be clearer. For example, this is the Summer 2012 issue of Startling Stories; it would go against usage in reliable sources not to capitalize that. Can we restore the Quarterly Review example? On the other hand, if you're simply talking about an issue that came out in the (northern hemisphere) summer of 2012, there's no reason to say "summer 2015 issue" as you now have it; it would usually be better to say "mid-2015" instead. Mike Christie (talk - contribs - library) 20:24, 2 March 2024 (UTC)[reply]
I removed Quarterly Review because it hasn't been published since 1967, so "Summer 2015" is factually incorrect. I suppose you could change it to a historically correct example, such as "Summer 1966". But going to the crux of our issue, Amazon really isn't a reliable source because the product description page was written by the publisher of Startling Stories, so it's not independent. MOS:CAPS looks at usage in "independent, reliable sources" (emphasis added). Edge3 (talk) 20:33, 2 March 2024 (UTC)[reply]
See this archived discussion for numerous examples from reliable sources, and in particular see NebY's comment at the end. The few counter-examples given look to me like cases where the writer was not referring to an issue titled that way, so I'm not even sure all of them are counter-examples. Mike Christie (talk - contribs - library) 20:37, 2 March 2024 (UTC)[reply]
Oh interesting! I didn't realize you had previously brought up this issue in 2022. Thanks for sharing it now.
I think we're always going to find cases where one publication uses capital letters, and others use lower case. For example, Stanford Social Innovation Review refers to its own "summer 2015 issue" (lower case) in running text, even when the issue is titled "Summer 2015". Edge3 (talk) 20:57, 2 March 2024 (UTC)[reply]
Yes, there are certainly exceptions, but there was a strong preponderance of evidence in those examples -- unanimity for genre examples, and majority for others. Given that the previous discussion was closed with a consensus to retain the capital letters for magazine seasonal issues, would you mind reverting that part of your changes while this discussion continues? I think, given the previous discussion, we'd need to demonstrate a new consensus before we could make the change you've made. Mike Christie (talk - contribs - library) 21:10, 2 March 2024 (UTC)[reply]
I'd be happy to, but my concern about the historical inaccuracy of "Quarterly Review, Summer 2015" still applies. Do you have a specific example that you like better than that? Edge3 (talk) 21:18, 2 March 2024 (UTC)[reply]
How about one of the first two given in that earlier discussion? Either "Spring 1942, Tales of Wonder" or "Science Fiction Quarterly, Summer 1942" depending on whether you prefer an example with the date before the title or vice versa. Mike Christie (talk - contribs - library) 21:31, 2 March 2024 (UTC)[reply]
Mostly these examples seem to be treated as titles, meaning that the usual rules of title case are applied, and so every major word is capitalized. No surprise here. Only the "summer 2015 issue" example mentioned by Edge3 is not title-cased, hence no capital letters. It would be odd to talk about "the Summer 2015 Issue of Whatever Magazine" or "the Summer 2015 issue of Whatever Magazine". No, this is running text and so lowercase letters are called for: "the summer 2015 issue of Whatever Magazine". But when the issue date is mentioned as part of the title, title case is fine: "Whatever Magazine, Summer 2015". Gawaon (talk) 21:54, 2 March 2024 (UTC)[reply]
I agree. Perhaps two examples, so that those cases can be distinguished? Mike Christie (talk - contribs - library) 22:00, 2 March 2024 (UTC)[reply]
I've added the examples per both of your comments. Feel free to revise further. Edge3 (talk) 22:07, 2 March 2024 (UTC)[reply]
Actually, looking back at the list of examples from the 2022 discussion, it seems many of the running text examples also use upper case, so I'm not sure I fully agree with that part. My main concern was that we keep an example using title case as that's helpful when (as has happened to me) someone contests that. Personally I think it would be OK to have "the Fall 1943 issue of Thrilling Wonder Stories" which is certainly supported by reliable sources, and if you truly mean "the issue that came out that summer" that in itself is a violation of SEASON and should be rephrased. But let's wait and see what others think. Mike Christie (talk - contribs - library) 22:15, 2 March 2024 (UTC)[reply]

After reviewing some more examples I've removed the "running text" part. It doesn't correspond to the usage in the sources I have. I'm aware that we don't always comply with the usage in other sources, but I think we need more of a consensus to vary from that usage than we have here. Mike Christie (talk - contribs - library) 01:44, 3 April 2024 (UTC)[reply]

I believe the exception makes sense and have reverted your proposed change. Dondervogel 2 (talk) 09:00, 3 April 2024 (UTC)[reply]

idea to help prevent disruptive invocation of WP:ERA[edit]

As written, it is quite easy for editors to misuse this policy to disrupt an article in which they have no interest beyond the imposition of their preferred era style. I see that this policy has been debated ad nauseam in the past, and that this problem might not be as easy to fix as I had initially assumed. Nevertheless, I have a proposal. The sentence at issue is the following:

An article's established era style should not be changed without reasons specific to its content; seek consensus on the talk page first (applying Wikipedia:Manual of Style § Retaining existing styles) by opening a discussion under a heading using the word era, and briefly stating why the style should be changed.

The problem, as I see it, is that it is entirely unclear what constitutes reasons specific to its content. None of the previous proposals for clarification seemed to go anywhere in past discussions, which I am sure no one wants to revisit. But what if, instead of seeking a positive characterization, we modified the language to instead include a negative prohibition. I have in mind something along the lines of the following:

Reasons that contradict the earlier policy language stating that The default calendar eras are Anno Domini (BC and AD) and Common Era (BCE and CE). Either convention may be appropriate for use in Wikipedia articles depending on the article context. are to be disregarded in article talk space discussion. It is a violation of WP:SPURIOUSPROTECT to invoke a policy only to litigate against that very policy. Consensus as to what constitutes relevant article context must be established with reasons specific to the subject matter of the article itself.

My hope is that this, or something like it, would reduce the number of disruptive interventions by editors not actually there to improve the article under discussion. It would, at minimum, make it much more difficult for editors (whether involved in the development of the article or not) to effectively shut down discussion with a wall of irrelevant considerations likely recycled from previous such debates.

Thoughts, suggestions, criticisms all most welcome! My goal here is just to limit disruptive editing. (The best solution, of course, would be for the MOS to just pick one or the other of these interchangeable styles. But apparently we can't have nice things.)

Cheers, Patrick J. Welsh (talk) 16:38, 23 March 2024 (UTC)[reply]

Do you have examples of this disruptive editing you speak of, by editors who have actually read the guideline? --Trovatore (talk) 16:59, 23 March 2024 (UTC)[reply]
Hi @Trovatore,
Yes I do, and I notified them on their talk page, detailing my objections to their editing practice, and offering a chance to provide a more sympathetic account. This was more than two weeks ago, however, and they have not responded or made any other edits since. Anyone who wants can find this through my edit history, but I would prefer to keep this discussion at the policy level. If it goes nowhere, I will consider ANI (it's not their first offense), but I'd much rather just amend the language here to help prevent it from happening again by clarifying the language of the policy. Pursuing sanctions on a case by case basis just eats up more of everyone's time.
To the second part of your question: yes, and this is the problem. I changed BC to BCE throughout an article (two, actually). I thought this was just a copy edit, and I explicitly described what I was doing in my edit description. According to WP:ERA, however, anyone can come in at any time in the future and change it back – with no content-specific justification – unless there was first a talk page consensus established under the heading "era". Since hardly anyone is familiar with the policy, this empowers drive-by editors to selectively revert per WP:ERA and then throw up roadblocks to any actual effort to engage in a collaborative discussion.
In the archived discussion to which I link above, no consensus was reached with respect to limiting this policy-protected right to revert (not with respect to article-involvement, stability, or time-frame). The intention of my suggestion here is to instead insist that any discussion subsequent to such a revert be kept narrowly focused on the actual article and its context, per the policy as currently written. Anyone who doesn't care enough to engage on these terms could then be easily reverted by anyone who cares enough to provide a context-specific justification for changing it back on the talk page—subject, of course, to the normal policy on consensus.
Cheers, Patrick J. Welsh (talk) 18:15, 23 March 2024 (UTC)[reply]
Why did you change from BC to BCE in the first place? Gawaon (talk) 18:24, 23 March 2024 (UTC)[reply]
Per current policy, that's a discussion to be conducted on that article's talk page in terms specific to its subject matter and the relevant context. Patrick J. Welsh (talk) 19:02, 23 March 2024 (UTC)[reply]
The best way to avoid disruptive editing on ERA is not to change the era style without getting the change agreed on the Talk page first. And in fact, where there is a consistent era style in the article, a lot of effort can be saved by leaving the existing era style in place. Sweet6970 (talk) 17:04, 24 March 2024 (UTC)[reply]
Hi @Sweet6970,
I am not proposing that we remove the requirement of prior discussion, which would be a policy change. The issue I raise concerns the current policy-restricted scope of the required talk page discussion.
Per the explicit assumptions of this policy, there are two acceptable styles, and at least sometimes there are good reasons to make a change in one direction or the other. (It was an option to simply forbid such changes; this did not achieve consensus.)
It is also a fact that editors, whether aware of this policy or not, believe they have such good reasons.
My point is that, any argument that, if sound, would apply just as much to all articles as to the article in question is, for this reason, in contradiction with this very same policy, which states that there are actually two at least more-or-less equally acceptable practices.
Therefore any such argument should be disregarded in that context. Because, again, any universal argument to adopt one style over the other is an argument that violates this same policy's stipulation that talk page discussion be conducted in terms specific to the content of the article.
If anyone does have such an argument in favor of either style, I suppose I should add, I would be happy to see it prevail so that the MOS could be revised to simply stipulate which to use. Until then, however – and since, apparently, the normal bold policy and consensus procedure are insufficient for this weirdly charged issue – we must work with what we have. And that is what I take myself to be doing.
My proposed rewording of the current policy, if I understand it correctly, only makes explicit what is already included, but which is less than immediately apparent as currently articulated.
If there is a flaw in my reasoning – or if there is some other justification for not drawing attention to this implication of the policy – could someone please explain?
Cheers, Patrick J. Welsh (talk) 18:19, 24 March 2024 (UTC)[reply]
PatrickJWelsh I think you have rather fundamentally misunderstood WP:ERA. For there to be an "established style", there does not have to have been "a previous discussion under the heading 'era'". If all occurrences (or the overwhelming majority) were BC before you changed it, then that was the established style, and your edit violated WP:ERA. --Trovatore (talk) 04:48, 25 March 2024 (UTC)[reply]
That's what I fear as well. It sounds like the needlessly disruptive type of edit which WP:ERA is meant to avoid. Gawaon (talk) 08:04, 25 March 2024 (UTC)[reply]
No need for fear! I most definitely violated ERA with my edits. This policy is a very specific exception to the usual WP:BRD, of which I was not aware. Once made aware, however, I attempted to engage in the requisite discussion.
For a variety of reasons, I do think that this is a bad policy we would all be better off without. All of my remarks, however, accept it as given. The amended wording that I propose would not change that I violated the policy. It would only, if it works I suppose, have kept the talk page discussion focused on what was best for the article in question.
My intention is only to make it more burdensome to invoke this policy in order to pursue what is, apparently, for some people a culture war issue, but which interferes with making Wikipedia a better encyclopedia.
I assume this weird exception to standard practices was implemented in order to prevent folks overly passionate about era styles from causing pointless disruption. It's specificity, however – not just talk page discussion, by talk page discussion under a specific heading! – makes it ripe for abuse. So, in the spirit of the policy itself, let's do our best to minimize that on the terms of the policy itself.
Cheers, Patrick J. Welsh (talk) 14:51, 25 March 2024 (UTC)[reply]
I don’t see any reason to change the current wording. It says that the era style should not be changed without discussion, and that the reasons used in the discussion should be specific to the article. You say The problem, as I see it, is that it is entirely unclear what constitutes reasons specific to its content. Well, being realistic, there probably are very few such reasons. This means that once a style is established, it is likely to stay. Sweet6970 (talk) 13:11, 25 March 2024 (UTC)[reply]
You seem to be arguing against the policy itself. No?
It is stipulated that there are some. This is a discussion about the proper procedure in the event of a disagreement. Patrick J. Welsh (talk) 14:55, 25 March 2024 (UTC)[reply]
No reasons are ‘stipulated’. And no, I am not arguing against the policy, as such. I am just pointing out the way it works out in practice. Sweet6970 (talk) 16:11, 25 March 2024 (UTC)[reply]
No specific reasons are stipulated as decisive in either direction (which is part of why it is a poor policy). It does however stipulate that there in some cases some such reasons. Otherwise the policy would instead state that once established, era style should never be changed. Which it does not. If you think it should, by all means advance such a proposal. It's less good of a solution than deciding on one style to be preferred by default, but it would address my concern about disruptive edits. Patrick J. Welsh (talk) 16:28, 25 March 2024 (UTC)[reply]
  • I endorse most of the comments above that are not by Patrick J. Welsh. I'd just add that the level of invalid changes of era, and spats over them, seems a good deal lower than a few years ago, and that most people starting them are pretty clearly unaware of WP:ERA. Many think, or claim to think, that BCE/CE are the preferred or mandated style. Johnbod (talk) 13:25, 25 March 2024 (UTC)[reply]
  • I would support removing the "by opening a discussion under a heading using the word era, and briefly stating why the style should be changed". I think a talk page discussion with the heading "BC vs. BCE" with a lengthy opening comment would be just fine, if it led to consensus to change the established style. I would not support adding additional language about which arguments are acceptable in such discussions. Firefangledfeathers (talk / contribs) 14:55, 25 March 2024 (UTC)[reply]
    Hi @Firefangledfeathers,
    I am concerned that requiring that a discussion take place under any specific header makes this policy subject to abuse by those passionate about era styles for reasons unrelated to any specific article. Is there any reason not simply to require prior talk page discussion?
    I'm also inclined to think that the policy should not specify whether the initial justification be brief or lengthy. This is subjective, and I would expect it to be ignored with impunity. For that reason, however, I don't think it particularly matters.
    Cheers, Patrick J. Welsh (talk) 15:09, 25 March 2024 (UTC)[reply]
    I agree. I only brought up "BC vs. BCE" as an example of a perfectly adequate heading that would be inappropriate under the current rule. Again, my preferred outcome here is removing "by opening a discussion under a heading using the word era, and briefly stating why the style should be changed". Firefangledfeathers (talk / contribs) 15:13, 25 March 2024 (UTC)[reply]
    Oh, I misunderstood! That does not go as far as I would like, but I do believe it would be an improvement.
    I will add that my ideal outcome, whatever the best means to achieve it, would be to redirect editors with a strongly held universal preference away from individual articles to instead hash things out at the Village Pump.
    If policy allowed, I would strongly support reopening a RfC on revising the MOS in either direction with the further stipulation that, should there be no consensus, it be decided by the coin toss of an uninvolved admin.
    The two styles are interchangeable. It's frankly embarrassing that we can't just pick one so that we can all get on with making Wikipedia a better encyclopedia. Patrick J. Welsh (talk) 15:39, 25 March 2024 (UTC)[reply]
    That won't happen, and for the same reason that we don't postulate that all of Wikipedia be written in American (or British, or whatever) English. Gawaon (talk) 16:00, 25 March 2024 (UTC)[reply]
    There is no intrinsic difficulty preventing the MOS from taking a stance. Doing so is a large part of the point of having such a thing at all. What I'm proposing, however, is a clarification of what is already there. Patrick J. Welsh (talk) 16:38, 25 March 2024 (UTC)[reply]
    Some of us have participated in several discussions on this subject, and we know from experience that they are a waste of our virtual breath. The question is not going to be resolved in the foreseeable future. Sweet6970 (talk) 16:14, 25 March 2024 (UTC)[reply]
    Sorry? In any case, please don't feel obliged to waste any further breath. Patrick J. Welsh (talk) 16:39, 25 March 2024 (UTC)[reply]
    You're not the first person to think that there should be a project wide standard for this, but developing a community-wide consensus has not happened. What is currently in the MOS is a compromise, and until something shifts it is going to be around for a while. MrOllie (talk) 17:14, 25 March 2024 (UTC)[reply]
    Hi @MrOllie,
    Yes, I understand and accept that, however unfortunate.
    As best I understand it, however, the language of this compromise policy already excludes from article-specific discussion such general reasons such as "this is standard", "this is traditional", or "this is more neutral".
    If my understanding is correct, then making this explicit in the wording of the policy might help prevent talk page discussions from devolving into an irrelevant culture war debate.
    Cheers, Patrick J. Welsh (talk) 17:29, 25 March 2024 (UTC)[reply]
    I think the best approach to pursue here is simply not to start any talk page discussions on the subject. If the current era style used in an article is inconsistent, you are free to clean it up anyway. But if there is a clear dominance of one or the other style detectable, just clean up whatever inconsistencies remain. That's the best usage of everybody's time. Gawaon (talk) 17:58, 25 March 2024 (UTC)[reply]
    You're almost certainly right that it is a waste of time to argue about anything so trivial. The current policy, however, says that that is what you must do if you think a change should be made. Which some people do.
    If you want to propose a policy change to "always retain established style per first use of either convention", I would reluctantly support that as at least better than what we currently have. Patrick J. Welsh (talk) 18:16, 25 March 2024 (UTC)[reply]
    Just act is if that already is the rule (I think it essentially is, for most practical purposes), and you won't go wrong. Gawaon (talk) 20:08, 25 March 2024 (UTC)[reply]
    I could get on board with adding something like "or another expressive heading" after "using the word era". I decidedly don't think that the requirement for a preceding talk page discussion should be dropped. Gawaon (talk) 16:03, 25 March 2024 (UTC)[reply]
    @PatrickJWelsh: The first post in this thread fails to state when the language being complained about was first put into the policy. Obviously the language does not apply to any consensus reached on any talk page before the language first appeared in the guideline. Jc3s5h (talk) 17:26, 25 March 2024 (UTC)[reply]
    Hi @Johnbod,
    Yes, thanks, I hadn't thought about that, but it makes sense (no ex post facto). I would support adding the qualifier "before [date]" to the language in order to prevent particularly egregious abuse of the policy.
    Cheers, Patrick J. Welsh (talk) 17:45, 25 March 2024 (UTC)[reply]
    I just looked up the bit that it looks like you two are talking about; it says [...]by opening a discussion under a heading using the word era[...]. I don't think that was ever meant to be a legalistic requirement; it's just a helpful hint to open a discussion that other discussants can easily understand and join. If we're talking about it as something that has to be grandfathered to take into account earlier discussions, then it's just being misinterpreted and we should remove it. The intent is just, if you want to change the era style away from an established one, you need consensus first. --Trovatore (talk) 19:57, 25 March 2024 (UTC)[reply]
Patrick J. Welsh changed BC to BCE on the Aristotle article, Crumpled Fire reverted, Patrick J. Welsh changed BC to BCE again, Crumpled Fire reverted again, and it was discussed .on the talk page with participants Patrick J Welsh, Andrew Lancaster, Crumpled_Fire, Peter Gulutzan (i.e. me), 86.6.148.125. Patrick J. Welsh also posted what looks like a warning on Crumpled Fire's talk page. I continue to support the reversion, and will support any other reasonable actions that might persuade Patrick J. Welsh to stop, or at the least to ping all participants when moving to a new forum. By the way, WP:ERA is not a policy but a guideline, as is WP:TALKHEADPOV. Peter Gulutzan (talk) 19:42, 25 March 2024 (UTC)[reply]
Hi @Peter Gulutzan,
I quote myself from the talk page discussion:

Thanks for weighing in! The emerging consensus does seem to be "what is wrong with you people and why are you arguing about this?"...Cheers, Patrick J. Welsh (talk) 5:26 pm, 18 February 2024, Sunday (1 month, 6 days ago) (UTC−6)

And then I dropped the matter and left it BC/AD.
I am not here to change the style of the Aristotle article back to what I consider a very slightly preferable convention. The policy is correct in stating that both conventions are fine.
What I am attempting to do is to raise the barrier to entry for people who do not care about the article in question, but are just gunning for a fight.
Please do share here any considerations you might have in response to the concerns I raise above. If your problem, however, is with my individual editorial conduct, it would probably be more appropriate to raise that on my talk page.
Cheers, Patrick J. Welsh (talk) 20:10, 25 March 2024 (UTC)[reply]
I don't see any need to raise barriers to entry. People care about articles for different reasons, it isn't up to us to question people's motivations. MrOllie (talk) 20:36, 25 March 2024 (UTC)[reply]
No kidding. Masterhatch (talk) 20:53, 25 March 2024 (UTC)[reply]
Hi @MrOllie,
I should not have expressed myself that way. In both this discussion and in the Aristotle discussion I have made a conscious effort to avoid imputing bad faith motives to individual participants, and doing so in this more general way did no one any favors. I apologize to all concerned.
With respect to "barriers to entry" I should clarify that the only barrier I am proposing is that participants in a discussion about changing era style provide reasons more specific to the article in question than those general reasons that have been proposed and that have failed to achieve consensus in a more general forum. For what less than this could reasons specific to its content be construed to mean?
That said, however, I am satisfied that I have had my say, and I acknowledge that I appear to persuaded precisely no one that this is, in fact, a little bit of a problem that we could easily do a little bit to fix. So, unless someone speaks up in support of this or a related proposal, I will drop the matter. (On pain of rank hypocrisy!)
I am glad that this discussion appears to have at least resulted in a consensus to clarify that the talk page header does not literally need to be "era". If no one else makes the change, I'll swing back around and implement the language suggested by Gawaon and link to this thread in the edit description.
Cheers, Patrick J. Welsh (talk) 23:49, 25 March 2024 (UTC)[reply]
The current text does not say that the header must be merely "era". "Change era style from BC to BCE" and other headers using the word era would also be compliant. NebY (talk) 13:54, 26 March 2024 (UTC)[reply]

Seasons in magazine titles in running text[edit]

Dondervogel 2 reverted this edit of mine, which removed the bolded text in the sentence below, about the use of seasons in magazine titles:

They are capitalized when part of the title of a work (Science Fiction Quarterly, Summer 1942), except when referring to a seasonal edition in running text (the summer 1942 issue of Science Fiction Quarterly).

The example was added about a month ago without much discussion; see further up this talk page. I removed it for two reasons:

  1. Sources that discuss magazines mostly do capitalize the season name even in running text; and
  2. The use of the lower-case season in this way is against the advice of SEASON in any case, since if we're not using the formal title of the issue, "Summer 1942", then we should be avoiding the use of season names.

It appears that the sources capitalize in this way when they are referring to a specific issue that has that title. I started to compile a list of usage by source, but it's easier to simply go to Google Books and search for "the summer 2019 issue". The first fifteen results have ten with "Summer" and five with "summer". I think the example that Dondervogel 2 reinstated should be removed again: it advises a usage that doesn't agree with what reliable sources do; it makes no allowance for the writer wishing to refer to a specific issue with that formal title; and it conflicts with the main point of SEASON. Mike Christie (talk - contribs - library) 10:32, 3 April 2024 (UTC)[reply]

My point is that "summer" in "the summer 1942 issue" is not a proper noun, so I see no reason to capitalise. Dondervogel 2 (talk) 18:13, 3 April 2024 (UTC)[reply]
I agree it's not a proper noun. The reason it's capitalized is that it's part of the formal title of that issue of the magazine. The example in the first half of the sentence uses upper case; if a writer is referring to that issue of the magazine, they can use the title of the issue if they wish -- and from a look in Google Books it's evident that's what most writers do. Mike Christie (talk - contribs - library) 18:45, 3 April 2024 (UTC)[reply]
Instead of removing it, I've now replaced it with text saying "if a mention of a seasonal edition does not capitalize the season name, avoid using the season name because of the ambiguity". That avoids implying that it should always be capitalized or always uncapitalized in running text, and also avoids giving an example that uses a lower-case season name. Mike Christie (talk - contribs - library) 10:36, 4 April 2024 (UTC)[reply]
I have reverted that, since I don't think it's an improvement. It's totally unclear what's meant by "a mention" (in Wikipedia? in a RS?) and "avoid using" is not useful advice if you don't know how else to refer to the issue in question. Gawaon (talk) 11:47, 4 April 2024 (UTC)[reply]
Personally I think that when such an issue identifier is mentioned in running text it's often unclear whether it's indeed part of the title (which calls for capitalization) or just a generic identifier similar to "the second issue of 1942". Maybe because of this ambiguity, we could simply allow either capitalization and write something like "except that seasonal editions may be lower-cased in running text (the Summer/summer 1942 issue of Science Fiction Quarterly)"? Gawaon (talk) 11:52, 4 April 2024 (UTC)[reply]
My main concern is that the prior wording forbade the use of upper case in running text, so that would work for me. Is it a problem that the example you give uses "summer", which we're trying to avoid recommending? We do say it's "appropriate when it is part of a conventional name or designation"; I think here the "conventional name" would be the magazine issue's title, and that would be upper case. I think the usages one can see of lower case "summer 2019 issue of" in Google Books are season references of the type we discourage. But other than that your wording seems good to me. Mike Christie (talk - contribs - library) 11:57, 4 April 2024 (UTC)[reply]
I've gone ahead and made the change to your wording. Mike Christie (talk - contribs - library) 12:05, 6 April 2024 (UTC)[reply]
I object to the change because if "the Summer 1942 Issue" is interpreted as a part of the title, then "Issue" would also be capitalised. Dondervogel 2 (talk) 12:33, 6 April 2024 (UTC)[reply]
I don't think we can say "issue" is part of the title; the phrase "Summer 1942" will typically appear on the cover and contents page and sometimes the masthead of a magazine, but it is never accompanied by the word "issue". Mike Christie (talk - contribs - library) 12:56, 6 April 2024 (UTC)[reply]
I don't think that's true. The magazine cover will probably just say something like "Science Fiction Quarterly – Summer 1942", the magazine title being the main title, and the issue identifier something like the subtitle. The word "issue" probably won't appear on the cover and so is not part of the title. (I had already largely written this when Mike Christie's comment appeared, so I'll let it stand despite the repetition.) Gawaon (talk) 12:58, 6 April 2024 (UTC)[reply]
I fully agree the word "issue" is not normally considered part of the title, in which case it should not be capitalised. My point is that if "issue" is not part of the title, then neither is "summer 1942". It's just text describing which issue we are referring to. Just because "Summer 1942" can be part of the title, as in Science Fiction Quarterly, Summer 1942, does not imply it always is. It depends on the construction. Dondervogel 2 (talk) 14:25, 6 April 2024 (UTC)[reply]
I think it's the other way round -- the only difference between the two constructions (the writer is using the title of the issue vs. the writer is mentioning the time of year when the issue appeared) is the capitalization. If it's capitalized, the writer is using the issue's title. The revised wording suggested by Gawaon allows for both, which is in line with actual usage in the sources. Mike Christie (talk - contribs - library) 14:28, 6 April 2024 (UTC)[reply]
Indeed. "Summer 1942" is how the publisher named the issue, as well as being how others refer to it. It may or may not bear any particular relationship to the season in which it was actually published or even indicate when it could be taken off sale and returned. NebY (talk) 14:43, 6 April 2024 (UTC)[reply]
Sounds like I am in a minority of one. For that reason I withdraw my objection. Dondervogel 2 (talk) 18:43, 6 April 2024 (UTC)[reply]
I agree with @Dondervogel 2 that we should default to lower-case in running text. Let's consider a non-season example. Our MOS would recommend using Science Fiction Quarterly, Third Edition when referring to the edition as a title, but on the other hand we would state third edition of Science Fiction Quarterly in running text. I don't see a compelling reason to do anything differently just because we're now dealing with a season name.
For what it's worth, I initiated the discussion above because of an MOS discussion at the 'Oyster dress' FAC, which actually concerned a fashion collection rather than a periodical title. Over there I was a so-called "minority of one". Just as an FYI to you, Dondervogel 2, that you're not alone in your position. I maintained my objection in that discussion because I could not find an MOS-based reason to support capitalization despite my best efforts.
I like the wording that @Gawaon and @Mike Christie added. It gives flexibility based on how reliable sources handle capitalization. However, I do have two recommended changes.
  1. The new text currently states the Summer/summer 1942 issue, but in the MOS we usually provide separate instances of an example to avoid ambiguity. We're not telling people to actually write down Summer/summer; we want them to pick one or the other. So I think the text should be fully expanded to say "the summer 1942 issue of Science Fiction Quarterly or the Summer 1942 issue of Science Fiction Quarterly". But this also might unnecessarily lengthen the guideline so I'd appreciate thoughts from others.
  2. It also might be helpful to remind editors of MOS:CAPS, which looks for a "substantial majority" of such sources to support capitalization. Of course, "substantial majority" is still an imprecise term so I don't know how helpful it would be on the more contentious cases.
Edge3 (talk) 05:01, 7 April 2024 (UTC)[reply]
For #1, a shorter magazine title would help. How about "the summer 1985 issue of Interzone or the Summer 1985 issue of Interzone"? Mike Christie (talk - contribs - library) 10:57, 7 April 2024 (UTC)[reply]
Fine with me. But we should probably keep the capitalized form first. Gawaon (talk) 11:28, 7 April 2024 (UTC)[reply]
I tried to incorporate my changes for #1 and #2, along with the feedback here. See edit. It's a somewhat complex change, so feel free to revise further! Edge3 (talk) 02:38, 8 April 2024 (UTC)[reply]
I have partially reverted that since it's not what we agreed on and would put an undue burden on editors, who cannot be expected to research "substantial majority" distributions for every issue title they mention. Let's keep it simple and allow both case forms without prejudice. Gawaon (talk) 05:19, 8 April 2024 (UTC)[reply]
I agree. I've changed the date for the Interzone example to 1985, since we might as well use an issue that really appeared as an example. Mike Christie (talk - contribs - library) 10:08, 8 April 2024 (UTC)[reply]
I was trying to address my point #2 above to give guidance on when to capitalize. You both haven't talked about it yet so I'm happy to hear feedback. Edge3 (talk) 14:46, 8 April 2024 (UTC)[reply]

I don't know that there's anything useful we can add on when to capitalize. It seems that in running text the seasons are more often capitalized than not, but as discussed above I think the only way to tell the writer's intent is from the capitalization -- that is, we're not going to be able say "if your sentence is like <this> then capitalize". I suppose we could say something like "if you mean to refer to the issue by its title, capitalize; otherwise if you are referring to the season of the year when the issue appears, then do not capitalize", but that seems a bit wordy. I think the lower-case usage does run into a problem with the main reason for SEASON in the first place so ideally we wouldn't mention it at all, but then we'd have to say something like "northern summer" which is just not how the sources do it -- they assume the context is the location where the magazine is published. Mike Christie (talk - contribs - library) 15:11, 8 April 2024 (UTC)[reply]

Let's not overcomplicate this. The current wording works. Gawaon (talk) 16:35, 8 April 2024 (UTC)[reply]
The current wording may be fine for seasonal periodicals, but it still doesn't give clear guidance in other cases. Specifically for fashion-related articles, a majority of sources use lowercase, but our WP articles still capitalize based on a previous interpretation of the MOS. The phrasing "may be lower-cased" is permissive, while MOS:CAPS provides an explicit test: avoid capitalization unless supported by a "substantial majority" of sources. Edge3 (talk) 17:10, 8 April 2024 (UTC)[reply]
Uh, seasonal periodicals is what the wording is all about, so where shouldn't it be fine? Gawaon (talk) 06:05, 9 April 2024 (UTC)[reply]
Edge3, if you're talking about fashion shows such as the Spring/Summer 2006 collection at which Neptune was shown, then I'd say the sources show exactly the same variation that source about magazines do -- when the writer is referring to the show by what they regard as the formal title they use the upper case version; when they are referring to the season they use lower case. Just as with magazines, the capitalization is what tells you their intention -- the fact that both occur doesn't mean one is right and one is wrong; it just distinguishes the two usages. Pinging Premeditated Chaos as I know this discussion began on one of her FACs. Mike Christie (talk - contribs - library) 11:00, 9 April 2024 (UTC)[reply]
Mike, while I appreciate the ping, I'm not interested in participating in this discussion. Edge3 has consistently shown that he has no interest in listening to the opinions of other editors, as indicated by his single-minded dismissal of the clear consensus from something like a half-dozen-plus editors (including FAC coords!) who showed up at the Oyster dress FAC to tell Edge3 that his interpretation was incorrect.
I'll repeat the argument I made when Edge3 showed up at my next FAC to complain that I wasn't following the arbitrary change he made to MOS:SEASONS, despite the fact that the capitalization was actually correct under his arbitrary brand-new wording.
"Season names are generally not capitalized (a hot summer), except when personified (Old Man Winter) or when part of a formal name". A fashion season such as "Autumn/Winter 2008" or "Resort 2014" is a formal name for a particular period in the industry, so it is capitalized. Other editors clearly agreed with this interpretation in the last discussion, so although the MOS wording may have changed, the reality underpinning my reasoning has not.
I do not see the point in participating in a discussion with someone who has decided that consensus is irrelevant unless it's in his favor, who feels he can arbitrarily rewrite the MOS whenever consensus does not go his way, and who feels he can interpret his brand-new wording however he wants even when it actually supports my position despite his rewrites. I have zero intention of altering the capitalization for fashion seasons unless there is a strong consensus for this change from editors who are not Edge3. I am deliberately not watching this page, will not be reading any replies, and do not wish to be pinged back here to this or any further discussion on the topic, because I find attempting to speak to Edge3 on this topic exhausting and frustrating, and I would prefer to do literally anything else with my time than argue about capital letters. ♠PMC(talk) 11:46, 9 April 2024 (UTC)[reply]

Numbers[edit]

Under the Numbers section, it states:

"Generally, in article text:

Integers from zero to nine are spelled out in words."

I wonder why is "from zero to nine" instead of "from zero to ten"? We humans have ten fingers, we learn how to count from one to ten since we were little kids. If we learn a foreign language, the first thing we learn is words like hello, thank you, good bye, and count from one to ten. It doesn't make sense that only integers from zero to nine shoulde be spelled out in words. It should be integers from one to ten. 120.16.218.233 (talk) 17:18, 13 April 2024 (UTC)[reply]

Yes, but cats have nine lives, so it makes perfect sense actually. GiantSnowman 17:19, 13 April 2024 (UTC)[reply]
LOL. You must be joking. 120.16.218.233 (talk) 17:21, 13 April 2024 (UTC)[reply]
...weren't you? GiantSnowman 17:23, 13 April 2024 (UTC)[reply]
Nope. I really think that in article text, integers from zero to ten should be spelled out in words (i.e. ten years ago not 10 years ago). 120.16.218.233 (talk) 17:28, 13 April 2024 (UTC)[reply]
We don't say that "only integers from zero to nine shoulde be spelled out in words". We do say that Integers greater than nine expressible in one or two words may be expressed either in numerals or in words and proceed to qualify that in several ways, allowing for either "10" or "ten" to be used as appropriate. NebY (talk) 17:39, 13 April 2024 (UTC)[reply]
I’ve thought this for a long time, so agree with you. Numbers expressed as words are easier to read and don’t visually interrupt a sentence in the same way as does sticking figures in the middle of it. IMHO figures should only be used when multiple words are needed to express the quantity. MapReader (talk) 18:59, 13 April 2024 (UTC)[reply]
"Numbers expressed as words are easier to read". My experience is the opposite. I find it much easier to express numbers as numerals always. I only express them in words when English convention says Thou Must Use Words For Small Numbers but I never liked it. Mind you, I spend most days writing software and doing engineering stuff, so I may not represent the typical reader.  Stepho  talk  11:07, 14 April 2024 (UTC)[reply]
Agreed. We should be looking to REDUCE the instances of "numbers as words", not increase them. --User:Khajidha (talk) (contributions) 17:19, 17 April 2024 (UTC)[reply]
While I have no strong preference one way or the other, adding ten to the numbers for which words are preferred would be fine with me. Ten is indeed just one more character than 10, so it's the number easiest to spell out. Gawaon (talk) 19:25, 13 April 2024 (UTC)[reply]
Some other style guides:
  • The BBC News Style Guide has "For the most part, we use words for single-figure numbers, digits for anything above nine (ie eight, nine, 10, 11)" followed by various exceptions.[1]
  • The Guardian and Observer style guide has "Spell out from one to nine; numerals from 10 to 999,999 ...."[2]
  • According to this 2005 discussion here in WT:MOSNUM, Wikipedia talk:Manual of Style/Dates and numbers/Archive 25#Numbers written as words, the Chicago Manual of Style has (or had) "According to Press style, the following are spelled out in ordinary text: Whole numbers from one through ninety-nine; Any of these followed by hundred, thousand, million, etc."
  • According to the same discussion, the Oxford Style Manual (2003) had "In non-technical contexts, OUP style is to use words for numbers below 100."
  • Fowler's Modern English Usage (4th edn) has "Figures should be used when the matter consists of a sequence of stated quantities [e.g.] The past 12 months show an increase of 5 tons" and "In descriptive matter, numbers under 100 should be in words, but write 90 to 100, not ninety to 100."
I haven't tried a proper search in MOSNUM's history – I doubt a straightforward Wikiblame search would help – but it looks as if the core one-to-nine rule's been stable since Wikipedia talk:Manual of Style/Dates and numbers/Archive 73#Proposed revision of "Numbers in words" in 2007. NebY (talk) 20:26, 13 April 2024 (UTC)[reply]
Proposal The IP user brought up an interesting point. Why "from zero to nine"? Why not "from zero to seven, eight, ten, or eleven"? I propose that we change the rule to "Integers from zero to twenty are spelled out in words". If we can express a number in a single, simple English word, then use the English word. If more than one word or a hyphen is involved (e.g. twenty-one, one hundred and one), use the numerals. N. Mortimer (talk) 00:32, 14 April 2024 (UTC)[reply]
Against - Existing form (words for single digits, numerals for more) works fine. Examples for each:
  1. There 14 reasons to object.
  2. There are fourteen reasons to object.
The numeral form is so much more compact, quicker to type, quicker to read, requires less effort to understand and the quirks of spelling for 11-19 are avoided for our English as a second language audience (why is 11,12 different to 13-19; why is 13-19 different to 23-29, etc?). Keep it simple.  Stepho  talk  01:53, 14 April 2024 (UTC)[reply]
So you also support my proposal of adding "ten" to the mix? Thank you. Ten is a very simple word, I think all people with a basic understanding of English know this word.
By the way, even if we use "14" instead of "fourteen" in your sentence example, we can't really omit the "are", but I agree with you that numbers greater than ten should be written in the numeral form. 120.16.218.233 (talk) 09:57, 14 April 2024 (UTC)[reply]
Oops, I forgot to type in "are" for the first example. My mistake.
Oh dear, it looks like only 1 of us knows how to count up to 2. "10" is not a single digit, so "words for single digits, numerals for more" means I support "10", not "ten".  Stepho  talk  10:22, 14 April 2024 (UTC)[reply]
Why don't you support "ten"? "Ten" is shorter than "three", "seven" or "eight". People like to group things in even numbers, not odd numbers (because they are odd 😂). 120.16.218.233 (talk) 23:59, 14 April 2024 (UTC)[reply]
Because "10" is not a single digit. Am I saying this wrong? Should I type slower? Should I use words with one syllable or less?  Stepho  talk  00:31, 15 April 2024 (UTC)[reply]
No. Spelling out such simply words is already allowed, it shouldn't be required. It's very hard to see why 17 should be treated differently than 27, and if this rule were adapted, it would logically have to apply to thirty, forty etc. as well. Gawaon (talk) 04:43, 14 April 2024 (UTC)[reply]
Yes, it should logically apply to thirty, forty etc. And the reason is obvious; single spelled words are easier to read than interrupting a sentence with digits, but that advantage weakens when multiple words are required to spell out a number. MapReader (talk) 06:40, 14 April 2024 (UTC)[reply]
Actually, I find "The applicants' ages ranged from seventeen to seventy" harder and less convenient to read than "The applicants' ages ranged from 17 to 70". Especially, in latter sentence the numbers stand out, making them very easy to detect when one skims a text quickly, which is not the case in the former sentence. Gawaon (talk) 07:02, 14 April 2024 (UTC)[reply]
That's why we should make "ten" the cut-off point:
Zero
One
Two
Three
Four
Five
Six
Seven
Eight
Nine
Ten
11
12
13.... 120.16.218.233 (talk) 10:03, 14 April 2024 (UTC)[reply]
No. As spelt out in the very next sentence after Integers from zero to nine are spelled out in words, we already allow that Integers greater than nine expressible in one or two words may be expressed either in numerals or in words, both subject to and extended by the following notes and exceptions. This is appropriately flexible; the mere fact that single words exist for some numbers does not meant they are always the best way for readers to take in quantitative information, even when reading the text closely rather than skimming it for key points – as many encyclopedia readers do. Our manual is in keeping here with at least some other major style guides, and has served as stable guidance and a sound reference point for Wikipedia editors for many years. NebY (talk) 18:02, 17 April 2024 (UTC)[reply]

The redirect Mos:DOB has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2024 April 25 § Mos:DOB until a consensus is reached. Utopes (talk / cont) 21:59, 25 April 2024 (UTC)[reply]

Hyphenation in spelled-out fractions[edit]

Per MOS:FRAC: Spelled-out fractions are hyphenated.

Should this always be so? I noticed One half doesn't abide in its title, and there are potential ambiguities in use. Remsense 05:54, 18 May 2024 (UTC)[reply]

See existing (but closed) discussion at Talk:One half, on a failed proposal to move it to one-half. In particular, there, jacobolus wrote MOS:FRAC is straight up wrong here, and should be changed. Whether to add a hyphen depends on the grammatical context. Some others (myself included) agreed. —David Eppstein (talk) 06:03, 18 May 2024 (UTC)[reply]
Right, it seems to make more sense to add a hyphen when they are used as modifier (adjective), but not when used as noun. Gawaon (talk) 07:04, 18 May 2024 (UTC)[reply]
On this basis there is clearly no consensus for the rule as stated, so I removed it until there is agreement on what it should be replaced by. My view is that of Gawaon. For example
  • A one-half octave is one half of an octave.
  • Seven eighths of a mile is 1,540 yards.
  • Three tenths of a kilometre is 300 m.
Dondervogel 2 (talk) 10:29, 18 May 2024 (UTC)[reply]
"Hyphenate a spelled-out fraction used as a modifier" or similar seems like a fine rule to include. –jacobolus (t) 16:32, 18 May 2024 (UTC)[reply]
I had WP:BOLDly edited the page and suggested the following wording: "Spelled-out fractions are hyphenated before a noun (They won a two-thirds majority), but not when used stand-alone (The distance was seven eighths of a mile)." That change was reverted so it seems more discussion is needed. Gawaon (talk) 16:50, 18 May 2024 (UTC)[reply]
FWIW, the latest Fowler's Modern English describes real-world usage of the hyphen as "chaos", notes it's on the wane "even in British English", identifies some main uses (creating a single unit of meaning (dry-clean); phrases in front of nouns (up-to-date record, well-known man); with prefixes (ex-husband, re-cover); in lists (two- or three-fold); to avoid misinterpretation (extra-marital sex); with phrasal verbs, as a mistake; in printing,to break a word) but doesn't address this question directly.
Two-thirds majority fits Fowler's first and second usages; I think seven-eighths of a mile fits Fowler's first, a single unit of meaning, especially considering its other representations (0.875, 7/8). NebY (talk) 17:20, 18 May 2024 (UTC)[reply]
  • I don't think I've got the energy to stick with this discussion, but let me point something out. In he walked three quarters of a mile, I'm not sure the phrase "three quarters" is a fraction; seems to me it's 3 quarters, if you get my meaning. EEng 17:14, 18 May 2024 (UTC)[reply]
    I do, but though that works in I ate three quarters of the quattro stagioni (but not the mushrooms) or even he ran three quarters of the mile (but walked the third one), by itself he walked three quarters of a mile is no more than he walked 3/4 mile. NebY (talk) 17:41, 18 May 2024 (UTC)[reply]
    Just throwing this out: "he played three quarters of the basketball game" (it has four quarters), versus "he watched three-quarters of the movie". Just wondering. Bubba73 You talkin' to me? 04:56, 20 May 2024 (UTC)[reply]
    Would you really write them differently? I would tend to write them the same (both without a hyphen). Gawaon (talk) 05:22, 20 May 2024 (UTC)[reply]
    What would you say if the sentence is, "he played in three quarters of the basketball game"? To me, that reads that he played in at least part of each of three quarters of the games (say, from the middle of the second quarter to the middle of the fourth quarter), but not necessarily for a full three-quarters of the games. A bit contrived, but edge cases test rules. Donald Albury 16:54, 20 May 2024 (UTC)[reply]
    True, I'd say that "he played in three quarters of the basketball game" might mean that he played less compared to "he played three quarters of the basketball game", which is more likely to give the total length of his play. However, I'd say if the use or non-use of a hyphen should depend on such subtleties, we're overcomplicating things. According to the rule I favour, no hyphen should be used in either case. Gawaon (talk) 17:19, 20 May 2024 (UTC)[reply]
    Would it make a difference with fourths instead of quarters? —David Eppstein (talk) 18:22, 18 May 2024 (UTC)[reply]
    Not sure. To be honest, I was quite sleep-deprived when I made that post and I'm not sure now how exactly I thought it would clarify anything. :( What about the case of "one half"? There's no "one twoth". EEng 07:02, 19 May 2024 (UTC)[reply]
    "One half" is somewhat an exception because it is used so commonly (cf. first, second, third, instead of oneth, twoth, threeth). The same goes for "one quarter" (though "one fourth" is an accepted alternative). I don't see anything wrong with the phrase "three quarters of a mile", that's just 3*(1/4) mi = 3/4 mi. ~~lol1VNIO (I made a mistake? talk to me) 10:28, 19 May 2024 (UTC)[reply]
    I didn't say there's anything wrong with it. I was just pointing out, since this discussion is nominally about fractions, that it may not be clear that "three quarters" (and so on) actually is a fraction. EEng 20:34, 19 May 2024 (UTC)[reply]
    I think it's clear that a "quarter" is 1/4. A quarter of an hour is 15 min. A quarter of a dollar is 25 cents. I'm sorry, I'm not sure where the confusion lies. ~~lol1VNIO (I made a mistake? talk to me) 09:01, 20 May 2024 (UTC)[reply]
    Well, since you press the point: no, it's not clear. "Three quarters" might be a fraction (3/4), or it might be three times a fraction (3 · 1/4), but not itself a fraction. EEng 09:25, 20 May 2024 (UTC)[reply]
    3/4 and 3(1/4) are both the same, just expressed differently. One can choose interpret "three quarters" as the former and the problem would be solved. ~~lol1VNIO (I made a mistake? talk to me) 09:28, 20 May 2024 (UTC); edited 09:31, 20 May 2024 (UTC)[reply]
    • 3/4 and 3(1/4) are both the same, just expressed differently – Wow, and to think I spent all that money on a degree in applied math from Harvard, and they never taught me that. If what you're saying is really true, then I'm going to ask for my money back! Next you'll be telling me that (1/x) · x = 1.
    • One can choose interpret "three quarters" as the former – You're contradicting yourself. If the two things are the same, then choosing between them makes no sense, since (says you) they're both the same -- there's no choice to be made. But they're not the same. That's the point. One's a fraction and one is an integer times a fraction, in which case the question of "how to write fractions" doesn't apply to it.
    EEng 09:51, 20 May 2024 (UTC)[reply]
    Are you saying that "one eighth" is a fraction, but "three eighths" isn't? That would be a highly original interpretation of "fraction". Gawaon (talk) 10:04, 20 May 2024 (UTC)[reply]
    No. If we interpret "three eighths" not as a fraction, but rather as an integer followed by a fraction, then "one eighth" is also not a fraction. EEng 17:49, 20 May 2024 (UTC)[reply]
    How silly of me! All those Aristotlean logic I learned for nothing! ~~lol1VNIO (I made a mistake? talk to me) 10:06, 20 May 2024 (UTC)[reply]
    All those grammar, too! EEng 17:49, 20 May 2024 (UTC)[reply]
    Not necessarily. The fraction 3/4 can be seen as indicating a cohesive part. While 3(1/4) would equal the same amount, it might not be a single "thing". For example, imagine a cake cut into 8 equal parts (labeled 1-8 in clockwise fashion). If I eat pieces 1-6, then I can be said to have eaten 3/4 of the cake and also to have eaten 3 of the quarters of the cake. However, If I eat pieces 2-4 and 6-8, then I can be said to have eaten 3/4 of the cake but not to have eaten 3 of the quarters of the cake. --User:Khajidha (talk) (contributions) 15:34, 20 May 2024 (UTC)[reply]
    ^ This guy gets it. EEng 17:49, 20 May 2024 (UTC)[reply]
    I think rarely in articles, you would dig into the nitty-gritty of how it came to 3/4. In the original example (he walked three quarters of a mile), no reader would be perplexed as to if he walked three (quarters of a mile) or (three quarters) of a mile. If you really want to specify that he either walked in quarter miles, taking breaks along the way, or walked 0.75 miles in one go, then say it.
    In User:Khajidha's example, there is a fraction in both cases: said to have eaten 3/4 of the cake and also to have eaten 3 of the quarters of the cake (here, 3/4 is "three quarters"); and have eaten 3/4 of the cake but not to have eaten 3 of the quarters of the cake (also 3/4 aka "three quarters"). So "three quarters" is a fraction either way. ~~lol1VNIO (I made a mistake? talk to me) 19:42, 20 May 2024 (UTC)[reply]
    I.e., basically what Chicago is saying in the passage I quoted below? (And using the same example, incidentally!) Graham (talk) 03:19, 21 May 2024 (UTC)[reply]
    As for "used stand-alone", that is when the denominator of the fraction is not an attribute, that's when it shouldn't be hyphenated (according to the discussion). An attribute is optional, so if you remove it, it still makes grammatical sense. For example, They won a three-quarters majority (not standalone), if you remove "three-quarters", it makes grammatical sense; whereas They won a majority of three quarters (standalone), if you remove "three quarters", it makes no sense. Thus, NebY's example above (seven-eighths of a mile) should not be hyphenated because there, the attribute is "of a mile". ~~lol1VNIO (I made a mistake? talk to me) 10:49, 19 May 2024 (UTC)[reply]
    That was my proposal (also suggested by others), and I still think it makes a lot of sense and reflects widespread usage fairly well. EEng, if you think the used wording was unclear, maybe you have a suggestion on how to improve it? Gawaon (talk) 11:21, 19 May 2024 (UTC)[reply]
    We could explain it linguistically and note that hiding attributes would still make grammatical sense: Spelled-out fractions are hyphenated when it is used as an attribute (They won a two-thirds majority), but not when used stand-alone (The distance was seven eighths of a mile). Rule of thumb: hyphenate if removing the fraction would still make grammatical sense. Instead of "when used stand-alone", we could dig deeper into linguistics and say "when the denominator is used as the head noun of the phrase", but I doubt that would be any more clear. ~~lol1VNIO (I made a mistake? talk to me) 11:50, 19 May 2024 (UTC); edited 11:58, 19 May 2024 (UTC)[reply]
    Hmm. I might not hyphenate if the emphasis was on the denominator, but that's a more narrow exception and perhaps more traditionalist. NebY (talk) 12:18, 19 May 2024 (UTC)[reply]
    The suggested wording sounds fine for me. Gawaon (talk) 13:05, 19 May 2024 (UTC)[reply]
    Lol1VNIO's suggestion makes sense to me too. I would just replace "when it used" with "when used". Dondervogel 2 (talk) 18:56, 19 May 2024 (UTC)[reply]
If we were writing here for The New Yorker or some other highfalutin publication, we could, perhaps, follow a more complex style, but in the encyclopedia anyone can edit, simple rules are better. It's like the comma after a mdy date. Sometimes there is no need for a comma after May 20, 2024, but it is so much easier to always use it and it doesn't hurt anything. Let's stick with the hyphen in written out fractions. One half may or may not be correct, but we can live with some inconsistency.  SchreiberBike | ⌨  11:36, 20 May 2024 (UTC)[reply]

I would agree with others that I don't think it makes sense to hyphenate fractions where they are being used as compound modifiers. However, to maintain consistency with MOS:HYPHEN, I would suggest that we further specify that we only use hyphens with fractions where it is being used as an attributive or substantive modifier (which is what I think most of us have in mind anyway) rather than a predicative modifier. Graham (talk) 04:27, 20 May 2024 (UTC)[reply]

That matches my intuition. —David Eppstein (talk) 08:10, 20 May 2024 (UTC)[reply]
Our manual of style has to be plain and direct, providing easily understood guidance to all editors who need it, not only those who are trained in the use of high-falutin' terms like attributive, substantive, predicative and modifier. NebY (talk) 11:19, 20 May 2024 (UTC)[reply]
Are you proposing that we amend MOS:HYPHEN? Graham (talk) 03:07, 21 May 2024 (UTC)[reply]

The Australian style guide says Use a hyphen in fractions written out in words (eg two-thirds). I oppose any change to the MOS. Hawkeye7 (discuss) 04:46, 20 May 2024 (UTC)[reply]

What's "the Australian style guide"? Anyway, our old rule stating the same has already been thrown out. The question is now what to replace it with. Gawaon (talk) 05:24, 20 May 2024 (UTC)[reply]
That's here, along with Write fractions in full in running text, and use a hyphen. The Australian govenment's style manual has Hyphens link parts of a fraction.[3] NebY (talk) 10:33, 20 May 2024 (UTC)[reply]

The BBC News Style Guide has simply three-quarters (and other fractions).[4] NebY (talk) 10:22, 20 May 2024 (UTC)[reply]

Purdue has a collection of style guides; I only found Use a hyphen with compound numbers: forty-six, sixty-three, Our much-loved teacher was sixty-three years old.[5] NebY (talk) 10:44, 20 May 2024 (UTC)[reply]

That's not really relevant to fractions. Graham (talk) 03:04, 21 May 2024 (UTC)[reply]
It is relevant when the only guidance on compund numbers is to hyphenate; that includes fractions. Back in 2007, we stated it as Spelled-out two-word numbers from 21 to 99 are hyphenated (fifty-six), as are fractions (seven-eighths)[6] (it may have been on some other MOS page before then). NebY (talk) 15:48, 23 May 2024 (UTC)[reply]

Graham11 reports The Chicago Manual of Style also prescribes the hyphenated form, even when the term is used as a noun.[7] NebY (talk) 17:35, 20 May 2024 (UTC)[reply]

The most relevant passage is 9.14:

9.14 Simple fractions. Simple fractions are spelled out. For the sake of readability and to lend an appearance of consistency, they are hyphenated in noun, adjective, and adverb forms. In the rare event that individual parts of a quantity are emphasized, however, as in the last example, the expression is unhyphenated. See also 7.89, section 1, under fractions, simple. For decimal fractions, see 9.19.

She has read three-fourths of the book.
Four-fifths of the students are boycotting the class.
I do not want all of your material; two-thirds is quite enough.
A two-thirds majority is required.
but
We divided the cake into four quarters; I took three quarters, and my brother one.
Graham (talk) 03:17, 21 May 2024 (UTC)[reply]
Thanks for that. In short, Chicago supports our Spelled-out fractions are hyphenated with one minor exception. NebY (talk) 15:41, 23 May 2024 (UTC)[reply]

Collins English Dictionary's entry for two-thirds begins with two-thirds of.[8] NebY (talk) 17:48, 20 May 2024 (UTC)[reply]

Merriam-Webster online gives for three-quarters Three-quarters of the class will be going on the trip and three-quarters of an hour, plus many "Recent Examples on the Web", each using three-quarters of, hyphenated: nearly three-quarters of those using the feature (WSJ); three-quarters of lawmakers (Anchorage Daily News); three-quarters of a percentage point (Los Angeles Times) and more.[9] NebY (talk) 18:06, 20 May 2024 (UTC)[reply]

"Full, unambiguous signifier" for currencies[edit]

Do we have a list somewhere of "full, unambiguous signifier[s]" for currencies? MOS:CURRENCY links to List of circulating currencies, but nowhere can we find "A$" or "US$" there, which MOS:CURRENCY recommends us to use. LightNightLights (talkcontribs) 10:41, 18 May 2024 (UTC)[reply]

@LightNightLights: See Currency symbol#List of currency symbols currently in use. That article deviates heavily from the World Bank Group's editorial guide (p. 134) that lists uncommon symbols like $A. ~~lol1VNIO (I made a mistake? talk to me) 11:25, 19 May 2024 (UTC)[reply]
@LightNightLights: I've just discovered that templates that are titled after ISO 4217 codes standardize the signifiers on enwiki. Use {{AUD}}, {{CAD}}, {{USD}} etc. or {{Currency|value|code}} with codes at Module:Currency/Presentation ~~lol1VNIO (I made a mistake? talk to me) 15:39, 19 May 2024 (UTC); edited 16:52, 19 May 2024 (UTC)[reply]
@Lol1VNIO Thank you. I do not consider myself as someone who writes or contributes to style manuals so I do not know the answers to these questions, but:
LightNightLights (talkcontribs) 18:03, 20 May 2024 (UTC)[reply]
@LightNightLights: The guide already links to Currency symbols, specifically to #dollar variants, though a link to the page after "full, unambiguous signifier" wouldn't be a bad idea. As for templating every currency, not really. It makes sense in some (฿100) but others you can just enter on your keyboard. Often, you're familiar with a set of currencies that you don't need to look up, anyway. ~~lol1VNIO (I made a mistake? talk to me) 20:15, 20 May 2024 (UTC)[reply]
@Lol1VNIO I swear that I fully read MOS:CURRENCY multiple times, but I didn't notice the Currency symbols link. I am not sure how to correctly add the link after "full, unambiguous signifier", so I am okay with you adding it. LightNightLights (talkcontribs) 10:24, 21 May 2024 (UTC)[reply]
Perhaps add suggestions to consider using {{currency}}, {{USD}} and similar.  Stepho  talk  06:11, 24 May 2024 (UTC)[reply]