sitter added a comment.
Stacking the functions seems to work fine
QString KLanguageName::nameForCode(const QString &code)
{
const QStringList parts = QLocale().name().split(QChar('_'));
return nameForCodeInLocale(code, parts.at(0));
}
I do have various refinements and fixes for the logic plus a unit test I can
update the diff if you are ok with that.
As for kcoreaddons, I don't think we could go there with kconfig could we?
And I am not sure QSettings is up to the task?
I also have some behavior concerns. The auto-fallback to QLocale is super
handy, but isn't very flexible: As an application author I might have another
way to map a language to a pretty string, if KLanguageName automatically falls
back to QLocale, I won't be able to easily determine if I should use another
(possibly better) fallback.
At the same time falling back to `QLocale::languageToString` is not
necessarily in the interest of the user either. Who's to say the user will know
what a language means in English.
So, I haven't give this a great deal of thought, but it seems that always
returning QString(), if we cannot resolve a string internally, is possibly more
flexible. Worst case the consumer has to do:
str = KLanguageName::nameForCode("fr")
if (str.isEmpty()) { str = QLocale("fr").nativeLanguageName() }
Which isn't that much code TBH.
REPOSITORY
R265 KConfigWidgets
REVISION DETAIL
https://phabricator.kde.org/D10446
To: aacid
Cc: kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns
