As I write this, it has been close to three years since CDTM ran in a customer SAP system for the first time. From day one, the tool has been helping customers reduce their translation scope by enabling them to translate only the customizing entries that they need, and by doing so, and lowering their SAP translation costs. Here’s the story of how it came about.
Customer Entries into the Pot, SAP Entries into the Crop!
When I started to work on what was to become Customizing Delta Translation Manager, I set out to make a tool that covered a typical customer use case that SAP‘s translation tool suite was not addressing. In nearly every SAP translation project I had worked on up to that point, customers needed to translate texts from customizing tables such as ANKT from FI (Asset categories) or TVAPT from SD (Sales document item categories). And they generally wanted to translate only a few entries from each table — the entries that were created by their implementation team. But of course, since we are talking about SAP standard tables, each of these tables also contained text entries delivered by SAP.
Sorting through these tables and identifying the exact entries needed caused quite a bit of manual work, for the customers, but also for myself, when I was working on SAP translation projects. So I was looking for a way to pull out only the customizing texts that the customer’s consultants created, and leave all the entries from SAP as they are. What I came up with was a tool that scans the entire transport history of an SAP system, and sifts through all the table entries created in that system or in a predecessor system. Those texts are then copied into a so-called customizing snapshot and made available for translation in the form of temporary translation objects, or via export to XML-based files.
Managing the Translation Scope
The obvious benefit is that you save translation costs and avoid touching customizing texts that SAP may update or change with notes, support packages or new releases. And the difference is often quite significant: there are tables with thousands of entries coming from SAP and only a handful added by the customer. Another decisive factor is that with this tool, you get an overview of the number of texts per table you have created, and you can exclude any tables from the scope before the texts go to translation.
The tool also helps you to define the scope of your translation project by exposing not only the numbers of lines for each table (both the total number of lines and the number of lines created by your team), but also metadata for each table, such as the application component (e.g. FI-AA), development package etc. Knowing the application component of each table is particularly important, because that allows you to, say, exclude all tables from the BC component (SAP Basis) in one fell swoop, since most of those texts are not very likely to be visible to an end user. Based on the numbers of lines and the metadata, you can then exclude any text tables that you don’t need in the location you are rolling out to.
A Tool-Agnostic Translation Process
Once you have decided what the translation scope will be, the tool lets you make those texts available to translators. From the start, CDTM supported transaction SE63 as a translation editor, which is a very good option if you have translators that know his tool (I’ve written about it here). Since then, I’ve added functionality to export texts for translation, but to tell the truth, most texts in CDTM snapshots are still translated in SE63 (and taking advantage of the proposal pool).
During the project, or at its end, CDTM will let you write back the translations that your translators entered to the original tables. During the write-back process, the tool fully compares the state of the text tables at the time of snapshot creation against their state at the time of write-back. This way, the tool can prevent incorrect translations from being written back by accident. If, for example, the original text for a customizing entry has changed since the snapshot was created, and that the translation that was created for the old source text would now be incorrect for the new text, the translation will not be written back.
With each project that CDTM was used in, I have added new features and simplified existing ones. The tool has been tested in many projects, in SAP ERP systems and on SAP S/4 HANA (see here for an introduction to translation in S/4 systems). It has grown from a 1.0 to a full-featured product that makes it easy to integrate the exact customizing texts you want into your translation workflow. It saves you so much time that today, I cannot imagine working on an SAP translation project without having this tool available.
Read more on our SAP translation tools…