Skip to content

feat(i18n): translate pages, components, stores and validators#103

Open
Nic-dorman wants to merge 4 commits into
mainfrom
feat/i18n-phase-2-sweep
Open

feat(i18n): translate pages, components, stores and validators#103
Nic-dorman wants to merge 4 commits into
mainfrom
feat/i18n-phase-2-sweep

Conversation

@Nic-dorman
Copy link
Copy Markdown
Contributor

Summary

  • Phase 2 of i18n rollout — extracts every remaining user-facing English string after the framework + shell sweep in feat(i18n): vue-i18n framework + shell strings (English + Japanese baseline) #102.
  • Covers all 4 pages, the 5 file dialogs, the 4 node components, StatusBadge, UpdateDialog, store-level toasts (files / nodes / updater) and filename validators.
  • Ships the matching machine-translated Japanese baseline in locales/ja.json.

Stacked on #102

PR1 (framework + shell) must merge first. Once it does this rebases cleanly onto main with just the two sweep commits.

Notable refactors

  • plugins/i18n.client.ts now exports the i18n instance so options-API Pinia stores can call i18n.global.t(...) from outside a Vue setup context.
  • utils/validators.ts::filenameError now returns translation keys instead of pre-translated English. Callers wrap with \$t(...) at render time.
  • StatusBadge.vue's statusMap is keyed by backend status strings and resolves to translation keys at render time.

Out of scope (intentional)

  • Dynamic status strings with appended formatting (Uploading 45%, Failed: <err>, Quote: 0.001 ETH) pass through StatusBadge untranslated. Translating these requires the source emitting structured tokens instead of pre-formatted strings — bigger refactor than this PR; noted in a comment in StatusBadge.vue.
  • components/SettingsField.vue is unused (no callers) — not translated.
  • JA strings are machine-translated, flagged with _machine_translated: true in ja.json. Community polish is the next phase.

Test plan

  • App in English: every page, dialog and toast renders in English with no `[i18n] Not found` console warnings.
  • App in Japanese (Settings → Language → 日本語): every page, dialog and toast renders in Japanese with no missing-key warnings.
  • Layout: nothing clipped or wrapped awkwardly when switching to Japanese (spot-check Files-page table headers, Settings cards, UploadConfirm dialog).
  • Filename validator: invalid name in DownloadDialog → error renders in active locale.
  • Trigger toasts from each store action (add node, remove node, start all, upload complete, payment failure, download failure) → toast text renders in active locale.

🤖 Generated with Claude Code

Nic-dorman and others added 4 commits May 12, 2026 12:57
…seline)

Plumbs vue-i18n@11 with tauri-plugin-os locale detection, a persisted
i18n_locale config field, and a Settings → Language picker showing
"System default: <OS-native name>" for the follow-system option.

Extracts shell strings — sidebar nav, page titles, header connection
pills, active transfers, Connect Wallet — to locales/en.json with a
machine-translated locales/ja.json baseline. ja.json is flagged with
_machine_translated: true; community polish to follow.

Pages, components, toast strings, and validators are untouched — that
sweep follows in a separate PR.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
vue-i18n's LocaleMessage type requires every value to be a string or
nested message object, so the boolean _machine_translated: true flag
failed nuxi typecheck:

    Property '"_machine_translated"' is incompatible with index signature.
    Type 'boolean' is not assignable to type 'LocaleMessageValue<…>'.

Rename to _translator_notes and put the same signal in a sentence —
satisfies the type system and reads more naturally for a contributor
who lands in ja.json from a PR.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sweeps every user-facing string from:
- pages/index.vue, files.vue, wallet.vue, settings.vue
- 5 file dialogs (CostEstimate, DatamapSaveAs, DownloadByDatamap,
  Download, UploadConfirm)
- 4 node components (NodeTile, NodeDetail, NodeDetailPanel, AddNodeDialog)
- StatusBadge — statusMap refactored to use translation keys

Toast strings declared inline in these files are wrapped via t() at the
call site; standalone store-level toasts (stores/files.ts, stores/nodes.ts,
stores/updater.ts, stores/settings.ts) plus validator messages stay in
English here and follow in a separate commit.

Adds machine-translated Japanese (ja.json) for every new key.

Dynamic StatusBadge strings ("Uploading 45%", "Failed: <err>", "Quote: …")
pass through untranslated by design — the source emits them already-
formatted, so translating them requires the source to emit structured
tokens instead. Noted in StatusBadge comment for the follow-up.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sweeps the remaining store-level toast strings and validator messages:
- stores/files.ts — upload/download complete + failed, payment failed,
  datamap missing / read failed toasts
- stores/nodes.ts — add/start/stop/remove single + bulk toasts
- stores/updater.ts — install no-restart + install failed toasts
- utils/validators.ts — filenameError returns translation keys instead
  of literal strings; callers (DatamapSaveAsDialog, DownloadDialog) render
  via \$t(returnedKey)
- components/UpdateDialog.vue — title, badge, progress + action labels

Stores use options-API and can't call useI18n() (no setup context), so
plugins/i18n.client.ts now exports the i18n instance. A small module-scope
\`t()\` helper routes through \`i18n.global.t\` from each store.

ja.json grows accordingly. No untranslated keys reachable through the UI
in either locale (manual grep + DevTools console scan).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@Nic-dorman Nic-dorman force-pushed the feat/i18n-phase-2-sweep branch from d1e1e0d to 7b3281c Compare May 12, 2026 14:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant