If you know that there are texts in your SAP systems that you will need to get translated, the next step is to identify the texts you really need. This is what scoping is all about. The following is the second in a series of three posts that aim to give you an overview of the first steps towards an SAP translation project that covers all the texts you need and stays within budget. This post will be about translating custom ABAP development entries. To get an introduction to scoping, I encourage you to go back and read
Reduce the scope or streamline the translation process?
There are two possible ways to make an SAP translation project more efficient. One is to reduce the number of texts you need to translate, in other words reduce the scope of the translation project. The other one is to optimize the translation process itself, by automating translation as much as possible while still getting the level of translation quality that you expect. Both are important, but for user interface texts of custom SAP developments, more so than for any other texts that live in SAP systems, it pays to take a closer look and find where the most efficiencies can be gained.
What does SAP offer?
For scoping Z developments, the SAP Standard does most of what you need on the tool side of things. In fact, it is particularly well suited for translating ABAP user interface texts, much more so than for customizing texts, forms or even master data. This makes sense if you consider that when SAP translates their own products, the vast majority of texts they need to cover are user interface texts. This means you can easily scope this part of your project using just the SAP Standard and nothing else.
The main transaction used for scoping is called LXE_MASTER.
In addition, as translation coverage is very good for many of the 40 languages that SAP provides translations for, in many projects you won’t actually have to worry about translating SAP Standard texts. You do, however, need to be aware of the fact that SAP does not provide all texts for all products in all 40 languages. In other words, there are translation gaps that may require you to translate SAP Standard texts. This is especially true for less thoroughly covered languages such as Korean, for example.
Language packs are the way to get SAP Standard screens translated.
Optimizing and Automating the Translation Process
In most larger projects, it can prove difficult to optimize and reduce the translation scope for Z developments, sometimes simply because the resources to perform this task are not there, be it on the IT side or on the business side. And if you bring in external resources that have not done this kind of thing before, costs can spiral out of control as hours and days are invested to exclude every last text from the scope. At this point, it is often advisable – and much more cost effective – to translate rather than keep optimizing. So it makes sense to strike a balance and reduce the scope as much as possible within a reasonable amount of time, and leverage translation automation tools to get you the rest of the way.
This is especially true for Z development. Most other text types are easier to scope, particularly because in many organizations there’s a good level of knowledge about which forms or which master data records you need in another language. And thanks to our CDTM add-on , customizing entries are not much of a headache, either. And the good news is, while Z developments may be the hardest to scope for translation, they are also the easiest to automate.
Optimizing and Automating the Translation Process
The biggest savings in SAP translation can be achieved by automating translation – especially for custom developments. Provided you have access to a third-party tool like tf-externalize which offers this functionality, you can leverage the translations from SAP language packages, as well as any other existing translations by populating the proposal pool (which I’ve written about here ) with the relevant SAP Standard translations. This means that whenever your developers write user interface texts that are identical to an SAP Standard text, the translator translating this text into French, for example, can re-use the SAP Standard translation.
Generating translation proposals saves a lot of work.
And there’s also a way to deal with duplicate texts using Automatic Distribution, an SAP Standard feature which I’ve described here .
Leveraging SAP Translation Hub
I’ve written quite a bit about the treasure trove full of pre-existing SAP Standard translations that is SAP Translation Hub, see here and here . Thanks to our tf-externalize add-on, you can retrieve translations from this repository without ever leaving the SAP GUI, and you can deploy various automation scenarios, the most common of which is to get translations from SAP Translation Hub and have translators review and approve these translations in order to keep translation quality high.
Anything else?
If you’ve gone back and read my post about scoping Customizing entries for translation, you now know about the two types of texts that make up the biggest part of most SAP translation projects… but there’s more.
The next post in this series will deal with scoping texts that do not actually originate on development systems, but that are created in productive environments, such as master data texts. Stay tuned!
