SAP Translation Hub is a solution that offers a number of features for translating SAP texts. First and foremost, there is the multilingual text repository (MLTR), which stores large parts of SAPâs translation history and makes those translations available to customers. SAP Translation Hub has now been around for more than three years, and Iâve worked with it from the very beginning. Here is an overview of this solution and what you can do with it.
A Little History
SAP introduced SAP Translation Hub in late 2016, positioning it as the new translation solution for custom SAP developments. SAP Translation Hub runs as a service on top of SAP Cloud Platform, and when it was launched, the only way to consume the new service was via its APIs. SAP has since added a user interface for translating, reviewing and post-editing texts. In the beginning, the product was mainly pitched as a way to translate apps developed on SAP Cloud Platform, but soon it also offered integration for ABAP-based texts. Most of the larger implementations that I know of or have been involved in have used the API-based approach and applied it to ABAP-based texts.
From the start, you were able to send English-language texts to SAP Translation Hub and get back translation suggestions in a number of target languages. Each of those suggestions came from one of two sources - the multilingual text repository (MLTR), or SAPâs machine translation engine. The MLTR is a “treasure trove of translations” that SAP has amassed over the years by virtue of translating millions of words themselves, for their own products. The machine translation is SAPâs own engine, which is trained to focus on SAP-typical texts and terminology. SAP monetizes the service via a volume-based system, where you pay just under 40 euros per 100.000 characters that you consume. The service counts the source characters that the API receives as a result of your usage.
The Strengths of the Concept
The biggest strength of the product, and the feature that sets it apart from other translation memory systems (see here for a short introduction to what a translation memory is), in my view, is something that has been built into SAP systems from the start - the so-called language vector. The idea is that the MLTR stores translations not as text pairs (for example, Cancel and Stornieren (German)), but that each text is associated with all its translations across all the supported languages (Cancel and Stornieren (German), Annuler (French), and so on). This allows you, for example, to send a user interface text for one button in one transaction, but send that button text not only in English, but also in French and Spanish, if the text was already translated into those languages. Using this additional information, the, say, Chinese and German texts that you get back from SAP Translation Hub will already have been disambiguated. And as a result, the translation you get back is much more likely to be correct. Iâve blogged about this reference language feature on textform.com) when it first came out.
Another thing that SAP Translation Hub has going for it is the vast amount of translations that the MLTR contains, and that you can use to pre-translate your own custom ABAP developments and your apps. The quality of the results that you get back varies a lot across language combinations, which has a lot to do with how many texts are available in any given language, and how âclosely relatedâ source and target language are. I have, for example, seen particularly good results translating from English into Romance languages, such as into Spanish or French. Then there is SAPâs machine translation engine. Iâve seen pretty impressive results that this engine produced, particularly since SAP Translation Hub switched from statistical machine translation to neural machine translation. But all good results I have seen have been for documentation-type texts, not for user interface texts. This is mainly due to the fact that user interface texts are usually very short, which gives any machine translation engine a much harder time.
Limiting Factors
What SAP Translation Hub is not is a âfire and forgetâ solution. To produce good results, a human translator needs to review any text you get back, to catch low-quality suggestions and correct translations for ambiguous texts. There are scenarios where it can be helpful to use SAP Translation Hub texts without reviewing them afterwards, but they are few and far between. So it comes as no surprise that most successful projects implementing this solution incorporate a human component, and ensure that either all suggestions coming from SAP Translation Hub are reviewed by SAP-savvy translators, or that at least most of them are.
Another aspect is the cloud-based nature of the solution, which is an advantage to some customers, but to others makes it much harder or even impossible to use, depending on their internal policies. Not every customer wants to send their language data to a cloud service, itâs as simple as that. SAP addresses this issue by offering terms of service that provide good data protection and by only using SAP data for training their machine translation engine, not customer data. Another way that SAP has come up with to make it easier for customers to take that leap of faith is the customer-specific MLTR, which stores translations used or changed by a customer in their own separate data silo.
Using SAP Translation Hub via the SAP Cloud Platform App
There are three main ways to use SAP Translation Hub for translation. The first is via the user interface that SAP provides on SAP Cloud Platform. You can pull a file from a Git repository into an editing environment, or upload a file in a number of formats. Once you have imported the file, you can use the built-in, very basic translation editor to translate it. The file is pre-translated using the SAP Translation Hubâs API, but you can review and change any translations. Once you are happy with the translations, you can write the file back to the Git repository or download it. A number of file formats are supported, and there is also a way to skip the editing step and write to Git or download without reviewing the translations first.
One obvious use case for this approach is when a developer or business user who speaks more than one language and wants to quickly translate an SAP Fiori app or another SAP-related app into another language. As stated before, I would not recommend skipping the review step, but for translating single apps, using the app can be a good solution. For professional translators who are used to powerful translation industry tools like SDL Studio or Memsource, the SAP Cloud Platform UI of SAP Translation Hub is not really an option. There are simply too many features missing that a professional translator needs to be able to work efficiently, and there are next to no relevant features for translation project managers. This means that this approach would not work well in an outsourcing scenario.
Using SAP Translation Hub via its Translation API
Another way to use SAP Translation Hub is to just use the Translation API, without using SAP Cloud Platform at all. To me, this has always been the most promising application. With this approach, communication with SAP Translation Hub is only one-way, and none of the translations you end up going with is ever stored in MLTR, but in your own translation memory. You also have much more control on what kind of translation suggestions you get, since you can use the APIâs various parameters to specify more precisely what you need. For example, you can specify to only get translations from the MLTR and no machine-translated texts, or you can specify to only get translations that, according to SAP Translation Hub’s quality metric (the quality index), have a certain likelihood of being correct.
You can also use the reference language feature I mentioned above. And thanks to the new “simulation” feature, you can choose to not get any translations at all, and instead only request statistics on how many texts would match your query. After all, you will be paying for every translation suggestion that SAP Translation Hub provides, so itâs good to know how many hits you are going to get before you get them. And by the same logic, pre-filtering the results and getting back only the texts of the quality level you want is also helpful. Especially when combined with a traditional translation memory and a powerful editing environment, I find the SAP Translation Hub to be a valuable addition to a translation workflow for SAP texts.
Translating ABAP-Based Texts
Translating custom SAP developments may be the most common use case for SAP Translation Hub today. Once SAP Fiori becomes more widespread, this may change, but luckily, SAP Translation Hub can help with both use cases. While it is also possible to pull texts from an SAP system into SAP Cloud Platform via SAP Cloud Connector and use the user interface described above, this setup does not perform well for larger projects, and you would still have to use the built-in editor, which is not much help in outsourcing scenarios. A better way to use SAP Translation Hub for translating ABAP-based texts is to call its API directly from an SAP system, get the translation suggestions and apply them to the text elements, data elements, tables, messages etc. that you want to translate in the SAP system.
The first solution that offered this feature that I know of was text&formâs tf-externalize for SAP Translation Hub, which came out in the spring of 2017 (full disclosure, I wrote that app when I was working for text&form, who are also a partner of ours). This add-on was used successfully in quite a number of translation projects for SAP customers and SAP partners. About a year later, SAP released a report (via the SAP note 2644105) that offered similar functionality. I am understandably a little biased towards the text&form solution, where I like some of the design decisions better, but in the end, itâs the overall approach that matters. SAP Translation Hubâs API is a really helpful tool in translating ABAP-based texts, and using it can both lower your translation costs and increase quality.
Whatâs Right for You?
There are three main scenarios in which you should take a serious look at SAP Translation Hub. One is when you want to translate ABAP-based texts and need to lower translation costs in exchange for a little more complexity in project management. This is especially true if you are outsourcing translation, but itâs a good option even when translating in-house. Accessing SAP Translation Hub via its Translation API is the way to go here, whether you use the report from SAP Note 2644105 or a custom solution. And thanks to our own i18n Translation Manager for SAP Fiori, mixed scenarios in which you have to translate both Fiori texts and SAP backend texts in the same project can also be supported easily.
The second scenario is for small in-house projects translating SAP Fiori apps or other applications using SAP terminology. Especially for colleagues who are not professional translators, SAP Translation Hub makes it easy to get started, and the simplicity of the built-in editor can even be an advantage and simplify the translation process for users who do not need the power of a translation-industry tool. The only precondition that I see is that the files to be translated should be stored in a Git repository, since most of the simplicity of the tool is lost when you have to upload and download files.
The third scenario deals with translating long-form texts that use SAP terminology, such as documentation of custom SAP developments or training materials. For these types of text, SAPâs machine translation engine integrated into SAP Translation Hub can be useful, especially if you access it via the API. This is not a scenario that I know well, but I expect SAPâs engine should outperform other machine translation services for these types of text. But as with all use cases of SAP Translation Hub or indeed, of any machine translation service, keep in mind that itâs a good idea to have human translators review and post-edit the resulting translations.
UPDATE: An earlier version of this post incorrectly stated that SAP’s machine translation engine is being improved using customer data, which is not the case. The text above been corrected accordingly. We are sorry for this mistake!
Erfahren Sie mehr ĂŒber unsere Services im Bereich SAP-Ăbersetzung…