Translating the user interface texts of one or more Z transactions into another language is a typical requirement in rollout projects where SAP GUI is deployed, meaning SAP Fiori is not in the picture, or only used for select processes. If you use a purely manual approach to tackle this task, it can be a lot of work, but there are tools to help you.
Finding the Right Puzzle Pieces
SAP GUI user interfaces, as a rule, display texts from many different types of objects. On the first level, there are the text elements, screen painter texts, and GUI statuses of the report that is called up by the transaction. But there are also objects such as classes, function groups, data elements, messages, and so on. And custom SAP transactions can be pretty complex, with multiple screens calling up hundreds of different objects. In that sense, finding out exactly which texts need to be translated can be like assembling puzzle pieces.
One typical approach to tackle this task is to ask developers to come up with a list containing all translation-relevant objects. This can be daunting since developers are bound to spend hours, if not days, for each transaction – and the original developers of the Z transactions may not even be around anymore. Once you have a spreadsheet that lists all relevant objects, the next steps would be copying out all those custom SAP transaction texts so they can be translated. Make no mistake – this is an immense effort that makes this approach impractical if you are translating more than a handful of SAP transactions.
The Right Tools for the Job
A more efficient approach is to rely on a tool such as LUDECKE Translation Manager that scans the code of your transactions to find out which objects are being called up. This “reference analysis” approach partly relies on where-used lists. This way, the tool can even find objects that are accessed several levels deep, such as a report calling up a function group that then calls up a class that then pulls a text from a data element, to give a typical example. This usually works very well, but you cannot expect more than a 95-99% hit rate, since developers are a creative bunch and are absolutely able to come up with designs that no tool can account for.
But then again, the same is true for a developer sifting through code manually to find all relevant texts – the results will never be 100% perfect. In most projects, it is acceptable that some untranslated texts remain and are only found during user acceptance testing.
Another advantage to using a dedicated tool to SAP translate transaction texts is that it collects all the translatable texts are collected in one central place in your SAP system, and it’s easy to export them for translation or collect them in a worklist, ready to be translated in transaction SE63. There is no need to copy and paste texts – once you have run the analysis, you are ready to start translating.
Initial Translation Versus Continuous Translation
This “automatic analysis” approach admittedly does have its limits – not because it may miss a few objects, but because it is not well suited to continuous translation. What do I mean by that? The first time you translate a set of custom SAP transactions, the automatic analysis will produce good results. But as developers make changes and add functionality to the transactions, they also add and change texts – which will also need to be translated at some point. But since these changes are incremental, it becomes increasingly cumbersome to run a full analysis every time.
This is especially true in scenarios where you are regularly deploying new versions of existing transactions, and even more so if you are using Agile methodology. In those cases, you are much better served by doing a full “automatic analysis” for the initial translation, but using a different approach for continuous translation. You can take advantage of the fact that all changes your developers make are logged in transport requests and scan these transports for translatable texts. This can be done using the SAP Standard translation tools centered around transaction LXE_MASTER.
Once the scope is defined (for initial or continuous translation), the next step is to choose the translation environment (a “translation editor”) where the translators will be entering the target-language texts. Which tool you end up using here should depend on what your translators are familiar with. If you are working with a veteran SAP translation partner, the answer may be transaction SE63, since their translators will know this environment well. If you are translating in-house, exporting the texts into a simple translation tool that requires little to no training may be a better option. But once you have defined the translation scope and you know who will do the translation, you have many good options here.
Learn more about our SAP translation consulting services…