---
title: Index languages
slug: cms-12/docs/language-support-and-analysis
docTags: 
createdAt: 2026-08-10T15:55:59.000Z
---

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](https://www.elastic.co/guide/en/elasticsearch/guide/current/analysis-intro.html).

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](https://webhelp.optimizely.com/latest/en/searchnavigation/search-optimization.htm) 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](docId\:k86dL0gc_bGtar_K2YDRn).

:::hint{type="info"}
**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`.

```json
    "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:

```csharp
.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**.

See also: [Elasticsearch guide](http://www.elasticsearch.org/guide/)