Objective: Run KiCad and get the UI in English, no matters which language is selected in the OS (I’m talking about Linux, not Windows).
What I tried: LC_ALL=en_US.utf8 pcbnew
Where en_US.utf8 was determined running locale -a and looking for en_*
This almost works, but doesn’t always work. The GTK native dialogs sometimes remain in the global language, here is an example:
You can see the KiCad Print dialog using english and the GTK Print dialog using spanish (Also note: both dialogs has the exact same name Print, IMHO a very bad idea)
What is even more bizarre is that using: LC_ALL=C pcbnew works as expected.
The problem with this is that some Linux distros, like Arch (IMHO broken, C locale is a traditional UNIX locale for scripts trying to avoid localization details) doesn’t define this locale, so I can’t rely on this.
Why is KiCad (wxWidgets, GTK, etc.) doing this? I’m explicitly asking for a locale in the environment, but getting a mix of two locales. What’s wrong here?
And BTW, I think the KiCad menu to select the language is broken. If I try to select English it says it isn’t supported by the system, but en_US.utf8 is installed. I guess KiCad is assuming some fixed name, like en or en_UK, and not asking the system which locale is installed for the selected language, like I’m doing using locale -a.
I’m running KiCad from the command line. As I explained: LC_ALL=en_US.utf8 pcbnew
If I use LC_ALL=C pcbnew it works. But, as I explained, the C locale isn’t always available. Arch Linux users reported it isn’t defined on Arch.
This is an oversimplification, the real thing is like this: Arch Linux defines C locale, but modern Linux systems switched to UTF-8 and defines C.UTF-8. Arch Linux doesn’t. The problem is that using plain C some tools fail (i.e. xdotool fails to compare UTF-8 text from the Windows titles) . So must use C.UTF-8. But as this isn’t available on all cases what we are trying to use is just some english locale.
Potentially the two languages are shown because the translation to the non-english language is incomplete. The parts that are not translated will default to english.
wxWidget’s locale handling is separate from system locale handling. The native GTK print dialog you mention is not wxWidgets window and is likely playing by system rules. I’m guessing here but maybe it doesn’t recognize en_US.UTF-8 locale and defaults to system locale.