How to translate picklist values in Salesforce

A picklist value is translated in Translation Workbench (Setup → Translate), but where in it — and where the translation is stored — depends on where the value is defined: on a custom field, in a global value set shared by several fields, or in one of Salesforce's standard picklists. Only the value's label is translated. Its API name stays the same in every language, which is what keeps reports, integrations and formulas working.

First, find out where the value is defined

Open the field in Object Manager → the object → Fields & Relationships. The field's detail page tells you which kind it is:

• Values defined on the field — a custom picklist with its own values.
• Uses a global value set — the values belong to the named value set (Setup → Picklist Value Sets), and every field that uses it shares their translations.
• A standard field (Industry, Lead Source, Case Status, Opportunity Stage …) — its values are a standard value set, owned by Salesforce's standard object.

The difference matters twice: it decides where you translate, and it decides which metadata a deployment has to carry.

Translating the values

In Setup → Translate, choose the language, then:

Double-click a value's translation cell, type and save. For standard picklists, only the values Salesforce lets you edit are offered (metadata available for translation). For many values or several languages, Translation Workbench's Export and Import carry picklist values with everything else (export and import).

Record type names are translated separately (Setup Component Record Type), even though a record type often looks like a picklist on the page.

What the translation changes — and what it does not

The label a user sees changes; the value stored in the record does not. That has consequences worth knowing before anyone reports a bug:

• Record pages, list views and reports show the translated label in the user's language.
• SOQL returns the stored value, unless you ask for the label: toLabel() translates results into the language of the user who runs the query — SELECT toLabel(Industry) FROM Account, or toLabel(RecordType.Name) for record types. Apex that compares a picklist to a string should compare API names, never labels.
• Formulas see the API name. TEXT() converts a picklist's value to "the value's API name", so a formula that builds a sentence from a picklist is not translated.
• Integrations read and write API names; a translation never breaks them.

A picklist value that will not translate: a checklist

1. Is it the user's language? The translation must be for the language on the user's record, and that language must be Active in Translation Language Settings.
2. Is the value where you translated it? A value from a global value set is translated on the value set, not on the field.
3. Is it a picklist value at all? A record type's name, a field's help text or a Custom Label in a component can look like one. The guide to finding the metadata behind Lightning text covers how to tell.
4. Is the text built by a formula or by code? Formulas and code that build text from the stored value show the API name, whatever the translation says.
5. Was the value renamed? A translation entered before the value's label changed can still be there, describing the old label; Translation Workbench's Out of Date column flags labels whose primary label was updated after translation.
6. Did it reach this org? A translation made in a sandbox is not in production until it is deployed — see comparing translations between orgs.

For developers: deploying picklist translations

• A custom picklist's value translations travel in the object's CustomObjectTranslation (Account-es), under the field — and a retrieve returns only the translations of components named in the same package.xml, so name the field too.
• Global value sets translate in GlobalValueSetTranslation, standard picklists in StandardValueSetTranslation, one file per value set and language (Salesforce's own example is AccountRating-fr).
• Compare the translation files of two orgs before deploying one over the other: a value renamed in one org and not the other no longer lines up, and the diff is where that shows.

Related guides

• Translating a Salesforce org: where every label is translatedThe map — which Setup page translates which label, how to translate many at once, the metadata types behind them, and how to check the result.
• How to find missing translations in SalesforceUntranslated and out-of-date labels, found systematically — with Translation Workbench's export and grid, on the pages users see, and as a release checklist.
• How to find the Salesforce metadata behind text in LightningA word on a Lightning page can be a field, a picklist value, a Custom Label, a section or a button. How to tell which, and find its API name — in Setup, with a query, or from the page itself.