The case against externalization when translating custom-developed screens as part of a global SAP rollout
Most SAP customers need to extend the feature set of their SAP installation through custom development, which creates functionality for business processes that are not currently supported by SAP. The user interface for these new programs and transactions is initially only available in one language, since SAP offers language packs free of charge, but only for the SAP Standard. Furthermore, when you need your custom-developed screens translated into another language, there are a few points to consider…
Many SAP services providers offer tools that can be used to export user interface texts of custom-developed transactions and reports from the SAP system so they can be translated “offline”, for example in a Microsoft Excel spreadsheet. In systems using SAP Netweaver 7.31 and later, this externalization function is even built into the SAP Standard. The resulting spreadsheets essentially have two columns: one for the source language (generally English or German) and one for the target language. The spreadsheets can then be handed off to translators, who can enter their translations into the target language column.
This approach has its advantages. There is no need to train translators to use the translation environment in the SAP system, such as transaction SE63, which is rather complex. Furthermore, IT does not have to worry about setting up the translation environment. This keeps costs low, at least initially.
Translating without context information
But this convenience comes at a price. When end users test the translated screens, they tend to run into a significant number of mistranslations. The problem is that an Excel spreadsheet provides essentially no context for the user interface texts to be translated, even for the most experienced SAP translator. Let‘s say we’re translating from English into German – does the word “Account” mean “bank account” (German: “Konto”) or “customer” (German: “Kunde”)? Will the “Check” button create a bank check (German: “Scheck”) or verify your entries (German: “Prüfen”)?
Cases such as this one are very common for any language combination, and a spreadsheet alone offers no guidance whatsoever on which translation is correct. Transaction SE63, on the other hand, makes it fairly easy for an experienced SAP translator to find out which texts appear together and what the translated screens will look like to the end user. Using the SAP system as a resource to find out context information, translators can ensure that they enter correct and high-quality target language texts.
The benefits of planning ahead
It’s true that, initially, setting up the translation environment in the SAP system, which enables you to use SE63 as intended, results in additional work. But in most cases, it is significantly more expensive to deal with large numbers of translation errors later on. Salvaging such a project means having to test and retest screens, as well as finding and correcting the relevant texts in the SAP translation environment, which is not always easy and takes a lot of time. In most projects, putting in the initial effort saves a lot of work in the long run.
That said, externalization does have a place in SAP translation projects, for example when translating large master data tables, where working in the system would provide no additional context information to the translator; however, when it comes to translating SAP screens, which are the user interfaces that end users work with on a daily basis, translating in SE63 is by far the better option.
About the author
Martin Lüdecke is the Head of SAP System Translation at text&form and has been working with SAP Translation Tools since 2006. He collaborates closely with SAP’s language technology experts and is constantly expanding his knowledge, which enables him to bring the most up-to-date SAP translation expertise to each project. He is a certified Technology Associate – SAP Netweaver.
