The Document Locale

[hic]

The locale defines a number of regional settings. Here is how it is done in Qlik Sense. 

[hic]

In the beginning of the load script you will find a number of Set statements defining the environment variables. These determine the date format, the month names and a number of other things that pertain to the regional settings.

This is the Document Locale.

In other products or situations, there is usually a locale per computer or per user, but for Qlik Sense and QlikView the locale is per app. The reason is that the locale affects selections and set expressions internally in the Qlik logic, so it wouldn’t work with different locales for different users. Examples:

• The date format: Should {<Date={7/11/2022}>} refer to July 11th or to Nov 7th? The interpretation is different in different countries.
• The collation: Should {<Text={"*a*"}>} also match ‘å’, ’ä’, ‘ā’, or ’æ’? This is different in different countries.

Since we want a measure containing a set expression or a bookmark to return the same value for different users, we cannot have different locales for different users. Everyone within the same app must use the same locale. The solution is to have a document locale.

If the set statements are organized a little, it becomes easier to see what they do. The following shows the locale I usually use:

First, you have some variables that pertain to numbers, decimal symbol, thousand separator, etc. These will be used for interpreting text as numbers when loading data, as well as for formatting the values. Then you have some variables that pertain to date and time. Also these are used for interpretation and formatting, but now of dates and timestamps.

Then you have some variables that pertain to calendars; names of months and week days, how the week numbers should be calculated etc.

All of the above variables are used internally by the Qlik functions, so if you change a variable, some functions will return a different value. For example, the WeekStart() function obviously uses the value of FirstWeekDay. Further, the month and day names are linked to format codes. For example, Date(Date,'MMMM') will always return one of the values in LongMonthNames.

Many functions have parameters that can override the environment variables, i.e. the variables define a default, but as a user you can change that. Example:

Date(Date) will use the date format of the variable DateFormat
Date(Date,'YYYY MMMM DD') will use the date format of the parameter

The week numbering is a chapter of its own: In some countries, the ISO week numbering is used: The week starts on a Monday, one week number may well span two years, and Jan 4th is always in week 1. This corresponds to

Set FirstWeekDay =0; // 0=Monday
Set BrokenWeeks =0;
Set ReferenceDay =4; // Jan 4th is always in week 1

But in other countries, e.g. USA, a different system is used: The week starts on a Sunday, a week number never spans two years, and Jan 1st is always in week 1:

Set FirstWeekDay =6; // 6=Sunday
Set BrokenWeeks =1;
Set ReferenceDay =1; // Jan 1st is always in week 1

We recently had a bug that caused some problems: The MakeWeekDate() function ignored the environment variables and instead always returned the ISO8601 values (the ISO standard assumes that Monday always is the first day of the week). This was an obvious error and was fixed, but unfortunately the fix caused negative effects for some customers, and we apologize for that. More info on the support blog.

Finally, the CollationLocale affects sort orders of text strings and searches: Which field values should be matched for a given search string.

Feel free to change these variables should you need to!

HIC

Read more about interpretation and formatting and about collation.