ABAP Report using SAP Translation Hub for i18n of Texts of ABAP Artefacts
This is the second blog post in my series in using the SAP Translation Hub in an agile development process for developing solutions with an ABAP based backend and an UI5 based frontend.
For the first blog post see UI5 Tooling Custom Task using SAP Translation Hub for i18n of UI5 Apps.
ABAP Systems have a long history of providing tools for the translation of texts used in the various UI technologies. For OData based UI5 applications the OData metadata and the annotation model delivers i18n texts to be used eg as labels and tooltips in the UI5 app. i18n texts are used in error messages in the OData responses.
At the end of a development process and with the help of the LXE_MASTER transaction you can first gather all objects with texts to be translated in one object list, then export the texts including context information to XLIFF files (one file per target language). These files are handed over to the translators and they fill in the translations. Afterwards the files are imported (again with LXE_MASTER) and the i18n texts are automatically delivered to the UI5 apps.
While this works good for quite some time already there is room for improvement as with the frontend texts!
At first this process is even more fixed to the outdated waterfall model of first developing and then translating than the frontend process. Eg you have to match files from the translators to the export runs and the object lists used for export are static. Agile Development aims to deliver an improvement to users at the end of each sprint, so the amount of texts to be translated increases with each sprint. And this improvements should of course not only benefit the users understanding the default language… So we need to also have agile translation in parallel to the agile development!
A second improvement aspect are modern tools to support the translators, eg the SAP Translation Hub. For an introduction to the Translation Hub see my first blog in this series linked above.
Translation Hub offers a direct integration with the translation of the object lists from LXE_MASTER. This makes it possible to automate the process of using translation hub. However there could be several problems with this approach:
- One might not be comfortable with an outside cloud service having write access to the onpremise SAP system (although you can nicely restrict the access in the SAP Cloud Connector to the strict minimum)
- A project is tied to a translation of one objects list with a static content
- Using a file project variant instead of the abap project variant in the Translation Hub involves a lot of manual tasks, especially a constant and tedious renaming of files with complicated names.
In order to offer a different approach overcoming these problems, I have developed the ABAP report ZPUSH_PULL_TRANSLATION_HUB and offer it as open source on github.
The report is intended to be run after the report RS_LXE_EVALUATION_SCHEDULE . The latter report takes a selection (eg for all UI texts in one or more packages) and builds a new object list of all texts to be translated for the selection (and also creates an evaluation). ZPUSH_PULL_TRANSLATION_HUB then exports the newly created object list and uploads it to a ABAP XLIFF File type Translation Hub File project, initiates translation and after finish downloads and imports the translations.
Make sure your ABAP system fulfills the prerequisites mentioned in the README.
The github project is an abapGit project. So if not installed already, follow the installation instructions for abapGit. Then install this project according to the Installing online repo instructions using the url https://github.com/DerGuteWolf/ABAP_TRANSLATION_HUB .
In your translation hub UI create a File Translation Project for ABAP XLIFF File.
In your ABAP system follow the instructions in the README to configure a server directory and create a HTTP destination.
Do the basic translation setup in transaction LXE_MASTER.
Create a variant for the report RS_LXE_EVALUATION_SCHEDULE. Do not select the Mail options, select Create Object List and choose an unique Description for the object list. For Object Type select all A5 User Interface Texts :
In the upper right you see the number of packages and with a click on Standard you can verify them
You have to fill in also data for the Worklist, the results from this part are however not used.
Save the informations entered as a variant. You can now schedule the report for a single run or for regular runs. Each run will create an up-to-date object list with all current UI texts from all current objects of your packages. The object list number is increased with each run but the description will always be the description you entered. When run, the report starts some more reports. When scheduled as a job this might look like this (upper five entries are from this report, for the sixth entry see next paragraph:
The spool from the OBJECTLIST job lists the number of objects for each object types and might look like this
Now create a variant for the report ZPUSH_PULL_TRANSLATION_HUB . Fill the values according to the instructions in the README . As ExternalID in Transl.Hub Proj. use 1. Make sure you enter exactly the same Description for the object list as in RS_LXE_EVALUATION_SCHEDULE . Do not change the source language, the first target language or the ExternalID afterwards! Now you can run or schedule the report with the variant, for the result see the last entry in the job list above. The spool from a succesful run might look like this
What happens during a ZPUSH_PULL_TRANSLATION_HUB run?
First the highest object list number of the object list with the description configured is looked up and a new externalization ID is created. Then the export of the texts of this object list to a file in the configured server directory for the first target language is called. The file is read into memory and is immediatly after reading deleted from the server directory. Contact to the Translation Hub project is established and the file content is uploaded with a constant filename derived from the source language, the first target language and the ExternalID and thus is aways the same. The translation execution is triggered and progress is followed until finish. A zip of the files with the translations is then downloaded, unpacked and the files are written to the configured server directory with the file names the import expects. The import is then called and files are immediatly deleted regardless of the outcome of the import.
I hope you find this task useful! If you find bugs, please use github for reporting.
The ease of sharing this report with would not have been possible without the great work of Lars Hvam (and all other contributors) in developing abapGit.
And of course as in the first blog I have to thank SAP for opening their MLTR treasure chest and offering the Translation Hub Service. Special Thanks to Beatrice Pasch and her team for bringing Translation Hub to us!