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

[Chusslove Illich]

> [: 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 
site.

> 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 
env vars.

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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060202/c9598b18/attachment.sig>