Translate SAP Fiori apps using an SE63-based Workflow with i18n Translation Manager

Published on 4 May 2020

When you are planning to translate Fiori apps into another language, you often will also have to translate a number of ABAP-based objects from the backend, too. In this scenario, wouldn’t it be nice have a common translation editor in which to translate all of these texts? For ABAP-based texts, that environment would be transaction SE63. i18n Translation Manager for SAP® Fiori now closes that gap and enables you to translate SAP Fiori texts in SE63, too.

Connecting Two Worlds

One of the main problems we tried to solve when developing i18n Translation Manager] was how to connect the two separate technology stacks of SAP Fiori apps and ABAP that lead to two streams of texts. SAP Fiori apps store their texts on business server pages, and in Git repositories. ABAP-based texts sit in an SAP system. Translators can access ABAP-based texts in SE63, or you can choose to export the texts for them. SAP Fiori texts they cannot access at all: you have to physically copy the texts from the development enviroment into text files and send the files over to them. That is why it made sense to try and make SAP Fiori texts available in SE63. And while SE63 may not be everyone’s first choice of translation editor (it’s admittedly not welcoming to beginners, see my article on translation environments for SAP translation), it is usually the first choice when you are working with SAP-savvy translators that know this particular working environment well. And if a text can be accessed in SE63, it also means that it can, in theory, be exported the same way as all other SAP texts, if exporting is what you want to do.

With i18n Translation Manager, you can translate Fiori apps in SE63.

i18n Translation Manager enables you to translate Fiori apps in SE63, together with SAP Backend texts.

Bringing SAP Fiori Apps into the Fold

i18n Translation Manager is an ABAP-based application that typically lives in the SAP system where the backend objects for your SAP Fiori are developed. At the heart of it’s functionality is the concept of snapshots. When the tool creates a snapshot, it gets all the texts from the relevant BSP applications on the SAP Fiori Gateway system. It then takes the files apart completely and handles each text separately. And it not only matches source and target texts, it also splits overlong texts into manageable chunks and checks the files for issues such as duplicate keys. Once the snapshot has been created, the tool outputs the number of lines per file, using the same metrics that the SAP standard translation tools use throughout – new, modified and translated lines. At this stage, you can also edit the snapshot to exclude files that are not needed after all. This can be very useful when you have created a snapshot for your entire development namespace, or for all of Z*, and need to exclude files from translation, but still want to keep them in the snapshot so you see the numbers of lines for all files from all apps.

Snapshot details

Once you have created a snapshot, you can see line numbers and metadata.

Once you are happy with your scope, you can start the translation process, which is done by generating translation objects, which are temporary objects that can be collected in a regular translation worklist, which your translators can then process in transaction SE63. And since the ABAP objects used in your Fiori apps live in the same system where you run i18n Translation Manager, they can be added to that worklist as well. This is and ideal situation for translators, who can now translate all the texts for your apps in the same workflow. i18n Translation Manager also tries to give translators as much context as possible by exposing the metadata for each file. It also make the developer comments available to the translators. This means the developers can add notes for the translators by simply adding a comment in the original file.

Safety First

Once translation is completed, you can write back the translations to your BSP applications, and update the associated Git repositories at the same time. During the process, the current state of the target-language files is not simply overwritten. Instead, a new snapshot of the same apps is taken in the background, the old and the new state are compared, and conflicts are resolved. This ensures, for example, that if a text was translated as part of the current snapshot, but that text has changed in the meantime, its translation is not written back, since that translation would not match the new source text. The same goes for the target language texts: any changes a developer makes to the translation while the files were “checked out” takes precedence over the translation entered by the translator.

A temporary translation object in the SE63 short text editor.

A temporary translation object in the SE63 short text editor. Notice the keys from the original object, and the developer comments.

This “safe write-back” methodology also has a few other benefits. If a snapshot has been written back, you can create a new snapshot right away. All the texts for which the translations have been successfully written back will now be displayed as translated, but any texts where a sync conflict led to them being skipped during write-back will come up for translation again. And so, by the way, will any new texts added by developmers in the meantime, which means you can comfortably handle translation deltas and build a continuous translation process.

Making Corrections

Correcting single texts is also easy, since you can quickly create a snapshot for a single app, if needed, even if translation is ongoing for a new version of that app in another snapshot at the same time. The translation you make will be safely written back, and when you finally write back the snapshot in which the new version of the app is translated, that corrected translation will simply be skipped – because the target-language text has changed in the meantime.

The Write-Back Results screen.

This snapshot has been successfully written back to a BSP app, to a Git repository, and a transport request has been created.

In summary, i18n Translation Manager enables translation of your SAP Fiori apps in transaction SE63, but for all texts that are displayed on the app’s user interface – not just the ones that reside in the app itself. It also allows you to build a sustainable translation workflow, for continous translation as well as for ad-hoc translation corrections. It also takes the burden of translations off the shoulders of your developers. Snapshots creation and write-back are fully automated, which means you won’t even have to send your translation teams any files. It is the best way to translate SAP Fiori apps.

Update: Translating Fiori apps in a Web-Based Editor

As of December 2021, you can also translate Fiori apps using XTM Cloud’s modern, web-based translation editor. Our new XTM Connect for SAP Systems enables a workflow that works as described above, but instead of provisioning the texts from and the ABAP backend texts in transaction SE63, you can upload the texts for translation to XTM Cloud.

Read more on our SAP translation tools