Planning for Translation when Implementing SAP S/4HANA On Premise

Published on 16 Sep 2019

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 and SAP S/4HANA Cloud Solution. But since the customization options are more limited with these two options, we will not focus on them here.

SAP Fiori or SAP GUI

On S/4HANA on premise, 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.

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 i18n.properties 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.

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.