Introducing CDTM – a better way to translate your SAP customizing entries

written on by Jenny Nilén.

When rolling out your SAP at an international location, one of the things you might need to do is translate the language-dependent parts of SAP customizing entries. These texts have always been unwieldy: It’s hard to identify the exact texts you need to translate, and even if you do, the translation process can be clunky. The Customizing Delta Translation Manager (CDTM) is here to make things considerably easier.

What’s so difficult about translating SAP customizing entries?

If you simplify things a little, there are three main types of SAP texts that you may need to translate:

  • texts from Z programs
  • custom forms, and
  • texts from customizing entries.

Identifying what you actually need to translate is not always easy for each of those, but it’s especially tricky for customizing. This is because most of the texts you have created during customizing reside in tables in the SAP namespace. Why can this be a problem, you ask? The thing is, many if not most of those tables are not empty when you start customizing. They already contain texts for the part of customizing that is delivered by SAP. And why translate the texts delivered by SAP? After all, most of the time, the translations you need will be provided to you by SAP via language packs. This means there are texts created by your organization and texts delivered by SAP residing in the same set of customizing tables.

SAP Customizing Table which shows entries both from SAP and from the SAP customer

This table contains both texts created in your organization and texts created by SAP.

This is why you face two main problems when you want to translate SAP customizing entries:

  • finding out what texts were created during customizing
  • isolating those texts so they can be easily translated

If you rely on the functionality provided by the SAP Standard, most often, you end up doing one of two things. Either you invest time and resources to manually identify the texts created during customizing and ask your translators to call up entries one by one for translation. Or, you decide to translate entire customizing tables, including entries delivered by SAP. This means you either spend too much on translation, or your internal resources invest too much time finding out what’s what, or both.

Table as seen in transaction SE63

If you call up this table in SE63, there is no way to tell your texts from SAP-delivered texts.

Enter Customizing Delta Translation Manager (CDTM)

To solve this problem, we built an SAP add-on solution. We’re calling it Customizing Delta Translation Manager, or CDTM for short. This tool not only identifies the texts created or changed during customizing, but also manages the entire translation process. The basic idea behind the tool is to scan your development system for customizing entries that were added or changed, to pull out the texts associated with those entries and write them into temporary objects. These temporary objects can then be translated using the SAP Standard translation tools, such as transaction SE63, or exported for translation using tf-externalize for SAP® Translation Hub, another add-on we are offering. After translation, the newly translated texts will be written back into the original tables.

The Customizing Snapshot

The heart of the tool is what we call a customizing snapshot. This snapshot contains all the text tables that were modified in your development system, or only those tables in the transport requests you provide. The first thing you learn after you have created a customizing snapshot is how many texts those text tables contain, and more importantly, how many of those texts were created by your organization. In a way, considering that you’ll probably only need to translate those texts, you’ll see right away how much the tool will save you.

Snapshot in Customizing Delta Translation Manager

CDTM shows the total lines in all tables identified, as well as the delta lines, which were created in your organization.

Using Customizing Snapshots for Scoping Translation Projects

But that’s not the only thing you learn from a customizing snapshot. The snapshot also offers detailed information on each text table, such as table name, development package, and terminology domain, which is roughly equivalent to the application component or SAP module, such as FI or MM. And of course, it also includes the number of total lines and the number of lines created in your organization. If you use the standard SAP translation environment, you can also get more granular information on new, modified and translated texts in each table. This information, which you can export to a spreadsheet, is a good basis to scope your SAP customizing translation project.

Knowing what to exclude

Each table within the snapshot can be excluded from translation. And based on the exported list of tables, it’s easy to exclude all the tables you don’t need. You can, for example, exclude all tables from BC for all languages, or exclude all tables for PM and FI for Spanish, or exclude all tables from a certain namespace. This makes it easy to scope your project in a way that you only translate the tables that you need into any language of your choosing.

Excluding customizing tables from translation

You can exclude tables that do not need to be translated, which are then marked as excluded.

Delta Objects and Original Tables

Once you have defined your translation scope, you create what we call delta objects. These are special translation objects that each contain texts from one text table, but only the texts that were created in your organization. These objects can then be translated using the SAP Standard translation tools. In fact, they are fully integrated into the translation environment centered around transaction SE63. Furthermore, our add-on tf-externalize also allows you to export the texts for translation to a translation-friendly format.

Once the texts have been translated, be it using SE63 or outside the SAP system, CDTM writes those translations back into the original text tables, thus finishing up your translation project:

The finished SAP translation

Making the Most of CDTM

To sum up, Customizing Delta Translation Manager helps you decide which of your customizing tables to translate and which ones to leave out. It also saves time and money by giving you the option to only translate the SAP customizing texts that you actually created, skipping the entries  created by SAP. If you plan to translate Z programs and forms, it fully integrates with your larger SAP translation project, whether you work with the SAP Standard tools or with tf-externalize. It runs on systems on SAP Basis 7.40 or later.

 

Click here to learn more about Customizing Delta Translation Manager.

Exporting SAP Long Texts for Translation with tf-externalize

written on by Martin Lüdecke.

For quite some time now, translators as well as SAP users have voiced their dislike of the editor that transaction SE63 offers for long text translation, that is translating SAPscript-based long texts. While SE63’s editor for short texts is quite powerful, its counterpart for long texts is bare bones at best. We’ve made a tool to change all that.

Translation Re-Use – Not an Option

The main criticism that is often leveled at the long text editor is “…it does not even offer translation memory integration”. And indeed, if you have translated a sentence in a smartform or an F1 help text, you may, a few objects down the road, come across the same sentence again, and have no way to reuse your old translation or any translations entered by other translators. This means that translation takes a lot longer than it needs to, and is quite a bit more expensive.

The SAP Standard editor does little to make a translator's life easier during long text translation.

The SAP Standard editor does little to make a translator’s life easier during long text translation.

Short texts, on the other hand, such as text elements and data element texts, have a fairly nifty translation memory system called the Proposal Pool. This tool is tailored specifically to SAP translation (I wrote about it here and here). But guess what – all the translations from reports, data elements or other short texts are not proposed for reuse during long text translation either. This often makes it hard to keep the terminology consistent between the user interface texts and the F1 help, for example.

Long Text Translation That’s Faster, Cheaper, and Actually Better, Too

Our SAP add-on tf-externalize solves that problem by exporting SAPscript-based long texts to the localization interchange format XLIFF. This XML-based format has been an industry standard for some time. Exporting the long texts enables you to translate them using translation industry tools such as SDL Trados Studio, where translation-memory integration is part of the standard functionality. This allows for much speedier, and much more cost-efficient translation of these texts. And the quality is better too, since any existing translations matching new texts will be proposed to the translator at the time of translation. And past translations are fully searchable as well.

tf-lte exports long texts to the XLIFF format, enabling an efficient translation process.

tf-externalize exports long texts to the XLIFF format, enabling an efficient translation process.

If an experienced SAP translator working on long texts has access to the SAP system the texts were exported from, for example because they are already working on short texts in transaction SE63, they can still take advantage of the resources available there. This is due to the fact that all the metadata of the original long texts objects is preserved in the downloaded files. So when the translator is translating a F1 help text for a report, for example, they can simply call up the translation object that contains that report’s text elements and match their translations to those of the short texts.

Seamless Integration with SE63-Based Translation

The add-on itself consists of two ABAP reports, one for exporting long texts and one for importing the translated XLIFF files. All SAP languages are supported, and you can choose to include already translated long texts in the export, for example for review purposes – although they are excluded by default. It is also fully integrated into the SE63-based workflow. After the export, the report outputs the number of new, modified and translated lines of the objects that were just exported. These numbers follow the same logic as the translation statistics that are available as part of the SAP Standard (tcode SLLS).

tf-lt shows export results using the same logic as the SAP standard translation statistics.

tf-externalize shows export results using the same logic as the SAP standard translation statistics.

tf-externalize also supports the fingerprint-based versioning system for long texts that SAP introduced with Netweaver 7.4. This ensures that when a long text is changed in the original language by a developer, the status of the French and Chinese versions of that long text will change to modified, just as it would had the long text been translated in SE63. This fits in well with our preferred method of SAP translation: using SE63 for all user interface texts in most cases, and now exporting long texts for more consistent and faster translation.

For now, tf-externalize supports long text translation for all F1 help texts as well as IMG documentation and smartforms. New text types will be added on demand. tf-externalize supports systems on SAP_BASIS 7.40 and higher.

What’s in an SAP Translation Line?

written on by Martin Lüdecke.

Once you have defined the scope of SAP translation in your SAP system, the translation statistics and SE63‘s worklist give you the translation volume in „lines“. But what can you expect an SAP translation line to contain?

What's in an SAP translation line? View of SAP translation statistics

This is what the result of scoping may look like in the translation statistics.

The SAP Translation Line

In the SAP system, translation volumes are measured in so-called “SAP lines”, which can range from 1 to 255 characters in length, from an “OK” button to a full error message. When translating from German or English, you can expect an average SAP translation line to contain 3,5 to 4,5 words. An experienced SAP translator can process up to 500 SAP lines per full working day, on average, depending on how difficult to translate the source texts are, and of course, how well they are written.

This dialog box an SAP translation line ("OK") with two characters, a text with 43 characters!
This dialog box contains texts ranging from two characters in length (“No”) to a text with 43 characters.

Different Text Types

There are three types of texts that can be relevant for translation, short texts, long texts, and forms. Each of those is processed by the translator using a different built-in text editor. Short texts are texts that appear on the user interface, such as text elements, button texts, or table entries. Long texts are used in F1 help texts, for example. And there are also different types of forms, such as Smartforms and SAPscript forms, the latter of which come with their own editor.

The explanation text in the F1 help box is a long text, while the rest of the texts visible on this screen are short texts
The explanation text in the F1 help box is a long text, while the rest of the texts visible on this screen are short texts.

How Accurate Are Our Estimates?

For short texts, the metric of „3,5 to 4,5 words per SAP line“ is fairly accurate, and since short texts are the most common text type by far, this metric will give you a good idea of how many words need to be translated. Things are more tricky with long texts and forms, however – for those text types, it is not strictly accurate to talk about a number of lines, since the number SE63 give here is more of a „footprint“ than an actual line count.

With long texts and Smartforms, lines are generally much longer than 4-5 words, since these are full sentences, but on the other hand, tags such as <b></b> are counted towards a line, and both headings and empty lines count as full lines as well. With SAPscript forms, things are even more complicated, which starts with the fact that the names of formatting elements such as „Italic“ are also translated.

But looking at translator throughput on average over many years of SAP translation projects, the „up to 500 lines per full working day“ metric is generally fairly accurate on average, be it for short texts, long texts or forms.

Exceptions to Prove the Rule

There are exceptions, however – a few text types that come up in SAP translation such as SAP Forms by Adobe that cannot be measured in SAP lines, since SE63 displays them as having one single line in the worklist, even though they actually contain a lot more text. The form in the screenhot below contains 543 lines of texts (this number varies by how you choose to display the text), but in SE63‘s worklist, it is displayed as a single line.

A PDF form in the worklist
A PDF form in the worklist.

The same PDF forms in the editor
The same PDF forms in its editor.

The Proposal Pool: A Short Introduction

written on by Martin Lüdecke.

A key feature of transaction SE63, the centerpiece of SAP’s translation tools, is the way existing translations can be reused. For each source text that comes up for translation, SE63 will check in the proposal pool if an identical text has been translated before. And if so, it will propose the translation that was entered last time so that the translator can apply it to the new text by simply double-clicking it. This not only saves time, but also improves translation consistency.

The Proposal Pool: Double-click to reuse!

The proposal pool functionality is somewhat similar to what the translation industry calls a translation memory, but has a number of differentiating characteristics that promote translation quality.

First, it links the translation to the proposal, which means that if the proposal is deleted or changed so it no longer matches the translation, the text loses the Translated status and will come up for translation again. This is very helpful when making changes or corrections to translations across an entire SAP system, and it promotes consistent use of terminology.

Secondly, it only allows exact and case-sensitive matches. When translating user interface texts that frequently only consist of a single word, is it very useful to only be offered exact matches instead of large numbers of “fuzzy” matches.

The proposal pool also supports proposals that are specific to an SAP module such as FI or MM and that will not be proposed for texts from other modules. It is also possible to create abbreviations, and you can assign one of four quality statuses to mark a translation as the only valid option or as one of several possible translations for a source text, for example.

And finally, the proposal pool is updated live so each translator always has access to their colleagues’ latest translations. This built-in feature is similar in functionality to a translation memory server, which many CAT tools only offer as a very expensive add-on option.

These features make the proposal pool better suited for SAP translation than other CAT tools, from an individual translator’s perspective, but the proposal pool concept also has a number of interesting applications for project managers and consultants, but that’s a story for a different blog post.

Combining Language Supplementation and SAP Translation

written on by Martin Lüdecke.

When it comes to filling the gaps in an SAP language version, knowing where to do so is critical. If perfomed in the wrong system, language supplementation can render any subsequent translation activities extremely difficult and very costly.

What is Language Supplementation?

SAP delivers the interface for their products in up to 39 languages, depending on the product, but English is the only “complete” language, which means each text in SAP Standard exists at least in English — even German is not 100% complete. If you’ve installed an additional language, this language will also not be complete, and there will be “gaps” in the user interface where either no text is displayed or a technical code such as ITEM_TYPE is visible. And this is not only a usability issue — certain functions will not execute correctly as long as there are texts missing.

To remedy this, SAP recommends performing language supplementation, which means that each missing text in an installed language is filled in with the corresponding text from another language. Supplementing Russian with English will therefore produce a user interface that is mostly Russian, but you will see an English text here and there. This solution may not be perfect, but it ensures that all there are no runtime errors because of missing texts, and it improves usability.

When Language Supplementation leads to mixed language screens
Supplementing a language leads to “mixed language” screens.

Language Supplementation and Translation

Language supplementation has a strong impact on translation, and knowing where to perform supplementation goes a long way towards ensuring that your SAP translation project runs smoothly. A good rule of thumb is, do not supplement a language if you are planning to translate into this language in the future. And it’s good to remember that language supplementation cannot be undone.

After supplementation, all the gaps in a language version, say Portuguese, are filled with texts from the supplementation language, say, English. More precisely, all the gaps where corresponding texts exist in the supplementation language are filled in, and since every text in the SAP standard exists in English, any language in a freshly installed SAP system can, in theory, be supplemented with English, and there will be no empty texts after supplementation. But that also means that when a translator translating into Portuguese in transaction SE63 comes across a line of text that was supplemented, the target text line will not be empty. Instead, there will be text in a different language, for example English.

A supplemented translation object in SE63
A supplemented translation object in SE63; the target language is Portuguese, but the English text has already been filled in.

Planning Translation into a Supplemented Language

This can be an issue when you are trying to identify texts residing in the SAP namespace that need to be translated, such as texts from the SAP standard and texts from customizing. For these texts, you usually rely on the target language text being empty to identify the texts that are untranslated. When working in the SAP namespace, translators will, as a rule, only edit objects that contain untranslated texts, which means they will look for objects with at least one empty target language line. And if all target language lines have been filled using language supplementation, the translator will, theoretically, have to comb through thousands of lines manually to find the texts that actually need translation.

Supplementation also causes problems in the translation statistics (transaction SLLS), which are generated at the beginning of a translation project and provide you with information on the number of texts that need to be translated. If you’ve supplemented the target language prior to generating the translation statistics, the texts created during customizing will be indistinguishable from texts delivered by SAP, which makes it impossible to estimate project costs or set a reliable timeframe for translation.

Translation statistics for a supplemented language
Translation statistics for a supplemented language: This is not what you want to see at the start of an SAP translation project.

To illustrate this, let’s say you are planning to translate the customizing entries that were created as part of an SAP implementation project from English into Portuguese, but language supplementation has already taken place for Portuguese in your development system (supplementation language was English). As a consequence, all the customizing texts that were created will now no longer be untranslated, and to anyone looking at the translation statistics or a translation worklist, they will look identical to the lines that come from the SAP standard. That means the Portuguese translators can now only find the translation-relevant texts manually, which takes much too long for an SAP translation to be completed within a reasonable timeframe, rendering translation very expensive. Think of it this way: The effort of finding the correct translation objects is comparable to developers identifying every single text that could be relevant for translation, since that is exactly what the translators need to do in that case. They can no longer rely on the SE63’s tools to find the texts for them.

Everything in its Right Place

To avoid causing problems in translation, language supplementation should only be performed in systems where no translation activities will take place in the future. That usually means language supplementation should never be performed in a development system, but only in a productive system. A test system can be supplemented, but in language testing it is in fact easier to troubleshoot language issues if supplementation has not taken place yet. But since the test system is often a copy of the productive system, this is not always possible.

If you follow this guideline, the texts that are relevant for translation will be empty for the target language when you need them to be, translators will be able to easily identify them, and translation costs should remain under control.

About this Blog

This blog is about SAP translation and SE63 (find out more here and here). I am a consultant and project manager for SAP translation projects.  As I am the sole contributor on this blog, it does not necessarily reflect the views of text&form, but only my own. If you have any feedback or questions, please find me on Twitter at @martinludecke.

– Martin

Your Point of Contact for SAP Translation 

Martin Lüdecke 

Director of SAP Translation

Logo Header Menu