[Development] QLocale work

[Thiago Macieira]

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.

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

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?

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

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

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

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120118/9783119f/attachment.sig>