Eine Website mehrsprachig zu machen bedeutet, zwei getrennte Hälften zu übersetzen: die Oberfläche, die die Website selbst darstellt, und den Inhalt, der in Ihrem CMS gespeichert ist. Die meisten Tools decken die eine ab und berechnen die andere separat, weshalb Lokalisierung so oft als kostenpflichtiges Add-on oder als manuelle Duplizierungsarbeit endet. Hier erfahren Sie, was jede Hälfte tatsächlich erfordert, was Sie bewusst in einer Sprache belassen sollten, und wie Sie den halbfertigen Zustand vermeiden, der eine übersetzte Website kaputt wirken lässt.
Warum ist Mehrsprachigkeit meist ein Add-on?
Weil die beiden Hälften wirklich unterschiedliche Probleme sind. Die Oberfläche zu übersetzen bedeutet Routing, einen Sprachumschalter und eine Kopie jedes Labels, Buttons und jeder Fehlermeldung. Den Inhalt zu übersetzen bedeutet, dass jede Zeile in jeder Collection eine Version pro Sprache benötigt, was die Struktur Ihrer Datenbank verändert und nicht nur ihre Werte. Tools, die um ein Page-Builder-Dokument herum gebaut sind, lösen tendenziell das erste Problem und flicken das zweite später an, meist als Plugin mit eigenem Abonnement.
Was die Website-Hälfte braucht
Drei Dinge, und alle drei müssen zueinander passen.
- Eigene Routen. Jede Sprache braucht echte, separate URLs, damit eine Seite auf Französisch eigenständig verlinkt, geteilt und indexiert werden kann. Eine Sprache, die nur als clientseitiger Umschalter existiert, ist für Suchmaschinen unsichtbar.
- Übersetzte Oberflächentexte. Navigation, Buttons, Formularfelder, Validierungsmeldungen, Leerzustände. Das wird am häufigsten unterschätzt, weil es über die ganze Website verstreut ist statt in einer einzigen Inhaltsdatei zu stecken.
- Ein Umschalter, der die Navigation übersteht. Ein Sprachwechsel sollte Sie auf der Seite halten, die Sie gerade gelesen haben, statt Sie zur Startseite zu schicken.
Was die Inhalts-Hälfte braucht
Jedes übersetzbare Feld braucht einen Wert pro Sprache, und der Editor muss das als ein Feld mit Sprach-Tabs anzeigen statt als einen Haufen duplizierter Spalten. Der Unterschied klingt kosmetisch, ist es aber nicht: Eine Collection mit acht übersetzbaren Feldern über vier Sprachen sind zweiunddreißig rohe Spalten, die niemand zuverlässig bearbeiten kann.
Sie braucht außerdem einen Fallback. Fehlt eine Übersetzung, sollte die Website unauffällig die Standardsprache anzeigen, statt eine leere Überschrift zu rendern. Genau dieses Verhalten erlaubt es, schrittweise zu übersetzen, statt einen Launch zurückzuhalten, bis jede Zeile fertig ist.
Was sollten Sie nicht übersetzen?
Mehr, als man erwartet, und es falsch zu machen, erzeugt dauerhaft Mehrarbeit. Lassen Sie Folgendes in einer Sprache:
- Eigennamen. Der Name einer Person, Ihr Firmenname, ein Produktname, eine Stadt. Diese werden überall gleich geschrieben, und ein Feld pro Sprache dafür führt irgendwann dazu, dass jemand eine leicht abweichende Schreibweise in eines davon einträgt.
- Preise, Daten und Kennungen. Formatieren Sie sie zur Anzeigezeit passend zur Locale, statt eine separate Kopie zu speichern.
- Bilder und Dateien. Sofern das Bild selbst keinen Text enthält, bedient eine einzige Datei alle Sprachen.
Der Test ist, ob sich der Wortlaut zwischen den Sprachen tatsächlich unterscheidet. Überschriften, Beschreibungen und Fließtext tun das. Ein Nachname nicht.
Sind regionale Varianten unterschiedliche Sprachen?
Ja, behandeln Sie sie als unterschiedlich. Britisches und amerikanisches Englisch sind getrennte Zielgruppen mit unterschiedlicher Rechtschreibung, Redewendungen und oft unterschiedlicher Preisgestaltung, weshalb jede ihre eigene Übersetzung verdient, statt von der anderen zu erben. Jeder Standard-Sprachcode sollte funktionieren, einschließlich regionaler wie pt-BR oder en-GB, und ein Tool, das nur eine feste Dropdown-Liste großer Sprachen anbietet, wird Sie irgendwann ausbremsen.
Wie handhabt Modulify das?
Als eine einzige Anfrage statt zwei Projekte. Eine Sprache anzufordern richtet Routing, Oberflächentexte, die CMS-Felder pro Sprache und die Übersetzung bestehender Zeilen gemeinsam ein, sodass Sie nicht mit einer Website enden, die die Sprache wechselt, darunter aber englischen Inhalt zeigt. Nicht übersetzte Werte greifen automatisch auf die Standardsprache zurück, Sprachen können entfernt werden, und die Standardsprache kann später geändert werden, ohne den Text einer der beiden Sprachen zu verlieren. Es gibt keine Obergrenze für die Anzahl der Sprachen eines Projekts und keine separate Gebühr für Lokalisierung.
Was ist mit SEO?
Echte Routen pro Sprache sind der größte Teil der Antwort, weil dann jede Version unabhängig gecrawlt, indexiert und verlinkt werden kann. Behalten Sie darüber hinaus die gleiche Seitenstruktur über alle Sprachen hinweg bei, damit eine übersetzte Seite aus eigener Kraft rankt statt wie eine dünne Kopie zu wirken, und widerstehen Sie der Versuchung, alles auf einmal maschinell zu übersetzen. Hundert schlecht übersetzte Seiten performen schlechter als zehn gute, und sie sind später viel schwerer zu reparieren.
Was Sie vor der Entscheidung prüfen sollten
Vier Fragen, die sich lohnen, unabhängig davon, welches Tool Sie bewerten:
- Bekommt jede Sprache ihre eigene URL, oder ist es ein clientseitiger Umschalter?
- Zeigt das CMS ein Feld mit Sprach-Tabs, oder ein Feld pro Sprache?
- Was passiert, wenn eine Übersetzung fehlt: Fallback oder leer?
- Ist Lokalisierung enthalten, oder ist es ein separater Plan oder ein Plugin?
Diese vier Antworten sagen mehr aus als jede Feature-Liste. Für den größeren Zusammenhang, wie eine Website auf diese Weise gebaut wird, beginnen Sie mit dem vollständigen Prompt-zu-Website-Leitfaden, und lesen Sie warum ein relationales CMS wichtig ist für die strukturelle Hälfte derselben Geschichte.
