> For the complete documentation index, see [llms.txt](https://academy.pentaho.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.pentaho.com/schema-workbench/schema-workbench/localization.md).

# Localization

{% hint style="info" %}

#### Localization

Schema localization allows your Mondrian OLAP cube to display in multiple languages. Instead of hardcoding "Sales" or "Customer" directly in your schema, you use placeholders (called tokens) that get replaced with the appropriate translation based on each user's language preference. 

Think of it as mail merge for analytics – one schema serves many languages.
{% endhint %}

placeholder for localized cube screenshot:

{% tabs %}
{% tab title="Tokenization" %}
{% hint style="info" %}

#### Tokenization

**Tokenization** is the process of replacing real text like "Sales" with placeholders like `%{sales.caption}` in your schema XML file. These tokens act as variables that will be filled in later.
{% endhint %}

{% hint style="danger" %}

#### The Golden Rule

This is the most important rule in schema localization. You should **only** localize captions (the display text users see) and descriptions. **Never** localize the technical names that Mondrian uses internally.

For example, in `<Dimension name="Customer" caption="...">`, the `name="Customer"` should always stay "Customer" in all languages, but the `caption` can change to "Client" in French. The name is for the system; the caption is for users.

The same applies to levels, measures, and hierarchies. Always keep names stable and only translate what appears on screen through captions.

**Why this Rule matters ..!**

**Performance Problems**: If you localize names, Mondrian's cache breaks every time someone switches languages. Member names keep changing, forcing the system to rebuild caches constantly. This makes your analytics incredibly slow.

**Query Failures**: A French user writes a query referencing "\[Client].\[Europe]". An English user tries to run it, but their system is looking for "\[Customer].\[Europe]" – the query fails. Keeping names consistent means queries work regardless of language.

**Maintenance Nightmare**: Imagine updating a dimension referenced by 50 queries, but you have to do it in 5 languages with different names. You'll spend hours tracking down which name goes where. Stable names mean you only update once.
{% endhint %}

```xml
<?xml version="1.0" encoding="UTF-8"?>
<Schema name="ClassicModels"
  caption="%{classicmodels.schema.caption}"
  description="%{classicmodels.schema.description}">
...
```

{% hint style="info" %}

### What to Localize vs. What to Leave Alone

**DO localize** (these are for users to see):

* Dimension, hierarchy, level, and measure captions
* Description text
* User-facing labels and titles

**DON'T localize** (these are for the system):

* Dimension, hierarchy, level, and measure names (the `name=` attribute)
* Database column names
* Database table names
* Technical identifiers

Think of it this way: if it's in a `caption=` or `description=` attribute, localize it. If it's in a `name=` or `column=` attribute, leave it alone. This separation keeps your schema working smoothly while giving users their preferred language.
{% endhint %}
{% endtab %}

{% tab title="Message Bundles" %}
{% hint style="info" %}

#### Message Bundles

**Message Bundles** are simple text files (one per language) that contain the actual translations. For example, `MondrianMessages_en.properties` has "Sales" while `MondrianMessages_fr.properties` has "Ventes" for the same token.
{% endhint %}

```
classicmodels.schema.caption=Modèles Classiques
classicmodels.schema.description=La description
classicmodels.measures.caption=Mesures
classicmodels.measures.sales.caption=Ventes
classicmodels.dimension.customers.caption=CLIENTS
classicmodels.dimension.customers.description=La description
...
```

{% hint style="info" %}

### Properties File Best Practices

* Use UTF-8 encoding for special characters
* Add comments to organize sections
* Keep consistent token names across all language files
* Test all tokens have corresponding translations
* Avoid line breaks in property values
* Escape special characters with backslash if needed
  {% endhint %}

x
{% endtab %}

{% tab title="Dynamic Schema Processor" %}
{% hint style="info" %}

#### Dynamic Schema Processor

**Dynamic Schema Processor** is the engine that does the replacement. When a French user opens Analyzer, it reads your schema, finds all the `%{...}` tokens, looks them up in the French properties file, and replaces them with French text – all automatically.
{% endhint %}

x

x
{% endtab %}

{% tab title="Locale" %}
{% hint style="info" %}

#### Locale

**Locale** is simply a language code like "en" for English or "fr" for French that tells the system which translation file to use.
{% endhint %}

x
{% endtab %}

{% tab title="Second Tab" %}

{% endtab %}
{% endtabs %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://academy.pentaho.com/schema-workbench/schema-workbench/localization.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.