Every so one often, you need to find out which system user actually entered a particular translation in transaction SE63, most often to correct a translation mistake. Here’s a summary of the functionality available in the SAP standard for getting answers.
A Word with the Translator
When you have completed or are in the middle of an SAP translation project, sometimes you need to find out who entered a particular translation in your SAP system. The most common scenario is that you have found a translation mistake and you want to ask the responsible translator to correct the translation – and let him or her know the correct term that should be used going forward.
This German translation is incorrect, let’s find out who entered it.
Let’s have a look at how to get that information. You will see that there are limits to what you can find out, and that the data you can get is not very granular. But it’s good to know what is possible, especially as none of this functionality is currently documented.
Finding out the Translation Object
What you will need in any case is the name of the translation object that contains the offending text. If you came across the problem during translation in transaction SE63, you will generally already know the translation object’s name. But if you came across the offending translation in testing or production, while using a translated version of an SAP report or transaction, finding out the relevant translation object often is a really complex task.
A translator working in SE63 already knows the name of the translation object, it’s displayed at the top of the editor screen.
From the perspective of a key user or consultant, finding out the translation object is best left to an ABAP developer or a professional SAP translator. Developers and translators will usually approach this problem from very different angles, which means that it sometimes even takes the combined efforts of both a translator and a developer to identify a translation object.
If possible, it’s a good idea to turn to a professional translator or translation consultant first, since they will know what a translation object is (hint: It’s not necessarily identical to a development object), and are often able to identify a translation object without help from a developer, while many developers have never dealt with translation issues before. And when the translator does need help, that’s when letting him or her talk to a developer usually yields the quickest results.
Table LXE_LOG
Once you know the name of the translation object, you can look up the translator who last saved that object using SAP table LXE_LOG. It’s simply a question of going to the system where translation took place (often the development system), calling up that table in transaction SE16, entering the translation object name in the OBJNAME field and the target language in the TARGLNG field, and executing. Double-clicking the result reveals the name of the user who last saved the object in the UNAME field, as well as the save date and time:
Enter target language and translation object, and execute.
Here’s who last saved this translation object.
Helpful, but Not Sufficient
Unfortunately, this table is also updated when a translation object is saved, but has not been changed, which makes the results somewhat less reliable. Also, LXE_LOG has no history feature and only ever shows the last user who saved an object. And things get even trickier when the translation object in question contains more than one line of text and you only want to know who translated one particular text.
What if you want to know who entered “统计” and don’t know if the individual lines where translated by different translators at different times?
This scenario comes up quite often, since the translations for an object are often updated multiple times, for example when the text elements of a report are translated initially, and the developer then adds a new text element that is translated at a later date. Or maybe a translator made a correction to one of the texts in a translation object, but did not touch any of the other lines in that same object. In these cases, LXE_LOG is not very helpful, since it offers no insights on the individual translation lines level.
Objects with Already Translated Lines
In theory, since a translators should always check the entire object they are translating, they are also responsible for all the lines in an object – not only the ones they changed, but also the ones that were already translated. But if an object contains hundreds of already translated lines, and only a single line was translated by our translator, you cannot realistically expect him or her to have checked all the other lines as well, especially if the translator was were only paid for a single translated line.
So unless we know that the object did not contain any translated lines before it was saved (say, this is the first time translation took place in the system), we don’t know if the user listed in LXE_LOG really entered the translation for our particular line.
Proposal Pool to the Rescue?
The proposal pool is SAP’s translation memory system, and apart from being extremely useful to translators for a variety of reasons, it also allows you to look up the user who first created a particular translation, although it will tell you nothing about who last used this translation in the translation object you are looking into. A translation can be created and added to the proposal pool, and can then be reused thousands of times over a period of many years.
If you know the exact text of the translation you would like to know more about, you can call up transaction SLPP, enter the source language (usually deDE for German or enUS for English, try both) and target language, and enter the translation in the second text field, leaving the first one empty. Note that the proposal pool search is case-sensitive.
In this case, we want to look up the text Chinese “统计” which was translated from English.
The Proposal Details Dialog
When you hit Execute, you get a dialog box offering up the source text for this translation. You can then double-click the source text to get more information (there may be more than one source text, in which case you should try each one). If there are no source texts, there is no proposal for this text and this source language, which means you should select a different source language, or that no proposal exists for this text. In this last case, it usually means you are either looking in the wrong system, or that the text was translated without a proposal being created (which is generally not a good idea, as I have detailed in this blog post).
Click the glasses icon to display details on the translation.
In the next screen, click the glasses icon to learn who created and last changed the proposal. If the date matches the last changed date of the translation object from LXE_LOG, congratulations! You have found the user who last edited this particular text. If the Last Changed date of the proposal is older than the LXE_LOG entry, you have found out which user originally created this translation, but you don’t know for sure who decided to use this translation in that particular translation object.
SLPP as a Shortcut
Looking up a translation in the proposal pool in transaction SLPP has the added advantage that you do not need to know the name of the translation object to learn more about a particular translation. So if you look a translation up in SLPP and find out that the offending translation was created fairly recently, you can give the user who last changed it a call, since at that point it is fairly safe to assume he or she was the one that entered the translation you want changed.
And if this user is a professional SAP translator working on an ongoing SAP translation project, he or she will know how to make sure this translation is corrected on the screen you noticed the issue on as well. If no translations are planned for the near future and/or the translator is not a professional SAP translator, it’s very likely that the translation environment has not been set up in your system, which is required for changes in the proposal pool to propagate to the individual translation objects, meaning you are back to needing to find out the name of translation object.
