Create translator-friendly localization catalog workflow

[FennexFox]

Create translator-friendly localization catalog workflow

Problem or Limitation

Issue #44 moved active language state and localText() into tools/drive_comparison_client/shared/i18n.js, which gives the browser client a cleaner localization boundary. That makes future localization work safer for developers, but it does not yet make translation work friendly for non-code contributors or crowdsourced translation.

Most dynamic UI copy is still embedded directly in JavaScript as localText(ko, en) pairs, and static template localization still uses STATIC_TRANSLATIONS, NOTE_HTML, translateText(), and applyStaticLanguage() from tools/drive_comparison_client/state/core.js. A translator currently has to edit source code and understand where each string is rendered.

There is also a related but separate game-data localization concern: some Terra Invicta template names and descriptions should come from the game's localization strings rather than raw template fields. For example, drive display names and descriptions can be resolved from keys such as TIDriveTemplate.displayName.<dataName> and TIDriveTemplate.description.<dataName>. That data-pipeline concern should be handled by #53 before this issue consumes those fields in the UI.

Proposed Change

Create a translator-friendly localization workflow based on external locale catalogs and validation tooling.

Suggested direction:

• Add source locale files for Korean and English, likely under a path such as tools/drive_comparison_client/locales/ or data/locales/.
• Replace inline dynamic localText(ko, en) pairs with stable message IDs or another catalog-backed lookup API.
• Decide whether static template strings and dynamic JS strings should share one catalog, or document why they remain separate.
• Add a verifier that detects missing translations, unused keys, duplicate keys, and malformed placeholders.
• Add contributor documentation explaining how to add or update translations without editing JavaScript logic.
• Keep generated docs/** output rebuilt through the normal npm run build workflow.

Game-data localization boundary

This issue should focus on app/UI copy owned by this repository, not on vendoring Terra Invicta's raw localization files.

Game-data strings derived from Terra Invicta templates, such as drive names and drive descriptions, should be resolved into repo-local generated game-data catalogs first. See #53 for the proposed generated drive catalog.

Expected boundary:

#53 / generated game-data catalog
  TIDriveTemplate.displayName.<dataName>
  TIDriveTemplate.description.<dataName>
  normalized drive metadata

#51 / app UI locale catalog
  buttons
  labels
  diagnostics
  chart guide copy
  preset/dry-mass UI copy
  static explanatory text owned by this app

After #53 lands, this issue may consume generated drive fields such as displayName and description, but it should not be responsible for parsing the local Terra Invicta install or deciding raw-template fallback behavior.

Acceptance Criteria

• Dynamic UI copy can be translated by editing structured locale data rather than JavaScript source call sites.
• Missing or unused localization entries are caught by an automated verifier.
• Placeholder/interpolation usage is validated so translated strings cannot silently break runtime UI text.
• The language switch still updates chart controls, presets, dry-mass modal text, chart diagnostics, chart guide labels, and source/static text.
• Game-data localization responsibilities are documented as separate from app UI copy localization.
• If drive display names/descriptions are used by UI components, they are consumed from the generated game-data catalog introduced by Add generated drive catalog with localized drive metadata #53 rather than parsed ad hoc in UI code.
• npm run build completes successfully.
• npm run verify completes successfully, or any verifier limitation is documented.
• A short translator/contributor guide is added.

Constraints and Non-Goals

• Do not change chart behavior or persisted chart state shape.
• Do not edit generated files directly; rebuild published output through npm run build.
• Do not require a third-party translation platform in the first implementation. The catalog format should be compatible with later Crowdin/Weblate-style tooling, but this issue can stay repository-local.
• Avoid broad UI copy rewrites unless needed to introduce stable translation keys.
• Do not vendor raw Terra Invicta template or localization files.
• Do not parse the local Terra Invicta install directly from UI localization code.
• Do not implement the generated drive catalog here; that belongs to Add generated drive catalog with localized drive metadata #53.

Relationship

Follow-up to #44. That issue established shared/i18n.js as the dynamic localization boundary; this issue should build on that boundary to make localization maintainable for contributors and possible future crowdsourcing.

Related prerequisite: #53 introduces a repo-local generated drive catalog for localized drive metadata. This issue should treat that catalog as an input once it exists, while keeping app-owned UI copy localization separate.