# Umlaut-Normalisierung Plan

## Ziel

Alle sichtbaren deutschsprachigen UI-Texte sollen konsistent echte Umlaute und korrektes `ß` verwenden.

Beispiele:
- `ae` -> `ä`
- `oe` -> `ö`
- `ue` -> `ü`
- `ss` -> `ß`, wenn orthografisch korrekt

Nicht Teil dieses Schritts:
- technische Bezeichner, Dateinamen, Keys, Routen, API-Felder
- bewusst ASCII-basierte interne Kennungen
- englische, spanische oder backendseitige maschinennahe Werte
- bestehende Konzept-/Audit-Dokumente, sofern nicht explizit gewünscht

## Leitregeln

- Nur sichtbare Texte anfassen.
- Keine Übersetzungs-Keys umbenennen, wenn nur der angezeigte Wert falsch ist.
- Keine Logikänderung mit Sprachkorrekturen vermischen.
- `ss` nur dort zu `ß` ändern, wo es sprachlich korrekt ist.
- Neue Texte immer direkt mit echter deutscher Schreibweise anlegen.

## Scope

### 1. Direkte UI-Texte in Vue-Dateien

Prüfen und korrigieren in:
- `frontend/src/components/**/*.vue`
- `frontend/src/views/**/*.vue`
- `frontend/src/dialogues/**/*.vue`

Typische Problemfälle:
- Überschriften
- Buttons
- Statushinweise
- Hilfetexte
- Leerzustände
- Fehlermeldungen

### 2. i18n-Inhalte

Prüfen und korrigieren in:
- `frontend/src/i18n/locales/de/**/*.json`

Besonders relevant:
- Navigation
- Header/Footer
- Home
- Blog
- Forum
- Vokabeltrainer
- Minigames
- Einstellungen
- Admin

### 3. Gemeinsame Shell- und Systemtexte

Zuerst prüfen:
- `frontend/src/components/AppSectionBar.vue`
- `frontend/src/components/AppNavigation.vue`
- `frontend/src/components/AppHeader.vue`
- `frontend/src/components/AppFooter.vue`
- `frontend/src/components/DialogWidget.vue`
- `frontend/src/components/MessageboxWidget.vue`

### 4. Produktbereiche mit hoher Sichtbarkeit

Danach prüfen:
- `frontend/src/views/home/**/*`
- `frontend/src/views/social/**/*`
- `frontend/src/views/falukant/**/*`
- `frontend/src/views/minigames/**/*`
- `frontend/src/views/settings/**/*`
- `frontend/src/views/blog/**/*`
- `frontend/src/views/admin/**/*`

## Abarbeitung

### Phase A: Inventur

1. Fundstellen mit Suchmustern sammeln.
2. Treffer in drei Klassen sortieren:
- `sichtbarer UI-Text`
- `i18n-Wert`
- `nicht anfassen` wie Variablen, Klassen, Keys, Pfade

Empfohlene Suchmuster:
- `Persoen`
- `Gaeste`
- `Zurueck`
- `Uebersicht`
- `Loesch`
- `Fuer`
- `Oeff`
- `Schli`
- `groess`
- `aend`
- `moeg`
- `ueber`
- `uebrig`
- `fuer`
- `waehr`
- `muess`
- `koenn`

### Phase B: Shell zuerst

Zuerst alle global sichtbaren Texte korrigieren:
- Bereichsleisten
- Navigation
- Header
- Footer
- Standarddialoge

Ziel:
- zentrale UI sofort sprachlich konsistent

### Phase C: i18n-DE bereinigen

Danach alle deutschen Locale-Dateien durchgehen.

Vorgehen:
- nur Werte ändern, nicht die Key-Namen
- orthografische Einzelprüfung bei `ss` -> `ß`
- HTML-haltige Texte mit prüfen, damit keine alten ASCII-Umschreibungen stehen bleiben

### Phase D: Direkttexte in Views und Dialogen

Dann alle nicht-i18n-basierten sichtbaren Texte korrigieren.

Priorität:
1. Home, Navigation, Auth
2. Social, Blog, Settings
3. Falukant, Minigames, Admin

### Phase E: Konsistenzreview

Zum Schluss ein kompletter Review auf typische Restfehler:
- `ue` in sichtbaren Labels
- `oe` in Überschriften
- `ae` in Buttons und Hinweisen
- `ss` statt `ß` in Wörtern wie `dass`, `groß`, `außer`, `heißen`, `Fuß`, `Maß`

## Abnahmekriterien

Der Schritt gilt als abgeschlossen, wenn:
- in allen sichtbaren deutschen UI-Texten keine ASCII-Umschreibungen mehr verbleiben
- zentrale Shell-Texte vollständig normalisiert sind
- `de`-Locale-Dateien keine falschen Umschreibungen mehr enthalten
- Builds weiterhin sauber laufen
- keine technischen Keys oder internen Bezeichner versehentlich geändert wurden

## Risiken

- versehentliche Änderung von technischen Strings statt UI-Texten
- falsche `ß`-Korrekturen in Fällen, in denen `ss` korrekt ist
- Mischung aus i18n-Texten und hart codierten Texten kann zu doppelter Pflege führen

## Umsetzungsempfehlung

Die eigentliche Umsetzung sollte in zwei Arbeitsblöcken passieren:

1. `UN1`
Shell + i18n-DE + hochsichtbare Bereiche

2. `UN2`
Restliche Views/Dialoge + Abschlussreview

## Ergebnisdokumentation

Nach Abschluss sollte kurz dokumentiert werden:
- welche Dateien geändert wurden
- ob nur sichtbare Texte geändert wurden
- ob noch bewusst ASCII-basierte technische Strings bestehen