greggy/landingpage-haus-schleusingen
1
0
Fork 0
Code Issues 1 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Multi-Language: UK/RU/EN (DE bleibt fuer Rechtliches) #71

New Issue
Closed
opened 2026-06-04 10:15:48 +02:00 by greggy · 1 comment
greggy commented 2026-06-04 10:15:48 +02:00
Owner
Copy Link

Kontext

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)
  • Englisch: internationaler Standard, expat-Potenzial
  • Deutsch: bleibt Default (rechtliche Pflicht fuer Impressum/Datenschutz nach Paragraph 5 TMG)

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
  • Client-side localStorage (haus-lang) persistiert User-Wahl ueber Sessions hinweg
  • URL-Query-Param ?lang=uk ueberschreibt beide (fuer Sharing-Links + SEO-Tiefe)
  • Prioritaet: URL-Param > localStorage > Accept-Language > Default (DE)

UI: Sprach-Switcher

  • Kleine Flaggen im Header (Desktop: rechts neben Logo/Nav; Mobile: im Hamburger-Menu oben)
  • Aktive Sprache visuell markiert (z.B. erhoehter Border, Opacity, oder Checkmark)
  • 4 Flaggen verfuegbar: DE (Dreieck), UK (Blau-Gelb), RU (Weiss-Blau-Rot), EN (Union Jack)
  • SVG inline (kein Extra-Network-Request, skalierbar)
  • Touch-Target mind. 44x44px (Mobile-UX-Standard)

Responsive Design

  • Desktop (>=1024px): Flags als kleine Leiste im Header, ~24x16px pro Flag
  • Tablet (768-1023px): Flags kleiner dargestellt, max 20x14px
  • Mobile (<768px): Flags im Hamburger-Menu, voller Touch-Target
  • Bei Sprachwechsel KEIN Layout-Shift (CSS-Variablen fuer Flag-Container-Groesse)

Inhalt-Update beim Sprachwechsel

  • Kein FOUC (Flash of Untranslated Content) -- Server-Render liefert direkt korrekte Sprache
  • <html lang="..."> wird dynamisch gesetzt
  • <meta og:locale> wird angepasst (de_DE, uk_UA, ru_RU, en_US)
  • <title> + <meta description> werden uebersetzt
  • Navigation, Hero, Galerie-Labels, Stockwerk-Namen, Preise, Lage-Beschreibungen, Kontakt-Form-Labels, Footer
  • Bei JS-Flag-Click: Page-Reload mit ?lang=uk (spaetere Optimierung: AJAX moeglich)

Translations-Pipeline

  • Translation-Files: app/Locales/{de,uk,ru,en}.php mit PHP-Arrays (kein JSON-Overhead, einfache Arrays)
  • Helper-Funktion: t("key") Pattern, im View-Layer
  • Initial-Uebersetzung: Maschinell (DeepL/Google) fuer UK + RU, Martin + Olha reviewen
  • Locale-Switcher-Komponente: app/Components/LocaleSwitcher.php (reusable)

Testing

  • PHPUnit-Tests fuer Locale-Klasse (Detection-Logik, Fallback-Verhalten, Edge-Cases)
  • Browser-Smoke-Tests (Playwright) fuer alle 4 Sprachen
  • Acceptance: User kann in 1 Klick zwischen 4 Sprachen wechseln
  • Acceptance: Kein FOUC auf erstem Render
  • Acceptance: Mobile-Touch funktioniert (44x44px Target)
  • Acceptance: <html lang> korrekt fuer jede Sprache

Out of Scope

  • Mehrsprachige SEO-URLs (/en/, /uk/, /ru/ als Subpath) -- nur Query-Param ?lang=
  • Maschinelle Uebersetzung der Bilder (z.B. Floorplan-Beschriftungen)
  • Auto-Translation bei neuen Inhalten -- manuell pro Feature/Issue
  • Mehrsprachige E-Mail-Templates (Kontakt-Form-Mail geht auf Deutsch raus -- Martin klaert mit Tenant)
  • hreflang-Tags (vorerst nur <html lang> + <meta og:locale>)
  • Eigene Subdomains (z.B. en.haus-schleusingen.de)

Erfolgsmetrik

  • UX: User kann in max. 1 Klick zwischen 4 Sprachen wechseln
  • Performance: First-Paint in korrekter Sprache, kein FOUC
  • Lighthouse-i18n-Score > 90 (korrekte <html lang>, og:locale, sinnvolle <title>-Uebersetzung)
  • Mobile-UX: Flags haben Touch-Target mind. 44x44px
  • Vollstaendigkeit: 0 fehlende Translation-Keys in Production (Build-Check: alle Keys in 4 Locales vorhanden)

Abhaengigkeiten

  • Olha (Ukrainian + Russian native speaker): Review der maschinellen Uebersetzungen
  • Keine externen Libraries -- PHP-nativ
  • DeepL API (optional): fuer initiale UK + RU Uebersetzungen, kann manuell gemacht werden

Aufwand-Schaetzung

XL (Epic, mehrere Sub-Tasks):

  • Issue A: PHP i18n-Infrastruktur (Locale-Klasse, View-Helper, t()-Funktion)
  • Issue B: Server-side Accept-Language Detection + Front-Controller Update
  • Issue C: Locale-Switcher-Component (HTML/CSS/JS)
  • Issue D: Translation-Files DE->UK/RU/EN (Content-Migration)
  • Issue E: Responsive Design fuer Flag-Leiste
  • Issue F: PHPUnit-Tests + Playwright-Smoke

Vorschlag: ein gemeinsames Issue (dieses hier) mit Gitea-Checklist + Closes #N in separaten Sub-Issue-PRs, OR separates Issue pro Sub-Task. Martins Entscheidung.

Labels

type:feature · priority:P1 · i18n · responsive · accessibility

Architektur-Vorschlag

Server-side rendering + Client-side Toggle (Hybrid):

  1. Server (PHP Front-Controller):

    • Liest $_GET["lang"], localStorage (via Cookie-Synonym haus-lang), Accept-Language Header
    • Setzt $locale = "de" | "uk" | "ru" | "en" (mit Whitelist + Fallback)
    • Laedt app/Locales/{de,uk,ru,en}.php als PHP-Array
    • Setzt <html lang="...">, <title>, <meta description>, <meta og:locale> in Layout
    • Ergebnis: kein FOUC, SEO-stark

  2. Client (JS):

    • Liest localStorage.haus-lang bei Page-Load
    • Bei Klick auf Flagge: localStorage.setItem("haus-lang", "uk") + window.location = "?lang=uk"
    • Optional: AJAX-Endpoint /api/locale/{lang} fuer SPA-like-Switch (spaetere Optimierung, vorerst Page-Reload)

  3. Translation-Files (app/Locales/de.php):

    <?php
return [
  "nav.gallery" => "Galerie",
  "nav.floorplan" => "Grundriss",
  "nav.rent" => "Miete",
  "nav.location" => "Lage",
  "hero.tag" => "Zur Langzeitmiete . Ab sofort verfuegbar",
  "hero.title" => "Grosszuegiges Einfamilienhaus in Schleusingen",
  "hero.meta.size" => "227 m^2 Wohnflaeche",
];

  4. View-Helper:

    function t(string $key, ?string $locale = null): string {
    static $cache = [];
    $locale = $locale ?? $GLOBALS["currentLocale"] ?? "de";
    if (!isset($cache[$locale])) {
        $cache[$locale] = require __DIR__ . "/../Locales/{$locale}.php";
    }
    return $cache[$locale][$key] ?? $key;
}

  5. View-Usage:

    <h1><?= t("hero.title") ?></h1>
<div class="hero-tag"><?= t("hero.tag") ?></div>

Volle Architektur-Begruendung in ADR-002 (siehe docs/adr/002-multilanguage-architecture.md, nach Martin-Approval).

Links

  • AGENTS.md (Projekt-Richtlinien, jQuery als global, Lint-Pipeline)
  • ADR-001 (PHPUnit-Integration -- Pattern-Vorlage fuer ADR-Format)
  • 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):

  • #72 (Schritt A)
  • #73 (Schritt B)
  • #74 (Schritt C)
  • #75 (Schritt D)
  • #76 (Schritt E)
  • #77 (Schritt F)

Reihenfolge der Umsetzung: A -> B -> C -> (D parallel E) -> F

Status pro Sub-Issue:

Sub Status Blockiert von
A - i18n-Infrastruktur angelegt -
B - Locale-Switcher angelegt A
C - Uebersetzungsdateien angelegt A
D - Flaggen-UI angelegt B
E - Accessibility angelegt B, D
F - Tests angelegt A, B, C, D, E
## Kontext 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) - **Englisch**: internationaler Standard, expat-Potenzial - **Deutsch**: bleibt Default (rechtliche Pflicht fuer Impressum/Datenschutz nach Paragraph 5 TMG) 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 - [ ] **Client-side** localStorage (`haus-lang`) persistiert User-Wahl ueber Sessions hinweg - [ ] URL-Query-Param `?lang=uk` ueberschreibt beide (fuer Sharing-Links + SEO-Tiefe) - [ ] Prioritaet: URL-Param > localStorage > Accept-Language > Default (DE) ### UI: Sprach-Switcher - [ ] **Kleine Flaggen** im Header (Desktop: rechts neben Logo/Nav; Mobile: im Hamburger-Menu oben) - [ ] Aktive Sprache visuell markiert (z.B. erhoehter Border, Opacity, oder Checkmark) - [ ] 4 Flaggen verfuegbar: DE (Dreieck), UK (Blau-Gelb), RU (Weiss-Blau-Rot), EN (Union Jack) - [ ] **SVG inline** (kein Extra-Network-Request, skalierbar) - [ ] Touch-Target mind. 44x44px (Mobile-UX-Standard) ### Responsive Design - [ ] **Desktop (>=1024px)**: Flags als kleine Leiste im Header, ~24x16px pro Flag - [ ] **Tablet (768-1023px)**: Flags kleiner dargestellt, max 20x14px - [ ] **Mobile (<768px)**: Flags im Hamburger-Menu, voller Touch-Target - [ ] Bei Sprachwechsel KEIN Layout-Shift (CSS-Variablen fuer Flag-Container-Groesse) ### Inhalt-Update beim Sprachwechsel - [ ] **Kein FOUC** (Flash of Untranslated Content) -- Server-Render liefert direkt korrekte Sprache - [ ] `<html lang="...">` wird dynamisch gesetzt - [ ] `<meta og:locale>` wird angepasst (`de_DE`, `uk_UA`, `ru_RU`, `en_US`) - [ ] `<title>` + `<meta description>` werden uebersetzt - [ ] Navigation, Hero, Galerie-Labels, Stockwerk-Namen, Preise, Lage-Beschreibungen, Kontakt-Form-Labels, Footer - [ ] Bei JS-Flag-Click: Page-Reload mit `?lang=uk` (spaetere Optimierung: AJAX moeglich) ### Translations-Pipeline - [ ] **Translation-Files**: `app/Locales/{de,uk,ru,en}.php` mit PHP-Arrays (kein JSON-Overhead, einfache Arrays) - [ ] **Helper-Funktion**: `t("key")` Pattern, im View-Layer - [ ] **Initial-Uebersetzung**: Maschinell (DeepL/Google) fuer UK + RU, Martin + Olha reviewen - [ ] **Locale-Switcher-Komponente**: `app/Components/LocaleSwitcher.php` (reusable) ### Testing - [ ] PHPUnit-Tests fuer `Locale`-Klasse (Detection-Logik, Fallback-Verhalten, Edge-Cases) - [ ] Browser-Smoke-Tests (Playwright) fuer alle 4 Sprachen - [ ] Acceptance: User kann in 1 Klick zwischen 4 Sprachen wechseln - [ ] Acceptance: Kein FOUC auf erstem Render - [ ] Acceptance: Mobile-Touch funktioniert (44x44px Target) - [ ] Acceptance: `<html lang>` korrekt fuer jede Sprache ## Out of Scope - **Mehrsprachige SEO-URLs** (`/en/`, `/uk/`, `/ru/` als Subpath) -- nur Query-Param `?lang=` - **Maschinelle Uebersetzung der Bilder** (z.B. Floorplan-Beschriftungen) - **Auto-Translation bei neuen Inhalten** -- manuell pro Feature/Issue - **Mehrsprachige E-Mail-Templates** (Kontakt-Form-Mail geht auf Deutsch raus -- Martin klaert mit Tenant) - **hreflang-Tags** (vorerst nur `<html lang>` + `<meta og:locale>`) - **Eigene Subdomains** (z.B. `en.haus-schleusingen.de`) ## Erfolgsmetrik - [ ] **UX**: User kann in max. 1 Klick zwischen 4 Sprachen wechseln - [ ] **Performance**: First-Paint in korrekter Sprache, kein FOUC - [ ] **Lighthouse-i18n-Score > 90** (korrekte `<html lang>`, `og:locale`, sinnvolle `<title>`-Uebersetzung) - [ ] **Mobile-UX**: Flags haben Touch-Target mind. 44x44px - [ ] **Vollstaendigkeit**: 0 fehlende Translation-Keys in Production (Build-Check: alle Keys in 4 Locales vorhanden) ## Abhaengigkeiten - **Olha** (Ukrainian + Russian native speaker): Review der maschinellen Uebersetzungen - **Keine externen Libraries** -- PHP-nativ - **DeepL API** (optional): fuer initiale UK + RU Uebersetzungen, kann manuell gemacht werden ## Aufwand-Schaetzung **XL** (Epic, mehrere Sub-Tasks): - Issue A: PHP i18n-Infrastruktur (Locale-Klasse, View-Helper, t()-Funktion) - Issue B: Server-side Accept-Language Detection + Front-Controller Update - Issue C: Locale-Switcher-Component (HTML/CSS/JS) - Issue D: Translation-Files DE->UK/RU/EN (Content-Migration) - Issue E: Responsive Design fuer Flag-Leiste - Issue F: PHPUnit-Tests + Playwright-Smoke Vorschlag: **ein gemeinsames Issue** (dieses hier) mit Gitea-Checklist + `Closes #N` in separaten Sub-Issue-PRs, OR **separates Issue pro Sub-Task**. Martins Entscheidung. ## Labels `type:feature` · `priority:P1` · `i18n` · `responsive` · `accessibility` ## Architektur-Vorschlag **Server-side rendering + Client-side Toggle** (Hybrid): 1. **Server (PHP Front-Controller)**: - Liest `$_GET["lang"]`, `localStorage` (via Cookie-Synonym `haus-lang`), `Accept-Language` Header - Setzt `$locale = "de" | "uk" | "ru" | "en"` (mit Whitelist + Fallback) - Laedt `app/Locales/{de,uk,ru,en}.php` als PHP-Array - Setzt `<html lang="...">`, `<title>`, `<meta description>`, `<meta og:locale>` in Layout - **Ergebnis: kein FOUC, SEO-stark** 2. **Client (JS)**: - Liest `localStorage.haus-lang` bei Page-Load - Bei Klick auf Flagge: `localStorage.setItem("haus-lang", "uk")` + `window.location = "?lang=uk"` - Optional: AJAX-Endpoint `/api/locale/{lang}` fuer SPA-like-Switch (spaetere Optimierung, vorerst Page-Reload) 3. **Translation-Files** (`app/Locales/de.php`): ```php <?php return [ "nav.gallery" => "Galerie", "nav.floorplan" => "Grundriss", "nav.rent" => "Miete", "nav.location" => "Lage", "hero.tag" => "Zur Langzeitmiete . Ab sofort verfuegbar", "hero.title" => "Grosszuegiges Einfamilienhaus in Schleusingen", "hero.meta.size" => "227 m^2 Wohnflaeche", ]; ``` 4. **View-Helper**: ```php function t(string $key, ?string $locale = null): string { static $cache = []; $locale = $locale ?? $GLOBALS["currentLocale"] ?? "de"; if (!isset($cache[$locale])) { $cache[$locale] = require __DIR__ . "/../Locales/{$locale}.php"; } return $cache[$locale][$key] ?? $key; } ``` 5. **View-Usage**: ```php <h1><?= t("hero.title") ?></h1> <div class="hero-tag"><?= t("hero.tag") ?></div> ``` **Volle Architektur-Begruendung in ADR-002** (siehe `docs/adr/002-multilanguage-architecture.md`, nach Martin-Approval). ## Links - AGENTS.md (Projekt-Richtlinien, jQuery als global, Lint-Pipeline) - ADR-001 (PHPUnit-Integration -- Pattern-Vorlage fuer ADR-Format) - `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): - **#72** (Schritt A) - **#73** (Schritt B) - **#74** (Schritt C) - **#75** (Schritt D) - **#76** (Schritt E) - **#77** (Schritt F) **Reihenfolge der Umsetzung:** A -> B -> C -> (D parallel E) -> F **Status pro Sub-Issue:** | Sub | Status | Blockiert von | |-----|--------|---------------| | A - i18n-Infrastruktur | angelegt | - | | B - Locale-Switcher | angelegt | A | | C - Uebersetzungsdateien | angelegt | A | | D - Flaggen-UI | angelegt | B | | E - Accessibility | angelegt | B, D | | F - Tests | angelegt | A, B, C, D, E |
greggy added the
ReadyForDev
type/feature
priority/P1
i18n
responsive
accessibility
 labels 2026-06-04 10:15:48 +02:00
greggy commented 2026-06-04 16:44:12 +02:00
Author
Owner
Copy Link

⚠️ 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.

## ⚠️ 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
Accessibility / a11y (44x44px, ARIA, contrast)
i18n
Internationalization / translation
Implementing
InQA
InReview
InValidation
KI
Von KI bearbeitet
KI
KI
KI
priority/P1
High priority (do soon)
ReadyForDev
Bereit zur Implementierung
ReadyForMerge
responsive
Responsive design (mobile/tablet/desktop)
type/feature
Feature request (new user-facing capability)
No Label
accessibility
i18n
priority/P1
ReadyForDev
responsive
type/feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
greggy
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: greggy/landingpage-haus-schleusingen#71
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?