1
2
3
The main goal of this E-Book is to give an introduction on the topic of
translation in SAP systems. The information is generic, but still offers an
extensive overview of the most important factors to consider when deciding on
a translation strategy. This E-Book offers a decision guide to choose the best
fitting translation strategy, for each customer situation.
Here is some background information to the history of this E-Book. It originated
from a request of the DSAG Special Interest Group for Globalization.
Initially, the idea was to have a strong customer involvement, but time
constraints on the customer side, prevented a high level of interaction.
Since it was very important for us to offer information relating to the daily
customer reality, we asked 4 of the SAP Language Service Partners to co-
author the E-Book based on their vast experience in SAP customer translation
projects. The partners are Lucy Software, Morphologic, text&form and
Wordflow.
4
This E-Book mainly focuses on translation of customer developments and
customer data in the ABAP environment, based on Netweaver 7.4.
As for S/4 HANA, the information in the E-Book also applies to S/4 HANA on-
premise. The translation processes are similar to the ABAP processes. If
required, we can also create follow-on E-Books with detailed information on
certain topics, for example translation of Cloud content and Fiori.
Even when limited to ABAP, the information is still extensive, and therefore we
decided to create the book in 3 parts. They can also be read as independent
E-Books.
The order of topics was chosen according to the usual process phases in a
customer translation project:
Part 1: Decision Making and Strategy, plus ScopingThese are always the first
phases in a translation project, or actually, even earlier, when you ask yourself
if translation is even necessary.
Part 2: Project Organization and Tools
This part focuses on planning aspects, including terminology, and the selection
of the right tool, SE63 or another tool, and elaborates on pros and cons of both
options. At the end of the chapter you will find a list of non-SAP tools.
Part 3: Translation Execution, Maintenance and Resources
This includes information on the actual execution phase, when translation is
being created and delivered, as well as information on activities which take
place after translation delivery, such as handling upgrades and re-use of
translation.
Part 3 also includes information about resources and translation pricing.
5
6
7
8
Why and When to Translate: Pros and Cons of Translation
Every organization implementing software globally has to make some strategic
decisions related to language and translation of systems or documentation.
Decision-makers need to find answers to the following questions:
Do we need to translate at all? Or can we do without translation?
As the majority of our business users speak English, should we rather provide English-only?
If we decide to translate, which languages do we need?
Do we need to cover all languages with the same level of completeness?
Can we just fill the gaps by supplementing with English?
This chapter outlines the key factors in the decision-making process for and
against translation. It will point out some benefits of translation in general.
Information on scenarios where translation is not needed is also included.
9
SAP Standard and Additional Translation Demands
SAP customers can rely on software which delivers country-specific legal
requirements and business practices in their local language.
However, global companies usually need to add some Customizing text
elements or Master Data (like business partner address data, material
descriptions, the chart of accounts etc.). These data are usually required in
more than one language.
In most countries, documents like annual financial statements, payroll
statements, tax return reports, or even the entire software and the related
documentation must be available in the local language, so as to comply with
regulatory requirements. On top of this, global organizations need to add some
additional developments to cover their own specific business requirements.
These may also need to be available in other languages, so that users in the
local subsidiaries can work with this customer specific functionality. Therefore,
it is important for a global organization to have a consistent approach and to
devise an appropriate language strategy right from the beginning of the project.
10
Pros and Cons of Translation - Advantages
The first and foremost reason why translation proves to be beneficial is that
users work more quickly and efficiently in their native language.
The success of a global rollout, strongly depends on the acceptance of the new
solution among the users worldwide. Users are more likely to accept changes if
they can work in their native language. Moreover, you don’t need to hire staff
with sufficient English language skills to work with your software. This
increases flexibility and reduces recruiting time and expenses. Countries with
lower business English skills can easily be integrated.
If standard SAP functionality is translated and your customizations are not, this
will result in mixed-language screens when users log on in the local language.
This will probably create confusion. Certain countries, like France and Canada
impose by law that the user interface is made available in one or more national
languages. And last but not least, SAP has been developing its products with
built-in support for multiple languages, recognizing the importance of translation
as a key factor for international business success.
11
Pros and Cons of Translation – Disadvantages
In your decision making process you should also consider some possible
disadvantages of translation. Translation may require considerable investment.
Similar to other activities in an SAP implementation process, translation doesn’t
come for free. Not only does the effort for the initial translation have to be taken
into account, but also pre-translation activities like terminology definition, the
setup of the translation environment, as well as post-translation activities like
client maintenance and language acceptance tests.
After the initial translation, translation of recurring updates should be planned
over the years. In addition, even if you plan to outsource translation activities,
you should consider that at least an internal coordinator on your side will be
needed. Finally, when certain functions are organized centrally, and the screens
are in a local language, it may make communication between subsidiaries more
difficult. So you should be aware of all these aspects when you decide for or
against translation, since this decision will have an impact on your processes
over a longer period of time.
The complexity and investment required for translation varies with the
translation volume, number of languages and complexity of your SAP system
landscape. Simple projects with one or only a few languages may be easier
and require a lower investment than larger projects.
12
End-users
One of the first questions arising in the decision process for or against
translation is: is translation required at all, or is English sufficient? The level of
English proficiency may vary significantly according to the type of user. A
warehouse worker may probably not be able to cope with a user interface in
English. Financial accountants or departments such as purchasing or sales
may accept English, although they probably would prefer working in their local
language.
Also consider the age group distribution in your company. Elderly people could
probably be less adaptive and less skilled in English than younger employees.
Secondly, you should also consider your external target audience and how you
communicate with them. Forms like invoices or delivery notes must be printed
in the target language of your business partner. Furthermore, authorities in
almost all countries require you to provide documents in their local language.
This means that some of the translation activities must take place
independently of the language of the user interface.
13
Industries
The type of industry you are operating in may also be considered in your
decision process. This chart shows significant differences according to the type
of business. The strongest levels of English are found in the consulting, legal,
science and IT sectors. These sectors stand out for global interaction and high
levels of education. On the other hand, industries like automotive,
manufacturing, construction or food usually have a large workforce base and
show the lowest scores.
14
Acceptance of English
In general, you could assume that companies would decide against system
translations in the local language, if the majority of the population can speak
English very well. For example, as is the case in the Scandinavian countries.
Yet it must be said that system translations are often performed for
Scandinavian languages, too.
In Northern Europe, English proficiency is generally very good. But users still
prefer to work in their native language and works councils may even insist that
the software in use, should be offered in the country’s official language.
Even if Southern Europe’s ranking has improved over the last few years,
especially among the younger generations, English proficiency is still
insufficient for daily business use. As a consequence of its protectionist
language policy, France ranks last out of all Western-European countries.
In South America, Southern and Eastern Europe and Asia, English language
skills for business use is limited. Here translation generally makes sense.
Apart from some exceptions like Israel or the United Arab Emirates, the Middle
East and North Africa generally do not have strong English skills and are the
only regions with declining English proficiency levels in the last few years.
Translation for these countries is recommended. Of course, these are general
statements that should always be checked against the current situation in the
countries where your operations are located.
15
Business English Proficiency Worldwide
According to recent surveys, and even if business English proficiency scores
have increased dramatically during the past years, scores for several key
industries remain low and, in some cases, have declined. Nearly 30 % of global
workers worldwide are ranked as beginners.
This world map provides an overview of the geography of English proficiency.
While The Philippines, Norway and the Netherlands lead the rankings, a total of
20 nations around the world possess a very low proficiency of Business
English.
16
17
Each company should try to define its own translation strategy, since there is
no one-size-fits-all approach. However, there are some common considerations
to be made before choosing the right strategy which fits a specific company´s
situation.
For many companies, the very first attempt is to translate into English only or,
in case English is the original language, not to translate at all.
However, other scenarios are possible. Starting from the mainly English
scenario right through to the only-local-language alternative.
In some cases, companies may be forced to introduce a special local language
variant not actively supported in the standard delivery. This requirement often
has a political background.
18
English-only Scenario
Providing software in local languages is time-consuming and budget-intensive. Not only do
the efforts for the initial translation have to be taken into account but also the maintenance
cycles of translation should be considered.
One possible alternative to translation is to provide “English-only”. This may prove to be a
viable approach for countries with English as an official language. For all other countries we
advise to check if, for example, regulatory reporting in English can be accepted from a legal
point of view.
Typical scenarios are:
Software is developed directly in English. Programmers write directly in English, even if
English is not their native language. Please take into account that providing software UI and
documentation in clear and flawless English is quite a challenging task for developers who
are neither native speakers of English nor expert linguists! In this case we recommend post-
editing activities to improve the quality of English as a source language. Needless to say, in
this case, the English-only option might not be a really less expensive and less time-
consuming alternative.
Another scenario is:
Software is written in another source language and should be translated into English. This
option looks better from a linguistic point of view, provided translators are expert linguists
with in-depth field experience.
19
Mainly English and Only Partial Local Language
This alternative may work in countries where end users feel at ease with
English and accept English screens. Translation efforts (and costs) are
moderate. Users log on in English and only regulatory reporting and some
customizing will appear in the local language. Also, mandatory reporting and
some forms for local communication can be made available in the local
language.
For some SAP products like Business Warehouse, this option can be
implemented more easily.
20
Local Language with Supplementation
This is the most commonly practiced solution for global rollouts involving many
countries and languages. This option means translating at least, the so called
“bare minimum” that allows users to logon and work with the user interface in
their local language. Documents like invoices, delivery notes, payslips etc. will
also have to be translated, to ensure that communication with clients, vendors
or employees works properly.
For each target language into which you want to translate to, the relevant
object types have to be defined. We recommend you refer to the SAP standard
translation level strategy for each language offered by SAP. However, for
corporate reasons, the strategic importance of each country and language can
differ from the translation levels offered by SAP. For example, you may decide
to translate the F1 Help documentation of your custom developments into
Danish, even if the SAP standard delivery does not provide translations for this
type of object.
Texts, that will not be made available in the local language, will be
supplemented with English.
21
Local-language Only
This option implies a high translation effort and should be implemented when
English is not accepted or if end-users are not supposed to understand English.
For example, SAP offers the full translation for Japanese. Needless to say, this
option implies high translation effort and high costs and is rarely implemented
for custom developments.
22
Language Variants
In the standard SAP language delivery for ERP, local language variants are
generally not included. However there are some exceptions. There is for
example US English and European French but no UK English or Canadian
French. On the other hand, Catalan for Spain is available for some ERP parts.
This may cause acceptance issues in some geographies. More information on
the standard delivery will be provided in one of the following chapters.
To accommodate for situations where, for political or corporate reasons, a
language variant is needed, SAP offers functions to setup a language variant,
supplemented with the standard language variant that is available and then
adjusted to the variant needed. However, changing the SAP standard, may in
the end, imply, too much effort, high costs and low return.
23
Translation in the SAP System or External Translation
Depending on the size of a project, you can choose how you prefer to translate.
The so-called online system translation, with the full use of the SAP translation
environment, is the tool of choice for larger projects, which usually involve more
than one single translator. The so-called Proposal Pool functionality of the SAP
translation environment guarantees consistency and re-usability of translations.
For smaller projects, it is also possible to translate outside of the system using
the Externalization functionality as from Release 7.30. Here, there is no need to
establish an external connection between the customer system and external
translators. This option is recommended only if external translators use a
Computer-Aided Translation Tool.
More detailed information on translation with the SAP translation environment
or external translation will be described in Part 2 of this E-Book
24
Where and When To Translate
A translation strategy should also define in which systems and clients,
translation takes place. Ideally, starting with the ERP system and then
proceeding with translation of other systems (like, CRM and BW) after having
supplied these systems with the translations from previous systems. Re-using
previous translations helps to stay consistent and saves money and time.
One of the objectives of a translation strategy is the definition of a project plan.
Like other steps in an implementation project, translation is a complex process
with several milestones that requires additional time, and hence has to be
considered in the general global rollout planning.
Chapter 2 in part 2 of this E-Book, contains more detailed information about the
planning and organization of an SAP translation project.
25
Here you see some examples of use cases.
In the first example we see a rollout to several European countries. The
customer decided to translate to all relevant target languages for ERP, whereas
Business Warehouse was translated only into English. The typical Business
Warehouse end users are executives or managers, so they are supposed to be
very proficient in English.
The second example also shows translation in all relevant languages for ERP
and for a restricted group of languages for Business Warehouse.
In the third example, a US-based company decided to stay with English for all
their rollout countries, except for China and Japan, where English was
supposed not to be accepted and not at the right level for business use.
The last example shows a case in the Fine Metals industry, where a company
decided to have English as the logon language for all users, and only forms
and relevant customizing entries to be printed in the local language.
26
Here you will find some original customer quotes, explaining the reasons why they
decided to move for translation.
27
28
Standard System Language Scope
A standard SAP system is delivered initially and also maintained via support
packages with English and German texts.
In addition, SAP offers around 40 languages for import into and usage in your
system. Please be aware that these languages have different translation depth.
There are various motives for making further languages available. You will need
to define and import the languages depending on your precise requirements, as
we have seen in the diverse scenarios in the previous chapter.
29
Defining a language in your SAP System
Depending on your specific requirements, there are various setup scenarios for
languages in your system
1. Output language for your own forms
Define the languages in question in the Natural Language Setup settings in a system
transaction called SMLT, which is used for defining languages and importing languages in
an SAP system.
2. Output language for standard forms delivered by SAP
In addition, define the languages in transaction SMLT and import the SAP language
packages including the relevant language packages required for your support package
status.
3. Full use of the local language (that is, logging on and using the system in the
local language)
In addition, define the required languages as logon languages in the system parameters.
30
4. Use of the local language only for specific texts such as material master data
Define the languages in question in the natural language setup settings in transaction SMLT.
In addition, perform supplementation (filling, for example, all Spanish fields with English –
apart from the master data).
5. Third party add-ons
If you have purchased and implemented third party add-ons (that is, software from SAP
partners), you should check if language packages are available for the relevant software and
import these, too. Consult your vendor for details and availability of languages.
31
SAP Texts versus Your Own
After successful implementation of functionality, your SAP system consists of
SAP texts and texts created by you while adapting and developing the system
to your specific needs.
The texts coming from SAP standard delivery are completely or partly available
in the SAP language packages, depending on the individual language. Please
check that the SAP delivery matches exactly to your requirements for the
translation depth. For example, F1 Help may not be translated into your
required languages.
The texts coming from your specific implementation, that is, your workbench
development and customizing, are not covered by standard SAP language
delivery and will need translation. For setup and dealing with the translation
itself please refer to the tool chapters in part 2 of this E-Book.
32
Your Implementation, Your Texts
You typically create objects and texts during implementation such as:
Menus, programs and reports
Forms and outputs
Customizing (like payment conditions), and
Master data
If you intend to deploy this functionality in local languages, you need to translate. You then
have to decide exactly which parts of the functionality and text types are relevant for the
individual countries, and then map that to the set of objects. This may turn out to be time
consuming but the result will be a scope that ensures the right level of translation.
Please always make sure that the productive environment is supplemented
correctly, so that potential translation gaps in the area of your development are
filled with a supplementation language and functionality is thus guaranteed.
33
Language Supplementation
English is the only language that is complete in every SAP system. In general,
any other languages are not completely translated.
Missing texts can sometimes cause processes to crash so they need to be
filled in somehow. The language supplementation function, via transaction
SMLT in the language tools enables you to do this.
Generally, it is recommended to use English as the supplementation language,
since this language offers complete translation.
After performing language supplementation, the text is available in the
supplementation language but has the language key of the target language
such as Spanish – ES.
You need to plan for supplementation on a regular basis, for example, after
upgrades, installation of support packages and the release of new functionality.
A word of warning:
Do not supplement in SAP systems that have been set up as systems in which translation
takes place. For example, in a development system. Doing so distorts translation statistics
and makes change management very difficult.
34
This is an example of language supplementation, in which, missing Spanish
texts are filled with the English equivalents.
You can see that the 2 missing Spanish texts are supplemented in English.
35
36
In SAP translation, scoping determines which texts will be translated as part of
your project, and which texts are left out. As a rule, an initial scope will be
defined at the start of the project. The initial scope will then be reduced step by
step, excluding for example, certain packages which do not need translation.
It’s important to note that the process of scoping is a dialogue between the
different teams involved, such as the project manager, IT, development, the
business units and the consultant taking the technical lead. It is especially
important that the business units are involved and sign off on what is in scope
and what is not, so as to avoid surprises in testing and productive use.
At the end of scoping, you will have determined the translation volume, using
the translation statistics, that is if you are working with the SAP system
translation environment around transaction SE63. As a result, you are able to
estimate project costs and define a timeline. This makes scoping a critical first
step in any SAP translation project. Without it, no planning is possible.
In most projects, scoping is a process of a few days for a consultant, not
counting the time for background runs needed to evaluate the translation
volume. In addition, it’s good practice to also plan for additional time needed for
internal decision-making. So while scoping is not instant, investing in scoping
almost always pays off in the long run.
Any texts that are excluded during scoping, as well as any other texts in the
system that are not in scope, will not be translated but instead, supplemented
after translation and only in productive systems. Have a look at the chapter
“Language Design & Architecture” for more information.
37
Measuring Translation
In the SAP system, translation volumes are measured in so-called "SAP lines”,
which can range from 1 to 255 characters in length, from an “OK” button to a
full error message. When translating from German or English, you can expect
an average translation line to contain 3,5 to 4,5 words.
The dialog box on the lefthand side, for example, contains texts ranging from
two characters in length (“No”) and a text with 43 characters (“This data will be
lost when you choose Exit”).
Also, please note that an experienced SAP translator can, on average, process
500 lines per full working day depending on both the complexity and the quality
of the source texts.
There are two main types of texts that can be relevant for translation, short
texts and long texts. Each type is processed by the translator using a different
built-in text editor. Short texts are texts that appear on the user interface, such
as text elements, button texts, or table entries, while long texts are, for
example, used in F1 helps. A third type of text are forms, some of which also
are translated in their own editor.
In the screenshot on the right, the explanation text in the F1 help box is a long
text, while the rest of the texts visible on the screenshot are short texts.
38
Horizontal Scoping
Defining the scope horizontally, means deciding which parts of the relevant
systems (that is, which packages, transport requests, transactions, reports etc.)
are relevant for translation. The scope can range from translating single objects
to translating everything developed in the customer namespaces, plus
customizing and master data. The scope should also be adapted for every
target language and include only the texts that are used in the respective
locations.
As a rule, the better you know your system, the quicker and the more exact
scoping will be. In an ideal case, the development packages or transport
requests that contain the relevant developments are already known. If that is
not the case, the best option is to start from a list of transactions, reports and
tables that are used in each relevant country.
The initial scope should be defined very broadly, since it minimizes the risk of
overlooking relevant texts, which then have to be identified during testing.
Identifying missing texts during testing is very costly, and it can easily take
several hours to identify a single missing text.
Once an initial scope is defined, the stakeholders should work together to
reduce the scope as much as possible, so as few unnecessary texts as
possible remain in scope. The goal is to translate what is needed, but no more.
39
Vertical Scoping
For each language, scoping should also be defined vertically, which means
defining which types of texts should be translated. Examples of text types that
may need translation are customizing tables, messages, forms, and F1 help
texts. There are also many text types that do not need to be translated for the
majority of languages.
There is a minimum set of text types that always need to be translated for
screens to be fully translated in a target language and that should be included
in most translation projects.
In the example in the screenshot, F1 help texts were not in scope for
translation into Russian, so they are displayed in English.
40
Scoping Customizing Texts
Adding customizing entries to the scope is a question of identifying the tables
and table keys that contain the relevant texts. The relevant tables should be
identified before the project starts, be it by scanning the relevant transport
requests or by identifying them manually.
Customizing tables often contain a mixture of target language texts from
different sources, which can make it difficult to identify the texts that actually
need to be translated. The main issue is that the relevant tables can contain
texts imported from SAP language packs and translations entered by internal
teams in the past, which usually do not need to be processed. But they can
also contain texts copied over from a different language, most often English.
The texts may for example, have been copied over during language
supplementation or copied over manually. These lines then need to be
reviewed by a translator.
The screenshot shows a customizing table that is being translated into Chinese
in SE63. It contains both actual Chinese translations and text copied over from
another language, in this case English, which is not an uncommon occurrence.
41
Scoping Master Data Texts
In many companies, translation of master data is an established process that is
part of the day-to-day operations. But additional master data translation may
still be be required within an SAP translation project. For example, as a result
of data conversions from legacy systems that are part of an international roll-
out. If there is no process in place for master data translation, master data that
already exists in SAP systems may also need to be tackled within the scope of
an SAP translation project.
If master data is in scope, one challenge is that it generally only exists in its
most current version on the productive system, while all other SAP translation
activities will take place either in the development system, in a consolidation
system or in a dedicated translation system. Master data texts are also
constantly changing, which means translations need to be updated on a regular
basis.
For scoping purposes, as a rule, the individual master data tables are added to
the scope manually, and the relevant tables should be identified before the
project starts. If the translation volume is not too large, it can make sense to
ask the business units to translate the master data texts themselves, since
these texts are specific to each company. It may also make sense to define a
translation process that is suitable outside the scope of the SAP system
translation.
42
Quick and Comprehensive Information
An easy way to find all language availability information in one source, is to call
up note 330104 via the link shown in the slide.
This note is updated regularly and also contains links to other important
sources of information around translation and languages in SAP systems.
In this note, the languages are shown with a 2-character ISO abbreviation. A
full list of the abbreviations for all languages can be found via the links shown in
the slide.
43
44
Other Information Sources
There are two other sources of information which you can use, if you want to
know in which languages a certain SAP solution is available in.
The first, is via the link in the slide to the SAP Service Marketplace. This
information is language-based.
For a solution-based view on SAP languages, please click the Product
Availability Matrix, which is shown when you click the second link. Here you
can select solutions or even parts of solutions and look at the languages
available for these solutions.
Translation Level of Languages Shipped by SAP
The level of SAP standard translations is different for different languages. This
is because business requirements are not the same for different countries.
Therefore a reduced scope for the translation is possible in some countries, as
we have seen in chapter 2.
Existing translation levels can be categorized as follows:
The translation level “User Interface” includes all elements of the SAP system that are
necessary to operate it, in the user's language. For example, screens, messages, menus,
and interactive PDF forms.
The translation level “User Interface and Selected Help” includes all elements of the User
Interface level, plus selected help. For example, F1 online help for system messages, data
elements, reports, and authorization profiles. One example for this level would be simplified
Chinese.
The translation level “User Interface, Selected Help, and Forms” includes all elements of the
User Interface and Selected Help level, plus forms - for example, SAPscript forms and SAP
Interactive Forms software by Adobe. For instance, French and Spanish are delivered based
on this translation level.
The translation level “Complete Translation” means that all application texts are available in
the respective language. This includes, for example, payroll-specific documentation and
release notes. Japanese and German can be named as examples.
45
The level “Complete Translation with Technical Texts” means that all elements that are
language-dependent are available in the respective language. English is the only language
delivered with this level of translation.
In some application areas, the translation level can deviate from the “global” translation level
for a specific language. This is especially valid for industry-specific areas.
Should the sources in this chapter not be enough to solve your query about language
availability for your set of solutions and languages, then please write to
46
47
After the previous chapters, entering into an SAP translation project may seem
like a daunting task, but it is no more complicated than any other part of an
implementation project. The key is to choose the right experts for the job. Just
as you would use financial experts to set up your general ledger functionality, it
is advisable to use SAP translation experts for SAP system translation projects.
If those experts are not available in your company, or from your implementation
partner, then SAP recommends to cooperate with an SAP Language Service
Partner.
SAP Language Service Partners go through an intensive auditing process by
SAP before they are accepted as a partner. This ensures the quality of services
provided, and the availability of proper experience, knowledge and expertise.
SAP also checks the knowledge and resource retention strategy, to make sure
that the same level of expertise and service, will be continuously available.
SAP differentiates between two service types for Language Service Partners:
Language Consultancy Services – includes scoping and advice on translation strategy
and/or implementation of this strategy, system preparation & setup, deployment of
translation in the system and maintenance activities after translation has finished.
Translation services – include the actual delivery of translation, terminology activities,
staffing, project management and monitoring.
A detailed overview of services available for each of the service types is shown
on the next slide.
48
49
Selecting the Right Partner for Your Language Project
You may ask yourself, “How do I choose the right partner to support me in my
language project?” This page offers a checklist of criteria and questions to ask
any company offering SAP language services.
A key decision factor for SAP system translation services should always be
previous experience with SAP systems.
Even if the actual translation is done in another environment, SAP system
knowledge is required to make sure no damage is done with export and import
activities, and the translation is actually usable and sustainable in the system.
SAP Language Service Partners fullfil these criteria.
50
The SAP Language Services Support portal was launched in May 2016, mainly to support the
agencies translating for SAP. The supplier-facing information is not accessible for customers
and partners.
However, as from mid of June 2016, the portal will also include customer-facing information on
SAP Language Service Partners. More specifically:
A general information document
A partner list
Partner success stories
This E-Book
When looking for SAP Language Service Partners, we recommend you use the partner list on
this page, as it also indicates which service types are offered by the partners.
Another option is to use the SAP Partner Finder, and select the Partner Type “Language
and Translation Partners”
51
Many customers ask themselves how other companies have approached their
language projects, and what the cooperation with a language services partner
brings. Some good examples answering such questions can be found in the
four success stories listed on this slide. Please click on stories listed below to
read more about the real-life benefits of cooperation with SAP Language
Service Partners
The fifth success story is this E-Book itself, which was co-authored by 4 SAP
Language Service Partners offering Language Consultancy Services. These
partners are Lucy Software, Morphologic Translations, Text&Form and
Wordflow. Please click on the company logos to go to the company websites,
or visit the company storefronts in the SAP Store.
And last but not least, should you need more information or tailored advice,
then please contact SAP. The program manager of the SAP Language Service
Partners is Gerdien Meijering. She will be happy to answer your questions.
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68