Happy Translating!

Übersetzungen von Anwendungen verwalten
Kommentare

Sie haben eine multilinguale Applikation entwickelt und möchten diese 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.

PHP Magazin

Der Artikel „Happy Translating!“ von Daniel Schlichtholz ist erstmalig erschienen im PHP Magazin 1.2012

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 dieses 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.


Themen der folgenden Seiten:

  • Die Zielsetzung
  • Die Geburt eines neuen OS-Projekts
  • oTranCe
  • Bearbeiten von Einträgen
  • Export
  • Import
  • Schreiben eigener Analyzer
  • Stand und Zukunft
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -