The Scoping Series, Part 3: Translating Texts from Productive Systems

So, you’ve worked your way through parts one and two of this series, and you’ve taken the first steps towards an SAP translation project that covers all the texts you need and stays within budget. While those first two articles dealt with translating texts on your developments systems, this one is all about texts that live on your productive systems. In some ways, things are simpler here, but the stakes are also a lot higher.

Development Versus Production

Most of the texts you may need to translate as part your global rollout, such as customizing texts, Z developments, and forms, are created on your development system. This means your IT organization has full control over when these texts are created, changed, and transported, and the same goes for translations of these texts. Many texts, however, are created by your business departments, directly on the productive system. These often include SAPscript standard texts, Report Painter texts, and of course, master data texts.

This is where the major types of texts are moste often translated SAP translation scoping

This is where the major types of texts are most often translated.

I have some good news about these texts. It is not actually that hard to include them in your overall scope of our SAP translation project. Your business departments and key users usually know pretty well which Report Painter reports they are using (if any), and which master data needs to be available in the respective local language. On the other hand, this knowledge may be scattered across your organization, depending on how big your company is, how many SAP modules you are using, and what your org chart looks like.

What’s So Hard about Master Data?

Master data texts can be challenging in a number of ways. For example, there is no language supplementation for master data texts. That means that a material description is by default only available if you are logged in in the language it was created in. So, if you are logged in in Japanese, each material description will either be available in Japanese (because it has been translated), or it will not be displayed at all. To make matters worse, master data texts are frequently visible to your own customers, for example, on delivery notes or invoice forms. This is why you should ensure the right master data texts are translated.

Master data texts are also typically very repetitive, chock-full of abbreviations, and often very cryptic to the uninitiated. This makes them very hard to translate correctly and often a pain to work on as a translator. Just imagine translating 5,000 names of cost centers for three days straight…All the more reason to translate only the master data you need.

I’ve Got Translators in My System

There are many scenarios where master data texts need to be migrated to your SAP first. Here are a few:

  • Names of accounts from your charts of accounts
  • Cost element descriptions
  • Material descriptions
  • Characteristics descriptions

But even if the master data texts are already in your SAP system, how to best translate them is not straightforward.

Let’s imagine you know which master data tables are relevant for translation, and which exact data records from each of those tables are needed. You even know which Report Painter reports need to be translated. You should be good to go, right?

Well, almost. While you can in theory call up each record individually in transaction SE63 and translate it, in most companies, allowing translators to work on the productive system is not an option: You need an option to export the master data texts for translation.

How to Export Completely and Never Be Found

The SAP Standard does offer functionality to export text tables for translation, but unfortunately, it always exports the entire table. And to make things worse, in the exported files, there is no information available on the table key of the individual exported text, such as the material number (for material descriptions) or the chart of account and the account number (for accounts). Imagine you have 500,000 material descriptions, 10,000 of which you need translated–and there is no way to export only those material descriptions that need translation. Even if you export them all, you cannot identify the ones you need in the export files.

Data Browser Table SKAT selection screen

I don’t think we need to export and translate all of these accounts …

At text&form, we have developed an SAP add-on called Master Data Translation Manager to solve this problem. This add-on lets you pick and choose which master data records or Report Painter texts to export and institutes a numbers of safety features to ensure the export and, more importantly, the import, work flawlessly. We export to XLIFF, which is supported by all major translation industry solutions.

Very Standard Texts

The one type of productive text that does not simply reside in a text table is SAPscript standard texts. These texts are used often as dynamic texts, headers or footers in SAPscript forms, smart forms, or PDF forms. Thankfully, most organizations don’t have too many of them. Also, remember that while these texts are most often created on productive systems, you can create them on development systems as well. They can be transported, albeit manually.

display standard text - SAP translation scoping

A SAPscript standard text.

Armed with the right export tool, translating productive texts is not rocket science. But you do have to be extra careful when exporting and especially when importing them. If you are translating master data, Report Painter texts, SAPscript standard texts, or productive texts into a new language for the first time, make the translations available to your test system first so they can be reviewed as part of your user acceptance tests. And since new master data texts are created all the time, consider looking into solutions for translating new texts going forward.

Martin Lüdecke is the founder of LUDECKE, our SAP Consulting Partner. Until 2019, he worked for us as Director of SAP Translation. He supports us with SAP consulting and software development work, and he sometimes guest blogs here. You can find his own blog at Notes on SAP Translation.