This week, we are releasing i18n Translation Manager for SAP® Fiori 2.0, which offers many improvements for our customers. Its headlining feature is called Automatic Translation Scoping, which lets you enter names of SAP Fiori apps, and the tool then collects the texts used by each app from both the frontend and backend.
Translating SAP Fiori Apps Should Be as Simple as Possible
When we released i18n Translation Manager for SAP Fiori in early 2020, we had one goal – making translation of SAP Fiori apps as simple as possible. To do that, we tackled the biggest challenge first – bridging the gap between frontend texts from the Fiori app itself and the texts that the app uses from the ABAP backend. We achieved this by building i18n Translation Manager as an ABAP-based SAP add-on that runs in the SAP backend and pulls the frontend texts from Fiori apps (typically maintained in i18n.properties files) into the backend. Once that hurdle was cleared, frontend texts could be translated in the same environment as the backend texts (such as text elements from classes or customizing table entries etc.). That environment can be transaction SE63, or the texts can be exported to a translation-friendly format.
In addition, we automated the translation process as much as possible to support Agile development approaches as well as change management. i18n Translation Manager automatically updates BSP pages and commits changes to Git repositories, supports complex SAP landscapes and allows you to run multiple translation projects at the same time. You can even make changes to the app while that app is already checked out for translation, meaning that developers can work on the app at the same time – i18n Translation Manager will figure out any sync issues for you. Many of these features were added over the course of the last year as part of customer requirements – but the commitment to automation, Agile development and change management was there from the start.
New Challenges
As i18n Translation Manager grew, one major problem became apparent that the tool was not addressing. It’s fairly easy to identify the texts that a Fiori app uses from the frontend – they can mostly be found in Java properties files. A Fiori app rarely has more than one or two of these files (although they are very tricky to disassemble into individual strings). But most custom Fiori apps also use a considerable amount of backend texts that they access via oData services, for example. These texts reside in traditional SAP objects like classes, data elements, tables etc. or are associated with the oData services or CDS view, among others. You can find these texts on the SAP Fiori Gateway Server system and in your SAP S/4HANA system (which, of course, can also be one and the same).
These backend texts are used in the apps along with the texts from the frontend, and appear in dropdown menus, field labels or in other places that may not be obvious at first glance. Identifying them really is a problem, since your developers have to comb through the backend part of each app to find them, which can take many days. Another approach is to consider all custom objects in the backend for translation and exclude the ones that you are sure will not be needed. This is a lot quicker, but you will invariably end up translating too much, which will mean higher translation costs. Since we were running into this problem again and again, we decided to build the feature that ended up being called Automatic Translation Scoping.
Automatic Translation Scoping
When creating a new translation snapshot with i18n Translation Manager now, you first enter the names of Fiori apps and then have the option to also perform a full analysis of the backend and Gateway objects that are used by the app. If you select that option, i18n Translation Manager will generate a scope that contains most, if not all of the texts that each app uses under the hood. This analysis can sometimes run for a few hours – but since we built i18n Translation Manager as an ABAP application, it has access to SAP background jobs and scales from a single Fiori app to hundreds of apps.
To make translation of customizing table entries more efficient, we even built in a miniature version of our Customizing Delta Translation Manager tool. This means after i18n Translation Manager identifies a customizing table that is used by one of your Fiori apps, it will only add custom entries from that table to the scope and skip any customizing texts delivered by SAP. There is, however, one restriction – since it is absolutely possible to implement Fiori apps in ways that the tool does not anticipate, it will probably never be able to catch 100% of all texts used by the apps– but it will come very close.
The backend and Gateway texts identified can be translated alongside the frontend texts as before, using the core feature set of i18n Translation Manager.
Read more on our SAP translation tools…