discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Localization of libc and number handling


From: Alexander Malmberg
Subject: Re: Localization of libc and number handling
Date: Mon, 23 Jun 2003 19:02:51 +0200

Andreas Heppel wrote:
[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.

[NSNumber -descriptionWithLocale:] looks correct to me, although it
would only work in practice if [NSString -initWithFormat:locale:] worked
correctly.

> 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?

No, this behavior is correct (although the implementation is broken). I
guess I wasn't clear enough. If you pass in nil for the locale
dictionary, you get a default locale similar to the c or posix libc
locale, ie. a safe, portable locale that is the same everywhere,
regardless of user settings. Among other things, this means that it will
use "." as the decimal separator.

If you want to use the user's locale, you need to pass in
[[NSUserDefaults standardUserDefaults] dictionaryRepresentation].

> Or rather, what is the right way to treat this problem? Is it GNUstep's
> responsibility? Is it mine (as an application developer)? Both?

Well, it's GNUstep's responsibility to behave correctly. :) If you don't
care about localization, you should just use the non-locale versions of
the methods, or pass in nil as the locale. This way, you'll always get
the portable locale and writing and parsing numbers will work without
any problems. If you want to use the locale when presenting data to the
user, you should use the right locale to get the strings, but only for
presentation purposes (ie. you should still save and load files in the
portable locale or the files might break if the user's locale changes).

- Alexander Malmberg




reply via email to

[Prev in Thread] Current Thread [Next in Thread]