Re: Localization of libc and number handling

[Andreas Heppel]

On 2003-06-23 18:00:30 +0200 Alexander Malmberg <alexander@malmberg.org> wrote:

<snip>
> > Unfortunately, it is not me (or in this case Enrico), who is mixing up libc
> > and GNUstep, but it's GNUstep itself, as the method -floatValue, for 
> > instance,
> > of an NSString uses atof() on the value returned by -lossyCString. And
> > -description comes into play, for instance, in NSCell's -setObjectValue. It
> > could be avoided (if I understand the code properly) by employing a 
> > formatter
> > for the cell.
>
> Seems like that would only be a workaround, though.
To me it rather looks like one of the possible solutions for number 
localization (see your statement below).

<snip>
> > Nevertheless, IMHO, an NSNumber should take into account the user's locale
> > when building it's description. At least it should take into account the
> > (first) value in NSLanguages, in the hope that this is coherent with the LANG
> > setting.
>
> No, it shouldn't. If you want localized number formatting, you need to
> explicitly request localized formatting (eg. using [NSNumberFormatter
> -setLocalizesFormat:], or [NSString +localizedStringWithFormat:];
> there's also -descriptionWithLocale:, but it's only available in some
> classes).
You're right. I've overseen the -descriptionWithLocale:

> [snip]
> > How does OpenStep locale handling work?
>
> Locale information is stored in dictionaries, and there are formatting
> methods that take these locale dictionaries as arguments. Normally,
> you'd pass in nil to get a default locale (kindof like the c or posix
> libc locale, I guess), or [[NSUserDefaults +standardUserDefaults]
> dictionaryRepresentation] to get locale the user has set.
I'd be fine with the latter, i.e. use the user's locale. But it is not handled 
like this (at least not in all cases). -descriptionWithLocale:, for instance, 
(at least NSNumber's implementation) does not treat the nil value for locale. 
To dig even deeper, GSFormat(...) does not, either. If the locale is nil, 
well, then it simply uses some hardcoded values (like '.' for the decimal 
separator) instead of using the user's defaults. Maybe, this should be 
corrected, then?
Or rather, what is the right way to treat this problem? Is it GNUstep's 
responsibility? Is it mine (as an application developer)? Both?

Cheers,
Andreas
--

SYSGO AG
Am Pfaffenstein 14
55270 Klein-Winternheim, Germany

Voice: +49-6136-9948-0
Fax:   +49-6136-9948-10
Web:   www.sysgo.de