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

[Nicolas Goutte]

On Sunday 29 January 2006 19:03, Andriy Rysin wrote:
> Nicolas Goutte wrote:
> > On Sunday 29 January 2006 17:02, Andriy Rysin wrote:
> >
> > ...
> >
> >> But there's another question here. New xkb config in XML (available
> >> since 4.3 and which will be used if libxklavier is in) has translations
> >> for layouts, models etc. Currently all those are translated with
> >> I18N_NOOP, so the question is whether we want to use old way of
> >> translating everything via KDE I18N_NOOP or should we try to find native
> >> xorg translations first?
> >
> > From what I have understood, you mean that libxklavier's source will not
> > be part of KDE's source code. So the translation is not a KDE matter
> > either.
>
> no - libxklavier is not part of KDE's sources, and yes - translation is
> the matter of KDE:
> This was the case before, e.g. layout names etc are taken from X11, and
> even they not present in KDE sources, they are translated in KDE with
> I18N_NOOP, as there were no other way to get them translated (X11 is not
> quite i18n'ed). Now we have some languages/messages from xorg covered by
> xkb XML configuration which will be returned by libxklavier. So we could:
> 1) use only translations from xorg
> 2) discard those from xorg and use old way of KDE translations
> 3) try to make hybrid: use xorg i18n, if it's not present use KDE i18n

I have looked at the code of libxklavier.

Everything user-visible string seems to be in the file xfree86.xml, which 
includes some translations too. (Unfortunately much too few translations.)

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.

But to switch to this library in the middle of the KDE 3.5.x branch, I do not 
think that there are enough translations.

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).

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.
(Be careful that if the library expects an untranslated string, you have to do 
the back conversion too.)

I do not know if we could setenv("LC_ALL","C") to keep the library to give 
back untranslated strings only. Otherwise the translators could not change 
the translation in KDE if the library has already a built-in translation.

Perhaps an alternative, but I do not know the API, is to give our own KDE 
version of xfree86.xml. However we have currently now program putting DE 
translations into a XML file. (We have such a program only for .desktop 
files.)

Again an alternative would perhaps be a KDE-specific xfree86.xml purged of 
translations.

I do not know if Chusslove Illich would have another idea how to handle that. 
May his experience with the Gettext runtime and ith translation scripting 
would give us another idea.

>
> > ...
> >
> >> We could probably do hybrid model with KDE translations taking higher
> >> precedence and falling back to xorg i18n strings if it's new for KDE.
> >
> > That is barely possible, as KDE does not use the Gettext/glibc runtime,
> > while the library is probably using it if it can handle translations by
> > itself. (And this situation will not change in KDE4, as KDE will still
> > have a specific form of handling translations.)
>
> I must note, that libxklavier and xorg don't show anything to the user,
> everything goes through kxkb code, so we could do whatever we want. The
> only problem with 3) is that it's not easy to tell which messages are
> missing from xorg translation (different versions of xorg may have
> different # of messages and languages i18n'ed) so we'd have to put all
> messages for translation anyway (especially if we are to support X11 <
> 4.3) and then some of them will be translated from xorg which will be
> confusing.

Yes, but you have only one libxklavier, not many of them.

> Anyway 2) (old way) is the only option for KDE 3.5.x and for KDE4 we
> still have some time to discuss. I'll be checking these problems with
> libxklavier author and possibly xkb maintainer.
>
> Andriy

Have a nice day!

PS.: tomorrow and perhaps the day after, I will probably not have time for 
KDE, so sorry if my next answer is more in around 48 hours. Sorry!