Kimball Forum
Would you like to react to this message? Create an account in a few clicks or log in to continue.

Localization

3 posters

Go down

Localization Empty Localization

Post  DavidKHay Sat Dec 07, 2013 12:41 am

Does anyone have shareable best practices, or references to information, about architecting a BI environment to present UI and reports in multiple languages? My main question is, should it be the DW's responsibility to provide all the translations, and when reports and UI query the DW they ask for the language the result should be returned in? Or, should the DW not be the source of all the translations; that it would only return a code reference to any translatable text/description and it is the UI/Reports' responsibility to take that code value and return the desired localized string for that code to the display/report via some other UI strings lookup? Although having the DW return the localized strings helps to have "one version of the truth", exposing a language parameter to any calls into the DW seems to require shifting from static objects like views supporting the BI layer to things that are harder to do impact analysis on for code changes like dynamic SQL. There is also an aspect that there are some localized strings in the UI/Reports that aren't the DW data, like report and column headings and such. Should the UI/Reports really be drawing some of what it needs from one UI String source and other information it needs from the DW in localized form?

I see Ralph has an article on localization (http://www.kimballgroup.com/1998/12/02/think-globally-act-locally/) but it doesn't address multiple language support.

DavidKHay

Posts : 1
Join date : 2013-12-07

Back to top Go down

Localization Empty Localisation of data and localisation of applications

Post  nick_white Wed Jan 15, 2014 5:50 am

Hi,

I believe localisation of data and localisation of labels/UI are two separate issues - so taking each one in turn...

UI: if you were using a commercial BI tool that supports localisation then you would follow whatever process is mandated by that tool - if your tool doesn't support localisation then either move to a tool that does (if you can find one!) or build your own UI - trying to force localisation into a COTS package that doesn't support it is almost definitely a non-starter. If you are building your own BI app/UI then this is 'just' an application development issue and you would again presumably just follow localisation best practice for whatever development framework it is that you are using.

Data: I would not even attempt this (unless you can find a pre-built solution that can do this - and I'm not aware of any) as any solution is likely to kill query performance and/or explode the volume of data in your DWH. I would be surprised if any requirement to provide translated data in a BI environment could pass a rigorous cost-benefit analysis (but happy to be proved wrong)
1) presumably not all data should be translated so this is an attribute-specific requirement rather than a global one? For example, you might not want to translate someone's title from 'Mr.' to 'Senor' (English-Spanish) but you would want to translate a record's status from 'Closed' to 'Ferme' (English-French)
2) Holding translations of each attribute within a Dimension table might work for a single supplementary language but would explode your data volumes as you added more languages and would be very inflexible - as adding new languages would require updating the structure of all your Dimensions, populating the new columns with the new translations on the existing records, etc.
3) Is your DWH in a single core language or not? Probably easier for reporting if it is (otherwise you would need to hold a language indicator on every record) but obviously would make the ETL more complicated if the source data isn't and so needs to be translated to the core language prior to loading into the DWH
4) You'd need a translation table - probably with a group id (such as 'customer title') and then columns for each language.
5) You'd need Views/stored procedures etc. to join all this up and you'd need some way for your UI to use the right view or pass the right parameters - and if your UI is a COTS package this may not be possible

nick_white

Posts : 364
Join date : 2014-01-06
Location : London

Back to top Go down

Localization Empty Re: Localization

Post  ngalemmo Wed Jan 15, 2014 12:35 pm

Multi-language support in the DW usually is limited to alternate descriptions in dimensional data.  To that end, there are three basic approaches:

1.  Have different dimension tables for each language.  Same table schema, same primary key.  User database access controls would be used to point a user to a particular language version.
2. One dimension table with rows for each language.  You would wind up with a compound PK: the surrogate key and a language code.  Queries would always need to filter by language code.
3.  If you are not international and only need to support 2 or 3 specific languages, you can always go with multiple description columns in the table.

At the BI/Reporting level, I don't know.  It really depends on the reporting tool.  You usually wind up creating copies of the report with titles and column headings in different languages.
ngalemmo
ngalemmo

Posts : 3000
Join date : 2009-05-15
Location : Los Angeles

http://aginity.com

Back to top Go down

Localization Empty Re: Localization

Post  Sponsored content


Sponsored content


Back to top Go down

Back to top


 
Permissions in this forum:
You cannot reply to topics in this forum