yourpart3/docs/UMLAUT_NORMALIZATION_PLAN.md

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