Support translation of list-based field values in embedded forms

The advanced options for form embed code include translation options; however, there is no option to specify translations for the list-based field values (_i.e._ contact properties of type Multiple Checkboxes, Radio Select, or Dropdown Select). Please add support for list-based field values in the translation options.

HubSpot updates
8 Replies
HubSpot Product Team
HubSpot Product Team
updated to: Needs Detail

Hi @JamiesonC, if possible would you be able to provide some examples of properties you and your team are using that would need this type of translation? Additionally, it would be helpful to understand how you and your team are planning on using the translation extension of forms on your website, this feature is rarely used in Forms today, and we'd love to get a better idea of ways we can add to it, or replace it with easier solutions. Thanks! 

Regular Contributor



Thanks very much for responding. I've sent you a private message with an example (non-production) Spanish landing page that incorporates an English form and attempts to translate everything. This should give you a good idea of how we are using the translation parameters for form embed, as well as the need to translate drop-down options.


Basically, any contact property that defines a list of possible values (dropdown select, multi checkbox, or radio select) are problematic to translate because HubSpot has no mechanism to define the translations for these values.


In deploying our main lead drivers to multiple countries, we have a very specific requirement: we will not split up the form submission data by creating a separate form for each language. Doing so would unnecessarily complicate any list or administrative workflow trigger whose criteria is based on specific form submissions. It would also complicate some manual downstream processing that we have to do as a result of having no API access to form submissions.


So: one form, that must be able to work in multiple languages. This is why we're pushing the limits of the translation options in the form embed code.


Let me know your thoughts. Thanks.

Community Manager
Community Manager
updated to: Idea Submitted
Occasional Contributor

I came upon this post trying to find information on how to do just this. I'm looking to do translated Country and State/Region lists in a single form with selection of the correct display values based on locale. 


It seems like the only way to support it currently is to have multiple Country fields, one for each locale, to show the translated country names. And then I would somehow take the submitted value and insert it into the Contact's Country value? Or I would have to use javascript to replace all the selectable contents of the dropdown with their translated versions, but still submit the value expected by the system.


Since the list of values is set at the field level and not at the individual form level, how does HubSpot recommend translating a Country list?

Regular Contributor



The two approaches you described are the two that I'm aware of.


  1. Having multiple versions of an enumerated contact property, one for each language, and a workflow to combine them into the "main" contact property. This is the approach that one of our sister companies uses. It is also the only solution that HubSpot has been able to recommend to me. I don't consider it sustainable, in terms of maintenance complexity.
  2. Using JavaScript to modify the form after it is created. This is the approach I'm using. But it is a hack and is not supported by HubSpot. As such, it requires internal support to make sure it doesn't break if HubSpot changes anything about their form code.
HubSpot Employee
HubSpot Employee

There is a workaround that we can utilize to achieve this. The solution would be to create a workflow that combines all multi-language property values into one value. Here is an example of what I mean:

  1. Contact fills out form - Contact fills out "Industry: Automotriz"
  2. Contact is enrolled in a workflow where the enrollment trigger is "Industry: Automotriz"
  3. The workflow erases the value for "Industry: Automotriz" and replaces with the value Automotive

The workflow will enable you to translate any values in a different language into your portal language.


You would still have to create properties and values that correspond to the language e.g. Portuguese Industry, Spanish Industry, English Industry.

Occasional Contributor

That's actually exactly what we ended up doing, but it becomes a massive pain when the system starts throttling our workflow performance and it starts taking longer and longer for these values to be updated.


We also end up having to do the reverse when the value is updated from our CRM (Dynamics 365 in our case, shuttling data through Scribe) as we have to take the value that comes into our core syncable property and copy it back out to the language specific properties.


And when we start doing that, we have to come up with ways to keep the updates from triggering an endless loop, which I currently handle via list membership since there isn't a workflow filter that allows me to check the source of a property update (in this case, update via form submission vs update via integration). So when somebody fills out a form, I chuck them into a "just filled a form" list. 

It's all very workflow intensive, which, again, gets us in trouble with the throttling, but it works like this:

1. Create different language specific Country properties (Country - Spanish, Country - Korean, Country - Japanese)
2. Use the core Country field as the English version
3. Each localized form uses the associated localized Country property
4. When contact fills form in English, Country value is set and contact is added to "just filled a form" list
5. Country value is copied to all of the localized Country properties, just to keep everything matching so the same country is auto-filled no matter what language form the contact visits
5. Country value syncs to CRM and kicks off a variety of CRM workflows
6. Updated data syncs back over to HubSpot, possibly triggering a Country update
7. Workflow sees that Country has updated, but checks to see if contact is a member of "just filled a form". If so, workflow bails. If not, it means the change came from somebody on the CRM side and that we should propagate the update to all the language specific Country properties.

It's a heck of a solution, and it's always fun to walk people through all the interrelated workflows, but it is unwieldy.

New Contributor


I'm voting for this idea.
Also, I would like to have an option once property with dropdown options is translated to any language (from English to French for example), next time when I'm using the same property in another form in French and I would like to have options already translated from the previous form.

It's annoying that I need to translate for every language dropdown options for every form.

My Example is

I have a form called "Example One" that is translated from English to French. Doing this has translated all the form labels (Country -> Pays). However, when using the drop-down options that the "Country" property, the country options remain in English and do not translate over to French. I translated Country option in French.
Then I created the second form called "Example Two" which is translated into French. Country field options are in English and I need AGAIN to translate them for every form.


Thank you!