Connectors Support for Multi-Language Profiles (March '22 Release)

Now you can use Connectors to easily ingest Multi-Language data and store it in corresponding Language Profiles. The updated Connectors workflow now allows users to specify the language of the Primary Profile and create and edit Alternate Language Profiles for Connectors from any source.

To specify the Language of your profile, you should add a column to your Connector that contains the locale code (e.g. “en”, “en_US”, “es”, etc.). This will designate the primary language for the entity, so any new entities created will be created with this language as their primary language profile.

Depending on where you are pulling your data in from, or where the data is stored - this data may come from your source data (e.g., a crawled website, an API response, etc.) or you may add it via a transform, like an “Add Column” transform.

Once you have a column that contains the locale for each profile, you can map that column to the new “Locale Code” field in the mapping step.

If you are adding or editing Alternate Language Profiles (either by itself or in addition to Primary Profiles), you must also include a column to indicate whether or not the row in the Connector corresponds to an alternate language profile.

To do this, you will need to have another column of data with “true” or “false” values that will designate whether the corresponding language is the alternate language or not.

You will then map this column to the new “Is Alternate Profile” field, so you should use the value “true” for any rows that contain an alternate language profile and the value “false” for any rows that contain a primary profile.

In the example below, the en_US is the Alternate Language profile for the entities. Meaning, an additional language profile will be created for that entity or the data on the additional en_US language profile will be updated.

This step is only needed for entities with multiple language profiles. If your Connector is only interacting with Primary Language Profiles, you can omit the “Is Alternate Profile” field and we will assume by default that the row contains a primary profile.

Note that for a given entity, you can only mark one row as “false” for “Is Alternate Profile” because each entity can only have one primary profile. Also, note that you cannot include Primary Only fields when adding or editing alternate language profiles.

To learn more about Connectors, visit the Data Connectors module. Or, to learn more about Multi Language Profiles, visit the Multi-Language Profiles in the Knowledge Graph module.


Hi, this new multi-language field functionality is going to be so helpful for me!
What are best practices for building a Connector that will include content for both the primary and alternate language profiles?

For example, if my primary profile language is en_US and the Connector I’m building has content in en_US, en_UK, and es_MX? I think I would need the values “true” and “false” in the Is Alternate column and I’m wondering if this is possible.


1 Like

Hi Adrienne,

Great question! Yes, the end goal here is to specify for each row, whether it’s the primary profile or an alternate profile. If the row is a primary profile, then you’ll want to map “false” to the “IsAlternateProfile” field. If the row should create an alternate profile, then you’ll want to map “IsAlternateProfile” to “true.” You can use a variety of transforms to create a column that designates true/false based on the intended behavior. One such example is using a “Find and Replace” transform, where all values that are “Spanish” are “true” and all that are “English” are false (therefore setting rows in Spanish to an alternate language profile and english rows to the primary profile). The transform you choose may depend on what data is pulled in and how it is formatted, but essentially, you just need to find a way to distinguish whether a row is or is not an alternate profile!

Hope this helps!

Hi Rachel!

This feature is really helpful but I noticed that it doesn’t work when we have different URLs based on the locale. I had a few times a scenario where the URL changes completely based on the language and I was wondering if there is a workaround at the current stage or if I am missing something!



We have translated versions of content with the language code “zh-hans”, but that value is throwing a validation error in the Connector. Clearly it’s a valid code, but it probably isn’t in the format that the Knowledge Graph wants. Where are the values that the Knowledge Graph will accept documented?

Would you able to try “zh_Hans” (capitalize the “H” and change the dash to an underscore)? We are working on getting a complete list of our language codes documented, but in the meantime, let me know if this solves your issue.


Hi Fede,

I assume you mean that you are having trouble creating one entity with two profile languages in the same connector since your URL is different. If my understanding is correct, then to resolve this, you will still need some way of creating a shared entity ID that both the profiles can reference (so KG knows to create 1 entity with two profiles!). If the URLs/Page IDs are different, I recommend finding a different way to link the two profiles via a shared entity ID.

If I have misunderstood your question, please let me know.


That does seem to work, thanks. Generally, it seems that Yext should be documenting the expectations of all of those data validators. This is the second time I’ve seen validation failures and found myself stymied because I had no idea what value was expected.

A follow-up question. Normally I expect that you would have an entity in the primary profile, at least, and one of more corresponding entities in the alternate profile(s). That’s certainly the case in our world most of the time; we create a piece of content in English, then translate it.

What happens, though, if there is an entity in one of the alternate profiles (i.e., languages) but there is no corresponding entity in the primary profile? Say, for example, we do a video specifically for our China audience but not our English speaking audience?

Great to hear that worked. Improving our documentation is a top priority and we greatly appreciate the feedback!

In the case that you have a video that is only for your China Audience, the primary profile would just be Chinese for that entity. Profiles (primary and alternate) are set at the individual entity level, and each entity must have a primary profile. So, even if most of your entities have english as the primary profile (with Chinese as the alternate), you can also have some entities where they only have one profile, that being Chinese, which would then be the primary profile on that entity.

Hope this helps!

OK, that’s enlightening. I had assumed that this was something set in the Type, not in each Entity of a Type. I’m going to have to think about the ramifications of that. Presumably, then, the alternate profiles are created when the connector is run if there is already an entity with the same Entity ID. Is that correct?

In my data connector, though, I’m setting the locale and “is alternate profile” values based on the JSON returned from the API Pull. There, I have transforms that populate the “is alternate profile” on the basis of language, assuming that every “en” object is no an alternate, and that all others are. In the event that is incorrect because the “en” object corresponding to the non-en object doesn’t exist (in which case at least one of the non-en objects is the primary), what will happen? Will the entity be created? Will it be tagged as the primary?

I suppose the larger question is what are the best practices for populating entities when you have multiple languages? Haven’t seen a lot of discussion around that here.

With respect to @Federica_Carrus’s question, assuming she’s referring to the Landing Page URL (or something similar, but in either case the path to the entity on their web site) wouldn’t that be a non-issue if the field was overridable? In that case each profile of the same Entity could have a distinct value, yes?

Yes that’s correct! I thought she was saying the issue was that because they were NOT the same, and she wanted to make the Page ID the entity ID, she was unable to link the two profiles to a single entity.

If I misunderstood, then you are correct in that having different URL values for an overridable field would not be a problem.

If you assume that all objects that are not “en” are alternate profiles, and if no primary profile exists, then the entity would not be created and you will see failure diagnostics. You’ll unfortunately need to be able to distinguish which entities have Chinese profiles are primary and correctly designate that in the connector.

Ugh. That’s going to complicate things quite a bit. I see some pretty involved Typescript transform functions needed here. OK, then.

Hey @Rachel_Adler,

Is there a way to create multiple alternate language profiles via a single connector? The use case here is that all content for a specific vertical is only in English, but that content is to be shared across all multi-language answers experiences (there are 6 total locales).

Hi Jason,

For sure! As many alternate profiles can be created as desired, each one just needs correctly have specified the local code as designated via a column in the connector, as well as column to specify “Is Alternate Profile” as “true” on each profile (i.e. each row in the connector that represents an alternate profile).

1 Like

Hi @Rachel_Adler,

The multi-lang feature is super cool. I am wondering if there is a way to set up the Selectors & Column Map Fields through Configuration as Code file, so people don’t need to manually going into the Connector and click through the mappings.

cc: @Ben_Haines


Selectors, transforms, and mappings are all configurable via CaC for Connectors! You can find a CaC file for each Connector Configuration in your Admin Console. Check out this example resource in my personal account!