D10446: Add KLanguageName

[Albert Astals Cid]

aacid added a comment.


  In D10446#376825 <https://phabricator.kde.org/D10446#376825>, @sitter wrote:
  
  > 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.
  
  
  Sure, tests are nice i remember this was kind of a bit of a hit and miss sometimes. But are you going to depend on having all of l10n installed (which is where kf5_entry.desktop files come from or will you have some fake kf5_entry.destkops for the test? (second would be awesome)
  
  > 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?
  
  QSettings doesn't support language entries AFAIK
  
  > 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.
  
  But you end up repeating that in lots of places (which we should there's lots of places that suffer from trying to guess a language name at this point, and all of them went the bad way one way or another). If you want to give some random potential user more flexibility i'm fine with that, add some flags, but i want the "give me the best you can do" possibility to still work. Maybe we should even never return an empty string and worst case scenario return code back.

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/20181215/e8f1b5ae/attachment-0001.html>