Might be an idea indeed to switch to default locale 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 change.

If this change goes in, then API dox pf ECMPoQmTools should see some mention of this behaviour (change). So people can rely on it.

there's a new revision of D10757 that shouldn't need this at all.