Lokalisierung großer und agiler Software: Fallstudie Kaspersky

Die Leitung der Lokalisierungsbemühungen eines großen Softwareunternehmens ist an sich schon eine Herausforderung. Was passiert, wenn dieses Unternehmen auf agile Praktiken umstellt? Nun, die Herausforderungen werden noch größer, und man muss schnell drastische Veränderungen umsetzen. In dieser Fallstudie Ekaterina Galitskaya und Darya Egorushkina vom Dokumentations- und Lokalisierungsteam von Kaspersky berichten über ihre Erfahrungen mit der Steigerung der Kapazitäten und Effizienz ihrer Prozesse mit Smartcat.

Weiterer Text von Ekaterina & Darya

Unser Team ist für das Verfassen und Lokalisieren von UI-Texten und Hilfe-Center-Artikeln für die mobilen Sicherheits-Apps des Unternehmens verantwortlich. Im Folgenden erzählen wir Ihnen, wie wir damit begonnen haben, Mobile Security-Apps auf zuverlässigere, agilere und automatisierte Weise zu lokalisieren. Wir beginnen mit den Problemen, die uns dazu veranlasst haben, überhaupt etwas zu ändern, und führen Sie durch die Herausforderungen, denen wir gegenüberstanden, und die Lösungen, die wir gefunden haben. Wir hoffen, dass dieser Artikel für alle mittelständischen bis großen Softwareunternehmen interessant ist, die vor der Herausforderung stehen, Agile nicht nur in ihrer Entwicklung, sondern auch in allen damit verbundenen Bereichen zu implementieren.

Wie viele andere Unternehmen hatte auch Kaspersky irgendwann auf agile Entwicklungsmethoden umgestellt. Dies führte natürlich zu deutlich kürzeren Release-Zyklen. Während wir zuvor alle paar Monate neue App-Versionen herausbrachten, war dies nun alle zwei Wochen der Fall. Zwar gab es nun weniger Strings in jedem neuen Release, aber das half nicht viel: Wir mussten diese wenigen Strings weiterhin unserem gesamten Lokalisierungs- und Linguistik-Testprozess unterziehen, während wir gleichzeitig mit viel engeren Fristen konfrontiert waren.

Es gibt auch ein weit verbreitetes Missverständnis, dass mobile Apps nur eine geringe Menge an Text enthalten. Das wäre schön! In unserem Fall hatten wir beispielsweise durchschnittlich ~25.000 Wörter pro App allein für die UI-Texte, multipliziert mit ~10 Apps und ~20 Zielsprachen für jede App. Und dazu kamen jede Woche neue UI- und Dokumentationstexte hinzu.

Infolgedessen wurde die Lokalisierung im Wesentlichen zum Engpass im gesamten Release-Rollout-Prozess. Und wenn Produktmanager zuvor nicht einmal die Namen der Mitglieder des Lokalisierungsteams kannten – warum sollten sie auch, wenn alle Übersetzungen wie „von Zauberhand“ erschienen? –, so waren sie sich nun aller damit verbundenen Probleme auf einer viel tieferen Ebene bewusst, als ihnen lieb war.

Bei Kaspersky umfasst der Lokalisierungsprozess in der Regel zwei Phasen: die Übersetzung und die linguistische Prüfung.

Das allgemeine Problem in der Übersetzungsphase bestand darin, dass aufgrund des verwendeten Prozesses und der Einschränkungen des CAT-Tools zu viel manuelle Arbeit erforderlich war. Im Einzelnen:

• Da Multibranch-Pipelines nicht unterstützt wurden, mussten wir die Deltas für die Übersetzung manuell erstellen und sie später wieder in die Branches zurückschreiben.

• Es war unmöglich, die Konsistenz zwischen den Apps und Sprachen sicherzustellen.

• Wir konnten zusätzliche angeforderte Übersetzungen nicht parallel durchführen, z. B. wenn die Quelltexte während des Prozesses geändert wurden. Stattdessen mussten wir warten, bis das grundlegende Übersetzungspaket fertig war, und konnten erst dann mit den zusätzlichen Übersetzungen fortfahren.

• Build-Fehler aufgrund von Fehlern in „nicht übersetzbaren Elementen”, nicht maskierten Apostrophen und anderen menschlichen Fehlern wurden zunehmend zu einem Problem.

Die Phase der linguistischen Prüfung kann bis zu zwei Wochen dauern, verglichen mit den drei bis fünf Tagen, die die eigentliche Übersetzung in Anspruch genommen hat. „Was um alles in der Welt ist eine linguistische Prüfung?“, fragen Sie sich jetzt vielleicht.

Der Hauptzweck von Sprachprüfungen besteht darin, die gesamte Übersetzung im Kontext zu überprüfen. Wir verfügen über ein solides Team von Übersetzern, die mit unserer Terminologie bestens vertraut sind. Wenn man jedoch einen Text übersetzt, ohne zu sehen, in welchem Kontext er steht, oder ohne zu wissen, ob es sich um eine Schaltfläche oder eine Überschrift handelt, kann es schnell zu Fehlern kommen.

Bei der sprachlichen Prüfung werden also alle resultierenden App-Bildschirme manuell überprüft, in der Regel anhand von Screenshots. Dies hilft dabei, Probleme zu identifizieren, wie beispielsweise

• Der Text ist zu lang für die Größe des Bildschirmelements. Manchmal kann dies rechtliche Konsequenzen haben, wenn der ausgelassene Text Haftungsausschlüsse oder Finanzinformationen enthält.

• Text, der nicht übersetzt wurde, entweder weil der Übersetzer einen Fehler gemacht hat oder weil er fest codiert und nicht als string externalisiert wurde,

• Text, der im falschen Kontext übersetzt wurde, z. B. wenn der Text auf einer Schaltfläche – z. B. „Download“ – grammatikalisch ein Imperativ statt eines Infinitivs ist.

Allein das Erstellen der Screenshots nahm enorm viel Zeit in Anspruch. Wenn beispielsweise eine neue Funktion 40 UI-Bildschirme umfasste und es 20 Zielsprachen gab, konnte dies bis zu 70 Stunden manueller, mechanischer Routinearbeit erfordern.

Insgesamt war dies etwas, womit man leben konnte, wenn alle drei Monate eine neue Version herauskam. Aber bei zweiwöchentlichen Veröffentlichungen begann dies, dem Lokalisierungsteam zuzusetzen. Das Problem musste behoben werden, und zwar schnell.

1. Weniger erfahrene Mitarbeiter einstellen und den Umfang der Lokalisierungsarbeiten reduzieren – was natürlich zu einem Qualitätsverlust führt, ODER
2. Automatisieren.

Wir haben uns für Letzteres entschieden.

Bei der Auswahl der CAT/TMS-Lösung standen für uns folgende Punkte im Vordergrund:

1. Weniger interne Freigaben – Genehmigung von Budgets, Generierung von Serienschlüsseln und all das

2. Sofort einsatzbereite Grundfunktionen – damit wir sofort loslegen konnten, ohne auf die Entwicklung weiterer Funktionen warten zu müssen,

3. Geringe Serveranforderungen – auch hier wieder, um langwierige Genehmigungsprozesse zu vermeiden,

4. Erschwinglicher, vorzugsweise kostenloser Zugang zum Service.

5. Angemessener Support auf Seiten des Dienstes, damit wir keinen internen Entwickler einstellen müssen,

6. Sicherheitsanforderungen – wir verbinden uns mit dem Dienst und nicht umgekehrt,

7. Unterstützung mehrerer Zweige – um mehrere Funktionen parallel zu übersetzen,

8. Zusätzliche Übersetzungen parallel zum ursprünglichen Stapel möglich.

Als wir eine Auswahlliste mit Optionen zusammengestellt haben, blieben am Ende nur zwei Namen übrig: Smartcat und Zing, ein Server für kontinuierliche Lokalisierung von den Entwicklern von Evernote.

Wir mochten Zing wegen seiner Anpassungsfähigkeit, dem kostenlosen Installationspaket und dem privaten Zugriff – wir konnten es innerhalb unserer eigenen Organisation hosten. Der Nachteil war, dass der Installationsprozess alles andere als einfach war, sodass die Einarbeitung all unserer Übersetzer und Mitarbeiter den Zeitaufwand für den Betrieb des Dienstes zu hoch gemacht hätte.

Also entschieden wir uns für Smartcat. Da wir CAT-Tools nicht direkt mit unserem internen VCS verbinden dürfen, entschieden wir uns für ein Smartcat–Serge-Bundle. (Serge ist eine Open-Source-Software, die Strings zwischen Versionskontroll- und Übersetzungsmanagementsystemen synchronisiert. Sie identifiziert Strings in Dateien verschiedener Formate und konvertiert sie in das branchenübliche PO-Format, das dann an Smartcat weitergeleitet wird. Wir können es direkt auf unseren Servern installieren, sodass keine unserer vertraulichen Informationen nach außen gelangt.)

Das hat uns an der resultierenden Lösung am besten gefallen:

• Sie erfüllt alle unsere Anforderungen: Multibranch-Pipelines, zusätzliche Übersetzungen, Sicherheit usw.

• Wir erhalten Updates in Echtzeit, ohne etwas herunterladen oder installieren zu müssen.

• Dank des Smartcat–Serge-Bundles können wir unsere eigenen Parsing-Schemas für Strings erstellen.

• Wir können mit den Übersetzern, die an unseren Dokumenten arbeiten, kommunizieren, ohne die Plattform verlassen zu müssen.

Wir können Freiberuflerp>

• Wir können Freiberufler direkt auf dem Marktplatz der Plattform finden, wenn wir jemals die Produktion steigern müssen.

• Wir können alle Sprachen und Projekte mit nur einer Rechnung bezahlen.

• Wir lieben den Support, den wir bekommen – das Team von Smartcat hat uns dabei geholfen, unseren Workflow zum Laufen zu bringen, und einige der für uns wichtigen Funktionen priorisiert.

• Der Service ist praktisch kostenlos – wir haben uns letztendlich aufgrund der projektweiten Textsuchfunktion für ein Abonnement entschieden, aber dieser Schritt war optional.

Einige der Herausforderungen, denen wir gegenüberstanden, waren:

• Anfangs konnten wir nicht innerhalb aller Dokumente eines Projekts nach Text suchen – dies ist nun kein Problem mehr, da Smartcat diese Funktion inzwischen implementiert hat.

• Freiberufler übersehen oder ignorieren manchmal Benachrichtigungen, dass ein Projektdokument aktualisiert wurde, sodass wir ihnen manuell über den integrierten Chat Erinnerungen senden müssen.

• Der Projektmanager muss Einladungen an Übersetzer manuell versenden – wir haben jedoch gehört, dass dieser Schritt bald automatisiert werden soll.

Angesichts unserer bisherigen Erfahrungen mit Smartcat sind wir zuversichtlich, dass das Team bereits daran arbeitet, diese Probleme zu beheben.

Um die Dinge ins rechte Licht zu rücken, hier ein Vergleich zwischen dem, was wir hatten, und dem, was wir jetzt haben, sowohl in Bezug auf den Prozess als auch auf die Zahlen.

Vorher

Vor den Änderungen mussten wir fast 30 Schritte in den Übersetzungs- und Sprachprüfungsphasen durchlaufen:

Übersetzung:

1. Texte aus verschiedenen Zweigen im Repository manuell extrahieren,

2. ein Delta für die Übersetzung manuell erstellen,

3. Pakete für die Übersetzung erstellen,

4. Laden Sie diese auf einen FTP-Server hoch,

5. Schreiben Sie eine Menge E-Mails an Agenturen, Freiberufler oder lokale Büros,

6. Laden Sie die fertige Übersetzung vom FTP-Server herunter,

7. Laden Sie sie in das CAT-Tool und stellen Sie sicher, dass alles in Ordnung ist,

8. die übersetzten Strings manuell in das Repository hochladen und dabei darauf achten, dass die Branches nicht durcheinander geraten,

9. einen Build ausführen, Fehler beheben, den Build abschließen,

10. zusätzliche Übersetzungen anfordern – im Wesentlichen also denselben Vorgang erneut wiederholen.

Sprachliche Tests:

1. Starten Sie den Build und warten Sie, bis er abgeschlossen ist.

2. Starten Sie den Build neu, wenn er aufgrund von Lokalisierungsfehlern fehlgeschlagen ist.

3. Konfigurieren Sie eine spezielle Testumgebung, wenn kein Debug-Menü vorhanden ist.

4. Erstellen Sie alle relevanten Screenshots für mehr als 20 Sprachen.

5. Finden Sie gemeinsam mit dem QA-Team heraus, wie Sie die noch fehlenden Screenshots erhalten können.

6. Erstellen und benennen Sie Screenshot-Pakete.

7. Laden Sie diese auf den FTP-Server hoch.

8. Weisen Sie Übersetzungsagenturen Aufgaben zu, um die Übersetzungen zu überprüfen.

9. Beantworten Sie die Fragen der Agenturen,

10. Nehmen Sie die Aufgaben an und nehmen Sie die Änderungen vor,

11. Führen Sie den Build durch – was manchmal lange dauert,

12. Wiederholen Sie den Build, wenn Fehler aufgetreten sind,

13. Erstellen Sie Screenshots für Regressionstests,

14. Erneut Screenshots hochladen und den Übersetzungsagenturen Aufgaben zuweisen,

15. Erneut alles mit den Agenturen besprechen,

16. Erneut eine weitere Runde Regressionstests durchführen, wenn es Änderungen an den Übersetzungen gab.

Nachher

Jetzt haben wir nur noch neun Schritte über alle Phasen hinweg:

1. Der Texter überträgt neue Strings in Git. Serge speist die Strings automatisch in Smartcat ein.

2. Der Lokalisierungsprojektmanager weist Übersetzer zu.

3. Die Übersetzer übersetzen im Kontext – mit Screenshots und Kommentaren, die ihnen zur Verfügung stehen.

4. Der Lokalisierungsprojektmanager überprüft und bestätigt die Übersetzung, die dann automatisch wieder in Git zurückgeführt wird.

5. Das Lokalisierungsteam führt den Feature-Screenshot-Bot für lokalisierte Texte aus.

6. Das Lokalisierungsteam speichert die lokalisierten Screenshots auf dem FTP-Server und sendet sie an die Linguisten.

7. Die Linguisten überprüfen die Übersetzungen und korrigieren sie bei Bedarf, während sie sich die lokalisierten Screenshots ansehen.

8. Die Änderungen werden automatisch an Git weitergeleitet.

9. Das Lokalisierungsteam schließt die Pull-Anfrage.

Das war's schon – mit dieser dreifachen Reduzierung der Komplexität spüren wir wirklich den Unterschied zu früher!

Alle Zahlen beziehen sich auf eine Veröffentlichung – alle zwei Wochen – und auf eine App.

Weitere Vorteile – von denen wir einige nicht erwartet hatten – sind unter anderem:

• Zuverlässigere Builds: Dank Platzhaltern müssen wir uns keine Sorgen mehr darüber machen, dass nicht übersetzbarer Text übersetzt wird oder Apostrophe nicht maskiert werden usw.

• Smartcat hat dank seiner Einstellungen für kritische Fehler einige ältere Fehler identifiziert.

• Keine Verschwendung der Zeit und Ressourcen anderer: Wir müssen keine Testgeräte vom QA-Team ausleihen oder die Zeit des Entwicklerteams für Screenshots in Anspruch nehmen.

• Screenshots für Übersetzer verfügbar, die sie ganz einfach direkt im Editor öffnen und anzeigen können, haben die Qualität der Übersetzungen erheblich verbessert.

Wir könnten noch weitermachen und sind sicher, dass wir mit der Zeit weitere Möglichkeiten finden werden, um sowohl die Effizienz als auch die Qualität unserer Lokalisierungsprozesse zu verbessern. Das Wichtigste ist, dass die Lokalisierung nun kein Engpass mehr im Release-Zyklus ist. Wir glauben, dass es sowohl für unser Team als auch für die Smartcat-Plattform eine Meisterleistung war, diese Ergebnisse in so kurzer Zeit zu erzielen.

Hier sind einige konkrete Schritte, die wir nach der Implementierung von Smartcat unternommen haben. Wir stellen sie hier als „Spickzettel” für andere Unternehmen und Teams zur Verfügung, die unserem Beispiel folgen möchten. Nicht alle sind einfach umzusetzen, aber die meisten tragen dazu bei, den Lokalisierungsprozess reibungsloser und weniger fehleranfällig zu gestalten.

Integration:

• Testen Sie die Integration von Git–Serge–Smartcat, um sicherzustellen, dass alle Strings in Smartcat-Projekte und zurück übertragen werden. Sie möchten schließlich keine Überraschungen in der Produktionsphase erleben.

• Vereinbaren Sie mit den Softwareentwicklern eine einheitliche Benennung der Branches. Auf diese Weise können Sie einen Bot einrichten, der nach den spezifischen Branches sucht, die lokalisiert werden müssen – das spart Ihnen und den Entwicklern viele Stunden an Kommunikationszeit.

• . Wir haben beispielsweise String-IDs, Kommentare und Links zu Referenz-Screenshots für Übersetzer sichtbar gemacht.

• gemäß der oben vereinbarten Namensmaske zu finden.

• Erwägen Sie UI-Tests und Screenshots von Funktionen mit dem Kaspresso-Framework. Unsere Entwickler fügen beispielsweise für jede von ihnen verwendete Zeichenfolge einen Link zu einem Screenshot ein. Wenn die Datei zu Smartcat gelangt, wird der Screenshot-Link automatisch in die Registerkarte „Kommentare” eingefügt. Weitere Informationen zu Kaspresso und warum Sie es verwenden sollten, finden Sie unter hier erfahren.

Lokalisierung und sprachliche Prüfung:

• Wenn Sie über Glossare verfügen, laden Sie diese in Smartcat hoch, um die Konsistenz Ihrer Lokalisierungen sicherzustellen.

• Fügen Sie Ihre internen Linguisten hinzu, damit diese die Plattform erkunden und sich einarbeiten können, bevor sie von Ihnen tatsächlich Aufträge erhalten.

• Finden und wählen Sie Freiberufler aus und weisen Sie sie in die Prozesse Ihres Unternehmens ein, damit sie wissen, wie sie Screenshots, Kommentare, Glossare usw. verwenden können.

• Finden Sie bei Bedarf Übersetzungsagenturen für zusätzliche Lokalisierungs- oder Testanforderungen.

Wir hoffen, dass diese Tipps hilfreich waren – lassen Sie uns wissen, wenn Sie selbst welche haben!