Wikipedia talk:Manual of Style/Dates and numbers

External image
Kliban: Converting feet to meters

Unofficial anagram of the Manual of Style (First runner-up: A lemony flatus.)

L is for liter

So as this MOS page notes, the lowercase letter "l" is easily confused with the number "1" or the uppercase letter "I" or the pipe symbol "I", depending on the font. The uppercase letter "L" does not have this problem. Consider the difference between these two lines:

100 L (22 imp gal; 26 US gal)

100 L (22 imp gal; 26 US gal)

When I learned the metric system in high school, for this reason we were taught to use only "L" for liter, and I'm told that's also why this standard has been adopted by some chemistry journals. Doing some Wikipedia-wide spellcheck work recently, I did find "l" being used for liter, and it is indeed not all that easy to read whether in the edit window or final display style. To improve clarity for editors and for users of Wikipedia content (which includes but goes beyond this web site and its default settings), I would like to propose changing the MOS guideline so that only "L" is recommended for liters, including constructed units like "mL". I can't think of any upside for using "l", though perhaps someone else can point some out. -- Beland (talk) 04:28, 14 February 2021 (UTC)

Context readily makes this clear. The pronoun "I" is equally easily confused with the number "1" or the lowercase letter "l" or the pipe symbol "I", depending on the font, but does not create any difficulty in the post above. 100 l is equally clear above. Doremo (talk) 04:47, 14 February 2021 (UTC)

I do not find it particularly clear; the reader can be left wondering what unit of measure is being represented by "I", especially in the U.S. where the metric system is not in common use. -- Beland (talk) 20:18, 15 February 2021 (UTC)

Sure it's clear. About as clear as mud. Dondervogel 2 (talk) 21:39, 15 February 2021 (UTC)

• Gosh, it seems impossible to imagine that this has been discussed before now, so that it would be worth checking the archives to see what arguments have been presented already, thereby saving repetition and waste of time. Nonetheless, hoping against hope, let's see ... Amazing! It has been discussed before! – WT:Manual_of_Style/Dates_and_numbers/Archive_157#Decide_on_“l”_vs_“L”_for_litre_(liter). EEng 04:50, 14 February 2021 (UTC)

  Just because it's been discussed before does not invalidate the argument presented. MOSNUM can, if it chooses, adopt a uniform symbol for use across Wikipedia, and a single uniform symbol makes articles easier to follow. Dondervogel 2 (talk) 09:53, 14 February 2021 (UTC)

  Sure, but it's a mark of courtesy (one might even say civility) to respect the time of one's fellow editors by reviewing past discussions first. "Ell can be confused with other stuff, and L can't, so always use L" has been suggested already, with much discussion, so if one wants to move things forward one should build on what has come before – not drag everyone back to the starting line. As the great J.S. Mill put it

  No one's idea of excellence in conduct is that people should do absolutely nothing but copy one another ... On the other hand, it would be absurd to pretend that ... nothing whatever had been known in the world before they came into it; as if experience had as yet done nothing towards showing that one mode of existence, or of conduct, is preferable to another.

  Of course, he wasn't talking about MOS discussion, but the point remains. EEng 14:28, 14 February 2021 (UTC)

Thank you for the link to the previous discussion; reading it was very helpful. I'd be happy to discuss the general problem of connecting current policy to previous discussions if we can do that in a collegial and non-snarky way.

In this case, it looks like the previous discussion got derailed and didn't come to any particular orderly conclusion, though it was a good brainstorm. Based on the preferences expressed, I think there were two options likely to get supermajority consensus support in an RFC. Before jumping into that, why don't I run those past people here:

• All cases - To avoid confusion with "1" and "I" and "|", "L" should be used in all cases, whether isolated like "L" or with a prefix like "mL".
• Limited cases - To avoid confusion with "1" and "I" and "|", "L" is prefered when used without a prefix ("L"), or with a prefix ("mL") if "L" is used elsewhere in the same article ("1000 mL is 1 L", "5 mL/L"). Otherwise, lowercase may be used with a prefix ("ml").

I was thinking of asking folks if they support neither, one, or both of these, and if they have a preference between them. Does that make sense? -- Beland (talk) 00:03, 19 February 2021 (UTC)

Absolutely not. When I taught in a secondary school we explained the the litre was a derived SI unit, it was a way of expressing 1 dm³. It is not derived from a persons name, like Joule or Pascal so must be written like metre, tonnes, or gram with a lowercase initial letter. It is not the Wikipedia way to take a POV, and canvas to have it established through polling users, and on the strength of that make a global change. The Wikipedia way is to reference an authoritative source. Nearest at hand was the Style Guide. THe Economist. 2005. p. 200. ISBN 1861979169. Petrol and all liquid capacity is measured in litres- and bottled beer in UK in 500ml bottles and is not legal unless marked that way.

Delving deeper, I find this explanation.

The litre, and the symbol lower-case l, were adopted by the CIPM in 1879 (PV, 1879, 41). The alternative symbol, capital L, was adopted by the 16th CGPM (1979, Resolution 6; CR, 101 and Metrologia, 1980, 16, 56-57) in order to avoid the risk of confusion between the letter l (el) and the numeral 1 (one).

"The International System of Units (SI)" (PDF). www.bipm.org. 2006. p. 124. Retrieved 19 February 2021.

So you youngsters may believe that uc L is an acceptable alternative, but anyone I have taught won't accept it, or us wrinklies. If the lc l could be confused, then write it out in full or use cubic decimeters instead. Please revisit this in 2161 but keep on smiling. ClemRutter (talk) 01:48, 19 February 2021 (UTC)

As you stated, "The alternative symbol, capital L, was adopted by the 16th CGPM (1979, Resolution 6; CR, 101 and Metrologia, 1980, 16, 56-57) in order to avoid the risk of confusion between the letter l (el) and the numeral 1 (one)." Given that it is after 1979, using "L" is a perfectly acceptable alternative. Thanks for finding the loophole. BilCat (talk) 02:11, 19 February 2021 (UTC)

• Regulars here will be unsurprised at my interjecting, at this point, the criteria given at Wikipedia:If MOS doesn't need a rule on something, then it needs to not have a rule on that thing, to wit, that something belongs in MOS only if (as a necessary but not sufficient test) either:

1. There is a manifest a priori need for project-wide consistency (e.g. "professional look" issues such as consistent typography, layout, etc. – things which, if inconsistent, would be significantly distracting, annoying, or confusing to many readers); or
2. Editor time has been, and continues to be, spent litigating the same issue over and over on numerous articles, either:
   1. with generally the same result (so we might as well just memorialize that result, and save all the future arguing), or
   2. with different results in different cases, but with reason to believe the differences are arbitrary, and not worth all the arguing – a final decision on one arbitrary choice, though an intrusion on the general principle that decisions on each article should be made on the Talk page of that article, is worth making in light of the large amount of editor time saved.

So if I may, before we proceed I'd like to ask for evidence supporting either (1) or (2) i.e. evidence that the merely suggestive (not prescriptive) language we have now ...

The symbol l (lowercase "el") in isolation (i.e. outside forms as ml) is easily mistaken for the digit 1 or the capital letter I ("eye").

is inadequate. EEng 05:49, 19 February 2021 (UTC)

For as long as people use ml/L it's inadequate. Mosnum should at least make clear that the same symbol for litre should be used throughout any one article. Dondervogel 2 (talk) 08:57, 19 February 2021 (UTC)

Have you discussed the issue with the editors of that article? EEng 09:21, 19 February 2021 (UTC)

It was discussed by MOSNUM editors in the link you posted, where it was stated that "ml/L" was perfectly acceptable. I will take it up at the article if and only if we agree here that such ridiculous and confusing notation is unacceptable. Dondervogel 2 (talk) 10:02, 19 February 2021 (UTC)

For reasons explained in the essay I linked a bit ago, it's highly useful for discussion to start in the context of actual articles. In my experience useful arguments are often uncovered that way which would otherwise go unthought in abstract discussions here. EEng 10:24, 19 February 2021 (UTC)

I understand the argument. I'm just giving notice that I do not intend to fight the nonsense without consensus here that it IS nonsense. Life is too short Dondervogel 2 (talk) 11:26, 19 February 2021 (UTC)

So you'd rather argue it in the abstract than hear from editors who are likely to be familiar with actual sources and actual usage in the real world. Noted. [Sorry, that last bit was snarky. My apologies.] EEng 02:31, 28 February 2021 (UTC)

Your post lacks your usual sharp reasoning:

1. There is no need for the discussion here to be abstract. It just helps holding it at one central location.

2. You imply I am unfamiliar with sources. I know from my own experience that some use "l" while others use "L". No serious science editor (in the real world) would sanction a mixture. We should not either.

Dondervogel 2 (talk) 07:57, 28 February 2021 (UTC)

The doctors took away all my sharp reasoning for fear I'll harm myself. Look, I'll just say it again. I don't think anyone here would care if you took 30 articles with ml/L and changed them to mL/L. Then if you wait a few days, you might get 5 inquisitive editors of those articles engaging you about it. Maybe all of them will see it your way, and you can go on changing another 50 articles, and so on, with no shots fired. Or maybe one or two object, and even have some reason you haven't heard of or thought of, or a reputable source that really does that. Talk to them about it. Maybe they'll come around. Or not. Then come here, and bring them with you. Those are the people we need in this discussion. EEng 12:41, 28 February 2021 (UTC)

Apologies not really needed (I know from experience you mean well) but gratefully accepted. I'll think about your suggestion. Dondervogel 2 (talk) 12:53, 28 February 2021 (UTC)

So I wasn't really asking for people to give their opinions on the answer to the question, just on how the question should be asked. But given there was support for the "written out" option and it's mentioned as a common solution on Litre#Symbol, I added that. "ℓ" is also mentioned there, so I'm throwing that in as well. So how about this: (Beland (talk) 20:19, 20 February 2021 (UTC))

Options

(EDITED BASED ON SUGGESTIONS BELOW)

The Manual of Style currently allows the use of "litre", "liter", "l", or "L", with a note that says: The symbol l (lowercase "el") in isolation (i.e. outside forms as ml) is easily mistaken for the digit 1 or the capital letter I ("eye").

How would you rank the following options?

• Option A - No change.
• Option B - Always use "L", including with ("mL") and without ("L") prefixes, to reduce confusion.
• Option C - Use "L" without a prefix to reduce confusion. Never mix "l" and "L", with or without prefix, in the same article. For example write mL/L and 1000 mL is 1 L instead of ml/L and 1000 ml is 1 L. E.g. "ml" is OK if "L" does not appear in the same article.
• Option D - Write out "liter" or "litre" to avoid confusion, where "l" would otherwise be used without a prefix. Follow WP:ENGVAR.
• Option E - Use "ℓ" to avoid confusion where "l" would otherwise be used without a prefix.
• Option F - Always use "l", including with ("ml") and without ("l") prefixes.

Discussion

For litres (not millilitres) {{convert}} seems to be used with "L" over "l" only about 56% to 44% in the February 1 database dump, but in free text just looking at well-spaced contexts, it's 6% "l" to 94% "L". Given that the warning has arguably dissuaded some but not all use of "l", whether it is adequate depends on how acceptable you find "l" in various contexts. -- Beland (talk) 20:19, 20 February 2021 (UTC)

• Any option that discourages a mix is OK by me. In particular, either of B and C from this list would be an improvement on what we have now. Option C can be improved further by also discouraging mL/l. Option E would make things worse because only the symbols L and l are accepted by the BIPM. Dondervogel 2 (talk) 00:02, 21 February 2021 (UTC)

  C would not allow "mL/l" because the denominator doesn't have a prefix; it would have to be "mL/L". -- Beland (talk) 03:32, 21 February 2021 (UTC)

• B - Use 'L' always. It is allowed by BIPM and is not mistaken for the number one or lowercase ell. Option A is putting our head in the sand. Option C (mix of ml and 'l') is yet another convoluted rule to remember - why bother? Option D often turns into an edit war if the article doesn't have any other instances of litre/liter, metre/meter, colour/color to base WP:ENGVAR on (I'm thinking of Japanese car articles). Option E is just so damn hard for the majority of editors to enter that it will never work in practice (technically it is just a font choice of the BIPM sanctioned lowercase ell, so it gets a lot of use on supermarket product labels).  Stepho  talk  00:59, 21 February 2021 (UTC)
• Once again, I wasn't asking people to answer the question yet, just making sure the question was phrased coherently before advertising the RFC. -- Beland (talk) 03:32, 21 February 2021 (UTC)

  The questions are fine - they cover the major bases. Let's start the RFC rolling.  Stepho  talk  04:43, 21 February 2021 (UTC)

  The question can be improved: I'd like to see an option like B, but for lower case only (plain l, not that silly curly font); and option C does not rule out mL/l, but IMO it needs to. Dondervogel 2 (talk) 09:34, 21 February 2021 (UTC)

  I added a new option F to address the first; and an option C2 to replace C. Dondervogel 2 (talk) 15:53, 21 February 2021 (UTC)

  C was intended to be the same as C2; I've unified them with more examples. Hopefully I didn't mess up the meaning? -- Beland (talk) 19:46, 21 February 2021 (UTC)

  Yep, you closed the loophole. Dondervogel 2 (talk) 21:00, 21 February 2021 (UTC)

• It seems to me that there is a missing option G, which is to say explicitly that mixing L and ml is OK, as long as it's done consistently in an article. That would be my preference. In the absence of that, I suppose I'd pick A, no change. --Trovatore (talk) 07:48, 28 February 2021 (UTC)

  Plus, by adding G we would open ourselves to the entire spectrum of musical notes–based ABCDEFG wordsmithing, with words like BAGGAGE, CABBAGE, FEEDBAG, and many more possible. (Handy words for traveling and dining, those are.) Or, restricting ourselves to rankings (with each option appearing at most once), people can select from DECAF, CAGED, FAG (sorry), FACED, BEAD, AGED, and (my favorite) EGAD. EEng 21:51, 28 February 2021 (UTC)

• Sorry I'm late to the party. Having read through this discussion and the RfC below I'm left wondering why use of the {{litre}} template hasn't been suggested. It would be pretty straightforward to add to the fonts it uses, such as Noto Sans JP, Source Sans Pro, PT Sans, Ubuntu or Nunito, etc., assuming that a simple @import tag can be implemented in the WP stylesheet. It may also be possible to amend the template so that screen readers read out the word litre in full, although I'm not sure how that works. nagualdesign 02:52, 4 April 2021 (UTC)

..I posted a query at Wikipedia talk:Skin#Additional fonts. nagualdesign 03:09, 4 April 2021 (UTC)

Litre abbreviation RFC

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There is consensus to not use "l" (lowercase L) to abbreviate liters. User:力 (power~enwiki, π, ν) 18:43, 3 April 2021 (UTC)

Of the six options presented, options C E and F can be immediately rejected. Option E (script "ℓ") received no support, Option F is clearly less popular than either A or B, and while there is support for avoiding mixed usage, the specific rule in Option C did not find support. Option D (to always write out "liter/litre") had some support, but consensus is that this is not reasonable in equations and tables where display space is limited. It is noted that nothing in the proposal requires the use of an abbreviation where spelling out a unit makes more sense editorially. A follow-up proposal for always writing out liter/litre in running text could be made.

As Option A is the status quo, this leaves Option B as the potential change to assess. The numerical vote is roughly 12-8 in favor of B (with two votes for option D and one vote for option C). The argument for B is primarily that it will avoid confusion with uppercase "I" and number "1". The arguments against B are threefold. The first is an argument against MoS guidances at all. The second is an ENGVAR argument. The third is that while "l" for litre should be discouraged, other abbreviations such as ml should be used. Regarding ENGVAR, capital L is not just an "Americanism", but is permissible everywhere and widely used outside of Europe; furthermore editors can still spell out litre in running text. As the third argument notes that lowercase "l" is confusing (as well as the voters for C and D), I find there is consensus to stop using a standalone "l" for litres.

Regarding the use of "ml", opinion is more evenly split. The specific construction "ml/L" (milliliters per liter) has both explicit support and strong objections. I do not see consensus to prohibit all uses of "ml" (or other derivative units) here. User:力 (power~enwiki, π, ν) 18:43, 3 April 2021 (UTC)

---

Should English Wikipedia stop using "l" to abbreviate litres in some or all cases? -- 04:14, 25 February 2021 (UTC)

The Manual of Style currently allows the use of "litre", "liter", "l", or "L", with a note that says: The symbol l (lowercase "el") in isolation (i.e. outside forms as ml) is easily mistaken for the digit 1 or the capital letter I ("eye").

How would you rank the following options?

• Option A - No change.
• Option B - Always use "L", including with ("mL") and without ("L") prefixes, to reduce confusion.
• Option C - Use "L" without a prefix to reduce confusion. Never mix "l" and "L", with or without prefix, in the same article. For example write mL/L and 1000 mL is 1 L instead of ml/L and 1000 ml is 1 L. E.g. "ml" is OK if "L" does not appear in the same article.
• Option D - Write out "liter" or "litre" to avoid confusion, where "l" would otherwise be used without a prefix. Follow WP:ENGVAR.
• Option E - Use "ℓ" to avoid confusion where "l" would otherwise be used without a prefix.
• Option F - Always use "l", including with ("ml") and without ("l") prefixes.

Previous inconclusive discussions:

• Wikipedia talk:Manual of Style/Dates and numbers/Archive 157#Decide on “l” vs “L” for litre (liter).
• Wikipedia talk:Manual of Style/Dates and numbers#L is for liter

-- Beland (talk) 04:14, 25 February 2021 (UTC)

• Prefer B; C is OK. D is too cumbersome when space is limited, but would be better than A. E and F would make things worse by being non-ASCII and more confusing, respectively.
  • "L" was added in 1979 to the SI system by the CIPM precisely because of these typographical issues. (See Liter#Symbol.) Some major institutions already use "L" exclusively, including NIST and some international scientific journals. CIPM may in the future deprecate "l".
  • Confusion of "l" does happen in practice. Wikipedia's use of a sans-serif font by default makes "l" after a number look like a one, especially if there is no space before the "l". With a space, it can still look like a one after a decimal space or implied multiplication or a typo. "l" is also indistinguishable from "I", which is used to represent electrical current, dynamic action, sound intensity, and moment of inertia.
  • While readers can usually figure out the meaning from context, it impedes Wikipedia's mission to be unclear and inconsistent and create a speedbump puzzle for students and people unfamiliar with the metric system.
  • A blanket rule to use "L" in all cases removes all the guesswork and is easy to enforce in a semi-automated fashion.
  • What's the downside? Some people say "mL" looks weird, but others say "ml" looks weird, and I think it just depends on what you saw more growing up. English Wikpedia readers from all countries currently encounter both in articles without restriction to any particular national variety of English. If Wikipedia consistently uses "L" and "mL", in the long term maybe that will begin to "look normal" to everyone, but much more importantly fewer readers will be confused by "l".
  • This doesn't make the Manual of Style longer; it's actually streamlining by changing a warning we have to think about in each case, to a guideline we just have to implement.

  -- Beland (talk) 04:14, 25 February 2021 (UTC)

• Prefer B. Lowercase l looks too much like a 1 in too many likely font choices. (In the ones I use, they are very different in preview, but I still can't tell I from l from | in preview, and I can't tell l from 1 in the edit source window.) If it's an official part of SI then it's an acceptable choice, and for typographic reasons the lowercase versions are not. —David Eppstein (talk) 05:11, 25 February 2021 (UTC)
• Prefer A, followed by F and D. The context almost always makes this clear, and it can be written out when needed. Doremo (talk) 05:24, 25 February 2021 (UTC)
• I can live with B, C or F. All other options are poor. Between these, I prefer to adopt a single WP-wide symbol for the litre, so my preferred options are B and F, with a preference between these for B for the reasons stated by others. My third choice is C because it deprecates bizarre combinations like “ml/L", thus improving on the present guidance. A is unacceptable because it permits "ml/L"; D is impractical because there are times when a unit symbol is needed (eg, in an equation). I guess that leaves E as just acceptable. On these grounds it becomes a (poor) fourth choice. To summarise

  1. B

  2. F

  3. C

  3. C (or Option A if modified to exclude mixture of l and L in the same article)

  4. E

• Dondervogel 2 (talk) 07:46, 25 February 2021 (UTC)

  I've just realised that Option E would permit all kinds of combinations, including ml/L, making it unacceptable to me. Dondervogel 2 (talk) 13:00, 25 February 2021 (UTC)

  The strikeout falling right on the middle arm of the E is a delicious touch. EEng 22:46, 25 February 2021 (UTC)

  LOL. Unlike I from l, E is (just) distinguishable from E. Dondervogel 2 (talk) 23:22, 25 February 2021 (UTC)

  Per my recent exchange with Peter coxhead, I would find Option A acceptable if it were modified to exclude a mixture of l and L in the same article. This would rank equally alongside Option C. Dondervogel 2 (talk) 09:52, 28 February 2021 (UTC)

• Option A – None of the others are acceptable to me. I'm not confused by 'ml' and 'L' used together (although 'ml' and 'mL' together probably should be deprecated), and I don't expect others to be confused. Besides, if you really want to make your meaning clear, you employ wiki-links or "convert" templates. Dhtwiki (talk) 09:40, 25 February 2021 (UTC)
• Option B as unambiguous. If we must have A, then the existing rubric needs extending so that it says The symbol l (lowercase "el") in isolation (i.e. outside forms as ml) is easily mistaken for the digit 1 or the capital letter I ("eye") and consequently should never be used. --John Maynard Friedman (talk) 11:20, 25 February 2021 (UTC)
• 🯁🯂🯃42 ...and what was the question ? --:GSMC(Chief Mike) Kouklis U.S.NAVY Ret. ⛮🇺🇸 / 🇵🇭🌴^⍨talk 15:23, 25 February 2021 (UTC)
• I'm still waiting for evidence that editors aren't working out this issue (if an issue it is) for themselves on article talk pages, or that such discussions are wasting time that would be saved by adding to the guidance here. Editors actually working on articles where the question arises are the best people to comment on such issues, and there are none such present here, AFAICS. EEng 19:49, 25 February 2021 (UTC)

  Well, if I went ahead and systematically changed all instances of "l" to "L" because I think that's universally clearer, I'm confident a bunch of editors would object (either in general or for the articles they are watching) and ask me to get consensus for such a change first. It would be a bit disruptive and potentially a waste of time to change a bunch of articles only to potentially change them back, for the sole purpose of proving there's a dispute. While a manual of style may be useful for settling disputes between employees (or in this case volunteers), in professional publishing they are also used to ensure visual consistency of arbitrary choices and to document best practices that copy editors should enforce. Here I'm not trying to settle active disputes, I'm trying to increase clarity; but first I need agreement that lack of clarity is actually a problem and that this is an acceptable solution. Option B doesn't "add" guidance in the sense of making the MOS longer; it would actually make it shorter. -- Beland (talk) 09:05, 7 March 2021 (UTC)

  Option B doesn't "add" guidance in the sense of making the MOS longer – No, but it adds guidance in the sense of telling editors what to do instead of letting them decide among themselves on particular articles. EEng 10:34, 7 March 2021 (UTC)

  Precisely, and that is the purpose of mosnum. Dondervogel 2 (talk) 11:19, 7 March 2021 (UTC)

  Where necessary, not for its own sake. EEng 11:51, 7 March 2021 (UTC)

  Indeed, not for its own sake, but for the sake of "clarity and cohesion ...[especially] within an article". Dondervogel 2 (talk) 12:27, 7 March 2021 (UTC)

  If and where guidance is needed to achieve that. EEng 05:47, 13 March 2021 (UTC)

  No need to be hypothetical here. I once tried doing what Beland suggests. I was immediately reverted. Dondervogel 2 (talk) 10:15, 7 March 2021 (UTC)

  And did you engage those editors in a discussion to elicit their reasons for preferring a particular style? That might be useful information to have here in this discussion. EEng 10:34, 7 March 2021 (UTC)

  I believe the editor concerned preferred to follow the sources that use ml (disregarding those that follow mL?), and was willing to sacrifice uniformity to achieve that. There are plenty of editors already here arguing precisely that, so adding one more would not change things. Dondervogel 2 (talk) 11:19, 7 March 2021 (UTC)

  Editors with skin in the game are often more effective advocates. EEng 11:51, 7 March 2021 (UTC)

  That particular editor was one who would resort to bullying, sometimes in alliance with a known sockmaster, to get his way. Not someone we'd want contributing to a civil discourse. Dondervogel 2 (talk) 12:25, 7 March 2021 (UTC)

  OK, well how about the next article editor you engaged on this issue? EEng 20:40, 7 March 2021 (UTC)

  I recall a discussion here. Many years ago. Before the one you mentioned. I wouldn't know how to find it though. How about pinging the editors in the discussion you found? Dondervogel 2 (talk) 20:44, 7 March 2021 (UTC)

  I found this snapshot on 25 July 2008. Does that help us track down the archive? Dondervogel 2 (talk) 21:02, 7 March 2021 (UTC)

• Option A - to leave it alone - is far preferable to all alternatives. Per Litre#Symbol, this is a case where usage genuinely varies between countries. That means, if we have to have a firmer rule, then we need to go down an WP:ENGVAR-type route. If we mandate obscure Unicode characters as in E, we'll be ignored. There will always be cases where a symbol is needed (i.e. where space is limited) so D is inappropriate. The others inappropriately mandate uniformity. Kahastok talk 20:34, 25 February 2021 (UTC)

  FTR, I do not object to Option G, advising against mixing L and l in the same article without requiring one or the other. Per User:Peter coxhead, this is not the same as option C. Kahastok talk 12:04, 7 March 2021 (UTC)

• I'm am still waiting for referenced sources, from the editors that regular use litres to add a little expert guidance. ClemRutter (talk) 20:38, 25 February 2021 (UTC)

  BIPM permits "L" or "l". NIST requires "L". What more do you need to know? Dondervogel 2 (talk) 22:18, 25 February 2021 (UTC)

• Option A Requiring B will never work with the many people used to lower case—this is a collaborative community of volunteers, not a bunch of paid hacks who take orders from on high. Encouraging Engvar wars is not useful. Johnuniq (talk) 23:04, 25 February 2021 (UTC)

  @Johnuniq: Engvar does not permit constructions like "The honor of modelling aluminum behaviour", and for good reason. Option A permits writing ml/L for millitre per litre. Why is mixing OK for the litre but not for Engvar? Dondervogel 2 (talk) 23:16, 25 February 2021 (UTC)

  Show me a page with mL/l and I'll correct it. We are allowed to use common sense. Johnuniq (talk) 23:29, 25 February 2021 (UTC)

  Bigeye tuna

  Murashige and Skoog medium

  Sea toad

  Wastewater discharge standards in Latin America

  Blue cod

  They're not all of the form "ml/L", but they do all mix l and L in some way. I expect there are many more. Dondervogel 2 (talk) 23:53, 25 February 2021 (UTC)

  We do lots of things that some people aren't used to and never write, like straight ' and ". It's not a problem for a second editor to come along and make a contribution MOS-compliant (and there are volunteers willing to do that), as long as the first editor doesn't change it back. I'm not sure if that's what you're saying will happen, or that people just won't bother to write MOS-compliant text up front? -- Beland (talk) 02:03, 26 February 2021 (UTC)

  @Beland: If they were non-compliant I would fix them myself. The problem is they comply. My purpose is to encourage a change to MOSNUM to make them non-compliant. Dondervogel 2 (talk) 09:00, 26 February 2021 (UTC)

  @Dondervogel 2: Sorry, I was replying to Johnuniq's original comment. -- Beland (talk) 00:24, 27 February 2021 (UTC)

  I moved the full list further down, leaving only the original 5 examples. Dondervogel 2 (talk) 09:49, 27 February 2021 (UTC)

• Prefer B+D, ie use 'L', 'litre' or 'liter' but never 'l'. Option A has too much scope for ambiguity. Option B is legal everywhere (even for those countries like mine that were taught to use little ell back in the 1970s - if we can understand colour/color, litre/liter, autumn/fall then this is nothing). Option C is too complicated for many of our editors (which is a sad commentary but true). Option D should be allowed as an alternative to B (WP:ENGVAR works like it has done for years) . Option E is good for reading but the average editor still struggles with entering hyphens, let alone other symbols. Option F has too much scope for ambiguity.  Stepho  talk  07:26, 27 February 2021 (UTC)

• Prefer B+D, per Stepho-wrs. Seems reasonable to me. BilCat (talk) 23:28, 27 February 2021 (UTC)

• Option B (and D as an acceptable alternative) - it leaves no room for confusion. -- Carlobunnie (talk) 00:52, 28 February 2021 (UTC)
• Option A with a requirement to not mix within an article is my preference, as per Johnuniq. Peter coxhead (talk) 08:15, 28 February 2021 (UTC)

  @Peter coxhead: What's the difference between 'Option A with a requirement not to mix' and 'Option C'? Dondervogel 2 (talk) 08:46, 28 February 2021 (UTC)

  @Dondervogel 2: the status quo allows the use of "l" without a prefix so long as it's clear; Option C does not. Text like Its volume is about 6.7 L (1.5 imp gal; 1.8 US gal) is perfectly clear and hence acceptable in my view. Peter coxhead (talk) 09:38, 28 February 2021 (UTC)

  Thank you for explaining. I agree that consistent use of "l" throughout an article is acceptable, which is why I am also OK with option F. Perhaps the option you favour (explicitly ruling out the mixture) should be added to the list. Dondervogel 2 (talk) 09:49, 28 February 2021 (UTC)

• Option A. There is nothing wrong with ml/L. --Trovatore (talk) 19:24, 28 February 2021 (UTC)
• Option B – if "L" is acceptable per SI, and results in less confusion, which seems really clear to me because I frequently struggle with glyphs that look similar, like - (hyphen-minus) − (minus sign) – (en-dash) — (em-dash), then let's standardize on the least confusing acceptable option. —Joeyconnick (talk) 18:44, 6 March 2021 (UTC)
• Option B When comparing "1 l" with "1 L" out of context, the lowercase "l" can lead to confusion with the numeral "1" for certain fonts, and so the capital letter "L" is used. To keep things consistent, adding a prefix, such as "milli", should not change the unit symbol. The SI Brochure (9th edition) shows that both "l" and "L" are accepted. The unit symbols are lowercase letters unless they are derived from a proper name, but an exception for "L" was made by the CGPM in 1979. However, in the United States, the use of "mL" is preferred by NIST and the FDA. It seems like the CIPM's recommendation of using SI units rather than liters may explain their indifference between "l" and "L". Somerandomuser (talk) 03:16, 7 March 2021 (UTC)

  Units and measurements on Wikipedia are very rarely - if ever - provided without context. MOS:UNITNAMES says that the first few instances of measurements in litres in prose should be spelt out in prose. We also mandate that a non-breaking space be used between a number and the unit symbol. Plus, in our default font used by the vast majority of our readers, the "l" and "1" are pretty easily distinguishable. The likelihood of genuine confusion is minimal.

  Meanwhile, upper-case "L" and "mL" are unusual enough to look jarring in significant parts of the English-speaking world. Arguing for NIST is not convincing in areas outside the United States where it is just another foreign national standards body. Kahastok talk 12:02, 7 March 2021 (UTC)

• I've already posted these examples in the other section below, but I would like some opinions on some interesting cases used in medicine. These units can be found in charts as well. The units for measuring human chorionic gonadotrophin (hCG) levels, thyroid-stimulating hormone (TSH) levels, or other hormone levels: mIU/ml or mIU/mL (milli-international units per milliliter). See also IU/l or IU/L and mU/ml or mU/mL. The units for measuring blood mean platelet volume: fl or fL (femtoliters). The "fl" is also used as "fluid" in "fl oz". What should be done for these cases? Somerandomuser (talk) 06:20, 15 March 2021 (UTC)

  Present advice for fluid ounce is to use either "US fl oz" or "imp fl oz" (not "fl oz"). When written like this it's hard to see fl being read as femtolitre. Dondervogel 2 (talk) 08:15, 15 March 2021 (UTC)

• Option B, although I think 'liter' is acceptable too. I just think we should get rid of "l" since it can be confused with I, I guess that would make D acceptable too. Eccekevin (talk) 03:40, 9 March 2021 (UTC)
• Option D - per making Wikipedia more accessible to our visually impaired readers and editors. Screen readers (at least mine) do not recognize the letter L, upper or lowercase, as an abbreviation for liter. Other abbreviations like ml. kg. km. etc. are recognized by a screen reader, but only if the period is included, otherwise it just reads as letters. Isaidnoway (talk) 19:12, 12 March 2021 (UTC)

  I'm sorry, but this makes no sense at all. I'm sighted, and my browser doesn't recognize the letter L, upper or lowercase, as an abbreviation for liter. All I see is the naked letter, and I have to know that it means liter. So you're on exactly the same footing as everyone else. EEng 20:02, 12 March 2021 (UTC)

  I think the point is that "500 l" or "500 ml" exist in real life text. So, if you're in a place where those symbols are used, you'll interpret them easily because you're used to seeing them in that context. The problem for a person with a screen reader is that basically nobody ever refers to "500 litres" in speech as "five hundred ell". Kahastok talk 20:29, 12 March 2021 (UTC)

  A screen reader isn't supposed to be imitating speech; it's supposed to read out what's on the screen. EEng 05:47, 13 March 2021 (UTC)

  Ideally, it should read out the screen in a way that is readily understandable to the user. That is inevitably going to imitate speech. Otherwise, why not just have it spell out all the words? Don't get me wrong, I accept the argument that says that writing out literally every instance of the unit is unworkable in practice. But it's worth bearing in mind that our guidance already says to write out the unit in most situations. Kahastok talk 11:26, 13 March 2021 (UTC)

  Spelling them out in full each time is ok for text but gets unwieldy in tables and infoboxes. This would make the each entry in the {{{engines}}} field in {{infobox automobile}} overflow to 2 lines in many car articles. Stepho  talk  22:29, 12 March 2021 (UTC)

• Option D. I would prefer to see most, if not all, units spelled out. Avoiding any potential confusion is well worth the extra characters it takes to do so. -- Calidum 19:43, 12 March 2021 (UTC)

  Surely you jest. EEng 20:02, 12 March 2021 (UTC)

  How dare you call me Shurley! Dondervogel 2 (talk) 20:09, 12 March 2021 (UTC)

• [1] EEng 20:26, 12 March 2021 (UTC)

• Option B. There's a reason why it was added to the official standards and why most scientific contexts have adopted it exclusively. And this is not some recent change. The 70s were half a century ago. Heck, even the bottle of Coca-Cola sitting next to me uses "500 mL". The use of lowercase for liters is properly considered archaic. The idea of using a script lowercase l is also objectionable on lack of ease of input, and again, the modern standards call for an uppercase L; the cursive lowercase is even more archaic. As for spelling out, it seems good in theory, except the whole ENGVAR thing and the principle of WP:COMMONALITY. Why introduce additional places where there can be spelling issues, especially for a unit so common that even Americans use it daily (see, again, Coca-Cola or any hard liquor, the one area that has been fully metricized). Nah, just keep it simple. Use the modern standard: L for liter. oknazevad (talk) 11:01, 13 March 2021 (UTC)

  Which suggests that you're based in North America or Australia. Coke bottles and other drinks bottles in Britain and Ireland say "500 ml", with a lower case l. This isn't "archaic" any more than it's "archaic" to spell it as "litre". It's just different standards in different places. Kahastok talk 11:26, 13 March 2021 (UTC)

• Option C, which resolves the central matter of avoiding a single ‘l’ whilst not forcing unnecessary article change in the many uses of cl, ml, etc. in lower case, which remains standard usage in much of the world. Minimising the extent of change to resolve the key concern should be a criterion when considering any change to the MoS. I don’t give too much weight to concern about understanding, since if that were the criterion then the MoS would say next to nothing about punctuation. The important thing is that whatever we write is as clear as possible, so that it is understood when cited. Incidentally, if we can turn the clock back, the mistake was using a single letter; it would have been better if litre(s) were lt. MapReader (talk) 06:54, 15 March 2021 (UTC)
• Option B Should be the preferable option.Sea Ane (talk) 11:48, 18 March 2021 (UTC)

WP:NOTVOTE MapReader (talk) 07:46, 20 March 2021 (UTC)

• Of the proposed options, I'd agree most with B, as WP is (within reason) entitled to choose to standardise on formats based on its need to communicate information unambiguously. We're not proposing any innovation or deviation from the relevant international standards; indeed, standardising on one symbol for the litre is perfectly compatible with BIPM guidance, and it is entirely representative of the practice of reputable reference publications – I'd argue more so than allowing a hodgepodge mixture of "l" and "L", which is unnecessary and IMHO unprofessional. I see ENGVAR as irrelevant, since we are discussing international mathematical symbols that do not form part of any natural human language, let alone specifically English, let alone specific dialects of English. Some sort of de facto rule amounting to "use l and L according to the relative frequency of their use" (i.e. the situation we are in without standardising) is needlessly overcomplicated and sacrifices unambiguity to a chimerical notion of neutrality. I do not think that compromise is warranted. Archon 2488 (talk) 11:08, 22 March 2021 (UTC)

  You need an exceptionally narrow definition of "natural language" to argue that the word or symbol for litre is not natural language. People in metric-using countries speak and write them all the time, including dialect-specific features like pronouncing "ml" as "mill". User:GKFX^talk 15:47, 27 March 2021 (UTC)

• Prefer A Per NIST, "both l and L are internationally accepted symbols for the liter, to avoid [the ambiguity] the preferred symbol for use in the United States is L." As such enforcing the capital L would be an Americanism, and the whole point of WP:ENGVAR is that all common forms of English are permissible. Consistency within each article is good, but the aim for consistency is again something covered by ENGVAR (and common sense). I oppose E, F on respectively the NIST guidance cited and the same argument as above that UK English should not be favoured either. User:GKFX^talk 15:47, 27 March 2021 (UTC)

  If the use of capital L was purely a stylistic thing then, yes, it would be an Americanism. But it serves a very real purpose of avoiding a point of ambiguity for all readers and hence is not an Americanism at all. Note: I'm not American and usually argue against Americanisms.  Stepho  talk  16:04, 27 March 2021 (UTC)

  Option A does not require consistency. There are MOS-compliant articles that mix l and L in the same article and others that mix them in the same unit symbol (ml/L). This makes Option A unacceptable to me. I can accept it if it is modified to require consistent use of l or L within an article. Dondervogel 2 (talk) 16:13, 27 March 2021 (UTC)

• Option A. Why reduce flexibility? It could be tightened, as Dondervogel 2 suggests, but I see no advantage to forcing everyone to use "L" and "mL" in all circumstances. In "ml", what can the "l" possibly be confused with? Is there an "m1" (em-one) that has meaning to someone? Option B would prohibit the use of the word "litre"/"liter" after a numeral, which would be a bizarre restriction. EddieHugh (talk) 15:20, 2 April 2021 (UTC)

  Two points:

  Option A permits mixing l and L in the same article, which is undesirable. (Example: "during the experiment, 500 ml of water were poured into the bottle (capacity 1000 mL), thus half filling it").

  The RFC is about which symbol to use if a symbol is used, not whether to use a symbol. None of the options would prohibit spelling out the unit name in full.

  Dondervogel 2 (talk) 15:33, 2 April 2021 (UTC)

Your first point: that's why I supported your proposal (also made by others above) to require consistency within an article. Your second point: that doesn't appear to be how several people here are interpreting it (hence the suggestion to have a B-D combination, and 'Always use "L"' in the description of B supports the idea that using the word would not be permitted). EddieHugh (talk) 17:30, 2 April 2021 (UTC)

The entire table is about what unit symbol to use IF a symbol is used. If others interpret it differently, they misunderstand the purpose of the table. Dondervogel 2 (talk) 21:13, 2 April 2021 (UTC)

The table states that "long ton" should be written "long ton"; "carat" should be written "carat", etc.... Anyway, let's move on. EddieHugh (talk) 21:53, 2 April 2021 (UTC)

References

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

Litre abbreviation examples

Dondervogel 2 provided some interesting examples where l and L are mixed: Bigeye tuna • Murashige and Skoog medium • Sea toad • Wastewater discharge standards in Latin America • Blue cod. I had been confident that mixing was obviously wrong but now I'm very unsure. From the first link, compare "oxygen content is below 1.5 ml/L" with "oxygen content is below 1.5 ml/l" or "oxygen content is below 1.5 mL/L". In the second link, changing the subheadings to "Major salts (macronutrients)/ 1l" gives an awful result but "1,650 mg/l" is correct for many people. On reflection, I would leave these for editors maintaining the articles to manage (although the Blue cod example needs a simple consistency fix). The standards body probably allows l or L for reasons similar to Wikipedia's ENGVAR pragmatism. In medicine, it is essential that doses be unambiguous and I believe L is often used for that. Yet a large number of people trained in other science areas are used to lower case and consistency should give way to the reality of a volunteer community. I'm posting here to invite opinions on these specific examples. Johnuniq (talk) 02:32, 26 February 2021 (UTC)

• BIPM originally preferred "l" because (like the metre (m) and unlike the newton (N)) the litre is not named after a person. When people complained that "l" could be confused with "I" an exception was made to permit "L" for this one unit. Aberrations like "ml/L" were never intended.
• I fixed example two by spelling out "per litre" in full

Dondervogel 2 (talk) 07:29, 26 February 2021 (UTC)

Aberrations like "ml/L" were never intended – How do you know? It seems quite natural to me. EEng 20:31, 27 February 2021 (UTC)

It stands to reason. The CIPM is driven by a desire to remove ambiguity. This is why there is one and only one symbol for 99 % of units (I know of just 2 exceptions). Permitting a mixture would result in some readers thinking that the symbols "l" and "L" represent different units. Who would benefit from that? And if the font in use does not distinguish between "l" and "1", it also would not distinguish between "ml" and "m1".

Having said this, regardless of the CIPM's intentions, using "L" only (Option B) is clearly permitted, as is using "l" only (Option F). These remain my first and second preferences, with C a close third.

Dondervogel 2 (talk) 20:54, 27 February 2021 (UTC)

Sure it stands to reason. And since it's clear that lots of apparently at least some high-quality sources apparently use ml/L, that apparently stands to reason too. Do you have any actual sources for the statement that ml/L was not "intended"? EEng 21:05, 27 February 2021 (UTC)

I know of no sources that state "ml/L" was not intended. I also know of no sources that use that combination, and I'm surprised to learn that you do. What sources are they? Dondervogel 2 (talk) 21:16, 27 February 2021 (UTC)

I was inferring from the discussion that the use we see in articles followed sources, and I should have made that clear; I've modified my post. EEng 02:31, 28 February 2021 (UTC)

It is tempting to observe that any source that used an abomination like that is ipso facto not a reliable source. --John Maynard Friedman (talk) 22:06, 27 February 2021 (UTC)

Some interesting examples would be the units for measuring human chorionic gonadotrophin (hCG) levels or thyroid-stimulating hormone (TSH) levels: milli-international units per milliliter (mIU/ml or mIU/mL). See also IU/l and mU/mL. Somerandomuser (talk) 03:50, 8 March 2021 (UTC)

The blood mean platelet volume is measured in femtoliters: fL or fl. Somerandomuser (talk) 04:10, 8 March 2021 (UTC)

List of examples

Blenders Pride

Examples are listed of articles in which "l" and "L" are mixed, or in which a (bare) lower case "l" is used as a symbol for litre. Feel free to add your own examples.

• Aldosterone-to-renin ratio
• Assessment of kidney function
• Beer in Canada
• Bigeye tuna
• Bitburger Brewery
• Blenders Pride
• Blood test
• Blue cod
• Bong Spirit Vodka
• Breastfeeding
• Calvert Extra
• Cardiac output
• Cuauhtémoc Moctezuma Brewery
• Cider in the United Kingdom
• Cirrhosis
• Citric acid
• Coca-Cola Vanilla
• Container-deposit legislation
• Container deposit legislation in Australia
• Crush syndrome
• Cup (unit)
• Customs declaration
• Diagnostic peritoneal lavage
• Donkey milk
• Drunk driving law by country
• Effective renal plasma flow
• Eosinophilia
• Estradiol
• Exercise intensity
• Fifth (unit)
• Filtration fraction
• Fluid ounce
• Gestational diabetes
• Glomerular filtration rate
• Glossary of winemaking terms
• Glossary_of_wine_terms
• Glucokinase
• Hemoglobin
• HIV and pregnancy
• Hyponatremia
• Ketamine
• Kingfisher (beer)
• Labatt Brewing Company
• Latent iron deficiency
• Loop diuretic
• Louis_XIII_(cognac)
• Lysogeny broth
• Metabolic syndrome
• Methanol
• Methylphenidate
• Minimum inhibitory concentration
• Mitsubishi Outlander
• Mother (drink)
• Mountain Dew
• Murashige and Skoog medium
• NEWater
• Olanzapine
• Olde English 800
• PAH clearance
• Pint
• Postpartum physiological changes
• Pregnancy test
• Ranson criteria
• Reference ranges for blood tests
• Renal blood flow
• Royal Stag
• Sea toad
• Shot glass
• Sinfire
• Sprite Zero Sugar
• Statin
• Urge (drink)
• Uric acid
• Urine sodium
• Wastewater discharge standards in Latin America
• Weir formula
• Zinc nitrate

Proposal: use 0o123 format for octal in a computing context

Should we change MOS:HEX to specify 0o123 for octal, in place of 0123? Octal#In_computers says:

Newer languages have been abandoning the prefix 0, as decimal numbers are often represented with leading zeroes [...] The prefix 0o [...] is supported by Haskell, OCaml, Python as of version 3.0, Raku, Ruby, Tcl as of version 9, PHP as of version 8.1 and it is intended to be supported by ECMAScript 6."

The leading zero notation "0123" has always been problematic, as any reasonable person would assume it means 123, but in fact it means 83. (It's also a source of fun bugs...[2]) If major programming languages are switching to "0o123" we probably should too. (For context, we are already using 0xFF and 0b11111111 notation.) The exception unless there is a strong reason to use some other notation would continue to apply. User:GKFX^talk 08:56, 12 April 2021 (UTC)

I'm a developer, but also an author. In my opinion, we should not necessarily follow notations used in programming languages (except for in programming examples in articles dealing with those programming languages), but instead follow more general notations as used in mathematics and normal prose. I always considered it extremely poor writing style (not only here, but also in independent publications) to use artifacts of programming languages in prose. It comes over as nerdy and as if the author could not express himself/herself in proper language. As we are an encyclopedia for everyone, not only for software developers, we cannot assume that the average reader is familiar with programming languages.

Examples:

• 111111112, 11111111b, 11111111bin, 11111111BIN
• 1238, 123o, 123oct, 123OCT
• 8310, 83d, 83dec, 83DEC, 83
• FF16, FFh, FFhex, FFHEX

--Matthiaspaul (talk) 18:51, 14 April 2021 (UTC)

Agreeing with Matthiaspaul, we shouldn't use the convention of a particular language (except within an article on that language) but use the standard mathematical notation. {{octal}} displays it well, taking a decimal input and displays it as octal with the subscript 8. {{octal|10}} gives 12₈. So perhaps a new template to display a given number with a given subscript. Something like {{base|10|8}} to display 10₈ .  Stepho  talk  23:48, 14 April 2021 (UTC)

I also agree with Matthiaspaul that the standard subscript notation is preferable to programming-language hacks that are not likely to be readable to non-programmers. —David Eppstein (talk) 01:33, 15 April 2021 (UTC)

I agree 50% with Matthiaspaul, because I've never seen the likes of 123o or FFh and find them hard to parse, and because the upper-case subscripts feel like an assault. I recommend the suffix approach, preferring 8310 because that convention extends to any base discussed anywhere, not just the ones associated with computing, but 83dec is clear enough too. Largoplazo (talk) 01:57, 15 April 2021 (UTC)

My answer to the main question is yes: we shouldn't use 0123 to specify octal numbers. 1238 is the clearest, but there's benefit to a format like 0o123 that doesn't involve subscripts. User:力 (power~enwiki, π, ν) 02:07, 15 April 2021 (UTC)

However, 0o123 is unhelpful in a general encyclopedia because every instance would need an explanation. Using "octal 123" would be better. Johnuniq (talk) 02:48, 15 April 2021 (UTC)

I created a new template {{base}}. {{base|4632|8}} yields 4632₈ . Perhaps this could be useful.  Stepho  talk  10:59, 15 April 2021 (UTC)

Nice, the best of all worlds (including the subscript-challenged one)! Largoplazo (talk) 11:12, 15 April 2021 (UTC)

Just thought of another use. {{base|F900|hex}} yields F900_hex and {{base|123|octal}} yields 123_octal . Although I prefer the 16 and 8 usage.  Stepho  talk  11:57, 15 April 2021 (UTC)

In my opinion, the benefit to avoiding subscripts is small in a medium where subscripts are easy to create and used routinely for the likes of H₂SO₄. Largoplazo (talk) 11:05, 15 April 2021 (UTC)

GKFX, would you happen to know of any nontrivial examples of computer-related articles where the currently prescribed notation is used? i was hoping to see how the format was currently used in wikipedia, but i could only find minimal instances of its usage, mostly as examples of how the notation is used in the relevant computer languages, although my search was admittedly not very thorough. dying (talk) 10:17, 14 May 2021 (UTC)

I couldn't actually find any so it may be that the guidance was just wrong. In any case I've updated the guidance based on the discussion. User:GKFX^talk 11:27, 14 May 2021 (UTC)

GKFX, i actually didn't think the previous guidance was incorrect, but simply not often used, assuming that it was necessary in the first place. i had been hoping that you could provide instances where your proposal would have changed the text of an article, since you were the one proposing the change.

admittedly, i think the changes you have made actually invite further confusion, since "computer-related articles" and "computer code samples" are not the same thing, and stating without qualification that one should "Avoid 0123 notation for octal" appears to be contrary to what one would assume would be best practice when referencing octal numbers in the context of languages that use that notation.

i may easily be wrong about this, but my interpretation of the discussion above led me to believe that there was no strong opinion on whether or not the guideline should change, since the discussion (or at least my understanding of it) did not really focus on "computer-related articles", which was a qualification that the previous guidance had on the usage of the prefix "0" for octal. also, i would have considered the attempt of providing proper computer code for a language that used "0o" to denote octals to be "a strong reason to use some [notation other than the '0' prefix]", so the previous guidance did not appear to preclude usage of "0o" in those instances anyway.

would you happen to know of any nontrivial examples of either computer code in article space or computer-related articles that currently use either the "0" notation or the "0o" notation for octal numbers? dying (talk) 13:33, 14 May 2021 (UTC)

Which is correct?

Which is correct, and why? When embedded in a sentence, "nine minutes and 29 seconds" or "9 minutes and 29 seconds". Thanks, WWGB (talk) 22:57, 13 April 2021 (UTC)

To my surprise there's nothing on this. Boldly added [3], subject to the approval of my esteemed fellow editors. EEng 02:27, 14 April 2021 (UTC)

But definitely not "9:29 minutes", a syntax I recently heard from a sports commentator whose native language was not English. —David Eppstein (talk) 04:09, 15 April 2021 (UTC)

Totally off-topic (also WP:NOTFORUM yadda yadda) but yesterday I was enquiring about some surgery I could do with and was told, "The cost of a consultation is £220.00 and surgery starting from £2,3080.00." (sic) So I wrote back, "Can you please confirm the cost of surgery? £23k seems excessive! Perhaps you meant £230.80?" To which she replied, "That is 2,3080.00 not 23k? Two thousand three hundred and eighty". Honestly, you just can't get the staff these days. nagualdesign 04:34, 15 April 2021 (UTC)

The phrase steer clear comes to mind. EEng 05:27, 15 April 2021 (UTC)

I wouldn't trust those people to cut my grass, let alone my flesh. --Khajidha (talk) 15:15, 26 April 2021 (UTC)

Bringing it on-topic: I reject any proposal that we write two thousand three hundred eighty as 2,3080 on Wikipedia. Largoplazo (talk) 11:08, 15 April 2021 (UTC)

Of course not. You'd write that 2,30080. EEng 01:55, 17 April 2021 (UTC)

spacing in floruit example

is there a reason why the example used to illustrate the usage of floruit (fl.) does not have a spaced en dash?

Jacobus Flori (fl. 1571–1588)

the last point in the mos:approxdate section notes that spaced en dashes should be used when "fl." appears in a range, "whether on one or both sides", and i can't seem to find an applicable exception for this example. had the point explicitly stated "whether on the right or both sides", i would have understood the lack of a spaced dash, but that is currently not the case. dying (talk) 06:53, 16 April 2021 (UTC)

It looks to me to be a case of practice (inadvertently) not being in accordance with theory, and no one has caught it before. Dhtwiki (talk) 23:15, 16 April 2021 (UTC)

thanks for the feedback. i have added spaces to the example. feel free to revert my edit if a reason for the previous lack of spaces is discovered. dying (talk) 07:52, 17 April 2021 (UTC)

• No, this is wrong. I'm sure the guideline does a bad job of explaining this, and I think even some of the related examples might not be right, but in this case definitely no spaces around the ndash, basically because the 1571–1588 bind to each other first, and the fl. applies to them as a unit: fl. 1571–1588.
  In contrast, in c. 1588 – 1622, the c. applies (presumably) only to the 1588, so we move the latter a bit away from the 1622 so as to put it in closer visual association with the c.. EEng 08:00, 17 April 2021 (UTC)
  • interesting. i had previously interpreted the guidelines as basically stating that if the text used to describe the date range, including all modifiers, could be written without a space if the en dash was not spaced, then the en dash is not spaced. otherwise, the en dash is spaced. my interpretation was more based on style rather than semantics, so thank you for that explanation.
    does this mean that fl. should not have been previously listed in the last guideline of the mos:approxdate section? admittedly, i currently cannot think of how fl. could have applied to only one side of a range, especially since fl. is used "[w]hen birth and death dates are unknown".
    also, from what i can tell, fl. is considered a modifier, both currently and before your recent edits to the guidelines. since the guideline right before the mos:topresent section currently recommends that a spaced en dash be used when a modifier is present, should an exception be explicitly made for fl. in that guideline? alternatively, should it be explicitly noted that fl. is not considered a modifier? dying (talk) 13:35, 18 April 2021 (UTC)
    • EEng, i was hoping for further guidance on this issue, if you have the time. tianwen-1, currently a bold link on itn, mentions the date range "c. 340–278 BC" to note the lifespan of poet qu yuan. in this range, i am assuming that "BC" should be interpreted as a modifier that "applies to the range as a whole", which implies that an unspaced en dash should be used. however, this also appears to be a case "[w]here era designations ... are present", which implies that a spaced en dash should be used. also, the modifier "c." is present and applies only to the first date of the range, which implies that a spaced en dash should be used. note that the unspaced version is currently also used in the lead of the article on qu yuan.
      is the current usage of the unspaced en dash correct? if so, are there any issues with "c." being misinterpreted as applying to the whole range because of the unspaced en dash? dying (talk) 19:38, 16 May 2021 (UTC)

Notes

Copyedit queries

"General notes" appears first after the intro.

"It is acceptable to change other date formats in an article for consistency, as long as those changes would otherwise be acceptable."

It's very unclear. Tony (talk) 02:24, 18 April 2021 (UTC)

---

Then we have a pretty unhelpful note about "Non-breaking spaces":

Guidance on the use of non-breaking spaces ("hard spaces") –  , {{nbsp}},  , {{thinsp}} – is given in some sections below; {{nowrap}} may also be useful in controlling linebreaks in some situations. Not all situations in which hard spaces or {{nowrap}} may be appropriate are described. For further information see Wikipedia:Manual of Style § Non-breaking spaces and Wikipedia:Line-break handling.

Why parade these items without explaining them in situ? In other words, why not specifically link to the sections that mention them instead of the vague "in some sections below"?

Lots of unexplained "may".

Tony (talk) 02:33, 18 April 2021 (UTC)

I added that [4] back in the day when I realized that (a) there were a lot of places were nbsp/nobr should probably be discussed but weren't and (b) it was going to be a big job to fix that and (c) in the meantime I didn't want people mistakenly concluding that presence some places meant absence elsewhere is significant. EEng 04:54, 28 April 2021 (UTC)

So do you think it's ok as now edited? Tony (talk) 00:22, 29 April 2021 (UTC)

Now that I've fixed the comma splice :P it looks OK to me. EEng 00:56, 29 April 2021 (UTC)

WP:COMPUNITS

@Dondervogel 2: (who previously edited here as Thunderbird2 (talk · contribs)) doesn't like WP:COMPUNITS, specifically the requirements around not using IEC units except under very specific circumstances. He'd like to change it. As I'm very much opposed to using IEC units as they are very rarely used in anything with widespread use (most of our sources use classic metric terms like KB, MB, GB, not KiB, MiB, and GiB), I'll leave it to them to fill in the reasoning for using these archaic terms that somehow overrides WP:NOR and WP:VNT. —Locke Cole • t • c 16:54, 25 April 2021 (UTC)

@Denniss and Zac67: since you apparently agree with IEC units and also want the MoS changed. —Locke Cole • t • c 16:56, 25 April 2021 (UTC)

Simply put, no. This is inappropriate canvassing. We don't need IEC die-hards dictating the MOS. Headbomb {t · c · p · b} 18:13, 25 April 2021 (UTC)

IEC dibi-hibiards, maybe? Anyway, agree, no change is needed or desired. —David Eppstein (talk) 18:21, 25 April 2021 (UTC)

@Headbomb: I debated mass-pinging the editors involved in the prior big discussion (which was apparently 10+ years ago) but didn't want to get people too ticked off. The problem is, Dondervogel 2 (and the other two editors I ping'd) are reverting changes to articles to use the metric (KB, MB, GB) terms in favor of keeping them using the IEC terms (KiB, MiB, GiB). So either we need to discuss this again, or this needs to go to WP:AN/I because a local consensus of editors should not be overruling the guidelines in the MoS. Otherwise why have these guidelines if they can just make small battles over years and slowly force the articles to IEC terms? —Locke Cole • t • c 19:11, 25 April 2021 (UTC)

AN/I is indeed the way to deal with tendentious editing. Headbomb {t · c · p · b} 19:12, 25 April 2021 (UTC)

I'm a bit surprise of the aggressive tone seen in the comments here. We reverted the undiscussed changes to SDRAM-related articles where KiB etc are desired and required. Locke Cole did not even try to enter a discussion but simply continued to revert. We did start a discussion at Talk:Synchronous_dynamic_random-access_memory#Disputed_edits but all he did was simply closing it off. We do not intent to change Mosnum, you just have to accept there are areas where KiB etc has more value than KB etc.--Denniss (talk) 19:36, 25 April 2021 (UTC)

It gets annoying reliving Groundhog Day moments here because an editor refuses to discuss this on the appropriate forum (in this case, here) because they know the outcome here will likely not be to their liking. See Talk:ThinkStation#COMPUNITS for another discussion this editor tried to force on a far-away article page debating this guideline. WP:COMPUNITS is also explicit on where and when IEC units are appropriate, and the articles I've been reverted on are not listed as potential exceptions. Further, with the IEC units, the articles are now engaged in original research, giving undue weight to a unit of measure that almost nobody uses (ESPECIALLY for memory-related articles, as JEDEC standards almost exclusively used KB, MB, GB). The current forked conversation (which I also closed and pointed here) is from just the past day, over here.

(edited to add) Dondervogel 2 has also tried, repeatedly, to have this discussion on other article talk pages (besides the two others linked above):

• Talk:X86-64#COMPUNITS
• Talk:IPad_Pro_(3rd_generation)#COMPUNITS
• Talk:IPad_Pro_(4th_generation)#COMPUNITS
• Talk:IPad_Pro#Clarification_of_GB_vs_GiB

I'll wait and see if anything comes of this conversation, but AN/I is seeming more and more likely.. —Locke Cole • t • c 19:58, 25 April 2021 (UTC)

In my day job I program embedded devices. Which means I spend a lot of time in the manufacturer's data sheets. I can't remember the last time I saw a MiB, KiB, etc in an official datasheet. Nor do I find them on Stack Overflow, or programming blogs or any other online resource when searching for answers for particularly hard problems. In fact, the only times I can remember is here on WP in talk page discussions arguing about whether to use them. It simply isn't used in the industry to any great extent.  Stepho  talk  22:55, 25 April 2021 (UTC)

I see no need for discussion here because I am not suggesting a change to MOSNUM. Nevertheless, if there is a consensus to hold the discussion here, so be it. As Denniss has already pointed out, the discussion thus started is unnecessarily hostile, so I start by reminding participants of WP:CIVIL. My purpose is to improve individual articles by implementing the MOS as it presently stands. Improvements to individual articles are best dealt case by case so let’s start with SDRAM. At that article an edit war has ensued, and I tried to move the discussion to its Talk page. The issue is how to remove the ambiguity introduced by this edit (and subsequent reverts) by Locke Cole. I started a discussion on the talk page. That discussion was closed by Locke Cole, so I have transferred that thread to here (below). Dondervogel 2 (talk) 14:45, 26 April 2021 (UTC)

@Zac67: @Locke Cole: @Denniss: Dondervogel 2 (talk) 14:48, 26 April 2021 (UTC)

Your concern is with the application of WP:COMPUNITS. You disagree with how it has been applied and believe my edits to be in error. The "hostility" you perceive is well-deserved because you have repeatedly started whack-a-mole discussions on various talk pages (for virtually identical issues) instead of coming here where the nexus of your concerns can be realistically addressed. As to Denniss (talk · contribs), this edit where he referred to what I said as "blah blah" pretty much takes the wind out of any feigned victimhood he tries to present here. WP:CIVIL is a two-way street. —Locke Cole • t • c 15:20, 26 April 2021 (UTC)

For a (hopefully) MOSNUM-conform prefix disambiguation I have created a new template, {{binpre}}. The template should enable quick and uniform footnotes when binary prefixes are (and need to be) used. Hope that helps. --Zac67 (talk) 11:55, 30 April 2021 (UTC)

@Zac67: We've had {{BDprefix}} for some time, which I've been trying to use where appropriate. When coupled with {{efn}} and {{notelist}} it provides a clean explanation that usually integrates well with other article content like references and other notes. —Locke Cole • t • c 14:35, 30 April 2021 (UTC)

{{binpre}} produces a numbered reference, which isn't appropriate. If it is to be used, it should produce a lettered footnote. NebY (talk) 09:17, 8 May 2021 (UTC)

@Compvis, Jc3s5h, Cybercobra, Woodstone, Greg L, Art LaPella, Seraphimblade, MJCdetroit, Pyrotec, Theaveng, and Cyde: ping'ing editors from the prior discussions since this has apparently turned into a larger discussion. Dondervogel 2 is attempting to use IEC units as disambiguation in articles despite longstanding recommendations being available here at WP:COMPUNITS. My reading is that there are very few exceptions for using IEC, and most are around whether the majority of sources use them or not, and whether or not it's possible to use one of the other methods to disambiguate the terms. Additional input would be appreciated. —Locke Cole • t • c 18:27, 3 May 2021 (UTC)

In fact, WP:COMPUNITS absolutely allows using IEC prefixes "in articles in which both types of prefix are used with neither clearly primary, or in which converting all quantities to one or the other type would be misleading or lose necessary precision, or declaring the actual meaning of a unit on each use would be impractical." In SDRAM], M and G are used with binary meaning for memory capacities, and with their standard SI meaning for data rates and frequences. In my mind, the currently used footnotes are impractical, especially when both meanings are used very closely together. Locke Cole repetitively reverting those disambiguations is in violation of those terms. I do not request the use of IEC prefixes in any other cases (storage sizes and whatnot) but the ones expressly designated in WP:COMPUNITS. --Zac67 (talk) 05:18, 4 May 2021 (UTC)

You (and others) are taking far too much liberty with that sentence from COMPUNITS. My reading of that is that the sources still need to be using those terms for it to be applicable, but so far as I've seen no source uses gibit. WP:V and WP:NOR are policy for a reason. —Locke Cole • t • c 14:17, 4 May 2021 (UTC)

Discussion transferred from SDRAM

WP:COMPUNITS is not a licence to introduce ambiguity in any article. I have restored an earlier, stable version of the article so we can discuss the disputed edits since 20 April. Relevant statements include:

• Do not assume that the binary or decimal meaning of prefixes will be obvious to everyone.
• Disambiguation should be shown in bytes or bits, with clear indication of whether in binary or decimal base. There is no preference in the way to indicate the number of bytes and bits, but the notation style should be consistent within an article.
• The IEC prefixes kibi- (symbol Ki), mebi- (Mi), gibi- (Gi), etc., are generally not to be used

The bottom line is that disambiguation is needed. The only question is how. It's hard to satisfy all three requirements, suggesting WP:IAR as the only practical guideline, and disambiguation using the most practical method to hand. What do others think? Dondervogel 2 (talk) 16:46, 24 April 2021 (UTC)

Agree – seconding that in full. Ambiguous units don't help anyone and explanations for readers unfamiliar with binary IEC prefixes are available on the linked page. --Zac67 (talk) 09:57, 25 April 2021 (UTC)

You keep trying to have these whack-a-mole discussions on far-off pages away from WT:MOSNUM. The correct location for this discussion is WT:MOSNUM. Stop starting forest fires and start the discussion where it makes sense. You're not going to change the wording of WP:COMPUNITS here. —Locke Cole • t • c 16:48, 25 April 2021 (UTC)

For purposes of this discussion, I'll stick to megabyte (MB)/mebibyte (MiB) (but the same logic applies to kilobyte (KB)/kibibyte (KiB), gigabyte (GB)/gibibyte (GiB), terabyte (TB)/tebibyte (TiB), etc). Depending on use, megabyte (MB) either means 1,000,000 (one million) bytes, or it means 1,048,576 bytes (notwithstanding some truly odd uses as was done in some floppy disk manufacturing). The 1,000,000 use is typically hard drive/storage manufacturers, while the 1,048,576 usage is typically memory/RAM manufacturers. To this day megabyte (MB, and the similar smaller/larger units) remain in wide use in not just technical documentation but also in the larger media around computing topics as well as in marketing materials and packaging for computing related products. I can walk into a Best Buy, pick up a hard drive box, and see that Western Digital is still proudly selling a 14 terabyte hard disk drive. There will be an asterisk, and on the bottom of the box I'll see a disclaimer noting that "1 gigabyte = 1 billion bytes, 1 terabyte = 1 trillion bytes". If I walk over to the computer memory area, I can look at a package of DDR4 SDRAM and see that it is sold in units of GB (gigabyte). If I walk over to the Apple store, I see that iPad Pro's come in storage options like 64 GB and 256 GB, but a disclaimer is near the bottom of the marketing material stating that "1 GB = 1 billion bytes".

Long story short, IEC unit adoption is effectively non-existent. Other than academic work in some spotty situations, the wider world has largely stuck to the metric units we've had since the early days of computing. Wikipedia reports on the world as it is, not how people want it to be. It's unfortunate that this type of imprecision is baked in to something that demands precision (computing and technology), but for our readers using terms like "gibibyte" and "mebibyte" when they're used to seeing terms like "gigabyte" and "megabyte" simply creates unnecessary confusion. Our best bet is to wikilink these terms as appropriate (so readers can dig deeper if they choose), and perhaps provide linked footnotes that give more precision to potentially problematic instances within our articles (simply using language similar to what Apple and Western Digital uses would at least remove any uncertainty for our readers where that may be an issue; e.g. - "1 MB = one million bytes").

I'm open to additional options, but using KiB, MiB, GiB, etc. is not one of them except as exactly proscribed in WP:COMPUNITS (which only lists four very specific instances where we would use them). —Locke Cole • t • c 15:20, 26 April 2021 (UTC)

Good to have an expert on board, Locke. Tony (talk) 05:17, 27 April 2021 (UTC)

You are missing the point. COMPUNITS is very clear on the requirement to disambiguate:

• Do not assume that the binary or decimal meaning of prefixes will be obvious to everyone.
• Disambiguation should be shown in bytes or bits, with clear indication of whether in binary or decimal base. There is no preference in the way to indicate the number of bytes and bits, but the notation style should be consistent within an article.

You are the editor who with this edit introduced ambiguity in the article (and when your edits were disputed by other editors you chose to revert 3 times [5] [6] [7] instead of engaging on the talk page), so the onus is on you to remove that ambiguity. How do you propose the article in question might disambiguate between different units sharing the same symbol? Dondervogel 2 (talk) 18:25, 26 April 2021 (UTC)

No, I'm very much aware of your point. But what you've missed entirely is that Wikipedia does not use IEC units except in very specific situations. Full stop. What you've also missed is the answer to your own question from WP:COMPUNITS. Now considering you've been directed there dozens of times so far (and you have to know it exists because you participated in the discussions over ten years ago that lead to WP:COMPUNITS being what it is today), and that you're now pretending that you can't read basic English, I'm beginning to think WP:CIR applies to your situation. From WP:COMPUNITS:

• Disambiguation should be shown in bytes or bits, with clear indication of whether in binary or decimal base. There is no preference in the way to indicate the number of bytes and bits, but the notation style should be consistent within an article. Acceptable examples include:
  • A 64 MB (64 × 1024²-byte) video card and a 100 GB (100 × 1000³-byte) hard drive
  • A 64 MB (64 × 2²⁰-byte) video card and a 100 GB (100 × 10⁹-byte) hard drive
  • A 64 MB (67,108,864-byte) video card and a 100 GB (100,000,000,000-byte) hard drive

I personally think that's overkill, and that simply using language similar to what Western Digital and Apple uses ("1 GB = 1 million bytes" (and so on, as appropriate) as a footnote) would suffice. Wikipedia will not be using KiB, MiB, etc. If you'd like to change that, we're finally on the right page. But given the comments above I think you'll find that discussion won't have the outcome you're looking for. —Locke Cole • t • c 19:34, 26 April 2021 (UTC)

Yes, I'd like to propose a change. When the last discussion is 10 years past it might be time to reconsider.

In my last workplace, IEC prefixes were mandatory in documentation where binary prefixes made sense (mostly RAM), everything else had to use decimal. In my current job, IEC prefixes are recommended for binary prefixes. JEDEC simply don't use them because they use binary prefixes exclusively and have to need for decimal. However, when you're dealing with various aspects of computers it's impossible to avoid ambiguity when mixing binary and decimal prefixes without pointing out the current meaning all the time. There are

If this policy can't be changed, how are we supposed to refer to a memory with a capacity of 2³⁶ bytes?

• 64 GB (with footnote: G means 1024³ here and only here)
• 68.719.476.736 byte
• ca. 68.7 GB

Isn't 64 GiB so much simpler? Please don't get me wrong – using binary prefixes in any way for arbitrary amounts (storage, network, telecommunication) is simply nonsense, even if there's a tradition. I'm just talking about the few cases when binary prefixes make real sense. [perplexed] --Zac67 (talk) 21:28, 26 April 2021 (UTC)

Of the three options you gave, only one is valid, the first one with the footnote. #2 would likely run afoul of WP:POINT (and concerns over WP:V and WP:RS not using that type of language), and #3 would be WP:OR as it's not how our sources use the terms. In the past ten years nothing of significance has changed to make IEC units any more attractive than they were back in 2008-2009. In the end, they fail the most basic requirement for use: being widely used in our sources and in everyday life. Apple does not use GiB. Microsoft does not use GiB. Major electronics manufacturers do not use GiB. News outlets, especially those dealing in technology and computing, do not use GiB. Go read the archives, they tried using IEC here for years prior to WP:COMPUNITS, and IEC was ultimately deprecated due to lack of use in our sources and confusion to our most important concern: readers. —Locke Cole • t • c 21:54, 26 April 2021 (UTC)

Stating "G means 1024^3 here and only here" is not a workable solution. We need a better way to disambiguate, and the best disambiguation method will likely vary from article to article. Locke Cole needs to stop the campaign to introduce ambiguity into dozens of articles while we debate this. Dondervogel 2 (talk) 10:15, 28 April 2021 (UTC)

I think in the long run we should leave the choice to the reader (similar to date formats and metric vs imperial units). For now, I'll add disambiguation footnotes, see DDR4 SDRAM. Unwieldy but so be it. We should create a template for the footnotes so there's a uniform format and it's easier to migrate (in case that actually happens). --Zac67 (talk) 10:23, 28 April 2021 (UTC)

I support this form of disambiguation when GB has one and only one meaning in an article. I do not support it when it has two or more meanings. Dondervogel 2 (talk) 10:41, 28 April 2021 (UTC)

I'm operating with the current consensus. Until you've shown support for another method I'll continue to edit as I have because the guideline has been stable for over a decade with significant support. If you want to change that, make it known and present your choice for how to proceed. Otherwise, drop it and move on and leave those of us working within the current MoS guidelines to improving Wikipedia by using language our readers understand and see everywhere else. —Locke Cole • t • c 16:04, 28 April 2021 (UTC)

You are not working within current MOS guidelines; you acknowledge yourself that these require disambiguation and yet you choose not to follow that part. And I am not arguing for a change to those guidelines. Instead I am arguing against your repeated edits introducing ambiguity in SDRAM, when there is a clear consensus here that disambiguation is needed, and required by MOSNUM. And I am arguing that the article should stay in its state before this discussion ensured until we agree how it should be resolved. Dondervogel 2 (talk) 16:19, 28 April 2021 (UTC)

WP:COMPUNITS already prescribes methods for disambiguating them. My edits have been focused on removing the inappropriate IEC units as in addition to not following the consensus here, they also violate WP:V and WP:NOR as almost all of our sources use the more traditional binary units. WP:SOFIXIT if you think something is not clear, using one of the already demonstrated methods at WP:COMPUNITS. The status quo is we do not use IEC units. Until you demonstrate consensus to change that I will not be hamstrung to constant debate over something that has already been settled for over a decade. Your problem is you don't think I have consensus when I already do. —Locke Cole • t • c 16:37, 28 April 2021 (UTC)

You are aware of the requirement to disambiguate but you choose to ignore that requirement. Therefore your edits do not comply with COMPUNITS. I've made an attempt to disambiguate the article. Suggested improvements are welcome. An edit war is most unwelcome. Dondervogel 2 (talk) 18:52, 28 April 2021 (UTC)

@Dondervogel 2: I choose to accept that not everything on Wikipedia will be done simultaneously, or nothing would ever get done: see WP:NOTPERFECT. Your reverting back to a version where IEC units are in use, which runs contrary to the consensus here as well as the MoS guideline which says IEC units are not to be used except in a handful of very specific circumstances, is what is decidedly not welcome. You are disrupting Wikipedia by undoing constructive work. —Locke Cole • t • c 05:11, 29 April 2021 (UTC)

On the contrary. I am trying to find a solution that works. More specifically, as SDRAM uses G with a decimal meaning and M with a binary meaning I propose replacing all binary occurrences of 'G' with '1024 M'. It's messy and far from ideal but it works. Dondervogel 2 (talk) 13:01, 1 May 2021 (UTC)

@Dondervogel 2: What makes you think that G is solely used with the decimal meaning? M, G, T are commonly used referring to binary powers as well, especially by JEDEC. --Zac67 (talk) 16:05, 1 May 2021 (UTC)

@Zac67:My point is that GB/s is used in this particualr article in the decimal sense. I suppose we could define 1 GB as 1000^3 B and 1 Gbit as 1024^3 bit, but I prefer to see G used with only one meaning in any one article. Any other convention is likely to confuse the reader. Dondervogel 2 (talk) 16:56, 1 May 2021 (UTC)

@Zac67: I put a couple of 'dubious' tags at places where I think the article is now in error as a result of recent changes. See what you think. Dondervogel 2 (talk) 20:25, 1 May 2021 (UTC)

@Dondervogel 2: I beg to differ. In telecommunication and storage, there's no reason to use binary prefixes (save for some corner cases). Accordingly, "GB/s" should always be based on powers of 1000. Transfer rates are defined using decimal prefixes. For an example, check out JEDEC docs – for sizes they use 1024^x and for rates 1000^x (base clocks are 100 or 200 million Hz). If that doesn't really make sense then you've got my initial point. --Zac67 (talk) 20:27, 1 May 2021 (UTC)

@Zac67: Sorry, I did not explain myself well. The problem is that the article defines Gbit to mean 1024^3 bit, and then uses it (where I placed the 'dubious' tags) to mean 1000^3 bit. Dondervogel 2 (talk) 20:35, 1 May 2021 (UTC)

@Dondervogel 2: Hmm, can't see any general definition in the article. All binary prefixes should be footnoted now, the plain ones should be decimal. --Zac67 (talk) 21:01, 1 May 2021 (UTC)

@Zac67: I fixed the error. It's messy, but at least it's not wrong. Dondervogel 2 (talk) 00:29, 2 May 2021 (UTC)

@Dondervogel 2: Sorry, you didn't. We don't use binary prefixes arbitrarily. When a data rate is defined by a frequency based on a decimal prefix (e.g. 200 MHz) it makes absolutely no sense to use a binary prefix (not even JEDEC do that), so we must stay decimal. In a nutshell, RAM size is expressed using binary, RAM speed in decimal. A rare exception could be when the frequency is some power of two, due to binary multiplication, but that isn't the case with standard RAM. Do we need a decimal footnote as well...? --Zac67 (talk) 07:43, 2 May 2021 (UTC)

No. That's not the solution. A Gbit is either 1000^3 bit or 1024^3 bit. At the moment it's both but we need to choose between them. Which is it? Dondervogel 2 (talk) 09:08, 2 May 2021 (UTC)

@Zac67: We should not assume the reader will know which Gbit is decimal and which is binary, and this is phrased in MOSNUM as "Do not assume that the binary or decimal meaning of prefixes will be obvious to everyone" and "consistency within an article is desirable". There is no reason to introduce inconsistency in this article. Dondervogel 2 (talk) 10:36, 2 May 2021 (UTC)

"Gbit" is decimal unless it's tagged as binary (which is clunky but Locke Cole wouldn't allow using IEC prefixes reasonably). Binary Gbit is reasonable for semiconductor memory sizes or capacities (and very few other cases). Data rates, disk capacities, etc all use decimal prefixes because there's no fundamental binary array behind them. Check WP:MOSNUM also. Consistency is desirable, but not to the extent of mashing up data rates. (like "100 MHz × 8 bit/s = 95.4 MB/s" – definitely not) --Zac67 (talk) 11:21, 2 May 2021 (UTC)

LC neither makes the rules, nor has a monopoly on their interpretation. MOSNUM requires us to think of the reader and make clear the meaning of each unit symbol. Using the same unit symbol (Gbit) with two different meaning does not achieve that, so the question becomes how else can it be done. Here are 4 examples of disambiguation in scientific publications:

• do Carmo et al 2007
• Heithecker et al 2007
• Blomer 2015
• Gerhke et al 2016

In all 4 cases, disambiguation is achieved by using Gbit for the decimal quantity and Gibit for the binary one. We have both sought alternatives to clarify this article, and none so far has been successful. I propose we follow the disambiguation method used in reliable sources. Dondervogel 2 (talk) 17:43, 2 May 2021 (UTC)

Shame that none of those four sources are used in Synchronous dynamic random-access memory (edit | talk | history | protect | delete | links | watch | logs | views). What do our sources used in the article say? —Locke Cole • t • c 00:51, 3 May 2021 (UTC)

I think we've now sufficiently established that reliable sources use IEC prefixes and traditional, ambiguous prefixes both, with and without additional disambiguation (see below). That also falsifies the above statement that "IEC unit adoption is effectively non-existent". Also, MOSNUM currently permits IEC prefixes where both decimal and binary prefixes are reasonably used within an article and disambiguation is required.

From recent experience, I can say that using repetitive footnotes with binary prefixes is clunky at best. Can we now please use IEC prefixes (sparingly and where they are really useful, compliant with MOSNUM) without having to fear edit warring? --Zac67 (talk) 09:02, 3 May 2021 (UTC)

Sufficient established? You say that as though you mean the majority of reliable sources use IEC prefixes. But you have only established that some reliable sources from academia use IEC prefixes. You still have to prove that the majority of reliable sources (including official sources such as manufacturer datasheets and standards bodies) use IEC prefixes and do not use MB/GB/TB/etc. You also have to prove that sources that use MB/GB/TB are unreliable.  Stepho  talk  11:57, 3 May 2021 (UTC)

What has been established is that all sources identified to date that disambiguate on the subject of SDRAM, do so using IEC prefixes. That's a majority of about 52 reliable sources using IEC prefixes to none using the silly methods suggested by MOSNUM. Dondervogel 2 (talk) 12:07, 3 May 2021 (UTC)

@Stepho-wrs: Requiring a general majority of RS before allowing IEC prefixes in a page isn't helping – it could very quickly lead to the prefix use becoming a (biased) editor's selection criterion for RS, instead of a source's value in terms of clarity and appliability. Also, there's no ground for demanding a majority of sources – the current MOSNUM already allows IEC prefixes when individual tagging is impractical (which imho is clearly the case in the SDRAM article). --Zac67 (talk) 12:57, 3 May 2021 (UTC)

I have disambiguated Gbit and Gibit, so that the article is not wrong. It's still messy though. Dondervogel 2 (talk) 16:44, 3 May 2021 (UTC)

Invocation of WP:CALC at Talk:Memory hierarchy

@Tom94022 and Dondervogel 2: Quoting the first sentence of WP:CALC: Routine calculations do not count as original research, provided there is consensus among editors that the result of the calculation is obvious, correct, and a meaningful reflection of the sources.

Let's take the requirements one by one:

• […] provided there is consensus among editors […] – seems like an important point;
• […] that the result of the calculation is obvious, correct, […] – no disagreement there, as the IEC units as defined are a drop-in replacement for the classic metric unit names;
• […] and a meaningful reflection of the sources – …and here is where it all falls to pieces, very few reliable sources use these IEC units/prefixes. The vast majority, I'd expect somewhere north of 95% of sources use the classic kilobyte/KB, megabyte/MB, gigabyte/GB, terabyte/TB and so on. And regardless of that, the language here at WP:COMPUNITS has enjoyed consensus for over a decade. It is unacceptable to disrupt editors working to implement our style guidelines because you disagree with the result of the discussions here. If you want to change WP:COMPUNITS, this is the place to hold that discussion. That being said, endless debate because you disagree with what the majority supports is not going to work: Wikipedia does not have a filibuster. —Locke Cole • t • c 16:23, 30 April 2021 (UTC)

Contrary to his assertion above it is this article that allows IEC prefixes in the article in question. Locke Cole is edit warring by imposing his point of view at Memory hierarchy in spite of the clear teaching in this article that IEC prefixes maybe used "in articles in which both types of prefix are used with neither clearly primary ..." The article in question has used IEC prefixes as prescribed in this article for clarity for a long time so there is clearly consensus amongst the editors of the article to use the prefixes and no one to date has supported his POV. Tom94022 (talk) 16:48, 30 April 2021 (UTC)

Note that I have reported Locke Cole for edit warring on this subject. Tom94022 (talk) 17:24, 30 April 2021 (UTC)

You missed the remaining quote from what you read: […] or declaring the actual meaning of a unit on each use would be impractical. My edit shows that using {{BDprefix}} made it possible to declare the actual meaning of each unit. This also keeps it in line with our sources which do not use GiB or MiB or KiB. —Locke Cole • t • c 17:58, 30 April 2021 (UTC)

The appropriate place for this discussion is Talk:Memory_hierarchy#IEC_units where the editors of that article can decide which section of this article is most applicable. Locke Cole is formum shopping by raising it here and any editor having knowledge and interest in application of IEC prefixes to memory hierarchy should comment there. Tom94022 (talk) 17:40, 30 April 2021 (UTC)

No, it's here. Stop trying to make ForestFires. You lost. Get over it. —Locke Cole • t • c 17:58, 30 April 2021 (UTC)

So this is what it's about? Winning and losing? Pfft. You're behaving childishly to valid arguments. --Zac67 (talk) 20:28, 30 April 2021 (UTC)

@Zac67: That's some nice gaslighting. Go ahead and read this: Wikipedia talk:Manual of Style (dates and numbers)/Archive B16#Gibibytes_versus_Gigabytes; I didn't realize Tom had also been involved in the 10+ year old discussion and was just beating a dead horse for over a decade... —Locke Cole • t • c 21:05, 30 April 2021 (UTC)

Do I have to turn the hose on you bunch? EEng 22:21, 30 April 2021 (UTC)

IEC usage in print media

List taken from List of newspapers in the United States, List of newspapers in the United Kingdom by circulation, List of newspapers in Australia by circulation and List of newspapers in Canada by circulation.

Google query results
Newspaper	site:<URL> "gibibyte"	site:<URL> "gigabyte"	site:<URL> "fatberg"
usatoday.com	0	745	26
wsj.com	1	2,890	2
nytimes.com	1	4,610	168
nypost.com	0	234	130
latimes.com	0	1,390	5
washingtonpost.com	0	971	47
startribune.com	0	410	1
newsday.com	0	270	0
chicagotribune.com	0	952	41
bostonglobe.com	0	278	3
Extra entries for fun
seattletimes.com	0	611	23
seattlepi.com	0	383	0
International (English-speaking)
timesofindia.com	0	490	4
metro.co.uk	0	109	2,290
thesun.co.uk	0	137	135
dailymail.co.uk	0	710	318
www.standard.co.uk	0	88	17,900
mirror.co.uk	0	154	170
thetimes.co.uk	0	439	65
www.telegraph.co.uk	0	407	72
theguardian.com	0	546	3,270
heraldsun.com.au	0	76	26
www.dailytelegraph.com.au	0	84	45
www.couriermail.com.au	0	49	34
www.smh.com.au	0	1,030	29
www.theaustralian.com.au	0	364	8
www.theglobeandmail.com	0	602	2
www.thestar.com	0	387	22
nationalpost.com	0	58	49
No "site:" filtering, just the terms in quotes
	213,000	72,400,000	238,000

I may expand this, but as a datapoint I thought it might be interesting to see. —Locke Cole • t • c 15:30, 1 May 2021 (UTC)

We are talking about disambiguation in SDRAM and in Memory hierarchy. Do any of these newspaper articles disambiguate? If not they are not relevant to the discussion. Below are some scientific publications that are about either memory hierarchy or SDRAM. They all disambiguate using IEC prefixes. Dondervogel 2 (talk) 17:58, 1 May 2021 (UTC)

If not they are not relevant to the discussion. Sorry, what? In what universe do you think the media-at-large not using the terms you're pushing is somehow not a death-knell for the idea at the outset? And I'll say again, I've yet to see any sources in the articles I've changed which utilized IEC units, let alone any with a ratio of IEC being more prominent than the traditional metric units. Wikipedia is not a platform to push your agenda. —Locke Cole • t • c 19:11, 1 May 2021 (UTC)

Disambiguation in scientific publications on memory hierarchy

Scientific publications using IEC prefixes

1. Ayers et al 2018
2. Balkesen et al 2013
3. Capodieci et al 2020
4. Choe et al 2020
5. Deakin and Price, 2017
6. Endo 2016
7. Gottscho et al 2016
8. Hackenberg et al 2009
9. Kim et al 2019
10. Kloda et al, 2019
11. Kodama et al 2019
12. Kodama et al 2020
13. Le Seur and Heiser 2010
14. Molka et al, 2009
15. Molka et al 2014
16. Molka et al, 2017
17. Monil et al 2020
18. Moreira et al 2006
19. Navarro et al 2019
20. Perarnau et al 2016
21. Ren et al 2021
22. Sanchez et al 2018
23. Schlosser et al 1999
24. Sing et al 2009
25. Thiemann 2020
26. Yarom et al 2015
27. Zlatanov 2016

Scientific publications using other methods of disambiguation

• Sun 2011

Discussion

I maintain that reliable sources that disambiguate on the subject of memory hierarchy, do so using IEC prefixes. Are there any counter-examples? Dondervogel 2 (talk) 17:58, 1 May 2021 (UTC)

Here's a cherry picked counterpoint against your cherry picked examples:

• Guangyu Sun, 2011, Exploring the Memory Hierarchy Design with Emerging Memory Technologies (see page 19)

Isn't it fun playing the cherry pick game!  Stepho  talk  01:03, 2 May 2021 (UTC)

A comment and a question:

I was not cherry picking (there are plenty more where those came from)

I see no disambiguation in the example you found. Where is the disambiguation?

Dondervogel 2 (talk) 07:31, 3 May 2021 (UTC)

When there are millions of papers out there, any selection is unlikely to be representative. You can pick hundreds of papers showing your view and I can pick hundreds of papers showing my view. Both selections are meaningless. Hence, any hand picked selection is inherently cherry picked - even if it unintentional.

For the paper that I showed, look at page 19 (use the printed page number, not the PDF page number). It says "2MB (16x128KB)" and a few similar expressions - clearly showing that it is not 2,000 KB or 2,000,000 bytes.

But let's go to a more authoritative source. JEDEC defines standards for many memory devices - including eMMC/MMC/SDCard devices and DIMM/SDRAM. The MMC standard is at https://www.jedec.org/sites/default/files/docs/JESD84-B51.pdf (you will need to register but it's free). JEDEC uses KB/MB/GB exclusively.

Same for SD Cards at https://www.sdcard.org/downloads/pls/pdf?p=Part1_Physical_Layer_Simplified_Specification_Ver8.00.jpg&f=Part1_Physical_Layer_Simplified_Specification_Ver8.00.pdf&e=EN_SS1_8 (another free registration required).

Or back to JEDEC for SDRAM standards at https://www.jedec.org/system/files/docs/4_20_10R19A.pdf .

Feel free to explore JEDEC - they have plenty of documents using KB/MB/GB/TB/etc and I have found only one that mentions IEC prefixes: "JEDEC Dictionary of Terms for Solid-State Technology – 7 th Edition" https://www.jedec.org/system/files/docs/JESD88F.pdf . On page 135 (PDF page 141) it gives the definition of mega and specifically contrasts it with mebi. And then they never use the IEC prefixes in any other document (at least not that that I have found by pulling documents at random).

I believe this discussion started at the SDRAM article. SDRAM standards are maintained by JEDEC. And JEDEC use non-IEC prefixes.  Stepho  talk  13:22, 3 May 2021 (UTC)

JEDEC use mixed prefixes. They use binary ones for memory capacity only and decimal/SI ones for data rates and such. While this is a commonly understood way for seasoned professionals, I don't think it's the right way to go for WP, given our reader scope. The same goes for the "2MB (16x128KB) [...] clearly showing" quoted above. Even JEDEC have acknowledged good use cases for IEC prefixes, they just don't live it that way (yet) – given the lack of pressure in these circles, an adjustment may very well take decades. I think – and hope – we can be more progressive here. --Zac67 (talk) 13:54, 3 May 2021 (UTC)

@Stepho-wrs: In reply to your various points

• Sun 2011: Thanks. I see now that MB is is disambiguated in the way you suggest. I don't see KB or GB disambiguated anywhere. Worse, the disambiguation of MB helps me not one iota to decipher (p94) "The average bandwidth provided by main memory is assumed to be 8GB/S". Not very professional and certainly not an example we should follow.
• JEDEC: We cannot expect our readers to be familiar with JEDEC standards. Nor does JEDEC define all of the prefixes in a binary sense. See Template:Quantities_of_bytes.
• This discussion started at Memory hierarchy, not SDRAM.

Dondervogel 2 (talk) 14:18, 3 May 2021 (UTC)

Regardless of where it was started, for topics relating to memory (DRAM, SDRAM, GDDR, etc), JEDEC is the organization that creates standards and generally promotes the terms used on packaging and in manufacturer literature. As discussed below in IEC units in scholarly papers, the instances of IEC units is vanishingly small compared to the use of the traditional metric units in scholarly papers. —Locke Cole • t • c 16:48, 3 May 2021 (UTC)

D, if you expect the reader to not understand the source of most computer memory standards but do expect them to understand academic papers then your rose coloured glasses have become cherry coloured glasses. Both are written to about the same level of complexity and both would be roughly equal in understandability to the reader.  Stepho  talk  20:52, 4 May 2021 (UTC)

@Locke Cole: The "traditional metric units" you refer to are in many cases not metric units, but binary units. If they don't disambiguate we can't tell, and that is my point. In my experience, the ones that do disambiguate use IEC prefixes.

@Stepho-wrs: Do not put words in my mouth.

Dondervogel 2 (talk) 12:51, 7 May 2021 (UTC)

@Dondervogel 2: That's a nice idea, but the fact that only two sources in print media even use those terms at all takes the air out of that idea really fast. Then considering less than two percent of scholarly works reference those units, again, makes that argument very unbelievable. See Hitchens's razor and Sagan standard. Even the sources you've cited here have been found to not be disambiguating like you claim, so the assertion that the ones that do disambiguate use IEC prefixes is simply not true. —Locke Cole • t • c 15:32, 7 May 2021 (UTC)

Which of the sources are not disambiguating? Dondervogel 2 (talk) 07:47, 9 May 2021 (UTC)

I'm done playing your "I don't hear you" game. The majority of editors here don't support changing COMPUNITS. COMPUNITS already says IEC units are The IEC prefixes kibi- (symbol Ki), mebi- (Mi), gibi- (Gi), etc., are generally not to be used. There are already methods in COMPUNITS to disambiguate that do not involve using IEC units. You're not convincing anyone with this game you're playing at where you fork these discussions (which are largely about the same fucking thing) and then pretend you don't see or choose to ignore conversations that don't go as you wanted. The IEC units are not widely used by our reliable sources, by the media at large, by scholarly works, or by businesses and manufacturers in the industry. Full stop, end of story. I'm done here unless someone besides you says something even remotely compelling. —Locke Cole • t • c 08:08, 9 May 2021 (UTC)

You did not answer my question; is that because the sources do disambiguate as claimed? And I don't recall proposing a change to COMPUNITS; this discussion is about ambiguities in Memory hierarchy. Dondervogel 2 (talk) 10:15, 9 May 2021 (UTC)

@Dondervogel 2: can you explain what words you think I am putting in your mouth? You presented a handful of academic papers and I presented the official standard used for most computer memory production. Both have similar levels of complexity and both are equally understandable (or at least equally hard to understand). Why would you accept one and reject the other?  Stepho  talk  23:55, 7 May 2021 (UTC)

Your post implies that I "expect the reader to not understand the source of most computer memory standards but do expect them to understand academic papers", which is not what I said. My words were "We cannot expect our readers to be familiar with JEDEC standards", which means that if WP decides to follow JEDEC standards, WP needs to explain the implications by disambiguating, which is no more than what COMPUNITS already says. Dondervogel 2 (talk) 07:54, 9 May 2021 (UTC)

Disambiguation in scientific publications on SDRAM

1. Andersson et al, 2017
2. Biancolin et al 2019
3. Carroll and Heiser, 2010
4. Christmann et al 2016
5. Doonan et al 2006
6. Engel et al, 2019
7. Floris et al 2004
8. Frerking 2018
9. Fujiwara et al, 2020
10. Gamess et al 2020
11. Gilbert 2016
12. Goossens et al 2016a
13. Goossens et al 2016b
14. Gotzhein, 2020
15. Grant et al 2010
16. Gruhn & Muller 2013
17. Heywood 2016
18. Heinig et al 2013
19. Heirman et al 2005a
20. Heirman et al 2005b
21. Heirman et al 2006
22. Hirano et al 2017
23. KARI 2021 (in Korean?)
24. Kim et al 2020
25. Knight et al 2016
26. Knight & Furber 2016
27. Knight et al 2016
28. Kokosa 2018
29. Kurth et al 2016
30. Lopez 2017 (in Spanish)
31. Mao et 2014
32. Michard et al 2013
33. Muller 2009
34. Mundy et al 2015
35. Neider 2011
36. Park et al 2016
37. Pedersen 2013
38. Plefka et al 2011
39. Rosa 2011
40. Rowley et al 2019
41. Sindelar 2012
42. Smith 2013
43. Sohn & Sander 2021
44. Stockel 2015
45. Sunter et al 2016
46. Tang & Du 2021
47. Tervo 2017
48. Vohnik 2010 (in Czech?)
49. Weinert 2007 (in German)
50. Zhou et al 2013
51. Zhou 2019
52. Zlatanov 2016

Scientific publications using other methods of disambiguation

None identified to date

Discussion

I maintain that reliable sources that disambiguate on the subject of SDRAM, do so using IEC prefixes. Are there any counter-examples? Dondervogel 2 (talk) 17:58, 1 May 2021 (UTC)

I don't have an IEEE or Springer account so I can't verify those links, but Carroll and Heiser, 2010 is NOT about SDRAM. The title of the paper is An Analysis of Power Consumption in a Smartphone. Floris et al 2004, which is also not a paper about SDRAM but instead titled A New PCI Card for Readout in High EnergyPhysics Experiments, discusses SDRAM in discussing the card, but doesn't disambiguate at all. Likewise, Fujiwara et al, 2020 is also not a paper about SDRAM but mentions it in passing, and does not disambiguate. Sunter et al 2016, which will come to a surprise to nobody at this point, is ALSO not about SDRAM. It's a paper titled DUAL-CAMERA PAYLOAD for ESEO which is about a dual camera system for a low-Earth orbit device. It also does not disambiguate as you claim (and in fact fails to disambiguate a microSD card that the paper claims has 1 GiB of storage, which would be remarkable considering most SD cards use 1 GB = 1 billion bytes, and the manufacturer advertises their cards as using GB not GiB). I'll wait for someone with IEEE and/or Springer access to confirm those links, but I'm not impressed with what you're presenting so far... —Locke Cole • t • c 01:48, 3 May 2021 (UTC)

I'm certain to regret this, but like a moth to the flame I can't resist. I do have access. I haven't been following (except to thank my stars I don't care about the issue) but if you'll tell me exactly what I'm looking for I can copy out relevant bits. EEng 04:27, 3 May 2021 (UTC)

like a moth to the flame I can't resist; so long as you don't set yourself alight because I might still take you up on that hose offer above. Luckily I can see titles and an abstract for the Springer/IEEE links, so really you just need to look at 1) how prominent SDRAM is as a topic to the paper overall (is it mentioned in passing as a dry tech spec, is SDRAM itself actually discussed in great detail, or..?), 2) is the paper using IEC units (KiB/kibibyte, MiB/mebibyte, GiB/gibibyte, TiB/tebibyte, etc) and 3) does the paper also utilize decimal versions of the metric units (KB/kilobyte, MB/megabyte, GB/gigabyte, TB/terabyte, etc). Here's the links in table form, just fill in the blanks:

Link	Title	Authors	1) SDRAM prominence	2) Uses IEC units	3) Uses metric units
[8]	LEON Processor Devices for Space Missions: First 20 Years of LEON in Space	Andersson et al, 2017	Totality of referencex to SDRAM, KB, MB, GB, KiB, MiB, GiB, Kbit, Mbit, Gbit are: *PROM/SRAM/SDRAM memory controller ... 32 MiB PROM ... 32 MiB SRAM ... 512 MiB SDRAM ... 192 KiB on-chip RAM bus connects to a 2 MiB [cahse] ... external EDAC protected SDRAM. with 32KiB cache ... PROM/SRAM/SDRAM memory controller ... up to 32 MiB PROM ... 32 MiB SRAM ... 512 MiB SDRAM ... 192 KiB on-chip RAM with 16 + 16 KiB writethrough cache ... 2 MiB Shared L2 write-back cache ... 64-bit data SDRAM PC100 memory interface ... RMAP @ 300 Mbit/s ... 10/100/1000 Mbit Ethernet interface ... target interface @ 33 MHz Level-2 cache and/or the external SDRAM. 10/100/1000 Mbit Ethernet ports ports with RMAP @ 300 Mbit/s ... 2x 10/100/1000 Mbit Ethernet interface up to 300 Mbit/s processor cores with 32KiB 192KiB EDAC protected tightly coupled memory up to 16 MB ROM and 256 MB SRAM up to 2.4 Gbit/s
[9]	BiPS – A Real-Time-Capable Protocol Framework for Wireless Networked Control Systems and Its Application	Engel et al, 2019	Intel XScale PXA 270 controller with 256 KiB SRAM, 32 MiB SDRAM, and 32 MiB FLASH. It supports clock rates up to 416 MHz
[10]	Implementation Aspects of ProNet 4.0	Gotzhein, 2020	Intel XScale PXA271 processor with 256 KiB SRAM, 32 MiB SDRAM, and 32 MiB FLASH ... clock rates up to 416 MHz ... executed from SDRAM ... platform offers 32 MiB flash memory ... provides 256 KiB SRAM and 32 MiB SDRAM ... consumed only about 59 KiB ... 59 KiB static memory and 26 KiB dynamic ... needs at least 140 KiB static and 26 KiB dynamic ... consumes about 350 KiB static and 26 KiB dynamic ...
[11]	An efficient SpiNNaker implementation of the Neural Engineering Framework	Mundy et al 2015	*32 KiB for instructions and 64 KiB for data; and shares 128 MiB of off-chip SDRAM matrix associated with the firing neuron from SDRAM This is 8 MiB as each core is allocated 1/16 of the 128 MiB SDRAM. occupy approximately 2.28 GiB of memory each core only has 8 MiB of SDRAM retrieves synaptic weights from SDRAM require the SDRAM of three SpiNNaker chips 2. 4 MiB to store the full weight matrix or 70. 0 KiB each ... (a total of 140. 0 KiB)

I've left HTML comments in the table markup for you to fill-in at your discretion. —Locke Cole • t • c 05:31, 3 May 2021 (UTC)

You owe me, buster! EEng 07:42, 3 May 2021 (UTC)

Thank you! =) @Dondervogel 2: So these all appear to be mentioning SDRAM, not papers about SDRAM, and you appear to be pretty lax in your assessment that they are "disambiguating", since it seems like most are just using IEC units outright, with no other data units (like KB, MB, GB) in use. A paper using MiB and then using MHz is not what I'd call a shining example. I think the big confusion we were all trying to solve is around MB being either 1,024 × 1,024 = 1,048,576 or 1,000 × 1,000 = 1,000,000. I very much doubt readers are being confused by MHz and MB/megabyte. —Locke Cole • t • c 16:06, 3 May 2021 (UTC)

IEC units in scholarly writings

@Dondervogel 2: At User:Thunderbird2/The case against deprecation of IEC prefixes, which you apparently have religiously updated over the years, there is a Google Scholars link that you use to determine how many articles are using IEC units. I note that currently for the 2020-2022 period there are 582 hits for MiB/GiB. That same search ran with MB/GB returns 44,900. Granted, some of those may be false positives (since MB/GB are more likely to occur as initials for other terms), so for clarity I ran the search using mebibytes/gibibytes and megabytes/gigabytes. There were 28 hits for the IEC unit, and 1,560 for the traditional metric unit. It would seem, even among research papers, that IEC units make up a small fragment, about 1.76%. Metric units accounted for 98.23% of the results. As I've already explained above, the wider media at large does not use the IEC units whatsoever, and their use in academic circles appears to be vastly outnumbered by the traditional metric units. —Locke Cole • t • c 16:06, 3 May 2021 (UTC)

And just to continue the "fatberg" sanity check from above, that returned 49 results for the same period. —Locke Cole • t • c 16:08, 3 May 2021 (UTC)

Dondervogel 2

I just stopped Dondervogel 2 (talk · contribs) from moving yet another conversation here from Talk:SD card. Is there any consensus for having multiple almost identical discussions? When I started this discussion it was with a goal of letting them see if they can convince editors here to change WP:COMPUNITS to allow for more IEC usage. Dondervogel 2 has forked this conversation into separate discussions unnecessarily as the issue is not with these individual articles, but rather with whether or not IEC units are something the editors here feel have reached a point where they should be used in Wikipedia-at-large. After the AN/EW closure I thought we might see some actual discussion, but instead I see Dondervogel has returned to starting forest fires and trying to fork these conversations. So again: Is there any consensus for having multiple discussions here on different articles? —Locke Cole • t • c 17:08, 3 May 2021 (UTC)

@Locke Cole: There's a longstanding unwritten rule on MOSNUM that discussions about changes to MOSNUM take place once a need for the discussion is established following disagreement on article talk pages. It was your decision to bring discussions on individual articles here and no one objected so I have participated in the discussions here. But it's important to distinguish between discussions about changes to WP:COMPUNITS (though I have proposed none) and discussions about individual articles about the implementation of COMPUNITS. It's time to stop your bullying. Dondervogel 2 (talk) 17:27, 3 May 2021 (UTC)

@Dondervogel 2: But you appear to be editing against longstanding consensus here that IEC units are generally not to be used. Methods for disambiguation already exist at COMPUNITS, which you are well aware of. The fact that you're trying to fork these discussions doesn't instill much good faith in your actions. It's time for you to stop acting against consensus here and consider other uses of your time. My involvement on this issue is recent, where you seem to be holding a very long grudge and just looking for excuses to undermine the current language that's been here. It's disruptive and unnecessary. —Locke Cole • t • c 18:16, 3 May 2021 (UTC)

Question to interested editors

Does the discussion about changes to SD card belong at the article's talk page or on MOSNUM? Dondervogel 2 (talk) 17:30, 3 May 2021 (UTC)

Put up a notice here, but unless you want to change something about the guideline, the actual discussion would be better off at the article's talk page. Primergrey (talk) 17:43, 3 May 2021 (UTC)

You've literally had two administrators tell you this is the best location for a discussion. I get that you'd rather hold these discussions off on obscure pages far from the prying eyes of people interested in the subject so you could force these units in over a long period, but enough is enough. Stop making forest fires. —Locke Cole • t • c 18:30, 3 May 2021 (UTC)

User:EdJohnston said that this would be "the best venue to solve the underlying issue" i.e. determine whether or not a change to the guideline is appropriate. If there are debates at multiple articles that all focus on the same piece of guidance, then a possible change to said guidance could only occur here. I wasn't aware that this went beyond the single article, SD card. Primergrey (talk) 21:01, 3 May 2021 (UTC)

Here's a list of article, template, talk and other pages that both Locke Cole and Dondervogel 2 have edited since 1 March 2021. Excluding WP:3RRN and this WT:MOSNUM there are 39, of which every one I've checked has involved IEC units. They range from x86-64 to WinZip to Template:Quantities of bytes but yes, SD card's there too. Of course there may be similar disputes involving only one of those editors or neither, or older disputes. NebY (talk) 22:42, 3 May 2021 (UTC)

The community has spoken on this issue. Thunderbird2 was without a doubt the most tendentious editor I ever experienced. I don’t know if the fact that years have passed makes this tendentiousness more forgivable or less. The purpose of a general-interest encyclopedia is to communicate clearly. There are many things in the world that should have had better naming conventions, like planetary nebula, which have nothing at all to do with planets, but a general-interest encyclopedia goes with the flow and doesn’t try to effect change in an “Oh, didn’tcha know”-fashion by using unconventional terminology that 99% of our readership has never seen before… all in the vain hope that somehow our leadership might catch on with the rest of the world.

As a general-interest encyclopedia, Wikipedia follows the standard conventions used throughout the dominant bulk of the computer industry. The vast majority of the computer industry, including industry leaders of DRAM like Crucial (here) Micron (here) use conventional terminology familiar to every single computer user, from the aficionado to experts. Industry-leading manufacturers of PCs, like Dell here) and Apple (here) also use conventional technology. If you want to buy DRAM at an online retailer, they are smart enough to use conventional terminology (Amazon, here). The use of non-standard terminology is confusing and a disservice to our readership.

Why are we even debating Thunderbird2/Dondervogel 2? He’s out in left field tilting at technology windmills. We have better things to do in life than deal with tendentious. Doesn’t Wikipedia have an expedient system to just say “No. Move on”? Greg L (talk) 05:50, 4 May 2021 (UTC)

Since ambiguous units create confusion, everyone seems to agree that disambiguation is necessary. The current guideline allows to use IEC units for disambiguation in articles where both meanings are mixed. So why is there so much clamour when someone does it that way? −Woodstone (talk) 07:22, 4 May 2021 (UTC)

Quoting you “So why is there so much clamour when someone does it that way?”. Because terms like “gibibits” are so unusual and unfamiliar, spell checkers don’t even recognize them. Not even one-half centiuno of the world uses the terminology. It’s obvious. We’ve been down this path over a decade ago and nothing is changed. The unfamiliar terminology just confuses. Greg L (talk) 13:42, 4 May 2021 (UTC)

In the specialised world of DRAM and SDRAM quite a few publications use units like GiB. Both by manufacturers and community sites. You underestimate the usage in the real world.−Woodstone (talk) 07:15, 7 May 2021 (UTC)

@Woodstone: You underestimate the usage in the real world. #IEC usage in print media, #IEC units in scholarly writings; and you grossly overestimate their use in the real world. —Locke Cole • t • c 07:48, 7 May 2021 (UTC)

@Woodstone:, thanks for confirming that. For me, the discussion started on Synchronous dynamic random-access memory on 24 April with repetitive reverts mentioning WP:MOSNUM, which were in fact unfounded. I'm just trying to use "64 Gibit RAM" instead of clumsy "~68.719 Gbit RAM" or clunky "64 Gbit RAM (here, G means 1024^3)" when mixed prefixes are required in an article and there's no clear preference for either variant. --Zac67 (talk) 10:07, 4 May 2021 (UTC)

Judging from the reposnes from Primergrey and Locke Cole, the consensus seems to be that the discussion on SD card should take place at WT:MOSNUM. Dondervogel 2 (talk) 08:14, 4 May 2021 (UTC)

But is "64 Gbit RAM" using G to mean 1024^3 or is it using it to mean 1000^3 and just not being exact? --Khajidha (talk) 13:10, 4 May 2021 (UTC)

I see that some bright spark has declared that gigabit is 10⁹ despite its virtually universal usage to mean 2³⁰ (1024³). Does wp:common name not apply? Does anyone anywhere use gibibit with a straight face? --John Maynard Friedman (talk) 13:59, 4 May 2021 (UTC)

Generally for any unit X, a gigaX is equal to 10⁹X. It is not surprising that making an exception for X=bit or X=byte causes confusion, especially since even for those units it is often used to mean just 10⁹ as well. Disambiguation is definitely the right thing to do. Professional circles use GiB and Gibit for the binary case and this seems a perfectly acceptable way to disambiguate the usage. −Woodstone (talk) 15:12, 4 May 2021 (UTC)

@John Maynard Friedman: The general problem is that the meaning of "Gbit" depends on context. Usually, "Gbit" means 1000³ bits. In special cases like memory capacities, chip sizes and such, it means 1024³ bits – for those in the know. Since we've got a slightly broader audience, WP:MOSNUM very reasonably requires us to disambiguate. The current dispute is about whether it's OK to use "64 Gibit" in cases where mixed prefixes are used within a page and there's no clear preference (like on SDRAM) (as I think is clearly mandated by MOSNUM), or if disambiguation requires clunky (imho) footnotes or similar. --Zac67 (talk) 16:13, 4 May 2021 (UTC)

Can you explain #IEC units in scholarly writings, above? Almost 99% of scholarly writings use the metric units. Professionals use the metric units (see anything from datasheets to tech notes to the packaging on professionally manufactured products like hard drives, memory or SSDs). Ten years on since the last time this was seriously discussed and the usage hasn't even wiggled the needle, but you think this means we should include it in an encyclopedia? —Locke Cole • t • c 15:26, 4 May 2021 (UTC)

@Locke Cole: We only had to care about scholarly writings, datasheets, industry commitees or leaders use if there was need to change WP:MOSNUM. There isn't. The policy is fine as it is because it allows prefixes in special, reasonable cases. So, please stop reverting edits that are made in those cases, conforming with MOSNUM. (In case you're still wondering, I'm not asking for the use of IEC prefixes for arbitrary figures like (user-visible) capacities of disk drives or memory cards.) --Zac67 (talk) 16:13, 4 May 2021 (UTC)

@Zac67: If your edits follow COMPUNITS, follow what our sources say, and otherwise aren't original research, you have nothing to fear from me. To date, no source from SDRAM has been shown to contain IEC units or derivatives. —Locke Cole • t • c 19:27, 4 May 2021 (UTC)

Why should it matter what the sources use? There's no obligation to locate such sources in WP:MOSNUM, it's just one of the cases. --Zac67 (talk) 19:36, 4 May 2021 (UTC)

WP:V and WP:NPOV spring to mind. I genuinely hope you were joking with that question though. —Locke Cole • t • c 19:57, 4 May 2021 (UTC)

Locke, "source-based units" became anathema here after editors were (accused of) picking sources only so they could, for example, display footballer's heights in metres. Really. It was part of a long conflict about Wikipedia standardising on metric units and it got ugly. We use sources, other style guides, and so on when thinking what MOSNUM should say, and if we're converting between units in an article, we need to make sure we understand what units the sources are using, but there are reasons beyond the IEC question not to let a reference determine the units used in an article. NebY (talk) 20:14, 4 May 2021 (UTC)

And yet COMPUNITS currently has when the majority of cited sources on the article topic use IEC prefixes; as one of the reasons one could conceivably use IEC units. Which I think is reasonable, but in the end, it's just a different way of tackling WP:V and WP:NPOV (specifically, WP:UNDUE). And given the data I've presented above, there seems to be very little use of IEC units compared to the traditional metric units for computing articles, so really it ought to be a moot point. But, here we are... —Locke Cole • t • c 20:53, 4 May 2021 (UTC)

when the majority of cited sources on the article topic use IEC prefixes looks fine but I fear it's being stretched too far. For example, if the majority of sources on RAM used IEC prefixes, that might justify using IEC prefixes in an article about RAM. But I've found IEC prefixes being used in articles about iPads to say how much RAM they have. There are 87 references for iPad 2. I haven't checked them all but frankly, if someone wants to make the extraordinary claim that most of them use IEC prefixes, they need to produce the extraordinary proof.

The trouble with that approach is that can mean article-by-article warfare that doesn't really end until someone gets sanctioned. I fear COMPUNITS might have to be more specific, for example by specifying precisely which family of articles use IEC prefixes. NebY (talk) 21:42, 4 May 2021 (UTC)

I wholeheartedly agree with what NebY wrote. To merely speak about “64 MB” DRAM in an article that is also discussing hard drive sizes does not…

A) necessarily require clarification that the two measures are actually slightly different, and

B) even if clarification was truly necessary, the need to point out the difference in the precise size of the two measures does not require the use of weird units that the vast majority of the computer industry has ignored, is ignoring, and will likely continue to ignore.

For the most part, it suffices to merely write that Alpha’s XYZ computer had 4 GB of RAM and a 1 TB hard drive but their XYZ-8 computer had 8 GB of RAM. In most cases, the reader really only needs to know—and only wants to know—that the XYZ-8 has twice the RAM.

It is a rare instance that mere mentioning of both attributes within an article requires “disambiguation,” which often really only means “explain the small difference in actual magnitude.” One example that quickly comes to mind is when one is writing about very arcane technical details pertaining to swapping data in and out of a RAM disk. And even then, one can make the technical details perfectly clear while using conventional units of measure that are commonly used in the computer industry and which 999 milliuno of our readership are perfectly familiar with.

Good technical writing is that which is suitable for its intended audience, informs and educates quickly, does so with ease and makes for an enjoyable experience, and does so without drawing attention to itself. Greg L (talk) 02:14, 5 May 2021 (UTC)

@Greg L: So, you essentially propose to ignore the ambiguity and use 1 TB RAM (implying 1024⁴) and 1 TB HDD (implying 1000⁴) side by side? Mind you, the "small" error is roughly 10 % (1.024⁴) – the deviance has grown quite a bit since we've used kilobytes and it won't stop there. Also, that ambiguity totally ignores Do not assume that the binary or decimal meaning of prefixes will be obvious to everyone. --Zac67 (talk) 05:11, 5 May 2021 (UTC)

@Zac67: Seriously? Seriously?? So, you tell me… just what part of my 02:14, 5 May 2021 post suggested that any responsible wikipedian should ignore an ambiguity that (legitimately) requires clarification (insofar as 64 GB of DRAM vs. the same in hard drive space)? I couldn’t have been any clearer. If you aren’t going to bother to read other‘s posts and fire off misrepresentations of what they wrote, how can you expect anyone to take you seriously?

First, like others wrote here, the “ambiguities” you profess to be deeply worrying about typically don’t really need clarification; the allegation that they do seems to be logical facades designed to dress up an agenda of persistently editing against consensus and flout a clear, well-hashed-out MOSNUM policy that makes perfect sense, goes against reliable media sources, and goes against the mainstream computer industry. Your position appears to be based on the mistaken premise that our adoption here will result in The World Following Wikipedia’s Great Leadership Into a New Tomorrow Where Logical Clarity and Scientific Goodstuff Prevails©™®. It’s a pipe dream. We tried it ten years ago (or something like that) and Wikipedia looked foolish for having done so. No one followed.

And secondly, wherever there is a genuine need for clarification, one can do so without using oddball Porky Pig’s gigiagigibits that our readership doesn’t recognize and would be afraid to repeat in the real world for fear of being laughed at. Whenever the mainstream computer industry perceives the need to clarify, they manage to pull off the task using conventional terminology everyone is familiar with. Greg L (talk) 00:48, 6 May 2021 (UTC)

Wikipedia aims to give readers information that's accessible and easy to contextualise, without tripping them up. We use common names and common units, we try not to be obstructively precise and we try to accept that it's not our mission to tidy up the world and right all its wrongs.

Readers are familar with memory coming in lumps of 1, 2, 4, 8 ... GB. They understand that in terms of functionality and ease of use, and they contextualise by seeing it expressed in the same way on sales pages, in popular media and in Wikipedia. They're not trying to calculate how many times the memory could be dumped into storage of 16, 32, 64, 128, 256 ... GB. They're not helped by being told something's 0.96 GiB, parenthetically or not; that just makes readers stumble.

Telling readers that WinZip's passed the 4-gibibyte barrier is overly technical and with no similar values for context it's potentially very confusing - is that something to do with the difference between bits and bytes, is a gibi a giga-giga? It can't simply be basically the same as 4 gigabytes or else Wikipedia would have said 4 gigabytes instead, right? "Disambiguating" complicates. Our readers know the difference between 2 and 4 and can tell K, M and G apart, and that should be enough.

Of course, editors matter too. We'd like readers to find a degree of consistency and comparability across Wikipedia articles, from IPad Pro (4th generation) to Samsung Galaxy S8 to Surface Pro 6, but that needs the editors to be on board. If you or Dondervogel 2 start converting each article, you'll often be reverted. If you counter-revert explaining it's per the MOS, we'll have more editors turning up here to change the MOS and make it express consensus more strictly. Sadly, we'll also have more editors thinking the MOS is entirely rubbish and best ignored, WP:PEACOCK and WP:COMPUNITS alike, and our readers will suffer. NebY (talk) 16:06, 5 May 2021 (UTC)

examples

Here are a few examples of the consequences for our articles, for those of us who find it easier to compare examples directly rather than follow a sea of links. They're from recent versions of a rather random selection of articles from this interaction list. These may not represent editors' best efforts, of course.

Article	preferring IEC units	not preferring IEC units
X86-64	This allows up to 256 TiB (248 bytes) of virtual address space. ... this would allow addressing of up to 4 PiB of RAM. etc	This allows up to 256 TB (248 bytes) of virtual address space. ... this would allow addressing of up to 4 PB of RAM
WinZip	Beginning with WinZip 9.0, ZIP64 archives are supported, eliminating ... the 4-gibibyte size limit [sole instance in this article]	Beginning with WinZip 9.0, ZIP64 archives are supported, eliminating ... the 4-gigabyte size limit
SD card	format supports cards up to 128 TiB or 140,737488355328 TB or 140 737 488 355 328 bytes (SI) or 154 742 504 910 672,534362390528 (Binary) and offers ... supports cards up to 2 TiB (2199023255552 bytes) ... but it requires the use of 64 KiB clusters etc	format supports cards up to 128 TB and offers ... supports cards up to 2 TB (2199023255552 bytes).. ... but it requires the use of 64 KB clusters
IPad Pro (4th generation)	[infobox] Memory 6 GiB RAM ... the RAM was increased from 4 to 6 GiB on the 128 GB, 256 GB and 512 GB models etc	Memory 6 GB RAM .... the RAM was increased from 4 to 6 GB (4-6 GiB) on the 128 GB, 256 GB and 512 GB models
Synchronous dynamic random-access memory	For reference, a row of a 1 Gibit DDR3 device is 2,048 bits wide etc	For reference, a row of a 1 Gbit DDR3 device is 2,048 bits wide

References

Template:Quantities of bytes

See discussion at Template_talk:Quantities_of_bytes#Recent_Edit_to_Table

Over at the talk page for Template:Quantities of bytes (edit | talk | history | links | watch | logs) in the section Recent Edit to Table the discussion has somehow switched to how JEDEC memory units are being given undue weight in the template (despite the presence of IEC units which, as shown above in media and scholarly use, are basically non-existent in sources or the wider media-at-large). Interested editors may wish to chime in there; I didn't initially move the discussion here because it started out innocently enough as a discussion about whether or not JEDEC terabyte should be in the table, but now the discussion has taken a turn to whether or not JEDEC units belong at all... I'm personally of the opinion that the IEC units are the ones being given undue weight, and we're effectively pushing a fringe theory by even giving them this much life outside of the IEC standards article(s), but more opinions would be appreciated. —Locke Cole • t • c 16:42, 5 May 2021 (UTC)

SD card

Why are the capacities in the thumbnail descriptions given in powers of 1000 (or 10^x where x is an int), e.g MB, GB, TB, while elsewhere they are in powers of 1024 (or 2^x where x % 10 = 0), e.g MiB, GiB, TiB? I'm concerned because as the capacities increase, esp for TB vs TiB and PB vs PiB, the difference in bytes is huge.

Highlighted inconsitencies of powers of 1000 and 1024, in revision https://wiki.riteme.site/w/index.php?title=SD_card&oldid=957885871

Fezzy1347 (talk) 17:12, 25 May 2020 (UTC)

Good question. My (limited) understanding is that the maximum capacities are binary (see exFAT), but that the published capacities are decimal. Dondervogel 2 (talk) 19:27, 25 May 2020 (UTC)

As noted by Fezzy1347 the difference is important. Hence the revert. Dondervogel 2 (talk) 10:14, 3 May 2021 (UTC)

@Fezzy1347: @Locke Cole: This edit introduced ambiguity into the article that was not previously present (for example, in the meaning of "TB"). I reverted it because disambiguation is required by WP:COMPUNITS, but my edit was subsequently reverted, re-introducing the ambiguity. The question now is how to remove that ambiguity? Dondervogel 2 (talk) 21:18, 11 May 2021 (UTC)

Let me point out one example of the problem I see. Near the beginning of the article, 'GB' is used in the decimal sense (eg, "formatting in excess of 2 GB (2000 MB)", whereas later a binary meaning is implied (eg, "up to 32 GB (34359738368 bytes)"), making it impossible for reader to tell which meaning is intended in specific instances, thus contravening COMPUNITS. I would not be surprised to find similar problems with MB and TB, but in situations like this I find it helpful to focus initially on a specific issue. By far the simplest solution is to make the decimal and binary meanings explicit. Does anyone have a counter-proposal? Dondervogel 2 (talk) 08:51, 14 May 2021 (UTC)

This ambiguous usage is widespread in the industry, making many unreliable many otherwise reliable sources unreliable. In all honesty, it is doing a King Canute to assert that MB/GB/TB etc always and only mean ^10 and that 'people' should use MiB/GiB/TiB when they mean ^2. It doesn't happen in the real world. Sales will go on using 10^ and engineering will go on using 2^. And sales will use 'B' for bits and engineering will use 'b'. The GiB notation has never gained acceptance and Wikipedia cannot assume that readers (and many editors) have ever even seen it, let alone know what it means. So the MOS must require that articles state explicitly the meaning intended when these abbreviations are used. --John Maynard Friedman (talk) 09:43, 14 May 2021 (UTC)

I disagree with your premise that an encyclopaedia cannot explain things (in fact I think that is the whole purpose of an encyclopaedia), but I think COMPUNITS already says what you are suggesting it should say. Do you have a proposal for bringing the article into compliance with COMPUNITS? Dondervogel 2 (talk) 10:37, 14 May 2021 (UTC)

No, that is not my premise. An encyclopedia, like a dictionary, records what is, not what should be. Otherwise it takes us into wp:right great wrongs. So the relevant policy is MOS:Abbreviations: initialisms should always be spelled out and disambiguated if necessary, on first use. So if an SD card is described as having capacity 1GB or 1 gigabyte then, per COMPUNITS, the article needs to spell out whether "giga' means 10⁹ or 2³⁰. I suppose a footnote might be appropriate to explain the notations and to refer to "learned institutions" preferred style but it is UNDUE to insert a mini-lecture inline in every article.

Anyway, to come back to your Let me point out one example of the problem I see. The case you cite is a blatant failure to wp:think of the reader. Any given article should use the initialism with just one and only one meaning throughout. (IMO, it also should have a comment note that advices future editors of that choice – I thinking of something like {{use DMY dates}}.) In the exceptional case where both meanings are needed, then it will be necessary to use (and explain) the MiB/GiB etc notation. --John Maynard Friedman (talk) 16:30, 14 May 2021 (UTC)

Sentence stricken because I see that the MiB notation is deprecated by COMPUNITS. (I approve). So explicit exponentiation is needed for the exceptional cases. --John Maynard Friedman (talk) 16:39, 14 May 2021 (UTC)

Are you suggesting each occurrence of 'GB' should be replaced with one of either 'GB (1000³ B)' or 'GB (1024³ B)', as applicable? Dondervogel 2 (talk) 17:15, 14 May 2021 (UTC)

I'm not exactly sure why we are even discussing this here? What happens on the SD card article should be resolved at talk:SD card. Your 'one example of the problem' is just an example of poor editing at that article: I don't see a general issue that needs to be escalated to the MOS talk page. I don't understand why the discussion was closed so peremptorily. Clearly there is a history to this?

(But for what it is worth, I'm suggesting that articles should use one meaning or the other, make it clear up front which choice has been made, and only in exceptional circumstances should the the same abbreviation (or name) be used to mean two different things. IFF that is unavoidable, yes, each instance needs a parenthesised qualification.) --John Maynard Friedman (talk) 19:40, 14 May 2021 (UTC)

Dondervogel 2 prefers using the obscure and generally unused IEC prefixes. They wish to operate against the longstanding consensus in WP:COMPUNITS. If they want to use IEC units, here is the correct place to have that discussion. If they want to discuss deviating from the suggested methods of disambiguation at COMPUNITS then here seems like the best choice (since their disambiguation method appears to involve using the IEC units which COMPUNITS explicitly says are "generally not to be used"). If they've moved off from that position then I don't care where they have the discussion. —Locke Cole • t • c 19:45, 14 May 2021 (UTC)

@John Maynard Friedman: I think the best place to hold the discussion about SD card is at the article talk page. However, Locke Cole closed an ongoing discussion at SD card and when I asked where it should be held, both Locke Cole and Primergrey preferred to hold it here. Locke Cole is seems to be now back-tracking and claims he doesn't care where the discussion is held. Let us now stop debating where it should be held and focus on IMPROVING the article. Dondervogel 2 (talk) 20:58, 14 May 2021 (UTC)

@John Maynard Friedman: I agree the meaning should not change within an article, so the trick is to pick one and keep that meaning throughout. The article starts with decimal GB and later flips to binary, and then flips back and forth like a yo-yo, creating an incomprehensible mess. Should we pick the decimal meaning or the binary one? Dondervogel 2 (talk) 21:08, 14 May 2021 (UTC)

Locke Cole is now back-tracking and claims he doesn't care where the discussion is held - I've done no such thing. Stop lying. —Locke Cole • t • c 21:16, 14 May 2021 (UTC)

I have rephrased my post (from "is" to "seems to be") to clarify that was the impression you gave. I accept it might have been intended differently. Please read WP:AGF and WP:CIVIL, and avoid personal attacks. Dondervogel 2 (talk) 21:31, 14 May 2021 (UTC)

Locke Cole said "if you have moved off that position then..." so it does appear that you are conveniently choosing the second part of their sentence because that is what suits you. It strains AGF when you do that sort of thing.

So let me be clear: right at the beginning of this I said The GiB notation has never gained acceptance and Wikipedia cannot assume that readers (and many editors) have ever even seen it, let alone know what it means. That remains my position. This notation does not solve your example of the problem because readers will not know what it means, any more than if you had suggested we use the Chinese character. The only practical solution is to spell out abbreviations clearly: if we mean 1,073,741,824 then that is what we should say. What we must not do in the same article is have GB mean 10⁹ in one sentence and have it mean 2³⁰ in the next sentence. --John Maynard Friedman (talk) 23:22, 14 May 2021 (UTC)

This is the correct place to discuss it. It is a problem that comes up in many computer related articles, so thrashing it out in a single article's talk page will just make it a discussion that has to be repeated for each and every article - what a waste of time!

To summarise the problem (using GB in the examples but also applying to the other prefixes): some uses of GB (giga bytes) means 10^9 and some mean 2^30. Some editors prefer to:

• Disambiguate them by using IEC prefixes like Gibi-. But these have failed to gain traction in the industry or popular media and remain relegated to some portions of academia.
• Disambiguate them via parenthetical notes or footnotes. It works but is repetitive and tends to clutter up the articles.
• Don't disambiguate them at all. Leaves the article clean but some readers will be confused when to use 10^9 or 2^30.

The short explanation is that memory this is directly addressable by the CPU (eg RAM, ROM) uses powers of 2 while practically everything else uses powers of 10 (eg hard drives, thumb drives and anything to do with rates or time). It is the directly addressable part that is critical. For RAM or ROM the CPU has to provide a certain number of binary address lines, so the size must be a power of 2. For devices that have some type of interface (eg IDE/PATA, SATA, USB), the address is sent as a number within a command. The remote device is free to remap that address in any way that it feels fit (eg, hard drives mapped a single address into cylinder, head, sector and the CHS numbers were usually not powers of 2), so the address is not constrained to powers of 2. This is anecdotal but based on my 3-4 decades of professional experience designing/programming computers.

Trying to explain to explain this in every computer article will just clutter up every article. Instead, I suggest that most articles are just left in the ambiguous state. After all, most readers don't really care about a 7% difference - most readers don't even know or care how much RAM their PC or phone has, only that it has enough. The people that care tend to already know when to use 10^9 or 2^30. But some articles that cover a broad topic like RAM, hard disk, or SD Card can spell out the appropriate form (or forms if it needs to specify capacity in powers of 2 and rates in powers of 10).  Stepho  talk  01:54, 15 May 2021 (UTC)

After a couple of false starts (GB and TB), I decided to use MB as a guinea pig. As far as I can tell, it is used primarily in the decimal sense, and there was already a statement to that effect near the beginning, which I have now qualified because there are exceptions. I have also labelled the exceptions. Does it make sense like this for MB? Dondervogel 2 (talk) 08:47, 15 May 2021 (UTC)

Hearing no reaction, I tried KB (binary use only) and GB (mixed use) as well. That still leaves TB. Dondervogel 2 (talk) 16:36, 15 May 2021 (UTC)

And now TB too. I do think it's messy though. Dondervogel 2 (talk) 17:15, 15 May 2021 (UTC)

MOS:TIME context

MOS:TIME starts with Context determines .... Is there, uh, any more to what kind of context that might be somewhere? Izno (talk) 19:57, 2 May 2021 (UTC)

Not sure about elsewhere but in Europe I'd say the 24 hour clock is the norm. Dondervogel 2 (talk) 20:02, 2 May 2021 (UTC)

There was a discussion here in 2017. You participated, but it still didn't reach any conclusion, so there was an RFC at the article in dispute but the only thing everyone could agree on was that we shouldn't express every time in an article in both systems eg 3.00pm (15:00). That article now uses 24-hour times in the three instances I saw (which you might not want to double-check, it's a grim article about a terror attack). NebY (talk) 20:35, 2 May 2021 (UTC)

It might have been good to have an ENGVAR type rule. "An article on a topic that has strong ties to the English language, an English-speaking nation, or the Anglosphere generally should use the 12 hour clock, otherwise the 24 hour clock". But that's not likely to happen. A lot of Wikipedia editors are from Europe or whatever, or if from the Anglosphere are educated, and they don't really believe that many Americans have no idea what "the explosion was at 14:47" means. It's true, but try telling that to a Wikipedia editor. So forget it, it's not in the cards.

I don't if Europeans etc. scratch their heads at "2:47pm". If they do, we should have a conversion program as we do for meters/feet. If they don't, the best we hope for is stare decisis: let the originating editor decide. Hopefully people are leaving articles as they found them; going around changing 12 hour time to 24 or vice versa (unless it's to make the article self-consistent) is pointless and should be rolled back on principle. Herostratus (talk) 23:50, 3 May 2021 (UTC)

I was born in England and have lived there for nearly 30 years, but I struggle to understand "12:15 am". I don't know whether it means 00:15 or 12:15. Any time between 12:00 and 12:59 (whether am or pm) would need to be disambiguated with its 24-h equivalent, regardless of subject matter. Dondervogel 2 (talk) 00:04, 4 May 2021 (UTC)

Not an Oxford man, I take it (see p.7 -- p.9 of the pdf). EEng 02:18, 4 May 2021 (UTC)

No need to struggle with 12.15 am. The “am” is an abbreviation for “ante meridian” (“before noon”) so it can only be 15 minutes after midnight. The only nonsense uses of am and pm are 12.00 am and 12.00 pm, which mean different things to different people. WWGB (talk) 02:54, 4 May 2021 (UTC)

...which is why strikes begin, armistices go into effect, and so on at 12:01am. EEng 03:36, 4 May 2021 (UTC)

which is obviously 2 minutes after 11:59 am. Dondervogel 2 (talk) 11:04, 5 May 2021 (UTC)

We'll be putting you in charge of the coffee and doughnuts. EEng 04:35, 6 May 2021 (UTC)

Happy to oblige. But if you order doughnuts at 12:01 pm, don't be surprised to be served at one minute after midnight. Dondervogel 2 (talk) 06:03, 6 May 2021 (UTC)

If it really is true that some people really do struggle with "2:15am" while others struggle with "14:15", then we really should have a conversion function. The code should be pretty easy. "The Wikipedia editor flung his laptop against the wall at 14:15 (2:14 am in freedom time)" and like that. Herostratus (talk) 18:20, 4 May 2021 (UTC)

As an American who prefers and uses 24 hour time, I am CONSTANTLY dealing with people who do not understand it. I once had someone tell me that they didn't like 24 hour time because they couldn't tell if 14:00 was a.m. or p.m. .... I mean, that's kind of the entire point of 24 hour time, that you don't have to figure that out. --Khajidha (talk) 18:29, 4 May 2021 (UTC)

@WWGB: I see every reason to be confused. Time does not stop at 11:59 and magically resume 2 min later at 12:01. My entire primary and secondary educations were delivered at British schools. I was first taught the 12-hour clock and accepted it for what it was (that's just how grown-ups do things). Then I was taught the 24-hour clock, at which point I realised not all grown-ups are alike. Some care about making themselves clear and some do not. Dondervogel 2 (talk) 06:25, 6 May 2021 (UTC)

Multiplication sign

@EEng: Regarding this revert: The raw Unicode character "×" appears in the 2021-04-20 database dump 1,298,705 times. The HTML entity × appears only 7701 times, in 3112 articles. (Except for a few articles that use <math>...</math> markup, which I haven't touched because sometimes math editors like to be able to search on words that represent characters in LaTeXish syntax.) I just finished a weeks-long process of converting all these HTML entities to characters. There have been a few thank-yous, but as far as I know no objections or reverts. Given that these are now essentially unused, it didn't seem right to keep recommending them. Does that make sense? -- Beland (talk) 04:05, 4 May 2021 (UTC)

• Agreed, as long as there is no obligation to use them, since they are hard to enter. Any editor should be allowed to type ×. An interested other editor or a bot might replace them with the character code. −Woodstone (talk) 06:40, 4 May 2021 (UTC)
  • That sounds like an argument for keeping the mention of the HTML entity here, then? I'm sure people and bots will continue to add them, just as we continue to get submissions like é for which there is strong consensus to change. And yeah, I just clean those up without complaining at whoever added them. -- Beland (talk) 21:26, 4 May 2021 (UTC)
• No it does not make sense. You went around changing symbolics to literals all over the place and now you want the guidance changed because the symbolics are now essentially unused? That's a joke, right? (Unfortunately we don't have a picture of a cat with feathers bristling from its mouth that I can post here.)
  We just went through this on WT:Manual_of_Style#Proposal:_replace_usage_of_template_character_combinations_such_as_–_with_"what_you_see_if_what_you_get"_such_as_"–". You should not be overriding the choices of those actually improving articles, and roiling the watchlists of actually productive editors for no reason, by mass-changing stuff like this according to your personal preferences or some fetish for mindless consistency. EEng 07:42, 4 May 2021 (UTC)

  I'm not going to respond to this because it is either mocking or doubting the sincerity of another editor, rather than sticking to the merits of the question. -- Beland (talk) 17:33, 4 May 2021 (UTC)

  But the real reason, of course, is that you can't explain why you're wasting time (yours and others') doing something with no discernable benefit. I note you haven't been able to cook up a reason to not respond to David Eppstein (below).

  I don't question your sincerity, but rather your competence and judgment. Since you have not, and apparently will not, explain the benefit of what you're doing, we are left to conclude that your motive is mere personal preference. Disabuse us if that's incorrect. EEng 00:47, 5 May 2021 (UTC)

  Regrettably, I cannot respond to this either, since it has doubled down on incivility and become explicitly insulting. -- Beland (talk) 01:27, 5 May 2021 (UTC)

  Well we agree on one thing: you're unable to respond. EEng 06:08, 6 May 2021 (UTC)

• No, it does not make sense. Editors should continue to feel free to add them, and you should find something more productive to do with your wiki-editing time than making pointless cosmetic changes. —David Eppstein (talk) 15:54, 4 May 2021 (UTC)

  The changes are not cosmetic in the sense of WP:COSMETICBOT, because they address search mismatch problems, as noted below, which I find worthwhile. I'm certainly happy to have editors input content in whatever format they like. -- Beland (talk) 06:24, 5 May 2021 (UTC)

• You have just made it harder for the average editor to know whether you actually meant "×" or "x". This is NOT helpful. You are NOT improving the encyclopedia. --Khajidha (talk) 16:20, 4 May 2021 (UTC)
  • For a long time I was also pondering whether the visual similarity justified using the HTML entity. But after I discovered we use "×" 1.2 million times, I took that as an indication that the vast majority of editors either have no problem seeing the difference or don't care about the distinction. (Otherwise, that would be an argument for replacing all 1.2 million instances with an HTML entity, but I expect that would generate complaints, given that going in the other direction did not.) After working with the character a bit, it actually doesn't seem all that hard to check whether or not it hits the baseline or is vertically centered, so in the end it's probably not much harder to distinguish than say, capital "V" from lowercase "v". It's also generally clear from context which character should be there, though putting the wrong character wouldn't make a semantic difference to readers anyway. Having a mix of "×" and "×" also creates a problem searching for this character when editing, since one would have to search twice. All else being equal, the vast majority of editors aren't familiar with HTML entity syntax, so converting them should make it easier for most editors to understand the wikitext. (Lots of these symbols seem to occur in articles about music, species, ships, and sports, with STEM articles being a minority.) -- Beland (talk) 17:33, 4 May 2021 (UTC)
    • When editing in desktop mode there's a link/button to place the Unicode character but on mobile you have to use the html entity. Just out of interest, how do you manage to type the Unicode character in the search box? If I was searching the code to find "2 [times] 2" I'd just search for a 2. nagualdesign 17:51, 4 May 2021 (UTC)
      • Well, my Android phone's default keyboard has "×" on it, right between "+" and "÷" on the punctuation page. All the entries on that page also appear in small type on the main QWERTY page, so if I want, I can easily enter "×" just by holding "w" for a few seconds. All operating systems have a means of entering characters that don't appear on the keyboard (see Unicode input) but for Wikipedia it's probably easier just to copy-and-paste into the search box from the edit widget or from any page where the character appears, such as multiplication sign. -- Beland (talk) 18:29, 4 May 2021 (UTC)
        • I guess my phone's too old. Holding the W only gives me a 2, and the only multiplication symbol I can produce is a *. nagualdesign 18:36, 4 May 2021 (UTC)
          • If you edit articles with non-ASCII characters, you may find it easier if you use a different keyboard (assuming you are talking about a software-defined one). Personally, I sometimes just tell my phone to edit in Desktop mode, which gives me access to all the special-character editing widgets without having to go copy-and-paste from somewhere else. -- Beland (talk) 21:26, 4 May 2021 (UTC)
    • But, Beland, you seem to be working from the premise that it has to be one or the other, which isn't true. The sole persuasive argument in your response above is the potential difficulty of mixed usage on a page. Are you saying that all your conversions from × were on pages which already had × somewhere? — JohnFromPinckney (talk) 20:13, 4 May 2021 (UTC)
      • Well, wikitext doesn't have to be easy to understand and re-use in other contexts, but I think it helps editor retention and productivity and knowledge dissemination if it is. I did not check whether or not the articles that used the HTML entity already had the Unicode character. Some of them definitely did, but I expect most did not. If both representations are in widespread use, it would be hard to know whether an article is using a mix or only one, without doing at least two searches, e.g. if one is making a change to all such instances. Search mismatches can also be a problem when one is searching across all articles (depending on the search engine and how one is specifying the query), on a small number of pages where "×" actually appears in the title, and on every page that uses HTML entities (because searching on the strings that appear when viewing the article does not work when editing the article). -- Beland (talk) 21:26, 4 May 2021 (UTC)

        Who says literal characters are easier to understand than templates or html? When the existing text has either of the latter two, a novice editor can see immediately how to insert the character using a standard keyboard. When the existing text has only literal characters, he or she may be stymied as to how to insert one using dropdowns and special keyboards and so on. This is just your surmise. EEng 00:47, 5 May 2021 (UTC)

        That's certainly a reasonable theory, among many others. In practice, I don't see how the idea that the HTML entity is easier to enter is compatible with the fact that the Unicode character apparently has been entered roughly 168 times as often. -- Beland (talk) 01:23, 5 May 2021 (UTC)

        I didn't say HTML was easier to enter. I said that it may be that it's easier for a novice editor. For all we know all the literals all over the place have been stymying and discourage novices left and right. Do you have a breakdown of how often HTML/template vs literal has been used by novice editors? Also, do you have statistics on how many potential novice editors did not edit an article with HTML or template, vs. how many didn't edit an article using literals? That's the data you need to support your thesis. EEng 03:13, 5 May 2021 (UTC)

Followup: Could you direct me to the BAG approval under which your bot-like 7k+ edits are authorized? Same for your edits re sdot (discussed elsewhere). EEng 05:34, 5 May 2021 (UTC)

I did not require WP:BAG approval; I was not using a bot. I manually and lovingly inspected every edit. The scale of changes was too small to justify writing a bot, and doing it manually allowed me to deal with weird circumstances and improve some surrounding text (like unconverted units). As I said, other editors thanked me for doing this.

I don't see how a novice editor would know how to enter an HTML entity from scratch, since novices are by definition not expected to be familiar with wikitext, and only a small minority of people are already familiar with HTML entity syntax outside of Wikipedia. Those who did see an existing HTML entity would have to figure out that several characters are converted into a single character, which is feasible since they have both the input and output available, but that seems like more thinking required than if the input and output are the same. In comparison, the pull-down menu is discoverable and usable by novices, and I expect its presence explains why there are not a ton of questions asking how to input this and similar characters. If you want to fund a usability study and put novices in front of a web browser and look at their success rate, I'm sure the Wikimedia Foundation would be interested to know where people are having trouble, and perhaps it would give us insight into the HTML entity question in general. That would be the best way to get the "gold standard" sort of proof you are asking for. Personally, I'm not going to put that much effort into researching this question, because I find the answer fairly obvious given the data we already have, because the already-implemented solution seems to have been supported by the community, and because problems like search mismatches are also important.

I've shared the data that motivated my change and answered the edit summary question "says who?". It seems everyone agrees that editors should be allowed to input wikitext in either style. Having now been fully informed, it seems folks aren't clamoring to hide the HTML entity syntax from this page, and I don't have a problem letting the revert that started this thread stand. -- Beland (talk) 06:24, 5 May 2021 (UTC)

You need to go further than merely not continuing to push for MOS approval of your bad edits, and stop making those bad edits. —David Eppstein (talk) 07:05, 5 May 2021 (UTC)

Beland, your activities clearly fall under WP:MEATBOT and probably WP:COSMETICBOT. You're an admin and are supposed to know this kind of stuff without being told. EEng 06:10, 6 May 2021 (UTC)

No response. Huh. EEng 23:00, 11 May 2021 (UTC)

Do we really need this little subsection?

Days of the week

• Days of the week are capitalized (Sunday, Wednesday).
• Where space is limited (tables, infoboxes, etc.) an en dash may be used for a range (Monday–Thursday).

— Preceding unsigned comment added by Tony1 (talk • contribs) 11:57, 14 May 2021 (UTC)

• I've been wondering about that for years. Capitalization is general English, which we don't teach at MOS unless there's been a chronic problem. That ndash can be used for ranges is straightforward and I can't see that belaboring it here is worth any evil averted. I did add something about abbreviations. [12] EEng 12:42, 14 May 2021 (UTC)
• Delete. Less is more. Herostratus (talk) 12:19, 23 May 2021 (UTC)

Historic unit name, usage

I noticed an editor changed WMGM-FM (New York City), an article about an FM radio station of the 1940s–1950s, to use megacycles instead of megahertz. I was always taught that the modern name of the unit should generally be used (since the CGPM adopted "hertz" in 1960; Broadcasting magazine adopted megahertz broadly in 1970). Which is correct? Sammi Brie (she/her • t • c) 08:10, 22 May 2021 (UTC)

Megahertz (symbol MHz) is correct, except in a verbatim quote. Dondervogel 2 (talk) 09:31, 22 May 2021 (UTC)

I reverted MMessine19 (talk · contribs) but there might be similar problems in other articles. Johnuniq (talk) 09:38, 22 May 2021 (UTC)

Hey Neutralhomer, do you want to check some articles!? Searching for "megacycles" finds KEPH + KCMK + KSOM (Arizona) and more. Johnuniq (talk) 09:43, 22 May 2021 (UTC)

MMessine19 is extremely active in articles on defunct stations, so there might be a good chunk of them. Sammi Brie (she/her • t • c) 17:55, 22 May 2021 (UTC)

@Johnuniq: Sure! So just search for "megacycles" and change it to "megahertz"? - Neutralhomer • Talk • 22:21, 22 May 2021 (UTC)

There is also Mcs vs. MHz and any other problems that I would not recognize. Johnuniq (talk) 00:34, 23 May 2021 (UTC)

@Johnuniq: I just realized something. Some of these, pre-1945, are going to rightly use "megacycles". Then, the FM band was from 42 to 50 megacycles. Megahertz wasn't a thing yet. It wouldn't be until Edwin Armstrong created it in 1941, it was adopted by the FCC in 1945, and the 88.1 to 105.9 FM band came about, they would later add 106.1 to 107.9 as the frequencies filled in. That was technically Megahertz. But pre-1945, the 42 to 50 frequency bandwidth was megacycles.

Now, I have no issues changing others like this, it was just outright incorrect. But some, I would have to leave them alone like like KYW (4th paragraph, 3rd sentence, "Also in 1942, KYW added an FM station at 45.7 megacycles, W57PH."). That, technically, is correct. Would these be an issue? It might take longer? - Neutralhomer • Talk • 03:42, 23 May 2021 (UTC)

@Neutralhomer: Hmm, no idea. Hey EEng, in 1942, did KYW_(AM) add an FM station at 45.7 megacycles (because "megahertz" would be anachronistic), or was it at 45.7 megahertz although in 1942 people weren't aware of that term? I would think that, since we are writing for a modern reader, we would use the modern name. Johnuniq (talk) 03:50, 23 May 2021 (UTC)

(I hope you're not mistaking me for some kind of Talmudic scholar because you're definitely on the wrong track there. But I'll do my best nonetheless ...) It was 45.7 megacycles. Also, it was 45.7 megahertz. Both are true statements, but only one uses the terminology we at WP use (and everyone else today uses), so that's they way our articles should talk. In quotations, you might want to change megacycles to a bracketed [megahertz]. It's probably a good idea to get some appropriate Wikiproject on board before going on a change spree, but that's not to say their local opinion should be deferred to -- we don't want another "she for ships" for radio stations -- see [13] and (shamelessly plugging my own essay) WP:YOURMAJESTYYOURSLIPISSHOWING. EEng 05:26, 23 May 2021 (UTC)

Just as US readers in the mid-1940s would have had trouble understanding the newly introduced megahertz, wouldn't modern readers have (slight) trouble understanding ye olde time megacycles? Or like grandpa Simpson, should we continue using "forty rods to the hogshead"? After all, it's unlikely that US citizens from the mid-1940s will be reading Wikipedia.  Stepho  talk  03:59, 23 May 2021 (UTC)

Yes. Actually, this should be asked at a suitable wikiproject. Their word might not be final, but it should be raised there to give people an opportunity to engage. Johnuniq (talk) 04:00, 23 May 2021 (UTC)

I suggest not editing verbatim quotes. Instead, link them like this "Also in 1942, KYW added an FM station at 45.7 megacycles, W57PH." Dondervogel 2 (talk) 08:17, 23 May 2021 (UTC)

I like Dondervogel 2's idea. Putting a WikiLink to hertz where one finds megacycles. The group for radio stations is WP:WPRS, so post that over at, of course, WT:WPRS. :) Would you all mind if I pinged in a couple of our long-time members for more opinion? You all already have Sammi. :) - Neutralhomer • Talk • 22:43, 23 May 2021 (UTC)

WP:MILFORMAT question

• Hmm I have a small question here about this sentence: "In topics where a date format that differs from the usual national one is in customary usage, that format should be used for related articles: for example, articles on the modern US military, including biographical articles related to the modern US military, should use day-before-month, in accordance with US military usage.". It's a little bit vague here to me. What's considered the modern US military? Is it possible to add a year or so when this rule has started within the US Army? I see a lot of biographical articles from WWII or the early Cold War which use MM/DD and to a lesser extends DD/MM. Cheers. CPA-5 (talk) 11:25, 23 May 2021 (UTC)

Huh, sounds like a weird rule. You'd think that the assumption would be that you'd use the regular national format. Most of our readers are not soldiers, they want to know when something happened and not how a soldier would describe it to another soldiers. Military organizations do a lot of things for their own purposes that don't necessarily have anything to do with what we're trying to do here. We don't call soldiers "warfighters" (as the Pentagon sometimes does) and so on. We also don't usually follow sources for formatting issues when it contradicts our MOS -- if a source has "October 8th" or the organization we're writing about uses that format, we still say "October 8" here. Not sure why the US Army gets special deference (altho there may be a good reason).

Sounds like a dumb rule to me. Well, right at the top of this page it says it's a "generally accepted standard that editors should attempt to follow, though it is best treated with common sense, and occasional exceptions may apply." Sounds like this'd be one of those occasional exceptions per common sense, so I'd just ignore that part of the rule (which who know when it was put in, why, by whom, and with what consensus or logical explanation). Herostratus (talk) 12:44, 23 May 2021 (UTC)

The format became standard during World War II. Since then most US government agencies have adopted it too. For our purposes, we define "modern US military" as the 20th and 21st centuries. Most of our readers use the DMY format all the time. US military people are generally dismissive of civilians who want to use the month first format. Now that the Make America Great Again movement is over and done with, we could consider making day-first the standard Wikipedia-wide. Hawkeye7 (discuss) 13:11, 23 May 2021 (UTC)

You may find last year's long discussion on this interesting, as well as the RFC in 2015, the guidance at WP:Manual of Style/Military history#Dates which I understand to be the product of a local consensus that is in accordance with general consensus, and the other discussions in this page's archives (about half of these). NebY (talk) 14:39, 23 May 2021 (UTC)

" Most of our readers use the DMY format all the time", sorry but I stopped reading after that. Guess we'll have to agree to disagree, probably on whatever else you wrote also. Herostratus (talk) 15:59, 23 May 2021 (UTC)

Sounds like an uncontroversial statement to me (or at least it would be if rephrased to say "... most of the time"). What is your reason for questioning it? Dondervogel 2 (talk) 16:23, 23 May 2021 (UTC)

. EEng 20:39, 23 May 2021 (UTC)

It's an opinion, and as such it does not need a citation. There are approximately 2 billion English speakers, of which about 300 million are Americans. It is rare to encounter MDY outside the US, so it is reasonable to assume most English speakers use DMY. I accept that the proportion of en.Wikipedia readers is larger in the US than in (say) Bangladesh, so it is still possible there are more Wikipedia readers who are MDY users than DMY, but it does not seem likely. My point is that Hawkeye7's opinion is a reasonable one to hold. Dondervogel 2 (talk) 21:10, 23 May 2021 (UTC)

And of course, as generally the more comprehensive, the English WP will also be read by many with English as a second or other language, as well. MapReader (talk) 21:22, 23 May 2021 (UTC)

The reason for the widespread adoption of the day first format is that it reduced errors, especially those caused by missing or misplaced commas. That's a good, practical reason, and why day-first would be adopted if we had to standardise on one format; but its not an overwhelming one. As EEng has pointed out in the past, it's not like people cannot read both forms when they are properly formatted (and we have banned ambiguous date formats). On Wikipedia we recognise that article writers have to do some cross-braining when sources are in one format and they are writing in another; hence the acceptance of the use of different formats in different contexts. What we don't accept is people edit warring to enforce their personal preferences. Hawkeye7 (discuss) 22:24, 23 May 2021 (UTC)