libxklavier translation (was: Re: is new lib dependency possible for 3.5.2?)
caslav.ilic at gmx.net
Thu Feb 2 15:06:42 GMT 2006
> [: Nicolas Goutte :]
> I have looked at the code of libxklavier.
I gave it a trace too...
> From what I understand of the code, it is the code who translates the
> strings, according to the translations put in the xfree86.xml file.
> So for KDE4, I suppose that we could use directly the library and ask
> the translators to translate libxklavier directly at freedesktop.org.
I agree with this view.
Additionaly, the author of libxklavier is also the coordinator of XKB
configuration project XKeyboardConfig, and the translation is properly
registered with Translation Project, domain xkeyboard-config.
While currently not all distributions are using XKeyboardConfig, there is
no reason to think this will not improve in the future.
> From the KDE point of view, xfree86.xml is GPL/LGPL as the rest of the
> library, so we could copy that file into KDE and then extract messages
> from it (with extracrc form kxkb's "messages" target).
I agree with Jens' view that this should not be done. Configuration is not
ment to be invariant across distributions, and there will always be new
revisions, so the best course of action is to take what is present at
> The problem is to use the translations. One way could be to pass every
> returned strings from libxklavier through i18n() to get the KDE
> translation. [...]
This is indeed a problem. Internaly libxklavier has its own way to decide
translation by the priority of languages, I suppose aimed to be consistent
with Gettext, but *not* actually using Gettext. Adding KDE's own language
resolution into the mix doesn't help the matters either :)
Perhaps something like this can be done: make libxklavier assume same
language priority as KDE (there is call in KLocale to get the list of
languages), than pass whatever is returned through KDE's normal i18n
system - if it was translated nothing will happen, and if it wasn't, there
might be a translation in KDE's catalog.
> I do not know if we could setenv("LC_ALL","C") to keep the library
> to [...]
It seems something like that could work: within initialization of
configuration (API call XklConfigInit), internal function _XklI18NInit is
called, where priority of languages is determined in a cascading manner by
Or perhaps Andriy can talk to Sergey to implement call for direct setting
of language priority into libxklavier.
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