Language Settings
Language Settings is the group of Salesforce Setup configurations that control which languages an org runs in and how users see translated content.
Definition
Language Settings is the group of Salesforce Setup configurations that control which languages an org runs in and how users see translated content. It governs two separate things that admins often mix up: the display language each user sees in the interface, and the content language used to translate picklist values, field labels, and other metadata through the Translation Workbench. Both work together for a multi-language org, but they are configured in different places and behave differently.
Salesforce sorts every language into one of three support levels, and that level decides how much translation you get for free. Fully supported languages translate the whole interface, including Setup and Help. End-user languages translate standard object labels and end-user pages but leave Setup, admin pages, and Help in English. Platform-only languages provide no standard translation at all and exist so you can localize the custom apps you build. Knowing which level your target language falls into is the first thing to check before you promise localization.
How the three language support levels shape what users actually see
The three support levels and why they matter
Salesforce groups languages into fully supported, end-user, and platform-only tiers, and the tier sets your expectations. Fully supported languages number around 18 and include English, French, German, Spanish, Italian, Dutch, Japanese, Korean, Chinese (both Simplified and Traditional), Portuguese (Brazil), Russian, Swedish, Danish, Finnish, Norwegian, and Thai. For these, the entire product is translated, Setup and Help included. End-user languages number around 19, covering Arabic, Hebrew, Polish, Turkish, Greek, Czech, and others. They translate standard object labels and end-user pages, but Setup, admin screens, and Help stay in English, and Salesforce does not provide support in these languages. Platform-only languages exceed 80 and include regional variants like Spanish (Argentina), French (Canada), and English (Australia). They carry no standard translation, so you use them only to localize your own custom labels, objects, and field names. Untranslated labels fall back to English (a few platform-only languages fall back to a related language, such as Catalan to Spanish). Pick the tier before you scope a localization project.
Display language versus content language
Two ideas live under Language Settings, and separating them prevents most confusion. Display language is what an individual user sees in menus, buttons, and standard labels. It is driven by the Language field on each User record, and the choices available there come from the languages the org has enabled. Content language is the translation of metadata such as picklist values, custom field labels, field-level help, and custom labels, and it is supplied through the Translation Workbench. Enabling a language for translation does not change anyone's display language by itself. A user only sees translated content when their personal Language matches the locale that a translation was entered against. So an org can run almost entirely in English while still presenting French picklist values to users whose Language is set to French. Treat the display layer and the content layer as two switches you set independently, because changing one does not automatically change the other.
Setting the org default and enabling languages
The org-wide default display language lives under Setup in Company Information. The Default Language there sets the language new users inherit and the fallback the platform uses when a user has no language of their own. Enabling additional languages so users can choose them is handled through the language settings in Setup, and once a language is available it shows up in the Language picklist on the User record. This part is non-disruptive: turning a language on does not retranslate anything or change existing users, it simply widens the menu of choices. A common pattern is one primary default for the company with a handful of additional display languages enabled for regional teams. Plan the default carefully, because every user created without an explicit language inherits it, and changing the org default later does not rewrite the Language field on users who already exist.
The Translation Workbench and translators
Content translation runs through the Translation Workbench, enabled from Setup. Once on, you add each language under Translation Language Settings and mark it Active when its translations are ready for users to see. You also assign translators, who are users granted permission to enter translations for the languages you assign them. A translator needs the View Setup and Configuration permission and can only translate the languages they are assigned. The Workbench covers picklist values, custom field labels, field-level help, validation rule error messages, custom labels, and similar metadata. Each translation is keyed to the original English string and a target locale. Salesforce recommends leaving a language Inactive until translators finish, because Active status is what exposes the translations to end users. Active and Inactive control only what users see; the setting does not affect the import or export of translation files, so you can keep loading translations in the background while a language stays hidden.
Language and Locale are not the same field
On every User record, Language and Locale are separate settings that do separate jobs. Language controls the words: the interface text and translated labels a user reads. Locale controls the format: how numbers, dates, times, currency, and names are displayed for that user. They are independent, so a support agent might keep the interface in English while switching Locale to match a customer's region for correct date and currency formatting. Many orgs set both to the same value out of habit, which is fine, but the two were designed to move apart when needed. Users can edit both for themselves under their personal settings on the Language and Time Zone page, and admins can set them on the User record. When you test a rollout, change Language and Locale separately so you can tell whether a formatting problem comes from the wrong translation or the wrong number and date format.
Email templates, reports, and where translation stops
Some surfaces translate, and some do not, so plan around the boundary. Email templates can have locale-specific variants, and the platform can pick the matching template based on the recipient's Language, but each variant is a separate template you build and maintain, so map this out before a multi-language mass send. Report and dashboard labels translate through the Translation Workbench, yet the report data itself does not. If your records hold values in several languages, a report shows those underlying values regardless of who is viewing, because translation lives in the metadata layer, not the stored data. This is why the bigger decision is structural: will you keep shared records and translate their metadata, or store separate records per language. That choice ripples through every object that touches customer-facing content, so align it with the business plan before you enable a single language.
How to enable a language and translate content
Enabling a new display language and translating content are two tasks. Here is the order an admin follows in Setup to do both for a single org.
- Confirm the support level
Check whether your target language is fully supported, end-user, or platform-only on the Supported Languages page. This tells you how much of the interface is already translated and how much you must translate yourself.
- Set or confirm the org default
From Setup, open Company Information and edit the Default Language. This is the language new users inherit and the platform's fallback when a user has none of their own.
- Enable the display language
Turn on the languages you want users to be able to choose. Once enabled, each language appears in the Language picklist on the User record so individuals can select it.
- Enable Translation Workbench
From Setup, enable Translation Workbench, then under Translation Language Settings add each language you plan to translate and assign translators to it.
- Translate, then activate
Let translators enter picklist, label, and custom label translations while the language stays Inactive. Mark it Active only when the translations are ready for users to see.
Org-wide setting in Company Information that new users inherit and that acts as the fallback display language.
Per-user field on the User record that sets the interface display language for that one person, chosen from enabled languages.
Per-language toggle in Translation Language Settings that exposes finished translations to end users; leave it off until translation is complete.
Users granted the View Setup and Configuration permission and assigned to specific languages so they can enter translations for those languages only.
- Enabling a language widens the user menu but translates nothing on its own; content still needs the Translation Workbench.
- End-user languages leave Setup, admin pages, and Help in English, so admins working in those screens still see English.
- Changing the org Default Language later does not update the Language field on users who already exist.
- Report data never auto-translates; only labels do, so multi-language reporting depends on your underlying data model.
Prefer this walkthrough as its own page? How to Language Settings in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Supported LanguagesSalesforce
- Add Translation Languages and TranslatorsSalesforce
- Language, Locale, and Currency SettingsSalesforce
Straight from the source - Salesforce's reference material on Language Settings.
- Supported LanguagesSalesforce
- LanguageSettings | Metadata API Developer GuideSalesforce
Hands-on resources to go deeper on Language Settings.
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. On a Salesforce User record, how do the Language field and the Locale field differ in what they control?
Q2. Which tool do translators use to provide translated picklist values, custom labels, and validation rule error messages for an enabled language?
Q3. Before enabling a target language for a localization project, why does Language Settings push admins to confirm whether it is fully or partially translated?
Discussion
Loading discussion…