Stellen Sie sich vor: Sie haben 7 Entwicklungsteams mit insgesamt mehr als 100 Mitarbeitern. Sie sahen gleichzeitig 13 Bewerbungen. Die Arbeiten werden in 20 Repositories durchgeführt.
Alle Bewerbungen müssen übersetzt werden. Einige in 6 Sprachen, einige in 20. Und einige in 13, aber dies ist ein völlig anderer Satz von Sprachen, der in den vorherigen 20 nicht enthalten ist.
Jeder hat einen anderen Stapel, aufgrund unterschiedlicher Zeilenformate: js, json, ts, yaml oder yml. Und einige behalten ihre Texte immer noch in der Datenbank.
Sie arbeiten an Agile: tägliche Wertschöpfung, zweiwöchige Sprints. DoR enthält alle notwendigen Übersetzungen. Natürlich wurden gestern Übersetzungen benötigt, um Zeit zum Testen zu haben.
Es gibt eine Abteilung für technische Redakteure. Wer ist technischer Redakteur? Dies ist eine Person, die externe Dokumentation schreibt, manchmal interne. Schreibt alle Arten von Texten, die Benutzer oder Partner sehen können: Front-End-Texte, Nachrichtentexte, API-Antworten, Fehler. Begleitet den Entwicklungsprozess, um in Technologie und Geschäftslogik einzutauchen. Und bietet die rechtzeitige Lieferung von Übersetzungen an die Anwendung.
Es gibt auch die Position eines Texter-Übersetzers und Lokalisierungsmanagers. Dies ist eine Person, die alle Texte auf Englisch erstellt, die Konsistenz der Übersetzungen überwacht, Übersetzer ernennt und alle damit verbundenen Probleme löst.
Achtung, die Frage ist: Wie viele technische Spezifikationen, Texter und Lokalisierungsmanager sind erforderlich, um die Entwicklung nicht zu behindern und nicht die gesamte technische Abteilung zu verletzen?
In unserem Fall haben wir 4 technische Services und 1 Manager für die Lokalisierung von Textern verwaltet. Die Lieferung von Überweisungen erfolgt im Durchschnitt innerhalb eines Werktages und überschreitet nie drei Werktage. Ich hoffe du findest es interessant.
Wie sind wir dazu gekommen?
Vor 6 Jahren haben wir in Google Sheets und einer DB gearbeitet. Das heißt, wenn während des Entwicklungsprozesses Zeilen zur Übersetzung angezeigt wurden, haben wir sie auf ein Tablet kopiert und sie dann per Post an die Übersetzung gesendet. Als die Übersetzung fertig war, wurde sie manuell in die Datenbank eingefügt. Das einzige Plus dieser Lösung ist, dass Sie die Anwendung nicht neu verlegen müssen, um neue Zeilen zu sehen. Wenn die Übersetzungen jedoch einen Fehler enthalten, funktioniert das Zurücksetzen nicht. Kein Translation Memory, keine Glossare. Die Konsistenz der Übersetzungen wird durch die Blickmethode erreicht.
Erster Versuch
Die erste Version, die diesen Prozess automatisierte, sah folgendermaßen aus: Wenn ein Entwickler Zeilen hatte, fügte er diese einem neuen Zweig in einem speziellen Repository für Übersetzungen hinzu. Dann wurde in derselben Verzweigung eine Pipeline gestartet, die per API alle Diff-Zeilen zur Übersetzung sendete. Die Übersetzungen sollten zwar bereits in die Datenbank zurückkehren, die Zeilen von der externen Ressource konnten jedoch nicht über die API in die interne Datenbank geladen werden.
Was hat eine solche Integration gebracht? Es wurde ein Schritt entfernt, bei dem der technische Redakteur alles in einer Tabelle zusammenfassen, manuell senden und dann die empfangenen Übersetzungen nach Anwendung und Anzahl der Sprachen teilen muss. In diesem Fall wurden die Zeilen sofort zur Übersetzung im Rahmen eines gleichnamigen Projekts mit der Anwendung gesendet, für die sie bestimmt waren. Infolgedessen erhielt der technische Redakteur eine Reihe von Archiven für jede der Anwendungen, für die Arbeiten durchgeführt wurden. Dies reduzierte den Anteil der Handarbeit erheblich. Zusätzlich wurde der Translation Memory auf der Anbieterseite implementiert. Diese Lösung hatte jedoch auch eine Reihe von Nachteilen: Das Speichern von Zeilen in der Datenbank ermöglichte keine vollständige Zeilenverwaltung auf unserer Seite und implizierte nach wie vor einen großen Teil der manuellen Arbeit.
Schmerz und kontinuierliche Lokalisation
Die folgende Integration brachte den Entwicklern viel Leid. Es scheint mir, dass diejenigen, die es gefangen haben, immer noch ihre Augen bei dem Wort „Lokalisierung“ zucken. Dies war die erste Integration mit Serge und Smartcat.
Hier ist es wichtig zu sagen, was Serge und Smartcat sind.
Serge ist ein Dienstprogramm, das Git unterstützt. Sie weiß, wie sie die erforderlichen Zeilen aus dem Zweig erhält, sie zur Übersetzung sendet und dann die Übersetzung für dieselben Zeilen nur an denselben Zweig zurückgibt. Wir benötigen auch ein Plugin, das die API des CAT-Systems aufruft, in das wir übersetzen. Das Plugin sollte neue Zeilen von Serge erhalten und fertige Übersetzungen an Serge zurücksenden.
Smartcat ist ein CAT-System mit Unterstützung für Glossar, Translation Memory und Platzhalter. Außerdem aggregiert und vereinfacht Smartcat den Abwicklungsprozess mit Freiberuflern und unterstützt die Verbindung von Übersetzungsanbietern.
In diesem Schritt haben wir die Zeilen aus der Datenbank in das Projekt-Repository übertragen. Jetzt mussten die Zeichenfolgen direkt aus dem Anwendungsrepository gesendet und dorthin zurückgegeben werden.
Es wurde angenommen, dass dies so funktionieren würde: Der Entwickler weiß, aus welchem Zweig er seinen Feature-Zweig erstellt hat, und der Unterschied in den Ressourcendateien zwischen diesen beiden Zweigen ist genau das, was übersetzt werden muss. Wenn ein Entwickler eine Reihe von Zeilen für die Übersetzung hat, startet er einen Job in seiner Niederlassung mit der Serge-Konfiguration. Serge berechnet diff, extrahiert neue Zeilen, ruft das Plugin auf und sendet die Zeilen zur Übersetzung. Wenn die Übersetzungen fertig sind, ruft der Entwickler den folgenden Job auf: Er stellt die im vorherigen Schritt erstellte Serge-Instanz bereit, empfängt die fertigen Übersetzungen und schreibt sie in den Quellzweig.
Die Lösung erwies sich als instabil: Serge sollte nicht bei jedem Start der Pipeline von Grund auf neu bereitgestellt werden, die Entwickler wollten nicht über Unterschiede zwischen den Zweigen nachdenken, und das Smartcat-Plugin musste dringend aktualisiert und verbessert werden. Die Lieferung neuer Leitungen kann Stunden dauern. Und leider war es nicht immer erfolgreich.
Theoretisch wurden alle Phasen des Prozesses automatisiert. Tatsächlich dauerte die Wartung, die Berechnung des Diff vor dem Start der Pipeline und die Fehlerbehebung länger als die vollständige manuelle Ausführung derselben Aufgabe.
Licht am Ende des Tunnels
Bis August 2018 haben wir die aktuelle Version der Integration gestartet. Wir haben einen Lokalisierungsserver. Auf dem Server für jedes Repository befindet sich eine separate Instanz von Serge. Serge scannt alle Zweige im Repository, sendet neue Zeilen zur Übersetzung und schreibt fertige Übersetzungen an die ursprünglichen Zweige. In der aktuellen Integration ist alles schnell und stabil. Nach dem Erstellen eines Zweigs für Übersetzungen werden die Zeilen innerhalb von 5-6 Minuten in Smartcat angezeigt. Nach Bestätigung der Übertragungen erfolgt die Festschreibung auf ähnliche Weise innerhalb derselben 5-6 Minuten. Die Lieferzeit für Übersetzungen ist nur durch den menschlichen Faktor begrenzt: die Arbeitsbelastung der Übersetzer, die Unterschiede in den Zeitzonen usw.
In den folgenden Artikeln werde ich Ihnen erklären, wie Sie die Serge-Smartcat-Gitlab-Integration von Grund auf neu konfigurieren und wie wir verschiedene nicht standardmäßige Aufgaben gelöst haben.
Fortsetzung:
20 Projekte, 20 Sprachen, Frist gestern. Teil 220 Projekte, 20 Sprachen, Frist gestern. Teil 3