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.
This article was originally published on September 16, 2019, and has been updated to reflect the state of SAP S/4 HANA translation in 2022.
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).
The Frontend and Backend of Fiori Apps
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. Most Fiori apps consist of three parts: a Frontend component that is stored as a BSP application, traditional ABAP objects that are used on the Backend side, and Gateway services that connect the two. You can build Fiori apps using programming languages like Java, JavaScript, Python, but you can also still use ABAP. But for translation, the important thing to know is that 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 these texts. 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.
This makes your S/4HANA translation project quite a bit more complex, since you have to pull out the i18n.properties files, translate them outside of the SAP system, and paste the translated texts back into the relevant BSP pages, or into the IDE of your choosing. On the Backend side, you still have all the traditional dictionary objects, texts elements, etc. that your project needs to cover, too. And you also need to identify which Backend texts your Fiori apps are using in the first place. We have created our i18n Translation Manager for SAP Fiori add-on to handle this complex scenario and roll all your relevant SAP texts into a single project.
The Impact of Legacy Developments on S/4HANA Translation
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.
Learn more about our SAP translation consulting services…