libxklavier translation (was: Re: is new lib dependency possible for 3.5.2?)

Chusslove Illich caslav.ilic at
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 
Gettext standard.

Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the kde-core-devel mailing list