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: David Ayers
Subject: Re: Test base library stable branch please
Date: Tue, 02 Jan 2007 11:16:05 +0100
User-agent: Mozilla Thunderbird 1.0.2 (X11/20061113)

address@hidden schrieb:
>>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.

OK, this would be consistent with printf(3) (I suspect scanf(3) is
similarly).

>>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."
>>
> 
> 
> It's the tests which are broken in this case, as they compare the result
> of the formatting to a non-localised string (i.e. they work fine on my
> system in C locale, but would break in other locales).  I don't know when
> I'll have time to fix the tests so do look at it if you want, otherwise
> I'll try to fix it sometime soon.

I'm not sure if I fully agree here.  I would have expected
@"1.234,57" which of course would have also failed the test.  So yes,
the test cases need to honor localisation, yet the formatting does not
produce the expected result.

Let me know if you need me to debug this.

Cheers,
David




reply via email to

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