feat(i18n): add zh-tw (Traditional Chinese, Taiwan) locale - #927
Open
YTingWu wants to merge 1 commit into
Open
Conversation
Adds a Taiwan-specific Traditional Chinese translation alongside the existing Simplified Chinese (zh) locale, using Taiwan tech-industry terminology rather than a straight character conversion. Also fixes Accept-Language matching to try an exact tag match before falling back to the bare 2-letter prefix, so zh-TW browsers resolve to zh-tw instead of being absorbed into zh.
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
1 participant
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.
Summary
Adds a
zh-twlocale (Traditional Chinese, Taiwan) alongside the existing Simplified Chinese (zh) locale. This is a Taiwan-specific translation using Taiwan tech-industry terminology, not a straight character conversion ofzh.json— e.g.帳戶not賬戶,代理not智能體,品質not質量,使用者/登入/設定/專案/伺服器/快取throughout.Also fixes
src/i18n/request.tsAccept-Language matching to try an exact BCP-47 tag match (e.g.zh-TW) before falling back to the bare 2-letter prefix. Previously anyzh-*header resolved tozh(Simplified) because the code truncated to 2 characters before matching; now azh-TWbrowser correctly resolves tozh-tw.Risk Level
Low. Additive locale + a narrowly-scoped fallback-matching fix in
request.ts; no changes to existing locale files, routing, or auth. Main failure mode would be a missed/incorrect translation string inmessages/zh-tw.json, which is a content issue, not a functional one — the locale-parity test guards against structural drift (missing/extra/empty keys) going forward.Evidence
pnpm test→ full suite passes (1546/1546 unit tests includingsrc/i18n/locale-parity.test.ts, 21/21 — up from 19, confirmingzh-tw.jsonhas exact key parity withen.jsonand no empty strings)pnpm typecheck→ cleanpnpm lint→ cleanpnpm build→ succeedspnpm test:e2e→ 514/514 passing, including the updatedtests/i18n-language-switcher.spec.ts(now asserts 11 languages and a new test that switches tozh-twand confirms the login page renders登入以繼續/使用者名稱/登入in a real browser)Contribution Checklist
pnpm lint,pnpm typecheck, and relevant tests passNotes
Two sections (
gatewayControl,agentSquadPhase3) and a handful of onboarding/skills strings are intentionally left untranslated inzh-tw.json, matchingzh.jsonand every other existing locale (es/ja/ko/de/fr/pt/ru/ar) — this is pre-existing translation debt shared across all locales, not specific to this PR, so I keptzh-twconsistent with its siblings rather than scope-creeping into a cross-locale fix.