74716 - Use platform's thousands separator setting for message sizes

Status: RESOLVED INACTIVE

(Core :: Internationalization, defect)

Description

[Peter Lairo]

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.8.1)

Message size should have comma (,) as thousands separator

so "6359839 kb" becomes "6,359,839 kb" - now that's *much better* ;)

Comment 1

[Boris Zbarsky [:bzbarsky]]

er... you mean message size should have your locale's thousands separator
thingie as thousands separator?  In many European countries, that should be
6.359.839 ....

Comment 2

[Mark Anderson]

I really think a better choice altogether would be to switch away from kilobytes 
when the situation warrants.  Is there any reason that shouldn't be 6.07 GB 
instead of 6,359,839 kb?

And who in the heck has a 6 gigabyte message, anyway? :)

Comment 3

[Peter Lairo]

No, because the length of the number values gives a very quick visual indication
where the larger messages are when visually scanning the summary panes. This
would be lost if we switched between kb and mb - the numbers would all be
similar amounts of digits.

    24 kb   and
    12 mb   both look too similar, but...

    24 kb   and
12,000 kb   can be very clearly distinguished from another.

Comment 4

[Håkan Waara]

-> UI: Design Feedback

Comment 5

[Frank Tang]

looks like the following code cause this (not 100% sure) 
mozilla/ mailnews/ base/ src/ nsMsgDBView.cpp 
599 nsAutoString formattedSizeString;


615 formattedSizeString.AppendInt(sizeInKB);
616 // XXX todo, fix this hard coded string?
617 formattedSizeString.Append(NS_LITERAL_STRING("KB"));
618 }


so it is nsString currently format it. 

Comment 6

[Frank Tang]

I think we should do the following,
1. create a new api in nsString call AppendIntWithFormat
which take 
AppendInt(PRInt32 anInteger,PRInt32 aRadix, nsString aFormat)

2. store "###,###,###,###" into localized resources (property file)
3. the caller get such format string from locale bundle
4. the caller pass such string to AppendIntWithFormat and it return the right result

in French localized release, you put in "###.###.###" and in Korean, if we chose
to do the ancient / correct korean way, then we use "##,####,####" (notice it is
seperated every 4 digits instead 3 digits)

Yes, I know it looks like COBOL. But I think that probably give us the best
control over it. Changing underline implementation may produce bad behavior (I
still remember there are code generate PostScript x,y in french locale as "12,34
, 45,67" where it should be generated as "12.34 , 45.67" in PostScript
regrardless which locale we running in. 

Comment 7

[Boris Zbarsky [:bzbarsky]]

> 3. the caller get such format string from locale bundle

Why?  Is there a good reason not to just get the format from the C locale?  That
_does_ provide this information....

Also, hacking this in on top of nsString is a bad idea, imo.  If only because
there are plans to maybe do away with AppendInt and its ilk.

What we need is a utility function that takes a number and returns an
nsAString/nsACString that contains the formatted version of that number, per the
current locale (however we determine that).  Then the caller can decide whether
to append, whether to use nsString, whether to use the result in a string
concatenation (avoiding extra copies) or what.

Comment 8

[Matthew T (active 1999-2002)]

Nothing to do with UI Design, just a bug which should be fixed. --> I18n.

Comment 9

[Frank Tang]

I think both roy and me are off mozilla for more than 2 years. If these bugs are
still here now, I think the real stauts is 'won't fix'. If you want to reopen
it, please find a new owner for it first. 

Comment 10

[Travis Chase]

Mass Reassign Please excuse the spam

Comment 11

[Travis Chase]

Mass Re-opening Bugs Frank Tang Closed on Wensday March 02 for no reason, all
the spam is his fault feel free to tar and feather him

Comment 12

[Travis Chase]

Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam

Comment 13

[Peter Lairo]

No activity since 2005. Assign to "nobody"?

Comment 14

[Zibi Braniecki [:zbraniecki][:gandalf]]

We now have access to vendored-in ICU and expose Intl.NumberFormat in JS.

Comment 15

[Ben Bucksch (:BenB)]

We now have access to vendored-in ICU and expose Intl.NumberFormat in JS.

I'm going to attempt to translate this sentence into English, for other software developers:

---

We now imported a third party library for the "International Components for Unicode" (see https://phrase.com/blog/posts/guide-to-the-icu-message-format/ ), which allows us to find the correct number format for the current locale.

We are exposing that to JavaScript code using a new API Intl.NumberFormat (see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat ). That means that any JavaScript code can now consider the locale's number format.

However, all code that wants to use the correct number format must be changed to use the new API.

---

Did I translate this correctly? Also, doesn't that mean that this bug is now either FIXED (because the request here was implemented in the code) or a DUPLICATE of the bug where the implementation happened?

Comment 16

[Zibi Braniecki [:zbraniecki][:gandalf]]

The latter. We are coalescing around ECMA-402 standard which exposes https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/NumberFormat

All callsites in Firefox/Thunderbird etc. UI can use it to add grouping separators and other locale specific features to locale formatting. The new localization system (Fluent) is also using NumberFormat API to localize numbers.

Also, doesn't that mean that this bug is now either FIXED (because the request here was implemented in the code) or a DUPLICATE of the bug where the implementation happened?

I don't think so. The request was to use platform's number formatting, while we use the ECMA-402 spec for it.

As to what status we should use, I guess it could be WONTFIX, but I am quasi mass-cleaning the component before the new team takes it over in January and was just using INACTIVE for all old bugs that I think are not relevant anymore.

Comment 17

[Boris Zbarsky [:bzbarsky]]

To be clear, it sounds like a separate bug should be filed for Thunderbird specifically to use the NumberFormat API to addres the initial user-facing concern here.