Hi,

At least in Korean, it works.

In regards to what's new entry, I think it should be clarified that it affects certain languages such as French. I'm interested in comments from @nvdaes and other Spanish users and speakers of languages where this is an issue.

Thanks.

Hi,

Also, @bdorer, can you test this pull request to see if German does sort languages correctly?

Thanks.

Hi, I find the following issues for now:

• Alemán (Suiza), de_CH previous to Alemán, de
• Español (Colombia), es_CO previous to Español, es

@Christianlm or @ABuffEr may want to join this conversation for Italian.

I don't know if it matters or not, but with Windows 10 in bulgarian, we're also affected by this sorting bug. But it is only a minor issue - from all the supported by NVDA languages, only the icelandic one is written with a lower case first letter "i" and it is located on the bottom of the list, before the "Default for the user account" option.

@k-kolev1985:
For now bulgarian is the only confirmed language where this issue also occurs. Moreover, in another alphabet (Cyrillic).
Could you test that the issue is resolved with this PR?

@nvdaes and all:
Also in French German CH appear befor German (common) as well as Spanish (co) before Spanish (common). This is indeed most expected to have the common language before the national specific one.

I may also fix this in this PR if people agree.

I have just added a new commit (and rebased) to sort only on the first part of the list item (i.e. full language name) and not on the whole list item string (i.e. "Full language name, ln", ln being the language name abbreviation). The consequence is that "German" is now sorted before "German (Switzerland)" (and the same for Spanish).

@josephsl: Since this last modification should have impacted all languages, should I still modify the Change log information or not? If yes, what would you suggest?

hi @CyrilleB79
I used pr10355 to do related tests in Simplified Chinese.
Inaccurate alignment in Simplified Chinese
Simplified Chinese zh_CN should be above the traditional Chinese zh_TW
For example, the following example:
Language (restart effective) (L): Chinese (Simplified, Chinese), zh_CN
Language (reset to take effect) (L): Chinese (Traditional, Hong Kong Special Administrative Region), zh_HK
Language (reset to take effect) (L): Chinese (Traditional, Taiwan), zh_TW
The following is incorrect sorting:
Language (reset to take effect) (L): Chinese (Traditional, Taiwan), zh_TW
Language (reset to take effect) (L): Chinese (Traditional, Hong Kong Special Administrative Region), zh_HK
Language (restart effective) (L): Chinese (Simplified, Chinese), zh_CN
thanks

Hello @dingpengyu

Thank you for your tests and your useful feedback.

• What is your Windows language?
• What do the language list example you write correspond to? Is it Chinese (zh_CN) translated manually by you in English?
• If you have the language names in Chinese, could you please paste the original copies from the combobox item, with the expected order and the actual order?
• Could you also test the build of the commit a63a877?

@josephsl
In case you have Windows in korean, is there the same issue in korean?

In french, the order is as follow: zh_CN, zh_HK, zh_TW. I will try with Windows language set to English later to check this.

Thanks.

Hello @dingpengyu

Thank you for your tests and your useful feedback.

• What is your Windows language?
  Chinese (Simplified, China)
• What do the language list example you write correspond to? Is it Chinese (zh_CN) translated manually by you in English?
  The list of test languages ​​is based on the latest NVDA alpha and windows10 -1903
• If you have the language names in Chinese, could you please paste the original copies from the combobox item, with the expected order and the actual order?
  There is a corresponding example in the previous feedback.
• Could you also test the build of the commit a63a877?

@josephsl
In case you have Windows in korean, is there the same issue in korean?

In french, the order is as follow: zh_CN, zh_HK, zh_TW. I will try with Windows language set to English later to check this.

Thanks.

@dingpengyu,:

If you have the language names in Chinese, could you please paste the original copies from the combobox item, with the expected order and the actual order?
There is a corresponding example in the previous feedback.

The example you gave me are in English, not in Chinese. If your Windows UI is in Chinese, I would have expected these names to be in Chinese. Did I miss something?

Could you also test the build of the commit a63a877?

Any feedback from this point? It seems there is no compiled snapshot on appVeyor for this commit, maybe because I have rebased my branch. So you need to checkout this commit and run NVDA from source to perform the tests. Is it possible for you?

hi @CyrilleB79
I used pr10355 to do related tests in Simplified Chinese.
Inaccurate alignment in Simplified Chinese
Simplified Chinese zh_CN should be above the traditional Chinese zh_TW
For example, the following example:
语言(重启生效)(L): 中文(简体，中国), zh_CN
Language (restart effective) (L): Chinese (Simplified, Chinese), zh_CN
语言(重启生效)(L): 中文(繁体，香港特别行政区), zh_HK
Language (reset to take effect) (L): Chinese (Traditional, Hong Kong Special Administrative Region), zh_HK
语言(重启生效)(L): 中文(繁体，台湾), zh_TW
Language (reset to take effect) (L): Chinese (Traditional, Taiwan), zh_TW
The following is incorrect sorting:
语言(重启生效)(L): 中文(繁体，台湾), zh_TW
Language (reset to take effect) (L): Chinese (Traditional, Taiwan), zh_TW
语言(重启生效)(L): 中文(繁体，香港特别行政区), zh_HK
Language (reset to take effect) (L): Chinese (Traditional, Hong Kong Special Administrative Region), zh_HK
语言(重启生效)(L): 中文(简体，中国), zh_CN
Language (restart effective) (L): Chinese (Simplified, Chinese), zh_CN
thanks

@dingpengyu
Thanks again for feedback.
I have reproduced this behavior by testing the localized sorting of the strings you indicate in your last comment. As you, I have zh_TW string, zh_HK string and zh_CN string at the end. However unfortunately, I do not know Chinese nor fare-east language sorting methods, so it's hard to investigate. I will ask some help on NVDA devel mailing list.

I have however some questions:

• With this PR, NVDA zh_CN, Windows UI zh_CN, is the sorting of other languages than Chinese correct or not

• With NVDA 2019.2.1 or last alpha, NVDA zh_CN, Windows UI zh_CN, is the sorting correct:

  • for the 3 Chinese languages?
  • for all languages?

Help from other Chinese/Japanese/Korean speakers is welcomed.
@josephsl, any advice?

@bdorer
The build is this one: nvda_snapshot_pr10355-18925,3c4cac23.exe

You can test it, and in German, de should appear before de_CH.

Note however that I am still waiting a feedback from @dingpengyu or anybody else that could help me to understand how language names are sorted in Chinese and why they are not sorted as Chinese people would expect. I have sent an e-mail on nvda-devel mailing-list but did not receive any answer yet.

The build is this one: nvda_snapshot_pr10355-18925,3c4cac23.exe

As I said in an earlier comment, in bulgarian locale we have problem only with the Icelandic language being sorted second to last in the list due to being written with a small letter "I". With this test build however, the problem is fixed - Icelandic is sorted in its correct place in the list.

@bdorer:
As pointed by @lukaszgo1 in #10334 (thank to him), it seems that the issue is not linked to this PR.
To confirm this hypothesis, could you tests if you are able to run:

• last alpha
• alpha-18915,86b5b7e5, on which this PR is based?

Thanks.

The issue of NVDA not speaking is now understood (cf. #10334) and is about to be resolved (cf. PR #10421).

@dingpengyu could you give feedback on these questions so we can go ahead on this PR?

• With this PR, NVDA zh_CN, Windows UI zh_CN, is the sorting of other languages than Chinese correct or not
• With NVDA 2019.2.1 or last alpha, NVDA zh_CN, Windows UI zh_CN, is the sorting correct:
  • for the 3 Chinese languages?
  • for all languages?

And also if you (or other Chinese speaking people) could give me explanation on how Chinese words (here language names) are sorted, this would be welcome, since I have almost no knowledge on this topic.

According to @dingpengyu ,that sequence may be determined by pinyin.
Why not just sort by ISO locale codes?
Then the order would be the same across languages, also users with none latin language can use single key navigation in that list.

To enable single key navigation for none latin language users
Locale code also need to be put before locale name
zh_TW, Chinese (Traditional, Taiwan)

Since content of this list is highly locale specific, we can just make key and list content translatable.

def localeListKey(lang):
  lc=lang[0]
  desc=lang[1]
  frmDesc=locale.strxfrm(lang[1] if lang[1] else lang[0])
  return _("{frmDesc}".format(lc=lc,desc=desc,frmDesc=frmDesc)

Thanks @larry801 for all these feedbacks:

@larry801 you wrote:

According to @dingpengyu ,that sequence may be determined by pinyin.

So it seems that pinyin is not relevant to determine the order that a Chinese user would expect. Right?

@larry801 you wrote:

Why not just sort by ISO locale codes?

For languages written with latin alphabet, ISO local code is not always at the same position as full language name, e.g. Persian (fa), Albanian (sq) and Chinese (zh). This was the reason of issue #7284 / PR #8143 . Sorting with locale code would mean revert this PR.

@larry801 you wrote:

also users with none latin language can use single key navigation in that list

OK, that is a point to consider. If I understand well, Chinese people can only use first letter navigation if items start with latin text. Right?

What about people using non-latin alphabet (Cyrillic, Arabic)? @k-kolev1985 can you use first letter navigation in bulgarian and how does it work for you?

@larry801 you wrote:

Since content of this list is highly locale specific, we can just make key and list content

There seems to be something missing in your code (all inputs of format are not present ins string). Anyway the idea of making keys and displayed description translatable is interesting. To be discussed before being implemented however. Would it be allowed for translators to take the responsibility to translate the key string as '{lc}' for east-asian ones and '{desc}' for translators of languages using latin letters?

Cc @bhavyashah, @feerrenrut, @jcsteh, @josephsl who have already discussed a similar topic in #7284.

Is there any progress on this?

Hi,

Regarding sorting languages list by ISO-639 codes, from technical standpoint, it would resolve this issue. However, from user experience perspective, it will not, as it is the language name users want to see, not the language code.

Regarding Icelandic shown as a lowercase word in Bulgarian: unless the situation has changed in latest Windows 10 releases, I'm afraid this is something Microsoft must fix.

As for an overall progress on this pull request, provided that there will be no outstanding regression, I think it might be best to either merge it into 2020.1 or alpha first so folks can provide feedback.

Thanks.

This won't go into 2020.1 only serious bug fixes will at this stage. While looking at this, I think it makes sense to ensure that the "user default" option is the first in the list. At the moment it is appended, after all other languages. There isn't a code comment to say why, though perhaps there is some history on it that I am not aware of?

I have put the default language in first place in the list as suggested by @feerrenrut since I did not find any hint on why it was appended last.

Moreover, regarding sorting for Chinese people, I am not sure to have fully understood the sorting issue. Anyway, I have understood that strxfrm seems to use pinyin (what seems not to be a suitable order) and that if description coming first does not allow to use first letter navigation. Thus I have implemented translatable item pattern as suggested by @larry801, so that each translator can customize how the items of this list are displayed.
Two point remain pending however:

• Should I care if a translator does not translate correctly the string (missing "{desc}" and/or "lc" part)? For now there is no security for this.
• Would NVAccess poeple allow to make these items customizable by translators since there were instructions given in issue Sort items in Language (requires restart to fully take effect) combo box alphabetically by the expanded language names #7284 / PR General Settings/Language: sort items based on descriptions #8143? @feerrenrut any comment?

I am a little bit worried about changing position of User default from last to first on the list. While I have no idea why it has been placed as the last option in the first place this is a behavior to which our users are accustomed (it has been like that since at least 2014.2). If I'd mistakenly change language to one which I do not speak it gives a certain comfort to know that I am easily able to press END and return to the Windows language. Such changes of behavior are sometimes unavoidable but I do not think that it brings any real advantage in this particular case and it might make someone unable to return to the default language as easily.

@lukaszgo1 you are right saying that people already used to NVDA would remember that the default option is at the end. On the contrary, such default options usually are at the top of the list in other applications settings. So some other people may expect it at this place (new NVDA users or not).
Well let's wait and see if other people comment on this topic, especially Reef. If needed, I will revert this commit.

I agree it's worth considering maintaining expected behavior for users who are lost (because NVDA is in the wrong language), instead is there anyway we can mitigate concerns in this situation? For instance, "Windows" is a product name and shouldn't be translated, if the first item is "Windows default" rather than "User default" this should be obvious enough? Even if translated, a user should be able to read the "Windows" part? I'm also not too worried about this, since I expect that the mostly its NVDA developers who are changing NVDA into a language they don't understand. Another slightly strange idea is to make it the first AND last item.

@feerrenrut wrote:

For instance, "Windows" is a product name and shouldn't be translated, if the first item is "Windows default" rather than "User default" this should be obvious enough? Even if translated, a user should be able to read the "Windows" part?

The problem that "user default" is a proper term - we are not using default language of Windows, but default language of the currenty logged in user

Perhaps "Match Windows language"?

Another more complicated solution is to have the language name in the current language but also in its native language. You could also do this with the "user default".
EG: If the current UI language is Dutch, but my Windows language is English

• "standaard voor gebruiker (User Default)"
• "Engels (English)"
• "Duits (Deutsche)"

Note:

• Dutch for "user default" followed by Windows language (English)
• Dutch for "English" then native English word
• Dutch for "German" then native German word

I think this is a much larger change, and should be out of scope for this PR. Happy for it to be worked on subsequently.

As for the other questions you had:

Should I care if a translator does not translate correctly the string (missing "{desc}" and/or "lc" part)? For now there is no security for this.

What will happen if one or either part is missing? We have had a similar problem with hotkey translations, where they are modified but not tested properly, leading to problems much later. I think it would be worthwhile adding a unit test for this.

Would NVAccess poeple allow to make these items customizable by translators since there were instructions given in issue #7284 / PR #8143? @feerrenrut any comment?

I think this approach is fine as long as mistakes are easy to catch.

How about implementing a dialog for language setting (i.e. like the dialog for choosing a synthesizer) where the user can choose to sort the list according to their needs? For example sort combo box: alphabetically, ISO xxx or any other option out there. I bet most people would just choose to sort the list alphabetically. But at least they would have the choice.

Thanks all for your comments. Here are my grouped feedbacks.

@lukaszgo1 you wrote:

The problem that "user default" is a proper term - we are not using default language of Windows, but default language of the currenty logged in use

So we may use "Windows user language"? This would allow to have the "Windows" text that could be easily recognized in any language as explained by @feerrenrut. And it specifies that this is the language of the currently logged Windows user as explained by @lukaszgo1.

@feerrenrut you wrote:

Another more complicated solution is to have the language name in the current language but also in its native language. You could also do this with the "user default".
(...)
I think this is a much larger change, and should be out of scope for this PR. Happy for it to be worked on subsequently.

I do not see a relevant use case for this request. Since the language names are written with Windows current user language, I expect this user to understand the Windows language he is using.
Anyway, as you wrote, it is out of scope of this PR. May be discussed further in another issue if useful.

@feerrenrut you wrote:

As for the other questions you had:

Should I care if a translator does not translate correctly the string (missing "{desc}" and/or "lc" part)? For now there is no security for this.

What will happen if one or either part is missing? We have had a similar problem with hotkey translations, where they are modified but not tested properly, leading to problems much later. I think it would be worthwhile adding a unit test for this.

I do not see how a unit test could cover such translation issue. Can you elaborate?

@Adriani90 you wrote:

How about implementing a dialog for language setting (i.e. like the dialog for choosing a synthesizer) where the user can choose to sort the list according to their needs? For example sort combo box: alphabetically, ISO xxx or any other option out there. I bet most people would just choose to sort the list alphabetically. But at least they would have the choice.

IMO it is really overkill for just a combobox sorting issue. It is a lot of extra code just for a sorting order. Most users would even not understand why there is such an option and they may be confused by it. Moreover, most people would expect the language names sorted alphabetically as you wrote. Only for few culture/language, alphabetical order does not seem to be relevant. That's why the format customization is at translator level.

I do not see a relevant use case for this request. Since the language names are written with Windows current user language, I expect this user to understand the Windows language he is using.

Despite being out of scope, I'll try to clear up the misunderstanding. The reason for being concerned about the name of "user default" is because we are considering changing it's position which may cause users to get stuck in a language they don't understand. This could happen if they accidentally changed the NVDA language, or they are developers testing a language specific problem, or perhaps using someone else's computer. Having the native name for a language fixes this problem. Arguably it makes sense to display languages ONLY in their native spelling, since users who understand that language should recognize it, and it doesn't matter if those who don't speak that language don't recognize it.

I do not see how a unit test could cover such translation issue. Can you elaborate?

This might be a test similar to the pot tests. It would use getText or similar to open each translation file, and get the entry, and check if it can be formatted with the required arguments. You would have to investigate whether this is easier / cleaner to just read the files directly or use getText to do it.

Thanks @feerrenrut for your review and the fixed typo.
Only the question of a unit test targetting the .po files is not yet addressed.
I do not have so much time nor background knowledge to investigate the translation system.
Maybe we could raise a new issue to address it in another PR? What do you think? Also a new issue/PR would allow to cover the check of "CTRL+ALT+N" translation if needed.