0

For example - I have a screen flow that shows a confirmation message like this:

The opportunity has been converted successfully:
{!Opportunity.Name}

The opportunity name also has a link to the actual opportunity:

/{!Opportunity.Id}

This works nicely (as long as I'm not in the console), however, I want to translate my text for users in a different language.

Now we could use a custom label for the text instead:

{!$Label.OpportunityConversionMessage}
{!Opportunity.Name}

But this has its own share of problems as it only works nicely when the variable is separate from the text (the custom label).

I could also translate it directly via the workbench - but then I have to translate the whole markup as well, e.g.:

<p><span style="background-color: rgb(255, 255, 255); color: rgb(68, 68, 68);">The opportunity has been converted successfully:</span></p><p><a href="/{!Opportunity.Id}" rel="noopener noreferrer" target="_blank">{!Opportunity.Name}</a></p>

Now this is the most flexible approach, doesn't use a custom label for a text that is only ever displayed here, and it can directly be translated in the workbench - variables work as well. But - I have to deal with all the markup, completely defeating the purpose of having the formatting in the flow.

How are you guys dealing with this? Is there any good and obvious solution without any downsides that I'm missing?

7
  • 1
    The latter is how you should be doing this. I do not understand your comment that this defeats the purpose. Not all language translations want the same structure for the translation compared with that in English. It is how it is and you work with it.
    – Phil W
    Aug 8, 2023 at 6:06
  • I agree with the structure part. But then there's also markup (and layout e.g. colors) thrown into the mix. If exported and used with external translators, they might screw up the markup - which is super bad.
    – Semmel
    Aug 8, 2023 at 16:44
  • Try stripping out the markup to see how that impacts the UI. If you don't really notice, just remove it from all languages, including the org default.
    – Phil W
    Aug 8, 2023 at 18:31
  • Stripping out the markup? How? If I put some text on a screen it's always - at the very least - wrapped in a paragraph, isn't it?
    – Semmel
    Aug 9, 2023 at 3:12
  • Do you not pull the flow (and other) metadata down to an sfdx project for storage in a version control system? If you do you can trivially edit the XML to remove the encoded markup before pushing back to the org.
    – Phil W
    Aug 9, 2023 at 6:02

1 Answer 1

0

So - this really comes down to which kind of downsides you're cool with as you basically have only two options.

  1. Use a custom label and translate it via the workbench.
  2. Text directly on the screens can also be translated via the workbench.

Option 1 is the one we're all used to. It's easy and straightforward even though it requires additional steps and text that is likely used only once stripped out of the flow. It's a good solution if you want to use the text in multiple locations.

Option 2 is the "native" solution. It can be used for screen components (like text) but not for something like variables that are just text. It also includes all the markup in the translation as display text basically is just a very simple rich text field.

The latter isn't perfect by any means but as one commentator pointed out - it's the way to do things in Salesforce natively (fully available since Winter '22). Though you have to be careful as potential outside translators can screw up the markup.

Side note: If you're building Lightning components you might be better of with something like Localize.

2
  • 1
    BTW, using labels does mean you cannot include markup at all, even if you want to. At least in some scenarios (if not all) and if you need to pass a security review.
    – Phil W
    Aug 11, 2023 at 6:28
  • Absolutely. Good, you pointed that out!
    – Semmel
    Aug 11, 2023 at 12:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .