[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Localization of libc and number handling
From: |
Andreas Heppel |
Subject: |
Re: Localization of libc and number handling |
Date: |
Mon, 23 Jun 2003 18:44:23 +0200 |
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