Ticket #190 (accepted defect)

Opened 5 years ago

Last modified 2 years ago

Wrong language chosen for interface if Windows locale has a non-standard language selected

Reported by: bb@rinn.ch Owned by: alamaison
Priority: minor (e.g. uncommon, cosmetic, has workaround) Milestone: 0.30 Better dialogues
Component: i18n Version:
Keywords: interface wrong language Cc:


If the user has chosen in Windows "German (Switzerland)" in Formats and "Switzerland" in Location but "English" as "display language" under "Keyboards and Languages", Swish chooses German as language for its user interface rather than English.

Swish should use the configured display language rather than relying on the locale. As a work around, it would be helpful if we could set the display language of Swish explicitly, e.g. by setting a registry key.

Change History

comment:1 Changed 5 years ago by alamaison

We're stuck between a rock and a hard place here. The Display Language setting only allows you to choose a language that Microsoft has translated Windows into and that you have installed. There are many languages that aren't included in the list and many that are require you to have the 'Ultimate' version of Windows. This means, even if someone had translated Swish into one of those languages, the translation would never be displayed.

So, we choose the language based on the the 'locale' which MS called 'Formats' for some reason. Despite the name, this locale is used for more than formats. In fact, it's this locale that Windows reports to C++ as the language of your system.

But, as you've noticed, this leaves us with a corner case where the locale and the display language are different. Out of interest, how have you come across this issue? Are you in a situation where the user is a native English speaker but the work they do must take place using Swiss German dates, currencies, etc?

So, we are left with 3 choices:

  1. Choose language based on locale (Formats) with full range of languages but corner case
  2. Choose language based on Display Language but lose a whole range of translations
  3. Allow the user to manually select the language

I don't think number 2 is an acceptable solution but the current situation (1) isn't ideal for some people. Number 3, however, goes against the overall design of Swish which is to do away with settings and autodetect everything. That said, I might be persuaded that some combination of 1 and 3 is viable: use the locale but provide a way to force-override it.

Any thoughts and comments are appreciated.

comment:2 Changed 5 years ago by alamaison

  • Priority changed from major (affects peripheral workflow) to minor (e.g. uncommon, cosmetic, has workaround)
  • Status changed from new to accepted
  • Component changed from frontend to i18n
  • Milestone set to 0.30 Better dialogues

comment:3 Changed 5 years ago by bb@rinn.ch

Thank you for the explanation. I guess using the locale to choose the default language and allow the user to override it is the best that can be done then. Being able to set a registry key to override the automatic language selection would already be great.

The environment we are in is an international research environment with many people from different countries using the terminal server and English being the 'lingua franca'. Still the general agreement is to use central European time and date formats, the metric measurement system and Swiss Franks as the currency, which is what the Swiss German locale does for us.

comment:4 Changed 2 years ago by anonymous

Thank you for this clarification, being in Switzerland but speaking English (as lots of organizations here do), this is not the only program encountering issues. Thank you for the workaround ideas.

Brian Goodman
 Swiss info

Note: See TracTickets for help on using tickets.