fix(dashboard): Make Japanese and Korean selectable and complete their translations - #5077

Makes Japanese and Korean selectable in the Dashboard, and fills in every missing translation for both.

The problem

packages/dashboard/src/i18n/locales/ko.po is tracked and holds around 1,005 Korean translations, but ko appears in neither the locales array in lingui.config.js nor defaultAvailableLanguages in vite/constants.ts. So lingui extract never updated it, and the Display language selector could never offer it. The catalog was still being compiled into every build, because the Vite plugin reads the locales directory with readdirSync and compiles whatever .po files it finds — Korean has been shipping in the bundle all along with no way to select it.

Japanese had half the same problem. It is in lingui.config.js, so ja.po stayed current, but it was missing from defaultAvailableLanguages, so it could not be selected either.

What changed

Enablement. LanguageCode.ja and LanguageCode.ko added to defaultAvailableLanguages, and 'ko' added to the locales array so extraction maintains the catalog from now on. ko.po is regenerated, picking up the 327 messages that accumulated while it was frozen. No language-name mapping was needed — language-dialog.tsx resolves labels through Intl.DisplayNames, so both appear with their native names automatically.

Translations. 327 Korean and 44 Japanese strings. The translation commit is exactly 371 removed msgstr "" lines and 371 added ones, with no msgid, reference comment, or header line touched, so it can be reviewed as pure translation content rather than catalog churn.

Both languages are now the best-covered locales in the repo: Korean has no untranslated strings at all and Japanese has 11, all of them obsolete #~ entries for messages that no longer exist in the source. Every other locale sits between 34 and 104.

Native-speaker review

Both catalogs were reviewed against the source code and the existing translations. That review found one genuine UI bug:

Size and Dimensions are consecutive <TableHead> elements in asset-gallery.tsx, and File Size / Dimensions are adjacent labels in asset-properties.tsx. Both rendered identically — 크기 in Korean and サイズ in Japanese — so the asset list showed two adjacent columns with the same header over different data (formatFileSize(asset.fileSize) versus {asset.width} x {asset.height}). Every other locale already distinguished the two. Japanese now uses サイズ / 寸法; Korean uses 용량 / 크기, with File Size moving to 파일 용량.

The review also produced a few consistency corrections, and two back-corrections to translations that pre-date this PR, kept in their own commit:

• Calculator was rendered as 計算機 / 계산기, which reads as a physical calculating device. In Vendure it names a pluggable shipping- or payment-cost strategy selected from a dropdown, so it is now 計算方法 / 계산 방식. The label is shared between the shipping-method and payment-method screens, so the replacement had to work for both.
• Japanese Dimensions, as described above.

Verification

• scripts/check-i18n-sync.sh, the dashboard i18n sync CI job, reports "i18n catalogs are in sync" and exits 0.
• lingui compile succeeds, so every ICU message in both catalogs parses. This matters because the Vite plugin parses these catalogs at build time.
• Extraction is idempotent: a second lingui extract produces an identical diffstat.
• audit-translations.js reports 0 suspicious entries for both languages. Most other locales report between 1 and 34.
• No empty translations remain in either catalog, confirmed with the repo's shared PO parser, a raw grep, and Lingui's own @lingui/format-po parser.

Two tooling gaps worth a follow-up

Both are in scripts/translate/i18n-tool.js and affect every locale, so they are not fixed here. Two entries had to be written into ko.po by hand as a result.

1. isLatinOnlyTechTerm exempts short verbatim Latin technical terms from the native-script guard, but its regex ^[A-Za-z0-9 _\-./]+$ has no colon. So SKU: is rejected for Korean even though leaving it verbatim is correct, which zh_Hans and ja both already do. Adding : to the character class would make the guard behave as its own comment describes.
2. escapeRegex escapes the msgid for PO format, turning " into \", and then for regex, but never escapes the backslash itself. The resulting pattern matches the unescaped text and never finds the entry. Duplicate value \"{trimmed}\" already exists was silently reported as "not found" rather than failing loudly.

Separately, packages/dashboard/plugin/constants.ts exports its own defaultAvailableLanguages and defaultAvailableLocales which nothing imports, and whose language list has drifted to 10 entries against the 28 in vite/constants.ts.

Follows on from #5075, which is where this work was originally split out from.

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}