Scoping, in essence, means getting a list of objects or files that are relevant for translation. All the Fiori i18n_properties files, all the SAP GUI texts elements, data elements, tables or messages are analyzed to determine if they are relevant for translation or not. Of course, you can try to compile this list manually, but there are quite a few tools that let you easily eliminate large chunks of your customizations from the scope. The objects you exclude should be those that users in the new location will not actually display as part of their daily work. Transaction LXE_MASTER gives you access to such tools, and there are also third party tools available that can get you most of the way towards a well-defined translation scope. One such tool is our own Customizing Delta Translation Manager.
The Cost of Fine-Tuning
After you have defined the scope in broad strokes, some fine-tuning needs to be done. This means looking at objects, for example, a customizing table, and manually checking where they are used, and if they are relevant for translation. You generally start with the biggest objects, the ones that contain the most translatable lines, and work your way down. Pretty quickly, you will get to a point where excluding a few more objects from the translation scope only saves you cents upon the dollar, because you would only be excluding a handful of lines. Translating these additional lines on the other hand would make next to no difference to the project cost. So finding that cutoff point, after which investing more time into scoping will only get you diminishing returns, is as important as the scoping work itself.
Another reason why fine-tuning your scope to exhaustion is not advisable lies with the powerful automation tools that you can deploy, even when you are only using SAP Standard functionality. First and foremost, there is Automatic Distribution, which I have written about here, and which can save you up to fifty percent of translation costs. If you add third-party tools into the mix, for example for reusing texts from SAP language packs, and you also use SAP Translation Hub, the costs go down even more.
Reduce Effort, Reduce Costs
The basic idea of all automation tools is to reduce the effort put into translation. They do this either by automating translation completely so translators do not need to do anything, or by speeding up the translator’s work by offering them translation proposals that they can reuse, thereby improving their throughput. You can look at it in terms of the number of lines to be translated (with one line representing one user interface text such as button or an error message): Scoping reduces the number of lines to be translated, while automation reduces the translation cost per line. With that in mind, it does not make sense to focus on one and eschew the other.
For many project managers working in IT departments, getting the scope exactly right seems to be the obvious first task in an SAP translation project. But developer time is expensive, and investing hours to exclude a handful of additional lines is rarely worth it. Especially if it would only cost a few dollars more to translate these additional texts in an outsourcing scenario. It’s true that this sometimes means asking someone to translate something that in the end will not be needed, and that is admittedly unsatisfying. But if you weigh translation costs against scoping costs, it is often the correct approach. So while scoping is important, automation can make as much of a difference, if not more, when it comes to keeping down the costs of your SAP translation project.