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

[Thiago Macieira]

Michael Pyne wrote:
>> Not always. An E1 link is 2 Mbit/s. That is, 32 channels of 64000 bits
>> per second, or 2048000 bits per second. So it's the same problem as
>> the floppy disks.
>>
>> But that's the only case I can think of. So you could file it away as
>> "5% rounding down", especially since the higher-level links (E2, E3,
>> STM-1, etc.) are clearly rounding down.
>
>Well no matter what we do I wonder what people who are /really/
> concerned about units will do with these cases.  If using JEDEC units
> is too confusing for people with the 7% error then I'm not sure how 5%
> error is magically OK. But at the same time though I think it's
> something that won't come up in practice (how close does the bitrate on
> E1 links come in practice to their rated capacity?)

Exact match, save for clock drifts. E1s always transmit 32 octets every 
125 milliseconds. Never more, never less, even if you have nothing to 
send.

>> The prefixes apply for metric units. Byte is not a metric unit.
>> Therefore, the prefixes don't apply. For what it's worth, people don't
>> even agree on what a byte is.
>
>And what JEDEC does is they refer to the units strictly as "KB", "MB",
> "GB" so in that regard they're not even trying to claim adoption of the
> metric units (which means that if we do add "long form" translations
> the KB would still be KB instead of kilobyte for JEDEC).

The problem, of course, is that anyone can make standards. We have to 
choose whose standards we follow, though.

Since Byte is not an SI unit, then there is no official standard.

>Well I think for such things as memory sizing in KInfoCenter and showing
>magnetic media capacity in KDiskFree it would be useful to select
> specific units (which is what this patch is for) but if we never add a
> GUI option to expose the hidden default binary locale option that's
> fine too, if we're worried about confusing users on units.

Then just show the full size down to the byte. There's no confusion over 
500 000 000 000 bytes.

>> However, given the flamewar, I may be a won-out vote and I'll accept
>> that. I'll accept because the only case where we'd be showing the
>> "wrong" values ("wrong" defined as "different from all other systems
>> and UIs, including KDE 4.3 and earlier") if and only if the user
>> explicitly made that choice.
>
>I assume you're referring to using kB/MB/GB as metric?  I agree we'll be
>different from essentially everything else out there in that regard, but
> the only reason I'd made it possible to be set as default is just
> because there is apparently user demand.

Well, "user demand" is usually two or three loud people in our mailing 
lists. It doesn't mean users really want this.

In particular, I think most users fall into the "don't care" category. But 
those same users may complain if we start giving them confusing 
information.

>Well my reasoning is essentially that we want to show what the "rated
>capacity" is (in the manufacturer's terms i.e. metric) and then when the
>"actual capacity" is (in the standard UI units).  i.e. something like
> making the DVD icon label "Empty 4.7 GB DVD (holds 4.37 GB [or GiB])". 
> Of course we can just call it a "single layer DVD" or such but we still
> get the issue where the user wonders where the other 7% went.

I understand your reasoning. It does sound nice to show the rated 
capacity, but I still think it brings more confusion. First, the fact that 
we show "4.7 GB (holds 4.37 GB)" will get users asking why the difference 
and how they can use the full size.

I have seen users (including family) ask why the brand-new 4.7 GB DVD they 
just bought at the store can only hold 4.4 GB. And they were not using 
KDE. The problem is not exclusive to us. 

So, like I said, the industry created this mess. And I don't think we do 
any service to solving the problem by bringing the mess into our UI. I'd 
rather we kept the old "JEDEC" units, but I accepted the new IEC ones 
because those are unambiguous.

I'm willing to accept the patch to change the unit names, but I don't 
think we need the API to select unit multipliers. You know there will be 
developers who disagree with you and I and the consensus and will select 
the units for their apps because they think that's the right thing to do.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090712/d9c18021/attachment.sig>