If you have been following along with all of the Salesforce translation articles I have written, firstly, thank you for coming along the ride. I do want to close it out by tying it all together. It’s sort of like a summary of everything I learned, plus new content, of course.

This should give you everything you need in order to translate your metadata and, in some cases, data like knowledge articles, custom metadata, etc.

If you are translating, use the above guide to:

1. Estimate properly because it tells you what’s manual, what’s automated, and what’s deployable.

2. Where to do the translations. Some are in set-up, some in CMS app, some in knowledge articles, etc. The guide should help you go to these places.

I did talk about estimations, but here’s going into it a bit more:

— 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 for that include 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 custom labels. Going back and changing hard-coded text to custom labels is a larger effort.

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

— Make the client understand limitations. If the client insists that untranslatable components need to be translated, we need to come up with workarounds. That will cost them more. Understand the regulatory/compliance requirements and estimate properly.  For example, custom list views are not translatable. If the user changes language via the UI in experience cloud on their contact record, then change the language on their user record and put them in a different public group 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.

Hope this helps those who are on this journey of making Salesforce translatable! Any suggestions are always welcome.