Closed Bug 74716 Opened 24 years ago Closed 4 years ago

Use platform's thousands separator setting for message sizes

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Type:
defect
Priority:
Not set
Severity:
trivial

Tracking

()

Status:
RESOLVED INACTIVE
Milestone:
Future

People

(Reporter: Peter, Assigned: smontagu)

References

Details

(Keywords: helpwanted, intl, platform-parity)

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* ;)
Status: UNCONFIRMED → NEW
Ever confirmed: true
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 ....
OS: Windows NT → All
Hardware: PC → All
Summary: Message size should have comma (,) as thousands separator → Message size should have locale's thousands separator inserted appropriately
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? :)
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.
Severity: enhancement → trivial
-> UI: Design Feedback
Assignee: sspitzer → mpt
Component: Mail Window Front End → User Interface Design
Product: MailNews → Browser
QA Contact: esther → zach
Keywords: helpwanted, mozilla0.9, nsCatFood
Whiteboard: simple to fix?
Keywords: nsCatFood → pp
Summary: Message size should have locale's thousands separator inserted appropriately → Use platform's thousands separator setting for message sizes
Whiteboard: simple to fix?
Depends on: 108689
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.
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.
> 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.
Nothing to do with UI Design, just a bug which should be fixed. --> I18n.
Assignee: mpt → yokoyama
Component: User Interface Design → Internationalization
QA Contact: zach → ruixu
Keywords: intl
QA Contact: ruixu → kasumi
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Blocks: numbers
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.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Mass Reassign Please excuse the spam
Assignee: tetsuroy → nobody
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
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam
Assignee: nobody → jshin1987
Status: REOPENED → NEW
No activity since 2005. Assign to "nobody"?
QA Contact: kasumi → i18n
Assignee: jshin1987 → smontagu

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

Status: NEW → RESOLVED
Closed: 20 years ago → 4 years ago
Resolution: --- → INACTIVE

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?

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.

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.

You need to log in before you can comment on or make changes to this bug.