Localization extends to return date, number and currency formats that are specific for the 'Locale' configured in the Registry. For more information, refer to Defining the System Locale.
In a multi-language installation, each Registry can be configured with a different locale. For example, when customers enter the purchase flow by selecting the Dutch language option, the date, number and currency formats will be validated against the Dutch locale (nl_NL). If they select the English language option, the date, number and currency formats will be validated against the applicable English locale (en_US or en_GB).
A portable software library called ICU is used to perform localization (http://site.icu-project.org/).
A locale is a set of parameters that defines the user's language and country. Currently, the following locales are supported:
•en_US: English - United States
•en_GB: English - Great Britain
•nl_NL: Dutch - Netherlands
The locale determines:
•The expected input format for dates, numbers and currencies.
•The thousand separators and decimal separator for the output formats numbers and currencies.
•The language used for any of the words used in the display format of a date (days of the week).
•The currency symbol for the currency code configured in the system.
To simplify the process of applying date formats to individual fields in the Registry, a set of standard subtypes have been introduced. Date formats can be applied to these subtypes, and then the subtype can be applied to the field in the Registry. The date/time format dd-mm-yyyy HH:MM will return 09-12-2024 19:02 for nl_NL and en_US; however, if a long form date component is requested (day of the week, month of year) the value will be returned using the language of the locale. Formats have also been removed from ticket template elements and have been replaced with a 'Subtype' field. For more information, refer to Defining Date and Time Display Formats.
Almost every area is affected by localization and display formats. Reporting, however, remains un-localized where all dates, numbers and currencies are returned in a standard un-localized format. This includes Business Intelligence extracts to the CSV, XML and Charting. PDFs output will return localized data.
When users operate the system, the locale configured in the Registry only controls the language of the user's session. For example, if an Desktop user is using the system in English (en_GB locale) and prints a ticket for an order created by a customer using the system in Dutch (nl_NL locale), the day of the week printed on the ticket will be in English, not Dutch. The locale is driven by the user operating the system.
Localization has been built around five key concepts.
1.The input is validated for the locale. When a field accepts an input, the input from the user is passed to ICU and validated against the expected input for the locale. For example, the numeric value of one thousand point five would be accepted as 1000.50 in the en_GB locale and 1000,50 in the nl_NL. Using the wrong thousand separators, decimal separator, date language or separator for the locale will return a validation error.
2.Editable fields have a non-configurable format. If a field accepts input, once the input has been validated the data is represented in an editable format. This is a non-configurable short format which allows the user to quickly change the values entered. For example, I might enter 12 June 2024 into a date field. If the input was valid for the locale the system would return the input as 12-06-2024. This is a similar concept to Microsoft Excel data entry. The field might be formatted in a long date format, but when the field is selected for editing the value in the field changes to a short format. When editing date fields, the separator and ordering of the date components is determined by the locale. When editing a currency field, the editable format removes the currency symbol and any thousand separators. When editing a number field, the editable format removes the thousand separators.
3.Display fields can be formatted either on the primitive or the subtype. A display field is a read-only field. For example, 'Event start Date' in a set of search results. Display fields use the format configured on the primitive or on the subtype applied against the individual field. Thousand separators, currency symbols and decimal separators are localized for the locale. For dates, the separator and ordering is all configurable within the format. If the user configures the date format to provide a long form of a date component (month as a word), this date component will be returned in the language of the locale.
4.Durations are not localized. The duration +1d means +1 day. These definitions are not localized. The d will always be used to represent day even if the the word day does not exist in the language.
5.Currencies are defined by the localization and provide the currency symbol. The system operator still configures the currency code and default currency in the system. For more information, refer to Configuring Currencies and Conversion Rates. This currency code is passed to ICU, and ICU provides the currency symbol for that currency code. If there is ambiguity, ICU provides extra data with the currency symbol. For example, the system currency is CAD but the locale is en_US. It could be confusing to a customer to return just a $ symbol in this scenario, it could mean USD or CAD dollars. ICU would return the currency symbol as CA$ to prevent any confusion.
Known Limitations:
•It is not possible to purchase a stored value item that has multiple price options.
•Calendar controls for scheduled payments will return ##-##-## ##:##:## as the date when used, the date should be entered manually.
•SVG seat map creation and editing is not currently supported for users operating under the nl_NL locale – the user must use the en_GB or en_US locale instead.
