React v19 - i18n mit react-i18next

React v19+ — i18n mit react-i18next

0:00 Mehrsprachigkeit wird in Projekten fast immer unterschätzt. Der erste Gedanke lautet: Wir tauschen die Texte aus, das ist eine Fleißaufgabe. Und dann stellt sich heraus, dass Polnisch fünf Pluralformen kennt, dass deutsche Wörter dreißig Prozent länger sind als englische und die Schaltflächen sprengen, und dass Arabisch von rechts nach links läuft und damit das ganze Layout spiegelt.

0:22 Wer Mehrsprachigkeit früh richtig anlegt, hat später eine Fleißaufgabe. Wer sie nachrüstet, hat ein Projekt. Heute schauen wir uns an, wie der erste Weg aussieht.

Internationalisierung mit react-i18next

0:32 Der Bogen führt von der ersten Einrichtung bis zu einem Arbeitsablauf, bei dem Übersetzerinnen und Übersetzer eingebunden sind und die Bauleitung fehlende Texte meldet. Das Leitmotiv steht im Zitat: Kein Text steht mehr fest im Code, jede Zeichenkette lebt in einer Übersetzungsdatei — und wird dabei typsicher referenziert.

0:49 Dazwischen liegen die Themen, die in der Praxis wehtun: Plurale, Zuschnitt der Dateien und die Frage, wie man merkt, dass jemand einen Text vergessen hat. Die mittlere Frage ist meine Lieblingsfrage in diesem Seminar, weil sie zuverlässig Geschichten hervorbringt. Fehlende Texte, die im Betrieb als kryptischer Schlüssel auf dem Bildschirm stehen. Ein Zähler, der "1 Artikel" schreibt, aber auch "1 Artikel" für null.

1:14 Oder das arabische Layout, bei dem zwar der Text spiegelt, aber die Pfeile weiterhin nach rechts zeigen. Wenn Sie solche Erfahrungen mitbringen, sprechen Sie sie an — wir gehen heute an genau diese Stellen.

Grundlagen der Internationalisierung

1:27 Fangen wir mit den Begriffen an, denn hier steckt bereits die wichtigste Weichenstellung. Zwei Wörter, die im Alltag munter vermischt werden, meinen zwei sehr verschiedene Tätigkeiten — und wer sie trennt, plant sein Projekt anders. Wer sie durcheinanderbringt, plant im Zweifel die falsche Arbeit ein — und merkt es erst, wenn die erste Übersetzung ansteht.

1:47 Der Unterschied lässt sich gut an einem Neubau erklären. Internationalisierung ist die Elektroinstallation: Sie legen Leitungen und Anschlüsse, damit später überall eine Lampe hin kann. Lokalisierung ist das Einschrauben der konkreten Lampe. Das eine ist Ihre Arbeit als Entwicklungsteam und geschieht einmal, das andere geschieht pro Sprache und wird meist von anderen erledigt.

2:08 Die Problemfelder darunter sind die Stellen, an denen sich Sprachen wirklich unterscheiden — und keines davon lässt sich durch bloßes Austauschen von Texten lösen. Der erste Punkt ist die praktische Konsequenz aus der Definition: Ihre Anwendung muss übersetzbar sein, bevor irgendjemand übersetzt. Der zweite verdient eine Illustration.

2:28 Im Deutschen gibt es zwei Zahlformen, Einzahl und Mehrzahl. Im Polnischen sind es je nach Zahl drei, im Arabischen sechs. Wer im Code eine Bedingung schreibt, ob die Menge eins ist, hat damit eine deutsche Grammatikregel fest in seine Anwendung eingebaut — und die stimmt für den Rest der Welt nicht. Genau deshalb ist das kein Textproblem.

2:48 Fünf Schritte ohne eine Zeile Code, und das ist Absicht. Besonders lohnend ist der zweite: Sammeln Sie die Problemfelder für Ihre konkreten Zielsprachen. Wenn Ihre Anwendung Deutsch, Englisch und Französisch spricht, ist vieles harmlos — ähnliche Schriftrichtung, ähnliche Zahlformen. Kommt Arabisch oder Polnisch dazu, ändern sich die Anforderungen an Ihr Layout grundlegend.

3:10 Diese Frage einmal ehrlich zu beantworten, bevor Sie anfangen, spart die unangenehme Entdeckung sechs Monate später. Diese Gegenüberstellung sollten Sie mitnehmen, weil sie das Denkmodell für den ganzen Tag ist. Oben Ihre Arbeit: Schlüssel statt fester Texte, einmal für alle Sprachen. Darunter die Arbeit pro Sprache, die meist gar nicht bei Ihnen liegt. Und unten die Liste, die ich als Prüfliste empfehle.

3:35 Gehen Sie sie durch, bevor Sie eine neue Sprache aufnehmen — vier von fünf bösen Überraschungen in mehrsprachigen Projekten stehen dort. Besonders die Textausdehnung wird selten eingeplant und trifft dafür umso zuverlässiger. Diese erste Aufgabe ist bewusst eine Denkaufgabe. Halten Sie fest, welche Sprachen tatsächlich kommen sollen, welche Problemfelder das mit sich bringt und warum Sie sich für ein bestimmtes Werkzeug entscheiden.

4:00 Der letzte Teil ist der, den man am liebsten überspringt und am ehesten begründen muss — spätestens wenn in zwei Jahren jemand fragt, warum nicht die andere Bibliothek. Wer im Umfeld von Next.js arbeitet, nimmt die Zusatzaufgabe und wägt die spezialisierte Alternative ab. Der letzte Punkt ist der teuerste. Schriftrichtung von rechts nach links ist keine Einstellung, die man am Ende anschaltet — sie betrifft jedes Layout, jeden Abstand, jedes Symbol mit Richtungsbedeutung.

4:28 Wenn Ihre gesamte Gestaltung mit "links" und "rechts" arbeitet, wird daraus ein Umbau. Machen Sie es von Anfang an richtig, und es kostet Sie nichts; wir kommen im letzten Kapitel darauf zurück. Der dritte Punkt ist der visuelle Klassiker: Was auf Englisch passt, sprengt auf Deutsch die Schaltfläche.

Setup & Konfiguration

4:46 Jetzt wird es praktisch. Wir richten die Bibliothek ein, legen die Struktur für die Übersetzungsdateien fest und sorgen dafür, dass nicht alle Sprachen auf einmal geladen werden. Gerade der letzte Punkt entscheidet später über die Ladezeit. Zwei Einstellungen aus diesem Kapitel entscheiden übrigens darüber, wie Ihre Anwendung im Fehlerfall aussieht.

5:06 Zwei Bausteine lohnen einen genaueren Blick. Die Rückfallsprache ist Ihre Versicherung: Fehlt ein Text in der gewählten Sprache, erscheint er in der Rückfallsprache statt gar nicht. Das ist der Unterschied zwischen einer Oberfläche, in der ein Satz englisch bleibt, und einer, in der eine Schaltfläche leer ist. Der zweite Baustein ist das bedarfsgesteuerte Nachladen: Ihre Anwendung bringt nicht sämtliche Texte aller Sprachen mit, sondern holt sich, was sie gerade braucht.

5:33 Bei drei Sprachen ist das nett, bei fünfzehn ist es entscheidend. Der letzte Punkt hat eine Nutzerseite, die man beachten sollte. Die automatische Spracherkennung schaut sich mehrere Quellen an — die Adresse, einen gespeicherten Wert, die Browsereinstellung. Die Reihenfolge dieser Quellen ist Ihre Entscheidung, und sie hat eine klare richtige Antwort: Was der Nutzer aktiv gewählt hat, gewinnt immer.

5:56 Nichts ist ärgerlicher als eine Seite, die einen bei jedem Besuch wieder in die vermeintlich passende Sprache zwingt, obwohl man längst umgestellt hat. Der letzte Schritt verdient eine Erklärung, weil er ein sichtbares Problem löst. Das Nachladen der Texte braucht einen kurzen Moment — und wenn Ihre Anwendung in diesem Moment schon zeichnet, sieht der Nutzer für den Bruchteil einer Sekunde die rohen Schlüssel auf dem Bildschirm.

6:20 Das sieht aus wie ein Fehler und ist die häufigste Beschwerde nach dem ersten Einbau. Ein sauber gesetzter Ladezustand verhindert es. Ansonsten gilt: Die Ordnerstruktur nach Sprache und Bereich einmal richtig anlegen — nachträglich umbenennen kostet mehr, als man denkt. Was Sie hier sehen, ist eine Kette von Erweiterungen, die nacheinander eingehängt werden. Zuerst das Nachladen über das Netz, dann die Spracherkennung, dann die Anbindung an React.

6:46 Die Reihenfolge ist nicht beliebig, aber sie ist die naheliegende. Unten stehen die beiden Einstellungen, die man wirklich verstehen muss: die Rückfallsprache und der Standardbereich. Alles andere lässt sich später hinzufügen, ohne dass etwas bricht. Deshalb ist diese kompakte Einrichtung ein guter Startpunkt, auch für große Projekte.

7:06 Richten Sie das jetzt selbst ein. Der interessanteste Teil ist die Zusatzaufgabe, und ich empfehle sie ausdrücklich: Löschen Sie absichtlich einen Text in einer Sprache und schauen Sie, was passiert. Mit gesetzter Rückfallsprache erscheint der Text in der anderen Sprache — unschön, aber verständlich. Ohne sie erscheint der rohe Schlüssel.

7:25 Dieses Verhalten einmal gesehen zu haben, macht die Bedeutung dieser einen Konfigurationszeile deutlicher als jede Erklärung. Der dritte Punkt ist das Aufblitzen der unübersetzten Texte, über das wir eben gesprochen haben — es sieht im Betrieb billig aus und ist mit einer Zeile erledigt. Der vierte betrifft die Reihenfolge der Erkennungsquellen und damit die Nutzererfahrung.

7:46 Und der zweite ist der stille Kostenpunkt: Wer alle Bereiche aller Sprachen sofort lädt, schleppt bei fünfzehn Sprachen ein Vielfaches der nötigen Daten mit. Das merkt niemand beim Entwickeln mit zwei Sprachen und jeder im Betrieb.

Übersetzen in Komponenten

7:59 Jetzt zum eigentlichen Alltag: Wie kommen die Texte in die Oberfläche? Der einfache Fall ist schnell erledigt. Interessant wird es, sobald mitten in einem Satz ein Link oder eine Hervorhebung steht — und genau da machen die meisten Projekte den entscheidenden Fehler. Der Unterschied zwischen richtig und beinahe richtig ist hier besonders groß — und er zeigt sich erst in der dritten Sprache.

8:21 Der zweite Baustein ist der wichtigere, und er löst ein Problem, das man erst sieht, wenn man es einmal falsch gemacht hat. Nehmen Sie den Satz "Ich akzeptiere die AGB", wobei die AGB ein Link sind. Die naheliegende Lösung wäre, den Satz in drei Teile zu zerlegen: Text davor, Link, Text danach. Und genau das ist die Falle — denn in einer anderen Sprache steht der Link vielleicht am Satzanfang oder die Wortstellung dreht sich.

8:47 Die Übersetzerin bekommt drei zusammenhanglose Fetzen und kann keinen korrekten Satz daraus bauen. Die spezielle Komponente hält den Satz zusammen und markiert nur, wo das Markup sitzt. Der zweite Punkt verdient eine Sicherheitsanmerkung. Wenn Sie einen Namen oder eine Eingabe in einen übersetzten Text einsetzen, wird sie automatisch entschärft — aus spitzen Klammern wird harmloser Text.

9:10 Das ist der eingebaute Schutz gegen eingeschleusten Code. Es gibt einen Schalter, um das abzuschalten, und er wird regelmäßig aus dem falschen Grund benutzt: weil jemand HTML in einer Übersetzung unterbringen will. Dafür gibt es die andere Komponente. Diesen Schalter umzulegen, öffnet eine Tür, die Sie nicht öffnen wollen.

9:29 Der zweite Schritt betrifft die Ordnung in den Dateien, und die zahlt sich später aus. Schlüssel lassen sich verschachteln — also nach Bereich, dann nach Element gruppieren, statt zweihundert flache Einträge zu haben. Mit einem gesetzten Präfix sparen Sie sich dann in der Komponente das ständige Wiederholen des Pfades. Das klingt nach Kosmetik, entscheidet aber darüber, ob jemand in einem Jahr eine Übersetzungsdatei mit achthundert Zeilen noch bearbeiten kann, ohne zu suchen.

9:56 Hier stehen die beiden Wege nebeneinander. Oben der einfache Fall: ein Schlüssel, ein eingesetzter Wert, fertig. Unten der interessante: Der Satz bleibt als zusammenhängender Satz erhalten, mit dem Link an seiner natürlichen Stelle. In der Übersetzungsdatei taucht dieser Satz als Ganzes auf, mit einer Markierung für den Link — und die Übersetzerin kann den Link dorthin schieben, wo er in ihrer Sprache hingehört.

10:20 Das ist der ganze Unterschied zwischen übersetzbar und "technisch möglich". Bauen Sie jetzt eine Oberfläche vollständig auf Schlüssel um. Das Erfolgskriterium ist streng: alle sichtbaren Texte. Suchen Sie ruhig gezielt nach den vergessenen Ecken — Platzhaltertexte in Eingabefeldern, Beschriftungen für Screenreader, Fehlermeldungen, Titel von Tooltips.

10:41 Das sind die Stellen, die regelmäßig deutsch bleiben, wenn der Rest längst übersetzt ist. Als Ergänzung dann der Sprachwechsel mit gespeicherter Auswahl — und denken Sie an das, was wir über die Reihenfolge der Erkennung gesagt haben. Der erste Punkt ist der wichtigste des Kapitels und der häufigste Fehler überhaupt. Zusammengesetzte Sätze funktionieren auf Deutsch und Englisch zufällig, weil die Wortstellung ähnlich ist — und brechen in der ersten Sprache, die es anders macht.

11:08 Der zweite Punkt ist die Sicherheitstür von eben. Und der letzte ist eine Kleinigkeit mit großer Wirkung auf die Zufriedenheit: Wer seine Sprache jedes Mal neu einstellen muss, hält die Anwendung schlicht für kaputt.

Plurale, Kontext & Formatierung

11:20 Jetzt kommen wir zu dem Teil, in dem sich Sprachen wirklich unterscheiden — und in dem der naive Ansatz garantiert scheitert. Mengenangaben, Geschlechtsformen, Zahlen, Datumsangaben und Währungen. Die gute Nachricht: Für all das gibt es seit Jahren einen Standard im Browser. Die schlechte Nachricht: Wer diesen Standard nicht nutzt, baut sich die Grammatik jeder Zielsprache selbst nach.

11:43 Der entscheidende Gedanke ist, dass die Grammatikregeln nicht in Ihrem Code stehen, sondern im Browser. Der weiß für jede Sprache, welche Zahlformen es gibt und welche Zahl welche auslöst. Sie liefern nur die Varianten in der Übersetzungsdatei und übergeben die Menge — die Auswahl trifft der Standard. Für das Polnische entstehen dabei drei Einträge, für das Deutsche zwei, für das Japanische einer. Ihr Code bleibt dabei in allen Fällen identisch.

12:09 Genau darin liegt der Wert: Sie müssen die Grammatik der Zielsprache gar nicht kennen. Der zweite Punkt betrifft die Geschlechtsformen, und er ist eleganter, als er klingt. Statt im Code zu verzweigen, hängen Sie an den Schlüssel eine Zusatzangabe — und in der Übersetzungsdatei stehen die passenden Varianten. Der Vorteil: Sprachen, die diese Unterscheidung nicht brauchen, ignorieren sie einfach. Sprachen mit mehr Formen ergänzen weitere Einträge.

12:36 Die Logik wandert also aus Ihrem Code dorthin, wo sie hingehört — zu der Sprache, für die sie gilt. Die Schritte vier und fünf betreffen Zahlen, Datum und Währung, und dazu ein praktischer Hinweis: Diese Formate sind erstaunlich unterschiedlich. Das Tausendertrennzeichen ist mal ein Punkt, mal ein Komma, mal ein schmales Leerzeichen. Das Währungssymbol steht mal vorn, mal hinten.

12:59 Und ein Datum in der Form drei Punkt vier bedeutet in der einen Sprache März, in der anderen April. Nichts davon sollten Sie selbst zusammenbauen — die eingebauten Formatierer kennen die Regeln für jede Sprache. Das Wichtigste an diesem Beispiel ist, was man nicht sieht: Es gibt keine Bedingung. Sie legen zwei Einträge an, übergeben die Menge, und die richtige Form wird gewählt.

13:22 Der springende Punkt kommt beim Hinzufügen einer Sprache mit mehr Formen — dann ergänzt die Übersetzerin schlicht weitere Einträge, und Ihr Aufruf bleibt unverändert. Beachten Sie außerdem: Der Zählwert ist gleichzeitig der eingesetzte Wert im Text. Sie müssen ihn nicht zweimal übergeben. Ein Warenkorb ist die ideale Übung, weil beides zusammenkommt — Mengen und Preise.

13:44 Machen Sie unbedingt den Härtetest: Schalten Sie testweise auf Polnisch oder eine andere Sprache mit mehreren Zahlformen um und probieren Sie verschiedene Mengen durch. Sie werden sehen, wie die Formen wechseln, ohne dass Ihr Code davon weiß. Und schauen Sie sich die Preisformatierung in mehreren Sprachen an — die Unterschiede sind größer, als die meisten erwarten.

14:05 Der erste Punkt ist die Verzweigung im Code, und ich fasse noch einmal zusammen, warum sie so hartnäckig ist: Sie funktioniert. Auf Deutsch und Englisch macht sie genau das Richtige. Der Fehler zeigt sich erst mit der ersten Sprache, die anders tickt — und dann sitzt er nicht an einer Stelle, sondern an vierzig. Der dritte Punkt ist ein Versionshinweis: Ein älterer Formatierungsweg ist entfallen. Wer Beispiele aus dem Netz übernimmt, sollte auf das Alter der Quelle achten.

Architektur & Skalierung

14:33 Bis hierhin haben wir über einzelne Texte gesprochen. Jetzt geht es um die Frage, wie man dreitausend davon organisiert, ohne dass die Anwendung beim Start alles lädt und ohne dass die Dateien unbearbeitbar werden. Der Zuschnitt, den Sie hier festlegen, betrifft nicht nur die Ladezeit, sondern auch die Zusammenarbeit mit den Übersetzern.

14:52 Der Schnitt in Bereiche ist die zentrale Entscheidung dieses Kapitels, und er hat zwei ganz verschiedene Vorteile. Technisch: Wer nur den Kassenbereich öffnet, lädt auch nur dessen Texte. Organisatorisch, und das wird oft übersehen: Ein Bereich ist eine handhabbare Einheit für die Übersetzung. Man kann ihn jemandem geben, jemand kann ihn fertigstellen, man kann seinen Fortschritt messen.

15:14 Eine einzige Datei mit dreitausend Einträgen ist weder das eine noch das andere — sie ist ein Fass, in das alle hineinschütten. Der zweite Punkt ist eine Entscheidung, über die Teams gern streiten. Soll der Schlüssel den Ort beschreiben oder den Text? Für den Text spricht die Lesbarkeit im Code. Dagegen spricht ein handfestes Problem: Wenn der deutsche Text sich ändert, ändert sich der Schlüssel — und damit gehen alle vorhandenen Übersetzungen in allen Sprachen verloren, obwohl sie inhaltlich noch stimmen.

15:44 Bedeutungsbezogene Schlüssel überleben Textänderungen. Das ist der Grund, warum sie sich in großen Projekten fast immer durchsetzen. Der letzte Schritt verdient eine Einschränkung, denn hier wird gern übertrieben. Vorausladen ist sinnvoll für die zwei, drei Sprachen, die tatsächlich häufig genutzt werden. Alle fünfzehn vorzuladen ist genau das, was Sie mit dem bedarfsgesteuerten Laden gerade vermeiden wollten — nur umständlicher. Schauen Sie in Ihre Nutzungsdaten, statt zu raten.

16:12 Und beim Zuschnitt in Schritt eins gilt die einfache Faustregel: Ein Bereich sollte ungefähr dem entsprechen, was ein Team betreut. Zwei Zeilen, die die ganze Mechanik zeigen. Sie sagen in der Komponente, welchen Bereich Sie brauchen — und genau der wird geladen, sonst nichts. Bei mehreren Bereichen geben Sie eine Liste an, wobei der erste als Standard gilt.

16:33 Interessant ist, was das für die Ladezeit bedeutet: Die Startseite lädt nur die gemeinsamen Texte, der Kassenbereich kommt erst dazu, wenn jemand tatsächlich dorthin geht. Bei den meisten Nutzern passiert das nie — und sie zahlen die Datenmenge auch nicht. Teilen Sie jetzt Ihre Übersetzungen auf. Der aufschlussreichste Teil ist die Kontrolle im Nachhinein: Schauen Sie im Netzwerk-Werkzeug des Browsers nach, welche Dateien beim Start tatsächlich geladen werden.

17:00 Oft findet man dabei einen Bereich, den man nur für eine Kleinigkeit eingebunden hat und der jetzt überall mitlädt. Als Ergänzung dann das Vorausladen mit Messung — und zwar mit einer gedrosselten Verbindung, sonst sehen Sie im lokalen Netz gar keinen Unterschied. Der zweite Punkt ist der teure Fehler aus der Warum-Folie: Schlüssel, die den Text enthalten, brechen bei jeder Textänderung.

17:21 Der erste ist die Bequemlichkeitsfalle — eine Datei für alles ist am Anfang einfacher und wird genau einmal unhandlich, nämlich wenn es zu spät zum Umstellen ist. Und der dritte erinnert daran, dass bedarfsgesteuertes Nachladen einen sichtbaren Moment erzeugt, den man abfangen muss. Ohne diesen Ladezustand sehen die Nutzer wieder kurz die rohen Schlüssel.

TypeScript & Tooling

17:42 Kommen wir zu einem der schönsten Teile des Tages. Bisher waren Schlüssel einfach Zeichenketten — und Zeichenketten schreibt man falsch. Schauen wir uns an, wie der Compiler das übernimmt und welche Werkzeuge einem die Fleißarbeit abnehmen. Es ist der Teil, der aus einem fehleranfälligen Thema eine Sache macht, um die man sich kaum noch kümmern muss.

18:02 Die Idee dahinter ist bestechend: Ihre Übersetzungsdateien sind ja bekannt — der Compiler kann daraus ableiten, welche Schlüssel es gibt. Ab diesem Moment ist ein Tippfehler kein stiller Fehler mehr, der sich als Rohtext auf dem Bildschirm zeigt, sondern eine rote Unterringelung im Editor. Dazu kommt die Autovervollständigung, die den praktischen Nutzen fast noch übertrifft: Sie tippen den Anfang und sehen, welche Texte es in diesem Bereich schon gibt.

18:27 Das verhindert nebenbei, dass derselbe Satz zum vierten Mal neu angelegt wird. Der dritte und vierte Punkt beschreiben eine Automatisierung, die sich schnell bezahlt macht. Ein Werkzeug durchsucht Ihren Code nach verwendeten Schlüsseln und vergleicht sie mit den Übersetzungsdateien. Es findet also beides: Schlüssel, die verwendet werden, aber nirgends stehen — das wäre ein leerer Text im Betrieb.

18:50 Und Einträge, die niemand mehr benutzt, weil die Komponente längst gelöscht ist. Der zweite Fall ist harmlos, aber er summiert sich; in gewachsenen Projekten sind regelmäßig ein Drittel der Einträge tot. Wichtig ist der vierte Schritt, denn ohne ihn verfällt der Rest. Die Prüfung auf fehlende Schlüssel muss in der Bauleitung laufen, nicht auf dem Rechner von jemandem, der daran denkt.

19:12 Sonst passiert das Übliche: Es funktioniert drei Wochen, dann vergisst es jemand unter Zeitdruck, und ein halbes Jahr später ist die Hälfte der Sprachen unvollständig, ohne dass es jemandem aufgefallen wäre. Fehlende Übersetzungen sind ein Fehler wie ein fehlgeschlagener Test — nur dass ihn sonst niemand bemerkt. Ein kleiner Block mit großer Wirkung. Sie melden dem Typsystem einmal an, welche Übersetzungsdateien es gibt — und ab da kennt der Compiler jeden gültigen Schlüssel.

19:39 Der Kommentar unten ist das Entscheidende: Ein unbekannter Schlüssel ist kein Laufzeitproblem mehr, sondern hält den Bau an. Verschieben Sie die Fehlerentdeckung damit von "ein Nutzer meldet einen komischen Text" zu "der Editor unterringelt es beim Tippen". Das ist die größte Einzelverbesserung im Alltag mit mehrsprachigen Projekten.

19:59 Schalten Sie die Typprüfung ein und probieren Sie sie sofort aus: Schreiben Sie einen Schlüssel absichtlich falsch und schauen Sie zu, wie der Compiler meckert. Danach die andere Richtung — tippen Sie einen Bereich an und lassen Sie sich die verfügbaren Texte vorschlagen. Für die Zusatzaufgabe mit der aufrufbaren Schreibweise: Das ist reine Geschmackssache, aber sie hat einen echten Vorteil, weil Umbenennungen im Editor damit funktionieren.

20:23 Bei Zeichenketten tun sie das nicht. Der zweite Punkt ist der praktische Reibungspunkt beim Arbeiten: Die generierten Typen sind nur so aktuell wie ihr letzter Lauf. Wer einen neuen Text anlegt und sich wundert, dass der Compiler ihn nicht kennt, hat meist einfach die Generierung vergessen. Hängen Sie sie an den Startbefehl des Projekts, dann erledigt sie sich von selbst.

20:44 Der letzte Punkt ist der stille Ballast: verwaiste Einträge, für die weiterhin Übersetzungen bezahlt werden, obwohl sie niemand mehr sieht.

Workflow, Qualität & Best Practices

20:52 Zum Abschluss die organisatorische Seite. Übersetzungen entstehen nicht im Entwicklungsteam, sondern anderswo — und die Frage ist, wie beide Seiten zusammenkommen, ohne dass jemand Tabellen hin- und herschickt. Dazu zwei Prüfverfahren, die erstaunlich viel finden. Und wir schließen den Kreis zu einem Problem, das wir im ersten Kapitel bewusst aufgeschoben haben — der Schriftrichtung.

21:15 Der interessanteste Baustein hier ist die Schein-Lokalisierung, und sie ist ein schönes Beispiel für eine einfache Idee mit großer Wirkung. Sie erzeugen eine künstliche Sprache, in der jeder Text erkennbar verfremdet und künstlich verlängert wird. Dann klicken Sie durch die Anwendung. Alles, was normal aussieht, ist ein vergessener fester Text — auf einen Blick, ohne Suche. Und gleichzeitig sehen Sie, welche Schaltflächen bei längerem Text auseinanderfallen.

21:41 Zwei der drei Hauptprobleme aus dem ersten Kapitel, gefunden in einer Viertelstunde. Der erste Punkt beschreibt einen Ablauf, der die Zusammenarbeit umdreht. Statt dass jemand Listen exportiert und verschickt, meldet die Anwendung fehlende Texte selbst an das Übersetzungssystem, sobald sie ihnen begegnet. Die Übersetzerin sieht dort neue Aufgaben, ohne dass jemand sie informieren musste.

22:03 Wichtig allerdings: Das gehört in die Entwicklungsumgebung, nicht in den Betrieb — sonst schickt Ihre Anwendung im laufenden Betrieb Daten an einen externen Dienst, was so niemand geplant hat. Der letzte Schritt löst das Problem der Schriftrichtung, das wir am Anfang aufgeschoben haben — und zwar überraschend elegant. Statt in der Gestaltung von "links" und "rechts" zu sprechen, sagen Sie "Anfang" und "Ende".

22:27 In einer Sprache, die von links nach rechts läuft, ist der Anfang links; in einer, die andersherum läuft, rechts. Ihre gesamte Gestaltung spiegelt sich damit von selbst. Das ist kein Trick, sondern der vorgesehene Weg — und er kostet Sie nichts, wenn Sie ihn von Anfang an nutzen. Oben der Schalter, der fehlende Texte automatisch meldet — mit dem Hinweis von eben, dass er in die Entwicklungsumgebung gehört.

22:52 Unten der Hinweis auf die Schein-Lokalisierung, und schauen Sie sich das Beispiel genau an: Der Text ist noch lesbar, aber unübersehbar verfremdet, und er ist länger als das Original. Beides mit Absicht. Lesbar, damit Sie prüfen können, ob der richtige Text an der richtigen Stelle steht; verfremdet und länger, damit Sie sofort sehen, was nicht übersetzt wird und was nicht ins Layout passt.

23:14 Zum Abschluss die Qualitätssicherung. Ich empfehle, den Schein-Lauf tatsächlich zu machen und dabei durch die ganze Anwendung zu klicken — es ist die lehrreichste Viertelstunde dieses Seminars. Sie werden feste Texte finden, von denen Sie überzeugt waren, dass es sie nicht mehr gibt. Meist in Fehlermeldungen, Bestätigungsdialogen und allem, was nur unter besonderen Bedingungen erscheint. Genau die Stellen prüft nämlich sonst niemand.

23:39 Der zweite Punkt ist einer, den ich noch nicht angesprochen habe und der oft vorkommt: Texte, die in einer Konstantendatei oder in der Geschäftslogik stecken statt in der Oberfläche. Etwa eine Liste von Statusbezeichnungen. Sie fallen nicht auf, weil sie nicht in Komponenten stehen — und sie bleiben deutsch, bis sich jemand beschwert.

23:58 Der letzte Punkt fasst die Schriftrichtung zusammen: Wer mit links und rechts arbeitet, baut eine Anwendung, die sich nicht spiegeln lässt. Fassen wir den Tag zusammen. Übersetzbarkeit ist die Infrastruktur, die Sie bauen — kein Text steht mehr fest im Code. Die Einrichtung braucht zwei Entscheidungen, die man nicht vergessen darf: eine Rückfallsprache und einen Zuschnitt in Bereiche, die bedarfsgesteuert laden.

24:22 In den Komponenten halten Sie Sätze zusammen, statt sie zusammenzubauen, und überlassen Grammatik und Formate dem Standard. Und der letzte Punkt ist das, was den Unterschied zwischen einem Projekt und einem Dauerthema macht: typsichere Schlüssel und eine Prüfung, die automatisch läuft.

Fragen & Weiterarbeiten

24:38 In der Freigabe liegen alle Sprachdateien und Übungen — nehmen Sie sich besonders die Konfiguration mit den Typen und den Prüfschritten mit, das ist der Teil, den Sie in Ihr eigenes Projekt übertragen können. Die Dokumentation der Bibliothek ist gut gepflegt und hat für jeden Sonderfall ein Beispiel; die Kernseite lohnt sich für alles rund um Plurale und Formatierung.

24:58 Wenn bei Ihnen eine Sprache dazukommt, die wir heute nicht besprochen haben, melden Sie sich gern. Vielen Dank für Ihre Aufmerksamkeit.