libxklavier translation (was: Re: is new lib dependency possible for 3.5.2?)
caslav.ilic at gmx.net
Fri Feb 3 14:45:24 GMT 2006
> [: Nicolas Goutte :]
> The drawback of this is that KDE's translation is not the priority. So
> the translator might wonder why his translation is not displayed in KDE.
Hm, I thought of this as an advantage? KDE's own translation should be only
a stopgap measure, until distributions in general pick up translations
into their XKB configuration files.
> The problem is that libxklavier does not know about $LANGUAGE so you
> cannot give a language list to it.
Right. libxklavier is actually behaving decidedly unlike Gettext. It'll
just pick up whatever setlocale(LC_MESSAGES, NULL) returns, ie. a single
language at best. (I was fooled by some priority stuff in there, but that
was only trying to find translations for xx, xx_XX or xx_XX.ENC, if locale
string is xx_XX.ENC)
This is turning into a mess :)
Short term, for libxklavier as-is, we could initialize it n + 1 times, once
for C and once for n languages in KDE's list, and scoop up all the
messages. Then kxkb can do the prioritizing itself (skip to next language
if current is the same as C). This way we can also easily implement
whether KDE's or XKeyboardConfig's translation has the priority.
Long term, something should be done in libxklavier itself to conform to
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel