[Development] ICU decision?

[Knoll Lars]

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
>>for
>> >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.
>>Add
>> 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
>next 
>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
>system 
>API to provide QCollator support for the system locale. Does anyone know
>of 
>such a thing?
>
>I'm sorry, but I will block any task on making QCollator public until we
>know 
>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.

Cheers,
Lars