https://bugs.kde.org/show_bug.cgi?id=464694
--- Comment #3 from Ingo Klöcker <kloec...@kde.org> --- Analysis: * kxmlgui prepends the application-specific languages to the LANGUAGE environment variable. * ki18n uses QLocale::system().name() to know which translations to load. * This works on Unix because Qt considers LANGUAGE when (re-)initializing the system locale. * This doesn't work on Windows because Qt completely ignores LANGUAGE on Windows. On Windows, Qt does consider LANG, but unfortunately LANG is stored in a function static, i.e. once it has been initialized changes to LANG will be ignored. Therefore, my naïve attempt with https://invent.kde.org/frameworks/kxmlgui/-/merge_requests/145 doesn't work. The result is that on Windows all .qm files are loaded for the system language and not for the application-specific language. Possible (Windows-specific) solutions: a) Replace all usage of QLocale::system().name() in ki18n and in the ECM-generated qm loader with QLocale(first language in LANGUAGE).name(). This could be a performance problem if creating a custom QLocale is very slow. (QLocale::system() is a singleton.) b) Set LANG before QLocale::system() is initialized the first time which means before Q*Application is created. This creates a chicken-egg-problem which may not be solvable without touching all applications because the code that loads the application-specific language needs to know the name of the application (and currently uses qAppName() which requires Q*Application to be created already). I'll go for a). -- You are receiving this mail because: You are watching all bug changes.
