How Do the SAP S/4HANA Editions Differ When It Comes to Translation?

Published on 29 May 2020

SAP offers four main editions of S/4HANA, not counting any sub-variants. But is there any difference between them for the purpose of translating your custom developments, customizing etc. into other languages, say in the context of a global rollout? This is a high-level overview of the translation options you have on each of the editions of SAP S/4HANA.

Coming from an On-Premise World

Most SAP translation projects I have worked on over the years were for installations of one of the SAP Business Suite products, such as SAP SRM, or of course most commonly SAP ERP (ECC). Then, starting a few years ago as customers began to move to SAP S/4HANA, that was the product I was dealing with. But in every single one of these S/4 projects, the customer was running the on-premise edition of S/4HANA. Last fall a colleague from SAP explained the differences between the four currently available S/4HANA editions to me so succinctly, that to this day, that‘s the approach I take when someone asks me, how does translation work on SAP S/4HANA? If you want the short version, then nothing much changes on three of the four flavors of S/4, but the fourth one is really different. But let’s go through them one by one.

SAP S/4HANA On-Premise

This is the edition of S/4HANA that I covered in my post about migrating from SAP ERP. Customers can control every nook and cranny in their SAP system, and when it comes to texts, so can translators. You have the choice between building your custom user interfaces on SAP GUI, or you can build Fiori apps. All the translation tools that translators are used to from SAP ERP will still work – in fact, new features will be available to them because of the higher SAP_BASIS release that your S/4 system will come with. Third-party add-ons will also still work, provided they support the relevant release.

Translation options on the S/4HANA editions

The translation options in the SAP Standard on the four major SAP S/4HANA editions.

SAP S/4HANA on HANA Enterprise Cloud (HEC) or Similar Options

For the purpose of comparing your translation options, this is basically an on-premise system that is running in someone else‘s data center. I am simplifying, of course. But whether you are using HEC, AWS or any other hyperscaler, your system is still very much your own to modify as you please – it’s a system copy of an on-premise system, if you will. Your user interface options are again SAP GUI, Fiori, or both. And if you want to, you can even still use NetWeaver Business Client. This means, of course, that the same translation tools are available that you know from the on-premise edition.

SAP S/4HANA Single Tenant Edition

This is where things get a little more interesting. The Single Tenant edition can run on HEC or any hyperscaler, like the HEC edition. You can also develop SAP GUI or Fiori interfaces – but there is one limitation: You cannot modify the SAP Standard anymore. You can still use BAdIs and user exits, but you cannot change SAP code. The same limitation also applies to any add-ons that you want to install, such as third-party translation tools – they cannot contain any modifications. And on all three editions that we have discussed so far, you have access to all 63 country versions and all 39 languages that SAP provides language packs for.

A Few Words About Fiori

While it is possible to use SAP Fiori with SAP ERP systems (with some limitations), SAP Fiori was really made for S/4HANA. That means that most companies running SAP will make the decision whether or not to build Fiori apps once they move to S/4. And moving away from SAP GUI interface to SAP Fiori is a big change, not least when it comes to translation. In fact, it’s probably the biggest change that S/4HANA brings to SAP translation. The thing to keep in mind about Fiori is that most of the translation tools that are currently out there offer no integration for SAP Fiori apps. And that very much includes SAP’s own built-in translation offerings, that really only cover translation of text from the ABAP backend.

For small-scale Fiori developments, SAP Translation Hub is a reasonable option, if you develop on SAP Cloud Platform. For bigger translation efforts involving developments with both ABAP backend objects and Fiori Frontend texts, there is our own i18n Translation Manager for SAP Fiori – as long as you are running one of the three S/4HANA editions listed so far. And of course, you can always copy out files manually and leave the file handling to your translation agency of choice, who will most likely translate them using translation industry tools.

SAP S/4 HANA Public Cloud

And then there this is the “true” cloud option. While the first three are essentially the same product running in different environments with different modification options, this one is really a different product with quite a bit functionality that is not available on the other three editions, and vice versa. There are also fewer languages and country versions available from SAP (currently 40 country versions and 25 languages). Some customizing options are available via self services UIs (SSCUIs), but for custom developments, the idea is to extend S/4HANA public cloud using side-by-side scenarios, for example via SAP Cloud Platform.

Since there is no SAP GUI available for Public Cloud, none of the standard tools (such as transaction SE63) are available, nor are any of the third-party add-ons that run on the ABAP-stack. Translation is limited to customizing texts, which can be translated manually from the user interface, and to single custom fields, but there is no full translation tool suite. Any apps that you build in side-by-side scenarios, on SAP Cloud Platform or other environments, can of course be translated, but there are no SAP Standard solutions for this process yet. And which translation will be best for these kinds of custom solutions will very much depend on your implementation strategy.

Read more on planning your SAP translation project