Terminology can make or break your multilingual SAP rollout – it really can. It was only this year that I came across a German translation where “plant name” had been translated as “Planze Name” (sic) – that’s a plant as in potted plant. If your end users, who may already be on the fence about the new system they have to get used to, keep running into these types of terminological blunders, they can feel like they are not being taken seriously – which makes your job a lot harder.
In the above example, no human translator was at fault – the German text was generated by machine translation. But translators make mistakes, too. Take the below example from a project translating from German into English. Here the German text Anlage (meaning Asset) was translated as Attachment, which is a valid translation, but not in this context. Mistakes like this one happen all the time, and there are many reasons why wrong terms are chosen by translators. One common reason is that the translator simply did not have enough experience translating SAP texts. But there are many other possible explanations, too. Maybe they needed more context information, maybe they were not working with the right tools, or maybe they lacked support from project management.
Beyond SAP Terminology
So how do you do terminology right? To start with, it is important to understand that in a typical SAP translation project, terminology has three layers. First, there are the terms that occur in every SAP system – some of which did not even exist before SAP came along, such as company code. These are terms that an experienced SAP translator knows by heart, and for any terms they do not know yet, there is the SAPterm terminology database, which exists in every SAP system and which contains these types of terms as well as their translations. Working with experienced translators usually guarantees that you get these terms right.
Then there are the terms that are commonly used in your industry. Every industry has these, like site manager in a civil engineering company, or procedure in a medical devices company (which in this case refers to a medical procedure). And on the third layer, there are the terms that only your company uses. In some cases, your employees use a different term than the rest of the industry (e.g. agreement instead of contract), or you have terms that exist nowhere else, because the thing they describe was invented by your company.
Recording Terms in Spreadsheets Versus Using SAPterm
Of course, there are also a number of tools that can help you manage terminology. In most SAP rollout project with a single target language, recording terms in a Microsoft Excel spreadsheet is a good place to start. The important thing is that terminology is recorded at all, and that the terms defined are accessible to all translators working on the project. This can be achieved, for example, by making the spreadsheet available on your SharePoint, but there are many other options as well. Translators also need to know that they are responsible for applying this terminology and that they should be asking questions in case of doubt. But to any translator worth their salt, this is second nature anyway.
When you are dealing with a project where your custom developments, customizing texts, forms, etc. are translated into more than one language, or if your project covers a large number of SAP modules, using a spreadsheet may not be good enough. In these cases, you need a proper terminology database. Luckily, every SAP system comes with its own terminology database, SAPterm (Transaction STERM or sapterm.com). And if you do not want to invest in a new tool, using SAPterm can be a good option. It already contains all of the SAP Standard terminology, and you can create new entries for your own industry terms as well as for company-specific ones.
Another advantage of SAPterm is that every translator who has worked for SAP at some point in their careers (which, if you count freelance work, is most of them) already knows how to use this tool. This is why SAPterm is a good option specifically when you are outsourcing translation. This is especially true if your translation is done using transaction SE63, which means your translators already perform their work in your SAP system, and can easily be given access to SAPterm as well.
Industry Standard Terminology Solutions
When you have exported your SAP texts for translation, or if you need a more powerful terminology solution, you will reach the limits of what SAPterm can do for you. It probably makes little sense to give translators access to your SAP system only for using SAPterm. On top of that, modern terminology databases offer powerful terminology mining features, as well as integration into industry-standard translation tools. This will come in handy in very large SAP translation projects, or if you plan to build a terminology database that will be used across your organization and beyond the project at hand.
There are many such solutions out there. Personally, I like tf-term (if you follow the link, you have to scroll down a little to find the tool), which is developed by our partner text&form. This solution is especially good at mining terms from existing texts. This is really useful if there is already documentation or training material available for the functionality that you are rolling out. tf-term can search these text materials and automatically identify term candidates (they call this process termcasting), which means that in a few hours, you can build up a terminology database for your entire project, if not your entire organization.
Whichever tool you choose, you should include terminology in your planning, because translation rarely produces good results if you ignore terminology. This is an area where a small investment can go a long way to ensure the translated transactions or apps that you are rolling out offer a great user experience. And the better the user experience, the easier it will be to win over the end users in your foreign locations.
Learn more about our SAP translation consulting services…