I’ve spent an inordinate amount of time these past few weeks understanding how translation and languages (a.k.a. locales) work in MicroStrategy. The concept is simple: the metadata and/or the data in the data warehouse can be represented differently for users depending on the preferred language. This means that there has to be a mechanism for mapping what the user sees to whatever is stored in the metadata or the warehouse. For the data warehouse, data translation involves dynamically selecting lookup tables that have descriptions tied to the surrogate keys in the warehouse, and for the metadata, translation means associating a language with an object and identifying the label that gets called when the object (attribute, metric, prompt, etc.) is called.
Such is the example of a lookup table that has multiple columns supporting different languages, which is dynamically accessed based on the preferences that the user has been set up with.
Metadata translation works slightly differently, and is accessed for creation and modification by right clicking on any attribute and choosing the “translate” option.
The reason I’ve been spending so much time looking into languages is that unlike many things in MicroStrategy, the creation or altering of languages and translations does not have a corollary function available in Command Manager. This has taken me down an obscure alley in MicroStrategy to a place called the Repository Translation Wizard. The RTW is an executable that sets up a staging area for the translations that have to occur for selected objects. I had seen this aspect of MicroStrategy before, but never had a reason to use it — but for the uninitiated it is under the Object Manager folder:
So, essentially the RTW is a utility that can do a bulk replacement of object names. For a selected project the developer would choose all of the objects that require translation, and the utility creates an XML dump file with the proper object IDs and names.
At this point the RTW repository is essentially a staging area where the object information is dropped, with a placeholder column for the translation.
So, a little SQL update statement…
set TRANSLATION = 'Promotion for Client1'
where OBJECTID = '1B7A3F0249C78AD99C3A05A7274389BC'
and READABLEKEY = 'Object Name'
…and then check that the object has been translated…
…and when Client1 logs into the project the report will render with their custom name…
A scenario for this type of implementation is somewhat limited to highly customized environments where every user feels that the report is specific to their needs and their business. For example, if the Promotion attribute was used for departmental reporting, the language could be used to make the attribute label look and feel like it was designed specifically for that user.