fix(admin): replace hardcoded German strings with i18n keys (#7735)

[JohnMcLear]

Summary

Closes #7735.

PR #7716 (admin design rework) shipped the new admin UI with ~50+ literal German strings baked into JSX. Existing <Trans i18nKey="…"/> calls resolve to whatever language i18next detects (French, English, etc.), but the literals stay German — producing the "mix of French, English and German-ish" salad #7735 reports.

This PR:

• Adds 90+ keys to src/locales/en.json (admin.*, admin_login.*, admin_pads.*, admin_plugins.*, admin_plugins_info.*, admin_settings.*, admin_shout.*, and the previously-orphaned update.page.{disabled,unauthorized,error}).
• Replaces every hardcoded literal in admin/src/{App,LoginScreen,HomePage,HelpPage,PadPage,SettingsPage,ShoutPage}.tsx with t() or <Trans>.
• Threads i18n.language into PadPage so relativeTime() and toLocale*() honour the user's locale instead of forcing de-DE.

Non-EN locales pick up translations from translatewiki on its normal round-trip; until then i18next falls back to en.json.

Test plan

• pnpm --filter ep_etherpad-lite vitest run tests/backend-new/specs/admin-i18n-source-lint.test.ts — 10 source-lint assertions (10 pass).
• pnpm --filter admin tsc --noEmit — clean.
• pnpm --filter admin vite build — builds.
• Playwright admin spec (tests/frontend-new/admin-spec/admini18n.spec.ts) extended with rendered-text assertions for Home, Pads, Help, Login in EN; CI runs.
• Visually confirm /admin/?lng=en and /admin/?lng=de after merge.

🤖 Generated with Claude Code

[qodo-code-review]

ⓘ You've reached your Qodo monthly free-tier limit. Reviews pause until next month — upgrade your plan to continue now, or link your paid account if you already have one.

[qodo-free-for-open-source-projects]

Review Summary by Qodo

Replace hardcoded German strings with i18n keys in admin UI

🐞 Bug fix ✨ Enhancement

Walkthroughs

Description

• Replaces ~50 hardcoded German strings with i18n keys across admin pages
• Adds 90+ translation keys to en.json for admin UI components
• Threads i18n.language into PadPage for locale-aware date/time formatting
• Adds source-level lint test to prevent German literal regressions
• Extends Playwright admin spec with rendered text assertions

Diagram

flowchart LR
  A["Admin Pages<br/>App, LoginScreen, HomePage,<br/>HelpPage, PadPage, etc."] -->|"Replace hardcoded<br/>German literals"| B["t() and Trans<br/>i18n calls"]
  B -->|"Reference"| C["en.json<br/>90+ new keys"]
  D["PadPage"] -->|"Thread i18n.language"| E["Locale-aware<br/>formatters"]
  F["Source Lint Test<br/>admin-i18n-source-lint.test.ts"] -->|"Catch regressions"| G["CI validation"]
  H["Playwright Spec<br/>admini18n.spec.ts"] -->|"Assert rendered<br/>English text"| I["Rendered output<br/>verification"]

Loading

File Changes

1. src/tests/backend-new/specs/admin-i18n-source-lint.test.ts 🧪 Tests +92/-0

New source-level lint test for German literals

src/tests/backend-new/specs/admin-i18n-source-lint.test.ts

---

2. src/tests/frontend-new/admin-spec/admini18n.spec.ts 🧪 Tests +90/-14

Extended Playwright spec with rendered text assertions

src/tests/frontend-new/admin-spec/admini18n.spec.ts

---

3. admin/src/App.tsx ✨ Enhancement +4/-4

Replace hardcoded strings with i18n keys

admin/src/App.tsx

---

View more (7)

4. admin/src/pages/HelpPage.tsx ✨ Enhancement +12/-12

Internationalize help page copy and labels

admin/src/pages/HelpPage.tsx

---

5. admin/src/pages/HomePage.tsx ✨ Enhancement +18/-19

Internationalize plugin manager page strings

admin/src/pages/HomePage.tsx

---

6. admin/src/pages/LoginScreen.tsx ✨ Enhancement +9/-7

Add i18n to login form labels and messages

admin/src/pages/LoginScreen.tsx

---

7. admin/src/pages/PadPage.tsx ✨ Enhancement +61/-61

Internationalize pads page and thread locale formatting

admin/src/pages/PadPage.tsx

---

8. admin/src/pages/SettingsPage.tsx ✨ Enhancement +4/-3

Add i18n to settings page toast messages

admin/src/pages/SettingsPage.tsx

---

9. admin/src/pages/ShoutPage.tsx ✨ Enhancement +5/-3

Internationalize communication page strings

admin/src/pages/ShoutPage.tsx

---

10. src/locales/en.json ✨ Enhancement +94/-0

Add 90+ new admin UI translation keys

src/locales/en.json

---

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0)

Context used

✅ Tickets: 🎫 Hardcoded Non English default Translations on /admin page

1. Unsafe locale into Intl 🐞 Bug ☼ Reliability

Description

PadPage uses i18n.language directly as the locale argument to
toLocaleString()/toLocaleDateString()/toLocaleTimeString(), which can throw a RangeError and
break rendering if the detected language is malformed (for example via a crafted ?lng= value).
This is user-controlled in the admin SPA because language detection is driven by
i18next-browser-languagedetector.

Code

admin/src/pages/PadPage.tsx[R348-353]

+                      <td className="pm-num">{pad.revisionNumber.toLocaleString(locale)}</td>
                      <td>
                        <div className="pm-time">
-                          <span className="pm-time-rel">{relativeTime(pad.lastEdited)}</span>
-                          <span className="pm-time-abs">{fmtDate(pad.lastEdited)}</span>
+                          <span className="pm-time-rel">{relativeTime(t, pad.lastEdited)}</span>
+                          <span className="pm-time-abs">{fmtDate(locale, pad.lastEdited)}</span>
                        </div>

Evidence

Language detection is handled by i18next’s browser LanguageDetector, and the resulting
i18n.language is used as the locale argument to Intl formatters in PadPage. Because the detected
language can be influenced via ?lng=..., a malformed value can propagate into Intl APIs and throw
at runtime.

admin/src/localization/i18n.ts[55-64]
src/tests/frontend-new/admin-spec/admini18n.spec.ts[37-41]
admin/src/pages/PadPage.tsx[30-36]
admin/src/pages/PadPage.tsx[44-46]
admin/src/pages/PadPage.tsx[348-353]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`PadPage` passes `i18n.language` directly to `toLocaleString()` / `toLocaleDateString()` / `toLocaleTimeString()`. If `i18n.language` contains a malformed locale tag (e.g. `en_US`), the Intl methods can throw `RangeError`, causing the `/admin/pads` page to fail to render.

### Issue Context
`i18n.language` is influenced by `i18next-browser-languagedetector` (including URL `?lng=`), and is not validated/sanitized before being used as an Intl locale.

### Fix Focus Areas
- admin/src/pages/PadPage.tsx[348-353]

### Suggested fix
1. Introduce a small helper to produce a safe locale:
  - Normalize common bad forms (e.g., replace `_` with `-`).
  - Validate via a guarded Intl check (try/catch around `Intl.DateTimeFormat.supportedLocalesOf()`), falling back to `undefined` or `'en'`.
2. Use the sanitized locale for all `toLocale*()` calls (and keep `relativeTime()` using `t()` as it is).

Example approach (TypeScript):
```ts
const sanitizeLocale = (lng?: string) => {
 const raw = (lng ?? '').trim();
 if (!raw) return 'en';
 const normalized = raw.replace(/_/g, '-');
 try {
   // Will throw on structurally invalid tags
   const supported = Intl.DateTimeFormat.supportedLocalesOf([normalized]);
   return supported[0] ?? 'en';
 } catch {
   return 'en';
 }
};

const locale = sanitizeLocale(i18n.resolvedLanguage ?? i18n.language);
```

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---