Wikipedia talk:Manual of Style/Dates and numbers

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

In a discussion over era style, is it a correct interpretation that those supporting the status quo don't have to give a reason?

Because that's being said at Talk:Isaiah#Undiscussed change from BC to BCE where an editor correctly reverted a change from BC to BCE but then started a discussion about it.If that is the interpretation I don't think that's what we meant the last time it was discussed (above). Surely both sides need to discuss reasons. Doug Weller talk 14:30, 5 January 2020 (UTC)

Stability/precedent seems an adequate reason to me. As you may recall, I think there is a strong general accessibility argument in favour of BC, which is no doubt why the big museums still use it. This is an article with very broad appeal. But we don't want to have this argument every time. Johnbod (talk) 14:47, 5 January 2020 (UTC)

It is my understanding regarding something else, that the Smithsonian (US, sorry) has standards for museum exhibit terminology. They might have this one. Gah4 (talk) 20:20, 10 February 2020 (UTC)

Precedent is only an adequate reason to retain in the absence of a valid reason to change, otherwise it holds no weight. Of course, we should just be deprecating BC/AD in favor of BCE/CE (unless there's really some overriding reason not to use it in a specific case) and be done with it, but if we can't even get people to agree to stop using she for ships in favor of it, what hope is there for this? . –Deacon Vorbis (carbon • videos) 15:32, 5 January 2020 (UTC)

Lol. You make a good point. I don't know how to have a discussion with someone who just says "That's the way it's been, I don't need to give any other explanation." That's wrong is so many ways. @Johnbod: what arguments might be good reasons to change an article from BC to BCE? I'd really like your opinion. Doug Weller talk 15:38, 5 January 2020 (UTC)

Note – factual correction to User: Doug Weller’s post above: I added my comment on the Talk page of Isaiah at 23:58 on 3 January. This was because it looked as if an edit war was going on, and I thought the matter should, instead, be discussed on the Talk page. At 00:14 on 4 January another editor reverted a change back to the established style. I reverted this revert at 00:17 on 4 January (i.e. going back to the established style), with an edit summary referring to the Talk page. Sweet6970 (talk) 15:48, 5 January 2020 (UTC)

Certainly not - I see Deacon Vorbis uses American spelling, and is probably unaware how much BCE is an American thing, which has certainly gained some traction in academic circles globally, but is often just mystifying to a general readership. We shouldn't be ramming the current American PC style down people's throats, with an arrogant assumption that this is obviously the right, indeed the only, way to do things. I personally would usually choose BCE for East Asian articles & those on Jewish, Islamic or Pre-Columbian subjects. I used to prefer it for South Asian subjects until I noticed that most local editors from the region used BC. Next time I see a talk page query asking what CE is, Doug, I will send them your way. Where was that recent discussion where museum usage got analysed? Johnbod (talk) 17:36, 5 January 2020 (UTC)

Yes, that's correct, they don't have to give a reason. In discussions of style, there's no argument where you can point to policy. It's really a matter of aesthetic taste so it really comes down to headcount. If you can get a supermajority on a reasonable quorum (say, I dunno, 6-3 at a minimum) I guess you can make a change. But I mean even that is WP:LOCALCONSENSUS and can be resisted on that basis, so it's not really worth spending energy on. Otherwise, stare decicis and give the person who wrote the article the courtesy of deciding which to use, per WP:BLP.

My suggestion is for editors who want to see BC [or: BCE] used in more articles is, write some articles and use your preferred format in them. Herostratus (talk) 16:25, 5 January 2020 (UTC)

@Deacon Vorbis::Why should? The majority of the general population (at least from my vantage point in Australia) still uses AD/BC. Since both forms are in common use, it is merely a preference (depending on your social circles) for which is used. WP:RETAIN is a good example to follow.

@Doug Weller:, if convincing arguments can be made to go to CE/BCE then the AD/BC adherents need to also give arguments to stay. If neither side can convince the other side then the status quo remains in place. I can't see any arguments that give CE/BCE precedence over AD/BC (or vice versa) because both forms are merely a preference along the same lines as using British or American spelling.  Stepho  talk  22:03, 5 January 2020 (UTC)

First, my comment was already resigned to this being a lost cause, and I don't want a side comment I made to get drawn out into a big thing, but since you asked: referring to a year as one of "our lord", or to Jesus as savior (via the christ suffix) is a gross violation of WP:NPOV. We deprecate usage of all sorts of honorific titles and phrases for similar reasons. There are other good reasons too, but from a WikiPolicy standpoint, this is probably the clincher. –Deacon Vorbis (carbon • videos) 22:20, 5 January 2020 (UTC)

Yeah, and the name Friday honors the goddess Frigg. So what? There's lots of stuff like that. Big deal. You want us to start writing First day, Second day, Third day, like Quakers? Of course, that would honor and favor Quakerism... EEng 22:28, 5 January 2020 (UTC)

As EEng said, regardless of the origin, if it's in common use then it is valid and can't be thrown out due to your preferences. Should we also throw out January? - that's named after a god as well. Having 7 days in a week is also derived from Christianity, which picked it up from Judaism. Should we throw that out too? The argument to throw out something that is in common use due to your beliefs is POV itself.  Stepho  talk  22:56, 5 January 2020 (UTC)

Facepalm –Deacon Vorbis (carbon • videos) 23:06, 5 January 2020 (UTC)

I agree. There are none so blind as those who will not see. This is not 'political correctness gone mad', it is simply a different perspective on the world. AD/BC is in common use among Christians, who are the majority among Anglophones. People of other faiths and none tolerate it but dislike it. The current solution to edit wars is to leave things as first written but it has to be possible if the subject matter demands it, for change to be made if a significant majority of subject editors believe it appropriate. This is not the same as Freya's Day and Saturn's day. --John Maynard Friedman (talk) 23:36, 5 January 2020 (UTC)

Yeah, actually, it is. And by the way, I have no faith (no faith in a sky god or other supernatural fairy tails, at any rate) yet I do not, as you say, "dislike" AD/BC. It's just an historical relic like so much else. There are real things in this world to get exercised about, and that isn't one of them. EEng 16:23, 13 January 2020 (UTC)

My interpretation is that the default is to the status quo ante. So technically it's correct to say that the side that doesn't want it to change doesn't "have to give a reason", in the sense that, if neither side gives a convincing reason, then the style should remain what it was.

But this is only a default position. If the side that wants to change the style does give a convincing reason, then the other side would need to address it, I think. I'd qualify that by saying that a global preference for one style or another is not a good reason — the reason should be specific to the article topic in some way. I'm not sure what sort of reasons those would be, unless it's agreed that articles specific to Christianity should use BC/AD, which is a possible position to take but one I'd expect to attract some controversy. --Trovatore (talk) 01:22, 6 January 2020 (UTC)

Answering the original question is easy: if someone wants to change existing style, they need to have a very good reason to make the change. Someone wanting to follow WP:RETAIN is under no such obligation, although they would have to respond to claims a change would be helpful. If Wikipedia was a company with editors on the payroll, we would do what we were told after venting at a faux meeting. However, the only reasonable way for volunteers to handle style issues such as BC/BCE or mdy/dmy dates is to strongly favor RETAIN unless a compelling reason to change is available. Otherwise editors would waste undue time and energy arguing about side issues, with the winnings going to the person with the biggest emotional investment who is also prepared to slowly edit war to victory. Johnuniq (talk) 03:02, 6 January 2020 (UTC)

Perhaps we need to make it clear that arguments need to be engaged with. Otherwise it becomes just a vote count and that's something we shouldn't be doing on an issue that involves NPOV, which this does in a way that doesn't so clearly apply to other styles changes. Note that 'first written' isn't the automatic default. It wouldn't make sense to argue that for an article begun with one era style 15 years ago which was changed in the first month.As Johnuniq says, it's the existing style we are talking about, and that's about how long an article has been stable with one era style, and deciding that is a combination of length of time and how frequently the article has been edited. As for names of days and months, I'm sorry but that's a complete red herring at best and could be seen as insulting. I've seen books by believing theologians that use BCE but none that try to make up new names. The same for books in the fields of archaeology and history. I agree with User:Trovatore that global preferences aren't a good reason - sadly them used too often. I revert drive-by changes to BCE just I revert drive-by changes to BC. — Preceding unsigned comment added by Doug Weller (talk • contribs) 08:26, 6 January 2020 (UTC)

In order for arguments to be engaged with, they have first to be made. Saying, for instance, that articles connected to Christianity (whatever that means) should use BC/AD is not making an argument, it is stating a preference. The preference needs to be justified with reasons, before any counter-argument can be made. Sweet6970 (talk) 10:16, 6 January 2020 (UTC)

@Sweet6970: can you please give us a few examples of arguments you'd find acceptable? Doug Weller talk 11:44, 13 January 2020 (UTC)

Combined reply to User:Doug Weller’s posts of 13 January on the Isaiah and MOS pages

(i) On the MOS page, you ask: ‘can you please give us a few examples of arguments you’d find acceptable?’. This sounds as if you are asking me to make your arguments for you. I don’t see that I have any obligation to do this. Also, I am not the only one you have to convince.

(ii) ‘If you think that the era style shouldn’t relate in any way to the religion in an article, could you please give some examples?’

Sorry – I don’t understand the question. Examples of what? My reasons are given at (v) below.

(iii) Re the word ‘substantial’- The guideline on retaining existing styles says: ‘Where either of two styles are acceptable, it is inappropriate for a Wikipedia editor to change from one to another unless there is some substantial reason for the change.’ https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#Retaining_existing_styles

(iv) The guideline says that any reason given for change should be specific to the article. This means that any reason should not be a general argument for one era style versus the other. I cannot think of any argument, either way, which would be specific to any article. This has the beneficial result that I do not make proposals for changing the era style of any BCE article to BC, and much time and effort is saved.

(v) I get the impression that you consider that if the subject matter of an article relates to a religion, then that should determine the era style, as if the views of the adherents of that particular religion should determine the era style. I don’t agree. (a) Wikipedia articles should not be tailored to the views of any particular group of people, religious or otherwise. (b) In any event, Wikipedia articles are written for readers. I think that the most likely reader of a Wikipedia article on a religious topic is someone who doesn’t know much about it. So an article on Christianity, for instance, is more likely to be read by a non-Christian than by a Christian. A practising Christian is unlikely to come to Wikipedia for information about their religion. If they want to learn more about Christianity, I imagine they would go to a Christian source. Similarly for other religions. A religious person may come to a Wikipedia article to find out what Wikipedia is saying about their religion, and perhaps to complain about it. Perhaps you think these complainers should be placated. I don’t agree. I think they should be resisted.

Sweet6970 (talk) —Preceding undated comment added 11:17, 14 January 2020 (UTC)

Well, I can certainly think of a reason specific to the article: if the article has many quotations that use one or the other style, then it may make sense for the article text to follow suit. EEng 20:42, 14 January 2020 (UTC)

To play Devil's advocate - if an article quotes many Japanese sources, should the date use the Japanese calendar with Japanese characters?  Stepho  talk  10:41, 15 January 2020 (UTC)

I agree with the (implied) preference of Stepho-wrs (talk · contribs). The purpose of MOS (including MOSNUM) it to facilitate uniformity across WP and promote accessibility to WP readers, not compatibility with (often conflicting) external sources. Dondervogel 2 (talk) 13:14, 15 January 2020 (UTC)

The Japanese example is a straw man argument that has the beneficial side-effect of destroying its own argument. If we had such an article, yes we would certainly give dates in the Japanese calendar but we would also give their Gregorian equivalent – just as we do with Anno Mundi for articles about Judaism and Anno Hegirae for articles about Islam. The MOS recognises equal validity for both BCE and BC (and BP for that matter), and it is not acceptable to declare that the style you don't like to be haram/not koshher/sinful. --John Maynard Friedman (talk) 18:07, 15 January 2020 (UTC)

The Japanese example is certainly a straw man (by design) but how does it destroy its own argument? Many people say "follow the source". This is a good principle for facts but a lousy principle for style issues where the sources may differ wildly from what is appropriate. Which was all the example was highlighting. Given enough sources, a good researcher could find sources using BC/AD. A good researcher could likewise find sources using CE/BCE. Suitable cherry picking of sources could then "prove" that the sources use one or the other and then the article is locked in to that preference because the sources say so.  Stepho  talk  20:59, 15 January 2020 (UTC)

If the preponderance of sources use a particular style and we can recognise that in a way that is consistent with our own Style Guide, we can and should do so. Thus, for the Japanese example and assuming(!) that the most respected RS were only in Japanese, we would give both the original Japanese regnal dates AND the Gregorian dates as mandated by our MOS. It seems to me that it is equally cherry picking to ignore the most respected sources in favour of an English language text, just because the former happen to be Japanese and the latter English.

The "preponderance of sources" argument is certainly a valid element of a case for change, though may not be enough. But where the existing notation seems to be as it is because some editor in the past preferred that style and thus falls under wp:I just like it and no other, then the defence of the status quo is merely an extension of that view.

No-one wants to see a weekly culture war over the era style in contentious articles, but it seems to me that we need to say something like "the era style in an article should not be changed without substantial consensus, based on strong supporting evidence, that the existing style is inappropriate". The preponderance of RSs is an example of strong supporting evidence. --John Maynard Friedman (talk) 15:25, 16 January 2020 (UTC)

(i) What does ‘substantial consensus’ mean?

(ii) As has been said, if the era style for the article is to be determined by the style of the majority of the sources, then this may result in editors cherry-picking the sources which use their preferred style. This could result in skewing the selection of sources, and could damage the quality of the encyclopaedia. Also, an unspoken dispute over the era style may be transformed into a dispute over sources. Sweet6970 (talk) 23:21, 16 January 2020 (UTC)

Do we have a WP:Wikipedia is not a law-book? This is suggested guidance, not the (unexpected) Spanish Inquisition.

(i) Consensus does not mean unanimity but by 'substantial' I hope to reduce the incidence of holiday-season flip-flopping. (I haven't seen much if any flipflopping but then I keep away from articles like Jerusalem – I don't even dare look at it, I bet it even has arguments about Julian v Gregorian). I am trying to provide a structure where well-meaning editors acting in good faith have a means to move forward. I am beginning to understand the frustration!

(ii) My suggestion is only that the custom and practice in respected sources is a factor that could be taken into account, not that it is decisive let alone a directive. --John Maynard Friedman (talk) 17:58, 17 January 2020 (UTC)

On large subjects (Roman Empire, Alexander the Great, whatever) for Wikipedians to attempt to assess the usage of "The preponderance of RSs" is madness. For more obscure topics, RS will normally use the version dictated by the matrix of date of source, originating country, academic vs general public as intended readership, with the religious history of the region concerned a poor last. Johnbod (talk) 18:25, 17 January 2020 (UTC)

I just want to point out that all I said is if the article has many quotations that use one or the other style, then it may make sense for the article text to follow suit. I didn't say anything about preponderance of RSs. EEng 01:32, 18 January 2020 (UTC)

Nobody said you did. For heaven's sake, it's not all about you.... Johnbod (talk) 03:46, 18 January 2020 (UTC)

Well for that matter, I wasn't addressing you in particular. For heaven's sake, it's not all about you. You've certainly been dyspeptic lately. EEng 03:53, 18 January 2020 (UTC)

Good night, and good luck

-EEng

If I had seen EEng's if the article has many quotations that use one or the other style, then it may make sense for the article text to follow suit earlier, I'd have said yes, that is exactly what I meant to say, then tip-toed quietly away before chairs start getting thrown at the mirrors behind the bar. But I will do so now: I agree with EEng, thank you and good night. --John Maynard Friedman (talk) 17:10, 18 January 2020 (UTC)

I agree with EEng – Always the best policy. EEng 18:59, 18 January 2020 (UTC)

"See links above"

What? There's nothing above about links. Doug Weller talk 12:50, 29 January 2020 (UTC)

I figured out that it's referring to the links to sections of Year in each of the two preceding bullet points. I couldn't think of a clearer way to refer to them, so I revised the text to just repeat them. Largoplazo (talk) 11:09, 8 February 2020 (UTC)

Binary prefixes

A user is destroying my work because of the unscientific binary prefixes guideline written here. 217.162.74.13 (talk) 09:49, 7 February 2020 (UTC)

Agreed. It's infuriating and illogical, but WP makes decisions based on consensus and the last seventeen debates on this have come down in favour of the BIPM-deprecated "binary-SI" prefixes (see the SI brochure, p143). Resurrecting the debate will only lead to a vast amount of heat and no light. Martin of Sheffield (talk) 10:39, 7 February 2020 (UTC)

I would describe previous exchanges of opinion on the subject as shouting matches, not debates. For what it's worth, take a look at this case against deprecation of IEC prefixes. Dondervogel 2 (talk) 11:13, 7 February 2020 (UTC)

(edit conflict) That's what I meant by heat and no light! I like your case. Martin of Sheffield (talk) 11:20, 7 February 2020 (UTC)

I understand these are just guidelines, not mandatory. 217.162.74.13 (talk) 11:37, 7 February 2020 (UTC)

It is not for the populace to decide. The standards bodies already did it. 217.162.74.13 (talk) 11:15, 7 February 2020 (UTC)

Wikipedia has it's own Manual of Style (MoS), which takes precedence over guidance of the BIPM and similar bodies. You are in the right place to discuss the MoS. Please consider opening an account. There's no obligation to do this but in my experience your views are more likely to be taken seriously if you do. Dondervogel 2 (talk) 11:21, 7 February 2020 (UTC)

Wikipedia should spread knowledge, not ignorance. 217.162.74.13 (talk) 11:25, 7 February 2020 (UTC)

MoS: "editors should avoid ambiguity". 217.162.74.13 (talk) 19:02, 7 February 2020 (UTC)

Many quantities have a natural (or not so natural) uncertainty. It doesn't help anyone to make claims more accurate than the physical )or non-physical) system. In the commercial world, most often one has to supply at least as much as stated on the package, but then you read the fine print. In the case of, for example, flash memory devices, there is some overhead such that even though the chips come in binary powers, the resultant devices hold less data. The usual SSD are rated at 240GB and 480GB, not what you might expect at 256GB and 512GB to allow for this overhead. I believe in the case of flash devices, there are bad blocks that are factory marked and never seen, but the result is uncertainty in the exact size. In many article, the precise difference between MB and MiB isn't needed, even if it is known. Gah4 (talk) 22:26, 7 February 2020 (UTC)

When I bought an 8GiB memory card a while back I would have been seriously annoyed if it arrived as "8GiB - well nearly and there are a few bits that don't work so we'll call it 8GB". Caveat emptor is all well and good, but the whole point of having standard units is avoid uncertainty. BTW, when you say "240GB", exactly what number are you meaning? Martin of Sheffield (talk) 22:37, 7 February 2020 (UTC)

The SSD on this MacbookAir has 233228928 1K blocks, for 238826422272 bytes. That seems to be what they mean by 240GB. Gah4 (talk) 01:05, 8 February 2020 (UTC)

Apple has been using powers of ten to properly show storage in macOS for over 10 years. Storage vendors normally use powers of ten too, so they are using the units correctly too. Linux will normally use binary binary units instead since 2010, as well as other programs. Microsoft is the laggard. 217.162.74.13 (talk) 04:40, 8 February 2020 (UTC)

Apple still shows RAM and VRAM in the wrong units. 217.162.74.13 (talk) 04:48, 8 February 2020 (UTC)

It seems storage vendors use the wrong units for RAM cache too. 217.162.74.13 (talk) 05:44, 8 February 2020 (UTC)

Data rates are also measured properly everywhere. 217.162.74.13 (talk) 04:58, 8 February 2020 (UTC)

Linux even uses binary units for data rates to avoid confusion. 217.162.74.13 (talk) 05:23, 8 February 2020 (UTC)

The IEC invented these binary prefixes with good reasons. And the rest of the world gave a big yawn and ignored them. It is not Wikipedia's job to force the world to use them.  Stepho  talk  23:04, 7 February 2020 (UTC)

The world has not ignored them, as shown above. Wikipedia should comply with international standards or it is a bad source of information. 217.162.74.13 (talk) 04:40, 8 February 2020 (UTC)

The anonymous user is correct. The world has not ignored the IEC prefixes. The question for us is not whether to disambiguate but how. There are way too many ambiguous WP articles. How do we fix them? Dondervogel 2 (talk) 09:00, 8 February 2020 (UTC)

A significant issue is the way that all other units are treated. The SI-enthusiasts insist that only the current SI units are used except for a few isolated cases in "non-scientific" articles. As MOS:UNITS says: "In all other articles, the primary units chosen will be SI units, non-SI units officially accepted for use with the SI, or such other units as are conventional in reliable-source discussions of the article topic". So why is there a special section (4.4.1) which flies in the face of this? WP:RF is not accepted as an excuse for any other units. We need to either accept that WP is wholey illogical about IEC units or prepare for a battle royal I fear. Martin of Sheffield (talk) 10:00, 8 February 2020 (UTC)

I stand corrected - the world has not ignored the IEC prefixes. Only a merely 99.99% of the world has ignored it. By the way, I'm a professional programmer. You'd think our engineer's love of accuracy would push us towards the IEC prefixes but we ignore them too. Hard drives, thumb drives, video file sizes, internet throughput, screen pixels are all routinely expressed in MB, GB, etc and very rarely in MiB, GiB, etc. It isn't necessarily the best way to do things but it is what it is.  Stepho  talk  10:28, 8 February 2020 (UTC)

Not really relevant, but if it matters to you I've been programming computers since 1974 and have recently retired from running a supercomputer centre. Martin of Sheffield (talk) 10:51, 8 February 2020 (UTC)

I'm a bit jealous of your job. I started in 1980 but spent my career happily working in embedded.  Stepho  talk  12:00, 8 February 2020 (UTC)

A bot that will correct basically all units for RAM and cache in all wikipedias is needed. 217.162.74.13 (talk) 10:32, 8 February 2020 (UTC)

I'm afraid that is impractical. Some editors will have abused the SI prefixes, some will have converted all or part to decimal and correctly used SI. That's the problem, by allowing this deprecated sloppy use for the last 10 years WP has built up a right old mess that only human inspection will be able to sort out. Martin of Sheffield (talk) 10:51, 8 February 2020 (UTC)

You can still avoid most of the manual work by only automatically correcting the cases when the number is an integer multiple of 2. And not attempt to correct "GB cache" which is likely flash. 217.162.74.13 (talk) 11:00, 8 February 2020 (UTC)

If somebody wrote "1024 MB" for example, they would actually mean "1024 MiB". 217.162.74.13 (talk) 11:06, 8 February 2020 (UTC)

Note that we are not talking about flash, as some SSDs follow a hybrid pattern. 217.162.74.13 (talk) 17:00, 8 February 2020 (UTC)

Possibly. Bear in mind that for some devices (floppy disks for example) the sizes are expressed in decimal multiples of a KiB: "1.44 MB" = 1.44 x 1000 x 1024 — yuk! Hence why I think a bot impractical.

But the integer check would take care of that. You would also correct things like "1 MB" in these contexts, but it's probably better to leave the rare other odd integer cases alone. 217.162.74.13 (talk) 11:30, 8 February 2020 (UTC)

I think the API needs to be enhanced for table support. 217.162.74.13 (talk) 11:34, 8 February 2020 (UTC)

Here are some of the most complex phrases one should be able to handle to do a good job: Radeon_Pro#Radeon_Pro_SSG. 217.162.74.13 (talk) 12:25, 8 February 2020 (UTC)

Bot or human is not yet relevant. What matters is now is that the present mosnum guideline is untenable. A more practical method of disambiguation is needed. (I just wish I could think of one). Dondervogel 2 (talk) 16:37, 8 February 2020 (UTC)

Just follow the standards: binary for RAM, decimal for storage, communication. This is what the bot would do. It would not touch the latter. 217.162.74.13 (talk) 17:00, 8 February 2020 (UTC)

You are explaining to us how one might implement a change to the guidelines that has not yet been agreed. The guidelines recommend disambiguation (a good thing) and then deprecate the only disambiguation method in widespread use (a bad thing). That is just stoopid and has done lasting damage to thousands of articles. We can't fix the damage until we first agree on a more sensible disambiguation method than is presently required. Dondervogel 2 (talk) 10:45, 9 February 2020 (UTC)

If you want a policy change to be accepted, it is important to show that the site can be quickly moved to a consistent state. 217.162.74.13 (talk) 14:14, 9 February 2020 (UTC)

There is no need for the change to happen quickly. It just needs to be in the right direction (for way too long we've been moving in the wrong direction). Dondervogel 2 (talk) 18:55, 9 February 2020 (UTC)

Unless someone wants to trigger an RFC and the associated avalanche of POV pushing, accusations and bad blood, this is just so much moaning. :-( Martin of Sheffield (talk) 22:04, 9 February 2020 (UTC)

It is better if you let a bot take care of most of the editing. 217.162.74.13 (talk) 20:04, 10 February 2020 (UTC)

Which frameworks already provide easy table handling? 217.162.74.13 (talk) 23:17, 10 February 2020 (UTC)

Dysfunctional guidelines

Let's not let this die. The existing mosnum guidelines claim to encourage disambiguation but then go out of their way to discourage this practice by putting unnecessary obstacles in editors' path. It's time we fixed this failure. My proposal is to acknowledge that use of IEC prefixes, though not the preferred form of disambiguation, is better than no disambiguation. Dondervogel 2 (talk) 12:11, 1 March 2020 (UTC)

In order this to be considered it should be absolutely clear how this disambiguation would work. Please give rules and examples of binary and decimal measures including disambiguation. &mninus;Woodstone (talk) 13:45, 1 March 2020 (UTC)

1. Many articles use MB and GB with two different meanings in the same article, often in the same sentence, as in (say) "The laptop had 1 GB of memory and a 500 GB hard drive." My aim is to discourage this practice.

2. This can be "improved" (disambiguated) very simply by writing instead "The laptop had 1 GiB of memory and a 500 GB hard drive."

3. The same sentence can be "improved" further (made more familiar) by writing "The laptop had 1 GB of memory and a 500 GB hard drive."

I put the word "improved" in quotes because the improvement in steps 2 and 3 is subjective, but I hope all will agree that #3 is better than #1, and #2 provides a simple stepping stone to get us there. Dondervogel 2 (talk) 14:42, 1 March 2020 (UTC)

(3) is not an improvement on (2). In example (2) it is clear that GiB and GB are different whereas in (3) you need to follow the note, then decide which definition to select. Would all readers realise that RAM was memory? Martin of Sheffield (talk) 17:00, 1 March 2020 (UTC)

The most important point of my post was to point out that the desired disambiguation is inhibited by the present explicit deprecation of IEC prefixes. Any objection to removing this deprecation? Dondervogel 2 (talk) 07:00, 3 March 2020 (UTC)

None from me, indeed I'd love to go further and deprecate the incorrect use of SI prefixes where binaries are meant. Martin of Sheffield (talk) 11:57, 3 March 2020 (UTC)

I searched the archives for "GiB" and found that the string occurs in archives 133, 135, 140, 143, 146, 148, 153, and 157. My recollection is that these prefixes have been extensively discussed. I therefore feel no change to the guidance should be made without a well-advertised RfC. Discussion under a subheading doesn't cut it. Jc3s5h (talk) 11:59, 3 March 2020 (UTC)

Replacing MB by MiB as "disambiguation" as proposed is likely to generate questions by readers not familiar with the unit MiB. As in the current state MB (etc) are the only mentioned units, it seems better to keep these as they are and follow them by an unambiguous measure, similar to what is done for conversions. When units are used in decimal meaning, it is generally not useful to convert to a binary unit. Therefore the simplicity of factors 1000 can be exploited to make clear what is meant. For example:

• a memory chip of 512 MB (512 MiB)
• a disk of 500 MB (0.5 GB)

−Woodstone (talk) 15:21, 3 March 2020 (UTC)

Encycolpeadia are meant to provoke questions as well as provide answers, that's why we have blue links. Your memory chip example is false though, 537 MB = 512 MiB and that's exactly the point – using decimal prefixes as if they were binary is incorrect as well as banned by the BIPM. Martin of Sheffield (talk) 09:14, 4 March 2020 (UTC)

That's exactly the point. Currently most of the relevant articles state measures like 512 MB, often without qualification, forced by the current state of the MOS. In WP MiB is banned, and MB as binary unit prescribed. As a cautious step towards improvement this really existing ambiguity could be resolved by adding in brackets an explicit disambiguation (512 MiB). −Woodstone (talk) 16:45, 4 March 2020 (UTC)

The only thing that matters is giving correct information to readers. The correct position: for values taken from sources, use the value that the source gives without alteration. If the source gives "100 MB" using MB as a power-of-two, give that, link "MB" to the power-of-two unit, and maybe specify that it's the binary unit in either a parenthetical note or footnote. Altering something that a source gives, to me, seems to be deception. It's not our place to decide that, when presenting information from another entity, that they did something "wrong" and so we should "correct" it without notice to the reader. In any other context this would be considered a big no-no. If we put a quote in an article like, "I saw a light in a third-floor window", but the speaker is talking about a building with only two floors, we don't silently "correct" the quote to read "second-floor window"; we print the quote and then note in prose that the speaker was presumably mistaken, with sourced information stating the building has two floors. When we offer our own conversions to aid the reader, use the standard units. Following standards is good, but not if it involves deceiving the reader. --47.146.63.87 (talk) 02:45, 5 March 2020 (UTC)

I fear you contradict yourself. The statements "giving correct information to readers" and "use the value that the source gives without alteration" are sometimes mutually incompatible. The problem is that whatever the source says, we are not allowed to use IEC prefixes. We don't adopt this position for measurements, if a source says that a widget is 2" long we express this as 51 millimetres (2 in) or the metric mafia will be after you. If a source says that a laptop has 8GB of memory telling the reader this is misleading because it is wrong. In a case like this we ought to use 8.6 GB or 8 GiB. The only real alternative is 8 GB [sic] which is ugly.

However, this level of detail is appropriate for individual cases, the discussion here is the ban on the use of IEC prefixes and the requirement to use SI prefixes in a way that competent bodies such as the IEC or BIPM deprecate. Martin of Sheffield (talk) 09:12, 5 March 2020 (UTC)

The average person doesn't pay attention to whether "GB" is binary or decimal, and unfortunately the world is not consistent, so the best I feel we can do is explicitly point out how a source is using it. We use customary units as primary in articles where the subject is usually discussed using said units. This is especially notable in historical topics that pre-date widespread SI adoption. There, things can get messy, since units were often not standardized and there can be multiple units with the same "common name", like all the different troy ounces, karats, and inches. We usually have to spell out the exact unit, such as French inch, at least the first time, and provide conversions to modern units. Something like that is probably the most satisfactory solution here as well. Yes, it may be a bit unwieldy, but unfortunately the world isn't neat and simple. --47.146.63.87 (talk) 00:22, 6 March 2020 (UTC)

References

Proposed disambiguation method

As a comment above states, it would be preferable to keep the values and units given by the sources. However as a courtesy to the reader an explicit conversion should be added, not just a footnote or link to the unit. The appearance of a disambiguation shows that an editor has mede a conscious decision about the meaning. So these are the cases:

source	meaning	disambiguation	note
512 MB	binary	512 MiB	converting to the same term MB (decimal) would be confusing
500 MB	decimal	0.5 GB	repeating the same would be tautological, conversion to binary not useful
512 MiB	binary	537 MB	no conversion would deter a reader not familiar with MiB
512 MB	decimal	0.512 GB	disambiguation is necessary to avoid the impression that 512 MiB is intended

Comments on proposed disambiguation method

I think that would be a useful step forward. I have added a fourth case. Dondervogel 2 (talk) 11:11, 5 March 2020 (UTC)

I've looked at {{convert}} but there is a dismissal of conversion routines at Prefixes for multiples of bits (bit) or bytes (B). Pity, since that would seem to be an obvious way forward. However the problem is not with ways forward, it is the ban in MOS. All the bots and conversion routines in the world will not stop a wikilawyer coming along and trashing any updates. Martin of Sheffield (talk) 12:06, 5 March 2020 (UTC)

The solution is simple, already existent, and embedded in the MOS. If the exact number of bytes is important, then specify the exact number of bytes. Headbomb {t · c · p · b} 20:52, 5 March 2020 (UTC)

Are you suggesting that writing 8,589,934,592 bytes is clearer than 8 GiB? Martin of Sheffield (talk) 21:19, 5 March 2020 (UTC)

The solution embedded in the MOS is dysfunctional. It does not lead to the desired disambiguation because it is far from simple, so no one bothers to implement it. Dondervogel 2 (talk) 23:03, 5 March 2020 (UTC)

It is perfectly functional and straightforward. That "no one bothers to implement it" is a reflection that people already know that an 8GB stick of ram is 8×1024³ bytes, and those that don't know it don't care because it is utterly unimportant to them. Headbomb {t · c · p · b} 02:34, 6 March 2020 (UTC)

In general people don't know, and there are multi-million dollar law suits to prove that. And some people do care (the same law suits prove that too). The purpose of the MOS is to provide clarity. It fails dismally in this regard. Dondervogel 2 (talk) 07:03, 6 March 2020 (UTC)

Find me one lawsuit where someone purchased an 8GB stick of ram and sued someone because they got 8×1024³ bytes of it instead of 8×1000³ bytes of it. Those don't exist because no one expects this result, and no one cares. These lawsuits exist because some people expected a 1000 GB hard drive to contain 1000×1024³ bytes and instead got 1000×1000³ ≈ 931×1024³ bytes. Headbomb {t · c · p · b} 22:21, 6 March 2020 (UTC)

They exist because consumers buy an N-GB drive expecting it to contain N GiB. They are disappointed to receive only N GB and they sue. It doesn’t make any difference whether N is 8, 64, 256 or 1000. The logic is the same. Dondervogel 2 (talk) 23:36, 6 March 2020 (UTC)

So your solution is to report 1TB hard drives as 931 GiB, which no one does, or ram sticks as 8 GiB, which no one does? Nope, won't fly. Headbomb {t · c · p · b} 23:38, 6 March 2020 (UTC)

My preference would be to report 256 GB as "256 GB" and 256 GiB as "256 GiB", but the proposal on the table (which is not my proposal, though I support it) is not about my preference. It is about how to succeed where the present guideline has failed so badly. Dondervogel 2 (talk) 00:18, 7 March 2020 (UTC)

It hasn't failed. There simply isn't a need for disambiguation in the vast majority of cases. And when there is one, you can do what the MOS recommends, clarify by writing the exact number of bytes. Headbomb {t · c · p · b} 00:20, 7 March 2020 (UTC)

Here's a few lawsuits about advertised vs real drive sizes:

• https://www.foxnews.com/story/western-digital-settles-hard-drive-capacity-lawsuit

• https://www.wired.com/2003/09/hard-drive-size-does-matter/

Most seem to have happened circa 2003-2006, and then the world forgot about it and went back to accepting fuzzy numbers as standard industry practice.

This reminds of how in the 1980s some home computers were sometimes advertised as 65kBytes (ie 65535 bytes). Whereas now we always say 64 kBytes (64 x 1024 bytes).  Stepho  talk  00:35, 7 March 2020 (UTC)

No.

* The most such recent court case I am aware of occurred in January 2020. A summary of the court’s findings reads

This is a putative class action concerning the meaning of the term “GB” (or “gigabyte”) as it is used to denote the capacity of electronic storage devices. Defendant SanDisk LLC, a manufacturer of such devices, uses GB on its product packaging to mean one billion bytes. Many computer operating systems, however, use GB to mean 1,073,741,824 bytes. Plaintiffs therefore contend that Defendant’s use of GB is deceptive, causing the average consumer to believe that Defendant’s products contain more storage space than they actually do. The Court previously granted Defendant’s motion to dismiss the original complaint pursuant to Federal Rule of Civil Procedure 12(b)(6) for failure to state a claim, but allowed Plaintiffs to amend their complaint. Plaintiffs subsequently filed an amended complaint, which Defendant again moves to dismiss pursuant to Rule 12(b)(6). The Court held a hearing on the instant motion on December 19, 2019, and it is now ripe for decision. For the reasons discussed below, Defendant’s motion to dismiss is GRANTED WITHOUT LEAVE TO AMEND.

* According to MOSNUM we do not say "64 kBytes" to mean 64 KiB. Instead we say 64 KB (or possibly 65 KB - dunno, it's confusing and that's the whole point), but never 64 KiB.

The court cases prove that disambiguation is important to our readers. (Whether it is important enough to individual editors is irrelevant. Both plaintiff and defendant are potential readers of wikipedia). The present guidelines are discouraging that disambiguation by deprecating the relevant international standards. Dondervogel 2 (talk) 08:03, 7 March 2020 (UTC)

I got no dog in this fight, but the court dismissed the suit. How does that support the notion that the distinction matters so much? EEng 10:04, 7 March 2020 (UTC)

The court dismissed the the action because the defendant had used GB to mean GB, whereas the plaintiff has assumed that GB meant GiB. Exactly the sort of confusion we are talking about. Martin of Sheffield (talk) 10:11, 7 March 2020 (UTC)

So a revised guideline might help unclog the federal courts by forestalling meritless thumb-drive suits? EEng 10:31, 7 March 2020 (UTC)

A while back it was decided that nautical mile could only be expressed in official thoeretical BIPM terms and that NOAA and the Admiralty were unreliable sources which could not be mentioned because they disagreed with BIPM in the practical implementation. Now we have BIPM and IEC being ignored because some editors don't like the standards. "When I use a word," Humpty Dumpty said in rather a scornful tone, "it means just what I choose it to mean — neither more nor less." (Lewis Carroll: Through the Looking Glass) Martin of Sheffield (talk) 10:23, 7 March 2020 (UTC)

@EEng: One of the stated aims of mosnum is "to promote clarity and cohesion". That aim is not well served by continued promotion of the ambiguous use of "GB", and deprecating use of international standards that have been in place for 20 years, and are increasingly followed by reliable sources. Dondervogel 2 (talk) 10:56, 7 March 2020 (UTC)

"Two-digit ending years"

…may be used in any of the following cases: (1) two consecutive years; (2) infoboxes and tables where space is limited (using a single format consistently in any given table column); and (3) in certain topic areas if there is a very good reason, such as matching the established convention of reliable sources.

I would propose explicitly limiting this to iterations of some annually recurring cycle whose boundary happens to be offset from the calendar year, such as school years and sports seasons. This would exclude irregular periods of time which, by whatever good or bad fortune, begin in one year and end in the following year—and which may, in practice, be closer to zero years or two years than to one year (2 ≤ TOTAL_DAYS ≤ 731, in fact). For example, the end years of #3 and #4 below clearly should be spelled out:

1. dropped out during the 2003–04 school year
2. coached the Fake News Bears to 56 wins in 2016–17
3. also had one son, Kenneth (1995–96), who died in infancy
4. {| class="wikitable"
   ! Title !! Years active !! No. of episodes
   |-
   | Some Stupid Podcast || 2012–13 || 19
   |}

―cobaltcigs 11:04, 1 March 2020 (UTC)

• What do you see as the value of adding this additional wrinkle? EEng 11:08, 1 March 2020 (UTC)

  My personal preference would be to abolish two-digit years even for "sports seasons, etc." and use unabbreviated years in all non-quoted contexts. But everybody agrees the "sports seasons, etc." usage does have established convention of reliable sources on its side, so I'll aim lower. I think the overall effect of this change would be similar to allowing two-digit end-years if the existing guideline's criteria (1) AND (3) are met, rather than the implied OR. Also, I don't believe criterion (2) is valid at all. If space in your infoboxes and tables is so limited that two more digits cause a problem, fix the underlying design flaw instead. So combining (1) and (3) into a single use case "two consecutive years, in accordance with the established convention of reliable sources, e.g. school years and sports seasons" and deleting (2) "cramped tables/infoboxes" would actually make this guideline simpler than the status quo. ―cobaltcigs 11:24, 1 March 2020 (UTC)

I agree with cobaltcigs. Any change in the direction of encouraging 4-digit years (i.e., discouraging 2-digit years after the year 99 AD) is a good thing. Dondervogel 2 (talk) 11:37, 1 March 2020 (UTC)

Please note that school years in Australia are usually within the same calendar year. Starts in summer, ends in summer, but summer is 6 months different to the what northerners believe in. Probably the same for many other countries in the southern hemisphere.  Stepho  talk  11:44, 1 March 2020 (UTC)

The rules are already too complicated to remember; I oppose creating a new wrinkle. Jc3s5h (talk) 12:32, 1 March 2020 (UTC)

• Any change in the direction of encouraging 4-digit years (i.e., discouraging 2-digit years after the year 99 AD) is a bad thing. Tony (talk) 02:49, 5 March 2020 (UTC)
  • Do you really think #3 and #4 are acceptable usage, or are you being sarcastic? You don't think variations like this look sloppy as hell? ―cobaltcigs 20:47, 5 March 2020 (UTC)
    • To me, 3 and 4 are easier to read. Tony (talk) 03:06, 6 March 2020 (UTC)