Even before you are rolling out SAP internationally, there is something you may need to translate as soon as you start doing business in a new country: your custom forms. After all, your forms are sent to your customers and suppliers, so having them available only in English is generally not an option. Here’s a brief overview of how translation works for PDF forms.
Do you have a question about translating SAP forms? Let us know!
SAP and its Forms
SAP has employed a number of form technologies over the years, starting with SAPscript forms, then smartforms, and most recently, PDF forms based on Adobe Document Services. Each of these has its own quirks when it comes to translation. SAPscript forms are famous among translators for an editor that is very unwieldy, with texts distributed across many different screens. Smartforms are a lot more translation friendly, but come with their own challenges for translators. For example, there is no easy way to test a translated form’s layout.
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 Texts 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.
Customizing and Master Data
Many other types of texts can 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 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, for example using our LUDECKE Translation Manager.
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.
The transaction code to maintain translations on Adobe form is still SE63 in most cases, since you can use it to call up Form Designer texts (object types PDFA and PDFB), text modules (object type SSF) and any tables (object types starting with TA). The only exception are SAPscript standard texts, which have to be maintained in transaction SO10 and are not supported by SE63. But 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 need to translate other SAP texts than just forms, you will need a translation strategy that covers forms, UI texts, roles, customizing, master data and more.
Would you like to know more? Let us know!
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 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 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.
Learn more about our SAP translation consulting services…