the main goal of this e-book is to give an introduction on ... · the main goal of this e-book is...

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

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.

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.

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.

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.

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

[email protected].

46

mailto:[email protected]

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

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