Die Landingpage haus-schleusingen.de ist aktuell nur auf Deutsch verfuegbar. Die Zielgruppe umfasst jedoch zunehmend international sprechende Interessenten:
Ukrainisch: Martins Partnerin Olha (geb. 11.07.1983, Dnipro, Ukraine) hat Kontakte in die ukrainische Community
Russisch: haeufige Zweitsprache in der Region (Suedthueringen hat russischsprachige Zuwanderer)
Aktuelle Sprachen-Strategie: None. Browser-Sprache wird ignoriert, User ohne Deutschkenntnisse sehen unverstaendlichen Content.
Geschaeftskontext: Miet-Interessenten sollen in ihrer Muttersprache verstehen, was die Immobilie bietet -> hoehere Conversion-Rate bei Anfragen, professionelleres Image, Zugang zu nicht-deutschsprachigen Mietern.
User Story
Als Besucher der Haus-Schleusingen-Landingpage moechte ich die Seite in meiner Muttersprache (Deutsch/Ukrainisch/Russisch/Englisch) lesen koennen, damit ich Mietkonditionen, Galerie, Lage und Kontaktinformationen verstehe, ohne erst Woerterbuch oder Google Translate zu bemuehen.
Akzeptanzkriterien
Sprach-Umfang
4 Sprachen verfuegbar: DE (Default), UK (Ukrainisch), RU (Russisch), EN (Englisch)
Impressum + Datenschutz bleiben auf Deutsch (rechtliche Pflicht Paragraph 5 TMG), mit sichtbarem Hinweis "Diese Seite ist nur auf Deutsch verfuegbar" bei Sprachwechsel
Alle 4 Sprachen haben vollstaendige Uebersetzung (keine Fallback-Luecken)
Sprach-Detection
Server-side Accept-Language Header wird beim ersten Request ausgewertet
Vorschlag: ein gemeinsames Issue (dieses hier) mit Gitea-Checklist + Closes #N in separaten Sub-Issue-PRs, OR separates Issue pro Sub-Task. Martins Entscheidung.
app/views/layouts/main.php (Layout-Datei, muss <html lang> dynamisch werden)
app/views/home/index.php (Home-View, 500+ Zeilen Content, muss translatet werden)
Neue Konvention (gilt ab sofort fuer alle Issues)
ALLE neuen Features muessen Translation-Key-basiert implementiert werden. Die t("key")-Helper-Funktion ist der Standard fuer jeden neuen User-String. Translation-Files in app/Locales/ muessen mit-aktualisiert werden. Code-Review schliesst fehlende Translation-Keys explizit ein.
Diese Konvention wird in app/AGENTS.md und in der Skill gitea-dev-orchestrator (DoR-Checkliste) verankert.
Sub-Issues (A-F)
Alle Sub-Issues im Milestone Multi-Language MVP (#1):
Grund: Beim Code-Review auf https://haus.test.kies-media.de wurden Layout-Probleme in der Headernavigation entdeckt, die mit dem bestehenden inline-HTML-Pattern in app/views/home/index.php kollidieren.
Was passiert ist:
Die Home-View enthält den kompletten <body>-Content inline (inkl. <nav>, <section class="hero">, etc.)
Mein Locale-Switcher im main.php-Layout hat das Layout zerschossen, weil der bestehende Header in home/index.php hardcoded ist und nicht aus dem Layout-Template kommt
Die Architektur ist nicht i18n-ready: home/index.php muss erst so refactored werden, dass es nur den Hauptcontent rendert, nicht den ganzen <body>
Was Martin jetzt hat:
Server-Rollback auf pre-multilang Stand ✅ (alle 32 Bilder vorhanden, Navigation wie vorher)
Branch feature/multilanguage-mvp behalten — der Code ist solide, nur das HTML-Pattern passt nicht
Nächste Schritte (separates Issue nötig):
Refactor app/views/home/index.php: Body-Content aus dem HTML-File rausziehen, damit das main.php-Layout (mit <head>, Navigation, Footer) greifen kann
Refactor app/views/impressum/index.php und datenschutz/index.php: gleiche Logik
Dann erst: Locale-Switcher im Layout-Template main.php einbauen — wird dann sauber auf allen 3 Seiten gerendert
Branch und PR bleiben erhalten, der Code geht nicht verloren.
## ⚠️ Geschlossen ohne Merge
**Grund:** Beim Code-Review auf https://haus.test.kies-media.de wurden Layout-Probleme in der Headernavigation entdeckt, die mit dem bestehenden inline-HTML-Pattern in `app/views/home/index.php` kollidieren.
**Was passiert ist:**
- Die Home-View enthält den kompletten `<body>`-Content inline (inkl. `<nav>`, `<section class="hero">`, etc.)
- Mein Locale-Switcher im `main.php`-Layout hat das Layout zerschossen, weil der bestehende Header in `home/index.php` hardcoded ist und nicht aus dem Layout-Template kommt
- Die Architektur ist **nicht i18n-ready**: `home/index.php` muss erst so refactored werden, dass es nur den Hauptcontent rendert, nicht den ganzen `<body>`
**Was Martin jetzt hat:**
- Server-Rollback auf pre-multilang Stand ✅ (alle 32 Bilder vorhanden, Navigation wie vorher)
- Branch `feature/multilanguage-mvp` behalten — der Code ist solide, nur das HTML-Pattern passt nicht
**Nächste Schritte (separates Issue nötig):**
1. **Refactor `app/views/home/index.php`**: Body-Content aus dem HTML-File rausziehen, damit das `main.php`-Layout (mit `<head>`, Navigation, Footer) greifen kann
2. **Refactor `app/views/impressum/index.php` und `datenschutz/index.php`**: gleiche Logik
3. **Dann erst**: Locale-Switcher im Layout-Template `main.php` einbauen — wird dann sauber auf allen 3 Seiten gerendert
Branch und PR bleiben erhalten, der Code geht nicht verloren.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Kontext
Die Landingpage
haus-schleusingen.deist aktuell nur auf Deutsch verfuegbar. Die Zielgruppe umfasst jedoch zunehmend international sprechende Interessenten:Aktuelle Sprachen-Strategie: None. Browser-Sprache wird ignoriert, User ohne Deutschkenntnisse sehen unverstaendlichen Content.
Geschaeftskontext: Miet-Interessenten sollen in ihrer Muttersprache verstehen, was die Immobilie bietet -> hoehere Conversion-Rate bei Anfragen, professionelleres Image, Zugang zu nicht-deutschsprachigen Mietern.
User Story
Als Besucher der Haus-Schleusingen-Landingpage moechte ich die Seite in meiner Muttersprache (Deutsch/Ukrainisch/Russisch/Englisch) lesen koennen, damit ich Mietkonditionen, Galerie, Lage und Kontaktinformationen verstehe, ohne erst Woerterbuch oder Google Translate zu bemuehen.
Akzeptanzkriterien
Sprach-Umfang
Sprach-Detection
haus-lang) persistiert User-Wahl ueber Sessions hinweg?lang=ukueberschreibt beide (fuer Sharing-Links + SEO-Tiefe)UI: Sprach-Switcher
Responsive Design
Inhalt-Update beim Sprachwechsel
<html lang="...">wird dynamisch gesetzt<meta og:locale>wird angepasst (de_DE,uk_UA,ru_RU,en_US)<title>+<meta description>werden uebersetzt?lang=uk(spaetere Optimierung: AJAX moeglich)Translations-Pipeline
app/Locales/{de,uk,ru,en}.phpmit PHP-Arrays (kein JSON-Overhead, einfache Arrays)t("key")Pattern, im View-Layerapp/Components/LocaleSwitcher.php(reusable)Testing
Locale-Klasse (Detection-Logik, Fallback-Verhalten, Edge-Cases)<html lang>korrekt fuer jede SpracheOut of Scope
/en/,/uk/,/ru/als Subpath) -- nur Query-Param?lang=<html lang>+<meta og:locale>)en.haus-schleusingen.de)Erfolgsmetrik
<html lang>,og:locale, sinnvolle<title>-Uebersetzung)Abhaengigkeiten
Aufwand-Schaetzung
XL (Epic, mehrere Sub-Tasks):
Vorschlag: ein gemeinsames Issue (dieses hier) mit Gitea-Checklist +
Closes #Nin separaten Sub-Issue-PRs, OR separates Issue pro Sub-Task. Martins Entscheidung.Labels
type:feature·priority:P1·i18n·responsive·accessibilityArchitektur-Vorschlag
Server-side rendering + Client-side Toggle (Hybrid):
Server (PHP Front-Controller):
$_GET["lang"],localStorage(via Cookie-Synonymhaus-lang),Accept-LanguageHeader$locale = "de" | "uk" | "ru" | "en"(mit Whitelist + Fallback)app/Locales/{de,uk,ru,en}.phpals PHP-Array<html lang="...">,<title>,<meta description>,<meta og:locale>in LayoutClient (JS):
localStorage.haus-langbei Page-LoadlocalStorage.setItem("haus-lang", "uk")+window.location = "?lang=uk"/api/locale/{lang}fuer SPA-like-Switch (spaetere Optimierung, vorerst Page-Reload)Translation-Files (
app/Locales/de.php):View-Helper:
View-Usage:
Volle Architektur-Begruendung in ADR-002 (siehe
docs/adr/002-multilanguage-architecture.md, nach Martin-Approval).Links
app/views/layouts/main.php(Layout-Datei, muss<html lang>dynamisch werden)app/views/home/index.php(Home-View, 500+ Zeilen Content, muss translatet werden)Neue Konvention (gilt ab sofort fuer alle Issues)
ALLE neuen Features muessen Translation-Key-basiert implementiert werden. Die
t("key")-Helper-Funktion ist der Standard fuer jeden neuen User-String. Translation-Files inapp/Locales/muessen mit-aktualisiert werden. Code-Review schliesst fehlende Translation-Keys explizit ein.Diese Konvention wird in
app/AGENTS.mdund in der Skillgitea-dev-orchestrator(DoR-Checkliste) verankert.Sub-Issues (A-F)
Alle Sub-Issues im Milestone Multi-Language MVP (#1):
Reihenfolge der Umsetzung: A -> B -> C -> (D parallel E) -> F
Status pro Sub-Issue:
⚠️ Geschlossen ohne Merge
Grund: Beim Code-Review auf https://haus.test.kies-media.de wurden Layout-Probleme in der Headernavigation entdeckt, die mit dem bestehenden inline-HTML-Pattern in
app/views/home/index.phpkollidieren.Was passiert ist:
<body>-Content inline (inkl.<nav>,<section class="hero">, etc.)main.php-Layout hat das Layout zerschossen, weil der bestehende Header inhome/index.phphardcoded ist und nicht aus dem Layout-Template kommthome/index.phpmuss erst so refactored werden, dass es nur den Hauptcontent rendert, nicht den ganzen<body>Was Martin jetzt hat:
feature/multilanguage-mvpbehalten — der Code ist solide, nur das HTML-Pattern passt nichtNächste Schritte (separates Issue nötig):
app/views/home/index.php: Body-Content aus dem HTML-File rausziehen, damit dasmain.php-Layout (mit<head>, Navigation, Footer) greifen kannapp/views/impressum/index.phpunddatenschutz/index.php: gleiche Logikmain.phpeinbauen — wird dann sauber auf allen 3 Seiten gerendertBranch und PR bleiben erhalten, der Code geht nicht verloren.