The below information is the basic expectation for all Hexagon's PPM products. For information about the internationalization expectations for your specific product, refer to the next section.
Supporting internationalization in a homogeneous environment is one of the enhancements available in Hexagon's PPM products. A homogeneous environment uses elements from only a single locale. For example, a German customer running on a German operating system using only German characters and German cultural conventions is a fully supported homogeneous environment configuration.
When starting a new project, use extra care during installation and configuration to ensure the proper creation and maintenance of homogeneous environments:
All the computers (servers and clients) within a Hexagon's PPM product implementation must have the same regional settings, and no one should change the regional settings after the project has started.
Do not cross the decimal locale boundary. This is the most common cause of numeric data corruption and calculation errors. Having users with different regional settings (such as with a period versus a comma for the decimal point) causes the software to interpret values unpredictably. For example, a pipe run with a pressure of 35.3 psi can be read by the software as 353 psi to the user with different regional settings. A cable length defined as 39 ft 11,21 inches has been interpreted as 121718910971323 meters when published to an XML file. These incorrect interpretations may be used in internal software calculations and can be impossible to backtrack or correct. Do not change the decimal point character to try to solve an issue. Doing so will only corrupt values in the database or in text files.
Do not cross the character-set locale boundary. For example, the character set boundary between Western (Latin-based) and Eastern Europe (Cyrillic-based), or between Eastern Europe and Japan.
Create Oracle databases using AL32UTF8 for the database character set and AL16UTF16 for the NLS character set.
Never modify the NLS_LANG registry entry on an Oracle client. Doing so causes the character data not to convert to Unicode.
Create Microsoft SQL Server databases with locale-specific collation settings and ensure that all databases have the same setting.
Intergraph Smart Cloud delivers all solutions on English infrastructure. A homogeneous environment is available when customers deploy English clients.
In contrast, a heterogeneous environment using elements from different, or even multiple locales, is not supported. Many customers are currently operating in unsupported heterogeneous environments and are often not aware of that fact. Examples of heterogeneous environments:
Entering or viewing Japanese data on a US/English operating system
Using German Regional Settings (where the decimal point is a comma) on a US/English operating system
Using databases with different character encodings such as CL8MSWIN1251 or JA16SJIS
Using multiple languages in a project, especially when crossing language-group boundaries
Using an English server with different local language clients
Intergraph Smart Cloud delivers all solutions on English infrastructure. Any clients configured to use non-English will result in a heterogeneous environment.
International / Bi-lingual Projects
International bi-lingual projects are possible; however, great care must be used when configuring these environments. Limitations exist and must be properly understood:
Oracle and MS SQL Server databases can reside on any language operating system, as long as the databases have been created and configured with proper Unicode and collation settings.
All SQL Server databases must have the same collation setting and reflect the master language. Text is stored, sorted, indexed, and presented based on the collation setting. You must determine which language will be used primarily to generate output (P&IDs, SLDs, reports, approval documents, and so forth.) If Russian and English text is entered, and Russian is the target locale, choose the collation based on the Cyrillic character set.
All Microsoft operating systems (Japanese, Russian, German, and so forth) can enter English characters. The reverse, however, is not true in most cases.
Keyboard-locale can be changed as long as a character-set and code-page boundary is not crossed. For example, English, German, French, and Spanish characters can all be used in the same project because the same Windows® code-page (1252) is used. However, Russian characters (code-page 1251) cannot be used in a US/English environment.
You must decide which language operating system is the master for bi-lingual projects.
The following is an example of a Russian-based project:
Companies in the United States and the United Kingdom are working a project with a Russian company and the deliverables (drawings, reports, and so forth) must ultimately be provided in Russian. The companies in the U.S. and the U.K. are working the project using the master Russian operating systems (possibly using virtual Russian operating systems running on VMware Workstation). The U.S. and U.K. companies can install and use English Microsoft Office products on the Russian operating system because Office products are globally enabled. If a Russian interface exists for the Hexagon's PPM product application, then Russian users can use the Russian interface while the English-speaking users continue to use the US/English interface. English-speaking engineers can enter English characters. Russian-speaking engineers can enter Russian characters.
However, because the Russian locale uses different decimal and character-set locales, everyone (English and Russian engineers) must use the Russian decimal symbol which is a comma. For customization purposes, databases can be modified to accommodate new Russian-specific requirements (fields, properties, and so forth.) Using filters, display sets, and other software features, bi-lingual projects can be further customized. Graphic data, reports, and so forth can be created in either or both languages.
Do not change regional settings to reflect a U.S. environment in order to resolve problems in a non-US/English homogeneous configuration. Doing this creates a heterogeneous configuration that will cause other possibly hidden problems that cannot be corrected. Everyone working on a project must use the same regional settings and character set throughout the life of the project.
Citrix Virtual App Solutions for International Projects
Using Citrix Virtual App Solutions, you can define environments that isolate users from having to interact with non-native language operating systems while improving data integrity and minimizing opportunities for data corruption. However, users must enter data using master locale conventions for the project (decimal separator and date conventions, for example). You can create these environments using different combinations of languages, but some limitations exist. For example, you cannot use Russian and Chinese text together in a project. In addition, special language characters (the German ä and ß for example) cannot be used if the master locale is outside the western Latin-based languages (the master locale is Russian, Chinese, Japanese, or Korean, for example).
Questions and Assistance
Please contact your support representative for assistance and answers to your questions: see customer support.