Much has changed since we introduced the Automatic Scoping feature with i18n Translation Manager 2.0. The tool can now analyze the backend components of more types of apps and supports analyzing SAP standard apps. Here is a short overview of its current capabilities for analyzing Fiori apps.
State of the Automatic Scoping
i18n Translation Manager for SAP Fiori remains the only tool on the market – as far as we know – that allows SAP’s customers to run a complete, end-to-end translation workflow for Fiori apps. From the start, its marquee feature has been to unify the translation process for frontend and backend texts. Texts from the i18n.properties files and Fiori tiles can be translated the same way as domain values or texts from tables that are used in dropdowns used by the app, to give just one example. That makes i18n Translation Manager the best SAP translation tool for anyone whose SAP S/4 HANA implementation requires them to translate more than one or two Fiori apps.
The idea behind the Automatic Scoping feature that we introduced in early 2021 was this: To translate all texts that the app exposes on its user interface, you need to identify all objects used by a Fiori app, and the texts associated with them. To do this manually is a Herculean effort – so we automated this task. On the user interface of i18n Translation Manager, the Automatic Scoping feature is represented by a single checkbox – Include Backend Objects Used by BSP Applications and Gateway Services. But behind that single checkbox hide fairly complex analysis tools that scan the entire backend of Fiori apps and collect all the texts that each app uses. And while it’s clear that no automatic process will identify 100% of the texts that are displayed on the user interface of SAP Fiori apps, getting 95% of the way there – without any manual work – is a very good starting point. And that is what i18n Translation Manager does. This blog post is a quick overview of the most common use cases, i.e. the most common types of app implementations.
Apps Based on Gateway Builder Projects
As we started to roll the Automatic Scoping feature, we only supported what was maybe the most challenging use case. Apps based on SAP Gateway Builder projects (transaction SEGW) are among the most complex custom Fiori apps you can build. In addition to the i18n.properties files that are commonly used on the frontend to store the majority of then texts, these types of apps can make use of texts stored in the Gateway Builder project itself, as well as any texts called from the backend via the project implementation. That means we are looking at text elements from classes, domain values, and almost any other Data Dictionary objects such as tables or data elements. The Automated Scoping feature collects all of them into a translation snapshot and makes the texts available for translation.
Apps Based on CDS Views
As we deployed the tool for more customers, we reworked and expanded the Automatic Scoping feature, and gradually supported more use cases. The second addition was apps based on CDS views. These apps often have a smaller footprint, but there are also ways to build bigger apps this method. i18n.properties files and Fiori tiles are in play again here, same as above. But the way that texts are pulled from the ABAP backend is different: The gateway service used by the app points to the CDS view, and that CDS view can connect any number of other CDS views, table functions, etc. It can also include jumping-off points to execute any ABAP code. And of course, each CDS view itself can have texts associated with it that the app can use and expose on its user interface. With this addition, i18n Translation Manager covered most Fiori apps that are in use today.
Apps Based on Mapped oData Services
Mapped oData services are a fairly modern way of enabling Fiori apps to call data from the backend. They were introduced with SAP S/4HANA 1909, and as in the two above implementation scenarios, the Fiori app connects to the backend via a gateway service. But in this case, that gateway service does not require a Gateway Builder project or a CDS view, but instead points directly to a service definition. i18n Translation Manager will identify CDS views or other objects used up by that service definition and add them to the translation snapshot. Of course, apps that use more than one Gateway service can combine these three ways of accessing the backend – it depends on the implementation of the service. Adding support for this implementation type was particularly important since more and more SAP customers are starting to hook up their Fiori apps this way.
Looking Forward
As I write this, i18n Translation Manager for SAP Fiori is on version 2.38. It covers all common use cases you encounter when translating custom Fiori apps, and it now also supports translating SAP Standard apps – which is a requirement if you need to translate into a language that SAP does not offer translations for. For the next iteration of the tools, we will be focusing on refining its existing features, adding functionality that we currently only offer via other standalone add-ons, and simplifying the user interface.
Read more on our SAP translation tools…