Creating Translations for Users in Salesforce

Part 30: Creating Translations for Users in Salesforce

If your Salesforce org supports users who speak different languages, you need a way to translate field labels, picklist values, custom buttons, page layouts, and more — without building a separate org for every locale. Salesforce provides two main tools for this: the Translation Workbench for internal CRM translations, and Experience Cloud Site Translations for translating external-facing portals and communities. In this part of our Salesforce series, we will cover both tools end to end — what they are, how to set them up, and the best practices that keep multilingual orgs manageable.

What is the Translation Workbench?

The Translation Workbench is a built-in Salesforce feature that allows administrators and translators to provide translated values for customizations you have made in your org. It does not translate standard Salesforce UI labels — those are handled automatically by each user’s language setting. Instead, it focuses on the custom metadata that you, as an admin or developer, have created.

What Can the Translation Workbench Translate?

Here is a breakdown of the types of metadata you can translate using the Translation Workbench:

What the Translation Workbench Does NOT Translate

It is important to understand the boundaries. The Translation Workbench does not handle:

• Standard Salesforce labels — these are translated automatically based on the user’s language preference (e.g., the “Accounts” tab becomes “Comptes” in French automatically)
• Record data — the actual data stored in records (like an Account Name or a Contact’s address) is not translated; it stays as entered
• Apex error messages written as hardcoded strings — if you hardcode English text in an Apex class, Translation Workbench will not touch it (use Custom Labels instead)
• Third-party managed package labels — translations for these are managed by the package provider
• Standard picklist values on standard fields — some of these have built-in translations; for others, you may need to rely on Custom Labels

How Translation Workbench Fits Into the Bigger Picture

When a user logs into Salesforce and their language is set to, say, French, here is what happens:

1. Standard UI labels — Salesforce automatically renders them in French (menus, buttons, standard field labels)
2. Custom metadata — Salesforce checks the Translation Workbench for French translations of custom field labels, picklist values, validation messages, etc.
3. Custom Labels — If your code references Custom Labels, Salesforce returns the French version if one exists
4. Record data — Stays as-is, in whatever language it was entered

This means Translation Workbench fills the gap between the automatic standard translations and your org-specific customizations.

Note: The Translation Workbench is available in Enterprise, Performance, Unlimited, and Developer editions. It is not available in Professional or Essentials editions.

How to Use the Translation Workbench (Step-by-Step)

Setting up and using the Translation Workbench involves several stages: enabling it, adding supported languages, assigning translators, entering translations, and verifying them. Let us walk through each step.

Step 1: Enable the Translation Workbench

The Translation Workbench is not enabled by default. You need to turn it on first.

1. Go to Setup
2. In the Quick Find box, type Translation Workbench and select Translation Settings (or navigate to Setup > User Interface > Translation Workbench)
3. Click Enable
4. Read the confirmation message and click Enable again

Important: Once you enable the Translation Workbench, you cannot disable it. This is a one-way switch. Make sure your org genuinely needs translations before enabling it, because the setting is permanent.

Step 2: Add Supported Languages

After enabling the workbench, you need to tell Salesforce which languages your org will support for translations.

1. Go to Setup > Translation Workbench > Translation Settings
2. You will see a list of all available languages with checkboxes
3. Check the box next to each language you want to add (e.g., French, Spanish, German, Japanese)
4. Click Save

Here are some commonly added languages and their Salesforce language codes:

Note: Adding a language here does not automatically translate anything. It simply makes that language available as a target for translations. You still need to provide the actual translated text.

Step 3: Assign Translators

Salesforce lets you designate specific users as translators for specific languages. This is optional but recommended for orgs with dedicated translation teams.

1. Go to Setup > Translation Workbench > Translators
2. Click New
3. Select a User from the lookup
4. Select the Language they will translate into
5. Choose the Notification Setting — whether the translator receives email notifications when new items need translation
6. Click Save

You can assign multiple translators to the same language, and the same user can be a translator for multiple languages.

Note: Translators need the “Manage Translation” permission to access the Translation Workbench. You can assign this through a permission set or directly on their profile.

Step 4: Enter Translations Using the Translate Interface

Now comes the main work — actually entering translations. Salesforce provides a grid-based interface that makes this straightforward.

1. Go to Setup > Translation Workbench > Translate
2. Use the filters at the top to narrow down what you want to translate:
   • Language — Select the target language (e.g., French)
   • Setup Component — Select the type of metadata (e.g., Custom Field, Picklist Value, Custom Tab, etc.)
   • Object — Select the specific object (e.g., Account, a custom object)
   • Aspect — Select the specific aspect to translate (e.g., Field Label, Help Text, Description)
3. Click Filter to load the translatable items
4. You will see a grid with columns for the original English value and the translation
5. Enter the translated text in the translation column for each row
6. Click Save

Here is an example of what the grid looks like when translating custom field labels on the Account object into French:

Step 5: Enter Translations for Picklist Values

Picklist values are one of the most common items that need translation, because end users see these values constantly in dropdown menus, reports, and list views.

1. Go to Setup > Translation Workbench > Translate
2. Set Language to the target language
3. Set Setup Component to Picklist Value
4. Select the Object and the specific Picklist Field
5. The grid will show all picklist values for that field
6. Enter translations for each value
7. Click Save

Example — translating the “Industry” picklist values into Spanish:

Note: When you translate picklist values, the translated text appears in the UI for users who have that language set. However, the underlying stored value and the API name remain unchanged. This means your reports, formulas, and Apex code continue to reference the original English values — only the display changes.

Step 6: Translate Validation Rule Error Messages

Validation rule error messages are often overlooked in translation projects, but they are critical for user experience. If a French-speaking user triggers a validation rule and sees an English error message, it defeats the purpose of a multilingual org.

1. Go to Setup > Translation Workbench > Translate
2. Set Setup Component to Validation Rule Error Message (listed under the relevant object)
3. Enter the translated error messages
4. Click Save

Step 7: Export and Import Translations (Bulk Method)

For large orgs with hundreds or thousands of translatable items, entering translations one by one through the UI is impractical. Salesforce supports bulk translation via export and import.

Exporting Translations

1. Go to Setup > Translation Workbench > Export
2. Select the Source Language (usually English)
3. Select the Target Language (the language you want to generate a translation file for)
4. Select the Setup Components you want to include (you can select multiple)
5. Optionally filter by a specific object
6. Click Export
7. Salesforce generates a .stf (Salesforce Translation File) or a bilingual file you can download
8. The file is an XML-based or tab-delimited file that contains the source text and a column for the translation

Working with the Export File

The exported file typically has these columns:

You can open this file in a text editor or spreadsheet application, fill in the Translation column, and save it.

Importing Translations

1. Go to Setup > Translation Workbench > Import
2. Click Choose File and select your completed translation file
3. Select the Target Language
4. Click Import
5. Salesforce processes the file and applies the translations

Note: The import process will overwrite any existing translations for the items in the file. If you only want to add new translations without overwriting existing ones, make sure your file only contains the new items.

Step 8: Override Translations for Packages

If you have installed managed packages that include their own translations, you may want to override some of those translations to match your org’s terminology.

1. Go to Setup > Translation Workbench > Override
2. Select the Package from the dropdown
3. Select the Language
4. Select the Setup Component
5. Enter your override translations
6. Click Save

This is useful when a managed package uses a term that does not align with how your organization refers to the same concept. Your overrides take precedence over the package’s default translations.

Translation Workbench Best Practices

Here are the key best practices to keep your translation process smooth and sustainable:

1. Plan Before You Translate

Before diving into the Translation Workbench, create a translation inventory:

• List all custom objects, fields, picklist values, validation rules, buttons, and tabs in your org
• Prioritize by user impact — translate the items that the most users interact with first
• Identify which languages you need and assign owners for each language

2. Use Custom Labels for Code-Level Strings

If your org has Apex classes, Visualforce pages, or Lightning Web Components that display text to users, always use Custom Labels instead of hardcoded strings. Custom Labels integrate with the Translation Workbench, which means your code-level strings can be translated just like field labels and picklist values.

// Bad — hardcoded string, cannot be translated
String msg = 'Record saved successfully.';

// Good — Custom Label, translatable via Translation Workbench
String msg = System.Label.Record_Saved_Successfully;

3. Establish a Translation Workflow

For large orgs, establish a formal workflow:

1. Admin or developer creates or modifies a custom field, picklist value, or label
2. Admin exports the new or changed items from the Translation Workbench
3. Translator(s) receive the export file, provide translations, and return the completed file
4. Admin imports the translations back into Salesforce
5. QA tester (ideally a native speaker) verifies the translations in context by switching their language setting

4. Test Translations in Context

Translations can look correct in a spreadsheet but appear awkward in the actual UI. Always test by:

• Switching your personal language setting to the target language (Setup > My Personal Information > Language)
• Navigating through the application and checking field labels, picklist values, error messages, and page layout sections
• Running reports to confirm that picklist translations render correctly in report filters and results

5. Be Mindful of Character Length

Some languages require significantly more characters than English to express the same concept. German and French translations are often 20-30% longer than their English equivalents. This can cause:

• Truncated labels in list views and related lists
• Layout issues on page layouts where field labels are cut off
• Button label overflow on custom buttons

Plan for this by keeping your original English labels concise and testing that translations fit within the available UI space.

6. Document Your Translation Glossary

Maintain a glossary of key terms and their approved translations in each language. This ensures consistency across the org and prevents different translators from translating the same term in different ways.

7. Keep Translations Updated

Translations are not a one-time task. Every time you add a new custom field, picklist value, record type, or validation rule, you need to update your translations. Build translation updates into your change management process so that new metadata always gets translated before it is released to users.

What Are Experience Cloud Site Translations?

While the Translation Workbench handles translations inside the Salesforce CRM (the internal app your employees use), Experience Cloud Site Translations handle the external-facing sites and portals you build with Experience Cloud.

Experience Cloud sites are often used by customers, partners, and other external users who may speak different languages. Translating these sites involves a different set of tools and a different approach compared to the Translation Workbench.

The Two Layers of Experience Cloud Translation

When translating an Experience Cloud site, you are working with two distinct layers:

Both layers need to be translated for a fully multilingual Experience Cloud site. The Translation Workbench handles the first layer, and the Experience Cloud translation tools handle the second.

What Experience Cloud Site Translations Can Translate

Here is what falls under the Experience Cloud site translation umbrella:

How Experience Cloud Language Support Works

Experience Cloud supports multilingual sites through a language switcher. When you enable multiple languages on a site, users can switch between them using a language picker component, or the site can auto-detect the user’s browser language and serve the appropriate version.

The basic flow works like this:

1. You build your site in a default language (usually English)
2. You add additional languages to the site configuration
3. You export a translation file that contains all translatable strings from the site
4. Translators fill in the translations
5. You import the completed file back into the site
6. Users see the site in their preferred language

Note: Experience Cloud site translations are separate from Translation Workbench translations. You need both if your site displays CRM metadata (like custom field labels) AND site-specific content (like page titles and navigation labels).

How to Set Up Experience Cloud Site Translations

Let us walk through the complete process of making an Experience Cloud site multilingual.

Step 1: Ensure Translation Workbench Is Enabled

Before you can translate an Experience Cloud site, the Translation Workbench must be enabled in your org (even if you are only translating site content and not CRM metadata). The Experience Cloud translation system depends on the Translation Workbench infrastructure.

If you have not already done so, follow the steps in the Translation Workbench section above to enable it.

Step 2: Add Languages to Your Experience Cloud Site

1. Open your Experience Cloud site in Experience Builder (go to Setup > Digital Experiences > All Sites and click Builder next to your site)
2. In the Experience Builder, click the Settings gear icon (top left or in the sidebar)
3. Navigate to Languages
4. You will see the Default Language for your site — this is the language you built the site in
5. Click Add Language to add additional languages
6. Select the languages you want to support from the dropdown
7. Click Add

You can add as many languages as your org supports. Each language you add here will need its own set of translations.

Step 3: Add the Language Selector Component

For users to switch languages on the site, you need to add a Language Selector component.

1. In Experience Builder, navigate to the page where you want the language picker (usually the header or navigation area)
2. Open the Components panel (lightning bolt icon)
3. Search for Language Selector (sometimes called “Language Picker”)
4. Drag and drop it onto your page — typically in the header region so it appears on every page
5. Configure the component’s display options (dropdown style, flag icons, language name format, etc.)
6. Click Publish or save your changes

Note: If you do not add the Language Selector component, users can still see the site in their preferred language if it matches one of the active languages — the site auto-detects the browser language. But adding the selector gives users explicit control.

Step 4: Export the Translation File

Now you need to export all translatable strings from your site so they can be translated.

1. In Experience Builder, go to Settings > Languages
2. You will see each active language listed with an Export option
3. Click Export next to the language you want to translate
4. Salesforce generates a .xlf (XLIFF) file — this is an industry-standard XML-based translation file format
5. Download the file

The XLIFF file contains entries like this (simplified):

Source: "Welcome to Our Support Portal"
Target: "" (empty — this is where the translation goes)

Source: "Submit a Case"
Target: ""

Source: "Search Knowledge Articles"
Target: ""

Each entry has a source string (your default language text) and a target string (where the translated text goes).

Step 5: Translate the XLIFF File

The .xlf file can be translated using:

• A professional translation tool — such as SDL Trados, MemoQ, Smartling, or Lokalise, all of which natively support the XLIFF format
• A spreadsheet — you can open the XLIFF file in a text editor, copy the source strings into a spreadsheet, have translators fill in the target column, and then paste the translations back into the XLIFF file
• Manual editing — open the file in a text or XML editor and fill in the <target> elements directly
• AI translation tools — for a quick first pass, machine translation can provide a starting point that human translators then review and refine

Regardless of the method you choose, have a native speaker review the translations before importing them back into Salesforce. Machine translations and non-native speakers often miss nuances, especially for industry-specific or branded terminology.

Step 6: Import the Translated File

Once your XLIFF file is complete:

1. Go back to Experience Builder > Settings > Languages
2. Click Import next to the language you are uploading translations for
3. Select your translated .xlf file
4. Click Import
5. Salesforce processes the file and applies the translations to your site

You will see a confirmation message indicating how many strings were imported. If there are errors (malformed XML, missing entries), Salesforce will show an error report.

Step 7: Translate CMS Content

If your Experience Cloud site uses Salesforce CMS (Content Management System) for articles, banners, or other managed content, those items need to be translated separately.

1. Go to Setup > Digital Experiences > All Sites and click Workspaces next to your site
2. In the Experience Workspace, navigate to CMS (or go directly to Salesforce CMS from the App Launcher)
3. Open the content item you want to translate (e.g., an article or a banner)
4. Look for the Language dropdown or the Translations tab
5. Select the target language
6. Enter or paste the translated version of the content
7. Publish the translated content

Each CMS content item can have multiple language variants. When a user views the site in a specific language, Salesforce serves the corresponding language variant of each CMS content item.

Step 8: Test Your Multilingual Site

Testing is essential. Here is a systematic approach:

1. Preview in Experience Builder — Use the language switcher in the builder’s preview mode to check each language
2. Test as different user types — Log in as a customer user, a partner user, and a guest user in each language to verify translations appear correctly for all audiences
3. Check every page — Navigate through all site pages, not just the home page; translations can be missing on less-visited pages
4. Verify dynamic content — Make sure CRM data (custom field labels, picklist values) appears translated alongside the site content translations
5. Test the language picker — Confirm that switching languages preserves the user’s current page and context
6. Test login and registration — Check that login, registration, and password reset pages display correctly in each language
7. Check email notifications — If your site sends email notifications (case comments, password resets), verify these are in the correct language

Step 9: Publish Your Changes

After verifying everything looks good:

1. In Experience Builder, click Publish
2. Confirm the publish action
3. Your multilingual site is now live

Note: Every time you update site content, add new components, or modify page layouts, you may need to re-export and re-import translations for the new or changed strings.

Experience Cloud Translation Best Practices

1. Start with a Complete Site Before Translating

Build your site fully in the default language first — all pages, components, navigation, and CMS content. Then export and translate. If you translate a half-built site, you will need to re-export and translate again every time you add something new, which doubles the work.

2. Use a Translation Management Platform

For orgs with more than two or three languages, a translation management platform (TMP) like Smartling, Transifex, or Lokalise can streamline the process. These tools:

• Accept XLIFF files natively
• Provide translation memory (so repeated phrases are translated consistently)
• Support machine translation with human review workflows
• Track translation progress across languages
• Notify translators when new strings are added

3. Handle Right-to-Left (RTL) Languages Carefully

If you support languages like Arabic or Hebrew, your site layout needs to accommodate right-to-left text direction. Experience Cloud handles some of this automatically, but you should:

• Test navigation menus, forms, and component layouts in RTL mode
• Check that images and icons still make sense in a mirrored layout
• Verify that number formatting and date formatting are correct for RTL locales

4. Plan for Language-Specific URL Paths

Experience Cloud does not create separate URL paths for each language by default (e.g., /en/home vs /fr/home). The language is typically handled via a parameter or cookie. If SEO is important for your multilingual site, consider:

• Adding hreflang tags to your pages for search engine indexing
• Configuring language-specific page metadata
• Working with your SEO team to ensure multilingual content is properly indexed

5. Keep Translation Files Under Version Control

Treat your .xlf files like code artifacts. Store them in a version control system (Git, etc.) so you can:

• Track changes over time
• Roll back to a previous version if a bad translation is imported
• Compare versions to see what strings were added, removed, or changed
• Collaborate with translators using pull requests or merge requests

6. Automate Where Possible

If your site changes frequently, consider automating the export-translate-import cycle:

• Use the Metadata API or Salesforce CLI to script translation file exports and imports
• Set up a CI/CD pipeline that exports translation files whenever site content changes
• Integrate with translation APIs for automated first-pass translations

Common Pitfalls and How to Avoid Them

Translation Workbench vs. Experience Cloud Translations: Quick Comparison

Putting It All Together: A Complete Multilingual Checklist

If you are setting up a fully multilingual Salesforce org with both internal CRM users and external Experience Cloud site users, here is a comprehensive checklist:

Internal CRM Translations

• Enable the Translation Workbench
• Add all required languages to Translation Settings
• Assign translators for each language
• Translate custom field labels and help text
• Translate custom object labels (singular and plural)
• Translate all picklist values (standard and custom picklists)
• Translate record type names
• Translate page layout section headers
• Translate custom button and link labels
• Translate custom tab and app names
• Translate validation rule error messages
• Translate flow labels and screen text
• Convert hardcoded strings in Apex/LWC to Custom Labels and translate those
• Translate custom report type names and descriptions
• Test translations by switching user language settings
• Establish ongoing translation workflow for new metadata

Experience Cloud Site Translations

• Confirm Translation Workbench is enabled
• Add languages to the Experience Cloud site in Experience Builder
• Add the Language Selector component to the site header
• Export the XLIFF translation file for each language
• Translate all site strings (pages, navigation, components, themes)
• Import completed XLIFF files
• Translate CMS content for each language variant
• Translate login, registration, and password reset page text
• Test the site in each language as different user types
• Verify language picker functionality
• Check email notifications in each language
• Publish the multilingual site
• Set up process for ongoing translation maintenance

Summary

The Translation Workbench and Experience Cloud Site Translations are the two main tools Salesforce gives you for building multilingual orgs. The Translation Workbench handles the internal CRM experience — custom field labels, picklist values, validation messages, and other metadata that your employees interact with daily. Experience Cloud Site Translations handle the external-facing sites and portals — page content, navigation, CMS articles, and the overall site experience for customers and partners.

Getting translations right requires planning, a systematic approach, and ongoing maintenance. Start with a complete inventory of what needs translating, establish a workflow with assigned translators, use Custom Labels in your code, test thoroughly with native speakers, and build translation updates into your release management process. When done well, a multilingual Salesforce org creates a seamless experience for every user, regardless of what language they work in.

Next up — Part 31: Managing Duplicates in Salesforce, where we will cover duplicate rules, matching rules, duplicate jobs, and how to keep your data clean and merge-ready across your entire org. Stay tuned!