The reason to make the prefix localizable, e.g., exporting those symbols at say as a LC_NUMERIC/*.po file, is less than the use/application of thousand separator, proper numeric grouping, and decimal point of the current locale as the proposed prefixes are widely accepted by all regions. Such exported PO file would be quite useful though for possible localization.
However, use of thousand separator (if that will be also supported), grouping, and decimal point that will be from the current locale via localeconv() or nl_langinfo(3C) is rather mandatory since otherwise people will be confused on the '.' and the ',' as their meaning are switched based on what is your locale/culture and also the numeric grouping can be different as most of us know. I.e., without proper use of thousands_sep, grouping, and decimal_point from the current locale, the outcome of the function won't be really human-readable or humanized per se. An example: 123.456, would that be 123 point 456 or 123 thou 456? Ienup Paul Jakma wrote at 10/10/06 21:34: > On Tue, 10 Oct 2006, Nicolas Williams wrote: > >> Ienup brought up that question. >> >> This is definitely in the realm of L10N. So new items for >> nl_langinfo(3C) seem to be in order. > > > If we define the function to /strictly/ be SI, which all the world > recognises and uses so a reasonable constraint, then there'd no > localisation issues for prefix symbols. > > That would mean we need Kibi / 'Ki', Mibi / 'Mi', etc.. for the > 2**(10*n) prefixes. Which would be a good thing too. > > --paulj
