Russell Christopher's Semi-Useful BI Musings

Many people understand that you can leverage User!Language in order to grab the regional / language settings of a user, then use this information to localize your report data & label text. If you don’t, no worries. Check this topic out:

http://msdn2.microsoft.com/en-us/library/ms156493.aspx

While leveraging User!Language certainly will work in terms of allowing you localize your reports, doing so is admittedly a pain in the tail – you essentially have to replace all your label text with expressions that call into code that you write to do “label localization” ala:

= MyNameSpace.MyConvertingClass.MyConverter(“someLabelName”, User!Language)

Your code takes the name of a label and the language to use, then goes off to a resource file to pull and return the correct string.

Localizing your data is less painful, you just store your “description text” in multiple languages (see the Product.ProductDescription table in AdventureWorks to see what I mean) in a table and use a parameterized query to yank the correct record based on User!Language.

Leveraging  the SQL Analysis Services Translations feature makes all this a thing of the past, however. Assuming that your data is moving through a cube, you can use this great feature to localize all your text, including captions, data, etc: See the AdventureWorks DW OLAP sample in C:\Program Files\Microsoft SQL Server\90\Tools\Samples\AdventureWorks Analysis Services Project\Enterprise\ . Once you get it open, click the Translation tab and explore a bit.

Anyway, if you have translations in place, all you have to do is tell SSRS to use ‘em, and your life is good. To do so, utilize the LocaleIdentifier connection string property of ADOMD.NET 9.0 to set a locale (like 1036 for France). See the attached (very simple) RDL document which utilizes the Adventure Works DW cube.

In Excel 2007, you get this behavior “for free”, but in SSRS you must add the LocaleIdentifier connection string property yourself, and give it a numerical value (1033, 1036, etc.) Here’s the part which makes it all work – you use an expression-based connection string to sense the user’s language (in this case “Are you French? If not, you’re getting English”) and feed in the correct LocaleIdentifier: