Field Behavior | Yext Hitchhikers Platform

What You’ll Learn

In this section, you will learn:

  • How fields behave on multi-language profiles
  • How to set the language behavior on custom fields
  • How to add custom field option translations

Overview of Field Behavior

As you learned in the last unit, an entity is made up of a collection of language profiles. Each language profile contains a set of fields that have content. One of the most important parts about multi-language profiles is how content is shared between profiles of different languages.

For example, there is some content that is completely independent of language, like hours or a map marker. There is other content that is wholly dependent on language, like a description and all other pure string fields. Other content is somewhere in the middle – you might want to share it between profiles, but you might not, like photos or videos.

So, what if all of your content doesn’t need to be translated? Do you have to set all content on each profile separately?

The short answer is no! The long answer… is the rest of this unit.

Alternate Profile Language Profile

Any content that is on your primary profile is your primary language content. It cannot be inherited from other language profiles. But, alternate language profiles can inherit the content from the primary profile depending on the behavior of the field.

We categorize the behavior of fields between language profiles into 3 types:

  • Primary Only
  • Overridable
  • Language Specific

When you hover over a field on an alternate profile, you’ll see a tool-tip that tells the behavior for that field.

types of fields

Primary Only - Primary only fields can only be updated on the primary profile. There is no way to override it on an alternate profile. This is used for fields like map marker, hours, linked entity custom fields or enum fields like Price Range or Payment Options where the translations are stored on the field itself. By default, custom fields are set to primary only.

Overridable - Overridable fields by default will inherit the content from the primary profile but you can choose to add language specific content if you want. This is used for fields like Name, Photo Gallery, or Videos.

Language Specific - Language Specific fields will never inherit content from the primary profile because the field is inherently specific to each language. This includes any pure string fields, like Description, Keywords, or Featured Message.

For built-in fields, Yext determines the language behavior for all fields. For custom fields, you can set the language behavior for each field. You can do this when you create the field or after you create the field by modifying the “Alternate Language Behavior” property of the field.

set custom field behavior

You can change this for fields after you create them, but keep in mind that doing so could have an impact on the content that is returned for profiles (e.g., if you change a field from primary only to language specific, the content will no longer be available on alternate profiles until you explicitly fill it out).

light bulb
Note
The only custom field type that you cannot set the behavior for is Entity Relationship fields. These must be primary only. This means that any custom field type that contains an Entity Relationship field must also be primary only. This is because when you are linking an Entity, you are linking it on the entity level, not linking on the individual profile level.

Best Practices for Setting Language Behavior on Custom Fields

With custom fields, you have full freedom to set the behavior as you’d like. But with great power comes great responsibility! You should be thoughtful about what you choose and we recommend following some high level guidelines:

  • If it’s text based, it should be language-specific. The exception here would be if it is a proper noun or brand names
  • If it’s an option-type field, it’s usually best to be primary-only, unless the options truly do vary by language (more on that in the next section).
  • If it’s a photo, we recommend overrideable so you can choose to vary the content by language when it makes sense, but you don’t have to
light bulb
Note
If you’re building experiences for a single language but multiple variations (e.g., you have an English US site, English UK site and English CA site) then you might want to make more fields overridable since in most cases the translations will be the same. Field content inheritance is there to help save you time so you don’t have to add content multiple times.

Adding Custom Field Option Translations

When you make custom fields that have options (e.g., the single-option select or multi-option select fields), you can also add translations for those options.

How to Add the Translations

In the field specification property for an option custom field, you will see a link to “+Add translation”. When you click on this link, you can select the language for which you want to add translations, add in the translations and click “Save”. You can add as many translations as you would like. add custom field option translations

How are the Translations Used

It’s important to understand how custom field option translations are used.

  • They will appear for users based on browser language or the display language setting in Account Settings if a translation exists for their browser language. If one doesn’t exist, it will fallback on the primary language.

translation showing on entity edit

  • They will appear when the field option values are used as display content on Pages or Search. For example, if you want to display an option field in a subtitle of a card, it will show the field translation if it exists.

example of field translation in search

While it’s important to translate your options for option fields (when relevant), it’s also important to think about when an option field should be primary only vs. overridable vs. language-specific. In most cases, option-fields should be set to Primary Only if the field is talking about the definition of the entity, like a “type selector” or a list of “features”. The options selected should be true regardless of the language. However, there are some cases where you might want to make an option custom field overridable or language-specific, in particular if it’s about things like services offered in a given language.

unit Quiz
+20 points
Daily Quiz Streak Daily Quiz Streak: 0
Quiz Accuracy Streak Quiz Accuracy Streak: 0
    Error Success Question 1 of 3

    What are the 3 types of language behavior for fields?

    Error Success Question 2 of 3

    If a field is a single-line text field with a string that will appear on a Search results card in the subtitle, what would you recommend for the language field behavior?

    Error Success Question 3 of 3

    How are custom field option translations used? (Select all that apply)

    Climbing that leaderboard! 📈

    You've already completed this quiz, so you can't earn more points.You completed this quiz in 1 attempt and earned 0 points! Feel free to review your answers and move on when you're ready.
1st attempt
0 incorrect
Feedback