feat(web): i18n — multi-language support for the web UI

[NilsR0711]

Summary

The web UI currently has all user-facing strings hardcoded in English. There is no internationalization (i18n) framework in place. This issue proposes adding multi-language support so the UI can be used in other languages.

Current state

• All strings are inline in React components (buttons, labels, headings, tooltips, error messages, onboarding steps, etc.)
• No i18n library installed (next-intl, react-i18next, etc.)
• No locale files or translation keys exist
• localeCompare is used in a few places for sorting, but there is no locale-aware UI rendering

Proposal

1 — Integrate an i18n framework

Add next-intl (idiomatic for Next.js) or react-i18next and set up:

• A messages/ directory with per-locale JSON files (e.g. en.json, de.json)
• A locale provider at the app root
• A useTranslations() hook (or equivalent) for accessing translated strings

2 — Extract all hardcoded strings

Replace inline English strings across all components with translation keys:

// before
<Button>Create new project</Button>

// after
<Button>{t('projects.createNew')}</Button>

Key areas to cover:

• Sidebar, navigation, tab strip
• Projects view & onboarding
• Dashboard & metrics
• Chat mode & terminal UI
• Settings & configuration
• Error messages & toasts
• Tooltips & placeholders

3 — Initial language support

Start with:

• English (en) — default, already exists as inline strings
• German (de) — second language

Additional languages can be contributed via PR once the framework is in place.

4 — Language switcher

Add a language selector in the settings or sidebar:

• Persisted in localStorage
• Falls back to browser locale (navigator.language)
• Default: English

Suggested implementation order

1. Install i18n framework + configure locale provider
2. Create en.json with all extracted strings
3. Replace hardcoded strings with t() calls (can be done incrementally per component area)
4. Add de.json translation
5. Add language switcher UI

Scope / non-goals

• Not translating CLI output or terminal content — only the web UI chrome
• Not translating user-generated content (project names, chat messages, etc.)
• Not RTL layout support (can be a follow-up if needed)

[trek-e]

Enhancement Review

Verdict: NEEDS_RFC

The proposal is technically straightforward and next-intl is the correct library choice for Next.js. The concern is timing, not feasibility. Web UI strings are actively changing — open PRs (#4615 welcome screen, #4252 gsd review command, #4247 eval-review, #4256 docs) are all touching UI text. Introducing i18n now means every in-flight PR must simultaneously extract their strings to translation keys, or the en.json will be stale on day one. The RFC needs to answer two questions: (1) Is there a web UI string freeze point on the roadmap, or a plan to land i18n before the current wave of UI PRs merges? (2) Who owns the German (de.json) translation and will it be kept in sync? German is a fine starting point but requires ongoing maintenance by someone with domain fluency in the GSD product vocabulary. Without answers to both, this will create more merge friction than it solves. The framework setup and string extraction are well-specified — this is purely a sequencing and ownership question.