is new lib dependency possible for 3.5.2?

[Nicolas Goutte]

On Sunday 29 January 2006 17:02, Andriy Rysin wrote:
> Nicolas Goutte wrote:
> > On Saturday 28 January 2006 04:28, Andriy Rysin wrote:
> >> sorry for multiple messages early - my SMTP was telling me my message
> >> was not sent :(
> >>
> >> Andriy
> >>
> >> Nicolas Goutte wrote:
> >>> Do you thing that you would need new user-visible messages? Many of
> >>> them?
> >>
> >> I do not THING a thing unless that thing requires to be THINGed :)
> >>
> > :)
> >
> > If you hae to add some new user-visible strings, then please keep the
> > kde-i18n-doc mailing list informed. (I do not think that adding a few new
> > strings would be a problem, as you do not seem to have much choice.)
>
> well, for 3.5.2 I don't plan any new features and planned changes will
> be mostly in xkb config parser so I don't think new messages for
> translation would appear. As for the KDE4, of course there'll be new
> messages but I think it should not be a problem.

Sure I mean for KDE 3.5.x only. For KDE 4, you can do as you please, until its 
message freeze in many many months.

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

(That is also one of the reason why I would that in KDE4, KDE becomes more 
Gettext-like (e.g. no $KDE_LANG anymore but $LANGUAGE instead): to avoid 
glitches in translations between KDE and non-KDE.)

Probably this will mean that certain languages will lose their translations.

> Advantage of the former is keeping all translations synchronized. While
> advantage of the latter is if there's new version of xorg and new
> strings KDE does not know about yet we'll have native xorg translation.

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

>
> Andriy

Have a nice day!