It‘s inevitable. There‘s no way around it. You‘ve just realized that there are texts in your SAP systems that have to be translated, and they have to be translated soon. Perhaps you’re rolling out your SAP systems in your offices in China or Brazil. Or maybe one of your locations in Mexico is migrating from a completely different system to SAP. You think you’ve covered all your bases. You’ve got your template in place, and you know who will handle all of the local legal requirements. But what about language? It occurs to you that the system will need to be translated for the local subsidiary. You may be asking yourself…
Right here! This is the first in a series of three posts on “scoping”, simply put planning, that will give you an overview of the first steps in an SAP translation project that not only covers all of the texts you’ll need to translate but also stays within budget. The key to achieving this is nailing down exactly what needs to be translated and, more importantly, what doesn’t. If that sounds daunting or confusing, have no fear. We’ll walk you through it. To start, let’s talk about your reasons for translating customizing entries.
If you’ve read this far, you probably already know that you will not be able to avoid doing at least some translation. So, chances are one of the following four reasons to translate in an SAP system applies to you:
In other words, you want to increase user acceptance.
Across the globe, proficiency in English as a 2nd language varies a lot.
So, it comes down to defining why you are translating certain parts of your SAP systems. After all, when an SAP translation project is completed successfully, everyone involved usually feels much better about “their” SAP than they did before. Next, we’ll look at how SAP can help with translation.
SAP offers language packs for import in 40 languages. In many cases, that takes care of the SAP Standard user interfaces that are used in your organization. But be aware that SAP does not provide all texts for all products in all 40 languages. In fact, language coverage decreases the fewer overall SAP users there are for a given language. So while you can expect most ERP transactions to be available in French, the same may not be true for Korean, for example.
Language packs are the way to get SAP Standard screens translated.
For the rest of the texts, SAP provides language supplementation, which is useful, but it is not the answer to everything, as I discussed in this post on combining language supplementation and SAP translation. But any texts created on your own – in fact, anything in the customer namespace – will not be covered by SAP language packs. Here you are mostly on your own, and that’s the raison d’être for SAP translation projects.
One piece of good news is that, for some countries, you may not have to translate at all. Countries where English is either an official language or, at the very least, commonly spoken, such as Singapore, may let you get away with skipping translation entirely. That is a valid approach, but it does require that your custom texts be written in clear and understandable English. If they are not, you may need to do a project to first create a proper English language version.
In other countries, it may suffice to only translate some forms, some customizing texts and a few reports that need to be translated for legal reasons, and leave the rest in English. In some of these scenarios, you may not even need to install the local language as a logon language. This may be, for example, because the location you are rolling out to is only a relatively small sales office.
In other countries, it may suffice to only translate some forms, some customizing texts and a few reports that need to be translated for legal reasons, plus some master data texts, and leave the rest in English. In some of these scenarios, you may not even need to install the local language as a logon language. This may be, for example, because the location you are rolling out to is only a relatively small sales office.
But there will also be locations that do require a local logon language, which usually means you need to translate at least a few Z reports, along with customizing entries, forms, role menus, and master data texts. And any text you decide not to translate should at the very least be filled with English texts, using language supplementation.
Now that you know some of the options available to you for your project, let’s head into scoping.
The first step in scoping is always to identify any texts that may need to be translated. The result will be your “initial scope,” which will get you the initial number of lines that could go into your project. Then, you reduce the scope by as much as you can while keeping the texts that absolutely must be translated. This will allow you to translate as little as possible and keep costs low.
The initial scope can be shockingly large.
As you move through the scoping process, however, you’ll need to decide when too much scoping is too much. Why? Because it’s generally more inexpensive to translate than to pay consultants for further scoping. This means that there is always a point at which reducing the scope further, e.g., by just a few more lines, is actually more expensive than simply locking in the scope and hitting the start button on translation.
Once scoping is complete and you know the number of lines to be translated, your SAP translation provider will be able to quote a fixed price for the translation project, and you are good to start translating.
In a post on translating SAP customizing entries, I explained that customizing entries reside in the SAP namespace.
The same tables that contain the customizing entries SAP provides are also the ones you’ve entered your customizing entries into. And there are hundreds of them. This means that after you’ve identified all the relevant text tables (and this is already a chore nobody want to do), you have two options.
This table contains both texts created in your organization and texts created by SAP.
The first is to hand off entire tables to translation, and translate any untranslated customizing texts from the SAP Standard that reside in those tables, along with the texts you’ve created. This obviously unnecessarily increases translation costs. The other option you have is to manually review all the text tables and pull out all the texts created by your organization. This can take a while, and you end up unnecessarily paying for work which is obviously ripe for automation.
Enter Customizing Delta Translation Manager (CDTM), which will make scoping easier.
This add-on takes any number of transport requests as input and identifies all the customizing tables that were changed by your organization. And not only that, it also finds all the individual entries in those tables you made during the customizing process.
CDTM shows the total lines in all tables identified as well as the delta lines,
What you get after the initial run of CDTM is a table that lists all the tables that were changed along with the total number of lines and, crucially, the number of lines you created. At a glance, this gives you an overview of your potential translation scope for customizing. But that’s only the initial scope, and we’re supposed to reduce it, right?
Exactly, and that’s where CDTM helps, too. For each table, you get useful metadata such as table description, SAP module, and development package. And for every language you are planning to translate into, you also get the number of lines that have been already translated (if any) and the number of lines that contain a translation but have not been reviewed by a translator.
The CDTM add-on provides detailed info on each text table and lets you exclude unwanted tables from the scope.
This means your IT team, along with the key users, can simply check off the tables that they do not need, right in Customizing Delta Translation Manager, and reduce the scope that way. This makes it easy to arrive at the final number of lines that allow you to estimate the cost of translation.
After scoping is complete, the next step is the actual translation. And if the “Manager” in this add-on’s name is any indication, you would expect it to take care of that, too. And you would be right, as I’ve detailed in this introductory post about CDTM.
As for scoping, the next post in this series will deal with scoping for ABAP-based user interfaces such as Z reports. Stay tuned!