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. For example, month and weekday names use i18n() calls, and i18n() internally calls locale functions for number formatting. This sort of cross- dependency should somehow be broken, no? As an example (the only other locale system I know of really), GNU libc locale functions do not call upon translation system, but hardcode everything; and gettext() calls do not do any argument formatting, so the locale and translation systems are completely oblivious of one another.
This brings up the second question: current KDE feature of freely combining country and language selection, for a (supposedly) sensible result. Again, GNU libc does not attempt this (as consequence of the above), but the user simply gets to see everyting locale-related according to hardcoded locale values for the selected locale; and locale name is used to pick up the most specific translation catalog (e.g. if locale name is foo_BAR@baz, first foo_BAR@baz catalog is tried, then foo_BAR, then foo@baz, then foo), or the user supplied catalog. In other words, there is neither the notion of "country" nor of the "language" in GNU libc, only of "locale name" and "catalog name" (the latter manually selectable through LC_MESSAGES category of locale, or LANGUAGE variable which offers explicit fallback). Personally, at this point, I would fall towards nothing better than GNU libc system, in both aspects. Circular dependency is possible only if both systems are part of same library, as up to now, and as will be no more. And while I would love to see meaningfull free combinability of locale elements, so far I haven't seen it working sensibly other than when the user selected an expected pair of country and language, i.e. in the same way GNU libc works. 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. -- Chusslove Illich (Часлав Илић)
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
