chore(locales): normalize Korean to ko, keep kr as back-compat alias#79
Conversation
The Korean locale shipped under the wrong code `kr` (that's ISO 3166-1
country, not language). Canonical ISO 639-1 is `ko`. The shipped file
was `kr.json` and `localeLoaders` mapped both `ko` and `kr` to it,
which `SUPPORTED_LANGUAGES` exposed under `ko` — a dual-code setup
that confused every new contributor and was flagged in code review.
- Rename `src/i18n/locales/kr.json` -> `ko.json` (via `git mv` so the
history follows).
- Drop the duplicate `kr` entry from `localeLoaders`; the alias map
already redirects `kr` -> `ko` at detection time.
- Migrate persisted `localStorage["waveflow-language"] === "kr"` to
`"ko"` once at startup so DevTools / future migrations see the
canonical value. `convertDetectedLanguage` already normalised on
read, so this is purely about cleaning up the stored token.
- Keep `kr` in `supportedLngs` so any direct `i18n.changeLanguage("kr")`
still resolves (belt-and-suspenders alongside the alias map).
- Update `CLAUDE.md` to reflect the new canonical code.
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 0 |
| Duplication | 0 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
Summary
The Korean locale shipped under the wrong code
kr— that's the ISO 3166-1 country code for South Korea, not the language code. Canonical ISO 639-1 isko. The repo carriedsrc/i18n/locales/kr.jsonwhile exposing the language in the UI asko, and the loader mapped both codes to the same file. This dual-code setup confused every new contributor and was flagged by Qodo on PR #69.Changes
git mv src/i18n/locales/kr.json src/i18n/locales/ko.json— history follows the rename.localeLoadersdrops the duplicatekrentry; the alias map already redirectskr -> koat detection time, so any inboundkrstill loads the Korean strings.localStoragemigration: a storedwaveflow-language === "kr"is rewritten to"ko"on startup.convertDetectedLanguagealready normalised the code at read time, so this is purely about cleaning up the persisted token (DevTools, future migrations see the canonical value).supportedLngskeeps"kr"so any code path that callsi18n.changeLanguage("kr")directly still resolves — belt-and-suspenders alongside the alias map.CLAUDE.mdupdated: locale list showsko(canonical), with a sentence explaining the legacykralias.Test plan
ko, app loads Korean strings.localStorage["waveflow-language"] === "kr"(simulate via DevTools): on next launch, the stored value becomes"ko"and Korean strings still load.ko-KR/kr/ko→ all resolve tokovianormalizeSupportedLanguageCode.bun run typecheckandbun run lintpass.