🎃 Set up i18n in the frontend and translate the sidebar and sign-in form (DE, IT)

Start with packages/frontend/src/app/layout.tsx, next.config.ts, and package.json to understand the existing layout, Sentry configuration, and dependencies; then inspect app-sidebar.tsx and app/login/page.tsx for the strings in scope. Add locale resolution, translations, switching, key-parity checks, and the documented coverage, while preserving existing routing and Sentry behavior. Verify the acceptance criteria with the i18n Playwright spec and existing frontend checks.

Part of the October Challenge #846.

Why

Many teams using AnythingMCP work in German- or Italian-speaking companies (think of the ERP connectors for SAP, Xentral, JTL-Wawi), and the people who set up connectors are often not the ones who read English comfortably. The README is already translated (README.de.md, README.ja.md, README.zh-CN.md) and the cookie banner speaks seven languages, but every UI string is hard-coded English and layout.tsx says lang="en". This issue lays the foundation and proves it on one area; each further page becomes its own small follow-up issue.

Self-hosted vs Cloud

• Self-hosted: enabled in Community and Business. Optional env DEFAULT_LOCALE (default en) for instances where everyone speaks one language.
• Cloud (DEPLOYMENT_MODE=cloud): enabled, same behaviour; DEFAULT_LOCALE stays unset (en). The locale is a per-browser preference and never leaves the browser except as a cookie to our own frontend.
• Who can use it: every visitor, signed in or not (the sign-in page must be translated before login). No role checks, no org data involved.

What to build

1. Library: next-intl v4 (supports Next.js 16 App Router and React 19, which we use: next ^16.3.6). Use its "without i18n routing" setup: no /[locale]/ URL segment. Locale prefixes would break src/proxy.ts's public-path list, the backend rewrites in next.config.ts and every bookmarked/OAuth callback URL.
2. Locale resolution in src/i18n/request.ts (getRequestConfig): cookie NEXT_LOCALE → Accept-Language best match among en, de, it → DEFAULT_LOCALE → en.
3. Root layout: set <html lang={locale}> and wrap children with NextIntlClientProvider (most pages are 'use client', so they use useTranslations). Compose the next-intl plugin with the existing withSentryConfig in next.config.ts — do not drop Sentry.
4. Messages: packages/frontend/messages/{en,de,it}.json, namespaced by area: nav.*, auth.signIn.*. en.json is the source of truth. Add a tiny script or test that fails when de/it miss a key present in en (missing keys must fall back to English at runtime, not render the key).
5. Language switcher: a small select in the sidebar footer menu (next to "Log out") and on /login (before sign-in). It sets the NEXT_LOCALE cookie (SameSite=Lax, 1 year, path /) and calls router.refresh().
6. Translate as proof (only these):
   • Sidebar: group titles and link labels in NAV, "Settings", "Log out".
   • Sign-in/register form on /login: heading, field labels, password rules, submit/switch buttons, the recovery-code links. Not the 2FA, license-key or email-verification sub-screens.
     Translations must be natural, not machine-literal; native speakers among maintainers will review DE and IT.
7. Do not translate: connector/tool names, adapter descriptions from the catalog, backend error messages (they come from the API in English).

Where to look

• packages/frontend/package.json — Next 16 / React 19, no i18n lib yet.
• packages/frontend/src/app/layout.tsx:72 — hard-coded lang="en"; :81 Providers.
• packages/frontend/next.config.ts:45 — withSentryConfig(nextConfig, …).
• packages/frontend/src/proxy.ts:4 — public paths; must keep working unchanged.
• packages/frontend/src/components/app-sidebar.tsx:43 — NAV; :185 "Log out"; :202 "Settings".
• packages/frontend/src/app/login/page.tsx:873 (heading), :920–:960 (fields), password rules ~:970.
• packages/frontend/src/components/cookie-consent.tsx:37, :424 — existing per-language strings and browser auto-detection; follow-up can make it use the chosen locale.
• packages/frontend/src/lib/translation-safe-dom.ts — keep it: users still run browser translators on untranslated pages.
• packages/frontend/tests/e2e/login-redirect-query.spec.ts — Playwright pattern for /login.

Acceptance criteria

• With Accept-Language: de-DE and no cookie, /login renders German and <html lang="de">; with it-IT Italian; with fr-FR English.
• Switching language sets the cookie, persists across reload and sign-in, and overrides Accept-Language.
• Sidebar labels appear in the chosen language; all untranslated pages still render English, no raw keys visible.
• Key-parity check runs in CI (npm run lint --workspace=packages/frontend or a node --test script).
• Playwright spec packages/frontend/tests/e2e/i18n.spec.ts (use locale / extraHTTPHeaders in the test) covers the three cases above; existing e2e specs still pass (they assert English strings).
• Docs: "Translating the UI" section in docs/ (how to add a key, how to add a language) and a pointer in README.md.

Out of scope

• Translating other pages — maintainers will open one follow-up issue per page/area (dashboard, connectors, MCP servers, settings…).
• Storing the language on the user record / backend, translated emails, translated backend errors.
• Japanese, Chinese and other languages (easy to add once the foundation lands).
• Locale-aware number/date formatting (toLocaleString('en-US') calls) — follow-up.

Size

L (several days, may be split: setup + switcher first, translations second).

How to claim

Comment "I'd like to work on this" and we'll assign you. Rules in #846.