About Localizing Live Collaboration

UTF-8 configuration for the app servers is mostly done by default with a few steps required to be done manually. For more information, see Language Support.

The following table shows the files used to localize each part of 3DSpace:

Items to be localized	Studio Modeling Platform	Other ENOVIA apps
User Interface menus, dialog boxes, tips	matrix.txt, matrix.vr	emxAPPNAMEStringResource_LANG.properties emxComponentsStringResource_LANG.properties Java class files that get compiled with applets (such as checkin applet, Gantt Chart applet, etc.) (no changes in field)
Schema objects	Language Aliases	emxFrameworkStringResource_LANG.properties
Lower level schema objects (policy states, attribute ranges)	one language only (administration definition)	emxFrameworkStringResource_LANG.properties
Error messages from 3DSpace Service	matrix.txt, matrix.vr (file on the client)	matrix.txt, matrix.vr (file on the server)
APPNAME is the name of the app; LANG is the 2-digit ISO code.

ENOVIA apps default to English if the translated string cannot be found. This can occur for several reasons. The most obvious is when the Web browser is configured for a language that is not provided. Also, MQL keywords are not localizable, and so these are always shown in English. In some cases, most strings appear localized, with a few showing up in English. This occurs when text is added late in the software release cycle, and you can assume that they will be updated in a future release. However, in other cases, the English word is preferred by the ENOVIA translation reviewer, and so will remain untranslated. If this is the case, and you have another preference for the string, you can modify the provided file(s).

In a UTF-8 environment, strings are not processed in the kernel. The 3DSpace Service just passes them to the database as received. However, one exception is for file checkin through the server using the workspace directory–standard checkin, not File Collaboration Server (FCS). 3DSpace hashes file names on checkout in the workspace directory, but does not hash file names on checkin. So, an English server configured for UTF-8 treats a UTF-8 encoded file with double-byte characters in the name being checked in as consisting of extended ASCII characters and succeeds in creating a file in the workspace directory. But the database expects UTF-8 bytes and so produces an error on checkin. However, the sequence of bytes in the file name are the same on the native and English operating systems. Also, the file content is encoded correctly.

The workaround is to use FCS for all file checkins through a 3DSpace Service.