Language Settings
Language Settings is the Salesforce Setup configuration that controls which languages are enabled for an org and how users interact with multi-language content.
Definition
Language Settings is the Salesforce Setup configuration that controls which languages are enabled for an org and how users interact with multi-language content. The page exposes two distinct concepts that are often confused: end-user display language (the language the Salesforce UI shows for each user) and content language (the language of records, picklist values, and translated content stored in the org). Both work together to provide a multi-language experience, but they configure separately and have different downstream effects.
End-user display language is set per user on the User record (Language field). The available choices come from the Languages list configured in Setup. Salesforce supports over 30 fully translated languages and additional partially translated languages. Content language uses the Translation Workbench to translate picklist values, field labels, custom labels, page layouts, and email templates. Enabling a language for translation makes it available as a content-translation target without changing what individual users see by default.
How Language Settings works
Fully versus partially translated languages
Salesforce ships UI translations for the core supported languages (English, Spanish, French, German, Japanese, Chinese, Portuguese, and dozens more). Partially translated languages have UI translation for parts of the platform but not all; users may see English fallback in some screens. Confirm which category your target languages fall into before promising full localization; partial languages produce inconsistent user experience.
Enable language at the org level
Setup > Company Information > Edit. The Languages section lists every language enabled for the org. Add the languages your users speak. Enabling a language adds it to the User Language picklist and to the Translation Workbench available locales. This is a one-time setup per language; enabling is non-disruptive.
Per-user Language and Locale
Each User record has a Language field (UI display language) and a Locale field (number, date, currency formatting). These are independent: a user might display the UI in English but use French locale for date formatting. Most orgs default both to the same locale, but global support staff sometimes display the UI in their own language while using the customer's locale for formatting.
Translation Workbench
Translation Workbench (Setup > Translation Workbench) lets translators provide translations for picklist values, field-level help, custom labels, validation rule error messages, and other translatable content. Each translation is keyed to the original English and the target locale. Translators add translations; users see them when their User Language matches the locale.
Email templates and locale
Email templates can be marked as locale-specific, with the platform selecting the matching template based on the recipient's Language. The setup is more complex than UI translation: each template needs a per-locale variant, and the routing logic checks the recipient User record. For mass email sends to multi-language audiences, plan template structure upfront.
Reports and dashboards
Report labels and dashboard titles translate through Translation Workbench. Report data itself does not auto-translate; if your records have content in multiple languages, the report shows the underlying values regardless of the viewer's language. Plan reporting around the underlying data structure, not the UI translation layer.
Plan adoption around language strategy
Before enabling languages, decide whether your org runs in one primary language with users seeing UI translation, or operates truly multi-language with content in each user's language. The two strategies require different metadata: shared records with translation versus separate records per language. The metadata decision affects every object touching customer-facing content; align with the business strategy upfront.
Enable and configure languages
Enabling languages is a one-time setup; configuring users and translating content is ongoing. The steps below cover the initial rollout.
- List target languages
Identify the languages your users speak. Confirm each is fully supported by Salesforce; partially supported produces inconsistent UX.
- Enable languages at org level
Setup > Company Information > Edit. Add target languages to the Languages list. Save.
- Set user Language fields
For each user, set the Language field on their User record to the appropriate value. Bulk update through Data Loader for large orgs.
- Set user Locale fields
Independently set Locale per user for formatting. Often defaults to match Language but not always.
- Translate content through Translation Workbench
Setup > Translation Workbench > Translate. Provide translations for picklist values, labels, validation rules, etc.
- Plan email templates per locale
For each mass-email template, create locale-specific variants. Configure the routing to pick the right variant based on recipient Language.
- Test from a sample user
Use Login As to impersonate a non-English user. Confirm the UI displays in their language and translations appear where expected.
Full UI translation. The standard target for production deployment.
Some UI translation. Users see English fallback in some screens.
Per-user display language. Set on the User record.
Per-user formatting locale. Independent of Language.
Tool for translating picklists, labels, and other content.
- Fully versus partially supported languages produce different UX. Confirm fully supported before promising localization.
- Language and Locale are independent fields. Setting one without the other produces mixed UX.
- Report data does not auto-translate. The UI layer translates labels; the records themselves remain in whatever language they were entered.
- Email template locale routing requires deliberate setup. Mass send without per-locale variants produces single-language output regardless of recipient language.
- Multi-language strategy is a metadata decision. Shared records with translation vs separate records per language affects every customer-facing object.
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. Why is understanding Language Settings important for Salesforce admins?
Q2. What is the primary benefit of Language Settings for Salesforce administrators?
Q3. In which area of Salesforce would you typically find Language Settings?
Discussion
Loading discussion…