© maksym yemelyanov, 123RF

Das freie Web-basierte Weblate hilft bei der koordinierten Übersetzung. Das Tool kommuniziert direkt mit den Versionsverwaltungen Git und Mercurial und unterstützt Gitlab, Github und Bitbucket.

Aus Web und translate hat der Entwickler Michal Cihar für sein Tool das Kunstwort Weblate geformt. Eng an eine Versionsverwaltung angebunden, dient das in Python geschriebene Weblate der kontinuierlichen Übersetzung von Texten, etwa in international aktiven Projekten wie Open Suse. Es lässt sich dank anpassungsfähiger Struktur aber auch für kleinere Vorhaben einsetzen.

Weblate bietet als Grundgerüst die Einbindung von derzeit fast 200 Sprachen. Dabei handelt es sich allerdings nur um grundlegende Definitionen, etwa für den Sprachnamen, die Pluralbildung, die Textrichtung, den Sprachcode (ISO xxx-x). Der Admin kann eigene Sprachdefinitionen festlegen oder bestehende ändern. Die Übersetzung selbst stammt dann je nach Einstellung des Tools von der gesamten Webcommunity, einem bestimmten Personenkreis – aber auch von der Einbindung maschineller Übersetzung [1] wie Deepl, Amazon Translate oder Google Translate. Weblate selbst kann ebenfalls als maschineller Übersetzer fungieren und greift dann auf die Volltext-Engine Whoosh zurück.

Installation

Weblate-Erfinder Michal Cihar nennt drei grundlegende Installationsmethoden. Die erste führt über Docker. Die ist empfohlen, wenn Nutzer sich mit der bestehenden Funktionalität von Weblate zufriedengeben und den Code nicht selbst noch anpassen wollen, was ebenfalls möglich wäre. Die zweite Option, auch hier bleibt der Code von Weblate unverändert, führt über eine Python-Umgebung, die mit Virtualenv eingerichtet wird. Die dritte Option ist eine Installation aus den Quellen, die auf Github liegen [2].

Die Git-Repositories lassen sich auch direkt in Open Shift installieren. In der Dokumentation von Weblate [3] ist das Setup ausführlich beschrieben. Eine deutsche Übersetzung ist dabei bislang nicht zustande gekommen, Englischkenntnisse sind nötig. Weblate bietet zudem eine gehostete Variante [4] an, die gegen Bezahlung die Einrichtung und das Hosting übernimmt. Die Preise dafür beginnen bei rund 20 Euro pro Monat.

Als Mindestanforderung für das Tool sind 2 GByte Speicher, eine Dualcore-CPU und 1 GByte Plattenplatz genannt. Mehr Arbeitsspeicher sei allerdings dienlich, weil er für das Caching auf allen Leveln nützlich ist, angefangen bei Dateisystem und Datenbank. Mehr CPU-Kerne wiederum seien bei einer steigenden Zahl von Nutzern leistungsfördernd.

Das System sollte außerdem Software-seitig Python 2.7 oder 3.4 oder neuer vorhalten und eine Datenbank, die mit Django kompatibel ist, PostgreSQL ist als Referenz genannt. Wer MySQL einsetzt, sollte sich auf mögliche Probleme mit der Unverträglichkeit von der in MySQL genutzten Kodierung UTF-8 und anderen Unicode-Zeichen gefasst machen und die Kodierung auf »utf8mb4« umstellen.

Einstellung

Dem Administrator steht eine breite Palette an Einstellungen zur Verfügung, die sich jeweils noch verästeln. Das betrifft zum einen die Pfade zu den Texten, die es zu übersetzen gilt, zum anderen die an der Übersetzung beteiligten Nutzer und nicht zuletzt deren Rechte. Weblate arbeitet dabei selbst wie eine Versionsverwaltung mit einer grafischen Nutzeroberfläche.

Wer das Tool produktionsreif aufsetzt, findet zudem einige Helferlein, etwa Warnhinweise in Form rot eingefärbter Ausrufezeichen. Es ist im Produktionseinsatz auch angesagt, den Debug-Modus von Django abzuschalten, der ansonsten alle Anfragen und Nutzerdaten anzeigt. Der Administrator konfiguriert nun auch die einzelnen Admins und deren Mailadressen. Weblate informiert über diverse Ereignisse auch per E-Mail.

Registrierung und Zugang

Neue Nutzer, sprich Übersetzer, registrieren sich bei Weblate standardmäßig über das Webformular »python-social-auth«. Die Authentifizierung überlässt Weblate der integrierten Lösung von Django. Diese lässt sich dann nach Gusto an die dort angebotenen Optionen anpassen. Dazu zählen auch Drittlösungen wie die von Gitlab. Prinzipiell erwartet Weblate aber eine validierte E-Mail-Adresse vom gewählten Authentifzierungsservice. Das Zugangssystem von Weblate ist feingranular einstellbar und basiert auf dem Gruppen- und Rollenmodell.

Wird die Access Control List (ACL) aktiviert, sind vorab alle Nutzer blockiert, bis der Admin die Zugriffsrechte definiert hat. Vier grundlegende Einstellungen sind wählbar: Public, Protected, Private und Custom. Ist der Zugang auf »Public« gestellt, ist das Übersetzungsprojekt für alle sichtbar und alle dürfen Übersetzungen eingeben. Der Zustand »Protected« macht die Übersetzungen für alle sichtbar, aber nur bestimmte Nutzer dürfen übersetzen (Abbildung 1). Im Modus »Private« können nur bestimmte Nutzer das Projekt sehen und übersetzen. »Custom« bedeutet, dass Weblate nicht für das Zugriffsmanagement zuständig ist.

Abbildung 1: Open Suse nutzt Weblate für die Übersetzung und hat Protected als Grundeinstellung gewählt. Quelle: Opensuse

Ausgehend davon lassen sich den Gruppen oder einzelnen Nutzern wiederum Privilegien einräumen. Der Einfachheit halber bietet Weblate vordefinierte Gruppen an, etwa für »Administration«, »Languages« und »Screenshots«. Teilnehmer von Languages wären dann für das Management der übersetzten Sprachen zuständig und dürfen solche hinzufügen (Abbildung 2). Die Screnshot-Teilnehmer könnten Screenshots zu bestimmten Zeichenketten hinzufügen.

Abbildung 2: Sprachenvielfalt der Übersetzungen und deren Fortschritt bei Open Suse. Quelle: Opensuse

Übersetzung

Weblate betrachtet übersetzbaren Content prinzipiell als »Project«. Ein Projekt bekommt alle zu übersetzenden Teile zugeordnet, die zusammengehören. Als Beispiel sind die Übersetzungen einer Anwendung in mehreren Sprachen nebst der jeweils zugehörigen Dokumentation. Den übersetzbaren Content ordnet das Tool in einer baumartigen Struktur.

Die Basis bildet das Project, darüber liegen die Components und darüber dann die individuellen Übersetzungen. In den Components sind die VCS-Repositories definiert, die wiederum die zu übersetzenden Dateien enthalten. Die Übersetzungen selbst behandelt Weblate als Translation-Dateien. Das Tool unterstützt eine ganze Latte von Übersetzungsformaten (Abbildung 3).

Abbildung 3: Die Übersetzungsformate, die Weblate unterstützt. Quelle: Weblate

Der Übersetzungsvorgang orientiert sich am Push- und Pull-Prinzip von Git. Wenn Entwickler Änderungen vornehmen, pushen sie diese in die VCS-Repositories. Weblate holt sich (Pull) die Änderungen von den Repositories. Findet Weblate Änderungen in den Übersetzungen, informiert es die Übersetzer, je nachdem, welche Einstellungen dafür getroffen worden sind. Die Übersetzer liefern ihre Arbeit wiederum im Interface ab.

Ist die Übersetzung beendet, folgt vorerst der Commit durch Weblate in das lokale Repository. Je nach Einstellung pusht das Tool die fertige Übersetzung dann zurück. Weblate eignet sich so für die kontinuierliche Lokalisierung.

Konfliktpotenzial

Die Merge-Phase ist nicht ganz frei von potenziellen Konflikten. Der Nutzer tut deshalb gut daran, beim Update der Übersetzungsdateien darauf zu achten, dass es nicht mehrere Änderungen an derselben Datei gibt. Um dies zu verhindern, lassen sich alle bestehenden Änderungen pushen. Die Übersetzung wird so lange gelockt, bis die gewünschten Änderungen vorgenommen sind.

Für das Übersetzungstool hat der Anbieter ein Demosystem [5] aufgesetzt, das sich online ansteuern lässt. Dort findet sich das grundlegende Nutzerinterface mit der Menüführung und Übersetzungsaufgaben. Ein Testübersetzer darf auch Eingaben machen und die Vorschläge anderer Teilnehmer anschauen sowie die Sprachen festlegen.