Qlik Community

QlikView Documents

Documents for QlikView related information.

Regional based formats and translations

Employee
Employee

Regional based formats and translations

This application gives a short example of how translations and regional formats can be applied in a QlikView application.

Attachments
Comments
joaquinlr
Valued Contributor II

Hi tko:

If the date seetings are available DD/MM/YYYY, MM/DD/YYYY and YYYY/MM/DD do you need to three date fields in every fact table? one for each format!!!

and three more for  DD-MM-YYYY, MM-DD-YYYY and YYYY-MM-DD

and three more for  DD.MM.YYYY, MM.DD.YYYY and YYYY.MM.DD

Thanks

joaquinlr
Valued Contributor II

Hi Toni Kautto:

If you have 10 different currencies, do you need 10 amount fields for each currency at you fact table?

If you have ###.###,00 and ###,###.00 as money format do you need 20 fields (10 amount currency for each money format)?

Thanks

Employee
Employee

Yes, by this principle those are correct assumptions. Creating additional fields general does not lead to any problems, besides creating a longer list of fields.

If you want to hide the fields you could consider adding a HidePrefix or HideSuffix so that the currency and language fields are not visible in all object properties.

Optionally a way to make the visualization easier could be to tie each user to a specific locale through Section Access, and thereby reduce the document to one locale only being visible for each user. Or perhaps the base locale and one more, to enable viewing values in local format as well as corporate format.

joaquinlr
Valued Contributor II

Well, i was thinking in an Users table with this fields

UserID, UserDateFormat, UserCurrency, UserDecimalSep, UserThousandSep

Too much fields multiplied by too much records will affect performance.

But if we do a reduction for each locale combination we will lose the "International Collaboration Session" functionallity.

Version history
Revision #:
1 of 1
Last update:
‎10-24-2013 06:04 PM
Updated by:
Employee