Über unsMediaKontaktImpressum
Adriano Raiano 05. November 2019

Continuous Deployment: Was kann ein Translation-Management-System?

Durch das Einführen von Continuous Deployment, also die automatische Überführung von Änderungen in die Produktion, kommt man zu schnelleren Releases und einer höheren Qualität – dies ist eines der Hauptversprechen von Continuous Deployment. Doch die Praxis zeigt, dass all zu oft die Produktion nicht freigegeben werden kann. Es gibt einen oft unterschätzten Verursacher für das nicht gelebte Continuous-Deployment-Versprechen. In diesem Artikel werden wir dem auf dem Grund gehen.

Wer ist der Verdächtige?

Man kann es kaum glauben, aber wenn man ein internationales Software-System entwickelt, ist dies ein Akteur, welcher dem Continuous Deployment häufig einen Strich durch die Rechnung macht. Der unterschätzte Verursacher ist der Lokalisierungsprozess, vereinfacht gesagt, die Übersetzungsarbeit.

Umfeld

Aber wie bettet sich diese Lokalisierung ein? Und was ist das genau?

GILT: g11n + i18n + l10n + t9n

g11n, i18n, l10n und t9n sind sogenannte Numeronyme [1] und stehen für:

  • Globalisierung (g11n) – Globalisierung ist der Überbegriff für das Entwickeln, Herstellen und Vermarkten einer Anwendung (Software, Webseite usw.), welche für die weltweite Verbreitung bestimmt ist.
  • Internationalisierung (i18n)– Technisch beginnt es mit der Internationalisierung. Man muss die Software so gestallten, dass sie ohne Quellcode-Änderung an andere Sprachen und Kulturen angepasst werden kann [2].
  • Lokalisierung (l10n) – Lokalisierung steht in der Softwareentwicklung für die Anpassung von Inhalten (z. B. Websites), Prozessen, Produkten und insbesondere Computerprogrammen (Software), an die in einem bestimmten geographisch oder ethnisch umschriebenen Absatz- oder Nutzungsgebiet (Land, Region oder ethnische Gruppe) vorherrschenden lokalen sprachlichen und kulturellen Gegebenheiten [3].
  • Effektive Übersetzung (t9n) – Die Übersetzung ist die Übertragung der "Bedeutung" eines Textes in einer Ausgangssprache in eine Zielsprache.

Vergangene Zeiten

In der Vergangenheit haben die meisten Software-Unternehmen ihre Produkte in einjährigen oder sogar mehrjährigen Zyklen geplant, entwickelt und veröffentlicht – Der typische Wasserfallprozess.

Jedes Mal, wenn das Entwicklerteam die Implementierung der Funktionen abgeschlossen hatte, konnte der Produktmanager den Übersetzungsprozess organisieren und initiieren. Das einzige, was die Entwickler garantieren mussten, war das Exportieren und Importieren von Textressourcen. Auf diese Weise konnten die Texte alle zusammen übersetzt werden, indem sie an verschiedene Übersetzungsagenturen oder regionale Marktorganisationen usw. gesendet wurden. Sobald die Übersetzungen fertiggestellt wurden (nach Tagen, Wochen oder sogar Monaten), wurden sie an den Produktmanager zurückgeschickt, welcher sie an die Entwickler weiterleitete. Anschließend wurden die neuen Übersetzungen übernommen, importiert, in das Produkt integriert und (erneut) freigegeben. Es hat mit diesem Prozess mehr oder weniger funktioniert, aber es war alles sehr statisch und langwierig.

Status Quo

Wie schon zu Beginn angedeutet, versuchen die meisten Organisationen heutzutage, den Entwicklungsprozess auf einen agileren Ansatz umzustellen. Durch das Offerieren von mehr und mehr SaaS-Produkten beginnen die heutigen Unternehmen mit der Einführung von Continuous-Deployment-Pipelines.

Die Entwickler konzentrieren sich auf die Instrumentierung des Quellcodes mit Hilfe einiger i18n-Bibliotheken:

  • i18next bietet nicht nur die Standardfunktionen von i18n (Pluralisierung, Kontext, Interpolation, Formattierung). Es bietet eine Komplettlösung für die Lokalisierung von Softwareprodukten von Web über Mobilgeräte bis hin zum Desktop [4].
  • FormatJS ist eine modulare Sammlung von JavaScript-Bibliotheken für die Internationalisierung, die sich auf die Formatierung von Zahlen, Datumsangaben und Zeichenfolgen für die Anzeige für Benutzer konzentrieren. Es enthält eine Reihe von Bibliotheken, die auf den integrierten JavaScript-Funktionen und branchenweiten i18n-Standards aufbauen, sowie eine Reihe von Integrationen für allgemeine Vorlagen- und Komponentenbibliotheken [5].
  • Polyglot.js ist eine kleine i18n-Hilfsbibliothek, die in JavaScript geschrieben wurde und sowohl im Browser als auch in CommonJS-Umgebungen (Node) funktioniert [6].
  • Globalizejs.com – Eine JavaScript-Bibliothek für die Internationalisierung und Lokalisierung, welche die offiziellen Unicode-CLDR-JSON-Daten nutzt. Die Bibliothek funktioniert sowohl für den Browser als auch als Node.js-Modul [7].

Die Texte werden in Ressourcendateien extrahiert, damit sie später von jemandem übersetzt werden können. Normalerweise bleibt während einer Entwicklungs-Iteration oder eines Sprints keine Zeit, die Ressourcen zu übersetzen, und das nicht nur, weil die meisten Leute die Einstellung haben:

Der Übersetzungsprozess selbst interessiert uns nicht!

Aus diesem Grund entscheiden sich einige Organisationen dafür, dem Prozess einen zusätzlichen Schritt hinzuzufügen, in welchem keine Textressource mehr hinzugefügt, bearbeitet oder gelöscht wird. Diese "Einfrier"-Phase gibt technischen Redakteuren und Übersetzern die notwendige Zeit, um an den Texten zu arbeiten. Je mehr Text verarbeitet werden muss, desto länger ist dieser Zeitraum. Dieser Prozess verlangsamt die Freigabe der Software in allen Sprachen erheblich und führt dazu, dass kein Continuous Deployment durchgeführt wird.

Vollständiges Continuous Deployment mit Continuous Localization

Automatisieren, separieren, unterbrechungsfrei – Dies sind einige der Erfolgsfaktoren für eine gut gelebte Continuous-Deployment-Pipeline [8]. Wieso dann nicht diese Erfolgsfaktoren auch auf den Lokalisierungsprozess übernehmen? Das Ganze heißt Continuous Localization: Die Softwareentwicklung hört nie auf, wenn die erste Version eines Produkts veröffentlicht wird (Fehlerkorrekturen, kleinere Updates und irgendwann größere Versionen und Releases). Das magische Wort heißt "kontinuierlich" (continuous).

Der Lokalisierungs- und Übersetzungsprozess sollte dem Muster der agilen Softwareentwicklung entsprechen. Er sollte in der Lage sein, die Übersetzungsdateien getrennt von der Software bereitzustellen, damit sie unabhängig aktualisiert und verwaltet werden können. Wer diesen Weg beschreiten möchte, muss sicherstellen, dass mehr als eine Version der Übersetzungen existieren muss. Mindestens eine für die aktuell veröffentlichte Version und eine für den aktuellen Entwicklungsstand. Auf diese Weise können sich die technischen Redakteure und Übersetzer vom ersten Tag an um die Übersetzungen kümmern und mit den Software-Änderungen Schritt halten.

Und so ist es sogar möglich, Übersetzungen zu ändern oder hinzuzufügen, ohne eine neue Version der Software auszuliefern! So etwas nennt sich Translation-Management-System.

Translation-Management-System

Ein zusätzliches Tool und eine zusätzliche Bereitstellung – erhöht das nicht nur die Komplexität und den Aufwand? Es gibt sehr viele verschiedene Translation-Management-Systeme auf dem Markt. In diesem Fall suchen wir aber nach spezifischen Lösungen, welche Continuous Localization ermöglichen.

Mit Continuous Localization wird automatisch und nahtlos neues Quellmaterial erfasst, zur Übersetzung veröffentlicht, übersetzt und wieder in die Software integriert. Letztendlich macht es das manuelle Lokalisierungsmanagement überflüssig – Exportieren, Konvertieren von Dateien, Versenden zur Übersetzung, Rückwärtskonvertieren und Festschreiben von Änderungen an der Versionskontrolle.

Um diese zu erreichen gibt es verschiedene Ansätze.

Import/Export API

Dieser ist der am häufigsten anzutreffende Ansatz: Über ein API kann neues Quellmaterial importiert und auch wieder exportiert werden, um wieder in die Software integriert zu werden. Die APIs können sehr unterschiedlich aussehen, bei manchen ist man auf das Nötigste limitiert und bei anderen wird man sogar mit Webhook-Events notifiziert. Das heißt, ein Enwickler muss ein bisschen Quellcode schreiben und dieses API in die CI/CD-Pipeline integrieren. Ein typisches Translation-Management-System für diesen Ansatz ist Phrase[9].

Integration in die Versionskontrolle

Dieser Ansatz ist für Entwickler bereits ein bisschen angenehmer. Es wird "direkter" in die Versionskontrolle integriert. Entweder mit einem zur Verfügung stehenden Kommandozeilentool oder beispielsweise mit einer tieferen GIT-Integration [10]. Solch eine GIT-Integration verfolgt Änderungen in dem Repository der Versionskontrolle und zieht sie in das Lokalisierungs-Projekt. Übersetzte Dateien werden per Pull-Request wieder mit dem Repository synchronisiert. Ein typisches Translation Management System für diesen Ansatz ist Gitlocalize[11].

Komplette Entkopplung der Texte

Ein noch disruptiverer Ansatz verfolgt das Ziel, alle Texte komplett aus der eigenen Software zu entfernen. Hierzu instrumentieren die Entwickler ihren Quellcode, um neue und fehlende Texte direkt (sogar während der Entwicklung) in das Translation-Management-System zu übertragen. Die fertigen Texte werden dann über ein CDN (Content Delivery Network) [12] bereitgestellt und direkt von der Software benutzt. Die Entwickler haben nach dem einmaligen Instrumentieren des Quellcodes bezüglich Lokalisierung eigentlich nichts mehr zu tun. Alles passiert automatisch.

Egal ob neue Features entwickelt werden oder die Produktmanager eine neue Sprache hinzufügen möchten – alles kann direkt im Translation-Management-System gemacht werden. Die Entwickler können sich viel besser auf das konzentrieren was ihre Hauptaufgabe ist. Während die Übersetzer, Redakteure und Produktmanager selbständig an der Lokalisierung arbeiten können. Ein typisches Translation-Management-System für diesen Ansatz ist: Locize[13].

Zusammenfassung

Der größte Fehler, den man machen kann, ist zu glauben, dass Lokalisierung nur aus der Instrumentierung des Quellcodes und dem Extrahieren von Textdateien besteht. Man sollte hingegen die guten Erfolgsfaktoren aus der agilen Softwareentwicklung zu Rate ziehen und den Lokalisierungsprozess frühzeitig in die Continuous-Deployment-Pipeline aufnehmen.

Es wird Zeit, sich von langwierigen Wasserfallprozessen und zurückgehaltenen Freigaben etc. zu verabschieden und Continuous Localization willkommen zu heißen. Somit wird die Lücke zwischen Übersetzung und Entwicklung erfolgreich geschlossen.

Autor

Adriano Raiano

Adriano Raiano hat mehr als zehn Jahre Erfahrung als Software-/System-Architekt und Lead-Entwickler im Cloud- und IoT-Umfeld. Sein technologischer Schwerpunkt liegt auf modernen Architektur- und Technologieansätzen.
>> Weiterlesen
Das könnte Sie auch interessieren
botMessage_toctoc_comments_9210