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.
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.
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.
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.
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.
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-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.
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?
This is what the result of scoping may look like in the translation statistics.
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.
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.
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.
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 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 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.
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.
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