Add support for simplified Chinese#1415
Merged
matthew-white merged 1 commit intomasterfrom Nov 13, 2025
Merged
Conversation
matthew-white
commented
Nov 13, 2025
Comment on lines
+26
to
+33
| // Set it up so that we can match either on language or on language + script. | ||
| // Region is ignored. | ||
| const byTag = new Map(); | ||
| for (const locale of locales.keys()) { | ||
| const { language, script } = new Intl.Locale(locale); | ||
| if (!byTag.has(language)) byTag.set(language, locale); | ||
| if (script != null) byTag.set(`${language}-${script}`, locale); | ||
| } |
Member
Author
There was a problem hiding this comment.
I thought about making byTag a nested structure (first level language / second level script), but this ended up seeming a little simpler to me.
2 tasks
lognaturel
approved these changes
Nov 13, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR specifies the options/code needed to support simplified Chinese (zh). It doesn't pull the actual translations: those will come in a follow-up PR.
The codebase already includes support for traditional Chinese (zh-Hant). Note that
zhis a language subtag, whileHantis a script subtag. We could have used the tag zh-Hans for simplified Chinese (with a script subtag ofHans), but we're just using zh instead. Simplified Chinese was added to Transifex as zh, not zh-Hans, and it's important that the codebase match Transifex. It was added to Transifex as zh because that's what was used for Collect.CONTRIBUTING.md has a section on Adding a New Locale. To add support for simplified Chinese, I followed the steps there. To double-check, I searched the codebase for
zhto see what was needed for traditional Chinese.Most of the changes are routine/expected, but I did have to make a change to
userLocale(), which isn't typical. Without the change, a user with a browser preference for simplified Chinese would have defaulted to traditional Chinese instead.userLocale()is the function that decides the user's locale based on their browser preferences (navigator.languages). Before, it used to be that each locale corresponded to a unique language. Now there are two locales that correspond to the same language (zh), but with different scripts (traditional vs. simplified). The logic ofuserLocale()had to change to account for that fact.Prior art for comparison:
:lang(zh)matches both zh-Hant and zh. I confirmed that locally. So nothing there should need to change.What has been done to verify that this works as intended?
I tried it out locally after pulling the actual translations. I saw that zh looked different from zh-Hant.
I also confirmed specifically that the date range picker showed Chinese characters and that zh looked different from zh-Hant (e.g., 周日 for Sunday instead of 週日).
For the changes to
userLocale(), I verified those via unit tests.How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
The risk of regression for existing languages should be low. Probably the main risk is from
userLocale(), but I feel like there's good test coverage of that.We sometimes ask the QA team to verify new languages. I don't feel like it's super necessary in this case, especially since the codebase already has zh-Hant.
Before submitting this PR, please make sure you have:
npm run testandnpm run lintand confirmed all checks still pass OR confirm CircleCI build passes