> [: Kevin Ottens :] > Verify that the language is available when setting it > > Restore a behavior which was happening in KLocale before ki18n split. > After all, the fact that the method is now in KLocalizedString doesn't > prevent us from calling it. :) > > M +1 -1 kdecore/localization/klocale_kde.cpp > > http://commits.kde.org/kdelibs/94b0ddc63602c0b413678ce3a2dababc79c9665e > > diff --git a/kdecore/localization/klocale_kde.cpp > b/kdecore/localization/klocale_kde.cpp > index 5409610..05e1a09 100644 > --- a/kdecore/localization/klocale_kde.cpp > +++ b/kdecore/localization/klocale_kde.cpp > @@ -607,7 +607,7 @@ bool KLocalePrivate::setLanguage(const QStringList > &languages) > // language in order to preserve the order of precenence of the user > QStringList list; > foreach(const QString &language, languages) { > - if (!language.isEmpty() && !list.contains(language)) { > + if (!language.isEmpty() && !list.contains(language) && > KLocalizedString::isApplicationTranslatedInto(language)) { > list.append(language); > } > }
Well it does prevent us from calling it, because Ki18n should depend on KLocale in the future. That's the technical reason not to do this, but there is also a principal one. The locale should provide user's language preference, to any client code that wants to take it into account. A UI translation engine is one such client, but not necessarily the only one. In other words, I consider the old behavior wrong. -- Chusslove Illich (Часлав Илић)
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
