Localizing a report model


Reports and report models can be localized at many levels. Following are some ideas around the current support in SQL Server 2008 for each type of localization.


 


          Localized metadata at report design time


o   Example: Spanish report author sees “Cliente” instead of “Customer” in model explorer


o   Report models do not support multiple languages for metadata names in a single model file


o   It should not be difficult to build a custom solution to generate localized versions of the model file


§  Original .smdl file + XML file with localized entity/attribute/role names => localized .smdl file


§  Could use either XSLT or minimal code


o   If implemented, reports would run against any localized version of the model because IDs are unchanged


o   Metadata displayed in the report (such as column labels) would be in the language of the person who designed the report. Since they are merely text values copied in from the model explorer, they would not change at report run time.


 


          Localized metadata at report run time


o   Example: Spanish report consumer sees “Cliente” instead of “Customer” in report column label


o   SQL RS reports do not directly support localization of text labels in a report


o   Some customers have implemented this using a custom “resource” assembly deployed on the server, and all labels in the report are replaced at report design time with expressions that retrieve the appropriate resource string from the custom assembly (sample)


o   This is obviously cumbersome to set up at report design time, but it does work


 


          Localized data formatting at report run time


o   Example: Spanish report consumer sees numeric and date values in the report data formatted as “1.234,56” and “27/04/2009” instead of “1,234.56” and “04/27/2009”.


o   This is supported by the default number formats available on the ribbon in Report Builder 2.0. In the dialog box, select the “Use regional formatting” checkbox.


 


          Localized data values at report run time


o   Example: Spanish report consumer sees product category “Bicicletas” instead of “Bicycles” in report data


o   This is typically done by storing localized values in the database as separate columns or as lookup tables based on user culture.


o   Offhand I can’t think of a slick way to do this with report models. If you have some ideas, let me know.


 

Comments (3)

  1. Neil says:

    Did you ever figure out a way to do Localized data values at report run time??

  2. antoni0000 says:

    The site SQL Reports has a great SQL tutorial. Highly recommended for people just getting started on SQL selects.check it out

    http://www.sql-reports.net/…/sql-select-tutorials.html

  3. Localized data values at report run time are typically solved at application level by the introduction of a language specific description for LOV (List of Values) and Master descriptions. To built something similar at report level could be achieved with the help of a resource (e.g. XML), a look up needing to be performed for each value and the standard values need to be synchronized between application and resource. This might work for a small set of values. Another approach could be based on the use of a dictionary or a translation service, though I'm not sure how reliable are such approaches.

    I don't think it makes sense to approach this at report level – if such functionality is needed in reports it should be attempted to be solved at application level.