Qt5 Locale and Date / Time (and apologies)

Chusslove Illich caslav.ilic at gmx.net
Fri Jan 20 20:16:32 UTC 2012


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 at baz, first
foo_BAR at baz catalog is tried, then foo_BAR, then foo at 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 (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120120/1995ab23/attachment.sig>


More information about the Kde-frameworks-devel mailing list