When you are developing SAP Fiori apps following an Agile methodology, it can be hard to find space for translation. As soon as one release is delivered for an app, your development teams want to start working on the next release. Translators would like to work on the texts for the finished release, without interference from the next one. And users expect the translations to be there when testing starts.
A Time and Place for Translation
To get translation done for an SAP Fiori app, you need two things – a window of time in which it can take place, and a place to get the source texts from and write the target texts to. In some projects, it is possible to add one or two weeks before the app is delivered, and to mandate a code freeze in the development system for the duration of translation. Maybe there is even the option to set up dedicated SAP system for translation. But this is not an option for many organizations running Agile projects, and that means both the time and the place for translation can be hard to come by.
In an Agile process, whenever a release is delivered for an app, your development team starts working on the next release right away. The time remaining between delivery and go-live is dedicated to integration testing, and extending the cycle by a week or two to fit in a translation step is often not an option. This means in the best case, that translation is done after the start of integration testing, and the translations are available to testers a few days into the integration testing period.
What’s so Hard About About Fiori?
With traditional SAP translation, it’s actually not that hard to minimize the translation window needed: You simply start the translation process early. And once development completes, you can get the remaining translation work done very quickly, since most of it is already finished. And it can all be done in the development system. This is possible because in the SAP backend, the user interface texts sit in a large number of individual objects, all of whose texts can be accessed separately by translators while development is ongoing.
That means nothing is preventing you from running development and translation at the same time, and in the same system. With SAP Fiori, on the other hand, the source texts sit in large monolithical files in BSP applications, often only one or two files per app. Grabbing these files and sending them to translator has to be done by developers, which introduces a lot of friction. This means you will probably only send an app to translation after it is done, and this in turn means that you need a larger translation window.
Where to Read, Where to Write?
To complicate things further, the place to get the source texts from is also less than obvious. In most organisations, SAP system landscapes are constructed around a development system, a test system, and a productive system. Let’s image we also have an integration system that business users have access to for testing, and a hotfix system for creating fixes for issues occurring on the productive system. In such a landscape, which system is the best place to read the source texts and write the target texts?
The first system that comes to mind is the development system. But once a release is in integration testing, the development system will already contain changes that will not go live as part of the current release, and therefore should not enter into the translation process. Another option is the integration system, which contains the source texts for the current release, but it cannot be used to deliver texts from. And the finished translations also need go into the development system, so they can be re-used once translation starts for the next release.
Enter i18n Translation Manager for SAP Fiori
With i18n Translation Manager for SAP Fiori, you can decouple development and translation, as I described in my guest blog post for text&form. This enables you to start translation at any time, which means translators can get a head start working on the source texts as they exist on the development system, and write their translations back to that system, without introducing any additional manual steps.
This way, maybe it is even possible to finalize translation before testing starts. But what if happens once a release is finalized on the development system and transported to the integration system? After this point, the right source texts for this release only exist on the integration system. And any fixes for those texts will only come from the hotfix system, not from the development system. Here, i18n Translation Manager for SAP Fiori gives you a lot of flexibility.
Updating Multiple Systems
On the newest release of i18n Translation Manager for SAP Fiori, you can create your translation snapshot (see last week’s blog post for a basic overview of how snapshots work) based on one system, but write the translations back to any number of systems. You also to do not necessarily have to write to the system based on which you created the snapshot. And for each of the systems you write the translations to, you can decide whether the changes should be recorded in a transport request.
In the scenario described above, you can create your snapshot from the integration system, which means your translators are working on the texts for the current release, exactly those texts that will later go to production. Once translation is done, you can write the translations back to the development system, record the changes in a transport request, and at the same time commit the changes to the Git repository for each app. That takes care of preserving the translations for the next release. You also can update the integration system with your translations (without writing a transport request, of course), so the testers can see and test the target-language texts. And you can repeat this process as often as you like.
Flexibility Built in
In order for the translations to go to production, however, it does not help to write the translations to the development system, since for the current release, no changes from development will go to integration or production anymore. The hotfix system, however, feeds integration and production for the current release. Here, developers fix bugs developed during integration testing – and this is also where you can write the translations to that you want to go live. So in addition to updating the development and integration system, you use i18n Translation Manager to also write to the hotfix system, creating the transport request that will be transported to production.
This kind of flexibility lets you support most workflows on almost an SAP system landscape. Whether you want to to translate based only on your development system, or whether translation has to fit into a complex process across multiple SAP systems – i18n Translation Manager for SAP Fiori adapts to fit your needs.
Read more on our SAP translation tools…