is new lib dependency possible for 3.5.2?
nicolasg at snafu.de
Sun Jan 29 16:56:09 GMT 2006
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.)
Have a nice day!
More information about the kde-core-devel