Index languages

You can index any content language, but Optimizely Search & Navigation uses a language analyzer to get the best search results for a specific set of content languages. When purchasing Optimizely Search & Navigation, you will order an index and specify analyzer support for a defined group of languages.

Search queries in any of these supported languages will run through the language analyzer, and the search results delivered are richer and more nuanced than for unsupported content languages. While Optimizely Search & Navigation indexes the content in unsupported languages, it does no analysis. See Elasticsearch Analysis and Analyzers.

The language analyzer breaks down text based on a language's characteristics. For example, the English analyzer might use stemming analysis to identify fish as the root word for fishing, fished, fishes, fisher, and fisherman. By understanding how to construct a language's words, Search & Navigation can recognize several versions of a word as the same term, providing better search results. Likewise, Optimizely Search & Navigation optimization only works with supported languages.

Optimizely Search & Navigation's analysis and optimization features supports the following indexing languages.

Indexing languages with analytics support

Arabic
Armenian
Basque
Brazilian
Bulgarian
Catalan
Chinese
CJK (Chinese, Japanese, and Korean)
Czech
Danish
Dutch
English
Finnish
French
Galician
German
Greek
Hindi
Hungarian
Indonesian
Irish
Italian
Latvian
Norwegian
Persian
Polish
Portuguese
Romanian
Russian
Spanish
Swedish
Thai
Turkish

See also Language-specific queries.

📘
Notes
Since language codes in Optimizely Search & Navigation are limited, use a fallback language for search analyzer and best bets settings. If you select and search for language Norwegian (Nynorsk)(nn-NO)which is known as Norwegian but in Search & Navigation you only know the Norwegian(no) code so that search request could return results with unexpected analyzer. To correct it, from Search & Navigation 16.4.0, developers can add the language mapping by key LanguageMaps inside the Find section which will define the fallback from [language code] to [other language code]. The following example defines nn and nb fallback to no.
    "Find": {
      "DefaultIndex": "your_idex",
      "ServiceUrl": "service_url",
      "LanguageMaps": {
        "nn": "no",
        "nb": "no"
      }
    }

Compound splitting

Many European languages contain compound words. For example, the single word in Swedish, "ståltermos," is two words in English, "steel thermos." Compound words adversely affect relevancy for normal free-text search engines, especially for ecommerce, and can result in lower conversion rates.

Optimizely Search & Navigation uniquely includes a feature called compound splitting, which analyzes each word and discovers compound words. To continue the previous example, a visitor can search for the Swedish word "termos" and get a relevant match for "ståltermos". Most search solutions (including Elasticsearch) do not include such functionality. And solutions that usually employ a less sophisticated approach that does not give the same high relevancy and associated conversion rates.

Compound splitting is available for Swedish and Norwegian.

Turn decompounding on and off

[New in Optimizely.Search & Navigation 12.3.0]

The default query setting is to not decompound the query string. To enable decompounding, use this syntax:

.For("query", x => x.Analyzer = Language.Swedish.Analyzer)

If a user submits a search term fotbollsmatch, the query only matches fotbollsmatch/er/en/… and not (as it did previously) ‘fotboll/ar/en/..’ and match/er/en/….

On the other hand, if a user submits the search term fotboll, the search matches fotboll/ar/en…, fotbollsmatch/er/en/…, and fotbollsplan/er/en.

📘Notes

Compound splitting

Turn decompounding on and off

📘
Notes