Files
BrowserSkill/packages/i18n/package.json
iAstro 759eebd4b6 fix(i18n): match browser locale by language subtag instead of exact code
The extension ships en-US and zh-CN resources, but only en-US was ever
selected: every other browser language fell through to fallbackLng
("zh-CN"), so users on en, en-GB, en-CN, en-AU, ja-JP, fr-FR saw Chinese.

Match on the BCP 47 language subtag and normalise it to a resource key:

  en*                                -> en-US
  zh-Hans* / zh-CN / zh-SG / zh      -> zh-CN
  zh-Hant* / zh-TW / zh-HK / zh-MO   -> zh-TW
  anything else                      -> unchanged (fallbackLng default: en-US)

Simplified vs Traditional is decided by the script subtag (Hans/Hant) when
present, then by the region subtag, since Chrome reports zh-CN / zh-TW
rather than script subtags. The zh-TW branch is written now so adding a
Traditional translation later needs no code change.

chrome.i18n.getUILanguage() is now preferred over navigator.language, which
is unreliable on the chrome-extension:// origin the popup runs on.

Adds a locale-resolution regression matrix (28 cases).

Closes #168
2026-09-04 10:03:43 +08:00

32 lines
604 B
JSON

{
"name": "@browser-skill/i18n",
"private": true,
"version": "0.1.0",
"type": "module",
"exports": {
".": {
"import": "./src/index.ts",
"default": "./src/index.ts"
},
"./react": {
"import": "./src/react.tsx",
"default": "./src/react.tsx"
}
},
"scripts": {
"test": "vitest run",
"test:watch": "vitest"
},
"peerDependencies": {
"react": "^19.0.0"
},
"dependencies": {
"i18next": "^24.2.2",
"i18next-browser-languagedetector": "^8.0.2",
"react-i18next": "^15.3.4"
},
"devDependencies": {
"vitest": "^4.1.6"
}
}