Change "KB" to "KiB" across the application

VERIFIED WONTFIX

Status

SeaMonkey
General
--
enhancement
VERIFIED WONTFIX
16 years ago
10 days ago

People

(Reporter: Alexey Chernyak, Assigned: Alexey Chernyak)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

16 years ago
We are using SI prefixes for decimal multipliers (as well as some non-standard
prefixes) to denote binary multipliers. This long-developed practise is an
unacceptable use of SI prefixes and is just plain wrong. This is even explicilty
mentioned in SI publication.

We should follow the standards and use binary prefixes.

The correct binary prefixes and their abbreviations are:
Kibibyte (KiB) = 1 024 bytes.
Mebibyte (MiB) = 1 048 576 bytes.
Gibibyte (GiB) = 1 073 741 824 bytes.
Tebibyte (TiB) = 1 099 511 627 776 bytes.

Binary prefixes and their symbols, developed by Technical Committee (TC) 25
(Quantities and Units, and Their Letter Symbols) of the International
Electrotechnical Commission (IEC) with the strong support of the International
Committee for Weights and Measures (CIPM) and the Institute of Electrical and
Electronics Engineers (IEEE), were adopted in January of 1999 as Amendment 2 to
International Standard "IEC 60027-2: Letter symbols to be used in electrical
technology - Part 2: Telecommunications and electronics". Subsequently the
contents of this Amendment were incorportated in the second edition of IEC
60027-2, which has a publication date of 2000-11 (the first edition was
published in 1972). The complete citation for this revised standard is "IEC
60027-2, Second edition, 2000-11, Letter symbols to be used in
electrical technology - Part 2: Telecommunications and electronics".

Relevant URLs:
IEC 60027-2 SE -
http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=pro-det.p&HeIEC&Pu60027&Pa2&Se&Am&Fr&TR&Ed2
TC 25 -
http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=TCboard.p&committee=SC&TC=25
IEC - http://www.iec.ch/
SI - http://www.bipm.org/enus/3_SI/si.html
CIPM - http://www.bipm.org/enus/2_Committees/cipm.html
IEEE - http://www.ieee.org/

Some more explanations behind binary prefixes -
http://physics.nist.gov/cuu/Units/binary.html
(Assignee)

Comment 1

16 years ago
Oops
The & did not get converted in the URLs above.
These URLs should work:

IEC 60027-2 SE -
http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=pro-det.p&HeIEC&Pu60027&Pa2&Se&Am&Fr&TR&Ed2

TC 25 -
http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=TCboard.p&committee=SC&TC=25

Comment 2

16 years ago
Yeah, this is an IEEE "standard", but frankly, NO ONE does this, it'll be
confusing to users, it sounds stupid as hell, and I vote for a WONTFIX
personally. Sometimes a standard can be wrong.
(Assignee)

Comment 3

16 years ago
Noone does this because this standard is just 1 year old and people don't know
that it came out. This is exactly why we should support it and help bring it to
wider audience.

Creating a prefix for binary multipliers instead of continuing confusion with
other prefixes can't be wrong.
There currently are at LEAST 3 different meanings to word "megabyte" all
denoting different numbers.
People currently try to see meaning in all these different abbreviations: "kb",
"Kb", "kB", "KB", see bug 94961 for example.
Talk about being "confusing"!

Currently there is a total chaos with the use of these prefixes and their
abbreviations, and you call people who finally bring order to it once and for
all "stupid"?
marking wontfix

see the discussion in bug 64179 and bug 65710
and I never saw KiB, everyone is using KB and there is no reason to change this.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
(Assignee)

Comment 5

16 years ago
One of Mozilla goals is to be standard compliant.
This is a standard.Like it or not it is official and it is international.
In bug 64179 and bug 65710 I see people waving around SI notation and saying
things like "it should be this way because SI says so", absolutely failing to
note that SI itself explicitly says that it's prefixes *should not* be used in
this way.
A lot of people are unaware of existance of official binary prefixes, simply
because they were standardised so recently.

The goal of this bug is to bring people's attention to it and educate them about
this issue.
On a larger scale this change will bring far more (important) benefits than
disadvantages. And Mozilla can be a leader here.

Reopening
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 6

16 years ago
If you want to fix this feel free to provide your own Localization ens-US or
something.  Users have no interest in this.

The kilogram is a standard but I use pounds. The meter is standard but I use
miles. Just because a unit is standardized doesn't mean real users will use it.

Please explain why this isn't a dupe of the second bug
Assignee: asa → mpt
Status: REOPENED → NEW
Component: Browser-General → User Interface Design
QA Contact: doronr → zach
(Assignee)

Comment 7

16 years ago
The word "kilobyte" means 1000 bytes.
If that's what is meant everywhere across the application - no problem.
Except that "KB" would have to be changed to "kB" to really be SI compliant.
However I do believe everywhere the size of 1024 bytes is meant.

kilograms and metres are used in most of the English speaking countries.
But that isn't even the issue here.

There is no problem with using "pound" because you just can't misuse it.
We are using "kilobyte" which means 1000 to denote 1024. There *IS* a problem there.

Comment 8

16 years ago
No, in THIS industry, "kilobit" means 1024 bits. It always has. Now, LATELY
marketroids have changed them back to their metric roots so that they can
advertise larger capacities than items actually have, just as they USED to
advertise monitors  by tube size, not viewable inches (now both, thanks to
California) when up to an inch per side was hidden by the bezel.

The problem HERE is that the IEEE decided to change something in use for 50
years to conform to a DIFFERENT use. As Timeless said,if YOU want this fixed,
make a localization patch. There is already a standard in this Industry, in use
for much longer than the IEEE has been around.

As I said, sometimes standards are wrong.
Status: NEW → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → WONTFIX
(Assignee)

Comment 9

16 years ago
1. It is actually "marketoids" who have taken the term "kilobyte" from tech
slang and have brought it into the mainstream.
2. This "industry" hasn't existed for 50 years, and electronics of 50 years ago
haven't manipulated data of such sizes that would require any prefixes.
3. IEEE "has been around" since 1884. I'm sure word "byte" haven't even been
known for decades after that.
4. IEEE is basically what created this "Industry" and is what stands behind it.
5. Please stop displaying your incompetence.
6. If you talk of an already existing standard, please do point us to the
document that defines this standard and who defined it.
7. You singlehandedly label a standard that's been developed by some of the best
scientists from different countries over a number of years as wrong?
8. See 5.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 10

16 years ago
Ah but kilograms are masses and pounds are weights. We do misuse pounds.

Comment 11

16 years ago
Ah yes, I was wrong about the IEEE. I misrea the date. But kilobit and kilobyte
HAS been used for 50 years. I have a vintage core memory board that's 4KB is
size dating to the 60's. Punchcards contained linear programs that were
thousands of bits long. The fact here is kilobit and byte, and theyr
larger/smaller counterparts have been inuse far longer than this standard, and
this standard does not redefine KB and the like, merely create a new KiB to mean
the same thing that we already use KB for, so make a localization package to
change KB and it's ilk to KiB if you like.

Comment 12

16 years ago
Mozilla doesn't follow standards as an end in itself. Mozilla follows standards 
in order to ensure its long-term viability, by encouraging a Web in which 
multiple user agents can survive. For example, if Mozilla only supported the 
old Netscape DOM we could justifiably be criticized for not supporting the MSIE 
DOM. But if we support the W3C DOM then it's a lot easier to get away with not 
trying to keep up with MSIE, though this will break some pages for users.

The base-ten vs. binary prefix problem is not nearly so important -- confusion 
between the two has existed for the past twenty years or so, and the sky has 
not fallen. (Although I'm sure you could find some relevant anecdotes in the 
RISKS archive if you looked.) The overwhelming effect of using `KiB' and `MiB' 
in Mozilla would be to befuddle users, and nothing more.

Alexey, I promise you that when Mozilla-based browsers have at least 50 percent 
market share, *and* the binary prefix standard is still in effect, *and* you 
can find any published science or computing textbook which consistently uses 
the binary prefixes where appropriate, *then* I will try to get this bug fixed. 
But until then, we simply can't afford to be this confusing.
Severity: normal → minor
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → WONTFIX
timeless@mac.com wrote:
-----
"The kilogram is a standard but I use pounds. The meter is standard but I use
miles. Just because a unit is standardized doesn't mean real users will use it."
-----

And if you started abbreviating pounds "pnds", I would raise a bug stating that 
it should be "lb.".  It is not the unit that is in question, but the correct 
abbreviation.

Comment 14

16 years ago
As you might know, 1 kb = 1024 b.
As you might not know, 1kbit/s = 1000 b/s

http://www.dante.net/ten-34/tf-ten/rumours/bits_p_kbit.html
http://www.alcpress.com/tutorials/units/units.htm
http://www.google.com/search?q=kbit+1000+bit&btnG=Google+Search

I don't like the transition to KiB either. I, too, find "Kibibit" ridiculous.
But in the last few months some projects adopted the new standards:

"My personal esthetic distaste for the new terminology (gack!  "kibi" 
sounds like something I would feed my cat!) is less important
than following best practices.  I'm hoping it will seem less ugly as it
becomes more familiar. I don't like my duty much in this instance.
But my duty is clear." - ESR, http://kerneltrap.com/article.php?sid=434

And you might consider a look at http://slashdot.org/article.pl?sid=01/12/23/1421225

I personally think that the community will soon (= not yet, esp. non-nerds) be
ready for the transition, and at this point we should not consider this bug
wontfix any longer.
(Assignee)

Comment 15

16 years ago
Michael, actualy it's neither unit, nor abbreviation that is in question. It is
a case of using name (and abbreviation) of one unit while meaning another.

I call it "this" but what I really mean is "that".

And it appears that this does not bother the key UI developers of Mozilla. Which
I find surprising.
VERIFIED (for now, anyway).
Status: RESOLVED → VERIFIED

Comment 17

16 years ago
I find the wontfix resolution of this bug highly disturbing. Using proper SI
notation is similar enough for anyone to quickly grasp what is meant (KiB vs kB)
(most users probably wouldn't even notice the extra "i", but those who did would
greatly benefit); and would clear up the confusion over actual data sizes in the
shortest of time. It's even mnemonically clear: "KiB" is longer (and therefore
larger) than "kB" (1024 vs 1000 bytes).

Updated

15 years ago
Component: User Interface Design → Browser-General
(Assignee)

Comment 18

14 years ago
In (almost) 2 years since resolution of this bug the following happened:

IEEE (International Electrotechnical Commission) has accepted a standard for
binary multiples similar to the IEC (International Electrotechnical Commission) one.
ANSI (American National Standards Institute) has also accepted the IEEE standard.

The use of binary prefixes in applications has increased, especially on UNIX
platforms (Linux kernel for example).

Apple, Dell, Gateway, Hewlett-Packard, IBM, Sharp, Sony and Toshiba have been
sued this September in a class-action suit in US for "deceiving" the true
capacity of hard disk drives. This of course was due to misuse of "KB".

-----

Let's recoup the reasons for fixing this bug:

* Follow set international (and local) standards for the sake of correctness.
* Have datasizes displayed in an unambiguous way.
* Be on the forefront of technology and not lag behind.
* Avoid lawsuits (due to ambiguity)?

-----

To fix this, changes should be made to:

* Locales
* Documentation
* Hardcoded source (about:cache for example)

-----

Reopening bug.
Severity: minor → normal
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
-> Reporter
Assignee: mpt → alexey
Severity: normal → enhancement
Status: REOPENED → NEW
QA Contact: zach → nobody
Target Milestone: --- → Future
(Assignee)

Comment 20

14 years ago
Created attachment 135963 [details] [diff] [review]
patch to fix about:cache
(Assignee)

Updated

14 years ago
Attachment #135963 - Flags: superreview?(darin)
Attachment #135963 - Flags: review?

Comment 21

14 years ago
it's funny that a google search for "kilobyte KiB" (quotes excluded) resulted in:

Did you mean: kilobyte Kb

;-)

Comment 22

14 years ago
Comment on attachment 135963 [details] [diff] [review]
patch to fix about:cache

sr=darin

this is the right thing to do.
Attachment #135963 - Flags: superreview?(darin) → superreview+
Comment on attachment 135963 [details] [diff] [review]
patch to fix about:cache

r=bzbarsky if darin is happy with this, I guess.  Luckily, about:cache is not
something users ever look at...
Attachment #135963 - Flags: review? → review+
(Assignee)

Updated

14 years ago
Attachment #135963 - Flags: approval1.6b?
data point, I think we rejected KiB somewhere else once...like in the thread
pane / folder pane for the size of messages / folders.

I'll be the download manager / progress dialog doesn't do KiB either.

so this fix doesn't really fix it across the app.

see also:

http://bugzilla.mozilla.org/show_bug.cgi?id=124336
http://bugzilla.mozilla.org/show_bug.cgi?id=140898

"we rejected KiB somewhere else once", I think it was this bug!

see ian@hixie.ch's comments in http://bugzilla.mozilla.org/show_bug.cgi?id=124336#c4
(Assignee)

Comment 26

14 years ago
Yes, it was rejected 2 years ago, when the standard was still rather new and
hasn't received much recognition.
Things changed.

More international and national standards bodies have accepted it: IEC, IEEE,
ANSI, NIST. Even W3C accepts their use in it's recent releases:
http://www.w3.org/TR/mathml-units/#IEC-prefixes

Linux over past few years has embraced it more than any other OS. Across the
kernel and many applications.

Mac users had to face it in light of the recent lawsuit on Apple and others. In
fact, the majority of recent hits on the URL for this bug have been coming from
various Mac forums.

This change is needed to eliminate ambiguity that exists with data sizes today.

Yes the patch above is the first small step on fixing it across the application,
and fixes just the hardcoded values in about:cache and I plan to follow through
with patches for locale and documentation. These are hard to track as different
notations are used everywhere in the app.
(about:cache uses "k", UI uses "KB", and documentation uses "K")

Also documentation is undergoing rewrite in XHTML at the moment, and I might
wait till that is finished before making patches for it.

For more detailed info on the binary prefixes and their use please see the URL
in this bug.
comment 12 still applies. This isn't a matter of us wanting to avoid doing the
right thing, it's just that the majority of our target market (IE users on
Windows who don't know much about anything) would get confused by this, and we
cannot afford to confuse our users in our current precarious position.

This should remain WONTFIX until Mozilla and Mozilla derivatives have enough
market share that we can fix it without risking turning even more users away.

Comment 28

14 years ago
about:cache is for advanced users, and it makes sense for it to state sizes in
an unambiguous and technically accurate manner.  as for UI that is presented to
most users (like the download manager), i'm not sure how i feel :-/  ... i
totally get the argument for keeping to user expectations.

the other day when i looked at size values reported by dmesg under linux and saw
a mixture of MB and MiB, i was thoroughly confused.  i think when it comes to
low-level stuff, it is good to be unambiguous.  technically minded folks will
"get it" and they are the audience for things like about:cache.

Comment 29

14 years ago
Comment on attachment 135963 [details] [diff] [review]
patch to fix about:cache

This doesn't add any significant value to 1.6.
Attachment #135963 - Flags: approval1.6b? → approval1.6b-
I wouldn't be against fixing this just for about:cache for now.
As someone who has used Mozilla for a long time, I find it crazy that Mozilla is
still not, apparently, following the SI/IEC/IEEE/NIST/W3C/Iso/&c standard on
this throughout the app.  I agree that it is a minor thing in Mozilla (which, in
a way, makes it even more silly), so ambiguity will most likely not be
life-threatening or result in data loss (as misuse of these prefixes does often
-- I've experience) or anything (but it is certainly confusing).

I strongly agree with the sentiments of #28 which makes a very good point.

Also to counter a few other points that have been made:

(1) For those who say standards are silly, this is *not* a
_standardisation_issue_ (at least not in the normal sense).  The issue is
intentional, pointless and ambiguity-increasing _standards_abuse_.  If you do
not want to use standard prefixes do not misuse SI prefixes for your own purposes.

(2) For those who say they have never seen KiB
   (a) I'm guessing you use MS Windows then
   (b) If you don't like KiB then you can use the abbreviation KB (but only when
K stands for kilo -- not when it stands for kibi)



> (2) For those who say they have never seen KiB
>   (a) I'm guessing you use MS Windows then

Most users use Windows. The overwhelming majority of our target audience uses
Windows. If our goal is to prevent Microsoft from playing the biggest vendor
lock-in game in te history of the industry when they release Longhorn in 2006,
we have to get those users over to our products. We can't do that if we feel
unfamiliar, using terms that while technically correct would just be confusing
to them, not matching any other part of their OS.

I could see an argument for making this change on all platforms but Windows,
although I imagine in practice that would be a maintenance nightmare.
Attachment 135963 [details] [diff] checked in.  Leaving this bug open for other issues.
The fact that Kilo stands for 1000 and never 1024 is exactly what is wrong with
this standard.  KiBi is actually shorthand for the full name which is
KiloBinary, so they are still using Kilo to mean 1024, and somehow claim that
appending the word binary, which means having 2 states, to the end of it makes
this OK. The binary term might make sense when talking about bits, which do have
2 states, but none at all when talking about bytes which have 256 states.  So,
to clear up a problem of misusing one term, we are now misusing 2 terms and by
putting them together make things more clear?  I think not!

But this is something that ought to be discussed with the IEC I guess.  BTW as
near as I can tell this is NOT a standard recognized or even supported by most
of the groups listed in the previous comments as strongly supporting it.  Some
of these groups just say you can't use kilo for 1024 but do not appear to have
embraced this lame KiloBinary thing.
(Assignee)

Comment 35

14 years ago
SI prefixes like kilo don't stand for actual numbers like 1000
they stands for the power to which base of 10^3 is raised (thus they are called
"decimal prefixes" to represent the original base, and not "thousand prefixes")

kilo - 1 (10^3)^1 = 1000
mega - 2 (10^3)^2 = 1000000

names of some prefixes are indicative of this:

peta (derived from Greek "penta") - 5
exa (derived from Greek "hexa") - 6
zetta (derived from Latin "septo") - 7
yocto (derived from Latin "octo") - 8

IEC prefixes work in the same way, except they represent to which power base
2^10 is being raised. Similarly their name is "binary prefixes", and not "byte
prefixes" or what not.

kibi - (2^10)^1
mebi - (2^10)^2

and so on

The exponents are the same as for SI prefixes - thus the use of same names for
their creation. But the base is different - thus the use of word "binary".

Note kibi and mebi are the actual standard prefixes, and words kilobinary and
megabinary are given only to show the origins of prefixes and are not standard
words themselve.

All of the above listed standards bodies have officially accepted this standard,
and for more info on that, relevant history and references, please read the URL
provided in this bug.
Firebird does not want to do this for the front end that uses are LIKELY to see,
so any other patches in core components that propagate up to the FE must take
this into account. We have no argument with about:cache, for the reason bz cites. 
Well, about:cache gives the size of individual cached items in bytes.  This fix
only changes the data about total cache size amount used, etc.  Why not just put
this out in straight bytes too and avoid all confusion.

Change this:

Memory cache device

Number of entries: 	101
Maximum storage size: 	21504 k
Storage in use: 	1630 k
Inactive Storage: 	1175 k

List Cache Entries
Disk cache device

Number of entries: 	1840
Maximum storage size: 	50000 k
Storage in use: 	39582 k

To this:

Memory cache device

Number of entries: 	101
Maximum storage size: 	22020096 bytes
Storage in use: 	1669120 bytes
Inactive Storage: 	1203200 bytes

List Cache Entries
Disk cache device

Number of entries: 	1840
Maximum storage size: 	51200000 bytes
Storage in use: 	40531968 bytes

Comment 38

14 years ago
"put this out in straight bytes too and avoid all confusion." (e.g. 22020096 b)

Please NO! Long strings of contiguous numbers are *extremely* hard to read. At a
minimum, use thousands separators (e.g., 22,020,096 bytes). BTW: "kibi" is still
the better solution (e.g., 22,020 kibi), because it is the easiest to read.
(Assignee)

Comment 39

14 years ago
Using commas to divide numbers in groups of three to facilitate reading is
against international standards and practises, since in most languages comma is
the symbol for the decimal marker. The correct way to divide numbers in groups
of three is by placing space between them.
re comment #39, the correct way to divide numbers into groups of 3 to facilitate
reading is to use the seperator character defined in the localization file which
should be either ',' '.' or ' ' depending.  I am kind of assuming here that the
mozilla localization files support this.  Every other application I know of that
has localization features does.  The reasons I just strung all the digits
together were:

1.  That is the way they are currently displayed.

2.  I thought it would avoid this discussion of what the proper seperator
character should be.
re comment #38.

Putting out 22 020 kibi is wrong for the same reason that putting out 22030 k
was wrong.  It is just a number but with no units. At least KiB tells you
un-ambiguously that it is in units of 1024 bytes.  BTW the 22 030 k was even
more incorrect because in the non-standard convention use in computing, k meant
1000, K meant 1024.  So the old 22202 k was wrong for 2 reasons always should
have read 22020 KB, so that we knew the multiplier was 1024 and that we were
talking about bytes.

 
Sorry for spamming the list with so many comments, but am trying to keep each
comment to one topic.

It is usually uinwise to try to speak for others, but I don't think it was the
intention of the IEC in creating these new prefixes trht the computer industry
abondon decimalization and just continue to plod on dividing by 1024 instead of
1000 and use these new prefixes as vindication for this bad practice.  I believe
the actual intent is that we begin to correctly utilize the kilo- mega- prefixes
by dividing things by 1000 instead of by 1024.  I think the new prefixes were
created for cases where doing so just plain does not make sense.  All of a
sudden changing what everyone knows as a 1 GB memory card to be called a
1.073741824 GB memory card is just plain dumb.  So the new prefixes to cover
things like this were required and this becomes a 1 Gib memory card.

However, I feel that continuing to divide by 1024 in places where we could just
as easily divide by 1000, and worse yet, taking places where we currenlty divide
by 1000 and changing to divide by 1024 to universally use these new prefixes is
most likely NOT what the IEC intended.
this bug is already useless anyway, so I'll add my comment...

dividing by 1024 is much easier than dividing by 1000 - div. by 1024 (2^10) is
just a bitshift. This is especially true in javascript, where you can't easily
do integer division, but can easily do bitshifts.
I'm compleatly on the side of IEEE standards here, we should not devide by 1024
and use the KB (or kB) unit. However I also agree with comments saying that the
new Ki, Mi, Gi prefixes will be confusing to most users.

The solution is however quite simple, devide by 1000 instead. In fact, i would
think that this is what most users expect. If I ask my mom what kilo-byte is she
will most likly guess it's 1000 bytes. So when she downloads and sees a speed of
5KB/s she'll think that she's downloading in 5000 bytes per second.

comment 42 puts it rather nicly. he IEC probably didn't intend for engineers to
switch to using 1024 and use the new prefixes. But rather to switch to using
1000. If you want I could ask one of IEC members that worked on this, he's a
professor of mine :).

So to sum it up: To give the most userfriendly experience, especially for
non-savvy users, we should devide by 1000 across the mozilla applications.

Comment 45

14 years ago
I disagree totally. There are dozens of industries where specific words have
meanings different from common useage. Heck, even a nautical mile is different
from a statute mile. There are different pounds, gallons, ounces, etc.

I move we consider a kilobyte/bit, megabyte/bit, et al., discreet units BASED
upon their greek/latin roots, but with a specific meaning. Obviously this is
above the level of Bugzilla...

I still hold that in this industry, 9 out of 10 answers will be that a
kilobyte/kilobit is 1024. It's established. As for the prefixes themselves, I'll
grant you that kilo is immutable, it is 1000. Mega, giga, etc., however are
different. Mega means "great"; Giga means "giant"; Tera means monster. Yotta is
the second to last letter of the Latin alphabet. Zetta is the last. Peta and Exa
are created terms by the General Conference of Weights and Measures (Conference
Generale des Poids et Mesures).

I still argue the common use predates the standard, it's what is in use industry
wide, it is already well established, and to change Mozilla in this sense would
substantially alter user preceptions as we would suddenly differ from the near
unanimous current use, and cause confusion. This is bad.

Comment 46

14 years ago
Created attachment 142394 [details] [diff] [review]
patch to fix some locale stuff

This changes KB to KiB in metaData.properties and pageInfo.properties (I'm
pretty sure everything that uses these works in powers of 2).
(Assignee)

Comment 47

14 years ago
Comment on attachment 142394 [details] [diff] [review]
patch to fix some locale stuff

you forgot the Cache options.

Comment 48

14 years ago
I think that "KB", "MB" should be changed to "KiB", "MiB" on the mozilla web
site, not only across the application, see for instance
http://www.mozilla.org/releases/, it would be more correct

Comment 49

14 years ago
Created attachment 142480 [details] [diff] [review]
patch to fix some locale stuff

(In reply to comment #47)
> (From update of attachment 142394 [details] [diff] [review])
> you forgot the Cache options.
> 

Is this what you mean?
Attachment #142394 - Attachment is obsolete: true

Comment 50

14 years ago
> I disagree totally. There are dozens of industries where specific words have
> meanings different from common useage. Heck, even a nautical mile is different
> from a statute mile. There are different pounds, gallons, ounces, etc.

Um, the very exsistance of the SI organization has only 1 single purpose, to
remove such different meanings and establising a standard with the resoult of
lowering confusion.

Also I don't understand much of the arguments about KiB being confusing.
I'm pretty sure that anybody who knows what 
45 KB means can easily figure out what
45 KiB means.

Non technical people that don't know what KB is probably won't even notice that
it's written KiB instead.

On webpages, for those that belive KiB to be confusing, one can always write eg
45KiB (KB) which will be both correct as well as educate people.

In any case, starting to change the values in "hidden" areas as well as
documentation is a good first step even if people prefer to keep the main
UI-parts as KB for a few more years.
> On webpages, for those that belive KiB to be confusing, one can always write eg
> 45KiB (KB) which will be both correct as well as educate people.

This is entirely INCORRECT.  The sole purpose of creating the KiB abbreviation
was so that KB could un-ambiguously mean 1000 Bytes.  So, putting KiB with KB
following it is incorrect by any standard.
Why don't we just divide by 1000 instead of 1024 when we use the suffix KB? That
way we satisfy everyone on this bug: we'd be technically accurate, and we
wouldn't be confusing to new users.
(Assignee)

Comment 53

14 years ago
(In reply to comment #52)
> Why don't we just divide by 1000 instead of 1024 when we use the suffix KB? That
> way we satisfy everyone on this bug: we'd be technically accurate, and we
> wouldn't be confusing to new users.

That won't be technically accurate, and would still be ambiguous. In this case
technically accurate would be kB, not KB.

I don't understand this fear of KiB. This is nothing compared to the confusion
correctness of Mozilla's layout engine causes. And unlike Mozilla laying sites
out horribly when something is wrong, and users not understanding what the hell
is going on, in this case user can always look up what "KiB" means, and would
most likely be grateful to learn something new.
Ok, kB then. Whatever.

Users are rarely grateful to learn something new, actually. They just want their
computer to Work and be friendly. KiB is not something they are used to, and it
is thus not friendly.
(In reply to comment #53)
> is going on, in this case user can always look up what "KiB" means, and would
> most likely be grateful to learn something new.

You mean they wouldn't think that KiB is a totally stupid invention to solve a
nonexisting problem?
(Assignee)

Comment 56

14 years ago
(In reply to comment #54)
> KiB is not something they are used to, and it is thus not friendly.

In that case, Mozilla in itself is totally not friendly since 95% of web users
are not used to it, and we should stop all efforts and instead release rebranded
version of IE to keep them happy.

> You mean they wouldn't think that KiB is a totally stupid invention to solve a
> nonexisting problem?

I think they won't care and won't pay attention to it, as it does not affect the
browser functionality. Or do you think your nana will care? :o)
> In that case, Mozilla in itself is totally not friendly since 95% of web users
> are not used to it, and we should stop all efforts and instead release 
> rebranded version of IE to keep them happy.

This is, of course, one of the main reasons Firefox tries to fit in so well with
the OS on Windows -- with the result that Firefox is quite similar to IE in many
respects. Anyway, this is off-topic.
(Assignee)

Comment 58

14 years ago
The way I see it, this doesn't affect the functionality of the browser or "user
experience".

Those anal users that will notice it, will be grateful to learn something new.
Those users that are rarely grateful to learn something new, won't care to
notice something like this in the first place, since it doesn't affect them one
way or the other.

This is a pretty minor change compared to issues like File->Exit functionality,
or CSS with wrong MIME type not being applied to pages. They do affect browser
functionality and user experience. This doen't.

I think the fear of it is unreasonable, and is blocking progression, recognition
and adaptation of international technical standards set 7 years ago by IEC,
IEEE, ANSI, and recognised and endorsed by BIPM, NIST and ISO.

And you, Ian, should be the last person I should be explaining this to.

This is a matter of evangelizing Mozilla, and very mildly at that.

Comment 59

14 years ago
(In reply to comment #52)
> Why don't we just divide by 1000 instead of 1024 when we use the suffix KB?

Alexey, what is wrong with this proposal (except the kapital K)?
(Assignee)

Comment 60

14 years ago
(In reply to comment #59)
> Alexey, what is wrong with this proposal (except the kapital K)?

That it would indeed change the functionality.
And that ambiguity would still not fully disappear due to current abuse of SI
prefixes.

Comment 61

14 years ago
> You mean they wouldn't think that KiB is a totally stupid invention to solve a
> nonexisting problem?

Not only is it a non-solution to a non-problem, it goes against 50 years of
industry convention.
> > Alexey, what is wrong with this proposal (except the kapital K)?
> 
> That it would indeed change the functionality.

What's wrong with changing functionality?

> And that ambiguity would still not fully disappear due to current abuse of SI
> prefixes.

We should fix that, not work around it.

Personally I think this bug should be WONTFIXed and a new bug should be filed:
"Divide by 1000 and 1000000 when prefixes kB and MB is used"
(In reply to comment #62)
> Personally I think this bug should be WONTFIXed and a new bug should be filed:
> "Divide by 1000 and 1000000 when prefixes kB and MB is used"

That's fortunately worksforme as we only use KB not kB.
(well, if you ignore MB, but I doubt we use that much...)
Well, KB is IMHO equivalent to kB (though kB is more correct and thus should be
used). So the new bug should be:

"Divide by 1000 and 1000000 when prefixes kB and MB is used, for all cases or kb
and mb. We should also change to use the kB and MB cases everywhere".

My point is this:
* We shouldn't use kB (or KB) when we devide with 1024. It's technicall and
  mathematically wrong. Same thing with MB (including Mb, mb, and mB).
* We shouldn't use the KiB or MiB since most people won't know what they mean,
  and they're not going to go through the effort of finding out.

It doesn't matter what reason they were invented for, we are still free to
choose whichever devisor we chooses, as long as we use the correct prefix when
using them. And our clients won't understand the new prefixes, thus we shouldn't
use them, thus we shouldn't use the binary devisors.

Comment 65

14 years ago
(In reply to comment #64)
> It doesn't matter what reason they were invented for, we are still free to
> choose whichever devisor we chooses, as long as we use the correct prefix when
> using them. And our clients won't understand the new prefixes, thus we shouldn't
> use them, thus we shouldn't use the binary devisors.

While we are free to choose whatever we want, I think it makes sent to stay with
the binary-based 1024 system. This is still what operating systems use to report
filesize (in KB/MB), and I don't use why we should be doing anything different.

As to what we call it, I don't really think that KB/MB or KiB/MiB really matter
a great deal. If someone knows what KB means, and sees an incrementing number
with KiB next to it (instead of KB), I don't think there is going to be a whole
lot of confusion.
> While we are free to choose whatever we want, I think it makes sent to stay 
> with the binary-based 1024 system. This is still what operating systems use to 
> report filesize (in KB/MB), and I don't use why we should be doing anything 
> different.

So just because the OS does the wrong thing so should we? (This reminds me of
something my dad said about jumping and the brookly bridge.)

> As to what we call it, I don't really think that KB/MB or KiB/MiB really 
> matter a great deal. If someone knows what KB means, and sees an incrementing 
> number with KiB next to it (instead of KB), I don't think there is going to be 
> a whole lot of confusion.

Most people will probably think it's a typo, which makes us look sloppy ("how
could they miss an obvious typo like that").
(In reply to comment #66)
> So just because the OS does the wrong thing so should we? (This reminds me of
> something my dad said about jumping and the brookly bridge.)

(I hate that argument)

But your suggestion does make the filesize shown in the download progress dialog
and the filesize that file managers shows for the same file not match.

Comment 68

14 years ago
(In reply to comment #66)
> So just because the OS does the wrong thing so should we? (This reminds me of
> something my dad said about jumping and the brookly bridge.)

Note that I said we should match the OS behaviour in terms of using the
binary-based power of two system. I never said that we should call it the wrong
thing, just that I'm open to any of the following: kb/KB/KiB. Having said this,
the mean reason I said we should match the behaviour is that this is what users
expect in terms of numbers matching. As biesi pointed out, the numbers will not
match if we switch to the 1000-based system.

If I'm downloading an ISO (I've purposely chosen a large type of file for
demonstrative effect) from somewhere, I don't want the website's ftp server to
tell me its 600MB, my operating system to tell me its 600MB, but have Mozilla
disagree and tell me that its actually 629.1MB.

Comment 69

14 years ago
If we're going to change something, the multiplier is the WRONG thing to change.
I'm against changing to KiB a lot less than changing from 1024 to 1000. If it
wasn't for a new "standard definition" that wasn't needed, this conversation
wouldn't be taking place. The potential to see the new math for filesizes as an
error is MUCH worse than then noticing KiB.

Frankly, the idea of changing the multiplier comes across as more of a cure
that's worse than the disease, maybe offered in hopes of seing KiB as a
middleground to agree on. Both are bad, but changing from 1024 to 1000 is worse.
Why don't we just honor industry convention and stick with kB/1024 until there's
an actual movement towards KiB. This is not a "Jump off a bridge" argument, this
is an issue of USER expectations. We should be consistent not just with an OS,
but with an industry that has an extensive consumer face.
(In reply to comment #69)
> If we're going to change something, the multiplier is the WRONG thing to 
> change. I'm against changing to KiB a lot less than changing from 1024 to 
> 1000. If it wasn't for a new "standard definition" that wasn't needed, this 
> conversation wouldn't be taking place. The potential to see the new math for 
> filesizes as an error is MUCH worse than then noticing KiB.

You're thinking of it the wrong way around. kB = 1000 bytes isn't new math for
the majority of the planet. kB = 1024 is new and strange for every non-geek out
there. It is simply wrong, and has always been, even though it has been widly
accepted among geeks for quite some time.

> This is not a "Jump off a bridge" argument, this is an issue of USER
> expectations. We should be consistent not just with an OS, but with an
> industry that has an extensive consumer face.

Ask 10 non-geek users how many bytes 1 kB is. I bet that in a country using
non-metric units you'll get a few 'I dunno' and a few '1000 bytes'. Ask in a
metric-using country and you'll get mostly '1000 bytes'.

Comment 71

14 years ago
> kB = 1000 bytes isn't new math for the majority of the planet.

As stated above, however, 600MB now equalling 629,145,600 bytes _is_. 

> kB = 1024 is new and strange for every non-geek out there.

And standard for everyone involved in the IT industry.

> It is simply wrong, and has always been, even though it has been widely
> accepted among geeks for quite some time.

Not just geeks, anyone in IT. It's not wrong, it's merely at worst a
"non-standard" use of the kilo prefix. As I stated, KiB is bad, KB = 1000 B is
worse. So fine, if that's truly the situation, KiB or KB = 1000 B, then KiB is
my vote. I'm normally against useless changes, but at this point, I don't care.
So let's change kB to KiB, just make sure _every_ developer knows that this is
the new standard nomencalture to be used, or we'll wind up being inconsisted,
yet again.
> So let's change kB to KiB, just make sure _every_ developer knows that this is
> the new standard nomencalture to be used

..and every non-geek not know what we're talking about. I don't even think that
non-geek IT people knows that 1024B = 1kB in most apps.

Actually, this entire issue isn't very important to me at all, but I think that
we should think about who we are targetting with whatever change (or non-change)
that we do.

If we absolutly want to keep using 1024 as devisor i actually think that we
should use KB as unit. There are very few people that knows about KiB, everyone
else will think it looks weird. Geeks and non-geeks alike. So we better look
sane and no-worse-then-everyone-else, then look sane and mathematically correct.
Man, never has the painting-the-bike-shed analogy been more appropriate than in 
this bug.

We're not using the KiB suffix. It is too geeky at this point in time, and we 
can't afford that. mpt's comment 12 made two and a half years ago _still_ 
applies. Nothing that has been said since then has in any way changed that.

We _might_ want to change to power-of-ten divisors if the people championing 
this bug really feel that accuracy is that important. Either way, _that_ would 
be a new bug, not this one.

WONTFIX. Please do not reopen this bug unless the conditions mpt gave in comment 
12 have come to pass.
Status: NEW → RESOLVED
Last Resolved: 16 years ago14 years ago
Resolution: --- → WONTFIX

Comment 74

14 years ago
I think, as Hixie said, we went through this a couple years ago... V
Status: RESOLVED → VERIFIED
What has changed is that we've established:
 1) Most non-technical users think a kilobit is 1000 bits
    a) I say my local telco/cable broadband providers agree
 2) Technical users know there are a medley of technica situations where a
number is either 2^10 or 10^3.
    b) When you go to CompUSA, BestBuy, Microcenter, Amazon, I-don't-care, and
you look at a hard drive, do you stop and think "gee, is that 80 GB hard drive
really 80 GB or 76 GB?"  And have you ever had to wonder for a second when
looking at RAM?  And, really, does it make any sense to refer to a contiguous
linear address storage system in /8 or /1024 units, as opposed to /1000 units?  No.

So, non-tech users don't know, and tech users have to actually think about this
****.  They shouldn't.  There are better things to waste brain cells on.

And if you're really concerned that non-tech users will think it's a typo, make
KiB/MiB a hyperlink to a mozilla.org page.  It can explain the *RECENT*
standardization process that Mozilla and the rest of the IT industry is
following/adopting, and which Linux and FreeBSD have already adopted.  It can do
so in less than 200 words, and follow up with a clear explanation of 2^(k10) and
10^(k3)for the curious.  It makes Microsoft look slow and behind the curve and
let's face it: if you're using Mozilla you know that.  Now you know Mozilla.org
isn't slow and lumbering and behind the curve.

Comment 76

14 years ago
(In reply to comment #50)
> On webpages, for those that belive KiB to be confusing, one can always write eg
> 45KiB (KB) which will be both correct as well as educate people.

That wouldn't be correct. KiB and kB refer to two distinct values, so if the
file was eg 45 012 B, then we should write (Mozilla pages usually fix values at
1 decimal place): "45.0 kB (44.0 KiB)".
Product: Browser → Seamonkey

Comment 77

13 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2)
Gecko/20050329 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2)
Gecko/20050329 Firefox/1.0+

I was just about to file a similar bug. Just a few of my thoughts to add here.

If Mozilla is not going to use KiB, then it should at least change all the KB to
kB. At least it would then be "correctly wrong" (small k meaning 10^3) and not
just "wrongly wrong" (big K not meaning anything in the number world.)

However, KiB should be used really. It's correct and avoids any possible
confusion when considering whether it means 10^3 or 2^10. However, many comments
have suggested it would be confusing to those who don't know anything about
binary and just use Mozilla products. That would be fair enough if KiB was much
different to kB (or even the ghastly KB.) But it's not. I honestly do not
believe anyone will be confused when confronted with a file size in KiB. They
probably knew that kB stood for kilobytes, so this abbreviation to them is no
different; it could still stand for kilobytes as the first 2 letters are the
same. Ki(bi)B(ytes) as opposed to k(ilo)B(ytes).

I hope that this will soon become the norm in data size representation.
(Assignee)

Comment 78

12 years ago
*** Bug 276656 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 79

12 years ago
Just keeping track:

By now all standards organisations have finished their trial periods and have
accepted IEC prefixes for full-use.

* IEC
  o Standard: IEC 60027‐2, Second edition, 2000‐11, Letter symbols to be used in
electrical technology — Part 2: Telecommunications and electronics

* IEEE
  o Standard: IEEE 1541-2002, IEEE Standard for Prefixes for Binary Multiples

* ISO
  o ISO/IEC 18025 EDCS units (draft)

* ANSI
  o Standard: BSR/IEEE 1541-200x, Prefixes for Binary Multiples

* W3C
  o Units in MathML

* NIST
* SI/BIPM

The users now should be a bit more in touch with this since the prefixes have
also been implemented in most popular P2P applications and some disk utilities
for Windows, as well as GNU utilities and Linux kernel. (see the bug URL for a list)

This is not a question of if, but a question of when.
The only thing that creates the inertia holding this back is Windows OS, and
with such broad adaptation by standard organisations this may change soon.

With IE7 on the horizon, I find the 50% share target to be too optimistic, even
though we're already around 10%.

Comment 80

12 years ago
I don't understand why we adhere to standards that confuse and frustrate typical end-users (Bug 25537 and all 120+ duplicates, Bug 45375, etc.), but refuse to implement ones like this that actually matter and make things consistent.

"We won't change it because Microsoft won't change it."  

Geez, c'mon. The open-source community needs to stop playing catch-up with proprietary software.  It's only a matter of time before everyone adopts these. Why wait for Internet Explorer to do it first?  "We are an advocate for standards" - http://www.mozilla.org/about/

"This will confuse the end user."  

The typical end-user thinks kilo- means 1000, just like it does everywhere else in the universe except a few types of computer measurements (where it was originally an approximation anyway).  The ones who are already used to thinking of KB = 1024 are smart enough to figure this out in a few seconds.  This is *less* confusing.  Especially if you make "KiB" a link to an explanation (or just a tooltip: "KiB = 1024 bytes").  

Worst case: they'll blink twice, read a paragraph of explanation, and move on.  Any confusion would be a one-time event.

"If Mozilla is not going to use KiB, then it should at least change all the KB to kB."
"We _might_ want to change to power-of-ten divisors"

NO.  That would be incorrect, since we aren't reporting in multiples of 1000.  We *should* report sizes exactly the way we currently do, in multiples of 1024; like everyone else reports file sizes. The numbers would not change.  But we should do so with an unambiguous unit symbol.

This is more accurate, it's simple to learn, it's endorsed and recommended by pretty much every important standards organization, and it makes sense.

W3C notes on units in MathML: http://www.w3.org/TR/mathml-units/#prefixes

"A plea for sanity": http://www.xciv.org/~meta/2005/02/25/#2005-02-23-units
Jon: We don't support all standards. Some standards are good, some standards are good for certain audiences but inappropriate for most end users, some standards are just plain bad. (Some standards contradict other standards.) In this particular case we have opted to follow this standard where it makes sense (e.g. in about:cache), and not where it doesn't (e.g. the download manager).
*** Bug 333234 has been marked as a duplicate of this bug. ***
Duplicate of this bug: 414304

Comment 84

10 years ago
Something should change now we have the opportunity with plurals just introduced( http://ed.agadak.net/2008/01/plurals-downloads-statuses-for-yous )

I can't believe what a simple change this would be, it would confuse no one who didn't care and enlighten people who did.

Comment 85

10 years ago
This is not about simplicity but about usefulness.
And the change as such is not useful.

Comment 86

10 years ago
(In reply to comment #85)
> This is not about simplicity but about usefulness.

This is not about usefulness, it is about correctness. 

And the change would make Mozilla correct. Also, the change wouldn't be unuseful either.

Comment 87

10 years ago
"And seven years later, the chicken was still alive."

After re-reading the comments, the only reason I see standing out from the others against using KiB is "the users will get confused".

Well it's just not true. John Doe will assume KB, kb, kB, Kb, kib, KiB and whichever variant coming with it is correct and they are all the same if anything. All he wants is to download this big file, take a coffee and come back to see it completed. He frankly doesn't care the least about however the size is named, as long as there IS a size.

In the worst case, he'll think it's a typo until the day he looks it up on wikipedia or whatever else.

I think this at least is pretty clear. As for the idea of keeping KB because it's used by Windows... who had it? Today, Windows Vista (and older versions) gives bytes counterparts and take up that excuse to avoid having to change the KB to KiB. It's pretty obvious Microsoft cares even less than John Doe about how the file size is determined.
Both people and applications will slowly adapt to that standard anyway - a lot have started. Having Mozilla adapt to it would be a step already.

Comment 88

10 years ago
If ISO had wanted to help solving a real-world problem of confusing usage ('kilo' used for 1024), they shouldn't have added to that by redefining traditional measures. Imagine the uproar and confusion if ANSI would define 1 yard := 1 meter!
(Mind that "byte" as such has had different lengths in the past, from about 4-10 Bits!)

ISO could have defined "kilo Octett" to represent 1000 8-Bit-Units, and everything would have been fine. People might have used it (or not - who knows).

As things stand, kiB & Co. are just confusing and thus not helpful.
This bug is WONTFIX for a reason, see Hixie's summary ;-) in comment #81.

Comment 89

10 years ago
How on earth is is confusing and unhelpful?!

Have you done any research in to that at all or are you just randomly assuming it? I got my Gran using Ubuntu which at several times uses KiB, that wasn't wan issue at all, not an eyelid bated, the world didn't suddenly get turned upside down. Since then I've had several different non-technical users use Ubuntu and a few other applications use it, I've yet to see any to them have a problem with it.

I'm sure Microsoft could argue having more than one browser is confusing and unhelpful! But we all know that'd just be FUD.

So I at least ask for a constructive reason!

Comment 90

10 years ago
(In reply to comment #87)
> After re-reading the comments, the only reason I see standing out from the
> others against using KiB is "the users will get confused".

"Regular" people in metric countries are more likely to be confused by the way things are now.  Technical people already know about the discrepancies.

Instead of using "KiB = 1024 B", you could also just use the SI prefixes correctly: "kB = 1000 B".  What's the benefit of dividing into powers of two when the file lengths are arbitrary?

(In reply to comment #88)
> they shouldn't have added to that by redefining
> traditional measures.

Whatever are you talking about?  "kilo-" has meant "1000" for hundreds of years, and still does in almost every discipline.  Even in computing, "kilo-" means "1000" in many situations, as it has since the first computers were developed.  It's just the idiosyncratic "K = 1024" Microsoft definition that we're trying to clean up.

Comment 91

10 years ago
(sorry for all my typos earlier, I'd only had a couple of hours sleep)

Another point to consider is even if people don't understand KiB meaning KibiByte, a lot will probably think KiB is short for KiloByte causing no more confusion than there is now. 

I've never seen the IEC standard prefix cause confusion in the sense people couldn't work out what was going on. I have seen the Microsoft notation cause such confusion, particularly in the sense of HardDrive space. Manufacturers often use the SI standard prefix GB , but Windows does not use the the SI standard prexfix GB but still uses the acronym, often giving people a feeling they've lost about 7% hard drive space.

What confuses me most is Firefox's moto is usually 'push for good standards'. Here's a good standard, there's no evidence supporting that it'll confuse people, it reduces ambiguity and it'll hopefully push for a wider adoption. But seemingly complying with Microsoft arbitrary notation is more important...

Updated

10 years ago
Duplicate of this bug: 421792

Updated

8 years ago
Duplicate of this bug: 537386
Duplicate of this bug: 637914

Updated

6 years ago
Duplicate of this bug: 695704
Duplicate of this bug: 902206

Comment 97

2 years ago
It appears to me that the system that use the outdated calculation are browsers and Windows.
OS X and most Linux variants (above all Ubuntu) have fixed this by using powers of 10 instead of using powers of 2.

So why not switch to calculating actual kilobytes? 
They're certainly way more intuitive and less confusing (except for Windows users probably).
You need to log in before you can comment on or make changes to this bug.