The problem here is that the FS for Mac is case insensitive however the amd loader we use is case sensitive. I need to see if I can find the correct casing of the file and then use that one as the locale independent of the case on the command line or locale.json file.

We need to keep this case sensitive in terms of strings since the Linux file system is case sensitive.

See #4206 for the casing details.

The quick 'hack' fix for this is to uppercase the region (in this case cn) since we know the languages we ship. However in the mid/long term this might not work for other language since 'locale' identifiers can be more complex. (for example: zh-Hant-TW and de-CH-1901 is valid as well.). I didn't find any node API to get the casing of a file on disk. All we can do is to read the parent directory and compare. This shouldn't be too expensive since we read a directory with 18 items.

Reproduce on Windows as well since Windows FS is case insensitive as well. If we fix this we need to retest #4206 on Linux.

For March, can we get comments and/or IntelliSense in the launch.json so that people don't accidentally get into this bad state?

Yes but might be more work/code changes then fixing it. And we do have the --locale command line switch which is affected as well. I will see how open the team is and prepare different fixes so that we can discuss it in the team.

Fixing wise I came up with the following: locale tags are case insensitive. So we will always generate message bundles with lower case locale tags and will convert the locale specified by the user to lower case as well. This makes it work on all platforms even with a case sensitive loader.

@chrisdias please verify. Code complete or documentation for valid locale values should be handled in a different issue. I wanted to keep the code changes to fix this to a minimum.

looks good, modulo #4589

it should be look like this!

"locale":"zh-CN"