Localization
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.
placeholder for localized cube screenshot:
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.
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.
<?xml version="1.0" encoding="UTF-8"?>
<Schema name="ClassicModels"
caption="%{classicmodels.schema.caption}"
description="%{classicmodels.schema.description}">
...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.
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.
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
x
Was this helpful?