Basic language selector & Fluent-based i18n infrastructure (Qortal Ext)

[QuickMythril]

Background / Problem Statement

Qortal Hub already supports multiple UI languages with a language selector and extensive translation coverage. The Qortal Chrome Extension currently appears to ship with hardcoded English strings and no visible language selector or i18n framework, despite being a key part of the Trifecta of interfaces alongside Hub and Go.

This makes the extension less accessible for non-English speakers and introduces inconsistency across interfaces. Adding a minimal i18n layer and language selector, reusing Hub’s language list and translation keys, will move the extension toward feature parity.

Scope (in)

• Introduce i18next + react-i18next to the extension’s React app.

• Create a public/locales/<lang>/<ns>.json structure for translations, starting with:

  • core namespace.
  • Languages: at minimum en, plus any languages that already have good coverage in Hub.

• Wrap the extension’s React root component with an i18n provider.

• Implement a Language settings section in the extension’s options/settings UI:

  • Uses the same language codes and labels as Hub.

• Persist user’s language selection via chrome.storage.sync (preferred) or chrome.storage.local.

• Translate core extension surfaces:

  • Popup UI (main dashboard).
  • Critical error/confirmation dialogs.
  • Any always-visible labels in toolbar or menus.

Scope (out)

• Full coverage of every string in the extension.
• Use of Chrome-native _locales / chrome.i18n (can be added later, but not required for this step).
• Translation of Chrome Web Store listing.

Acceptance Criteria

• Extension boots with:

  • A default language based on system/browser settings where possible, falling back to English.

• A Language selector is available in the extension settings/options UI.

  • Changing the language updates the extension UI without requiring a full browser restart (reload is acceptable if needed).
  • Selected language persists across browser restarts via chrome.storage.

• The following are translated via react-i18next using shared keys:

  • Popup’s main labels and nav items.
  • Critical error and confirmation dialog titles/messages.
  • Language selector labels themselves.

• Translation files for en and at least one additional language are present in public/locales, with key names aligned to Hub where semantics match.

Notes / Risks

• We should reuse Hub’s JSON translations where feasible:

  • Copy core namespace keys and values for en and other languages.
  • Add extension-specific keys under a new namespace (e.g., ext).

• Need to carefully consider bundle size:

  • Start with only a small set of namespaces and languages.
  • Consider lazy-loading additional languages if/when more are added.

• If _locales is desired later for Chrome-native UI pieces, that can be layered on top without rewriting the React i18n setup.