In December of 2016, SAP released the SAP Translation Hub to the general public. This tool promises to revolutionize the SAP translation process, and it delivers in at least one respect – the SAP Translation Hub makes large SAP translation projects considerably cheaper.
The SAP Translation Hub in a Nutshell
At its core, it’s a fairly simple idea – SAP is making the translations created for SAP’s products available for its customers to reuse during their own development and translation efforts. To do this, the SAP Translation Hub offers REST services that can be used, for example, to:
- propose texts via an auto-complete feature during development on the SAP HANA Cloud Platform
- pre-translate user interface texts from English into 45 other languages and language variants
The second use case is especially useful when translating custom-developed, ABAP-based user interfaces, also known as SAP short texts. This is what I will be focusing on here.
The Multilingual Text Repository
The container that holds the translations that SAP created over the years is called the Multilingual Text Repository (MLTR), which contains truly vast amounts of texts. That’s not too surprising: As far as I am aware, SAP has been, for a long time, the software company that produces the highest amount of translatable user interface texts. Each text pair within the MLTR, across the 45 target languages and language variants it supports as I write this (February 2017), has a quality index assigned to it that is shown on the Hub’s user interface. This helps you to get an idea about how good a fit the MLTR thinks a translation is for any text you feed to it. For now, only English is supported as a source language, but both the MLTR and the Translation Hub are being actively developed, so that could change down the road.
The quality index may not always help, but it gives some indication as to how good a fit each translation is for your text.
Asking the Machine for Help
As an option, the SAP Translation Hub will not only pull translation suggestions from the MLTR, but can, if it does not get a hit, use machine translation functionality to return a translation result. Using this feature is not something I can currently recommend for most use cases, but that is not really a surprise, since it is quite a tall order to successfully implement machine translation for user interface texts. Just use Google Translate for your user interface texts and you will see what I mean.
This is not quite fair since Google does not know SAP terminology, but machine translation generally does not handle ambiguous texts well.
ABAP or not ABAP? That is the Question
Originally, the Hub was intended to be used mainly for developments performed on the SAP HANA Cloud Platform (HCP). After SAP opened the first beta to its customers, however, it soon became clear that the Translation Hub’s biggest use case might be for translating, or rather pre-translating, texts created as part of custom developments in ABAP-stack SAP systems. Since then, SAP has added support for ABAP texts in two main ways, and from where I stand, this looks like the biggest thing to happen in SAP translation since the introduction of Unicode support.
File Upload (or Pushing Translations to SAP)
First, there is a file upload feature that allows you to take individual files exported from a SAP system in the XLIFF format, upload them, and pull translation proposals from the SAP Translation Hub (see here). Afterwards, you can download a translated version of the file. This feature may involve quite a bit of manual effort, but I found it very useful from day one. The second way to translate ABAP-based texts is to via RFC to language-dependent objects such as text elements, data elements and text tables collected in an object list in an ABAP-stack SAP system. Both of these features are built on the SAP HANA Cloud Platform, so you do not control them from your SAP system, but trigger them from the Hub itself.
The user interface for uploading a file to the SAP Translation Hub
Limits to the Current Functionality
Both of these features currently still have a number of limits that I would like to see removed in the near future. They both choke if the number of texts that you feed to them is too great. There is also no filter functionality yet that would allow you to set the minimum quality index of the texts pulled from the MLTR, which is especially worrying in the “Push to ABAP” scenario, because you are essentially loading texts of unknown quality into your SAP system without an easy way to get rid of them again. This scenario makes the translator in me cringe: after all, I’m in the business to not only get SAP texts translated, but also to ensure a high level of translation quality. There’s also not much automation built into the SAP Translation Hub right now, but I am expecting that to change.
Saving Costs Through Pre-Translation
While you can, theoretically, use the SAP Translation Hub to translate your SAP texts indiscriminately and be done with it that is not the way to ensure a high level of translation quality. This is why we see the Hub mainly as a pre-translation solution that produces translation suggestions that need to be reviewed by a human, ideally an experienced SAP translator. But since translators will need a lot less time to review and, if needed, adapt or even delete a translation proposal, compared to translating the same texts from scratch, using the Translation Hub for pre-translation will still be a huge cost-saver. So in order to get user interfaces that are correctly translated, you will still need translators.
The Hub versus Language Packs
In the excitement about this new tool, it’s easy to forget that many of the translations that you can pull from the SAP Translation Hub already exist in your SAP system, or can be imported at no extra cost, in the form of SAP language packs. These translations can of course also be reused, and in many respects, the translation from language packs might be an even better fit for your custom-developed texts, since these translations were intended for the specific product you used to develop. In all of our translation projects, reusing existing translations from SAP language packs is one of the essential building blocks.
Importing language packs gives you translations that can be reused for translating your custom developments
The Hub and Automatic Distribution
Another building block in any translation project is Automatic Distribution, about which I have written here. In a nutshell, Automatic Distribution means pre-translating the texts occurring most frequently within your translation scope and distributing the resulting translations within the system. Since this not only saves a lot of costs, but also produces high-quality translations, it would be foolish not to make use of this feature before you pull any translations from the SAP Translation Hub.
Cleaning Up the Leftovers
Unless you like to live dangerously and use the SAP Translation Hub’s machine translation feature, you will not get a hit for every text within your translation scope. Instead, a considerable number of texts will still need to be translated afterwards. Nowhere is this truer than for language-dependent customizing tables, whose texts are often very specific to your company and not likely to match an existing translation within the MLTR. But even the user interface texts from your custom developments will not produce a hit, so some manual translation will still be required. For this kind of work, SE63 is still the tool of choice in most cases, and all the reasons I’ve detailed before as to why exporting the texts into Excel is mostly not a good idea still apply.
This is not the kind of text you would expect to find a match for in the SAP Translation Hub.
Don’t Expect One-Stop Shopping
The SAP Translation Hub is very useful as a building block in any SAP translation strategy, but it is a far cry from being a one-stop solution. For starters, it does not give you a starting point for translation, as it does not help you find out which texts you actually need to translate, nor does it help provide a cost estimate for your project. It also does not eliminate the need for manual translation work, although it does considerably reduce the effort needed. And finally, it does not support a number of text types such as F1 help texts or smart forms, which require a separate solution. I’ve described my approach to these kinds of texts here.
More Affordable SAP Translation
In my testing, I found the SAP Translation Hub to be ready for production, with a few caveats. The first caveat is that working with the Hub still involves a certain amount of manual overhead, since you will most likely have to upload and download files multiple times during a project. Also, there is not really a complete integration with ABAP-stack systems yet, at least not in the way I would like to see. For these reasons, I would recommend trying it out, but be aware that it may not be the best fit for smaller translation projects yet. For most SAP translation projects though, in 2017 and onward, the SAP Translation Hub should be taken into consideration. It looks set to make SAP translation much more affordable.
ABOUT THE AUTHOR
Martin Lüdecke is Director of SAP Translation at text&form. He collaborates closely with SAP’s language technology experts and is constantly expanding his knowledge, which enables him to bring the most up-to-date SAP translation expertise to each project. He is a certified Technology Associate – SAP Netweaver.
