Internationalization and Localization
Internationalization and localization are means of adapting Logi applications to the different languages, regional differences, and cultural requirements of a specific user community. This topic discusses issues related to these challenges.
About Internationalization and Localization
Internationalization is the process of designing an application so that it can be adapted to various languages and regions without low-level engineering changes. Localization is the process of adapting an internationalized application for a specific region or language by adding cultural- or locale-specific customizations and translating text. Together these are often referred to as globalization. Culture settings, which are generally governed by the client computer operating system and browser, are used to control the visual display of:
- Language, including fonts, font-sizes, symbols, reading direction, etc.
- Number formatting, including thousands-place and decimal separators
- Date & time formatting, including the use of different calendar formats
- Time zone
- Currency formatting, including symbols and positions of currency markers
- Weights and measures
- Paper size
The culture name, used to specify culture settings, is a combination of a two-letter lowercase culture code (associated with a language) and a two-letter uppercase subculture code (associated with a country or region). The format for a culture name is:
Examples include ja-JP for Japanese (Japan) and en-US for English (United States). In rare cases where a two-letter language code is not available, a three-letter code is used. Not all culture names are available on all operating systems; for example, en-SG (English-Singapore) is not available on Windows XP. Developers may rely on the fact that Logi products use technology based on internationally-accepted standards, such as XHTML, XML, and CSS. There are no language- or culture-specific versions of Logi products and internally they can be expected to operate consistently without regard to language or culture. For example, there is no special set of elements for one language and a different set for another language. It is the output generated by Logi products, reports and web pages, that can be customized by globalization. Logi Analytics products include features designed to make globalization possible and to support a variety of cultures. Developers have successfully configured their Logi applications for use in numerous countries, languages, and cultures. This useful presentation, Designing for International Users, from the W3C, discusses many of the generic issues associated with developing globalized applications. The following sections address specific areas of interest for developers who want to globalize Logi applications.
Data displayed in Logi reports is typically stored in datasources external to the Logi application and these datasources may have their own language- or culture-specific configuration possibilities. This is significant for the developer and may require coordination with IT system administrators to ensure proper configuration. In particular, database servers often have language configuration options or are available in language-specific product versions. The specifics of these are beyond the scope of this topic, but system and database administrators involved with databases providing data for globalized Logi applications need to concern themselves with issues such as:
- Character encoding (Unicode, UTF8, etc.)
Database server vendors often have extensive information available about their products and globalization. Here are some vendor resources:
Microsoft - International Considerations for SQL Server 2008 R2
Oracle - Database Globalization Support Guide for 11g
Logi applications are viewed on a client computer or a mobile device, with a browser running on top of an operating system (OS). Both the OS and browser have culture-related settings that may need special configuration for use with globalized applications.
In the Windows 10 operating system, for example, culture settings are referred to as RegionalSettings and can be set, as shown above, via the Settings applet. Other operating systems have similar settings. The system-wide formatting configured here is used by the Format attribute of various Logi elements to format items in reports (discussed in more detail below). Your OS will also have setting for the default input language for the system.
Browsers have language settings, as shown in Firefox above, which are generally available under browsers' Tools or Options menu. Most web pages, and Logi reports, contain information that tells the web browser what language and character set to use when displaying the page. This type of information is referred to as language encoding and is derived from the OS settings. You can, however, override the OS settings and force the browser to use a different language. When you change the browser's language here, a number of formatting changes will happen automatically. For example, selecting French [fr] and making it the first language of preference in the example above, will cause
- $1,234.00 to appear as
The currency format is changed so that the Euro symbol replaces the Dollar Sign, and the thousands and decimal separators are changed to those used in France. In this way, reports hosted on servers in one country can be automatically reformatted for viewing in another country. You may encounter references to an "invariant culture" - this is a term Microsoft uses to identify use of the English language without a specific geographic association. For Logi applications, this refers to English and the United States or en-US. The culture setting configured for a browser is available in a Logi application using the @Function.UserCulture~ token. This token can be used in several elements to modify their behavior.
In Logi reports, stylesheets and their classes can be used to control changes such as fonts, font sizes,
line heights, and reading direction when language changes are necessary. This can be
particularly useful when dealing with languages like Chinese,
where users tend to prefer different fonts,
and can also be useful to better harmonize the look of
mixed, script-specific fonts, such as when mixing Arabic and Latin fonts.
In general, the use of CSS selectors such as text-align, position, background-position, float, and clear, which often use absolute positioning, need to be reviewed when
an application. CSS also offers the lang selector, which can be used in a variety of ways to affect the display of text in different languages.
In addition, CSS file encoding can be set by use of the @charset command at the top of the file, for example:
- @charset "iso-8859-1"
The standard themes provided with Logi reporting tools include stylesheets and developers may need to create their own custom globalized themes, duplicating all but the stylesheet files, if themes are being used. The stylesheet files would then be customized for globalization. For more information about creating custom themes, see Themes.
Special care must be taken when designing reports that will be globalized, especially if they include user input elements. For example:
- Avoid using fixed widths and heights. When elements include sizing attributes, use a percentage, rather than a fixed number of pixels, whenever possible.
- Plan for the possibility of text-wrapping. Labels, captions, and other text may become longer when displayed in some languages, overrunning or wrapping within the space provided for them.
- Separate captions from input elements. Use Row, Rows, and Column elements to create your own HTML table to contain input elements, rather than an Input Grid. Use separate Label elements for input element captions rather than using their Caption attributes.
In general, any physical boundaries on the report page that may be affected by the size and length of text or data, which may change with different cultures, need to be given special consideration.
The _Settings definition in a Logi application provides application-wide configuration of various settings, such as connections, team development, etc. The Globalization element, which provides valuable assistance when developing a multi-cultural application, is also available for use the _Settings definition. The following table describes its attributes:
|Default Input Date Format||Specifies the default input date format used when an Input Date element does not have its own Format attribute set.|
|Default Input Date Reformat||Sets a default value for all Input Date Reformat attributes. These are available with Input Date elements, which allow the user to enter dates.|
|Default Input Time Format||The default input time format used when an Input Time element does not have its own Format attribute set.|
|Default Input Time Reformat||Sets a default value for all Input Time Reformat attributes. These are available with Input Time elements, which allow the user to enter times.|
|First Day of Fiscal Year||Specifies the first day of the Fiscal Year and is used when calculating dates and quarters for fiscal calendars. The value must be in the format of mm/dd. For example if your fiscal year begins on March 5, enter 03/05. The default value is 01/01. This value affects the Fiscal Year and Fiscal Quarter formats. See Format Data .|
|First Day of Week||Changes the order of days in the week in popup calendars used with date inputs and data calendars. Also changes how the first day of the week is determined for the @Date tokens that return first and last days of the week, such as @Date.ThisWeekStart~ and @Date.ThisWeekEnd~. Valid values are: 0 = Sunday (default), 1 = Monday, 2 = Tuesday, 3 = Wednesday, 4 = Thursday, 5 = Friday, 6 = Saturday This value affects the Fiscal Week format. See Format Data .|
|Input Reformat Culture||This attribute is deprecated - do not use it. A culture value that can be used to reformat input dates and values. You can set this to a different culture so that values from Input elements are returned in that culture. This can be useful when the database expects date and numeric values that are not in the invariant format. In most cases it is best to set up the database or database client account to use an "English" culture. This attribute is not used for dates when Input Date Reformat is used. The culture is specified as a string, such as en-us. To see a list of cultures, open IE, select Tools, Internet Options, Languages, then Add. The default culture is the "invariant" culture, which is basically US-English.|
|Java Font Folder||Active only for Java applications. Identifies the folder where TrueType fonts are located for PDF exports. The folder is required for PDF exports with fonts that contain characters that are not in the ISO-8859_1 character set. In Windows this is usually something like C:\Windows\Fonts. In Linux, this would be something like/usr/local/share/fonts/ttfonts.|
|Metric Prefix String||
Specifies user-defined values to be used when the Metric Prefix ("mp") is selected in Format attributes.
The range of numbers formatted by metric prefixes is from 1000^6 to
1000^-6, so one of 12 characters is applied to each power of 10. The default string of characters is:|
representing atto, femto, pico, nano, micro, milli, kilo, mega, giga, tera, peta, and exa. You can replace this string with a comma-separated string of your own 12 characters. More information about Metric Prefixes is available here.
|User Culture||Normally, the user's culture is obtained from the browser's settings. If a value is supplied here, the User Culture attribute overrides the browser's culture setting with another value. User Culture can be set with a token value, such as @Session or @Request. The culture is specified as a string, such as en-us. A list of available cultures can be viewed in the browser, where Language is specified.|
These and other formats are directly affected by the formats set in the Operating System and attributes in the Globalization element. For example, if the browser language or Globalization element's User Culture attribute is set to English/United Kingdom [en-GB]then setting a Format attribute to Currency will result in numeric values being shown with the Pound symbol . For more information about individual formatting options, see Format Data.
A number of individual elements allow the user to enter dates or interact with calendars, and developers may want to change the behavior of related elements based on culture settings. These include the Input Date, Date Picker, Data Calendar, and Time Period Column. The format and presentation of calendars and dates varies widely depending on country and/or language. At the application level, date-related aspects of your Logi application can be changed by adding and configuring a Globalization element in the application's _Settings definition. For example, setting the Globalization element's First Day of Week attribute will change the display of calendars. If the attribute value is set to 1, then Monday will be the first day in the calendar; the default is 0 which is Sunday. In addition, the browser's preferred language setting will affect the display of the month and day-of-week names in both a Logi element calendar and the selected value:
In the examples shown above, a Globalization element has been used to change
the first day of the week to Monday. Notice that the month name and
day-of-week abbreviations in the calendar change based on the browser's
preferred language setting.
In addition, the actual value returned after the user clicks on a date, shown
below the calendars, also reflects the language preference in any text it
contains - "Jan" vs. "janv". The element's Format attribute, of course,
controls the format of the date value returned into the element's input text box
after the mouse click.
In a "globalized date" scenario, when passing/submitting dates from your input controls to other definitions for use within tokens, as filters on queries, or within elements such as Condition Filters, we highly recommend utilizing the ISO-standard date format (yyyy-MM-dd) to avoid any locale/browser date conflicts that might arise. The element's Input Date Reformat attribute can be used for this purpose.
Super-elements, such as the Analysis Grid, include their own user interface (UI), which allows users to interact with the element at runtime. By default, the labels, selections, titles, etc. displayed in the UI are in English. However, these can be modified to be displayed in alternate languages, using a Logi technology called Template Modifier Files.
This technology allows the text used in the UI to be changed on-the-fly when the report pages are rendered at the web server. It can even be conditional, through the use of tokens, so that the changes are made automatically, based on external criteria such as the browser culture. This subject is discussed in detail in Template Modifier Files.
Logi Info includes a technology called Definition Modifier Files (DMF). A DMF is an XML file that contains instructions to modify a definition file's elements and their attributes at runtime. It's a separate file that's processed before the Logi Server Engine starts to render a report definition. At that time, elements may be conditionally inserted or removed, and attributes may be set or unset. This makes it possible to set culture- or customer-specific values based, for example, on locale or security roles, at run-time. This means that each user can potentially receive a different report because the definition used to generate their report has been customized for them, on the fly. DMFs are similar to the Template Modifier Files mentioned in the previous section and they're also conceptually similar to a plug-in that executes on the "LoadDefinition" event. In this context, you might think of them as the "poor man's plug-in": they can provide similar functionality but don't require additional development tools (Visual Studio, etc.) to write and compile a plug-in .dll or .jar file. To assist with globalization, a DMF could be used, for example, to perform language translation. XPath notation can be used in a DMF to find and replace specific strings of text anywhere in a report definition, in order to translate them into another language on-the-fly. You could even have a different DMF for each language supported and tokenize the DMF name in your report definition so that you can support multiple languages automatically. This subject is discussed in detail in Template Modifier Files.
Logi reports are most often viewed on a computer monitor but they can be printed to paper. Standard paper sizes vary in different countries and so Logi developers have been given some control over paper size. The following elements are involved (click the link to view more detailed information about their usage):
The Printable Paging element allows developers to set the paper size and margins on a page to be printed by specifying the exact sizes in inches. For more information about the Printable Paging element, see Create Printable Reports.
When exporting to Excel, the Target.Native Excel element includes a special attribute, Excel Paper Size, shown above, that sets the default paper size for the resulting worksheet. If left blank, the default paper size of the printer is used. For more information on the Target.Native Excel element, see Export to Native Excel.