Seit wir beim i18n Translation Manager 2.0 die Funktion „Automatic Scoping“ eingeführt haben, hat sich vieles geändert. Das Tool kann jetzt die Backend-Komponenten von mehr Arten von Apps analysieren und unterstützt die Analyse von SAP-Standard-Apps. Hier kommt ein kurzer Überblick über die aktuellen Möglichkeiten des Tools beim Analysieren von Fiori-Apps.
Der aktuelle Stand beim automatischen Scoping
i18n Translation Manager for SAP Fiori ist – soweit wir wissen – aktuell das einzige Tool auf dem Markt, mit dem die Kunden von SAP einen vollständigen End-to-End-Workflow für die Übersetzung von Fiori-Apps umsetzen können. Von Beginn an war es damit möglich, den Übersetzungsprozess für Frontend- und Backend-Texte zu vereinen. Texte aus den i18n.properties-Dateien und Fiori-Kacheln können auf dieselbe Weise übersetzt werden wie Domänenwerte oder Texte aus Tabellen, die von der App in Dropdown-Listen angezeigt werden, um nur ein Beispiel zu nennen. Das macht i18n Translation Manager zum besten SAP-Übersetzungstool für jeden, dessen SAP-S/4HANA-Implementierung die Übersetzung von mehr als einer oder zwei Fiori-Apps erforderlich macht.
Die Idee hinter der Funktion „Automatic Scoping“, die wir Anfang 2021 eingeführt haben, war Folgende: Um tatsächlich alle Texte zu übersetzen, die die App auf ihrer Benutzeroberfläche anzeigt, müssen Sie alle von einer Fiori-App verwendeten Objekte und die mit ihnen verbundenen Texte identifizieren. Manuell stellt dies eine Herkulesaufgabe dar. Also haben wir diese Aufgabe automatisiert. Auf der Benutzeroberfläche von i18n Translation Manager wird automatische Scoping mit einem einzigen Ankreuzfeld abgebildet – Von BSP-Applikationen und Gateway-Services genutzte Backend-Objekte hinzufügen. Aber hinter diesem Ankreuzfeld stecken ziemlich komplexe Analysetools, die das gesamte Backend von Fiori-Apps scannen und alle von den Apps verwendeten Texte erfassen. Obschon klar ist, dass kein automatischer Prozess 100 % der Texte wird ermittelt können, die auf der Benutzeroberfläche von SAP-Fiori-Apps angezeigt werden, sind 95 % – ohne manuelle Arbeit – ein guter Ausgangswert. Und genau das tut i18n Translation Manager. Dieser Blogpost liefert einen kurzen Überblick über die häufigsten Anwendungsfälle, d. h. die gängigsten Arten von App-Implementierungen.
Auf Gateway-Builder-Projekten basierende Apps
Als wir die Funktion „Automatic Scoping“ eingeführt haben, haben wir zunächst nur den vielleicht schwierigsten Anwendungsfall unterstützt. Auf SAP-Gateway-Builder-Projekten (Transaktion SEGW) basierende Apps gehören zu den komplexesten eigenentwickelten Fiori-Apps. Neben den i18n.properties-Dateien, die im Frontend verwendet werden, um in denen die Mehrzahl der Texte abgelegt sind, können diese Arten von Apps Texte nutzen, die im Gateway-Builder-Projekt selbst gespeichert werden, sowie alle Texte, die über die Projektimplementierung aus dem Backend aufgerufen werden. Das heißt, wir sprechen von Textelementen aus Klassen, Domänenwerten und beinahe allen anderen ABAP-Dictionary-Objekten wie Tabellen oder Datenelementen. Die automatisierte Scoping erfasst alle diese Texte in einem Übersetzungsschnappschuss und stellt sie für die Übersetzung bereit.
Auf CDS-Views basierende Apps
Als das Tool bei weiteren Kunden zum Einsatz kam, haben wir das automatisierte Scoping überarbeitet und ausgeweitet, um sukzessive mehr Anwendungsfälle zu unterstützen. Als Zweites kamen auf CDS-Views basierende Apps hinzu. Der Fußabdruck dieser Apps ist oft kleiner, aber es können auch größere Apps mit dieser Methode entwickelt werden. i18n.properties-Dateien und Fiori-Kacheln spielen wie bereits oben hier ebenfalls eine Rolle. Aber die Art und Weise, wie Texte aus dem ABAP-Backend gezogen werden, unterscheidet sich: Der von der App verwendete Gateway-Service zeigt auf einen CDS-View, und dieser CDS-View kann eine Verbindung zu beliebig vielen anderen CDS-Views, Tabellenfunktionen usw. haben. Außerdem kann er Absprungpunkte für die Ausführung von ABAP-Code enthalten. Und natürlich können mit jedem CDS-View selbst auch Texte verknüpft sein, die von der App zur Anzeige auf der Benutzeroberfläche verwendet werden können. Mit dieser Ergänzung hat i18n Translation Manager die meisten heute verwendeten Fiori-Apps abgedeckt.
Auf Mapped-OData-Services basierende Apps
Mapped-OData-Services stellen eine moderne Art des Datenabrufs aus dem Backend durch Fiori-Apps dar. Sie wurden mit SAP S/4HANA 1909 eingeführt und wie bei den beiden bereits genannten Implementierungsszenarien verbindet sich die Fiori-App über einen Gateway-Service mit dem Backend. In diesem Fall jedoch benötigt der Gateway-Service kein Gateway-Builder-Projekt und keinen CDS-View, sondern zeigt direkt auf eine Servicedefinition. i18n Translation Manager ermittelt die von dieser Servicedefinition genutzten CDS-Views und deren abhängige Objekte und fügt sie zum Übersetzungsschnappschuss hinzu. Natürlich können Apps, die mehr als einen Gateway-Service verwenden, diese drei Methoden für den Zugriff auf das Backend kombinieren – es kommt auf die Implementierung an. Für uns war es besonders wichtig, auch diese Implementierungsart zu unterstützen, da immer mehr SAP-Kunden ihre Fiori-Apps auf diese Weise bauen.
Blick in die Zukunft
Gegenwärtig haben wir die Version 2.38 des i18n Translation Manager for SAP Fiori. Sie deckt alle üblichen Anwendungsfälle ab, denen Sie beim Übersetzen eigenentwickelter Fiori-Apps begegnen können. Außerdem wird jetzt auch die Übersetzung von SAP-Standard-Apps unterstützt, was unerlässlich ist, wenn Sie in eine Sprache übersetzen müssen, für die SAP keine Übersetzungen anbietet. Bei der nächsten Weiterentwicklung der Tools werden wir uns auf die Verbesserung bestehender Funktionen konzentrieren, Funktionen hinzufügen, die wir bislang nur über andere eigenständige Add-Ons anbieten und die Benutzeroberfläche vereinfachen.
Erfahren Sie mehr über unsere SAP-Übersetzungstools…