Decoupling Development and Translation for SAP Fiori Apps with i18n Translation Manager


When you create your first SAP Fiori app, translation doesn’t look like that big a deal. You find your single i18n.properties file, search for the texts from the SAP backend and manually copy and paste them into a spreadsheet, and then you send everything to a translator.

But when you attempt this process at scale, or worse, at every sprint in an agile environment, translation can drive you up the wall. If that’s where you are, i18n Translation Manager for SAP Fiori can help you out.

Coordinating Development and Translation

Developing SAP Fiori apps almost always means combining texts from the app itself and from the SAP backend. This leaves you with a complicated setup where your developers know where the texts are, but it can be a challenge to have a translator or a translation agency work independently on them. With i18n Translation Manager, the entire process of handing the texts to the translators is automated: the tool pulls in the texts from the apps on its own and writes back the translations once they are done.

This way, starting a translation process becomes a matter of simply handing off names of transport requests, development packages or BSP applications, and an SAP-savvy translation team will be able to take it from there.

For larger translation projects, a project manager may still need to oversee translation, but this can be an external team member or someone at a translation agency. Meanwhile, handing off translation responsibilities will free up a lot of development resources. The automation 18n Translation Manager offers reduces friction so much that you can easily build a translation process that produces biweekly or even daily updates to the various language versions of your app. The size of projects can range from initial translation of 100+ apps into a new language to single texts, which means the word “project” starts to lose its meaning.

Translating in an Agile Environment

This kind of approach also thrives in an agile environment. Here’s a typical scenario: You have sent off the i18n.properties files for the latest release of 15 SAP Fiori apps to your translation agency. However, while they are translating away, your end users request changes to the translations of the previous release that they are currently using productively.

You make these changes now, but when the translated files are returned to you a week later, they contain translations that do not match the ones that you had to enter to close tickets from production. Normally, you would need to merge the changes manually. Thankfully, i18n Translation Manager was built for this type of situation.

How “Snapshots” in i18n Translation Manager Help

To provide the kind of flexibility required, i18n Translation Manager uses the concept of “snapshots.” A snapshot consists of all the source and target texts that exist in the development environment at the moment that the translation process is started.

Let’s look at our example of 15 SAP Fiori apps above. One snapshot could contain the state of the English texts for the new release of those apps, the state of French, German, and Chinese texts from the previous release, and an empty Dutch language version that would be translated for this release. For this snapshot, the translation agency is currently working on translating the texts that were added after the previous release. All the existing translations serve as a reference for the translators, because they can be re-used if new texts are identical to texts from a previous release that have been translated before.

However, you now need to urgently change a handful of German texts in another app. You ask the translators to create a second snapshot a few days later that contains the state of the texts at that time. In snapshot #2, the translators make the requested changes to the German texts and check the snapshot back in.

When i18n Translation Manager then writes snapshot #1 back, the changed German texts are caught by the tool’s synchronization process. So for those German texts that were changed in snapshot #2, the versions from snapshot #1 are not written back, though they are preserved. This is how i18n Translation Manager ensures that nothing is ever overwritten by accident.

How i18n Translation Manager Writes a New Target Language Version

When i18n Translation Manager writes a new target language version of an SAP Fiori app, it writes it in two places ‚Äì in the BSP application on the SAP Fiori development system, and in the associated Git repository, where the changes are also committed. (This can be GitHub, GitLab, SAP’s Git service or any other Git implementation). This is a crucial part of letting translators work independently. If anything is not as you expect, you can always revert back to an earlier state, undoing the changes from the last translation round. In that sense, the translators integrate themselves into your development process like any developer would: they work independently and commit their changes when they are done.

Translation for SAP Fiori Apps Made Easier

Decoupling translation from development is almost always a good idea, but it’s true that with SAP Fiori apps, this kind of process change is a little bit harder because of that mix of text from the app and from the backend that you have to work with. But this downside can also be an advantage, because you can always rely on the SAP backend being there. i18n Translation Manager makes use of that fact by running exclusively in the SAP backend, on the AS ABAP, and uses it to help you realize a streamlined, agile, flexible and sustainable translation process.


Über den Autor:
Martin Lüdecke is the founder of LUDECKE, our SAP Consulting Partner. Until 2019, he worked for us as Director of SAP Translation. He supports us with SAP consulting and software development work, and he sometimes guest blogs here. You can find his own blog here.