feat: add Korean locale core support

[VoidLight00]

PR Draft — Add Korean locale core support

Title

feat: add Korean locale core support

Summary

This PR adds the core plumbing needed to ship Korean as a first-class UI language in Open CoDesign.

• register ko in the shared i18n runtime and locale normalization
• expose Korean in the renderer language toggle and Settings language picker
• add locale exports and regression tests for Korean strings and onboarding flows

Why

Open CoDesign already has multilingual UI support, but Korean was not a selectable or normalized locale. This made it impossible to test or ship a coherent Korean UX without fork-only overrides.

This change keeps the scope intentionally small and upstream-safe: it adds locale registration, selection, exports, and test coverage only.

Scope

Included:

• packages/i18n/src/index.ts
• packages/i18n/src/i18n.test.ts
• packages/i18n/package.json
• packages/i18n/src/locales/ko.json
• packages/i18n/src/locales/{en,pt-BR,zh-CN}.json
• apps/desktop/src/renderer/src/components/LanguageToggle.tsx
• apps/desktop/src/renderer/src/components/Settings.tsx
• changeset for @open-codesign/i18n and @open-codesign/desktop

Excluded on purpose:

• fork branding / About panel metadata
• local proxy / provider preset behavior
• release or installer documentation
• Korean hotspot translation follow-up outside locale-core

Testing

Passed locally:

• pnpm --dir /Users/voidlight/projects/claude-design/upstream --filter @open-codesign/i18n test
• pnpm --dir /Users/voidlight/projects/claude-design/upstream --filter @open-codesign/desktop test

Notes for reviewers

• ko.json is intentionally added as a full locale file so the runtime can switch coherently.
• Existing locales only receive the new settings.appearance.langKo label.
• This PR does not change provider policy, app identity, or distribution metadata.

[github-actions]

Review mode: initial

Findings

• [Minor] Korean locale falls back to English demo/example content in packages/templates — the examples/index.ts and index.ts registries map ko to English demos and examples. This means the starter prompts and demo list will appear in English when the UI is set to Korean, which may confuse users expecting a fully localized experience. Consider adding Korean translations for these as follow‑up.
  Suggested fix: replace the English fallback with actual Korean text, or clearly document the limitation.

• [Nit] The new ko.json locale file contains several untranslated English strings (e.g., toast.error.report, all loading.stage.* keys, sidebar labels). While the PR intentionally limits scope to core registration, the resulting mixed‑language UI on Korean can be jarring. Highlight the remaining English strings in a tracking issue for future translation efforts.

• [Nit] The packages/i18n/package.json exports are being corrected for pt-BR alongside the addition of ko. This is a necessary fix, but the PR description only mentions Korean — the inclusion of pt-BR export may be overlooked. It would be clearer to call out the fix separately or add a note.

Questions

No blocking questions.

Summary

The PR cleanly adds Korean locale registration, runtime support, and desktop language‑selection integration. All core constraints (no new dependencies, no hardcoded UI values, no direct provider imports) are respected. Tests cover locale normalization and key translation. The only actionable improvements are around starter content and translation completeness, which can be addressed in follow‑ups.

Testing

• Unit tests for packages/i18n already validate Korean normalization, fallback, and live locale switching.
• No Playwright tests were added; however, the UI toggle and settings picker follow existing patterns, so manual verification should suffice.

Open-CoDesign Bot

[hqhq1025]

Thanks for putting this together. The locale plumbing itself looks structurally good: ko is registered, Korean locale normalization works, the package export is present, the language toggle / Settings picker wiring follows the existing pattern, and CI is green.

I do not think we should merge this as a public Korean language option as-is yet, though. I checked the locale coverage: ko.json has the same 890 scalar keys as en.json, so there is no missing-key runtime issue, but 614 of those key/value pairs are still identical to English. packages/templates also maps ko demos/examples to the English registries.

That makes this closer to “Korean locale skeleton / core plumbing” than a user-ready Korean UI. Since the PR adds 한국어 to the user-facing language selector, users will reasonably expect most of the app to be Korean.

Could you please take one of these paths?

1. Keep Korean visible in the language toggle and Settings picker, but translate the main visible surfaces enough that Korean feels usable. At minimum, please cover the app shell/settings/canvas/chat/errors/examples surfaces and avoid English fallback for templates/examples where practical.

2. Or narrow this PR to runtime/plumbing only: keep ko registration, export, normalization, and tests, but do not expose Korean in the user-facing language selector until a follow-up PR completes the translation pass.

A tiny extra: please mention in the PR summary that this also adds the previously missing pt-BR locale export from packages/i18n/package.json; that part is useful, just not currently called out.

Once the public UI scope matches the actual translation coverage, I’d be comfortable taking another pass for merge.