How to transport translations made in SE63 without access to SLXT or authorization for transport request creation
When working on international projects, there is a need to translate new developments done in ABAP. In standard SAP provides SE63 tool, which help executing the translations for many objects at the same time. You can complain it is not intuitive and user friendly, but it if you have many translations to be done you cannot do much about it. After completing the translations in SE63, you need to put the translations in a transport request, as opposite to translation of customizing, the system does not prompt for transport request nor assigns the entries to a transport request when saving in SE63. In most cases you are just about to face new challenges. It is quite often nowadays, that you do not have authorization for transport request creation, as it is managed by central support team using SolMan, or you do not have authorization to SLXT transaction, which is provided in standard SAP to put all the translations done in SE63 into a transport request to be able to import it trough system landscape. When you do many translations, you can spent some time on getting proper authorization or request creation of the transport request with translation by central support team, but if you have just a few additional/new translations to be done, it seems to be too much hustle. In such a case there is a workaround to create the entries in transport task manually, it takes 15 minutes and you’re done 🙂
List of objects translated in SE63
First get the list of translations done in SE63 or in ABAP dictionary or directly ABAP workbench objects. The list is stored on DB table LXE_LOG:
You can select the entries based on you user name or the date and time of translation:
Mapping of translation objects to transport objects
Seems easy and what would you do is to put the entries from LXE_LOG directly to entries in the transport task, however some adjustments are required before doing that. Namely the object type has to be adjusted, as the ones used in transport request are different that stored in the table (strange, but it’s like that). But there is nothing that cannot be done without some analysis of ABAP code. SLXT uses FM LXE_OBJ_CREATE_TRANSPORT_ENTRY to conver the LXE_LOG entries into transport request entries. So actually the work is a piece of cake now.
All you need to do is take the object type from LXE_LOG entry and lookup the proper object type to be used in the transport entry.
Let’s take object type DOMA for a domain from LXE_LOG as example. You go to the FM and find the object type in the big CASE statement:
You see that for LXE_LOG object type DOMA (domain) the object type DOMD should be used in the transport entry.
Create transport entries for translated objects
So all you need to do now is edit a workbench Development/Correction task and add a new entries to it:
After putting the key (LANG/DOMD/<object name>) you will get a pop-up to provide the language of the translation (in our case it’s NL). After you provide it once, the language is used as default for all new translation entries you create in the transport request task.
I hope you find it useful and will enjoy your small translations! 🙂