mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-09-19 05:12:16 +03:00
0ff7d88869
Regenerating the "Supported Locales" table from config/i18n.json filled the 4th column with the locale code, overwriting four verified-correct values. Restored from `googleTl` in scripts/i18n/generate-multilang.mjs: `he` → `iw`, `phi` → `tl`, `pt-BR` → `pt`, `uk-UA` → `uk`. The other 38 rows were checked against the same source and already agreed; the header text, the column widths and every other cell are untouched, so `insertI18nGuideRow`'s anchor keeps working (add-locale --dry-run exits 0 and still inserts `el` in place). The `id` → `in` alias is the sole reason retiring a shipped locale is safe, but unlike its three siblings it had no config-reading regression guard: - tests/unit/i18n-config.test.ts pins LOCALE_ALIASES["id"] alongside uk-UA, phi and zh-TW. - tests/unit/cli-i18n-catalog.test.ts covers OMNIROUTE_LANG=in → id in the existing config-alias test. - tests/unit/i18n-resolve-requested-locale.test.ts adds one case built on the real LOCALES/LOCALE_ALIASES from src/i18n/config.ts (the existing fixture tests stay), asserting a saved NEXT_LOCALE=in cookie still lands on `id`. All three fail when the alias is removed from config/i18n.json (verified). Also: the "docs/i18n/README.md Is Auto-Generated" note no longer claims the index is regenerated by `generate-multilang.mjs docs` — it is maintained by `npm run i18n:add-locale` (row insertion) and by hand otherwise.