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

Reply via email to