# Subdomains durchgängig zweisprachig — Design / Spec

**Datum:** 2026-06-21 · **Branch:** `feat/wissen-subdomain`
**Ziel:** Beim Sprachwechsel bleibt die Sprache über ALLE Subdomains erhalten, jede Subdomain-Seite ist direkt in DE *und* EN erreichbar/verlinkt, und der statische Subdomain-Inhalt wird serverseitig sauber englisch (Langtail via bestehenden Google-Translate-Fallback). Variante A, Tiefe „Chrome + Landing".

## Ist-Zustand (verifiziert)
- `/en` auf Subdomains funktioniert strukturell (SubdomainDispatcher behandelt `/de|/en`, innerer Dispatch trifft `LocalizedPageController` → `EnglishHtmlLocalizer::translate`).
- `hreflang`-Alternates auf Subdomain-`/de`+`/en` werden bereits pro Seite ausgegeben (layouts/app.blade.php). „Doppelt erreichbar" (SEO) ist da.
- **Lücke 1 (Struktur):** `SubdomainRegistry::url()` erzeugt Cross-Subdomain-Links OHNE Locale → Hub-Nav/Footer/Welt-Karten verlieren beim Klick die Sprache (nur Cookie+302 rettet es).
- **Lücke 2 (Übersetzung):** `EnglishHtmlLocalizer` ist ein flaches ~150-Phrasen-`strtr`-Dictionary, das nur geteilten Chrome + Apex/Recht abdeckt. Subdomain-Inhalte stehen nicht drin.

## Bausteine

### B1 — Sprache trägt über Subdomains
- `SubdomainRegistry::url(string $key, string $path = '', ?string $locale = null): string` — bei gesetztem `$locale ∈ {de,en}` wird der Pfad mit `/{locale}` geprefixt. Default `null` = bisheriges Verhalten (Canonical/Sitemap unberührt).
- Neuer Helfer `SubdomainRegistry::currentLocale(): string` (aus `request()->segment(1)`, Default `de`).
- Call-Sites, die bereichsübergreifend verlinken, übergeben die aktive Locale: Hub-Header-Welten + Footer-„Alle Bereiche" (layouts/app.blade.php), `welcome`-Welt-Karten (welcome.blade.php). Auf `/en` zeigen sie dann direkt auf `host/en/…`.

### B2 — Modularer Übersetzer + pro-Bereich-Wörterbücher
- `EnglishHtmlLocalizer::translate($html)` mergt **Basis-Dictionary** (geteilter Chrome) + **Bereichsmodul** des aktuellen Bereichs (`SubdomainRegistry::currentArea()['key']`).
- Bereichsmodule unter `app/Support/Localization/{key}.php` (geben `array<string,string>` zurück). Neu mit hand-Qualität für statische Landing-/Chrome-Texte: `it-hilfe`, `webdesign`, `tester`, `shop`, `hosting`, `karc`. Fehlt ein Modul → nur Basis (kein Fehler).
- Basis = der bisherige Dictionary-Inhalt (in `base.php` ausgelagert).
- Langtail (News-Artikel, einzelne Webtools, Wissen) bleibt am clientseitigen Google-Translate-Fallback.

### B3 — Tests
- `tests/Feature/I18n/CrossSubdomainLocaleTest.php`: `url('ios','x','en')` → enthält `/en/`; Default ohne Prefix; auf einer `/en`-Subdomain-Seite tragen die Bereichs-Links `/en`.
- `tests/Feature/I18n/AreaTranslationTest.php`: `EnglishHtmlLocalizer::translate` übersetzt im jeweiligen Bereich einen repräsentativen Landing-String (Basis + Modul gemerged); Basis-Strings weiter übersetzt.
- Erreichbarkeit: representative Subdomain unter `/de` UND `/en` → 200 (mit `X-Requested-With`, vgl. i18n-Konvention).

## Bewusst draußen
Voll-Hand-Übersetzen jedes Absatzes; externe Übersetzungs-API (Variante C); Umbau aller Views auf Laravel-`__()`. `umfrage`-Subdomain-INHALT (kommt vom User) — die Infrastruktur ist aber so, dass eine neue Subdomain automatisch zweisprachig ist (1 Registry-Eintrag + optional 1 Localization-Modul).