Respondo wurde in Dubai gebaut, und diese Tatsache hat das Produkt stärker geprägt als jede Roadmap-Entscheidung, die wir getroffen haben. Eine einzige Support-Warteschlange hier kann eine Kundin, die auf Arabisch schreibt, eine zweite auf Englisch, eine dritte auf Hindi und eine vierte auf Urdu enthalten – oft innerhalb derselben Stunde. Es gab nie eine Version dieses Produkts, die eine Sprache als Standard und den Rest als Übersetzungen behandelte. Dreißig und mehr Sprachen, darunter solche mit Schreibrichtung von rechts nach links, mussten das Fundament sein und nicht eine Schicht, die wir später hinzufügten.

Diese Vorgabe erwies sich als klärend. Wenn Mehrsprachigkeit nicht optional ist, entpuppen sich viele Abkürzungen, die in einem englisch-zuerst-Produkt vernünftig erscheinen, als Sackgassen. Das ist es, was wir gelernt haben, als wir für diese Realität sowohl bei der KI als auch bei der Oberfläche gebaut haben.

Übersetzen ist nicht Verstehen

Die verlockende Architektur ist eine Pipeline: die eingehende Nachricht nehmen, sie über eine Übersetzungs-API ins Englische laufen lassen, sie mit Ihren englischen Modellen verarbeiten, eine englische Antwort erzeugen, sie zurückübersetzen. Sie ist günstig, sie ist schnell zu bauen, und sie versagt genau in den Situationen, aus denen Kundenservice besteht.

Kundengespräche sind dicht an Kontext, den generische Übersetzung einebnet. Slang, Redewendungen, Höflichkeitsregister und fachspezifische Terminologie werden im Hin und Her allesamt glattgeschliffen. Das klassische Beispiel ist ein einzelnes Wort mit einer Bedeutungsverzweigung: Eine Kundin, die im Einzelhandelskontext nach einer „return" fragt, will wissen, wie sie ein Produkt zurückschickt; dasselbe Wort im Finanzkontext meint die Anlagerendite. Übersetzen-verarbeiten-übersetzen verliert den Faden, denn bis das englische Modell es sieht, ist der entscheidende, entzweiende Kontext bereits verstümmelt.

Respondo verwendet stattdessen sprachspezifische Modelle. Eine Nachricht auf Arabisch wird auf Arabisch verstanden und beantwortet, muttersprachlich, ohne jemals als Zwischenrepräsentation durch das Englische zu gehen. Die Unterscheidungen, auf die es ankommt – Ton, Register, der richtige Sinn eines mehrdeutigen Wortes –, werden in der Sprache erfasst, in der sie tatsächlich leben. Das ist der Unterschied zwischen einer Antwort, die technisch korrekt ist, und einer, die ein Muttersprachler als flüssig erkennt.

Wenn die Oberfläche kippt

Die Sprachen im Modell zu handhaben ist die eine Hälfte des Problems. Die andere Hälfte ist die Oberfläche, und Sprachen von rechts nach links sind der Ort, an dem die meisten Designsysteme im Stillen auseinanderfallen.

Arabisch und Hebräisch zu unterstützen ist keine Sache des Übersetzens von Zeichenketten. Das gesamte Layout kehrt sich um. Text richtet sich rechts aus. Die Leserichtung verläuft von rechts nach links, was bedeutet, dass der visuelle Fluss eines Gesprächs, die Position eines Zurück-Buttons, die Richtung, in die ein Pfeil zeigen soll – all das spiegelt sich. Ein Design, das mit Annahmen von links nach rechts in feste Positionen eingebacken wurde, überträgt sich nicht auf RTL; es zerbricht.

Der subtile Teil ist, dass sich nicht alles spiegelt. Das ist die Falle, in die Teams tappen, wenn sie die CSS-Eigenschaft direction entdecken und denken, die Arbeit sei getan.

  • Layout, Textausrichtung und Leserichtung spiegeln sich. Eine Seitenleiste, die im Englischen links ist, gehört im Arabischen nach rechts.
  • Symbole mit Richtung erben die Spiegelung. Ein „Antworten"-Pfeil oder ein „Weiter"-Chevron muss in die andere Richtung zeigen, denn seine Bedeutung ist richtungsgebunden.
  • Inhalt, der von Natur aus LTR ist, spiegelt sich nicht. Telefonnummern, Markennamen in lateinischer Schrift, Code-Schnipsel und URLs lesen sich unabhängig von der umgebenden Sprache von links nach rechts. Spiegeln Sie sie, und Sie haben Unsinn erzeugt.

Das von Hand richtig hinzubekommen, Komponente für Komponente, über ein ganzes Produkt hinweg, ist genau die Art von Aufgabe, die sich unmöglich konsistent halten lässt, während das Produkt wächst. Also haben wir es nicht von Hand gemacht.

Bedingungsbasiert, nicht positionsbasiert

Die Entscheidung, die RTL tragfähig machte, war, unsere Komponenten nicht mehr über absolute Positionen zu beschreiben, sondern über Beziehungen.

Eine positionsbasierte Komponente sagt „diese Beschriftung sitzt 16 Pixel vom linken Rand entfernt". Diese Anweisung ist in dem Moment falsch, in dem das Layout kippt. Eine bedingungsbasierte Komponente sagt „diese Beschriftung sitzt am Anfang der Zeile, mit 16 Pixeln Abstand, bevor der Inhalt beginnt". Nun löst sich „Anfang" im Englischen automatisch nach links und im Arabischen nach rechts auf, und dieselbe Komponentendefinition rendert in beide Richtungen korrekt, ohne eine einzige Bedingung.

Wir haben uns dafür auf die logischen Eigenschaften des Browsers selbst gestützt – das moderne CSS, das in *start* und *end* denkt statt in *links* und *rechts*, und in *inline* und *block* statt in horizontal und vertikal. Eine so verfasste Komponente weiß nicht und kümmert sich nicht darum, in welche Richtung sie rendert. Die Richtung wird einmal gesetzt, an der Wurzel, und jede Komponente darunter passt sich an.

Der Nutzen verstärkt sich. Die nächste RTL-Sprache hinzuzufügen kostet fast nichts, weil die Layout-Logik von vornherein nie an eine bestimmte Richtung gebunden war. Eine neue Komponente, die auf den gemeinsamen Primitiven aufbaut, ist standardmäßig in beide Richtungen korrekt – ein Entwickler müsste sich schon Mühe geben, sie kaputtzumachen.

Raum, damit der Text atmen kann

Die letzte Lektion ist die am wenigsten glamouröse und die am häufigsten ignorierte: Die Textlänge variiert enorm zwischen den Sprachen, und ein Layout, das nur je Englisch gesehen hat, bricht unter denen, die nicht hineinpassen.

Dieselbe Formulierung kann im Deutschen 30 % länger ausfallen, im Chinesischen in einem völlig anderen Zeichensatz ankommen, wo ein paar Glyphen tragen, wofür das Englische einen ganzen Satz braucht, oder mehr vertikalen Raum für die diakritischen Zeichen benötigen, die über und unter der arabischen Schrift sitzen. Ein Button, der auf das englische Wort „Send" dimensioniert ist, schneidet ab oder läuft über, sobald eine längere Übersetzung darin landet.

Unsere Komponenten gehen von Anfang an davon aus, dass sie nicht wissen, wie lang ihr Text sein wird. Sie wachsen mit ihrem Inhalt, brechen elegant um und verlassen sich nie darauf, dass eine Zeichenkette eine bestimmte Länge hat. Es ist eine kleine Disziplin, die einem später tausend einmalige Layout-Reparaturen erspart – und, wie die Richtungsbehandlung, ist es die Art von Sache, die nahezu kostenlos ist, wenn man sie von Tag eins an einbaut, und enorm teuer nachzurüsten.

Der rote Faden

Jede dieser Entscheidungen reimt sich auf dieselbe Idee: Mehrsprachigkeit kann keine Funktion sein, die man hinzufügt, denn die Annahmen eines einsprachigen Produkts reichen bis in das Modell, das Layout und die einzelne Komponente hinein. Bauen Sie englisch-zuerst, und Sie verbringen den Rest der Produktlebensdauer damit, die Stellen zu flicken, an denen diese Annahmen durchsickern. Bauen Sie von Anfang an für dreißig Sprachen, und die einunddreißigste ist fast geschenkt. Dort ansässig zu sein, wo unsere Kunden ein Dutzend Sprachen am Tag sprechen, hat das nicht schwerer gemacht – es hat es unmöglich gemacht, es im Stillen falsch zu machen, und das ist die beste Art von Vorgabe, unter der man entwerfen kann.