provide localized strings for data units (megabytes, gigabytes, and so on)

RESOLVED WONTFIX

Status

()

--
minor
RESOLVED WONTFIX
17 years ago
7 years ago

People

(Reporter: mikel, Assigned: mikel)

Tracking

({intl, l12y})

Trunk
intl, l12y
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

17 years ago
There has been discussion about changing data unit symbols to the correct SI
notation in bug 65710.

Unfortunately, it seems that some persons don't want this, and it was suggested
that a new locale (such as en-SI) be created that changes these text strings to
what SI suggests.

This locale can not be made, as it seems that only the kilobyte string is
changeable (kb.label entity).

It should be stressed that this is a second preference, as I would prefer us to
agree on a common standardized international method for referring to data sizes,
but in the absence of this, we need to be able to customize strings for all data
sizes, including bits, kilobits, bytes, megabytes, gigabytes, and so on.

It should also be noted that 1000 bits != 1024 bits, and that the current system
is ambiguous.  It *may* be desirable to have a separate entity for 1000 bits
compared with 1024 bits, and so on.

Ideally, we could have a text string for the "kilo" prefix that got concatenated
with the "bit" or "byte" string as appropriate, but this could get messy, and
probably won't happen.  In this case, there would need to be a string for "kilo"
(x 1000) and "kibi" (x 1024).
(Assignee)

Comment 1

17 years ago
I can't make an SI locale if we can't customize all the data size strings.

Adding blocker.
Blocks: 126168
(Assignee)

Updated

17 years ago
No longer blocks: 126168
*** Bug 126162 has been marked as a duplicate of this bug. ***
Blocks: 126168
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

17 years ago
Keywords: intl
QA Contact: ruixu → kasumi

Updated

17 years ago
Keywords: l12y

Comment 3

17 years ago
Michael, do you mind owning the bug? and drive the effort?
Assignee: rchen → michael
(Assignee)

Comment 4

17 years ago
I can't guarantee anything on this one.  I have no experience with the Mozilla
source (yet), and don't have much time to spend on it.  I would prefer if
somebody else could handle this one.

If nobody can help, then maybe just leave it as "NEW" and I'll see if I can make
time to work on it soon.
(Assignee)

Comment 5

17 years ago
Just wondering how this would be done (not yet fully familiar with how things
work)...

I think the "KB" string is defined by kb.label.  Would it be best to make a
mb.label, gb.label, tb.label, and so on?  Could I just make a mega.label,
giga.label, tera.label, and so on, in conjunction with a byte.label and
bit.label and concatenate them?

Would it be possible to store these in an array or vector?

It should also be noted that there may in future need to be labels for larger
prefixes (peta, exa, zotta, and so on).

Any ideas about the best way to do this would be appreciated.

Comment 6

16 years ago
> Would it be best to make a mb.label, gb.label, tb.label, and so on?

Yes.

>  Could I just make a mega.label, giga.label, tera.label, and so on,
> in conjunction with a byte.label and bit.label and concatenate them?

No. Different languages may have different ways of expressing these units.

Comment 7

16 years ago
To fix this, we need to separate data from presentation. The data here is the
raw amount we are talking about expressed in Arabic numerals, as measured in one
of two different standards: bits and bytes. So, data could be 8192 bits, 8192
bytes, 1300000000000 bytes, or whatever.

Presentation of the data will take the data and express it in whatever form is
considered appropriate for the localization. For example, 8,192 bytes might
become 8 KB, 8kb, 8 KiB, 8 kilobytes, or other depending on the localization,
and so on.

Isn't this right?
QA Contact: kasumi → localization
Per my bug 126168 comment 11, I recommend this be resolved as WONTFIX. This is something better suited for a browser preference, rather than a localization string. Especially because the difference is between a handful of set standard strings. Localizing them doesn't make any sense, as the whole point of the standard is that they are supra-locale.
Whiteboard: [CLOSEME 2012-01-22 WONTFIX]

Updated

7 years ago
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
Whiteboard: [CLOSEME 2012-01-22 WONTFIX]
You need to log in before you can comment on or make changes to this bug.