Use Smart Functionality to Display Translated Forms

[Karena]

There's an option to make a form smart, so you can display a different form based on different rules. We want to use similar functionality to display localized forms - use the same form for all geographies, but display translated labels / dropdown values / help text / etc. based on various criteria (their IP Country, for example). This is not currently supported, but we would definitely use it! 

We have 8 supported languages and right now we use a lot of custom code on our external website. As our team looks to use more of HubSpot's built-in tools, this functionality would be really helpful. The time required to create/maintain 8 versions of each form, and the resulting complexity of all our landing pages, is a huge limitation.

[MFrankJohnson · Accepted solution]

Help other HubSpot searchers find this post quickly by accepting this solution today.

Excellent suggestions. You may wish to add to a new or existing thread in HubSpot Ideas.

You'll typically get much more traction from the HubSpot Community AND the Ideas Forum is where HubSpot Product Teams monitor suggestions for popularity -- i.e., VOTES! 🙂

That being said, multi-language content delivery and corresponding backend functionality is a HUGE challenge across many platforms. HubSpot is no exception.

Easily use smart rules to auto-display language-specific cotnent based on referring country.

see 2-Language Example LP (based on referring country)

The real challenge begins when we attempt to process data captured in multiple languages. It's a nice idea to expect HubSpot (or any SaaS platform) to allow smart rules within forms, but what would that even look like when adding to the CRM?

- Would we expect HubSpot to smart-swap custom properties based on language?

-- And if so, wouldn't that mean we'd have to pre-build those custom multi-language properties ahead of time anyway (just like we do now)?

- Would it also mean multiple, language-specific HubSpot properties -- e.g., Lead Status, Lifecycle Stage, etc.? (a serious headache)

-- And if so, what would that look like on the backend? (multiple languages?)

Point?

Seems like a HUGE amount of work to satisfy what we're guessing is a relatively tiny segment of HubSpot Users who have extensive multi-language needs which can't be met by existing HubSpot smart rule functionality and language-specific customizations.

2 languages = 2 forms = 2 sets of language-specific custom properties.

N-languages = n-forms = n-sets of language-specific custom properties.

Happy to help you build ...

Best,
Frank

---

www.MFrankJohnson.com

[Karena]

Thanks for taking the time to respond. I thought this was the Ideas forum but apparently not. Second post, hopefully on the Ideas Forum this time.

I'm not technical so I have no idea what it'd look like on the back end. Whether it would affect a large or small segment of HubSpot users is exactly why I created the post; to let the votes do the talking. If it's a tiny segment or just a plain old bad idea, it won't get votes and HubSpot is fully justified in ignoring the suggestion! 

That being said, we have 55 custom properties (not including those not used in forms), about 60 global forms (not including those only used on language-specific landing pages), and 8 languages. Obviously this would be a huge value-add for us, especially if we needed to swap out one field across all our forms. 

N-languages x M-forms = NxM forms to update if one field changes

[MFrankJohnson]

>>"N-languages x M-forms = NxM forms to update if one field changes"

Ok, precisely not.

What you're failing to take into consideration is that a given field in the CRM (e.g., email address or location) in a given language is reused on all HubSpot forms for that language. That's how databases work (HubSpot included).

Example #1:

-a- You have a field called Email Address on all 200 of your forms in English.

-b- You need that field to now say Work Email Address instead.

-c- You don't change 200 forms. You update the Email Address field in the CRM to be called Work Email Address. That single field change updates all forms that use that field -- i.e., your original 200 forms!

Example #2:

-a- You have 10 forms in Spanish that include a field called 'Localidad' with only two dropdown choices -- España and Peru.

-b- You start using a 3rd location (Chile) for your Spanish speaking clientle.

-c- You don't change 10 forms. You add Chile to the one (1) field called 'Localidad' as an additional dropdown choice. That single field change updates all forms that use that field -- i.e., your original 10 Spanish forms!

See how that works?

Original formula stands ... (version added for clarity)

2 languages = 2 (versions of) a form = 2 sets of language-specific custom properties.

N-languages = n (versions of) a form = n-sets of language-specific custom properties.

Good luck with your idea. Hope you get lots of votes.

 #nlmtt #nlmtu

[Karena]

Thanks for your extensive explanation. We've actually updated our form fields using both of your examples before, and you're right - they definitely save time!

Sorry for not being clear earlier - what I was trying to reference is the case where we might want to swap out an entire field for another. Say, for example, that our marketing strategy shifts and we'd like to replace "What's your biggest business challenge?" with "What version of [our product] are you using, if any?"

In this case, it wouldn't make sense to just change the name of the field, because they would be holding answers to different questions, and they're different field types (text vs. dropdown). So we'd need to go into each form that uses the "business challenge" question -- x8 if we have each form in each of our supported languages -- and remove the "business challenge" field and insert the "product version" field. 

When we're trying to take into account both marketing's segmentation needs as well as sales's feedback on what makes it easier to follow up, the fields we're using can be in flux quite a bit. Hope that helps you understand our use case a bit more. 

[MFrankJohnson]

Better understood. Thanks. This is excellent information. You'll want to definitely include it in your Idea wubmission. Use case examples help everyone understand the 'why' instead of just the 'how' and often encourage others to follow your example by citing their own sometimes very different but very applicable use cases.

Again, thanks for that clarity and good luck with your votes.