The zh folder under locales is outdated

[larry801]

Steps to reproduce:

Switch Windows System language to Simplified Chinese

Actual behavior:

WARNING - characterProcessing.SpeechSymbols.load (23:24:32.983):
Invalid line in file locale\zh\symbols.dic: ﹩ 錢號all

Expected behavior:

No warnings when loading

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2019.1

Windows version:

Windows 8.1

Other questions

The folder zh was introduced in this commit for espeak d6fe1f5
It also provide symbol and characterDescriptions for other zh locale which is not in transaltion SVN repo like (zh_MO or zh_SG).
It comes from an old zh_TW translation which is outdated and contain format errors.
It would be better if we copy them at installation instead of storing it directly in repo.

Does the issue still occur after restarting your PC?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

[LeonarddeR]

Before considering this, I really think it is helpful to have an overview of the several Chinese translations within NVDA (i.e. what group of Chinese speaking people is targeted by what language), and how does the plain zh folder fit within this picture?

[josephsl]

Hi, perhaps once Python 3 comes to master. Thanks.

[josephsl]

Hi,

Please ping me shortly after NVDA 2019.2 stable is released so I can take care of this once and for all. As part of that, I'll ask translators as to what to do.

Thanks.

[larry801]

The first Chinese localization work is done by people in Taiwan.
At that time they use zh as locale name.
Later users from Mainland China and HongKong started to maintain their versions separately.
Original zh folder was renamed to zh_TW.

zh locale was brought back to work around espeak issue.
This allows these character descriptions and symbols to be used for synths that only specify zh as their language (such as eSpeak mandarin)
It also has the side affect that it will also make these symbols and character descriptions get used for any other zh_* language as no other dic files have been provided for these languages yet. In short this now allows chinese character descriptions and symbols to function again, having previously been broken due to the addition of auto language switching.
Here is its original commit.
d6fe1f5

I think this workaround is not proper.
Without poper maintainance the two dic file soon became outdated, and take up space.
If we copy dic file from current maintained locales at install time, it would be better.

There are 5 specific cultures for Chinese in Microsoft Windows
Simplified: CN (Mainland China), SG(Singapore).
Traditional: TW (Taiwan), MO (Macau), HK (Hong Kong).
Current zh folder servers as a fallback for the two locales not included in NVDA.
But zh_SG uses Simplified Chinese while zh_MO uses Traditional Chinese, current zh folder is and outdated version of zh_TW which uses Traditional Chinese.

It seeems that we have not seen feedback from NVDA users who use the two locales.
May be we can set up the two locales at install time base on current ones for the time being
(zh_SG based on zh_CN
zh_MO based on zh_HK )
Then we can safely remove the zh folder.
we can set them up in translation workflow. until users in these regions show up。

[josephsl]

Hi,

Note: Larry's response was posted on translations mailing list at my request.

Based on Larry's explanation, I think a more proper solution is asking Espeak nG devs about splitting zh folder into locale-specific data. Because some users may still rely on deprecated behavior, I propose a transition period (perhaps one to two NVDA releases) to move folks from the old format to the proposed workaround.

Thanks.

[feerrenrut]

@dingpengyu Did you manage to contact @josephsl and resolve this issue?

[josephsl]

Hi, I haven’t kept up with this issue for a long time due to many things happening outside of NVDA. Thanks.

[cary-rowen]

Hello all,
This folder looks really useless, and I can't find the corresponding option in the language selection combo box. What is nvaccess hesitating at present?
@feerrenrut @josephsl What do you think about this? Hope this issue is not abandoned.

[cary-rowen]

Hi @feerrenrut
I see that the issue seems to be removed from the 2022.1 milestone, is there any reason behind this?
thanks

[feerrenrut]

This is still in our queue to look at, however, we don't believe it is required for the 2022.1 release.

[cary-rowen]

cc @seanbudd
NV Access is currently migrating its translation system. Do we need to pay attention to this issue again?

[seanbudd]

ignore previous message, we plan on removing these unless there are objections.

[lukaszgo1]

It would b good to get a confirmation from @michaelDCurran that the issue which was solved in d6fe1f5 is no longer relevant.

[cary-rowen]

If the zh directory exists in the locale directory of the add-on, it means that the translation of zh can cover zh cn and zh tw as well as zh hk.
If I remember correctly, this implicit feature is not pointed out in any documentation, but one add-on that embodies this feature is unigram plus.

Does removing this directory affect this? Overall, I think implicit features like this are worth using.

[Adriani90]

cc: @wmhn1872265132

[cary-rowen]

@Adriani90
what do you want to say

[dpy013]

If the zh directory exists in the locale directory of the add-on, it means that the translation of zh can cover zh cn and zh tw as well as zh hk. If I remember correctly, this implicit feature is not pointed out in any documentation, but one add-on that embodies this feature is unigram plus.

Does removing this directory affect this? Overall, I think implicit features like this are worth using.
hello @cary-rowen
Just checked the GitHub code for UnigramPlus.
Found that the addons doesn't have Simplified Chinese, only a zh Traditional Chinese.
Any other examples?

[cary-rowen]

Hello @dpy013
No, but I don't think any more examples are needed.

Can you clarify this? What impact might #17105 have on this?

Please let me reiterate:
The localized content in the zh directory in locale will apply to zh_CN, zh_TW and ZH_HK (if one of them does not exist)

1. Why is this?
2. You deleted the zh directory, what impact will this have?

Thanks

[dpy013]

Hello @dpy013 No, but I don't think any more examples are needed.

Can you clarify this? What impact might #17105 have on this?
From my personal test yesterday, the speech synthesizers of espeak, sapi4 and sapi5 run fine in Simplified Chinese.
As for Traditional Chinese.
When I submitted the pr at that time, no related users and developers came out to comment.
So it's not really clear what the situation is in Traditional Chinese.

Please let me reiterate: The localized content in the zh directory in locale will apply to zh_CN, zh_TW and ZH_HK (if one of them does not exist)

1. Why is this?
2. You deleted the zh directory, what impact will this have?
   The specific impact has not been found in the zh_CN environment.
   For specific test steps, check out 17105
   I'll test it again when the alpha compilation is complete.

Thanks

[CyrilleB79]

@tsengwoody, zh folder has now been removed (#17105). Could you double check that there is not any impact on zh_TW in latest alpha?

[tsengwoody]

@CyrilleB79 I've tested the latest alpha, and everything is working fine. The removal of the zh folder has no impact.