[Development] ICU decision?

Knoll Lars Lars.Knoll at digia.com
Wed Aug 7 21:29:03 CEST 2013

On 8/7/13 5:21 PM, "Thiago Macieira" <thiago.macieira at intel.com> wrote:

>On quarta-feira, 7 de agosto de 2013 08:00:27, Knoll Lars wrote:
>> >The only "degraded experience" I would accept is "full functionality
>> >C and 
>> >system locales". It would be acceptable for the classes to not have any
>> >support for other locales, like trying to get number formatting for
>> >Azerbaijani on a German Windows.
>> That would be acceptable for now IMO.
>> The third option we discussed:
>> * Require ICU, but have a 'fake' ICU lib available to deploy with Qt on
>> Windows/Android for those who want to ship with minimal i18n support.
>> some support to our packaging to choose which ICU lib to take.
>Thanks for the suggestions.
>If we go straight for option 3, can we get this fake library done in the
>couple of months?

It can be done, but the question would be who has the time.
>If we go for option 2 first, we'd have to investigate if there is any
>API to provide QCollator support for the system locale. Does anyone know
>such a thing?
>I'm sorry, but I will block any task on making QCollator public until we
>that we can have a working QtCore without an ICU dependency.

But we can't (or rather should't) go for a least common denominator
approach neither. A public QCollator won't mean a non working QtCore even
if it has to fall back to unicode sort order on some OSes. And with ICU in
place it'll all work fine.

I agree that ICU is a large dependency, but we can't simply leave out
important features forever because of this neither. and collation is
something we have been lacking for far too long.


More information about the Development mailing list