[Manager] Show native names for language options, and only those for which translations are available

[BrianNixon]

Fixes #2061

Release Notes
Manager ‘Other options’ dialog now shows native language names as well as English, and only offers languages for which a translation is available.

[BrianNixon]

Are we allowed to use C++11 yet? #3635

[BrianNixon]

This is no good. I shouldn’t have fiddled with my wxWidgets configuration…

[AenBleidd]

Are we allowed to use C++11 yet? #3635

We don't have yet any guidelines about c++11 and later. So if that's possible - please try to avoid using it now.
Thank you for understanding.

[BrianNixon]

This isn’t going to work on Mac without a wxWidgets update.

Assuming @CharlieFenton has neither the time nor the inclination to do that, do we allow platforms to diverge, or just drop this cosmetic enhancement?

[AenBleidd]

@BrianNixon, What is the minimal required version of wxWidgets that supports this feature?

[BrianNixon]

3.1.6
wxWidgets/wxWidgets@deef116

[talregev]

This isn’t going to work on Mac without a wxWidgets update.

Assuming @CharlieFenton has neither the time nor the inclination to do that, do we allow platforms to diverge, or just drop this cosmetic enhancement?

There is another tool that can update quickly wxwidgets to 3.1.6 on mac: #5103
But it not just the fact of the need "time" and "effort" to update wxwidgets.
On mac wxwidgets is a modify version for boinc, also insist to support older mac. (May have a solution for that even with higher wxwidgets version).

@davidpanderson For your attention.

[BrianNixon]

Yeah – I saw that discussion, which is why I’m conscious that any update needs a robust justification…

This branch builds now, at least – but it leaves the Mac version different from the other platforms. I’ll hold off on the C++11 removal until there’s further guidance.

[BrianNixon]

Reducing the language list to only those for which translations are available has a nasty side-effect because there is no separation in the Manager between display language (really meaning only text translation) and locale (which also influences things like date formats). This means regional variations are lost now that only the base language is selectable.

Example: my system locale is en-GB, but if I now set the BOINC Manager language to ‘English’ (because ‘English (United Kingdom)’ is no longer available), dates get displayed in U.S. format. This is unacceptable.

Needs more work…

[BrianNixon]

Latest commit improves things by adding (Automatic Detection) as an option, which applies system default locale settings everywhere. (It was partially there before, but only worked as a one-shot action on first run of the Manager, didn’t persist, and couldn’t be reselected subsequently.) This is probably what most people want.

There are still some edge cases where the new UX is worse than previously – for instance, if the user had chosen a regional variation like de_CH on a machine where en_US is the system default. The preference will be preserved in the new version, but in the Options dialog the language list will have no selection, which looks a bit odd; and if they subsequently select ‘German’, they will lose the Swiss-specific locale elements (like the thousands separator, which is different from standard German), even though the UI text will stay the same (because the only available translation is de). At that point the only way to get de_CH back is to edit the config file/​Registry by hand. I’m not sure whether this is an acceptable price to pay for reducing the drop-down list from the 800-odd locales that wxWidgets supports to the 30-something translations that are available for the Manager.

[CharlieFenton]

@BrianNixon I've taken only a cursory look at your code (or the original code). Please excuse my ignorance as I ask a few questions.

Why do you need to eliminate the many regional variants we currently support? How do the current regional designations get converted from de_CH to German (Swiss)? In any case, BOINC doesn't actually have a separate translation for de_CH but only a generic de. What happens under the current code if one selects German (Swiss) or English (U.K.) in BOINC's menu? BOINC does support a few separate regional translations, such as zh_CN and zh_TW.

Would it be possible to keep the current list (including the regional variants) and use the translation options in wxWidgets to translate the language name only (using some sort of lookup) in our original list so we could keep the regional variant names? I realize this would not translate the regional designations such as Austrian.

Perhaps it makes sense to not use the wxWidgets feature at all, and just create a list of translated language names ourselves (such as you already did in html/inc/language_names.inc) but including the regional variation names. This would of course require that we manually update that list if we add or remove languages we support. For robustness, it could be an N X 2 array, with the English and localized language names in each pair and using a lookup function to translate the displayed list.

This latter approach would also eliminate the need to update wxidgets on the Mac. That said, upgrading from 3.1.5 to 3.1.6 is probably not very difficult. An upgrade to the current 3.2.2 would require considerably more testing to ensure no bugs were introduced.

[BrianNixon]

Hi @CharlieFenton,

Why do you need to eliminate the many regional variants we currently support?

We don’t need to; it was a side-effect of making the list of languages in the drop-down match what is actually available for the UI (as suggested in the issue).

Does it make sense to offer German (Switzerland) as a language, when selecting it does not in fact translate the UI into Swiss German? Or Irish, when selecting it will leave the UI in English? Is it a good user experience to be presented with a list of 877 choices?

How do the current regional designations get converted from de_CH to German (Swiss)?

The display strings are all compiled in to wxWidgets.

What happens under the current code if one selects German (Swiss) or English (U.K.) in BOINC's menu?

The Manager locale (influencing number and date formats) is set exactly as specified, using wxWidgets’ implementation (or that supplied by the operating system). The UI display language (the words that appear on screen) falls back to the de translation supplied by BOINC when it doesn’t find one for de_CH, and to the compiled-in strings when it finds no translation for either en_GB or en.

Would it be possible to keep the current list (including the regional variants) and use the translation options in wxWidgets to translate the language name only (using some sort of lookup) in our original list so we could keep the regional variant names? I realize this would not translate the regional designations such as Austrian.

Certainly it’s possible, but what would that add? If we keep the regional variants, why not use the native name for the full thing (which wxWidgets will do for us)? German (Austria) – Deutsch (Österreich)

The ‘right’ answer is probably to separate the setting of display language and locale (and wxWidgets seems to be encouraging a move from wxLocale to wxUILocale to help address problems like this), but that would seem to add unnecessary complexity for negligible benefit. Approximately nobody is ever going to change the setting from the automatic choice anyway.

Maybe the halfway house is to keep the regional variants, but only those with a base language for which a translation is available? (Though that still leaves the list pretty unwieldy: there are 108 variants of English alone…)

[CharlieFenton]

Why do you need to eliminate the many regional variants we currently support?
We don’t need to; it was a side-effect of making the list of languages in the drop-down match what is actually available for the UI (as suggested in #2061).

Approximately nobody is ever going to change the setting from the automatic choice anyway.

Just my opinion, but I think you have found a number of good reasons to keep our current list with all the region codes, even when we don't actually support some of them directly. So I would disregard this portion of the original issue as it applies to region codes. (If the drop down includes languages we don't port at all, then those certainly should not be listed.)

[talregev]

Does it make sense to offer German (Switzerland) as a language, when selecting it does not in fact translate the UI into Swiss German? Or Irish, when selecting it will leave the UI in English? Is it a good user experience to be presented with a list of 877 choices?

@CharlieFenton You ignore valid and the most important point. The most important is user experience as you seems to ignore.
The very long list that cause me difficulty to change to my language and it very annoying. And to learn the most of the language there is not even translated is disappointing. I imagine for other user that switch to his language and it even not translated, after he struggle with the long list like I do. My feeling with this long list is common in the users of boinc.
This long list should be eliminated.

@BrianNixon Thank you for your hard work.

[talregev]

@BrianNixon Can you share a screen shots of this list before and after that other users can see on what we discuss here?

[AenBleidd]

The very long list that cause me difficulty to change to my language and it very annoying.

You want to say your language was not correctly detected automatically?

This long list should be eliminated.

I don't agree. As it was correctly pointed above, this is not a question of translation but the local settings that could be different for the same language but in different country.

And we can't make duplicate translations for every language that has different local settings since it will be too annoying for our translators as well, because this will duplicate their work, and we have no valid mechanism neither to validate nor to merge in a correct way the same language translations for different locations.

[talregev]

You want to say your language was not correctly detected automatically?

No. My windows is set to English. And I wanted to switch my local Hebrew language to test it and see it.
I had a bad user experience.

You should find a solution without duplicate the translation and keep this list small for that only translated or partial translated.

[talregev]

Each of the 267 variants map to one of the 33 languages correctly?

If you’re asking me whether I have tested all 267 options individually to verify that: the answer is no.

But the list is populated by comparing the language tag of each locale known to wxWidgets to the translations available to BOINC, so it shouldn’t be possible for there to be any mismatch.

I am not asking for you to testing all the 267 options. This task is for @AenBleidd when he release new version with the alpha testers.
If you test some of the variations (for example 2 variations of Hebrew are going to 1 translated Hebrew), and all other should work similar that ok.

I approve this PR, and @AenBleidd Please review it again.

[talregev]

I approve.

[AenBleidd]

Looks good to me

[AenBleidd]

Looks good to me

[AenBleidd]

@BrianNixon, could you please update this PR to resolve conflicts?
Thank you in advance