Let’s assume you’ve just realized there’s no getting around it —some texts in your SAP systems are going to need to be translated pretty soon. Maybe you’re rolling out your SAP to a location in China that will switch from their old system to SAP. You’ve got your template in place, and you know who will handle all the local legal requirements. But now — translation, too, of all things. You may be asking yourself…
Where Do I Start?
Right here. This is the first in a series of three posts on scoping – another word for planning – that will give you an overview of the first steps towards an SAP translation project that covers all the texts you need and stays within budget. The key to achieving that is nailing down exactly what needs to be translated and what does not. If that sounds daunting or confusing, hang tight: we’ll walk you through it. To start, let’s talk about your reasons for translating customizing entries.
Why are You Translating?
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 you are facing one of the following four reasons to translate in an SAP system:
- to meet laws that require some texts to be in the local language,
- to increase flexibility when hiring staff on location,
- to improve user experience in a country where English proficiency among your employees is not all that good, or
- to make it easier for your local teams to feel at home in the new system.
In other words, you want to increase user acceptance.
Across the planet, proficiency in English as a 2nd language varies a lot.
So, it comes down to defining why you are translating portions 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 might have before. But that can only happen if you’ve defined the reason for your translation. Next, we’ll look at how SAP can help with translation.
What Does SAP Provide?
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 is not 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.
What are Common Approaches to Translation?
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 translation 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.
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.
What is Scoping in a Nutshell?
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.
What’s So Special about Customizing Entries?
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.
What is Customizing Delta Translation Manager?
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, that were created in your organization.
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.
