Einfache Internationalisierung: Sprachverwaltung, die funktioniert

Zusammenfassung

Ich habe mein Multilanguage-Setup vereinfacht – für zwei Realitäten: Leser in Deutschland und alle anderen. Die erste Version war überentwickelt. Jetzt gibt es klare locale paths, eine einmalige Erkennung, einen Language Switcher, der den Kontext beibehält, und eine saubere Trennung zwischen UI-Strings und langen Inhalten. Vorhersehbar für Menschen. Verständlich für Suchmaschinen.

Kontext

Eine wachsende Leserschaft in Deutschland, gleichzeitig viele englischsprachige Besucher. Die Website sollte sich in Deutschland lokal anfühlen – aber englische Leser nie ausschließen. Search Engines sollten klare Sprachversionen sehen, keine Duplikate.

Probleme

Problem A — Sprache und Ort

Unterstütze mindestens DE und EN. „Place“ praktisch umsetzen: Standard = DE in Deutschland, Englisch nah dran, und keine Überraschungen für den User.

Problem B — Overengineered First Build

Die erste Lösung funktionierte, war aber zu clever: versteckte Fallbacks, zu viele Flags, Logik, die ich selbst nachlesen musste. Komplexität schlich sich in UX, SEO und Redaktion ein.

Rahmenbedingungen und Ziele

• Klare URLs für Vertrauen und bilingual SEO
• Eine höfliche Entscheidung beim ersten Besuch – danach merken
• Language Switch muss den aktuellen Page Context behalten
• Übersetzungen veröffentlichen ohne Deploy
• Architektur so klein, dass sie in einer Minute erklärbar ist

Vorgehen

Ich habe mich an die Grundlagen aus Clean Code (Robert C. Martin) gehalten:

• „Functions should do one thing.“
• „Meaningful names.“
• „Leave the code better than you found it.“

Keine Neuentwicklung – Subtraktion. Versteckte Regeln entfernt, Entscheidungen benannt, Verhalten dokumentiert.

Lösung im Überblick

• Locale paths: Jede Seite existiert unter /de/... und /en/....
• One-time detector: saved preference → browser Accept-Language → default = DE. Einmal entscheiden, dann Ruhe.
• Context-preserving Language Switcher: Sprachwechsel ohne Sprung zur Startseite. Preference bleibt gespeichert.
• Two layers of translation: UI-Strings in kleinen JSON-Files; Articles und Long Content im CMS, DE/EN-gekoppelt.
• Search alignment: hreflang zwischen Versionen, Sitemap listet beide locales.

So funktioniert es (User Flow)

Aufruf / → Wenn Language Cookie vorhanden, verwende ihn → sonst Accept-Language auswerten und erste unterstützte Sprache wählen → sonst Default = DE → User kann jederzeit wechseln → Choice wird gespeichert.

Implementation Notes (non-technical)

• Die URL zeigt immer die aktuelle Sprache.
• Detection ist einmalig und höflich.
• Der Switcher mappt gleiche Pages zwischen EN und DE.
• Redakteure übersetzen und veröffentlichen im CMS; UI bleibt versioniert im JSON.
• Search Engines sehen zwei saubere Versionen mit hreflang.

Wirkung

• Keine Überraschungen für Nutzer.
• Schnellere Redaktion, keine Deploys für Übersetzungen.
• Saubere Indexierung mit klaren Alternates.
• Ein System, das leicht erweiterbar bleibt.

Challenges & Fixes

• Helpful fallbacks that weren’t. Silent Rules entfernt; ein Detector, eine gespeicherte Preference.
• Context loss on switch. /de/x ↔ /en/x sichergestellt.
• SEO uncertainty. Locale im Path, hreflang Links, zweisprachige Sitemap.
• Editorial mismatch. Posts im CMS verlinkt, damit der Switcher mid-article richtig funktioniert.

Skalierbarkeit (neue Languages)

Wenn Spanish (es) und Italian (it) hinzukommen:

• Locale Codes ergänzen, Default bestätigen.
• UI-Files mit bestehenden Keys anlegen, Values übersetzen.
• Switcher-Options erweitern; Preference-Logic beibehalten.
• CMS-Schema anpassen, Posts verknüpfen.
• Routes und Sitemap aktualisieren, hreflang pflegen.
• Redirects, Detection und Indexierung testen.
• Supported Languages dokumentieren.

Kleine, bekannte Schritte. Repeatable.

Next Improvements

• Preserve ?query und #anchor beim Language Switch. Wichtig für Analytics und Deep Links.
• Redirect Types definieren. Permanente Routen als 301 kennzeichnen.

Lessons

Komplexität kommt oft als „helpful“ daher. Die Lösung ist Disziplin: sichtbare URLs, eine einmalige Detection, ein verlässlicher Switcher, und eine saubere Trennung von UI-Strings und Content. Wenn man das Verhalten in einer Minute erklären kann, ist es fertig.

References

• Robert C. Martin: Clean Code: A Handbook of Agile Software Craftsmanship (2008) ISBN 978-0132350884 – Amazon Deutschland
• MDN Web Docs — Accept-Language
• Google Search Central — hreflang für mehrsprachige Websites