Four Languages, One CRM: Making SSCV2 Truly Multilingual

Switzerland has four national languages, and a Swiss CRM rollout that only speaks German is half a rollout. We have taken SAP Sales and Service Cloud V2 through full German, French, Italian and English adaptation on client projects. The platform can do it. The know-how is scattered, and most of what went wrong for us went wrong conceptually, not technically.

TL;DR: In SSCV2 the logon language of the session decides everything, and a reload does not change it. Field labels and code values are two separate translation jobs. Mashups only receive the language through a system parameter bound per mashup and per tenant. The language must be active in the tenant before anyone can log in with it. And all four languages belong in the definition of done, checked after a fresh login.

Rule 1: the logon language decides

The display language of an SSCV2 session is the language chosen at login, fixed until logout. Not the browser language, not a preference field on the user record, not a claim in the token. Once you accept this, half the mysterious behaviour disappears.

It has a sneaky testing consequence. Colleagues switch the language, reload the page, see the old language and file a bug. Log out, log back in, and only then judge. We have watched perfectly correct translations rejected in testing purely because of a reload.

Rule 2: the language has to be active in the tenant

Before any of this matters, the language must be switched on in the tenant: activated, and enabled as a communication language. If it is not, nobody can choose it at login, and your French acceptance test cannot even start. It takes a minute to check and saves a lost test day.

Rule 3: translation is two jobs, not one

Field labels and the values inside selection lists are maintained separately, through different services. Labels go through language adaptation, one entry per language. Code values have their own texts per language. Translate only the labels and your French users see a perfect label above a list of raw technical codes.

Two smaller lessons ride along. First, read before you write: real tenants are rarely clean, and we have found the same label empty in two languages, with a typo in the third and a test string in the fourth. Second, a proper translation takes precedence over the hardcoded label, so a wrongly named field rarely needs an irreversible UI change. It needs four good translations.

SAP describes the adaptation tooling in the SAP Sales Cloud V2 documentation; the underlying services are listed on the SAP Business Accelerator Hub.

Rule 4: embedded pages only know the language if you pass it

Mashups, the pages you embed in the CRM, are where multilingual efforts usually fail. The iframe cannot see which language the surrounding session runs in. The mashup has to pass it: in the mashup configuration you bind a URL parameter (we use lang) to the system parameter for the logon language, and while you are there, a theme parameter to the system theme. SAP Learning shows the binding in Configuring a Mashup in SAP Sales Cloud and SAP Service Cloud Version 2.

Two traps. The binding is configured per mashup, not per page, and mashups do not travel with your code repository: every tenant needs it again. And the tempting workarounds do not work. The user record’s preferred-language field is often empty and has no effect on the session; the browser language is the browser’s, not the CRM’s; the token carries no locale. We have seen a custom lookup fail in both directions: an empty field that yields nothing, and a stale one that overrides the correct session language. Take the language the platform hands you and keep the texts with the page. For more on how we build these pages, see extending Sales Cloud V2 with custom apps on SAP BTP.

Rule 5: languages are part of done, not aftercare

The biggest lesson is organisational. Deliveries came back from customer testing not because a translation was missing, but because translation was treated as a final polish step. Our rule now: nothing goes to the customer before two checks are done.

1. All four languages are present for every new label, code value and message, including the error messages of custom validation logic.
2. One non-default language is checked by a person after a fresh login, not after a reload, on every screen and mashup that changed.

Each check takes a minute, and each exists because its absence once cost us a retest round. Doing it early is cheaper than doing it twice, especially in four languages.

This is one of the gaps we describe in our honest assessment of Sales Cloud V2 limitations: the platform supports the languages, but the delivery discipline has to come from the project. It is also a good question to ask any partner on a Swiss shortlist, as we suggest in our overview of SAP CX consultancies in Switzerland.

Four-language rollouts are standard in our Swiss projects; our page on SAP CX consulting in Switzerland describes how we deliver them.

If you are running Sales Cloud V2 or Service Cloud V2 in a multilingual market and want these checks built into your delivery rather than discovered in testing, talk to us.