Once SAP translation is done, language testing starts. For many years, correcting translation issues identified by testers has been a complicated and slow process that took up a significant part of the transation budget. With SAP’s 1Q language feature, you can now bring down the cost per ticket and implement a streamlined language testing workflow.
Translators as Language Testers
When you are testing newly developed functionality in your SAP test or consolidation/integration environment, and you find that something is not working right, who do you turn to? Well, development, obviously, are the ones to correct the bug. But what if you come across an issue with translation? Maybe a translation is missing, or the terminology used is not as you expect, so you open a ticket. And the person reponsible for fixing the issue would be the translator who entered it, or someone else from your translation team. So you assign them to the ticket, you include a screenshot and a description of the problem.
What is the first thing that happens next? Well, to correct an SAP text, a translator needs to know what is called the „translation object“ and the „translation object type“, which together form a technical ID that allows them to call up the offending text in transaction SE63. (Alternatively, they can also access the text in SE63 using the transport object.) This means the translator will now have to start searching the SAP system to find this piece of information, mostly using SAP development transactions.
Finding the Translation Object
In many cases, a competent SAP translator can find what they need if they also have sufficient access rights. But it will them take quite a bit of time to get there – in practice, this process can easily take a few hours. So let’s say that they are able to find the right object for about 50% of translation bugs. For the rest of the issues, they will have to ask development to identify the correct technical object for them, which will cause more overhead. And to make things worse, many issues that look like translation issues to a tester actually originate in development and have to be fixed there. Examples include hard-coded texts or tables without a language key. These kinds of issues are next to impossible for a translator to identify.
1Q Language to the Rescue
This process improved a lot when SAP introduced the 1Q language concept as way to make it easier to identify a translation object from the user interface. When you set up this feature, you add an additional logon language to the system: the 1Q language code. When you logon with this language, instead of user interface texts, you see technical codes. The technical set-up process for this feature is documented in SAP Note 1884828. After you follow the steps outlined there, each UI text is replaced by the technical ID of the translation object that the UI text is stored in. For a text such as Anlage in the below example, in the 1Q language, DTEL ZFI_ANLAGE would be displayed instead.
This piece of information is all a translator needs to call up the text in SE63 and correct its translation. So whenever a translator wants to correct a texts that they see on the user interface, there is no need to search around in the development system. They can simply log on to the system in the 1Q language, call up the same screen, note down the technical ID of the text, call the text up in SE63 and correct it. During language testing, this is a huge time saver.
ABAP versus Fiori
With SAP Fiori apps, the process is even simpler for the translator. Instead of having to log again, they can stay on the page where the issue is visible and simply change the language code in the URL to 1Q, right in the address bar of their browser. And the 1Q language feature also fully supports Fiori apps, which often contain user interface texts that do not reside in the backend system, but in .properties files in the Fiori Gateway system. To be able display these non-ABAP texts in the 1Q language as well, the set-up process is a little more complex than on the ABAP side. It is documented in SAP Note 2091514.
Once you have the 1Q language in place, you can instruct your tester to always take three screenshots of the screen that contains the text that they want changed: one in the source language (most often English or German), one in the target language where the translation issue is visisble, and one in the 1Q language. When a ticket that contains all the three screenshots (as well as a description of the problem) reaches a translator, in most cases, it will take them mere minutes to find the incorrect translation, correct it and complete the ticket. Compare this with the legacy process, where we were talking hours, not minutes, and it’s easy to see why translators as well as testers are so happy with the 1Q language.
Learn more about our SAP translation consulting services…