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