Wenn Sie SAP-Fiori-Apps agil entwickeln, kann es schwierig sein, Raum für die Übersetzung zu schaffen. Sobald ein Release für eine App geliefert ist, möchten Ihre Entwicklungsteams bereits am neuen Release arbeiten. Übersetzer würden aber gern die Texte für das fertige Release bearbeiten, ohne dabei mit dem nächsten Release in Konflikt zu geraten. Und Benutzer erwarten, dass die Übersetzungen beim Testbeginn vorliegen.
Ort und Zeit für die Übersetzung
Um für eine SAP-Fiori-Anwendung Übersetzungen zu erstellen, brauchen Sie vor allem zwei Dinge: ein Zeitfenster, in dem die Übersetzung stattfinden kann, und ein Ort, von dem die Quelltexte abgerufen und an den die Zieltexte geschrieben werden. In manchen Projekten ist es möglich, vor der Auslieferung der App ein bis zwei Wochen einzuplanen und für die Dauer der Übersetzung im Entwicklungssystem die Entwicklungstätigkeiten auszusetzen. Vielleicht besteht sogar die Möglichkeit, ein eigenes SAP-System für die Übersetzung einzurichten. Aber für viele Unternehmen, die agile Projekte betreiben, ist das keine Option. Und das bedeutet wiederum, dass die Übersetzung einerseits zeitlich schwer unterzubringen ist, und andererseits keine stabile Umgebung da ist, in der Texte gelesen und geschrieben werden können.
In einem agilen Prozess beginnt Ihr Entwicklungsteam sofort nach der Lieferung eines App-Release mit der Arbeit am nächsten Release. Die verbleibende Zeit zwischen Lieferung und Produktivstart ist dem Integrationstest gewidmet. Eine Erweiterung des Zyklus um eine oder zwei Wochen, um einen Übersetzungsschritt einzuplanen, ist oft keine Option. Im besten Fall bedeutet das, dass die Übersetzung nach dem Beginn des Integrationstests stattfindet und dass die Übersetzungen für die Tester erst ein paar Tage nach Beginn des Testzeitraums verfügbar sind.
Enge Zeitfenster bei Fiori-Apps
Bei der herkömmlichen SAP-Übersetzung ist es im Prinzip nicht so schwer, das für die Übersetzung benötigte Zeitfenster zu minimieren: Sie fangen einfach etwas früher mit dem Übersetzungsprozess an. Und sobald die Entwicklung fertig ist, können Sie die restliche Übersetzungsarbeit sehr schnell abschließen, weil das meiste bereits fertig ist. Und die ganze Arbeit kann im Entwicklungssystem erfolgen. Das ist möglich, weil die Benutzeroberflächentexte im SAP-Backend in vielen einzelnen Objekten stecken, deren Texte alle separat von Übersetzern aufgerufen werden können, ohne dass das die parallel weiterlaufende Entwicklung beeinträchtigen würde.
Das heißt, bei der Übersetzung von Backend-Texten können Sie Entwicklung und Übersetzung zur selben Zeit und im selben System verorten. Bei SAP Fiori stecken die Texte jedoch in großen monolithischen Dateien in BSP-Applikationen, oft in nur einer oder zwei Dateien pro App. Diese Dateien müssen von den Entwicklern abgerufen und an die Übersetzer geschickt werden, was Zusatzaufwand verursacht und die Entwicklungsprozesse stört. Das bedeutet, dass Sie eine App wahrscheinlich erst in die Übersetzung schicken, wenn sie fertig ist, was wiederum heißt, dass Sie ein größeres Zeitfenster für die Übersetzung benötigen.
Wo lesen, wo schreiben?
Um die Sache noch weiter zu erschweren, ist auch der Ort, von dem die Quelltexte gelesen werden müssen, alles andere als offensichtlich. In den meisten Unternehmen werden SAP-Systemlandschaften um ein Entwicklungssystem, ein Testsystem und ein Produktivsystem herum aufgebaut. Stellen wir uns mal vor, wir haben auch noch ein Integrationssystem, auf das Anwendungsbenutzer zum Testen Zugriff haben, und ein Hotfix-System, in dem die im Produktivsystem auftretenden Fehler behoben werden. Welches System ist in einer solchen Landschaft das beste zum Lesen der Quelltexte und Schreiben der Zieltexte?
Das erste System, was einem dabei einfällt, ist das Entwicklungssystem. Aber sobald sich ein Release im Integrationstest befindet, wird das Entwicklungssystem bereits Änderungen enthalten, die nicht im Rahmen des aktuellen Release produktiv gehen werden und deshalb nicht in den Übersetzungsprozess gelangen sollen. Eine andere Möglichkeit ist das Integrationssystem, das die Quelltexte für das aktuelle Release enthält, aber dieses System kann nicht zur Auslieferung der Texte verwendet werden. Außerdem müssen die fertigen Übersetzungen am Ende auch in das Entwicklungssystem gelangen, damit sie wiederverwendet werden können, wenn die Übersetzung für das nächste Release beginnt.
Mehr Flexibilität mit i18n Translation Manager for SAP Fiori
Wie ich es in meinem Gast-Blogartikel für text&form beschrieben habe, können Sie mit i18n Translation Manager for SAP Fiori die Entwicklung und die Übersetzung entkoppeln. So können Sie jederzeit mit der Übersetzung beginnen, was bedeutet, dass die Übersetzer bei der Bearbeitung der Quelltexte aus dem Entwicklungssystem einen Vorsprung bekommen. Und Sie können die Übersetzungen in das Entwicklungssystem zurückschreiben, ohne weitere manuelle Schritte einführen zu müssen.
Auf diese Weise schaffen Sie es möglicherweise sogar, die Übersetzung vor dem Testbeginn abzuschließen. Aber was passiert, wenn ein Release im Entwicklungssystem fertig ist und in das Integrationssystem transportiert wird? Ab diesem Punkt sind die gültigen Quelltexte für dieses Release nur noch im Integrationssystem vorhanden. Und mögliche Korrekturen für diese Texte werden nur noch aus dem Hotfix-System und nicht aus dem Entwicklungssystem kommen. Hier bietet Ihnen i18n Translation Manager for SAP Fiori viel Flexibilität.
Schreiben in mehrere Systeme
Im neuesten Release von i18n Translation Manager for SAP Fiori können Sie Ihren Übersetzungsschnappschuss (Informationen dazu, wie Schnappschüsse im Wesentlichen funktionieren, finden Sie im Blogpost von letzter Woche.) basierend auf einem System erstellen, aber die Übersetzungen in beliebig viele Systeme zurückschreiben. Außerdem müssen Sie nicht unbedingt in das System zurückschreiben, auf dem der erstellte Schnappschuss basiert. Und für jedes System, in das Sie die Übersetzungen schreiben, können Sie entscheiden, ob die Änderungen in einem Transportauftrag erfasst werden sollen.
Im oben beschriebenen Szenario können Sie Ihren Schnappschuss vom Integrationssystem erstellen, d. h., Ihre Übersetzer bearbeiten die Texte für das aktuelle Release – genau die Texte, die später produktiv gehen. Wenn die Übersetzung fertig ist, können Sie die Übersetzungen in das Entwicklungssystem zurückschreiben, die Änderungen in einem Transportauftrag erfassen und gleichzeitig die Änderungen an das Git-Repository für jede App übergeben. Auf diese Weise wird dafür gesorgt, dass die Übersetzungen für das nächste Release erhalten bleiben. Des Weiteren können Sie das Integrationssystem mit Ihren Übersetzungen aktualisieren (natürlich ohne einen Transportauftrag zu schreiben), damit die Tester die zielsprachlichen Texte anzeigen und testen können. Diesen Prozess können Sie beliebig oft wiederholen.
Integrierte Flexibilität
Damit die Übersetzungen ins Produktivsystem kommen, reicht es jedoch nicht, dass Sie sie in das Entwicklungssystem schreiben, da für das aktuelle Release keine Änderungen aus der Entwicklung mehr in das Integrations- bzw. Produktivsystem gelangen. Dafür versorgt das Hotfix-System das Integrations- bzw. das Produktivsystem für das aktuelle Release. Hier beheben Entwickler Fehler, die beim Integrationstest festgestellt werden – und hierher können Sie auch die Übersetzungen schreiben, die produktiv gehen sollen. Neben der Aktualisierung des Entwicklungs- und des Integrationssystems schreiben Sie mit i18n Translation Manager also auch in das Hotfix-System und generieren dabei den Transportauftrag, der für den Transport in das Produktivsystem sorgt.
Diese Art von Flexibilität erlaubt die Unterstützung der meisten Workflows in fast jeder SAP-Systemlandschaft. Ob Sie nur basierend auf Ihrem Entwicklungssystem übersetzen möchten oder ob sich die Übersetzung in einen komplexen Prozess über mehrere SAP-Systeme hinweg einfügen muss, i18n Translation Manager for SAP Fiori passt sich Ihren Anforderungen an.
Erfahren Sie mehr über unsere SAP-Übersetzungstools…