gnustep-dev
[Top][All Lists]
Advanced

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

Re: Test base library stable branch please


From: Graham J Lee
Subject: Re: Test base library stable branch please
Date: Thu, 25 Jan 2007 12:13:47 +0000

On 2 Jan 2007, at 09:38, address@hidden wrote:

David Ayers schrieb:


Actually I get these failures on the trunk also... So I'll need to
investigate... (possibly associated with my locale settings for decimal
points?)

Indeed this code looks very suspicious:
  // if no format specified, use the same default that Cocoa does
  if (nil == useFormat)
    {
      useFormat = negativeNumber ? @"-#,###.##" : @"#,###.##";
    }
as does the preexisting code:
- (id) init
{
  id    o;

  _allowsFloats = YES;
  _decimalSeparator = '.';
  _thousandSeparator = ',';
...

Shouldn't the format honor the values for NSLocaleDecimalSeparator and
NSLocaleGroupingSeparator somehow obtained via NSUserDefaults (or
NSLocale once we have that class)?


No...at least, not if it needs to work in the same way as Cocoa's
NSNumberFormatter.  Because the documentation says this:
 When you enable localization for a number formatter, separators are
converted to characters appropriate to the environment in which the
application is running.
and this:
when you enable localization for a number formatter object, the dollar
sign character is converted to the currency symbol appropriate for the
environment in which the application is running.

I took that to mean that the layout of the format string doesn't change,
but the output does depending on the locale.


In fact, that only seems true if you explicitly enable localisation in a given formatter. But I looked at providing that, and I think it would require that we already have NSLocale. Which of course isn't true :-(. Anyway, regardless the tests *ought* to still pass, because the test case *doesn't* enable localisation.

N.B. in the Cocoa docs it explicitly says that the thousands separator is "," unless and until you change it e.g. by enabling localisation. So I take it that the default behaviour is non-localised.

Currently in a de_AT.UTF-8 locale these tests fail:

base/NSNumberFormatter/basic.m:
FAIL: default format same as Cocoa
  pass([str isEqual: @"1,234.57"], "default format same as Cocoa");
where str = @"1,234."

I still haven't been able to duplicate that. Maybe if you're going to FOSDEM we could meet up and have a mini-hackfest to see WTF is happening :-)

Cheers,
Graham.





reply via email to

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