When setting a display language on macOS you can have multiple languages in a sorted list. The language at the top of the list is the primary language. All regular mac applications respect this setting and will always use the primary language. The ThinLinc client however will always use the first non-english language in the list. To clarify, below follows 3 examples: 1. If the order of the language list is like this: * English (primary) * Swedish * French Our client will display in Swedish. 2. If the order is like this: * English (primary) * French * Swedish Our client will display in French. 3. If the order is like this: * Swedish (primary) * English * French Our client will display in Swedish. The only way I found to get the ThinLinc client to display in English is if all other languages are removed completely from the list. The effect of changing this setting is immediate and a reboot or logout inbetween does not change the behavior.
Created attachment 858 [details] Screenshot showing the issue
Another detail that makes this easier to occur: If you add a keyboard layout then macOS tends to add the corresponding language as well. However you can then manually remove the language but keep the layout afterwards.
This issue still exists with 4.13.0 build 2172. Any solution or workaround so far?
I guess that you want the ThinLinc Client to display in English but want a different keyboard layout language? As described in comment #3, the workaround in this case is to remove all non-English display languages but keep the keyboard languages needed.
Reported upstream: https://www.cendio.com/bugzilla/show_bug.cgi?id=7167 Also noted in TigerVNC now that translations are working in their builds: https://github.com/TigerVNC/tigervnc/issues/1381
(In reply to Pierre Ossman from comment #8) > Reported upstream: > > https://www.cendio.com/bugzilla/show_bug.cgi?id=7167 > This is of course the wrong link. The proper one is: https://savannah.gnu.org/bugs/?61556
Upstream claims this is solved in 0.20.2 or later. We are currently using 0.19.3.
Still an issue with the tl-4.14.0_2324 client freshly downloaded from the Cendio website on the date I'm writing this.
gettext has now been upgraded to 0.22.5 as part of bug 8402. I tested the similar scenarios as in comment #1, and now the primary language is always used in the client.
I've checked the code changes and they look good. I've also tried the command line tools: * Generate a new .pot file for upstream TigerVNC * Generate .mo files for upstream TigerVNC * Download ThinLinc translations from Transifex and run them through msgfilter
Something is broken on Windows. It no longer respects the system language in either the UI or on the start menu.
The issue was a patch that was re-applied incorrectly when gettext was upgraded. This has now been fixed.
Works well now. Tested on Windows 10, Fedora 39, and macOS 15. Currently configured language is respected in all cases. Release notes look good.
