Planning for Translation when Implementing SAP S/4HANA

Published on 16 Sep 2019

If you are moving from ECC to SAP S/4HANA, but have no plans to ever roll it out beyond your borders, stop reading. But more likely than not, your first rollout is already on the roadmap, and that means, it’s time to think about translation, or it will be soon. Here are a few pointers for what to consider before you get started.

The More Things Change…

The good news is that while there are many things that change when you move from ECC to S/4, when it comes to translation, a lot stays the same, too. One thing that has not changed much are the built-in translation tools centered around transaction SE63, or the option to export texts to different formats for translation. Another is the set of options you have available in the SAP Standard to set up and configure the translation environment. This is because the translation tools that SAP delivers are tied to the SAP_BASIS component of the system, and this component exists in your S/4 systems as well as in SAP Business Suite systems.

While most of these musings revolve around the S/4HANA on premise solution, much of the world is moving to the cloud, at least partially. So I would be remiss if I did not mention SAP’s S/4 cloud offerings, mainly the HANA Enterprise Cloud (HEC), SAP S/4HANA Single Tenant and SAP S/4HANA Cloud Solution. When it comes to translation, things works mostly the same on On-Premise, HEC, and Single Tenant. But Cloud Edition is quite different, which is why we will not focus on this S/4HANA variant here.

SAP Fiori or SAP GUI

On S/4HANA, the same programs and data dictionary objects that you know from SAP ERP are still there. The question is how you use them. In customizing, things have not changed much from a translation standpoint – things are still tricky, and a tool such as CDTM is still your best bet if you want to translate efficiently. But when it comes to the user interface of your custom developments, things have changed quite a bit. The main question here is whether you use SAP Fiori or whether you are sticking with good old SAP GUI (and let’s for a minute discount the fact that Fiori can be used with ECC as well, and that there are more UI technologies than just those two big ones).

SAP GUI vs SAP Fiori.

The familiar SAP Easy Access Menu and the new SAP Fiori Launchpad.

Two Flavors of Fiori

If SAP GUI is all you need, I don’t have a lot of news for you. There are a few additional object types to consider when defining your translation scope, but that’s mostly it. SAP Fiori, on the other hand, is a different beast entirely. The important thing to understand is that Fiori apps can be built entirely in ABAP, in your ABAP-stack system, using a mix of traditional ABAP objects and Gateway objects. But you can also build Fiori apps using different programming languages like Java, JavaScript, or Python. In that case, a large part of your user interface texts will reside in files, and you cannot use tools of your ABAP-stack system to translate them. But since you will still, at the very least, be calling data dictionary objects such as data elements and customizing and master data tables to display their texts on the UI, the traditional SAP translation approach will still be used. This means you will be looking at a mixed scenario of translating both text files and ABAP-based texts.

Traditional SAP texts vs properties files.

Texts from a data element can be used alongside texts from properties files.

Another big factor in planning your translation effort is the type of S/4HANA project you are implementing. If you are migrating from ECC, a lot of old Z objects will still be there on your S/4 system, even if you deprecate as much custom code as you can. This means that it’s more important than ever to define the correct translation scope so you don’t waste time translating texts from all the old Z objects that you are no longer using. If you are using a greenfield approach, you will have a much easier time translating your custom developments. Whichever UI technology you decide you use, your footprint of custom code will be much smaller, and so will your translation costs.

Go Forth and Translate

While this article only scratches the surface of what you will have to consider when translating texts from your S/4HANA systems, one thing is clear: SAP translation is not getting any less complex. When it comes to translating forms, customizing texts, and master data texts, things have not changed much. But for custom user interfaces, there is no clear winner yet, and while some companies stick to their guns and build SAP GUI screens, others go all-in with SAP Fiori, be it in ABAP or in another programming language.

Learn more about our SAP translation consulting services