Add i18n support for top 10 Wikipedia languages

[xinbenlv]

Original Request

add i18n for top 10 Wikipedia language for our UI

Agent's Two Cents (could be wrong)

Everything below is the AI agent's best guess based on the current codebase.
Take with a grain of salt — the original request above is the only thing that came from a human.

Problem / Motivation

WikiLoop DoubleCheck currently only supports English, despite reviewing edits across all Wikipedia language editions. The top 10 Wikipedia languages by active editors — English (en), German (de), French (fr), Spanish (es), Japanese (ja), Russian (ru), Chinese (zh), Portuguese (pt), Italian (it), and Polish (pl) — represent the majority of potential reviewers. Adding translations for these languages would dramatically expand the user base and align the tool with its multilingual mission.

Proposed Solution

Create locale JSON files for each of the top 10 Wikipedia languages, leveraging the existing vue-i18n infrastructure already in place. Add a language selector to the web UI and extension popup. The userscript can piggyback on MediaWiki's native i18n system for most strings.

Top 10 Wikipedia languages (by active editors):

1. English (en) — already done ✅
2. German (de)
3. French (fr)
4. Spanish (es)
5. Japanese (ja)
6. Russian (ru)
7. Chinese (zh)
8. Portuguese (pt)
9. Italian (it)
10. Polish (pl)

Architecture Diagram

┌─────────────────────────────────────────────────────┐
│                  @doublecheck/core                   │
│  i18n/                                               │
│  ├── en.json  (88 keys, exists)                      │
│  ├── de.json  ← NEW                                  │
│  ├── fr.json  ← NEW                                  │
│  ├── es.json  ← NEW                                  │
│  ├── ja.json  ← NEW                                  │
│  ├── ru.json  ← NEW                                  │
│  ├── zh.json  ← NEW                                  │
│  ├── pt.json  ← NEW                                  │
│  ├── it.json  ← NEW                                  │
│  └── pl.json  ← NEW                                  │
│                                                       │
│  src/i18n/setup.ts                                    │
│  └── createDoubleCheckI18n()                          │
│  └── loadLocale(i18n, locale, messages) ← EXISTING    │
└────────────────────┬────────────────────────────────┘
                     │ imports locale JSON
        ┌────────────┼────────────┬──────────────┐
        ▼            ▼            ▼              ▼
   ┌─────────┐ ┌─────────┐ ┌──────────┐ ┌────────────┐
   │   web   │ │extension│ │userscript│ │  server    │
   │         │ │         │ │          │ │ (no i18n)  │
   │ i18n/   │ │ popup/  │ │ i18n.ts  │ └────────────┘
   │ index.ts│ │ main.ts │ │ (mw.msg  │
   │         │ │ (chrome │ │  + fall- │
   │ + lang  │ │  .i18n) │ │  back)   │
   │ selector│ │         │ │          │
   │  ← NEW  │ │         │ │          │
   └─────────┘ └─────────┘ └──────────┘

Dependencies & Potential Blockers

No major blockers identified. vue-i18n v9/v10 is already installed across core, web, and extension packages. The lazy-loading infrastructure (loadLocale()) already exists in packages/core/src/i18n/setup.ts. The main effort is translation of ~146 UI strings × 9 new languages.

How to Validate

• Each of the 9 new locale files loads without errors
• Switching languages in the web UI updates all visible strings
• Extension popup respects chrome.i18n.getUILanguage() and loads matching locale
• Userscript falls back correctly when MediaWiki doesn't have a translation
• No English strings leak through in any fully-translated locale
• Parameter interpolation works (e.g., {count}, {feed}) in all languages
• RTL considerations: none of the top 10 are RTL languages, but verify layout doesn't break with longer German/Russian strings
• Language selector persists choice across sessions (localStorage)

Scope Estimate

medium

Key Files/Modules Likely Involved

• packages/core/i18n/en.json — source strings to translate (88 keys)
• packages/core/src/i18n/setup.ts — lazy-loading setup, may need locale registry
• packages/web/src/i18n/en.json — web-specific strings (146 keys, superset of core)
• packages/web/src/i18n/index.ts — locale initialization, add language selector logic
• packages/extension/src/popup/main.ts — Chrome UI language detection
• packages/userscript/src/i18n.ts — bundled fallback messages

Rough Implementation Sketch

• Create 9 new JSON locale files in packages/core/i18n/ following the existing key format (Button-, Label-, Message-, etc.)
• Consolidate web locale with core (resolve the existing TODO in web/src/i18n/index.ts)
• Add a language selector component (dropdown or icon) to the web app header/settings
• Wire loadLocale() to dynamically import the selected language's JSON
• Store language preference in localStorage, default to browser's navigator.language
• Extension already detects browser language — just needs the locale files available
• For userscript: register translated messages via mw.messages.set() per locale
• Also i18n-ify hardcoded English strings in extension popup (App.vue lines 177-234) and web landing page (LandingPage.vue)

Open Questions

• Translation source: Use AI-generated translations as a starting point, then invite community review? Or wait for human translators? The README lists historical translation volunteers for ZH, UK, IT, ES, PT, JA, RU from v4.
• Consolidate web/core locales first? The web package duplicates core strings due to a bundler resolution issue (TODO in web/src/i18n/index.ts). Should this be fixed as a prerequisite?
• Partial translations: If a language is only 80% translated, show English fallback for missing keys (vue-i18n supports this natively via fallbackLocale)?
• Hardcoded strings: Should the ~15 hardcoded English strings in extension popup and landing page be i18n-ified as part of this issue or tracked separately?

Potential Risks or Gotchas

• German and Russian strings are often 30-50% longer than English — may break tight UI layouts (buttons, mobile views)
• Japanese and Chinese need proper font loading considerations
• The extension's _locales/ Chrome i18n system is separate from vue-i18n — may need both for full coverage
• AI-generated translations may have quality issues for technical Wikipedia terminology