Translation Workbench
A Translation Workbench is a Salesforce Setup feature that manages translations of customizable text and metadata labels into the languages your org supports.
Definition
A Translation Workbench is a Salesforce Setup feature that manages translations of customizable text and metadata labels into the languages your org supports. It covers items like custom labels, picklist values, custom field names, record type labels, validation rule error messages, and custom tab names, so users see the application in their own language.
It is available only for multi-language orgs, not single-language ones. Once enabled, an admin picks the languages to translate, assigns translators, and those translators enter or override text component by component. Salesforce tracks which entries fall out of date when the source value changes.
How Translation Workbench localizes a multilingual org
Enabling the workbench and adding languages
Translation Workbench is off until you turn it on. From Setup, type Translation Language Settings in the Quick Find box, open that node, then click Enable on the welcome page. The Manage Translation permission ships enabled in the System Administrator profile, so most admins already have access. Remember the feature works only in a multi-language org, so your org must support more than one platform language first. After enabling, you add the specific languages you want to translate. On the Translation Language Settings page click Add, choose a language, and assign one or more translators to it. A translator is just a Salesforce user who will supply the translated strings. You can leave a language inactive while translation is still in progress, then mark it Active when the work is done. Salesforce recommends you do not activate a language until translators have finished, because users assigned that language will immediately start seeing whatever has been entered, including any gaps. Inactive languages stay hidden from end users but remain editable in the workbench.
What you can and cannot translate
The workbench handles customizable metadata text, not the standard Salesforce interface. Standard labels like the word Account or the Save button come from the platform language pack, and the support level of each language decides how much of that is already localized. Through the workbench itself you translate the parts you built or configured. Translatable components include custom labels, picklist and multi-select picklist values, custom field names and their help text, record type names, validation rule error messages, custom tab labels, web tabs, workflow task subjects, button and link labels, and standard field overrides. You pick a setup component from a dropdown, expand the metadata tree, and fill in a translation next to each source value. Reports, dashboards, and the actual data inside records are out of scope here. Record-level data such as a knowledge article body uses a separate translation flow, not this tool. Knowing the boundary saves time. If a string never appears as an option in the component dropdown, the workbench is not where you translate it, and you look at the language pack or a data translation feature instead.
Translation mode versus override mode
The workbench offers two ways to enter text. Translation mode is the common one. You select a language other than your org default and supply the equivalent string for each source value, so a Spanish user sees Spanish picklist options while an English user sees English. This is how you build out a brand new language across your customizations. Override mode targets a different problem. It lets you replace a value that already came from somewhere, most often a second-generation managed package installed from AppExchange. A package author ships labels and translations, but those words may not match your company terminology. With override you change the displayed text for a language without editing the package itself, and your override wins for your org. You can also override the default language value to relabel something locally. Choose the mode that fits the job. Use translation mode to add a language from scratch, and use override mode to adjust strings a package or the platform already provided. Both modes write to the same per-language translation records, so a user only ever sees one final string per item.
Language support levels affect coverage
Not every language gets the same treatment from Salesforce, and the level matters before you promise a full localization. There are three tiers. Fully supported languages translate the entire product, including admin Setup screens and help, and cover languages such as French, German, Japanese, and Chinese. End user languages translate the standard objects and pages a normal user touches, but leave administration Setup and help in English, covering languages like Arabic, Greek, and Hebrew. Platform Only languages translate nothing out of the box, so you localize custom labels, custom object and field names, and other customizations entirely yourself. Translation Workbench is what makes Platform Only and partial languages usable, because it is the mechanism for supplying the strings Salesforce does not. A Platform Only language is essentially blank until your translators fill it in. When scoping a rollout, check the support level of each target language first. A fully supported language needs translation only for your customizations, while a Platform Only language means translating every label your users will read.
Keeping translations current with Out of Date tracking
Translation is not a one-time task. Every new picklist value, custom field, or validation message you create adds an untranslated string, and editing an existing source value can invalidate the translation already entered. The workbench helps you find this drift. When a source label changes after a translation was supplied, Salesforce flags the existing entry as out of date so a translator knows to revisit it rather than leaving stale text in front of users. In the editing grid you can filter to see untranslated or out of date items, which turns an open-ended task into a short worklist. For larger orgs, you can export all translations to a file, edit them in bulk outside Salesforce, and import the file back, which suits teams using an external translation service. Treat this as standing maintenance tied to your release process. When admins ship a customization that adds user-facing text, the translation pass should follow before that change reaches a multilingual audience, or some users see English mixed into their language.
Who owns translation and a worked rollout
Clear ownership keeps a multilingual org consistent. The admin enables the feature, picks languages, and assigns translators, while the translators (often subject matter experts or a localization vendor) supply the actual wording. Picking one owner per language avoids two people entering conflicting terms for the same field. Picture an org expanding into France. The admin confirms French is a fully supported language, so standard screens are already covered, then adds French in Translation Language Settings and assigns a bilingual team member as translator, leaving the language inactive. The translator opens Translate, works through each component, custom labels first, then picklist values on Opportunity Stage, then validation rule messages, entering French for every source string. They filter on untranslated items to confirm nothing is missed. The admin sets French to Active, and French-language users now see localized customizations alongside the already-translated standard UI. Two weeks later a new picklist value appears as out of date, the translator updates that one entry, and the org stays consistent. This pattern, scope by support level then translate then activate then maintain, repeats for each new language.
How to set up Translation Workbench
Enable Translation Workbench and add a language so translators can start localizing your customizations. You need a multi-language org and the Manage Translation permission, which the System Administrator profile already has.
- Enable the workbench
From Setup, enter Translation Language Settings in the Quick Find box and select it. On the welcome page, click Enable. The feature appears only if your org supports more than one language.
- Add a language and translators
On the Translation Language Settings page click Add, choose the target language, and assign one or more users as translators. Leave Active unchecked while translation is still underway.
- Enter translations
Go to Setup, open Translate, choose the language and a setup component such as Picklist Value or Custom Label, expand the tree, and type the translated text next to each source value. Filter to untranslated or out of date items to track progress.
- Activate the language
Once translators confirm every string is filled in, return to Translation Language Settings, edit the language, and select Active. Users assigned that language now see your translated customizations.
Makes a language visible to end users. Keep it off until translation is complete so users do not see gaps or untranslated strings.
The users responsible for entering strings for a language. Assign one clear owner per language to avoid conflicting terminology.
On the Translate page, selects which metadata type you are translating, such as custom labels, picklist values, record types, or validation rule error messages.
Lets you replace strings already supplied by a second-generation managed package or the default language, instead of adding a brand new language translation.
- Translation Workbench is unavailable in single-language orgs. Your org must support more than one language before the Enable option appears.
- Activating a language before translators finish exposes untranslated or partial strings to those users immediately.
- The workbench translates customizable metadata, not record data or the standard UI. Standard labels come from the language pack based on the support level.
- Editing a source value can mark its existing translation out of date, so translations need maintenance every time customizations change.
Trust & references
Cross-checked against the following references.
- Translation Workbench OverviewSalesforce
- Add Translated Languages and TranslatorsSalesforce
Straight from the source - Salesforce's reference material on Translation Workbench.
- Translate Metadata LabelsSalesforce
- Enable Translation WorkbenchSalesforce
Hands-on resources to go deeper on Translation Workbench.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Translation Workbench?
Q2. What can be translated?
Q3. Is translation a one-time task?
Discussion
Loading discussion…