Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
#859 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
next.js, playwright, react, typescript

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement hacktoberfest help wanted

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.

Ngôn ngữ chính
TypeScript
Star
856
Fork
82
Merge trung bình
6 giờ 44 phút
Pull request đã merge (30 ngày)
181

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của HelpCode-ai/anythingmcp

Tất cả issue của HelpCode-ai/anythingmcp

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.