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

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...[1]) 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 [2], 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)

nagualdesign, is it possible that the person in question grew up in a culture that grouped digits differently? although i think someone dealing with monetary transactions should probably be expected to have a good grasp of numbers, i admittedly also have trouble working with large numbers in systems i am not adept in, even though i like to think i am mathematically inclined. i wonder what she would have written if you had asked her to write out "twenty-three thousand eighty" in numerals. dying (talk) 10:47, 26 May 2021 (UTC)

The digit grouping wasn't the problem, it was the extra zero in the middle. I'm not aware of any cultures that insert extra digits into decimal notation. Although I don't think her misunderstanding of how to write numbers was unique either. I guess twenty-three thousand and eighty would be "23,0080". nagualdesign 17:47, 26 May 2021 (UTC)

WWGB, i'm assuming that this is a reference to how long derek chauvin knelt on george floyd's neck, correct?

at one point, there was heated debate over the title of the article Eight minutes 46 seconds, the length of time chauvin was originally believed to have knelt on floyd's neck. unfortunately, it looks like this title now violates the new guideline. (note that the word "and" is not present in the article's title, although i am not sure if this had any impact on whether the numbers were spelt out. my conjecture is that it is merely a dialectal idiosyncracy.)

personally, i preferred not having a guideline addressing this situation, as i can easily see situations where i would prefer spelling out one number and using numerals for the other, situations where i would prefer spelling out both numbers, and situations where i would prefer using numerals for both. in practice, there seems to be a lot of variance on this issue, so i don't know if establishing a standard here would overall have a positive effect.

do you think having a guideline on this issue is a good thing? if so, is this a proper guideline to have? dying (talk) 10:47, 26 May 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

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 [3] [4] [5] 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
[6]	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
[7]	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
[8]	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 ...
[9]	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)

What I see is "512 MiB SDRAM" (Andersson 2017); "32 MiB SDRAM" (Engel 2019 and Gotzheim 2020); "128 MiB SDRAM" (Mundy 2015). Clearly about SDRAM and with no ambiguity. Mentioning the amount in MB would only muddy the waters. Dondervogel 2 (talk) 09:57, 30 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://en.wikipedia.org/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)

What's the true formatted storage capacity of an iPhone, iPad or iPod?

This article by the editor of Macworld explains the storage capacity of iPhones, iPads and iPods, and leads with "What is the true formatted storage capacity of an iPhone, iPad or iPod - how many songs, films, apps and games can they hold? And why is the true capacity lower than the advertised figure?". To make himself clear the author uses GB to mean 1000^3 B and GiB to mean 1024^3 B. The introduction to the article reads

• "Before we start, here's the reported capacities we've been seeing for each of the four current storage tiers for iOS devices. Bear in mind that these are approximate (we've seen some variation between models and versions of iOS), but they give an idea of the shortfall you should be expect from the advertised storage capacity.

   128GB: approx. 114GiB
   64GB: approx. 56.5GiB
   32GB: approx. 27.5GiB
   16GB: approx. 11.5GiB

• You'll notice that I've used the unit 'GiB', or gibibyte, even though iTunes clearly uses the unit GB. I'll explain why this is, and the difference between the two, in the next section."

The article was cited in several Wikipedia articles, but it seems to have been removed. I suggest reinstating the reference because it helps to explain the storage capacity in a language WP readers can understand. Dondervogel 2 (talk) 08:19, 30 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. [10] 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 [11] 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)

I'm just waiting for a definitive answer and what WPRS wants before I get going. I still intend to help, it just seems this is still unanswered and/or waiting for answers from WPRS and others here at MoS....unless I misunderstand. - Neutralhomer • Talk • 16:56, 25 May 2021 (UTC)

I don't know who's done what where, but there seem to be only about 10 articles left that give radio station frequencies in megacycles (not counting quotations). NebY (talk) 17:31, 25 May 2021 (UTC)

"Megacycles" should not be used, except in direct quotes. To use "megacycles" in articles about old radio stations would confuse readers, making them think that back then, frequency was measured with a different unit. It's not a different unit, just a different name for the same unit. Jc3s5h (talk) 18:52, 25 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 en.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)

• Hey Hawkeye do you know which year the US military has adopted this usage in WWII? And if let's say the year is 1942 right, does that mean every notable American soldier who dies before that year has to be used the old system or does the US military also convert them into the current system? Another question here is, which system should every American soldier's article who started before the adoption and dies after the adoption use? The old, the new ones, or both of them with the same system like Old/New Styles? Thus the old system is used until the adoption. I don't know what the US military's policy is if it's talking about these. Cheers. CPA-5 (talk) 13:05, 25 May 2021 (UTC)

  The U.S. Army Center of Military History Style (Section 6.1) says to use the military day-month-year dating system regardless of the time period being written about, the only exception being a verbatim quotation of the title of a work being referenced. Hawkeye7 (discuss) 20:27, 25 May 2021 (UTC)