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 

  R265 KConfigWidgets


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

Reply via email to