When you’re getting started with SAP translation, the first thing you need to know is what to translate. It’s as simple as that. What you have to do to define your translation scope varies a lot depending on your use case, but there are a few best practices. This is the first in a series of blog posts each dealing with one category of texts. This one is about SAP GUI user interfaces.
To get this out of the way first, I wrote about scoping SAP translation projects before, over at text&form. Since these posts were written, a lot of time has passed, but I think they hold up reasonably well and offer a good starting point. They lean more towards the business side of SAP translation and are not too technical. In this new series of blog posts, I will focus more on the practical side of translation scoping, and also cover newer technologies such as SAP Fiori (which will probably be the next blog post in the series). But let’s start with good old SAP GUI.
Custom vs. Standard
If you have implemented SAP using SAP GUI instead of SAP Fiori as your user interface technology, there are probably a few custom developed transactions that you are considering to translate into the local language of the country you are rolling out to. To be clear, in many rollout projects, no SAP GUI user interfaces will be translated at all – it all depends on your strategy. Maybe you are rolling out to a smaller location where it is enough to translate forms, customizing entries and maybe some SAPscript standard texts. But if you are planning to let your users work within a software environment that fully supports their native language, your custom transactions will need to be translated as well.
In most rollouts, you will not have to worry about translating SAP standard transactions, since SAP provides language packs for 40 languages that you can import. And unless you are going beyond the more common SAP ERP transactions and are looking to support one of the “smaller” SAP languages (which here means, languages with fewer total global SAP users than the “big” languages such as English, German, French, Spanish, Chinese etc.), SAP’s language packs will get you there. But the language packs will not help you with translating any user interfaces you developed in-house, or any third-party add-ons.
Scoping by Transport Requests
The cleanest way to define your translation scope is to do so by transport requests. If you have planned for translation ahead of time, or if your implementation is very recent, you may be in a position to be able pinpoint the exact transport requests that contain the developments you want translated. But that is not the reality in most projects, where developments may have been done a few years ago, and there is really no way to find out which of the thousands of transport requests contain what. In this more common scenario, there are two possible routes you can take – defining your translation scope by development packages, or by transaction codes.
Scoping by Packages
If you define your translation scope by packages, you start by looking at the entirety of your Z packages (and any custom namespaces). In your first pass, you will only exclude text types that will likely not be displayed to end users, such as the descriptions of domains. There are a number of way to slice and dice this initial scope, but if your developments are not neatly organized into packages, you can end up translating almost your entire Z namespace. Of course, not all of the translation work will be done manually, since there are many ways to partly automate this work, which I have discussed at length in other blog posts.
The advantage of defining your translation scope based on development packages is that if you have properly dealt with any internationalization issues such as hard-coded texts, there will not be many surprises when you test the translated screens. You are not very likely to have missed many texts, so you can expect to encounter very few translation gaps. But scoping by packages also means that you are looking at higher upfront translation costs.
Scoping by Transaction Codes
Another approach is to define your scope by transaction codes. This means you are trying to identify the exact texts that are being displayed on each screen of these transactions. Of course, you will be translating a lot fewer texts that way. But the question is: How do you identify the right texts? If you ask developers or consultants to do this manually, it is certainly possible, but you are looking at many days of work. A better option is to use a tool to identify the texts for you. There is an SAP standard tool that covers some of the more common implementation scenarios, and there are third-party tools such as our own LUDECKE Translation Manager that go beyond the scope that SAP supports and have a higher chance of catching all relevant objects.
But since every SAP implementation is different, no tool will catch 100% of the texts, which means you will notice at least some translation gaps during testing that will have to be fixed. If you plan to do a significant testing effort anyway, or if it is acceptable that a small percentage of English texts remain on the final screens, this approach will let you save on translation costs. But if you want to be on the safe side, it can be better to build your translation scope based on packages.
You can run a successful SAP translation project based on any of these three approaches. Whether you define your SAP translation scope based on transport requests, packages, or transaction codes, you will be able to translate all required texts. Which approach is right for you will ultimately depend on your translation strategy.
Learn more about our SAP translation consulting services…