How locale aware is that function? #1

by Michael S. Kaplan, published on 2007/07/05 10:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/07/05/3693510.aspx


(This could potentially be a very exciting new series -- I am optimistic enough about this idea that I suffixed the title with a #1!)

One of the things I like about this blog is that people often point me at things that I might never have known about otherwise....

Like earlier today, when over in the Suggestion Box, Frederic Delhoume asked:

Hi,

I have been unable to find any information related to locale aware memory formatting.

I use StrFormatByteSize but how does it get its formatting information ?

I have not found any Win32 API related to this topic.

Thanks,
Frederic.

This function is a fascinating bit of code, in both good and bad ways.

Here is how it works:

  1. First, it works to find out what size value would best describe the size in the most compact form - bytes, kilobytes (10³), megabytes (10⁶), gigabytes (10⁹), terabytes (10¹²), petabytes (10¹⁵), or exabytes (10¹⁸).
  2. Figure out if the number is between 1 and 1000 or not.
    1. If it isn't, then add commas to it as appropriate given the LOCALE_SGROUPING/LOCALE_STHOUSAND values from GetLocaleInfo and a GetNumberFormat call, all using LOCALE_USER_DEFAULT.
    2. If it is, then get the LOCALE_SDECIMAL value of LOCALE_USER_DEFAULT from GetLocaleInfo and insert it appropriately.
  3. Get the localized size string based on the default user UI language and add the number to the string (note that the localizer can position the size value as either prefix or suffix, as needed).

So you end up with a string that is partially formatted based on the default user locale and partially formatted based on the default user UI language.

In my opinion the same setting could (perhaps should?) be used throughout.

But even more importantly, a function should take the locale/locales to use and then perhaps a simpler version could pre-fill the information for the Shell usage.

With the current code, any other settings are inaccessible, which does close down a whole bunch of scenarios.

This could be an interesting feature to consider adding to a GetNumberFormat/GetNumberFormatEx extension or new function that could take the info about units to use. I see lots of interesting complications that may not make it practical, but I think given the extensive work behind StrFormatByteSize, there is clearly a scenario worth thinking about....

 

This post brought to you by (U+2211, a.k.a. N-ARY SUMMATION)


# pcooper on 5 Jul 2007 12:33 PM:

Is there also a bug in it determining its formatting behavior by looking to see if the number is between 1 and 1000? I'm not quite getting what that step is doing there.

# Michael S. Kaplan on 5 Jul 2007 1:01 PM:

That is not so much a bug as just making sure that they will have a compact little number to use. It helps them determine whether to have anything in a decimal place or go for whole numbers....

# James Matthews on 5 Jul 2007 2:19 PM:

Couldn't you just show us the sourcecode =) Thanks for the explanation!

# Mihai on 5 Jul 2007 4:57 PM:

"So you end up with a string that is partially formatted based on the default user locale and partially formatted based on the default user UI language."

My old topic: which should also happen for currency formatting :-) (and adding an extra level, the currency itself)

So:

- use a user-provided currency

- use the UI locale for currency translation

- use user locale for number formatting and currency positioning


go to newer or older post, or back to index or month or day