Multi-Language Document Generation in SAP CPQ: What Decides the Language

A quote document that arrives in the wrong language is one of those problems that never throws an error. The layout is fine, the prices are right, and the product descriptions are in Italian for a customer in Munich. Nobody has to make a mistake for this to happen, because multi-language document generation in SAP CPQ is decided by a chain of settings, stored text and template tags that live in different corners of Setup.

SAP documents every link in that chain. It just does so across the Document Generation Templates, User Journey, Generating Documents, General Settings and Translations pages, and those pages do not always agree with each other. I read them against the 2609 documentation, and this puts the chain in order: what picks the language, what gets translated, what the template can do, and where to look when the output is wrong. Where the documentation is silent or contradicts itself, I say so instead of guessing.

Multi-language document generation in SAP CPQ starts with two parameters and a default

Everything begins in Setup, under Document Generation Templates, in General Settings. The first parameter is called “Users can choose customer’s language when creating documents”. When it is on, the Choose Template and Customize steps show a language dropdown. On Quote 1.0 that dropdown lists the languages available for translation. On Quote 2.0 it lists every system and custom dictionary on the tenant, and the administrator can either leave a language ID field empty, which preselects the tenant’s default dictionary, or build the list with a Formula Builder so that users only see the languages a rule allows them. A user without access to the selected dictionary or formula sees the default and nothing else, according to the Quote 2.0 General Settings page.

What happens when nobody picks a language

The second parameter, “Translate quotes using the user’s default dictionary”, only matters when the user chose no language or left the dropdown on Default. If it is enabled, the document follows the user’s default dictionary. If it is disabled, the document follows the language in which the quote was created. Take a quote created in German and opened by a colleague whose default dictionary is English: with the parameter off the document comes out in German, with it on it comes out in English, and a language picked in the dropdown beats both.

The chosen language also covers more than the attached file. According to the Generating Documents page of the User Guide, it applies to the generated document, to the subject and body of the email sent to the customer, and to the proposal page the customer opens from the link in that email. A 2505 fix made subject and body follow the language selected during generation rather than the sender’s default.

Predefined language and the skipped step

On Quote 2.0 an administrator can now set a document language per user in advance. That predefined language arrived in the 2608 release, and when a user has none the system falls back to the tenant’s default dictionary. There is a side effect worth knowing before you test a single-template setup. Normally, with only one template available, SAP CPQ skips the Choose Template step. If the language can be chosen, it does not skip, and the user stays on that page. The 2602 release notes describe this, and a fix in 2511.0.3 removed a “dictionary undefined” error that appeared when the step was skipped. If your set of quote templates that has to serve several markets suddenly shows an extra page, this is why, not a bug.

What gets translated, and what stays in the language it was saved in

Translations live in Setup, not in the template

Most of what ends up in a document is translated in the object where it is maintained, through the “Translate this item” action. The Quote 2.0 Translations page lists the objects: products, attributes, attribute values, categories and product tabs in the catalog, custom fields, custom quote tabs, partner functions and document generation templates in Quotes, and statuses, actions and approval rules in the workflow. The same page carries a note that multilanguage translations cannot be added to SAP CPQ through the API and have to be entered manually. Even that note has a nuance, because the 2508 release notes mention a bulk import job for product translations, so I would read it as “not through the API” and nothing stronger.

A SAP Community question from October 2024 complained that the team had “to translate in X places”. The complaint is fair, and the fallback rule makes it matter: any entry missing in the selected language is shown in the default language. A half-translated catalog therefore produces a document that mixes two languages without a single error. This is the translation half of what I mean when I say localization is more than a translation task, with currency and rounding being the other half.

The description is frozen on the quote item

This one catches experienced administrators. The User Journey page explains that when an item is added to a quote, its description is stored directly on the quote item. If the quote was started in one language and the document is later generated in the environment’s default language, the item fields are not translated, and the description and long description appear exactly as stored. In their example, an Italian quote with a German document requested and no German translation falls back to the product definition value.

The fields that follow the selected language differ by engine. On Quote 1.0 they are Product Name, Item Label, Description, Long Description and Description Builder. The Quote 2.0 list has no Item Label. Attribute and attribute value translations work in both Word and Excel templates, provided a translation exists for that language. On top of that, Quote 1.0 has a limitation that looks like a defect: no translation of item values occurs if the dictionary selected for document generation matches the dictionary of the user generating the document, which is the Quote 1.0 dictionary match I described in the tag reference. You test with your own account and the feature appears dead. A SAP Community question from December 2025 describes the same symptom in a Quote 2.0 context: translations imported, attribute values in the document stuck in one language.

Custom dictionaries only override

A system dictionary exists for each supported language and cannot be changed. A custom dictionary inherits from a parent and overrides individual terms, the documentation’s own example being color becoming colour for British English. Regional variants such as English – Australia get their own ISO code, EN-AU. The catch is explicit: product names, attribute labels and categories cannot be translated into custom dictionaries, only into the empty system dictionaries. When a user picks a custom dictionary at generation time, items are translated through the system dictionary it derives from.

Two places in the documentation contradict each other here, and I would test both before designing around them. The page on which dictionary a user receives says the lowest rank is retrieved first, while a note on the same page says the highest rank becomes the default. And the Limitations page says custom dictionaries cannot be set as default per user, while the dictionary form has a “Condition for Defaulting to this Dictionary” field. Custom table values have no built-in translation either. The accepted answer to a 2021 SAP Community question was to keep the translations in the custom table yourself and pick the row by the user’s logon language. User custom field values had their own defect, where they stayed in the original language after the default dictionary changed, with a fix planned in 2502 according to KBA 3514067.

Translating inside the template: the tags that help and the gaps that remain

The Translated CTX tags

The Quote 2.0 guide has a page called Enhanced Language Tags for companies working in several languages. It lists eight: Product.Name.Translated, Product.Description.Translated, Product.LongDescription.Translated, Product.QuoteDescription.Translated, and for attributes Value, Label, Description and ValueDescription, each with the Translated suffix. If a value is not found in the current dictionary, the default dictionary value is returned. The Quote 1.0 User Journey describes a related pair for the product name: ProductNameTranslated returns the value in the user’s current language, while ProductName returns the value from the product definition.

Here is what the page does not say, and it is the question I would most want answered: whether “current dictionary” means the language picked during generation or the language of the user running it. The page does not state the release that introduced these tags either. Until you have rendered one document in a language that is not your own default, I would treat the answer as unknown.

Static text, numbers, dates and fonts

Static wording inside the Word or Excel file is the biggest gap. The documentation lets you translate the template’s name and description, and the catalog data above, but I found no documented mechanism for translating fixed text in the template body. It does not say whether one template should serve all languages or whether each language gets its own, so that is a design decision, and it pulls in the variation by region and language that templates pick up over time. Two documented building blocks point in a direction. SAP Community shows text kept in a custom table and inserted with custom table tags when different text is needed per attribute combination, and a SAP topic expert mentioned that IronPython’s Translation.Get(dictionaryId, key) can be used for custom logic and custom outputs. Neither is presented as a template translation feature, so both need a test on your tenant.

Dates and numbers follow the same pattern of not being tied to language. The date tags return dates in the user’s date format, and SAP’s tip for numbers returns them in the user’s selected number format. Nothing says the format follows the document language, so if your users’ profile formats and your document languages differ, use an explicit CTX format string where the format matters. Fonts are the last surprise. Word output keeps the fonts of the template, but for PDF the documentation warns that Aspose may not recognize custom fonts and can replace them with defaults such as Arial or Times New Roman. Custom fonts are uploaded under Setup, File Management, Fonts, only .ttf and .otf are accepted, and a missing font produces a warning in the event log. The font page says nothing about scripts, so check a PDF in every target language early, and never switch fonts inside one tag or inside a C loop.

Why the document comes out in the wrong language

When the output is wrong, I work through the same short list in the same order, because the causes above stack and the cheap checks come first.

1. Is the language parameter on, and can this user see the dictionary? On Quote 2.0, a user without access falls back to the default.
2. Did the user choose a language, or leave Default? If Default, the second parameter decides, not the dropdown.
3. Does the entry exist in the selected language? If not, the default language value is shown.
4. Was the description stored on the quote item in another language when the item was added?
5. On Quote 1.0, does the dictionary chosen for the document match the generating user’s own dictionary?
6. Is the text a custom table value or a custom field? Those are maintained separately and are not covered by the dictionary.
7. Did the user go back to Choose Template? Returning discards the customization but keeps the chosen language, while Cancel and Return to Quote resets the language as well.

That covers the failures the documentation explains. The ones it does not explain are the ones to test on a sandbox before a go-live: whether the Translated tags follow the generation language, whether number and date formats follow it, and how fixed template text should be translated. If you would rather not find those answers in front of a customer, a wider troubleshooting service for quote behavior is usually faster than another round of trial and error, and teaching the administrators who maintain the translations how the chain fits together prevents most of it in the first place. Multi-language document generation in SAP CPQ is not hard once you know which setting owns which decision. The trouble is that no single page tells you.