© saicle/Shutterstock.com
Übersetzungen von Anwendungen verwalten

Happy Translating!


Sie haben eine multilinguale Applikation entwickelt und möchten sie nun in andere Sprachen übersetzen lassen? Dann stehen Sie vor der organisatorischen Frage, wie Sie den Übersetzern die Mitarbeit möglichst einfach gestalten und die zugelieferten Ergebnisse reibungslos in den Deploy-Prozess einbinden können. Dieser Artikel stellt ein neues Tool vor, das Ihnen dabei behilflich sein könnte.

Als Autor des Open-Source-Projekts MySQLDumper musste ich mir die eingangs geschilderte Frage ebenfalls stellen. Zwar besaßen wir zu diesem Zeitpunkt ein „Onlinesprachlabor“, aber das war in die Jahre gekommen und schwer zu erweitern. Der gute alte PHP4-Spaghetticode hatte seine Schuldigkeit getan und musste nun einem neuen Konzept weichen. Ich schaute mich nach Alternativen um und legte den Fokus dabei auf die Frage: Wie kann man sicherstellen, dass sich möglichst viele Übersetzer beteiligen können und die Ergebnisse zeitnah in der Anwendung erscheinen? Betrachtet man die Vorgehensweise verschiedener Open-Source-Projekte, so fällt auf, dass sich hier noch keine einheitliche Lösung als Best Practice herauskristallisiert hat:

  • Typo3 verwendet eine eigene Extension und verteilt die Ergebnisse über den Extension Manager

  • WordPress setzt auf gettext-Dateien und nennt einen ganzen Pool von Programmen, mit denen man gettext-Dateien pflegen kann

  • Joomla setzt wieder auf eine eigene Extension

  • PhpMyAdmin verwendet – wie WordPress – gettext-Dateien über Poedit, bietet aber zusätzlich die Übersetzung über ein Web-GUI per Pootle an

Je mehr Projekte man sich anschaut, umso mehr individuelle Lösungen findet man.

Einstiegshürden

Für jemanden, der sich gerne an der Übersetzung beteiligen möchte, bedeutet das, dass er sich in die Gepflogenheiten des Projekts einarbeiten und für sich zunächst die technische Basis schaffen muss. Nach meiner Einschätzung gehen bereits an dieser Stelle eine ganze Reihe von potenziellen Helfern verloren. Wer technisch nicht versiert ist, hat hier die ersten Probleme. Die Bedienung von Poedit ist beispielsweise, inklusive dem korrekten Im- und Export der Sprachdateien, nicht selbsterklärend. Die Gefahr, dass der Übersetzer entnervt aufgibt bevor er auch nur ein einziges Wort übersetzt hat, ist nicht zu unterschätzen. Er möchte sich nicht mit technischen Hürden konfrontiert sehen; er möchte schlichtweg übersetzen.

Diejenigen, die sich davon nicht abschrecken lassen, wenden sich bei Problemen an die Community. Das zieht einen teils nicht unerheblichen Kommunikationsaufwand nach sich. Zusätzlich zum eigentlichen Support der Applikation muss jemand die Übersetzer instruieren und Rückfragen beantworten. Besonders problematisch wird das, wenn der Helfer die benutzte Sprache der Community nicht versteht. Geschieht das Ausräumen von Problemen nicht zeitnah genug, passiert es durchaus, dass sich der anfängliche Enthusiasmus des Helfers in Frustration wandelt und er sich letztlich doch nicht beteiligt, obwohl dies ursprünglich seine Absicht war. Die Beantwortung von Fragen kostet aus Sicht des Projekts zusätzliche Zeit, die man sinnvoller in die Weiterentwicklung der Applikation investieren möchte.

Verwaltungshürden

Sind helfende Übersetzer gefunden, gibt es weitere Hürden beim Zusammenführen der erarbeiteten Ergebnisse. Die klassische Methode bei kleineren Projekten umfasst wohl das Zusenden der übersetzten Dateien an eine Person, die die Änderungen letztlich in das Projekt überführt. Werden Sprachdateien benutzt, in denen die Übersetzungen als Key-Value-Paare gespeichert sind, kann man eine so gelieferte Datei noch relativ einfach per Diff auf Änderungen überprüfen. Mit steigender Datei-, Übersetzer oder Sprachanzahl entwickelt sich diese Aufgabe allerdings immer mehr zu einer ungeliebten Sisyphusarbeit. Hinzu kommt ein meist manuelles Konvertieren, wenn die Datei in einem falschen Zeichensatz geliefert wurde, oder noch schlimmer: Es wird gar nicht bemerkt, dass der Zeichensatz falsch ist, und die Datei landet falsch kodiert im Repository des Projekts.

Wenn ein manueller, organisatorischer Schritt zwischengeschaltet ist, ist der Übersetzer in der Regel nicht in der Lage, seine Arbeit umgehend in der Applikation zu betrachten und zu testen. Genau das möchte er aber. Zum einen möchte er überprüfen können, ob der übersetzte Teil im Programmkontext korrekt angezeigt wird, und natürlich möchte er schlichtweg die Früchte seiner Arbeit genießen können.

Die Zielsetzung

Aus den zuvor genannten Punkten ergab sich für mich folgender Anforderungskatalog:

  • Die technischen Hürden sollen für die Übersetzer so gering wie möglich sein

  • Ergebnisse sollen sich möglichst zeitnah in die Applikation einbinden lassen

  • Aktuelle Übersetzungen sollen sich leicht in das Projekt-Repository übertragen lassen

  • Manuelle Zwischenschritte sollen vermieden werden

Mit diesen Anforderungen im Hinterkopf war schnell klar, dass keines der vorhandenen Systeme den Katalog zufriedenstellend erfüllte. Besonders eine Anbindung an ein Repository fehlte mir. So schloss ich mich zwei Wochen meines dreiwöchigen Sommerurlaubs in mein Arbeitszimmer ein und begann eine eigene Umsetzung.

Die geringste technische Hürde stellt aus meiner Sicht eine Onlineplattform dar. Für die Nutzung benötigt der Übersetzer lediglich einen Zugang mit entsprechenden Berechtigungen und einen Browser. Mit dieser Konstellation hatte ich in der Vergangenheit bereits gute Erfahrungen gemacht. Sofern die Oberfläche verständlich und leicht bedienbar ist, tendieren die Rückfragen gen null. Auch beim Oberfläc...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang