You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Japanese and Vietnamese already exist as README translations, but the website only ships English and Chinese. That makes the project look partially localized: users can find translated README content on GitHub but cannot browse the website in the same languages.
This should be the first website localization implementation wave because it does not require choosing new community languages. It brings the website up to parity with translated README work that already exists.
Evidence
README.ja-JP.md exists and is linked from README.md:6.
README.vi.md exists and is linked from README.md:6.
web/lib/i18n/config.ts:1 exposes only en and zh.
web/lib/i18n/dictionaries/ contains only en.ts and zh.ts.
web/components/locale-switcher.tsx:6-13 is a two-locale toggle and cannot scale to Japanese/Vietnamese without redesign.
Website pages live under web/app/[locale]/, so the route structure is already locale-ready.
Proposed direction
Add website locales for:
ja-JP or route alias ja
vi
Use #3090's matrix decision for exact route naming if that issue has landed first.
Scope should include the main public pages, not only the homepage:
homepage
install
docs
FAQ
roadmap/feed/contribute surfaces where currently localized through dictionaries or inline text
footer/nav/locale selector labels
Acceptance criteria
Website i18n config includes Japanese and Vietnamese route entries.
Website dictionaries exist for Japanese and Vietnamese.
Locale switcher can display and route among en, zh, Japanese, and Vietnamese.
Accept-Language detection can route ja, ja-JP, vi, and vi-VN requests to the appropriate locale.
Public pages do not silently fall back to English for visible primary copy unless explicitly marked as untranslated.
README language links mention the website locale if the README includes website/documentation links.
Long translated strings fit nav, cards, buttons, and mobile layouts.
Problem
Japanese and Vietnamese already exist as README translations, but the website only ships English and Chinese. That makes the project look partially localized: users can find translated README content on GitHub but cannot browse the website in the same languages.
This should be the first website localization implementation wave because it does not require choosing new community languages. It brings the website up to parity with translated README work that already exists.
Evidence
README.ja-JP.mdexists and is linked fromREADME.md:6.README.vi.mdexists and is linked fromREADME.md:6.web/lib/i18n/config.ts:1exposes onlyenandzh.web/lib/i18n/dictionaries/contains onlyen.tsandzh.ts.web/components/locale-switcher.tsx:6-13is a two-locale toggle and cannot scale to Japanese/Vietnamese without redesign.web/app/[locale]/, so the route structure is already locale-ready.Proposed direction
Add website locales for:
ja-JPor route aliasjaviUse #3090's matrix decision for exact route naming if that issue has landed first.
Scope should include the main public pages, not only the homepage:
Acceptance criteria
en,zh, Japanese, and Vietnamese.Accept-Languagedetection can routeja,ja-JP,vi, andvi-VNrequests to the appropriate locale.Verification
npm --prefix web run lint npm --prefix web test -- --run npm --prefix web run buildManual checks:
/jaor/ja-JPand/videpending on the matrix decision.