If you are running a simple three-system SAP landscape, and you only rarely change your development system, count yourself lucky. The more development systems you have, the more overhead there is. And nowhere is this more true than with translation. This is a short overview of how to approach translating in multiple systems at the same time.
Why Multiple Systems?
There are many reasons for running several development systems at the same time. The most obvious reason is that, in large organizations, there may be several productive systems, which each usually come with at least one development system. But there are other reasons for running more than one development system in parallel. A typical scenario is a new project, when a separate development system is used for a few months. After the project has been completed, the project development system is decommissioned, but for a few months, development happens in two systems.
And if you are working for a software company developing SAP add-ons, instead of an organization that is using SAP productively, you may need several development systems to support various releases of your products, or you are developing different products in different systems. But if you are supporting more than one language, running multiple development systems also means translating in multiple systems (even if you are using dedicated translation systems). If you have done translation in one system, and are considering translating in another development system, your first task will be to perform an “initial sync” and get all translation-related data into all additional systems. After that, you will want to keep the translation data in sync across all relevant development or translation systems, and to make sure the right translations are available for reuse in the right system.
Bringing Over Language Data Initially
Let’s first look at what to consider when you set up a new development system. It does not really matter whether you are keeping your existing development system around and are only adding an additional development system, or if the old development system will be decommissioned and replaced by the new one. Before you start translating in a new system, one of the preparatory steps is to move all translations done in the old systems to the new one, via transports or language packs. A second step is moving over the proposal pool from any existing translation systems, so the texts that your translation team has translated in the past can be reused for any texts that you want to translate in the new system.
This step is often skipped, but it is very important. If you do not move the proposal pool, you lose data related to the translations you have already done. The reason for this is that any translations that exist in the new system will not have the Translated status unless a matching proposal is available (I have explained the underlying logic in this article). When you are moving translations to a new development system, without moving the proposal pools as well, your translated texts will not actually be considered to be translated by the SAP Standard translation environment. You will not be able to tell your own translated texts from translated SAP Standard texts (for which SAP does not deliver proposals), or from any lines where the source text has been changed in the meantime and the translation does not fit anymore.
In this scenario, once you start the first translation project in the new system, there will be a large amount of texts where you are left with the choice of either reviewing them all again, or accepting that some of them will probably not be correct. That is why moving proposal pools to a new system may be the most important thing to remember, in case this is not already on your checklist. If you have performed translations is the past, do not decommission an old development system without checking if there are translation proposals that you need to move to the system that replaces it!
Keeping Translation in Sync
Once your new development system is up and running, you may still be doing translation in the old development system. Or you may have been running two (or more) development systems to begin with where translation is done on a regular basis. In any case, you are now in a situation where with every text that is entered by translators on each of your development systems, the translation state in the two systems is slowly getting out of sync. This is especially problematic if some of the objects you are translating are identical or near-identical on both systems. Since the translators working on these objects may not be aware that their colleagues may be translating the exact same texts in another system, they are likely to make at least some different choices. What you end up with is two sets of translations in two systems, and double the amount of work.
A good way to combat this is the RFC copy feature, which has been available since SAP_BASIS 7.40 (it was also made available on earlier releases via support packages). With this feature, you can copy translations for identical objects from other systems, via an RFC connection. What this means is, when you run a worklist evaluation, it will check for each object if the same object also exists in the reference system. For each identical object, if that object contains lines that are translated on the reference system but untranslated on the current system, it will copy over the translations to the current system. And best of all, it will copy the associated proposals, too.
This not only keeps the translations in sync, it also saves a lot of work, since identical texts will only have to be translated once. Depending on your translation strategy, it may still make sense to regularly transport the proposal pools between the systems. But if your systems are used to translate modules or products with very different terminology, it may also make sense to only use RFC copy. In many projects, this feature has been such a problem-solver that it’s easily my favorite addition to the SAP Standard translation tools since SAP_BASIS 7.40.
Both for the initial sync and the regular sync between two translation systems, the SAP Standard gives you the tools you need to get translations and proposals from one system to another. If you need tools that go beyond those features, such as integration between translating outside the SAP system and translating in transaction SE63, or moving translations and proposals for Fiori texts, our custom tools can help you out. But if you take one thing from this article with you, let it be this: don’t forget to move your proposal pools!
Learn more about our SAP translation consulting services…