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.
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; 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: 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.
