translate rich text component

Matt SonesMatt Sones 💎💎💎
edited October 15, 2019 in Questions
I need to translate the contents of certain rich text components into other languages. Any initial ideas on ways to tackle that?


  • edited October 15, 2019
    Could you use merge fields in the rich text and store the actual values in a Salesforce object so you can use Salesforce's translation?
  • Matt SonesMatt Sones 💎💎💎
    edited February 10, 2017
    Hmm. Interesting idea!

    One of the challenges is that I'm already using a bunch of merge fields in the rich text itself, and skuid doesn't like to process merges within merges...

    I'll have to noodle on that.

    Any other ideas in the mean time, friends?
  • edited October 15, 2019
    I'll beat this dead horse until Barry responds with the perfect answer..... How about many Salesforce fields storing the text strings that occur between your existing merge fields. Example: "In the meadow, the {{{$}}} runs quickly" Becomes: {{{$}}}{{{$}}}{{{$}}}}
  • J.J. 💎
    edited March 7, 2017
    Why wouldn't custom labels work?
  • Barry SchnellBarry Schnell 💎💎
    edited February 25, 2017
    Hey Matt -

    If the text you need to display is static then I'm with J and would use custom labels, seems perfect for this situation (assuming the language to display the text in can be based on SFDC profile language choice).  

    Now, with that said, if the text is dynamic and/or comes from user input, then things get more complicated.  If custom labels don't work, could you provide some more details behind your use case?  I've got a couple of ideas (e.g. Google Translate API - but understanding more of the specifics would be helpful.  For example, if User 1 in Language 'A' input something would User 2 in Language 'B' need to view that input in Language 'B'?
  • Matt SonesMatt Sones 💎💎💎
    edited March 2, 2017
    OK, I think the custom labels might work. But to clarify, would I still need to do something like what Raymond suggested?


    Or can my labels themselves include merge fields?

    If I have to do it the first way, I'd rather look into google translate or some such, because of the number of merge fields and conditional merges that we need in larger rich text components.

    Use Case:
    Our app is delivered with stock 'consent' forms that our customers use with their patients. We put the text of the consent forms in rich text compontents so that if the customer needs to make tweeks to the text, it's not to difficult.
    We also have a 'defaults' object, where the customer inputs some standard fields like Name, phone numbers, web addresses. the defaults object also stores some 'customization' fields like a 'We Treat for STDs' checkbox, etc. We use the fields from the defaults to quasi-dynamically change the consent forms. Basically, the customer just has to input their default values and the consent forms are changed appropriately.

    We also have some forms that change based on user inputs., particularly the "Print" versions of our forms, which integrate data from patient encounters into the forms via merge syntax. However, the data itself is mainly used for conditional merging, and even when it's text, it wouldn't have to be translated for a user in a different language.

    TL;DR (I actually have no idea what that stands for):
    We use a lot of merge syntax within our large rich text components, but only the text stored in the actual rich text component would need to be translated, not the data behind the merges.

  • Barry SchnellBarry Schnell 💎💎
    edited November 18, 2016
    Hey Matt -

    Here's my thoughts:

    1) Custom Labels should technically work and outside of having lots of conditional merging to accomplish, wouldn't be too difficult to implement.  The challenge you'll have here is when a user wants to change the "default" text as they would have to edit the custom label, not the data in your custom defaults object.  With that said, you could leverage the metadata api to create/update a label and provide an intermediate step (e.g. via an after trigger possibly) to update the label when the default record itself is updated.

    2)  Another option would be to create a DefaultLanguage object that is a master/detail to Defaults object.  Then, in your admin interface, provide the ability for the admin to specify default text and translated versions of that text.  Then, in your page, you would load the appropriate record for the language of the user.

    3) Google Translate - You could use this two different ways.  When a default is changed, you could make an apex callout to translate the text and then store the value.  Or, you could do this all client side making the calls as necessary.  The challenge with client side is that when it comes to server side processing like document merging (e.g. conga, etc.) you wouldn't get the translation.  The server side apex callout to google for translation would avoid the user having to translate the text themselves, however often times, it's better to have a human translate than google especially when the language is legal in nature (you want to be 100% accurate in the translation).

    If I'm understanding your requirements correctly, I'd probably lean towards #2 for full flexibility or #1 if you are familiar with metadata api, etc.

    Hope that helps!
  • Matt SonesMatt Sones 💎💎💎
    edited December 7, 2016
    That helps! I think I'll pursue something like #2. Providing a skuidified interface for 'admins' to edit their own consent forms and the translations is perfect.
  • Karen WaldschmittKaren Waldschmitt 🛠️ 
    edited December 21, 2016
    Hi Matt~

    Wanted to circle back and see if #2 worked out for you or not. 

    Also, per urban dictionary (and who wouldn't trust THAT?!), TL;DR = too long; didn't read ...

  • Matt SonesMatt Sones 💎💎💎
    edited December 7, 2016
    Thanks, Karen. We haven't actually pursued the solution for this one yet. I'll try to remember to keep the community updated.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!