Deutsche Umlaute in UI und Dokumentation korrigieren

docs/m2-technical-foundation.md

@@ -2,16 +2,16 @@
 
 Stand: 2026-07-13
 
-M2 fuehrt die technischen Grundbausteine fuer den SaaS-Umbau ein, ohne das
-Legacy-Verhalten oder das bestehende Design zu veraendern.
+M2 führt die technischen Grundbausteine für den SaaS-Umbau ein, ohne das
+Legacy-Verhalten oder das bestehende Design zu verändern.
 
-Status: abgeschlossen fuer den M2-Scope. Bewusst ausgelagerte Themen sind unten
-als Grenzen und M3-/M6-Uebergabe dokumentiert.
+Status: abgeschlossen für den M2-Scope. Bewusst ausgelagerte Themen sind unten
+als Grenzen und M3-/M6-Übergabe dokumentiert.
 
 ## Ziel
 
-- Versionierte Datenbankmigrationen statt loser Schema-Ausfuehrung.
-- Zentrales Bootstrap fuer Umgebung, Session und CSRF-Helper.
+- Versionierte Datenbankmigrationen statt loser Schema-Ausführung.
+- Zentrales Bootstrap für Umgebung, Session und CSRF-Helper.
 - Bestehende Legacy-Seiten bleiben kompatibel.
 - Layout-Trennung wird vorbereitet, aber noch nicht in bestehende Seiten
   hineingezogen.
@@ -28,47 +28,47 @@ als Grenzen und M3-/M6-Uebergabe dokumentiert.
   - `app_csrf_field()`
   - `app_verify_csrf()`
   - `app_require_csrf()`
-- `config.php` laedt den Bootstrap und startet die Session mit sicheren
+- `config.php` lädt den Bootstrap und startet die Session mit sicheren
   Cookie-Optionen.
-- Sessions werden standardmaessig unter `var/sessions` abgelegt, weil die
+- Sessions werden standardmäßig unter `var/sessions` abgelegt, weil die
   lokale PHP-Umgebung keinen beschreibbaren Systempfad garantiert. `var/` ist
-  von Git ignoriert. Der Pfad kann ueber `APP_SESSION_PATH` ueberschrieben
+  von Git ignoriert. Der Pfad kann über `APP_SESSION_PATH` überschrieben
   werden.
 - CSRF ist bewusst noch nicht global erzwungen. Die vorhandenen POST-Seiten
-  werden spaeter einzeln umgestellt, damit keine Formulare oder Spezialflows
+  werden später einzeln umgestellt, damit keine Formulare oder Spezialflows
   brechen.
 
 ### CSRF-Rollout
 
 Erste Legacy-POST-Seiten sind opt-in abgesichert:
 
-- `hinweise.php`: Hinweis anlegen und Hinweis loeschen. Der bisherige
-  GET-Loeschlink wurde durch ein POST-Formular mit CSRF-Token ersetzt.
-- `mitarbeiterverwalten.php`: Mitglied anlegen, Bearbeitungsformular oeffnen,
+- `hinweise.php`: Hinweis anlegen und Hinweis löschen. Der bisherige
+  GET-Löschlink wurde durch ein POST-Formular mit CSRF-Token ersetzt.
+- `mitarbeiterverwalten.php`: Mitglied anlegen, Bearbeitungsformular öffnen,
   Mitglied speichern, aktivieren und deaktivieren.
 - `namenanpassen.php`: Anzeigenamen aktualisieren.
 - `index.php`: eigene Web-Striche eintragen.
 - `stricheintragen.php`: Sammelerfassung von Strichen.
 - `einzahlung.php`: Sammelerfassung von Einzahlungen.
-- `letzteneintraege.php`: letzte Einzahlungen und Strich-Eintraege loeschen.
+- `letzteneintraege.php`: letzte Einzahlungen und Strich-Einträge löschen.
 - `csvupload.php`: CSV-Zahlungsimport.
 
 Noch offen:
 
 - Spezialprozesse: `mailversenden.php`, `jahresauswertung.php`.
 
-### CSV-Upload-Haertung
+### CSV-Upload-Härtung
 
 - `csvupload.php` nutzt jetzt CSRF.
 - Uploads werden unter `var/uploads` gespeichert und nach der Verarbeitung
-  geloescht. Damit liegen importierte Dateien nicht mehr im Webroot.
-- Dateiendung, Dateigroesse und MIME-Typ werden vor der Verarbeitung geprueft.
+  gelöscht. Damit liegen importierte Dateien nicht mehr im Webroot.
+- Dateiendung, Dateigröße und MIME-Typ werden vor der Verarbeitung geprüft.
 - Hochgeladene Dateien bekommen serverseitig erzeugte Zufallsnamen.
 - CSV-Auswertungswerte werden HTML-escaped ausgegeben.
 - Die PayPal-Namenssuche nutzt `Name` und `paypalname` mit expliziter
   Parameterbindung.
 
-Offen fuer M6:
+Offen für M6:
 
 - Importvorschau vor dem Schreiben.
 - Import-Batch/Audit-Log.
@@ -78,19 +78,19 @@ Offen fuer M6:
 
 - `database/migrations/0001_legacy_mysql_baseline.sql` bildet die bisherige
   MySQL-Dev-Baseline als erste versionierte Migration ab.
-- `scripts/dev-db.php` verwaltet `schema_migrations` und fuehrt neue
+- `scripts/dev-db.php` verwaltet `schema_migrations` und führt neue
   Migrationen idempotent aus.
-- `scripts/migrate.php` ist der direkte Runner fuer Migrationen.
+- `scripts/migrate.php` ist der direkte Runner für Migrationen.
 - `scripts/init-mysql-dev.php` nutzt ab jetzt ebenfalls die Migrationslogik.
 
 ### Layout
 
 - `header.php` und `footer.php` bleiben vorerst Legacy-Wrapper.
-- Die spaetere Trennung in Public-Layout und App-Layout wird erst umgesetzt,
+- Die spätere Trennung in Public-Layout und App-Layout wird erst umgesetzt,
   wenn die neue Route-/View-Struktur steht.
-- Die bestehende HTML5-UP-Struktur, Sidebar und Assets bleiben unveraendert.
+- Die bestehende HTML5-UP-Struktur, Sidebar und Assets bleiben unverändert.
 
-## Ausfuehrung
+## Ausführung
 
 Mit normaler PHP-CLI:
 
@@ -111,43 +111,43 @@ LD_LIBRARY_PATH="$PWD/.local/php/usr/lib/x86_64-linux-gnu:$PWD/.local/php/usr/li
 ```
 
 Die Skripte erwarten die bekannten Dev-Umgebungsvariablen `DB_HOST`, `DB_NAME`,
-`DB_USER` und `DB_PASS`. `scripts/init-mysql-dev.php` braucht zusaetzlich
+`DB_USER` und `DB_PASS`. `scripts/init-mysql-dev.php` braucht zusätzlich
 `DEV_AUTH_EMAIL`.
 
-## Aktueller Pruefstatus
+## Aktueller Prüfstatus
 
 - Migration `0001_legacy_mysql_baseline.sql` erfolgreich angewendet.
 - Zweiter Migrationslauf meldet: Datenbank ist aktuell.
-- PHP-Syntax fuer Bootstrap, Migrationen, Init-Skript und Config ist sauber.
-- Session-Start laeuft in der lokalen Dev-Umgebung ohne PHP-Warnings ueber
+- PHP-Syntax für Bootstrap, Migrationen, Init-Skript und Config ist sauber.
+- Session-Start läuft in der lokalen Dev-Umgebung ohne PHP-Warnings über
   `var/sessions`.
 - CSRF negative Tests: `hinweise.php`, `mitarbeiterverwalten.php` und
   `namenanpassen.php` liefern bei POST ohne Token HTTP 419.
-- CSRF positive Tests: gueltige Token funktionieren fuer Hinweis-Anlage,
-  Mitglieder-Bearbeitungsformular und Namensanpassung. Der temporaere
+- CSRF positive Tests: gültige Token funktionieren für Hinweis-Anlage,
+  Mitglieder-Bearbeitungsformular und Namensanpassung. Der temporäre
   Testhinweis wurde wieder entfernt.
-- CSRF negative Tests fuer Buchungsflows: `index.php`, `stricheintragen.php`
+- CSRF negative Tests für Buchungsflows: `index.php`, `stricheintragen.php`
   und `einzahlung.php` liefern bei POST ohne Token HTTP 419.
-- CSRF positive Tests fuer Buchungsflows: gueltige Token funktionieren fuer
-  eigene Web-Striche, Sammelstriche und Sammeleinzahlungen. Die temporaeren
+- CSRF positive Tests für Buchungsflows: gültige Token funktionieren für
+  eigene Web-Striche, Sammelstriche und Sammeleinzahlungen. Die temporären
   Testbuchungen wurden wieder entfernt.
-- CSRF negative Tests fuer Korrektur-/Loeschflows: `letzteneintraege.php`
+- CSRF negative Tests für Korrektur-/Löschflows: `letzteneintraege.php`
   liefert bei POST ohne Token HTTP 419.
-- CSRF positive Tests fuer Korrektur-/Loeschflows: gueltige Token funktionieren
-  fuer das Loeschen temporaerer Einzahlungs- und Strich-Testeintraege.
-- CSRF negative Test fuer CSV-Upload: POST ohne Token liefert HTTP 419.
-- CSV-Upload positive Tests: gueltiges Token verarbeitet eine CSV-Datei, erkennt
-  eine PayPal-Alias-Dublette und hinterlaesst keine Datei in `var/uploads`.
+- CSRF positive Tests für Korrektur-/Löschflows: gültige Token funktionieren
+  für das Löschen temporärer Einzahlungs- und Strich-Testeinträge.
+- CSRF negative Test für CSV-Upload: POST ohne Token liefert HTTP 419.
+- CSV-Upload positive Tests: gültiges Token verarbeitet eine CSV-Datei, erkennt
+  eine PayPal-Alias-Dublette und hinterlässt keine Datei in `var/uploads`.
 - CSV-Upload negative Tests: Nicht-CSV-Dateien werden abgewiesen.
-- Golden Master weiterhin gruen mit 104 Assertions.
-- HTTP-Smoke weiterhin gruen mit 23 sicheren Seiten inklusive Landingpage, Login,
-  Registrierung, Passwort-Reset, E-Mail-Verifikation und geschuetzter
-  Mandant-Einstellungen, geschuetzter Mandantenauswahl sowie Ledger-Preview.
+- Golden Master weiterhin grün mit 104 Assertions.
+- HTTP-Smoke weiterhin grün mit 23 sicheren Seiten inklusive Landingpage, Login,
+  Registrierung, Passwort-Reset, E-Mail-Verifikation und geschützter
+  Mandant-Einstellungen, geschützter Mandantenauswahl sowie Ledger-Preview.
 
 ## Bewusste Grenzen
 
-- Keine Tenant-/User-/Rollen-Tabellen in M2. Diese gehoeren zu M3.
-- Keine globale CSRF-Erzwingung fuer Spezialprozesse. `mailversenden.php` und
+- Keine Tenant-/User-/Rollen-Tabellen in M2. Diese gehören zu M3.
+- Keine globale CSRF-Erzwingung für Spezialprozesse. `mailversenden.php` und
   `jahresauswertung.php` werden in M6 als Jobs mit Dry-Run, Audit und
   Versandlog neu betrachtet.
 - Kein Layout-Umbau in M2. Die visuelle Struktur bleibt stabil; Public-/App-
@@ -157,26 +157,26 @@ Die Skripte erwarten die bekannten Dev-Umgebungsvariablen `DB_HOST`, `DB_NAME`,
 ## Abschlusskriterien
 
 - Migrationsrunner ist vorhanden und idempotent.
-- Bootstrap, Session und CSRF-Helper sind zentral verfuegbar.
-- Die relevanten Legacy-Schreibseiten sind CSRF-geschuetzt.
+- Bootstrap, Session und CSRF-Helper sind zentral verfügbar.
+- Die relevanten Legacy-Schreibseiten sind CSRF-geschützt.
 - CSV-Uploads liegen nicht mehr im Webroot.
 - Bestehende Legacy-Seiten bleiben per HTTP-Smoke erreichbar.
-- Golden-Master-Fachwerte bleiben unveraendert.
+- Golden-Master-Fachwerte bleiben unverändert.
 
-## Uebergabe an M3
+## Übergabe an M3
 
 M3 startet mit additiven SaaS-Tabellen und einer Default-Tenant-Abbildung. Die
-Legacy-Seiten sollen dabei weiterhin ueber die bestehenden Tabellen laufen, bis
+Legacy-Seiten sollen dabei weiterhin über die bestehenden Tabellen laufen, bis
 der fachliche Kern in M4/M5 schrittweise auf das Zielmodell umgestellt wird.
 
 M3 wurde inzwischen gestartet. Umgesetzte Details stehen in
-`docs/m3-saas-basis-vorbereitung.md`. Der urspruengliche Startpunkt war:
+`docs/m3-saas-basis-vorbereitung.md`. Der ursprüngliche Startpunkt war:
 
 1. `tenants`, `tenant_settings`, `users`, `tenant_memberships` und
    `participants` als neue Migration anlegen.
-2. Einen Default-Tenant fuer die bestehende Kaffeeliste definieren.
+2. Einen Default-Tenant für die bestehende Kaffeeliste definieren.
 3. Bestehende `kl_Mitarbeiter` in `participants` spiegeln, inklusive
    `legacy_mitarbeiter_id`.
 4. Admins aus `kl_Mitarbeiter.admin` als `tenant_memberships.role = 'admin'`
-   beziehungsweise fuer den ersten Hauptnutzer als `owner` abbilden.
-5. Erst danach Login/Registrierung und Public-/App-Routen anschliessen.
+   beziehungsweise für den ersten Hauptnutzer als `owner` abbilden.
+5. Erst danach Login/Registrierung und Public-/App-Routen anschließen.