Tabular Translations

Overview

The Analysis Services OLAP engine in Tabular mode has some missing features compared to the Multidimensional mode. The Tabular engine is used in Analysis Services on-premises, Analysis Services Azure and Power BI (desktop + cloud)

Among the features that Tabular mode does not replicate are

• Member translations
  • This allows multilingual display of a report based on the user.
  • e.g. An English speaker would see "Bikes" and a French speaker wouuld see "Vélo".
• Member Keys, separate from the member Caption
  • This allows reports to be built with member selections maintained when a Caption changes.
  • If you update a Caption in tabular mode and have a report filter containing that member, then the selection will no longer work.
    • In Power BI the old caption will be used, and the report will contain no data.
    • In an Excel PivotTable the selection will be lost when the data is refreshed, and the default (All) member will be displayed instead.

The Tabular Translations feature in XLCubed aims to address both of these issues allowing you to build a single multiligual report that will work correctly when member captions are updated.

Note this will not affect other from end tools such as Power BI or Excel PivotTables. You will have to use other translation strategies for those tools.

Translations

We will start with a simple data model conatining just the Product, Date and Sales tables from Adventure works (I have combined the Product tables in a database view so we have a star schema)

As you can see the dimension tables have the names in several languages. Currently each language is a separate hierarchy. Our aim is to present the user with a single hierarchy which will display the correct translation in XLCubed automatically.

To do this XLCubed uses a naming convention to chose the best translation to show the user. For example we have the Product Category Name which should be translated in reports.

We will rename EnglishProductCategoryName to Product Category Name, and this will be the default translation if no better one can be found. Next we rename SpanishProductCategoryName -> Product Category Name_es and FrenchProductCategoryName -> Product Category Name_fr. The extra two letters are the language code, these are standardised by ISO so it is simple to find the correct code for any langauge you need. [1]

We do the same for the Product Subcategory Name and Product Name.

If you do not want the users to access these columns you can hide them in the model, translations will still work correctly. Alternatively, you can add translations to the column names so that the users are presented with friendly captions when using these columns and attribute hierarchies. You do this using the standard metadata translation tools for Analysis Services.

With this done our model now looks like this:

Now if I turn on "Tabular translations" in the XLCubed -> Manage -> Manage Aliases screen then I will see the translations. Here is a before and after picture, both grids are using the same hierarchy:

Member Key and Caption

It is common to want a fixed key for a member so report selections are preserved when the caption is updated in the source data system.

To do this we will define a Key column and the Caption column it maps to. We will map to the base Caption column defined above, and any locale translations will also be applied.

To do this will do some more column renaming so the user sees useful names when building a report. ProductCategoryKey -> Product Category, ProductSubcategoryKey -> Product Subcategory and ProductKey -> Product.

Next we need to tell XLCubed how to map the key to the caption when running a query. This is done by adding an extra table to the data model (which you should hide). The table must be called XL3ColumnTranslations and have columns TableName, KeyColumnName and CaptionColumnName.

You can create this however you like, but for ease I will add a calculated table to the model:

And finally add a Hierarchy using the key columns:

Now when I create a grid based on the keys the captions are retrieved by XLCubed and translated into my preferred language:

As the drills are linked to the member keys the report will not change if the product captions are updated in the source system. The same would apply if I had placed the selections in the Headers area of the grid.

If I had used the attribute hierarchy for any of the key columns (e.g. "Product Category") then the members would also be translated from key to caption. You do not need to create a user hierarchy unless you need it in your model.

As the hierarchy is created using keys the default is to sort the members by those. If you wish to sort the hierarchy members by the caption or a custom sort column the you should set "Sort By Column" in your model.

Locale selection

As the translations are based on the column name suffixes ("_es", "_fr" in this example) XLCubed must choose the correct column to get captions from.

A users locale is defined as a language-country pair in windows (or through the browser for XLCubed web).

XLCubed will try

1. Exact language-country match
2. Matching generic language
3. Matching language for a different country
4. Base column with no suffix

For example if we have defined a translation for Portuguese(Portugal) we will have a column called Product Category Name_pt-PT. If a Brazilian Portuguese speaker opens a report then the process will be

1. User's locale is pt-BR but column is pt-PT - no match
2. Look for a column with suffix pt - not found so no match
3. Look for a column with langauge pt and any country - success pt-PT matches
4. Not evaluated, match already found

So the user would see the Portuguese translations in this case as the best match available in the model.