D10446: Add KLanguageName

[Harald Sitter]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20181214/f58617f1/attachment.html>