Best Practices for Building Multi-Language Search | Yext Hitchhikers Platform

What You’ll Learn

In this section, you will learn:

• What is a multi-language Search experience
• High level how it works between the frontend and backend of Search
• Overview of the steps to create a multi-language experience

Congratulations! You made it to the end of the module

You’ve hopefully learned a lot in this module about how to take a single language experience and extend that to multiple languages. For the most part, it’s the same, we just provide some additional tools and features to make it easy to manage while maintaining a high level of flexibility. We know that building global or multi-language experiences is a challenge in terms of coordinating teams and content, so we want to make the Search side of things as straightforward as possible for you.

We do have some best practices to share that can help guide you as you think about building a multi-language experience.

General Best Practices

• Don’t let collecting the content stress you out. You can start off an experience with limited verticals or features and gradually build it out over time based on your customer behavior. It’s possible that users in different languages are going to search for or want to see different information anyway.

• Remember that it’s important that your language profiles be consistent for your entities so all entities have the same “variation” of a language. If you want just one English experience, make sure that they all share the same language code (all “en” or all “en_US”). Each language experience is strictly limited to a locale.

• We strongly recommend building one language out first and then adding additional languages once you’ve established the look and feel of your experience and determined what content you want to include. Once you have one language that meets your needs, it’s much easier to start adding on later.

• Feeling lost? Use the Community and ask Yext Experts and your peers to help you if you have any questions. You can also join Office Hours on Tuesdays at 11am ET for some guidance or re-read through this module to see if you can find the answer to your question.

Search Configuration Best Practices

• As we noted in the Search Configuration module above, there are three options for creating multi-language. If you’re not sure which one is right for you, we recommend Option 2 where you create a separate single language Search Configuration for each language. This allows you the most flexibility and least complexity when making updates. This means you can add, remove or update verticals for each language at separate times which is important if content or translations are not all available concurrently. The configuration file is also just easier to manage.

• Make sure you feel comfortable with the difference between supportedLocales, countryRestrictions and localizations. If you’re using one configuration to build multiple experiences that map to different languages in Content (where en and en_gb are considered different languages) you must at least include supportedLocales. If you want any overrides, you’ll need to use localizations. If you are using built.location in your searchable fields and your entities are in multiple countries, you’ll want to include countryRestrictions.

Frontend Best Practices

• As mentioned above, we strongly recommend adding one language first and confirming with your team or client that it “looks good” before you start adding on more languages. Otherwise, it can be hard to keep track!

• Verticals like FAQs are almost always going to look the same across all verticals. Take advantage of that with Fallback so you have less to manage by deleting the non-default html.hbs files and limiting what you have to provide in the config.json file.

• If the cards are meant to look the same except for some hardcoded strings, take advantage of the translation files instead of creating separate forked cards with the strings directly coded into each card.