Blog

Systeme werden immer komplexer, die Innovationsgeschwindigkeit höher.

Pflichtenhefte schreiben, ein Projekt vom ersten Schritt bis zur finalen Software zu planen und einige Monate, manchmal Jahre zu entwickeln, bis das Produkt auf den Markt kommt, das geht in sehr vielen Anwendungsgebieten heute an der Realität und damit am Markt und Absatzchancen vorbei.

Aus diesen Gründen haben sich agile Ansätze zur Softwareentwicklung in den letzten Jahren immer mehr durchgesetzt. Es wird immer mehr vom Benutzer aus gedacht, geplant und entwickelt, anstatt „auf dem Reißbrett die, in der Theorie beste, technische Lösung für ein vermeintliches Problem“ zu planen.

Einer der Vorteile eines agilen Ansatzes sind die kurzen Phasen von der benutzter-zentrierten Beschreibung einer neuen, nützlichen Funktion in meinem Produkt, bis zur ersten Implementierung; die sogenannten Sprints.

Mit jeden Sprint, der eine Woche oder auch einen Monat dauern kann, werden dem Benutzer der Software neue Funktionen angeboten und diese Benutzer sind immer häufiger in vielen Ländern zu Hause.

Daher ist auch in der Softwarelokalisierung mehr Flexibilität notwendig.

Abläufe müssen verschlankt und automatisiert werden!

Genau hier setzt unser Produkt iLP an, unsere Lokalisierungsplattform.

Nahtlose Integration der Lokalisierung mit der Entwicklung und übersetzte Benutzeroberflächen quasi in Echtzeit.

Und so sieht das am Beispiel einer kleinen UI5-App konkret aus:

Eine Entwicklerin hat z.B. in Visual Studio Code (oder auch SAP Application Studio, was faktisch eine auf Visual Studio Code basierende Web IDE ist) ihren ersten Entwurf einer SAP Fiori-App gebaut und muss nun, zwei Tage vor Ende des Sprints, noch schnell die Lokalisierung planen und durchführen.

In einem View ist das Layout (1) definiert und ein paar Schaltflächen und Texte angelegt (2). Zur Anzeige der Texte hat die Entwicklerin die entsprechenden Schlüssel/Wert-Paare in i18n-Properties geschrieben (3). Auf Englisch, der geforderten Original- und Entwicklungssprache, sieht alles schick aus und funktioniert (4).

Nun bleibt nicht mehr viel Zeit, das neue Feature zur Genehmigung von Eingangsrechnungen für die Nutzer in den USA, Frankreich, Kanada und Deutschland auszurollen. Aber die Sprachen fehlen!

Schnell die letzten Änderungen ins Repositorys auf GitHub einchecken, damit per iLP die Lokalisierung umgesetzt werden kann.

Das entsprechende Projekt in iLP wird per Webhook über das Einchecken benachrichtigt und zieht sich die Änderungen in das Übersetzungsprojekt.

Hier können nun benötigte Sprachen hinzugefügt werden (2). Zudem sieht man, dass die zugrundeliegende i18n-Datei von der für die Sprache Englisch (en) an einer Stelle abweicht.

Dies wird geprüft und aktualisiert.

Sobald die gewünschten Sprachen hinzugefügt sind, wird (optional) eine automatische Übersetzung aus ggf. unterschiedlichen Quellen gestartet. Herangezogen werden andere Komponenten des gleichen oder anderer Projekte, sogenannte Übersetzungsspeicher (TMs) und verschieden MT Service (Machine Translation, maschinelle Übersetzung), wie z.B. DeepL oder der SAP Translation Hub.

Nach einer Nachbearbeitung durch professionelle Übersetzer, Lektoren oder anderer Experten (optional) werden die Übersetzungen regelmäßig im lokalen Repository persistiert. Daraufhin werden sie in das Remote-Repository der Entwicklerin eingecheckt.

Nachdem die Entwicklerin die Änderungen aus GitHub übernommen hat (1), sind die übersetzten i18n-Properties verfügbar (2) und die auf dem lokalen Webserver zum Testen laufenden Software zeigt nun nicht mehr die englischen, sondern die deutschen Texte auf der Benutzeroberfläche an (3).

Haben wir Ihr Interesse geweckt?

Kontaktieren Sie uns gerne für eine Demo!