D9793: Fall back to language name for translations lookup if locale name fails

[Safa Alfulaij]

safaalfulaij added a comment.


  > Why is this an issue?
  >  There's no difference really in loading ar/LC_MESSAGES/xxx.qm and LC_MESSAGES/xxx_ar.qm (or something like that), i.e. you would have the same problem if all translations would be in the same folder.
  
  Well, we were to simplify this to one call of loadTranslation, but yes, not a big deal.
  
  > The only relevant things I can see is that it replaces all occurences of '-' with '_' (which is necessary only because it gets the languages from QLocale::uiLanguages()), and that it doesn't cut off at the first '_', but creates entries cut off at every one. (i.e. "de_XX_YY" would yield "de_XX_YY", "de_XX" and "de" to try, IIUIC, while the current patch would only try "de_XX_YY" and "de")
  > 
  > I could do something similar, i.e. lookup translations in a while loop and cut off at the right-most '_' if a lookup fails until it succeeds.
  
  Well, that would be great for an ideal world. We can live for now and check the locales that KDE is currently translated to, and just adapt to them.
  
  > The current code does get the locale/language from Qt anyway. (it calls QLocale::system(), which does respect LANG and LANGUAGE )
  > 
  > It probably would also be a good idea to get a list of languages via QLocale::uiLanguages() instead like that find_translation() function does (that would also support things like LANGUAGE="de:ar"). But that's unrelated to this fix IMHO.
  
  Maybe later, I like full concept implementations, but yes, not needed.
  
  This will be enough for the time being. Thanks! :-)

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D9793

To: wbauer, #frameworks
Cc: safaalfulaij, #build_system
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180111/69275372/attachment.html>