SAP standard texts, or SO10 texts, are probably one of the most-used text types in SAP systems. They are easy to use for end-users and developers alike, and they can hold shorter as well as longer texts. They are also a very strange breed – especially from the point of view of someone dealing with translations, there is nothing “standard” about them.
A Text Less Ordinary
SO10 texts are based on SAPscript, which has been around for many years. But unlike other SAPscript texts, such as F1 help texts, or most SAP user interface texts, every SAP standard text only exists in a single language. To translate it, there is no preexisting slot that you can fill with a translation – you simply create a new SO10 text with the same name, but in another language. This is very different from how most other SAP texts work, which is why SAP’s standard transaction for editing translations, SE63, does not support them.
If you want to translate an SO10 text using SAP Standard tools, you simply open the source text in display mode, and in a second window, you create a new text in the target language, with the same name as the original text. Then you enter your translation into that window. There is no translation memory to support you and propose matching translations that were entered before, and no quality-of-life features exist, such as spell-checking. And once you have saved your translation, and you want to transport it to another system, the next challenge awaits.
Transporting the Untransportable
SAP standard texts are not integrated into the SAP transport system. When you create an SO10 text, you are never prompted for a transport request. And if you want to transport an SO10 text, you have to manually enter it into a transport request, like this:
There are a few tools available in the SAP Standard to make this process easier (take a look at report RSTXTRAN, for example), but the fact that transport these texts is so convoluted illustrates that they are best used in an environment where they are not intended to be transported regularly.
SO10 Texts in Adobe Forms
Maybe the most common use case for SAP standard texts is custom forms, particularly in Adobe PDF forms. It’s easy to see why – SO10 texts look like an ideal container for longer, static texts that you may want to print on forms, such as a footer text or a legal text on a purchase order, for example. And for texts that you want your end-users to enter or modify, SO10 texts are indeed a very good option. These kinds of texts are rarely transported, and they don’t necessarily have to be translated – which means this technology’s two weakest points are out of the picture. A typical use case for this type of thing would be a custom framework that lets users adapt forms to fit their needs, but those user-created texts are only visible to the user who created them.
For typical developments, however, resisting the urge to put all your texts into standard texts is probably a good idea. Developments will need to be transported, and when custom forms are rolled out to other countries, they may also need to be translated. The missing integration into the transport system is bound to generate extra work, and once you tackle translation, it will become abundantly clear that storing your texts elsewhere is preferable. If you have ever spent a day copying and pasting SO10 texts manually so you can send them to a translator, you will know what I am talking about.
SO10 Alternatives and Best Practices for Adobe Forms
The best place to store shorter texts that you want to print on a form is probably a custom table. I like using cross-client tables of class C for this purpose. This kind of table is easily integrated into any translation process, and it is supported by SE63 as well as any tool for exporting translations, such as our own LUDECKE Translation Manager. For longer texts, text modules (transaction SMARTFORMS) can be a good option, since they are supported by transaction SE63 as well as any other tools that use the SAP Standard translation environment. These are texts that can exist in more than one language, and they can easily be transported.
But what if you have already created hundreds of SO10 texts, and now need to translate them? That is when you turn to third-party tools such as LUDECKE Translation Manager (LTM, which recently added support for exporting SO10 texts to XLIFF, an XML-based format that is supported by almost every translation industry tool. Of course, LTM can also help if you followed the above recommendations and mostly avoided using SO10 texts, but even if your implementation relies heavily on SO10 texts, LUDECKE Translation Manager is here to help you out.
Learn more about our SAP translation consulting services…