is new lib dependency possible for 3.5.2?

Andriy Rysin arysin at
Sun Jan 29 18:03:00 GMT 2006

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

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


More information about the kde-core-devel mailing list