This is the third installment in my blog about SAP Translation Hub so far (see here and here). A lot has happened since SAP introduced this product over a year ago. As it has evolved, so too, has our SAP add-on tf-externalize for SAP® Translation Hub, which truly connects it to the ABAP world. Today, I want to tackle one of its features in more detail: the reference language.
The reference language feature has been there from the beginning, and it’s very, very useful. In fact, I’ve called it SAP Translation Hub’s “killer feature” on more than one occasion. The basic idea is that instead of sending one text in one language to SAP Translation Hub, you send two texts — one in the source language and one in the reference language. The reference language text helps disambiguate the text in the source language, which allows SAP Translation Hub to return a more accurate match. This means: you improve translation quality and minimize review work.
How are you able to select two texts that mean the same thing, you ask? That’s easy — if a button says Cancel when you log on in English and Stornieren when you log on in German, they reside in the same object and have the same ID. Now what happens if we send those two texts to the SAP Translation Hub?
Let’s say we are translating from English into French. A text like Cancel has two possible translations in French: Interrompre, which means “cancel an action,” and Annuler, which means “cancel an invoice.” In German, the situation is identical to French. Abbrechen is used for cancelling actions and Stornieren for cancelling invoices. This three-way relationship between English, French and German helps clarify which variety of Cancel we need. It disambiguates the English source text.
So, if you know that the English Cancel can be correctly translated into German with Stornieren, you know that it is much more likely that the correct French translation is Annuler and not Interrompre. How do you know this? Experience, you say? Well, SAP Translation Hub’s multilingual text repository works much the same way.
SAP Translation Hub stores not just a few text pairs, but a large number of so-called vectors. Each vector consists of a text in multiple languages that was once used to translate the same text, such as the same button on a screen, plus a large amount of metadata. This means that when you feed it not just one text, but two, it can select a vector that matches both the source language text and the reference language text. As a result, it can return a much better match.
Of course, tf-externalize also supports this reference language feature. This is especially useful in projects where the texts are translated into more than one language and high translation quality is expected. In such a scenario, instead of pulling translations from SAP Translation Hub for all languages at project start, we first get translation suggestions for one language only and ask translators for that language, say German, to start translation. So, in our example, we give the Germans a head start!
Once the German translators have translated the first few packages, we use tf-externalize for SAP® Translation Hub to get translation suggestions for all other languages from SAP Translation Hub. This time using German as a reference language. Plus, we also send the newly translated German texts in addition to the English source texts. The resulting translation suggestions will be of much higher quality, which allows the review work to go much quicker.
The translators for the other languages now start translating the completed packages in German, and the German translators start working on the next packages. Once these packages are completed for German, translation suggestions are again pulled from SAP Translation Hub for the other languages. This process can then be repeated until the translation is complete for all languages.
This process leads to a much more cost-efficient translation process overall, without compromising quality. However, for projects where speed is of the essence, it may not be possible to give one language a head start while the other translators are waiting. Apart from the initial delay, this scenario gives you lower translation costs with essentially no downside at all.
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.
If you simplify things a little, there are three main types of SAP texts that you may need to translate:
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.
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:
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.
If you call up this table in SE63, there is no way to tell your texts from SAP-delivered texts.
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 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.
CDTM shows the total lines in all tables identified, as well as the delta lines, which were created in your organization.
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.
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.
You can exclude tables that do not need to be translated, which are then marked as excluded.
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:
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.
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.
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