On Friday 20 Jan 2012 21:16:32 Chusslove Illich wrote: > I have two general questions on relation between locale and translation. > > The current (KDE 4) state is that elements of locale system require a > translation system, and elements of translation system require a locale > system.
The circular dependency was something I broke a few times during development, it was tricky to stop it causing problems. With ICU this goes away. The way this will now work is for all date/time translations will be sourced from ICU which has them hard coded in CLDR. API in QLocale will provide access to this. Originally the Qt parsers/formatters would then use this, but now with the ICU backend doing that it's all handled internally in ICU. While initially this would mean we have no influence over the translations used, I am looking at ways that we could "inject" our own KDE locale file into ICU to force it to use our settings, but that's a research project for now. We will lose something here, I believe the Arabic dates/numbers are scripted depending on country, we will lose that ability but hopefully ICU already takes care of that. > This brings up the second question: current KDE feature of freely combining > country and language selection, for a (supposedly) sensible result. This will be a little different than in KDE4, but hopefully not too much. ICU appears to also have the concept of mixing and matching, but if your requested combination of language and country is not actually available it then tries to find the closest match. It's the same system as currently used in Qt4 QLocale because it uses the same CLDR data to do so. It also does a lot of other fallback stuff if certain CLDR fields haven't been included in your selected locale, i.e. if you have de_AT and it doesn't have translations for the Coptic calendar, it will check in de before trying en. > I would only let the translation system still refer to locale (for number > formatting, and anything else convenient), since that basically comes for > free if the translation system will be a tier 2 component, as I plan it to > be. That sounds pretty much how it will (hopefully) work: translation will depend on QLocale, QLocale will have no requirement to call translation as ICU will provide that. Tier 1 libraries should have little need for translation, but if they do it should be fairly basic so tr() should suffice. Cheers! John. John. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
