pathdoc - stock.adobe.com
Moderne Übersetzungsmethoden für SAP-Fiori-Apps
Die Übersetzung von SAP-Transaktionen und -Anwendungen war in der Vergangenheit nicht trivial. In den letzten Jahren hat sich einiges getan. Einige Hürden bleiben allerdings.
Wenn man vor 20 Jahren eine eigenentwickelte SAP-Transaktion in eine andere Sprache übersetzen wollte, waren die Werkzeuge der Wahl allesamt im SAP-System selbst zu finden. Sie kamen im traditionellen Gewand der SAP GUI daher und erforderten für Projektmanager und Übersetzer einiges an Einarbeitung und Schulung.
Während andere Softwarelösungen mit Unterstützung von Standardsoftware übersetzt wurden, hatte man es im SAP-System mit einem zwar mächtigen, aber nicht gerade einsteigerfreundlichen Eigenbau zu tun.
Unter der Haube nutzte die Transaktion SE63 – so heißt die SAP-Lösung – zwar schon damals viele Konzepte, die man auch in den branchenüblichen Übersetzungswerkzeugen antraf, aber die Benutzeroberfläche dieses Tools stellte eine Art Paralleluniversum dar, das viel Vorwissen erforderte.
Das überrascht nicht, denn was übersetzt wurde, waren Entwicklungen in der Programmiersprache ABAP. Und Entwickler wissen, dass diese Sprache für jemanden, der Windows-Software oder Webentwicklung gewohnt ist, ein Paralleluniversum darstellt.
Doch das war früher, und die Dinge ändern sich. Schon seit geraumer Zeit gehören für viele SAP-Entwickler moderne Konzepte wie Git, Test Driven Development, Agile und DevOps zum Alltag, bei Add-on-Herstellern wie auch bei SAP-Kunden.
ABAP spielt als SAP-Programmiersprache noch immer eine zentrale Rolle, aber SAP hat in den letzten Jahren erhebliche Modernisierungen der Sprache ausgeliefert, von der Möglichkeit, in Eclipse zu entwickeln, über Anpassungen für SAP HANA, bis hin zu Neuerungen im NetWeaver-Stack wie der Möglichkeit, mit RESTful APIs zu arbeiten. Kurz gesagt: Es ist seit einigen Jahren wieder Musik im ABAP.
Mit SAP Fiori ändert sich vieles
Auch in Sachen Benutzeroberfläche hat sich viel getan. Mit SAP Fiori steht ein modernes Framework bereit, das immer häufiger eingesetzt wird, aber auch Side-by-Side-Szenarios werden häufiger. In beiden Modellen kommen ebenso andere Programmiersprachen zur Anwendung, angefangen bei JavaScript.
Und wenn sich die Benutzeroberflächentechnologie ändert, hat das auch Auswirkungen auf das Thema Übersetzung. In der Vergangenheit waren Benutzeroberflächentexte im ABAP-Stack-System verstreut, in Tausenden teilweise sehr unterschiedlichen Objekten. Das ist bei SAP Fiori anders. Hier sitzen die Texte größtenteils in Java-Properties-Dateien, oft nur in einer einzigen Datei pro App. Und auch bei Side-by-Side-Szenarios ist dies das präferierte Modell.
In vielerlei Hinsicht ist das einfacher. Vor allem in Sachen Übersetzung sind Java-Properties-Dateien grundsätzlich kein Problem mehr, denn solche Dateien werden in der Softwarelokalisierungsbranche seit 20 Jahren übersetzt.
Das heißt, SAP-Oberflächen lassen sich mit denselben Übersetzungswerkzeugen lokalisieren wie jede andere Software. Branchen-Tools wie SDL Studio, MemoQ, Memsource und XTM – sie alle kommen jetzt viel einfacher zum Zug. Kein mühsames Exportieren von ABAP-Texten aus SAP-Systemen ist mehr notwendig; es genügt, einer Übersetzungsagentur die i18n.properties-Dateien der zu übersetzenden Apps zu schicken.
Doch man vermisst etwas erst, wenn es nicht mehr da ist. So auch hier – viele Selbstverständlichkeiten von SAP-Systemen sind für Fiori-Texte nicht mehr verfügbar. Eine äußerst mächtige Übersetzungsumgebung? Im ABAP gibt es sie, bei Fiori fehlt sie (noch). In Echtzeit verfügbare Übersetzungen? Nachvollziehbare Übersetzungstransporte, die Change-Management ermöglichen? Aktualisieren einzelner Texte, ohne gleich eine ganze App als geändert zu registrieren? Das alles ging mit ABAP-Texten, aber mit Fiori-Texten nicht. Aus Sicht eines ABAP-Entwicklers sind Fiori-Apps monolithische Übersetzungscontainer, die jegliches dynamische Ändern und Transportieren von Texten verbieten.
Und es ist ja nicht so, dass man sich zukünftig nicht mehr mit ABAP-Texten beschäftigen muss. Texte auf Fiori-Kacheln werden grundsätzlich in einer klassischen SAP-Tabelle umgesetzt. Alle Texte aus dem SAP-Customizing, die der Anwender in Dropdown-Menüs sehen kann, kommen aus dem SAP-Backend.
Dazu werden über OData-Services diverse weitere Backend-Texte verwendet: Textelemente aus ABAP-Klassen, Datenelemente, Fehlermeldungen und so weiter. Natürlich ist es immer Sache des Entwicklers, ob er Texte aus dem Frontend nutzt, also in den Fiori-Apps selbst implementiert oder per OData aus dem SAP-Backend zieht. Aber allzu oft ist es tatsächlich die bessere Wahl, Backend-Texte zu nutzen, und häufig sogar die einzig sinnvolle.
Und so kommen Implementierungsprojekte zustande, in denen sowohl Texte aus den Fiori-Apps übersetzt werden müssen (die oben erwähnten i18n.properties-Dateien) als auch klassische ABAP-Texte.
Es sieht daher so aus, als ob uns das ABAP-Paralleluniversum auch in Sachen Übersetzung noch eine Weile erhalten bleibt. Neu ist nur, dass in SAP-Projekten, in denen eigene Fiori-Apps implementiert werden, mit den Java-Properties-Dateien eine Art von Texten hinzukommt, die in SAP-Projekten bisher keine Rolle gespielt hat. Damit nähert sich SAP auch beim Thema Übersetzungen auf der einen Seite dem Rest der Softwareindustrie an, bleibt aber auf der anderen Seite fest in der ABAP-Technologie verwurzelt.
SAP Fiori schafft neue Hürden
Was heißt das nun für das typische SAP-Rollout-Projekt, in dem eine Fiori-First-Strategie ausgerufen wurde? Wenn Fiori-Apps übersetzt werden müssen, hat man es einerseits mit den für SAP-Projekte neuartigen s-Dateien zu tun, aber andererseits auch weiterhin mit ABAP-Texten aus dem SAP-Backend.
Es müssen also Texte aus zwei verschiedenen Repositorys übersetzt werden, was im Endeffekt zwei separate Übersetzungsprojekte bedeutet. Es reicht daher nicht, Java-Properties-Dateien übersetzen zu lassen, sondern es gilt außerdem, alle von den Apps verwendeten Texte aus dem Backend-System zu ermitteln.
„Wenn Fiori-Apps übersetzt werden müssen, hat man es einerseits mit den für SAP-Projekte neuartigen s-Dateien zu tun, aber andererseits auch weiterhin mit ABAP-Texten aus dem SAP-Backend.“
Martin Lüdecke, Ludecke GmbH
Im besten Fall, nämlich wenn es nur ein paar wenige Fiori-Apps sind, die hauptsächlich Texte aus Java-Properties-Dateien nutzen, ist die Übersetzung ein wenig unhandlich, lässt sich aber verwalten.
Wenn es aber um eine größere Zahl von Apps geht, oder der Anteil der Texte aus dem SAP-Backend etwas höher ist, wird es schon schwieriger. Und wenn die Texte nicht nur einmalig übersetzt werden müssen, sondern regelmäßig neue Texte hinzukommen – wie in agilen Projekten üblich – ist endgültig Umdenken angesagt. Dann braucht es eine Strategie, die die Texte aus dem Frontend und Backend zusammenbringt.
Ziel sollte es dabei sein, schnell alle benötigten Texte zu identifizieren – entweder einmalig, als Big Bang, oder pro Sprint, damit die Apps in jeder Phase in allen benötigten Sprachen verfügbar sind. Die eigentliche Übersetzung kann dann, wie vor 20 Jahren, im SAP-System erfolgen oder per Export.
Die SAP-internen Tools wurden seitdem stark weiterentwickelt und sind in vielen Szenarien durchaus eine gute Wahl, aber es gibt auch gute Exportoptionen. Und natürlich gibt es auch Werkzeuge, die einen echten Ende-zu-Ende-Prozess für die Übersetzung von Fiori-Apps ermöglichen. Auf jeden Fall sollte in jedem Fiori-Übersetzungsprojekt mitgedacht werden, dass es Frontend- und Backend-Texte gibt, die beide übersetzt werden müssen, damit in der ausländischen Lokation vollständig übersetzte Apps ausgerollt werden können.
Über den Autor:
Martin Lüdecke beschäftigt sich seit vielen Jahren mit dem Thema SAP-Übersetzungen. Er ist Geschäftsführer der LUDECKE GmbH, die Tools für das Übersetzen von Texten in SAP-System entwickeln und die dazu passende Beratung anbieten. Ein Beispiel ist i18n Translation Manager for SAP Fiori, die Komplettlösung für das Übersetzen von SAP-Fiori-Apps.
Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder.
