Eine Website, zwei Sprachen, keine Übersetzungstabelle

Ein Maklerbüro, das Wohnungen an Zugezogene vermittelt, braucht seine Website auf Englisch. Ein Büro an der Grenze braucht sie auf Französisch. Und weil unsere Maklersoftware für einen internationalen Markt gebaut wird, war die Frage nie, ob die Maklerwebsite mehrere Sprachen spricht, sondern wie. Seit dieser Woche steht die Antwort: Eine Site kann beliebig viele Sprachen veröffentlichen, die Standardsprache wohnt an der Wurzel, jede weitere unter ihrem Kürzel — /en, /fr, /de-ch.

Die naheliegende Bauweise wäre eine Übersetzungstabelle gewesen: jede Seite einmal, dazu je Feld ein Text pro Sprache. So machen es die meisten Systeme, und so hätten wir es auch tun können. Wir haben es nicht getan, und der Grund ist ein Blick auf echte Maklerwebsites: Die englische Seite ist selten eine Übersetzung der deutschen. Sie ist kürzer, sie erklärt anderes, sie hat andere Menüpunkte — „Relocation" statt „Finanzierung", ein Blog, der nur die Hälfte der Beiträge kennt. Eine Übersetzungstabelle zwingt beide Sprachen in denselben Grundriss. Das wollten wir nicht.

Jede Sprache eine eigene Hälfte

Bei uns ist jede Sprache eine eigene Hälfte der Site. Seiten, Menüs, Blogbeiträge, Kategorien und Tags gehören einer Sprache; im Site-Dokument des Windows-Clients wählt man oben die Sprache und sieht darunter nur, was zu ihr gehört. Neue Seiten entstehen in der gewählten Sprache. Wer die englische Hälfte anders schneidet als die deutsche, darf das — nichts zwingt zur 1:1-Übersetzung.

Was die beiden Hälften verbindet, ist eine lose Bekanntschaft: Eine Seite, ein Menüpunkt oder ein Beitrag kann ein Gegenstück in einer anderen Sprache kennen. Kennt er eines, springt der Sprachumschalter dorthin, und die Sitemap meldet den Suchmaschinen beide Adressen als Alternativen. Kennt er keines, springt der Umschalter auf die Startseite der Zielsprache. Trägt man das Gegenstück auf einer Seite ein, ergänzt der Server den Rückverweis auf der anderen — ohne Zwang, nur damit es symmetrisch bleibt.

Zwei Entscheidungen haben wir bewusst gegen die Bequemlichkeit getroffen. Erstens: kein stiller Rückfall. Was es in einer Sprache nicht gibt, gibt es dort nicht — kein Menüpunkt, kein Treffer in Listen, eine 404 auf der Adresse. Eine englische Website, die stellenweise deutsch antwortet, wirkt kaputt; eine, die ehrlich sagt „diese Seite gibt es hier nicht", wirkt gepflegt. Zweitens: Die Wurzel leitet niemanden um. Wer ses-realestate.com aufruft, bekommt die Standardsprache, egal was sein Browser bevorzugt. Der Wechsel geschieht über den Umschalter, ein Modul wie jedes andere, das man in jede Position der Vorlage setzen kann — Kürzel oder Sprachnamen, waagerecht oder senkrecht.

Und weil eine zweite Sprache nicht an einem Tag fertig ist, gibt es die Wartung je Sprache: Die englische Hälfte lässt sich schließen, während die deutsche weiterläuft. Besucher sehen die Sprache dann weder im Umschalter noch in der Sitemap, Administratoren sehen sie und können bauen.

Was alte Daten und Backups davon merken

Die erste Frage bei jedem Umbau am Datenmodell lautet bei uns: Was passiert mit einer Site, die es schon gibt? Die Antwort musste sein: nichts. Beim Serverstart bekommt jede Site ohne Standardsprache eine, und alle Seiten, Menüs und Beiträge ohne Sprache werden auf sie gestempelt. Die Website läuft unter ihren alten Adressen weiter, als wäre nichts gewesen — das haben wir am eigenen Bestand geprüft.

Dasselbe gilt für die Datensicherung. Die Website im Koffer aus einem früheren Bericht — der Export einer ganzen Site in eine Datei — hat eine neue Formatversion, die Sprachen und Gegenstücke mitnimmt. Ein altes Paket bleibt trotzdem lesbar: Der Import erkennt das alte Format und stempelt beim Einspielen alles auf die Standardsprache. Ein Backup von letzter Woche in eine frische Datenbank importiert, ergibt fachlich dieselbe Site wie vor dem Umbau. Das ist der Test, den wir bei jeder Schemaänderung fahren, und er ist der Grund, warum wir ihn ohne Bauchschmerzen machen.

Die Immobiliensuche spricht mit

Die Seiten waren übersetzt, die Menüs auch — und dann stand auf /en zwischen englischen Texten „Haus zur Miete", „Kaltmiete", „Wohnfläche". Die Immobiliensuche und das Exposé bauen ihre Beschriftungen aus den Objektdaten, und die kommen aus OpenImmo: Objektarten, Vermarktungsarten, Ausstattung, Zustand, Energie, Entfernungen. All das stand als deutsche Tabelle im Code.

Jetzt liegen diese Begriffe in einer String-Tabelle je Sprache: 672 Einträge, Englisch als Grundtabelle, Deutsch daneben. Die Schlüssel sind die OpenImmo-Codes selbst — wer im Code Condition.LikeNew liest, findet in der Tabelle Like new und neuwertig. Ein paar Begriffe haben uns Diskussionen gekostet: Kaltmiete ist base rent, Warmmiete rent incl. heating, Hausgeld condominium fee, WBS housing permit. Zahlen und Beträge folgen der Kultur der Anfrage, also 1,250.00 € auf der englischen und 1.250,00 € auf der deutschen Seite. Filter-Chips, Ein-Klick-Filter, Kartenbeschriftungen und die Meldung „Immobilie nicht mehr verfügbar" sind mitgezogen. Was noch deutsch ist: die Ländernamen. Die sind ein Datenkatalog und bekommen ihre Sprache in einem eigenen Schritt.

Ein Grid für die Module

Mit zwei Sprachen wurde ein Bereich unübersichtlich, der vorher gerade noch ging: die Module. Bisher war das eine Textliste — eine Zeile je Modul, Name und Position, die Befehle als Knöpfe darunter. Sprache, Sichtbarkeit und Typ waren nicht ablesbar, und wer die englische Hälfte aufbaute, legte jedes Modul von Hand neu an.

Der Bereich ist jetzt eine Tabelle wie die Seiten und die Sprachen auch: Symbol, Name, Typ, Position, Sprache, Sichtbarkeit, veröffentlicht. Die Sprachwahl oben filtert sie; Module ohne Sprache — Logo, Fußzeile, der Umschalter selbst — gelten für alle und bleiben stehen. Im Kontextmenü gibt es neben Neu, Öffnen, Verschieben und Löschen ein Kopieren: Die Kopie kommt unveröffentlicht ans Ende ihrer Position, mit allen Einstellungen und Menübindungen, und wartet darauf, dass man ihr die andere Sprache gibt. Die englische Hälfte einer Site baut sich damit in Minuten statt in einer Stunde.

Was der Livetest noch fand

Der Umbau war kaum fertig, da meldete die Testseite die Kleinigkeiten, die kein Plan vorhersieht. Die Anmeldeseite antwortete nur ohne Präfix — unter /en/login gab es sie nicht; jetzt antworten Anmeldung, Registrierung, Profil und Suche unter jeder Sprachwurzel. Der Startseiten-Eintrag von /en fing alle Pfade darunter ab, sodass jede englische Seite die Startseite zeigte; er passt jetzt nur noch exakt. Die Brotkrumen hingen unter der deutschen Wurzel, das Logo verlinkte dorthin; beide folgen jetzt der Sprache der gezeigten Seite. Vier Fixes, keiner größer als zwanzig Zeilen, und keiner wäre ohne die zweite Sprache je aufgefallen.

Die Bilanz in Zahlen

• 1 neuer Datentyp: die Sprache einer Site, mit eigener Wartung und eigener Meta-Beschreibung
• 1 neues Modul: der Sprachumschalter, frei positionierbar
• 672 Fachbegriffe der Immobiliensuche in zwei Sprachen, geschlüsselt nach OpenImmo
• 1 Backup-Formatversion mehr — und das alte Format wird weiterhin gelesen
• 10 Schritte vom ersten Modell bis zum letzten Livetest-Fix, alle Tests grün

Was Anwender davon sehen: die Sprachwahl im Kopf des Site-Dokuments, den Bereich Sprachen mit Wartungsschalter, das Feld Gegenstück an Seite, Menüpunkt und Beitrag, den Umschalter auf der Website — und eine Immobiliensuche, die unter /en englisch bleibt, bis zum letzten Filter-Chip. Was als Nächstes kommt: die Ländernamen, und dann der Blick auf das, was eine dritte Sprache anders macht als die zweite. Vermutlich nichts. Das wäre das beste Ergebnis.