[PATCH] Add support for JEDEC/metric standards to KLocale::formatByteSize

[Michael Pyne]

On Sunday 12 July 2009 11:08:11 Karl Ove Hufthammer wrote:
> Michael Pyne:
> > 2) Go through the KDE applications we maintain and use formatByteSize
> > where appropriate.  What I mean by that is that whenever possible we
> > should respect the user's units.  However, when we report download speed,
> > that should be in decimal given existing practice, even for users with
> > JEDEC.
>
> Why? Is there a compelling reason for mixing different units?

Well, sometimes. :)

If we report hard disk sizes in IEC we've "artificially" shrunk the hard disk 
for users (until they learn that the -i makes a bit of a difference between 
IEC and metric).

If we report memory sizes in metric we've "artificially" enlarged memory size 
(but who wants to say they have 4.295 GB of memory?)

I'm not talking about making the desktop have different units everywhere, but 
I do recognize that in /some situations/ it may make sense for an application 
to use a specific unit type.

> For cases where there is a fixed set of values for units, such as in CD-ROM
> sizes and MP3 compression (128 ‘kbps’, 160 ‘kbps’, 320 ‘kbps’ – I haven’t
> looked up whether the ‘kbps’ refers to 1000 bits or 1024 bits), it is
> reasonable to always use the ‘standard’ *numbers* (but preferably the SI
> symbols, e.g., ‘kb/s’). But where there are no such standard fixed set of
> values, what is the reason for a confusing mix of numbers and symbols?

Well that's kind of my reasoning actually (using standard numbers).  Obviously 
for like a 54 Mbps WiFi network we'll never actually see download rates of 6.5 
MB/s (metric) but it may be less confusing to have the units match.

> For example, when you download data with a speed of 1 MB/s for 60 seconds,
> why should you end up with a file of 57.2 MiB? Isn’t it much more
> consistent to download data with with a speed of 1 MiB/s for 60 seconds and
> end up with a file of 60 MiB?

Of course this is a good point as well (matching units for data and data 
rate).  Either way I'm not too concerned about which one we do (except that we 
do need to be consistent in the desktop which one we use instead of using 
JEDEC and metric).

> And with the ‘mixing’ solution, should the download dialogue show both
> decimal and binary units – decimal numbers for the speed and binary units
> for the amount transferred?!

I was referring to KDiskFree in this case.  Especially if we can use Solid to 
determine it's magnetic media or flash drive, then we can add the appropriate 
unit.  I was thinking something like this:

"34.4 GiB / 42.6 GiB (capacity 45.7 GB)"

> Also note that the (*in theory*) unambigious use of KB (uppercase K) for
> indicating 1024 bytes as compared to kB (lowercase k) for 1000 bytes only
> works for 1000/1024. For MiBs, GiBs &c. we have no such correspondence.
>
> Or are you suggesting that MB should refer to 1024 × 1024 bytes for file
> sizes and 1000 × 1000 for download speeds, and that this will be easier for
> everyone to understand than always using unambiguous MiB units?

All I'm really trying to say is that we should have one measure for data 
transfer rate and that right now AFAICS that "standard" is metric, not IEC or 
JEDEC.  On the other hand file sizes have always been in JEDEC/IEC units.

> > When reporting hard disk capacity (i.e. in KDiskFree) we should
> > use (or at least show) decimal units even for IEC or JEDEC.
>
> So the numbers (excluding the symbols) displayed should always differ
> between kdf and df (-h)?

What's to say df doesn't change on us?  Are we referring to GNU df or Solaris 
df?

> > 3) I can't find the email right now but I do remember reading an email
> > from someone on our i18n teams who was having trouble with the various
> > applications using their own units (sometimes they meant decimal,
> > sometimes binary, etc.)
>
> Since this is crossposted to the I18N list, here’s the content of that
> e-mail, to make it easier to quote for translators:

>snip<

Thanks for including, this is exactly the email I was referring to.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090712/8d259e10/attachment.sig>