[Development] ICU decision?

Knoll Lars Lars.Knoll at digia.com
Wed Aug 7 21:42:22 CEST 2013

On 8/7/13 9:29 PM, "Knoll Lars" <Lars.Knoll at digia.com> wrote:

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

Looks like the CompareString/CompareStringEx methods should allow us to
implement collation on Windows without ICU.


>>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.
>Development mailing list
>Development at qt-project.org

More information about the Development mailing list