Problem/Motivation
Currently, format_size displays KB and MB as the suffix for 1024 and 1024**2, whereas these should be kiB and MiB respectively :
- since the division is by 1024 instead of 1000, these are kibibytes and mebibytes, not kilobytes and megabytes
- uppercase "k" is for Kelvin, not kilo (see note on http://en.wikipedia.org/wiki/Kelvin#Formatting_and_typestyle_for_the_K_s... ). Its use for the kibi was never validated.
Steps to reproduce
Proposed resolution
Leave this alone based on a comment from miki in the related issue. I have copied it here. #1114538-19: Use SI and/or IEC units for byte counts?.
Okay, let's just stop for a second, and review how these units are currently used across the industry:
Windows
Consistently binary (the old way)
OS X/iOS
Inconsistent. Decimal used for hard disk space in the Finder (in accordance with SI), binary used for RAM (in accordance with JEDEC). Binary used almost anywhere else (ls -lah, for example).
Linux/FreeBSD
Inconsistent, depending on which graphical shell (if any) you're using. CLI tools still using binary.
I don't own any Android devices, so I haven't been able to test those.
Bottom line
I don't there's a really good solution here.
- If we swich to using SI prefixes (ie. convert the numbers), we will get weird numbers in the UI (max upload size, 5.242 MB).
Additionally, we would be doing the wrong thing for memory sizes (ie. RAM limits), since RAM measurement follows the JEDEC standard, which specifies that RAM should be measured binarily.
- If we swich to using IEC prefixes (ie.
mebibytes and gibibytes), we will introduce a unit for disk size measurements that our users have likely never seen before, thereby confusing them.In summary, I think we should leave this alone. It's a nasty mess, and there's no solution that's correct everywhere.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | core_binary_prefixes-451404-12-test_only.patch | 2.12 KB | boobaa |
| #12 | core_binary_prefixes-451404-12-test_and_fix.patch | 3.52 KB | boobaa |
| #5 | drupal-451404.patch | 3.71 KB | boobaa |
Comments
Comment #1
Garrett Albright commentedWow. I've heard the 1000/1024 argument before, but "K = Kelvin" is a new one.
Given the context that we're talking about filesizes, and that the "K" is followed by a "B" (or "iB" if it absolutely must), isn't its meaning unambiguous? It's highly unlikely we're going to be measuring a file's temperature. If the "M" is going to be uppercased, the "K" also should be for consistency.
Comment #2
fgmIMO, it is not up to us to redefine well established international standards. §2.1.1.5 See http://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf
Comment #3
Garrett Albright commented"We" are not redefining anything. The use of KB to stand for "kilobytes" has been a standard in the computer field for decades. Tradition and common sense tell us that if a computer file has the property "8 K" or "8 KB", it's not talking about freaking temperature.
Comment #4
fda commentedAnd that will probably stay true as long as cryogenic quantum computers are not available on the market ;-)
Comment #5
boobaaAttached patch addresses this.
Comment #7
fgm@Boobaa: patch does not address the "K" vs "k" error.
Comment #8
dhthwy commentedThe patch does not go far enough, many more changes are needed, including UI text.
Doing this will entail changing every instance of kilobyte to kibibyte, and the same for megabytes, etc. Nobody except for geeks is going to understand what a kibibyte is.
The meaning of KB depends on the context, in IT it is generally assumed to be 1024, because computers operate at the binary level. And also because the new standard has not been fully adopted. You won't find hard drive's labeled as gibibytes at Best Buy or NewEgg.
That said, I see no way this will be considered for D7 -- not with a beta release on the horizon.
It's possible the standard will be more completely adopted in the future, so this can be re-evaluated for D8.
Comment #9
albert volkman commentedI don't believe this makes sense even for D8.
Comment #10
fgmI do. Especially given that Drupal has been steadily used by bigger entities, where standards compliance is an issue. Let this be refined instead of hiding it under the rug.
Comment #11
albert volkman commentedPlease provide example of other softwares that you seen that use this format.
Comment #12
boobaaAttached are straight rerolls of #5: one with test updates only, the other with the actual fix as well.
@fgm in #7: you are right about that kilo is abbreviated as k, but this does not need to be addressed if we are changing to use kibi, which is abbreviated as Ki.
OTOH, I'm not sure if DRUPAL_KILOBYTE should be changed to 1000, or it should be renamed to DRUPAL_KIBIBYTE (and leave it at 1024), or should we have DRUPAL_KILOBYTE = 1000 and DRUPAL_KIBIBYTE = 1024 both – so I'm not touching it at all.
Comment #22
pameeela commentedMarking this postponed until there is some consensus on whether to make this change.
Comment #25
kristen polThanks for reporting this issue and providing patches. We rely on issue reports like this one to resolve bugs and improve Drupal core.
As part of the Bug Smash Initiative, we are triaging issues that are marked "Postponed (maintainer needs more info)". This issue was marked "Postponed (maintainer needs more info)" more than a year ago, and there has been no activity here since that time.
Since there is no consensus to move forward with this issue, I am keeping the status at Postponed (maintainer needs more info) but tagging for maintainer review to provide direction so we know if this change would be supported or we should close this issue as "won't fix".
Thanks!
Comment #26
fgmThanks Kristen. What kind of info would a maintainer need to decide whether or not we want to respect international standards ? That's not really a rhetorical question: although I've been contributing and maintaining Drupal since 2005, seeing obvious actions like this remain blocked leaves me perplexed.
Comment #27
kristen pol@fgm I understand your frustration. This is a really old issue :(
As for what the maintainer needs to decide, I'm afraid I don't know for certain as I'm not a maintainer, but I do think enough information has been provided above that the maintainer should be able to make a decision on if this should go forward or not.
Comment #28
mxr576The currently associated subsystem is "base", the maintainer of that system is... NaN
https://github.com/drupal/core/blob/df7527f68d6e6f09c61cee99d45a7d9e3081...
So this issue is never going to move forward...? :thinking-face:
(Sorry, I am also frustrated about all those "abandoned" subsystems in Drupal core that has no maintainer assigned therefore every opened issue goes to /dev/null basically - and I do know that some of those are being pushed to become a contrib, but not all of them gets "fixed" like this. )
Comment #29
kristen polAh! I didn't realize there was no "base" subsystem maintainer o_O Thanks for pointing that out.
I'll put this in the bugsmash channel and see what we can figure out.
Comment #31
quietone commentedThis issue was discussed in #bugsmash, 3 months ago and we (darvanen, lendude, borisson_, catch and myself) all forgot to update the issue. I am doing so now.
It was pointed out that clients will not understand the difference and that the KiB/MiB notation is not widely know. A key point was that the related issue has a relevant comment which I have not copied here because it is long. I will copy the summary line of that comment,
There was agreement with the summary, that "we should leave this alone". That make this issue a won't fix. The related issue could be won't fix but first, it should be updated and probably used to update documentation to explain what we are doing.
I have updated the summary here and the status.
Thanks to everyone who worked on this to improve Drupal.
I will work on the related issue now.