[Development] QLocale work

[lars.knoll at nokia.com]

On 1/18/12 12:35 PM, "ext Thiago Macieira" <thiago.macieira at intel.com>
wrote:

>On Wednesday, 18 de January de 2012 00.47.31, John Layt wrote:
>> * QString will need a decision on the behaviour of toInt() / toLong() /
>>etc
>> using the Default Locale.
>
>They should use the C locale, not the Default (System) locale. Anything
>in 
>QtCore, outside of QLocale, should default to the C locale unless
>otherwise 
>explicitly requested. To deal with a specific locale, including the
>system one, 
>the user needs to use QLocale or use explicit locale-relevant routines.
>Higher-level classes, in end user-facing situations, like widgets and
>QML, 
>however, should default to the system locale.
>
>We need to avoid the problem of printf / scanf that use different decimal
>conventions depending on the user locale. That means the naive
>implementation 
>will be unable to parse the data it generated under a different locale
>settings.
>
>This is a slightly behaviour-incompatible change, but one I feel is
>justified: 
>reading / parsing of data with comma as a decimal separator was already
>broken, so we don't break it further; generating of data without
>thousands 
>separators and with dots instead of commas for decimals is a minor
>inconvenience.

Yes, I'm all for changing this to use the C locale. Let's simply document
it.
>
>> QLocale has friends which use QLocalePrivate methods and enums to
>>perform
>> number parse/format.
>> 
>> * QString
>> * QByteArray
>> * QIntValidator
>> * QDoubleValidatorPrivate
>> * QTextStream
>> * QTextStreamPrivate
>> 
>> Other classes call public QLocale methods for number symbols like
>> decimalPoint() and negativeSign() to use in their own custom
>>char-at-a-time
>> parse/format routines which will cause an issue as ICU / CLDR define
>>these
>> symbols as strings and not chars.

I think we need to change the QLocale API here. IIRC there are a few
locales where the decimal point is more than one char. The only safe thing
is a QString, but we might want to also offer a lower level API that gives
a const QChar * pointer and a length.
>
>QTextStream defaults to the C locale but it has a setLocale member for
>changing that. QString and QByteArray can only do the C locale, except
>where 
>the system one is explicitly requested ("%L1").
>
>The validators (which are in QtGui) need a setLocale too, but unlike
>QTextStream they should default to the system locale.
>
>Does anyone see a problem with different defaults?

No, this is something that simply needs documentation.
>
>> QString - Well behaved, only uses the QLocalePrivate number methods and
>> enums. Mostly only uses C Locale, but does use Default Locale first in
>> toInt() / toLong() / etc methods, and in arg() methods if %L override
>>used.
>
>See above.

Only part that will use locale specific conversion is %L.
>
>> QByteArray - Very well behaved, only uses the QLocalePrivate number
>>methods
>> and enums, only uses C Locale.
>
>Good, looks done.
>
>> QIntValidator & QDoubleValidator -  Very well behaved, only uses the
>> QLocalePrivate number methods and enums. You can set/get locale to use,
>> defaults to Default Locale but falls back to C Locale.
>
>Falling back is a bad idea, unless a Nokian can dig up from the old
>history of 
>that codebase a compelling reason why it was done like that.

Mainly trying to magically make things work. It's a bad idea.
>
>> QDateTimeParser is a private class used for basic date/time parsing in
>> QLocale and QDateTime, but as a validating parser in QDateTimeEdit
>>where it
>> is very deeply embedded.  It only uses the Default Locale unless you
>> sub-class it. QLocale and QDateTime can easily port to use ICU
>>(QDateTime
>> probably using C Locale) but QDateTimeEdit still needs QDateTimeParser.
>> It's not a great class or widget, so I'd suggest doing the minimal work
>> required to port to ICU, rename it QDateTimeEditParser and move it to
>> Widgets.
>
>Agreed.

+1.

Cheers,
Lars