[kdelibs/frameworks] kdecore/localization: Verify that the language is available when setting it

[Chusslove Illich]

> [: 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 (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130105/723d2892/attachment.sig>