[Manager] Show native names for language options, and only those for which translations are available #5176
Conversation
The translation is in Latin script, so the name should be as well
|
Are we allowed to use C++11 yet? #3635 |
|
This is no good. I shouldn’t have fiddled with my wxWidgets configuration… |
We don't have yet any guidelines about c++11 and later. So if that's possible - please try to avoid using it now. |
|
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? |
|
@BrianNixon, What is the minimal required version of wxWidgets that supports this feature? |
There is another tool that can update quickly wxwidgets to 3.1.6 on mac: #5103 @davidpanderson For your attention. |
|
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. |
|
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 Needs more work… |
New config option "BOINC Manager/UseDefaultLocale" (Boolean) Also remove the logic that tried to match regional locale variations to translation base languages, because it had the unacceptable side-effect of losing region-specific locale settings like date formats.
|
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 |
|
@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. |
|
Hi @CharlieFenton,
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?
The display strings are all compiled in to wxWidgets.
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
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 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…) |
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.) |
@CharlieFenton You ignore valid and the most important point. The most important is user experience as you seems to ignore. @BrianNixon Thank you for your hard work. |
|
@BrianNixon Can you share a screen shots of this list before and after that other users can see on what we discuss here? |
You want to say your language was not correctly detected automatically?
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. |
No. My windows is set to English. And I wanted to switch my local Hebrew language to test it and see it. You should find a solution without duplicate the translation and keep this list small for that only translated or partial translated. |
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. I approve this PR, and @AenBleidd Please review it again. |
|
@BrianNixon, could you please update this PR to resolve conflicts? |
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.