Lost in Translation? Make Your Experience Cloud Site Multilingual

It can often be an uphill challenge for admins/consultants to navigate the intricacies of rendering Salesforce multilingual. Transforming your Experience Cloud site into a multilingual entity demands meticulous attention to various facets within Sales Cloud. 

This comprehensive guide addresses key elements, such as metadata translations, to ensure you scrutinize every aspect of translations.

Don’t Underestimate the Project 

It is important for those who work in estimation (project managers, sales engineers, delivery workers) that the project can be difficult to handle. It needs to be estimated properly and correctly worded in the statement of work (if you are a consulting company).

It may seem like there are only two major steps (export the translation and import it back in), but there is far more to it. If your implementation is for Experience Cloud, your typical export and import process is not all click-happy.

For a project with a budget of 3 million USD, we calculated that an extra 150,000 USD would be needed solely for translations. The 150,000 USD additional cost is specifically for Salesforce-related translations and does not include the fees for hiring human translators, which is expensive in itself. 

Considerations and Limitations

Without considering the manual experience of cloud translations, here are some of the important limitations and caveats that I’ve come across:

1. STF Files: Salesforce gives the ability to export in STF format and XLIFF format. There was a known issue with XLIFF format and my export job was constantly failing. At the time, my only option was to export only in STF format. 
2. List view labels are not translatable. Upvote this idea! There are some hacks mentioned to translate a single list view, but if you have multiple, you cannot use this hack.
3. Flow Components: Flow components appear in the STF file export but will fail if you try to import them. Exclude any flow components in the STF file and then import your file. To translate flow components, like rich text, buttons, etc. Then go to Translate in settings, select the language, select your Set up Component as Flow, flow type, and select Flow Component you wish to translate.
4. All or none import: Even a single line of error in the import file leads to the whole file being rejected. The idea is that your import file must be spotless to import it back into Salesforce.
5. Hardcoded text in Lightning Web Components and Visualforce: Developers need as much heads-up as possible to use custom labels for every place where they’d normally hardcode text, like field labels or placeholder text on top of a form that they’d use in their Lightning Web or Aura Components.
6. Deployments: To deploy your translations, be sure to include Language Translations metadata component in your change. This works well alongside other metadata components that contain translations like custom labels, validation rules, custom fields etc. Otherwise, you will have to import your files all over again in every org.

Things That You Need to Prepare For

1. Make sure Translation Workbench is enabled in your Salesforce org. 
2. Add the language that you intend to translate to (you can have multiple languages). 
3. Add the translator. Typically an admin will be doing the export and import. 
4. The export file should be given to the translator to help you with the translation. Some companies will do this for you and export this data in the form of an Excel sheet. Then they can translate and give back the file to the admin to import. 

Errors 

1. If the field label is greater than 40 characters, your import will fail. For example, the French language tends to be long. Imagine that “pet” in English translates to “animal de compagnie” in French.
2. If there are two instances of the same # KEY in the same file or you are trying to upload the same translation for a # KEY that already exists in your org, your import will fail.
3. Although flow-rich text is in the STF export file, the translation workbench does not accept the import. Remove that failure line in your STF, reimport it and manually translate flow-rich here:

CMS Translations

Have you used CMS in your Experience Cloud site? Translating CMS content is another area that needs to be factored into your translations if you have used CMS content across your experience cloud implementation.

As with STF files, translating CMS content is not complex but it is procedural. In all likelihood, it will not be handled by business users. 

Step 1: Create a Channel and Select list of Languages. Select the experience cloud site as your channel.

Select languages and also specify default language. Then review everything on the next screen and click Done.

In the screenshots above, I skipped the part where you add your content administrators, managers etc. That’s because Permissions around content is not the intent of this article

Step 2: Change Content Status from Draft to Ready for Translation

Once you have created your content (irrespective of the type i.e. news, flex, or image), do not publish them yet and leave them in Draft mode. Once you have completed drafting your content, hit the “Ready for Translation” button.

Repeat this step for all of the content that needs to be translated.

Step 3: Export for Translation

Select all the files that are in “Ready for Translation” and click the button “Export for Translation”. Wait for an email and click the link in your email to download a zipped file. Unzip and open it in your favorite text editor. I’d use Notepad++ for Windows and Sublime for Mac.

Step 4: Add your Translations

At this point, hand off the text to your translators and wait for them to give back the translations. Once you have the translations, enter them in the target portion of this XLIFF file. For every source, you will notice that there is a target. Ensure that you have filled in all the translations within the target tags of this file without altering anything else. Save the file once you have all your translations.

Once again, zip the folder that contains your modified file. Remember, you are packing it just the way it came when you exported it for translation.

Step 5: Import your Translations

Once you’ve successfully imported your translations, you will receive a confirmation email. Head over to your content to see your translations in action.

Step 6: Check your Translations

Always check your work! Head over to the content you translated and see if it’s translated as expected.

Step 7: Publish your Content

Go to your individual content and publish it. It can be annoying to do the task individually, but that’s the only option for now. When you have your content translated, you will see it reflected wherever it is used in your Experience Cloud sites.

Important Notes for CMS Translations:

1. Deployment: This is something that cannot be deployed using change sets and would need to be manually done in every org that has CMS content.
2. Multiple Languages: If your workspace has multiple languages (in addition to the default language), the zip file that you get will have more than one file. In my example above, I chose French and Dutch with English as the default. So, when you export your content for translation, you will see two files in your zipped folder. Unzip as you would with a single file, and open both with your editor. Follow the same process as you would with a single file.

Metadata Components and Their Translations

Metadata	Manual or Automated?	Where?	Deployable?
Standard object names & field labels	Manual	Setup > Rename Tabs & Labels	No
Custom field labels, custom labels, custom metadata, picklist values, help text & validation rule messages, action, buttons, links, record type names	Manual/Automated	Manual: Setup > Translate Automated: Set Up > Translate > Export as STF files and then Setup > Translate > Import	Yes
Community Navigation Menu Item	Manual	Setup > Translate > Navigation Menu Item	Maybe using a third party tool
Managed Topics	Manual	Setup > Translate > Managed Topics	Maybe using a third party tool
Flow rich text & button labels (pending Spring ‘22)	Manual	Setup > Translate > Flow	No
Rich text component in community	Manual	Setup > All Sites > Your Experience Cloud Site > Builder > Change community language > Replace English with French text	No
CMS Banners & Text	Automated	Salesforce CMS App > Mark files to translate as “Ready for Export” > Export for Translation button > Add target language translations > Import for Translations button	No
Knowledge Articles	Manual/Automated	Using language to create articles in French or English. Language attribute controls which articles to show depending on logged in user’s language	No

If you are translating, use the above guide to:

1. Estimate properly, as it tells you what’s manual, what’s automated, and what’s deployable.
2. Where to do the translations – some are in Setup, some in CMS app, some in knowledge articles, etc. So, it will help you to have a look around.

More on estimations:

Number of languages: Let’s say we are developing an experience cloud site to work in French and Spanish (default: English), it doesn’t mean estimates will double but they will certainly increase. 

Reasons: importing Spanish and French files, manual steps that need to be performed twice etc. 

Number of custom components: Developers need to know at the outset that any text in aura/LWC components needs to have custom labels. Going back and changing hard-coded text to custom labels is a larger effort.

Number of sandboxes up until prod: Let’s say the sandbox stack is dev > partial > staging > prod. It doesn’t mean that we need to multiply by 4 but all the manual steps (for items that are not deployable) need to be done 4 times. Itemize manual translations and multiply by the number of sandboxes. 

If your stakeholder insists that untranslatable components need to be translated, you need to come up with workarounds which cost them more. Understand the regulatory/compliance requirements and estimate properly.  E.g. custom list views are not translatable. 

If a user changes language via the UI in the experience cloud on their contact record, then change language on their user record and put them in different public groups which will drive the visibility of list views. Trigger/flow on contact needs to be built/refactored which will asynchronously change the language setting on the user record (to avoid mixed DML error) which will remove the user from one public group to another. 

Summary

Estimating and managing multilingual projects can be a real challenge. Considerations and limitations, such as issues with STF and XLIFF formats, untranslatable list view labels, and nuances with flow components, are important to consider going forward. 

This article should provide you with some insight into preparing for translations, addressing errors, and handling CMS translations in Experience Cloud sites.