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.
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.
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.
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.
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.
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.
One of the tools in the toolbox that is SAP’s transaction SE63 is a feature called automatic distribution. It is often touted as an automatic translation feature, which it is to some extent, but some manual work is still required to use it. Here’s a short summary of what you can and cannot expect.
The automatic distribution feature was developed by SAP to avoid having to translate duplicate texts manually each time. A text such as “Back (F3)” (and we are talking about complete text strings, not the word “Back”) occurs thousands of times in an SAP system, and it makes very little sense to enter the same translation again each time.
Some texts are used over and over again in an SAP system.
As a first step, this feature collects all duplicate texts in the part of the system that you specify (SE63’s object list and worklist concepts are used here). You can also define what is considered a duplicate text by entering the minimum number of times the text has to occur. These texts are bundled in waht are known as “virtual translation objects” that a translator can process in transaction SE63.
In a second step, the duplicate texts are pretranslated by a translator, and finally, the translation for each text is distributed automatically (hence the name) into all the places it occurs in the relevant part of the SAP system, which means that thousands of texts do not have to be translated manually.
So far, this sounds fairly straightforward, but there is still a piece missing. The thing is, the translator who pretranslates the duplicate texts will not actually translate all the texts. This goes back to the fact that many texts have more than one possible translation, such as in this example from German to English translation:
The German text “Anlage” can mean two completely different things in English.
This is what linguists call an ambiguous text, and each time this text comes up during translation, the translator has to make a decision about which meaning is the correct one in this case. Making a blanket decision by translating this text once and then distributing it means that the translation filled into the different screens will be incorrect half of the time. This is why, during pretranslation, the translator will skip any text that he or she considers ambiguous.
If some of these texts should not be distributed automatically, the translator will skip them.
This makes the automatic distribution fairly safe, since only the texts that should be translated the same way every time will be distributed. And as an added bonus, it also ensures that the same terminology is used in all distributed lines. But note that, since the decision about what to distribute and what to leave out is so critical, the translator performing the pretranslation should have considerable experience with SAP translation. This is no task for beginners.
In real world usage, automatic distribution will usually save between 10 and 35 percent of work (and costs) if it is used conservatively, as it should be. Across a large-scale SAP translation project, this will mean many days or even weeks of work.
In this example, just under 20% of the texts were translated by automatic distribution.
In summary, I recommend using automatic distribution for any but the tiniest projects. It is a real time-saver.
If you have translated texts in your SAP system, such as customizing or master data texts or even entire transactions or reports, identifying and updating the translated texts later can prove to be difficult. This issue can be avoided by setting the Translated status in transaction SE63 for each translated text.
Translating your custom SAP developments, customizing or master data texts takes a great deal of effort. It can therefore be frustrating to find out a few months or years later that maintaining those translations is almost as much work. The fact is, after an SAP translation project is completed, there are still always texts being added or changed in development or customizing, and when a text is changed, its translations need to be updated as well to reflect the meaning of the new source text. Failing to update a translation means that users logged on in any but the original language see an outdated text on the user interface, which can be a serious usability issue.
A (fictional) example from English to French translation.
In this admittedly extreme scenario, a button called Save was translated to French as Sauvegarder. Then, a developer changed the functionality of the button and renamed it to Delete. Now, if the translation is not updated, this may end up confusing users logged on in French quite a bit (clicking the Sauvegarder button may not produce the desired results…). But in order to update the French translation, you have to identify the modified text first. One way to do this is for the developer to update the translations in all languages installed in the SAP system every time he or she changes a text. But to do this for every single text is clearly is not a sustainable process.
Luckily, it’s fairly easy to identify modified texts after the fact when translating in the SAP system using transaction SE63, and the modified texts can also be automatically collected and added to translators’ worklists for them to translate. But there is one requirement – modified texts can only be identified easily if the Translated status was set when they were originally translated. This status is set by adding the translation for a text to what is known as the “Proposal Pool”. One way to do this (and certainly not the only one – the Proposal Pool is a fairly complex thing) is via the Create Proposal Immediately icon in SE63:
In practice, setting this status is frequently neglected when translation is performed by developers or by the employees from the department using the translated texts as part of their daily work. Another reason for this status not being set can be that an alternative SAP translation tool was used to perform the translation, particularly one of the many third-party tools that offer to export the SAP texts from the system for easier handling. This is because most of these tools do not set the Translated status when the texts are reimported into the system (which is why I would strongly advise against using these tools for most projects). Both scenarios lead to a situation where identifying single texts that were modified is very, very cumbersome, and the best solution is often to perform a review of all translated texts just to find the texts whose source texts were changed.
To an experienced SAP translator working in SE63, however, setting the Translated status consistently is part of the standard working procedure, since the way SE63 works requires that the status be set. But even when your own employees are performing the translation themselves, there are good reasons for asking them to always set the target language texts to Translated, and by extension, to work in transaction SE63. In order for them to use this fairly complicated transaction competently, some training may be required, but investing in training (or translation outsourcing, for that matter) pays when the alternative is ending up with translations that are virtually impossible to maintain or update.
For German companies that have traditionally developed the user interfaces for their custom SAP reports and transactions in German, one of the first challenges when expanding to another country is translating these SAP screens into English. Getting the translation right and ensuring high quality is a good idea in any language, but it’s especially important for English.
In many countries, an English translation may in fact be the only translation you need. For all Anglophone countries, it’s obvious that only an English version is needed, but there are many other countries where creating a local language version may not be necessary for many SAP transactions. This depends as much on the country you are expanding to as it does on the level of education and English proficiency of your employees. A bank analyst in Singapore, for example, will very likely be able to get his or her work done efficiently using SAP with logon language English, without having to constantly consult a dictionary. A factory worker in China, on the other hand, may not.
That being said, a handful of transactions or reports may still require translation into the local language. Local regulations may require a local language user interface to be in place, and since different transactions will be used by different groups of users, some of those user groups will be more proficient in English than others. Plus, forms and master data that are visible to customers will need translation into the local language in any case. But the point is, many transactions or reports will only need an English user interface, and can be deployed in many different countries, not just English-speaking ones.
This makes the English translation of your custom SAP transactions and reports much more visible than all other language versions, since a far larger number of users will log on in English on a day-to-day basis. For SAP translation, this has two main implications:
In most SAP translation projects, especially if translation takes place in SE63 as SAP recommends, most languages translate not from German, but from English, even if the texts were originally developed in German. This is because, for many languages, especially non-European languages such as Chinese, Japanese and Arabic, you’d be hard-pressed to find translators who both know German and have the necessary SAP expertise, which is why English is most often selected as the source language.
For transactions that were developed in German, this leads to a two-step translation scenario, where the texts are first translated from German to English, and then from English to the all the other required languages. This means that any incorrect translations entered by an English translator will very likely lead to incorrect translations in a number of other languages (“follow-on languages”) as well, because the follow-on language translators are working from an already incorrect source text.
This makes getting the English translation right especially important. When every mistake made automatically causes a number of other mistakes, it makes sense to look at what you can do to ensure that your English UI is of the highest quality.
Any translator will tell you that it’s always a good idea to invest in translation quality. But with SAP translation, ensuring that the largest chunk of that investment goes towards the English translation has the greatest benefits. Once that decision is made, the obvious place to start is to ask departments to test the translated reports and transactions before they go live. It is also helpful to plan for a terminology project before starting the actual translation, to ensure that the terminology used in the project has been approved by the departments and is used consistently by the translators.
The biggest factor by far in improving translation quality, however, is working with experienced translators. It can be tempting to ask your German ABAP developers to enter English translations themselves by branching to SE63; after all, a lot of them speak decent English. In most cases though, it turns out that, while the English texts created by German developers sound good to a German, they are often very hard to understand for the end users as well as the translators translating from English into their native language.
Experienced SAP translators will not only know the correct terminology and have the training and experience to work with a complex tool such as SE63, but they will also know how to look up any context information they require to produce a correct translation, and they will know how to use the developer transactions in the SAP system to do so. This goes a long way to improve translation quality, and as we’ve seen, nowhere is this more important than with the English translation.
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.
Director of SAP Translation