kossebau added a comment.

  Might be an idea indeed to switch to default language instead of system one. 
Can you tell at which point the system one is estimated, and based on what?
  Grepping QLocale::system on lxr.kde.org 
 there are some hits, those might need some fixing as well then for consistency 
(via notification to app maintainers to fix themselves carefully)?
  Still leaves the race condition between the installed hooks. It would have 
assumed the static init of the kxmlgui lib is only run after the ones of those 
using the ECMQmLoader, and the registered hooks would be processed in order of 
registration. So the switchlanguage one is only run after the qmloader ones.
  IIRC all this would be not a problem if we were able tun run the 
switchlanguage hook before the QApp instance is created. Thus setting the 
LANGUAGE env var to our desire, and then letting things roll as usual. And it 
is just that things are delayed because the convenience code to find the UI 
language setting needs QStandardPaths & Co. set, which only is during the QApp 
instance creation. Anybody can confirm?
  I just see there is also a QEvent::LocaleChange event type. Perhaps there 
could be some listener on that event, which reinstalls an updated translator 
instance on a change? First event loop might be too late though, given some UI 
objects have already been created and most KDE code does not support UI locale 
  If this change goes in, then API dox pf ECMPoQmTools should see some mention 
of this behaviour (change). So people can rely on it.

  R240 Extra CMake Modules



To: aacid, apol, ilic
Cc: kossebau, apol, #frameworks, #build_system, michaelh

Reply via email to