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
- Example: Arabic report author sees “3ameel” instead of “Customer” in model explorer
- Report models do not support multiple languages for metadata names in a single model file
- 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
- If implemented, reports would run against any localized version of the model because IDs are unchanged
- 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
- Example: Arabic report consumer sees “3ameel” instead of “Customer” in report column label
- SQL RS reports do not directly support localization of text labels in a report
- 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)
- This is obviously cumbersome to set up at report design time, but it does work
– Localized data formatting at report run time
- Example: Arabic 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
- Example: Arabic report consumer sees product category “Akala” instead of “Bicycles” in report data
- This is typically done by storing localized values in the database as separate columns or as lookup tables based on user culture.
- Offhand I can’t think of a slick way to do this with report models. If you have some ideas, let me know.