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,;
  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.

  R265 KConfigWidgets


To: aacid
Cc: kde-frameworks-devel, sitter, markg, apol, michaelh, ngraham, bruns

Reply via email to