Earlier this year, we released i18n Translation Manager for SAP® Fiori, which embodies the way we think SAP Fiori apps should be translated in most SAP projects. But doesn’t SAP Translation Hub offer similar functionality for translating Fiori apps? In this article, we explain the thinking behind each of the two approaches – and we show you how to get the best of both worlds.
Translating Fiori Texts via the Built-In SAP Cloud Platform App
SAP Translation Hub can be used to translate both texts from SAP Fiori apps and texts from ABAP-stack SAP systems. On the surface, that sounds quite similar to what our own i18n Translation Manager for SAP Fiori offers – the integration of Fiori and ABAP translation. But the two tools are actually solving quite different problems.
If you have read my article SAP Translation Hub - an Overview, you know that as a standalone solution, SAP Translation Hub has all the basic features of a complete translation tool – there are ways to get texts in and out, there is an editing environment, and there is a repository that stores text pairs for reuse. But compared to fully-fledged translation tools such as SDL Studio or Memsource, it has a very limited feature set. The features that are there make it most useful for quickly translating single non-ABAP apps, or in scenarios when translations are done by in-house teams with little to no professional translation experience.
i18n Translation Manager, on the other hand, is not a translation tool as such – its job is to enable the integration of Fiori into ABAP-based translation processes. It essentially makes Fiori texts work like texts from custom ABAP developments. It provides no text editing environment, but instead makes texts available in transaction SE63 or via export from the SAP system. But since i18n Translation Manager comes with all the functionality of LUDECKE Translation Manager by default, you can integrate SAP Translation Hub in a way that, to my mind, can can add powerful new options compared to stand-alone usage of SAP Translation Hub.
Integrating ABAP Texts from the Cloud Side
Using SAP Translation Hub’s app running on SAP Cloud Platform, it’s easy to extract the texts in an i18n.properties file from a Git repository, for example, and quickly translate it. But your typical SAP Fiori app does not only use texts from its own i18n.properties files. It also uses texts from the ABAP backend, such as data element labels, customizing texts or other text tables, CDS views, text elements from classes or reports, and of course various text labels from the Fiori Gateway Server. The way to get those texts into SAP Translation Hub’s app running on SAP Cloud platform is to create an object list in the ABAP system, and then read that object list into an additional translation project in the app, using SAP Cloud Connector.
Since the SAP Translation Hub app will read each Git repository or file separately, one project will be created for every Fiori app that you want to translate. In addition to that, you need and at least one ABAP project. When you use SAP Translation Hub standalone, you also do not have access to backend SAP system features for processing and filtering texts, for building translation workflows and so on. And of course, every text in those projects is pretranslated using SAP Translation Hub’s API and counts against data volume consumption. Thus, the volume usage can quickly add up, since you are submitting every text in every file or object.
Use Cases for SAP Translation Hub
If you are looking to translate only a single app, this hardly matters. The SAP Cloud Platform app is a good solution for small translation endeavors. But when you are dealing with multiple apps, a significant portion of ABAP-based texts, and an external language services provider that uses professional translators, you quickly bump up against its limitations. The translation editor that SAP Translation Hub provides is targeted at a simple usage scenario, especially for easy use cases and non-professional translators. Whereas this can be and advantage for single app translation, in complex projects outsourced to professional translators, this may not be sufficient.
But when you are only looking at the SAP Translation Hub app itself, it’s easy to forget that the thing that makes SAP Translation Hub so powerful has little to do with the features available from the user interface of the app on SAP Cloud Platform. From the start, it was the raw power of the SAP Translation Hub API that was most useful in the projects I have worked on. It offers a lot of features – it can return texts from the multilingual text repository, which stores SAP existing product translations, or from SAP machine translation. It can disambiguate texts if you feed texts in two languages instead of one, and it can return the numbers of hits instead of the actual translations, which enables analysis features.
Integrating SAP Translation Hub from the ABAP Side
Our approach has always been that for translating ABAP-based texts, these API features are best consumed from within an SAP system, a feature that LUDECKE Translation Manager (or rather, its predecessor tf-externalize) has offered for a few years. And for translating Fiori apps, it’s not much different. i18n Translation Manager for SAP Fiori pulls the texts from i18n.properties files into your backend SAP system and makes them available to all the translation features of an SAP system. That includes SAP Standard functionality, of course, but also the SAP Translation Hub integration offered by LUDECKE Translation Manager.
Another aspect is that in the backend system, there is a translation memory system that you can use, the Proposal Pool. When LUDECKE Translation Manager queries the SAP Translation Hub API, by default, it skips any entries that already have a match from the Proposal Pool, which improves quality (after all, these are texts that your translators created, which are likely to be a better match for your texts than SAP Standard texts) and reduces your consumption of SAP Translation Hub texts, thus reducing costs. You can also restrict your matches in a number of ways, by SAP Translation Hub’s quality index metric, by translation source (multilingual text repository or machine translation), and maybe most importantly, you can select to only receive matches that not only match the text source language, but also the corresponding text in the a second, “reference” language.
You also have access all the good things that an SAP system offers. You can schedule translation analysis in the background, which is important to avoid timeouts on the these often very performance-intensive tasks. You have the very powerful (albeit complex) SAP translation environment at your disposal, complete with worklists, user management, functionality for assigning work to translators, and even functionality for billing. And you don’t even necessarily have to use transaction SE63 – LUDECKE Translation Manager will export all your texts for translation, including the texts from your Fiori apps.
End-to-End Fiori Translation
If your Fiori apps don’t just need to be translated once, but are updated on a regular basis, you get to take full advantage of the truly end-to-end translation processes that i18n Translation Manager for SAP Fiori enables. Whether you are running an Agile project, or your users or customers are simply requesting a lot of changes, with i18n Translation Manager, it’s easy to run delta translation projects, manage multiple translation projects simultaneously, or even cleanly update texts in an app that is already part of an ongoing translation project.
i18n Translation Manager effortlessly handles large numbers of Fiori apps and languages, fully integrates with the SAP transport system and commits changed versions of target-language i18n.properties files to your Git repositories. It works even in complex project setups, where several systems need to be updated at once with the latest version of i18n.properties files. And since it records all changes in a transport request or task, it also plays nice with your organization’s change management.
The Best of Both Worlds
If your SAP translation project is bigger than a handful of Fiori apps, or if your Fiori apps use any objects from the SAP backend, I think your project should be run from the ABAP backend side. i18n Translation Manager for SAP Fiori and its companion LUDECKE Translation Manager let you do just that. And you can still benefit from all the advantages of SAP Translation Hub, which can significantly reduce the workload for translators, especially on bigger projects.
Read more on our SAP translation tools…