DWX hakt nach: Wie lokalisiert man eine Anwendung am besten?

Wer seine Anwendung erfolgreich vermarkten will, der muss sie auf kurz oder lang auch in anderen Sprachen veröffentlichen. Dank i18n ist das kein Hexenwerk. Aber wie geht man bei der Lokalisierung am besten vor? Welche Tools empfehlen sich? DWX Developer Week hat den Lokalisierungsexperten Harald Binkle gefragt.

Harald hat in den letzten zwei Jahrzehnten umfangreiche Erfahrungen in Bereichen wie Entwicklung über Projektleitung und Produktverantwortung bis hin zum Kundensupport und Consulting gesammelt. In seiner Rolle als Full-Stack-Entwickler und Architekt konzentriere er sich hauptsächlich auf den Frontend-Bereich und ist verantwortlich für die Entwicklung, Einführung und Wartung von Cloud-Anwendungen auf Basis von Microservices-Architekturen. Auf der DWX Developer Week hält er einen Talk zum Thema It’s all greek to me! – Lokalisierung in Web-Apps elegant und einfach am 3. Juli 2025 um 15.00 Uhr.

Harald Binkle: Aus meiner Erfahrung werden die beiden größten Fehler in gleich zwei Bereichen gemacht.

Zum einen bei der Nutzung beziehungsweise Wahl diverser Lokalisierungs-Frameworks und zum anderen bei der Erstellung der Originalsprache. Viele Lokalisierungs-Frameworks, gerade im Web-Umfeld, verwenden "magic strings" als Identifikatoren der Übersetzungs-IDs. Diese sind aber weder refactoring-sicher noch werden sie von der Codevervollständigung der IDEs unterstützt und sind somit zu vermeiden. Beim Erstellen der Originalsprache werden Strings oft von Entwicklerinnen und Entwicklern isoliert und ohne Kontext erstellt, was beim späteren Übersetzen zu Missverständnissen oder klaren Fehlübersetzungen führen kann. Sogar wenn der Entwickler selbst die erste weitere Sprache übersetzt, geschieht ihm dies ohne Kontext auch.

Harald: Ja, mit zunehmende Projektgröße wird es schwieriger, aber die Projektgröße ist nicht allein dafür verantwortlich, ab wann man genau auf das Tooling und die Art der Implementierung der Lokalisierung achten sollte. Hat man beispielsweise eine kleine App, mit nur kleinem Funktionsumfang und wenigen Texten, muss diese aber in sechs verschiedenen Sprachen zur Verfügung stellen, ist die Wahrscheinlichkeit für Übersetzungsfehler gegebenenfalls noch größer als im Vergleich zu einer sehr großen Anwendung, die nur in zwei Sprachen bereitgestellt werden soll. Neben Projektgröße und die Anzahl Sprachen sehe ich auch weitere Faktoren, die ausschlaggebend sind.

Harald: Ja klar, es gibt doch immer irgendwelche Tools und Ansätze. Welche Tools wann und wie zum Einsatz kommen hängt davon ab wie groß das Projekt ist, wie groß das Entwickler-Team ist, wie viel Wert auf projektübergreifende Wiederverwendbarkeit gelegt wird und in wie viele Sprachen übersetzt werden soll – beziehungsweise, ob die Zielsprachen alle von Entwicklern abgedeckt werden können oder nicht. Und wenn nicht, wie technisch versiert die Übersetzer sind.

Es gibt aber auch Tools und Ansätze, die ich ganz klar in jedem Fall empfehlen würde, wie zum Beispiel i18n-ally für VSCode, das Beseitigen von zuvor genannten "magic strings" und das Bereitstellen von Kontextinformationen.

Wer mehr wissen und Harald selbst befragen will, der sollte auf die DWX Developer Week nach Mannheim kommen. Hier hält er seinen Talk It’s all greek to me! – Lokalisierung in Web-Apps elegant und einfach am 3. Juli 2025 um 15.00 Uhr. Mehr Informationen gibt es auf www.developer-week.de.