Translating SAP PDF Forms by Adobe

Published on 30 Sep 2019

SAPscript forms, smartforms, and Adobe PDF forms.

Form Designer texts

Text on Adobe PDF forms can be added from many sources. To start with, you can enter texts on the form itself, in transaction SFP. When you want an existing field from the backend to appear on the form, you can, for example, reuse a data element on the form. By default, the text label for the new field will then be copied from the label of that data element. You can rename the text label, but even if you leave it as is, the text on the form is then no longer tied to the original object, but now resides in the form itself, as a copy of the backend text.

Offloading text labels to backend tables

Instead of maintaining field labels on the form itself, another option is to maintain all static labels in tables in the backend system and pull them onto the form via the form’s driver program. This makes the text labels easier to handle for developers, and also allows for easier integration of form text labels into a translation workflow. From a translation perspective, a table entry is just another ABAP backend text, while texts maintained directly in the Form Designer require special handling. Form Designer text have their own SAP-internal text editor and their own SAP Standard export process if you want to translate them outside of the system.

Standard text and text modules

Most forms contain more texts than just field labels or table column labels. Various blocks of text can be included via text modules, which are created in transaction SMARTFORMS, or via standard texts, which are maintained in transaction SO10. Text modules can be included in your translation workflow fairly easily: you translate them the same way you translate smartforms. That means that on SAP ERP 6.0 EHP5 or higher (or on S/4), the standard long text editor can be used to translate them. SO10 texts are more tricky, starting with the fact that they cannot be translated in SAP Standard transaction SE63. In fact, there is no bilingual editor for SO10 texts available at all within the SAP system. And to export both types of texts, you have to rely on third party tools.

The translation environments for standard texts.

Customizing and master data

Many other types of texts can be appear on Adobe forms in addition to the ones I’ve mentioned so far, but the two most common ones are texts from customizing and master data tables. It can be as simple as displaying the name of product, or a currency. Those texts have to be available also in the local language too. And if customizing tables or master data texts are not already part of your translation scope, you may be forced to translate them in the context of rolling out your custom forms. After all, most of your customers or suppliers will expect the entire form to be displayed in their language. There are established methods for translating these kinds of texts, and you can choose between using SE63 or exporting them to a translation-friendly format.

Defining a translation workflow

As we’ve seen, forms can contain many different types of texts, and it can be a challenge to define one workflow that covers them all. They exist in various formats, such as Adobe LiveCycle Designer for PDF forms, SAPscript (text modules, standard texts) and ABAP short texts such as backend table entries, or any other backend texts that you have reused on a form. If you have a small number of forms and just a handful of SO10 texts, you can probably get away with translating the texts in the SAP system, but you have to be aware that you may have to do so in up to four different editing environments. If you need a sustainable translation workflow, it is often a better idea to set up a process that exports all the various texts into a single format. And if you also translate other SAP texts than just forms, you may need a translation strategy that covers forms, UI texts, roles, customizing, master data and more.

Fixing the layout in the target language

After you have translated all the relevant texts for your forms, you are not quite done yet. Upon testing the forms, you are may discover that because of the different lengths of the texts in other languages, the layout does not look right. You will find incorrect line breaks and texts where only half of the characters in a field label are visible. The easiest way to fix this is to ask the translators to a shorten the texts until the layout looks correct. Touching the actual layout of a translated form in transaction SFP is generally not a good idea, because changing the layout in one language will also affect the other language versions. It is much safer to simply shorten the texts that do not fit, and live with the fact that the forms will contain some abbreviated texts in the target language. If you want to go beyond this level of quality, translation is not the way to go. In this case, you are better off simply creating separate forms for each of the languages you support.