translate rich text component

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?

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?

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 {{{$Model.Animal__c.data.0.type__c}}} runs quickly” Becomes: {{{$Model.TextString__c.data.0.TextString1__c}}}{{{$Model.Animal__c.data.0.type__c}}}{{{$Model.TextString__c.data.0.TextString2__c}}}}

Why wouldn’t custom labels work?

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 - https://cloud.google.com/translate/docs/) 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’?

OK, I think the custom labels might work. But to clarify, would I still need to do something like what Raymond suggested?

{{$Label.Text1}}{{SomeotherMergeField}}{{$Label.Text2}}?

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.

Thoughts?

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!

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.

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 …

Thanks
Karen

Thanks, Karen. We haven’t actually pursued the solution for this one yet. I’ll try to remember to keep the community updated.