About Internationalizing

You can internationalize ENOVIA products, including the login and home pages. These guidelines assume the applications are written in JavaServer Pages (JSPs).

For more information, see Java 2 (JDK 1.2+) documentation.

For details on internationalizing UI component text, see Internationalizing Dynamic UI Components. For details on how the ENOVIA Studio Modeling Platform is internationalized, see "Localizing ENOVIA Live Collaboration" in the ENOVIA Studio Modeling Installation Guide.

This topic includes the following topics:

Resource Bundle File Naming

The naming convention for the base resource file, which is always in English, is: emxAPPLICATION_NAMEStringResource.properties, where APPLICATION_NAME is the original name of the application. For example, the string resource file for Engineering Central is emxEngineeringCentralStringResource.properties. The string resource file for pages that can be available for any application, such as the login and home page, is emxFrameworkStringResource.properties.

For ENOVIA Business Process Services, these files comprise the string resources:


  • emxFrameworkStringResource.properties
  • emxCommonStringResource.properties
  • emxMetricsStringResource.properties
  • emxTeamCentralStringResource.properties

The naming convention for internationalized versions of the StringResource files is emxAPPLICATION_NAMEStringResource_LANGUAGE.properties, where LANGUAGE is the standard abbreviation for the language, such as fr for French or de for German, in lowercase.

All string resource files must be located in Apps/Framework/VERSION/UserInterface.

The StringResource properties files must be encoded in ASCII for all languages, both double-byte and latin-based languages. To edit text for languages that include non-ASCII characters, work with the native file that is included in the properties directory (such as emxFrameworkStringResource_jaNative.properties) and then convert the modified file to ASCII. These native files are encoded using the native format for the language. For the English files, you only need to make sure you save the properties file as ASCII. See Adding and Editing Schema Translations.

Resource String Naming

String names in the resource files must follow a precise format.

Each string in the resource file should be formatted as follows to prevent name collisions:

emxAPPLICATION_NAME.PAGE.KEY=STRING_VALUE

For example, for a page named emxLibraryi18nTest.jsp in Library Central, the strings for a greeting and farewell would be entered as follows in the string resource file for English:

emxLibraryCentral.Libraryi18nTest.greeting=Hello
emxLibraryCentral.Libraryi18nTest.farewell=Goodbye

Application Applets

The ENOVIA products may provide some functionality, such as checkin and Gantt charting, using applets.

Applet translations come from within the .cab or .jar file, and therefore they can not be modified in the field.

Sample of an Internationalized JSP

This code shows a sample JSP that has been internationalized.

<%@ taglib uri="/emxUtil.tld" prefix="emxUtil" %>
<%@ page import="matrix.db.*, matrix.util.*, com.matrixone.servlet.*, 
java.util.* , java.net.URLEncoder, 
com.matrixone.apps.librarycentral.i18n.*"  %>
<%@include file = "emxTeamI18n.jsp"%>
<emxUtil:localize id="i18nId" bundle="emxLibraryCentralStringResource" 
locale='<%= request.getHeader("Accept-Language") %>' />
<html>
<head>
<title>i18n Sample page</title>
</head>
<body >
<emxUtil:i18n>emxLibraryCentral.i18nTest.greeting</mxUtil:i18n>
</body>
</html>

emxLibraryI18n.jsp defines two methods that can be used for internationalization.

<%@page import="matrix.db.*, matrix.util.*, java.util.* , 
com.matrixone.apps.Librarycentral.i18n.*"  %>
<%
  String DateFrm = (new 
Integer(java.text.DateFormat.MEDIUM)).toString();
%>
<%!
  // Call this method to internationalize variables in java.
  // i18nStringNow("stringid", request.getHeader("Accept-Language"));
  static public String i18nStringNow(String text, String languageStr) 
{
    i18nNow loc = new i18nNow();
    return (String)loc.GetString("emxLibraryCentralStringResource", 
languageStr, text);
  }
%>

Local Date and Time

This sample of a table cell displays a due date in the user's language and in the appropriate time zone.

  <td><emxUtil:lzDate displaydate="true" localize="i18nId" 
tz='<%=timeZone%>' %=sDueDate%></emxUtil:lzDate>&nbsp;</td>

When the displaydate parameter is true, only the date is displayed. To display only the time, use displaytime=true. To show both the date and time, do not specify either parameter. The timezone must be stored as a variable which is offset in hours from Greenwich Mean Time.

Debugging i18n

A back-door solution is provided for debugging internationalized pages. When the locale is set to debug, the i18n tag returns the string ID instead of the actual string.

The following is the same code presented previously, but translated:

<%@ taglib uri="/emxUtil.tld" prefix="emxUtil" %>
<%@ page import="matrix.db.*, matrix.util.*, com.matrixone.servlet.*, 
java.util.* , java.net.URLEncoder, 
com.matrixone.apps.librarycentral.i18n.*"  %>
<%@include file = "emxTeamI18n.jsp"%>
<emxUtil:localize id="i18nId" bundle="emxLibraryCentralStringResource" 
locale='debug' />
<html>
<head>
<title>i18n Sample page</title>
</head>
<body >
<emxUtil:i18n>emxLibraryCentral.i18nTest.greeting</mxUtil:i18n>
</body>
</html>

Formats for Schema String Resource IDs

When adding and changing resource file IDs, you must follow the defined formats. There is a standard format for all administrative objects and a slightly different format for attribute ranges and policy states.

Use only English characters in string resource IDs. Of course, the translated values can have non-English characters.

Administrative Objects

Use this format to define an administrative object.

emxFramework.<Admin Object Type>.<Admin Object Name>=<Translated Value>

where:


  • emxFramework is the keyword to group all these resource IDs as part of ENOVIA Business Process Services.
  • <Admin Object Type> is the administrative object type, such as Type, Role, Attribute, etc.
  • <Admin Object Name> is the name of the administrative object that needs to be translated. All spaces should be replaced with "_" for this ID.
  • <Translated Value> is the translated value for the administrative object.

Examples (for French translation of schema objects with English names):


  • emxFramework.Type.Manufacturing_Process=Processus de fabrication
  • emxFramework.Role.Buyer=Acheteur
  • emxFramework.Attribute.Count=Total

Attribute Ranges

Use this format for defining attribute ranges.

 emxFramework.Range.<Attribute Name>.<Range Name>= Range Name Translated

where:


  • emxFramework.Range is the key that groups all the range names within the FrameworkStringResource file.
  • <Attribute Name> is the actual name of the attribute to which the range value is associated. The blank spaces are replaced with "_".
  • <Range Name> is the actual value of the attribute range for which translation is required. The blank spaces are replaced with "_".
  • <Range Name Translated> is the translated value for the specified type name.

Examples (for French translation of schema objects with English names):


  • emxFramework.Range.Approval_Status.Abstain=S'abstenir
  • emxFramework.Range.Approval_Status.Approve=Approuver
  • emxFramework.Range.Create_Folder.No=Non
  • emxFramework.Range.Create_Folder.Yes=Oui

Policy States

Use this format for defining policy states.

 emxFramework.State.<Policy Name>.<State Name>= <State Name Translated>

where:


  • emxFramework.State is the key that groups all the state names with in the FrameworkStringResource file.
  • <Policy Name> is the actual name of the policy to which the state is associated. The blank spaces are replaced with "_".
  • <State Name> is the actual name of the state for which translation is required. The blank spaces are replaced with "_".
  • <State Name Translated> is the translated value for the specified state name.

Examples (for French translation of schema objects with English names):


  • emxFramework.State.Build_Archive.Archive=Archiver
  • emxFramework.State.Buyer_Desk.Exists=Existe
  • emxFramework.State.CAD_Model.Release=Distribuer

Type Name : Subtype Name

Use this format when defining a type with a subtype.

If a string property must include a colon, such as the header of the History page that displays Part:Assembly, the colon must be preceded by a backslash in the string resource file. For example:

#emxFrameworkStringResource.properties
emxFramework.Type.Part\:Assembly=Part:Assembly

Sample JSP Code for Getting Administrative Object Translations

Sample JSP code for getting the administrative objects translation is given below. Typically, you get the current name of the administrative object using the symbolic name.

For instructions on how to get the current administrative object name, see Getting Administrative Object Names from Symbolic Names. For the steps needed to use translated schema in JSPs, see Translating Schema.

//*************************************************************
<%@include file = " emxI18NMethods.jsp"%>  
<%
String languageStr = request.getHeader("Accept-Language");
// Get the Part Type name
String sPartType = getAdminI18NString("Type", "Part", languageStr );
// Get the Role name
String sRoleName = getAdminI18NString("Role", "Design Engineer", 
languageStr);
// Get the Attribute name
String sAttributeName = getAdminI18NString("Attribute", "Lead Time", 
languageStr);
// Get the Policy name
String sPolicyName = getAdminI18NString("Policy", "EC Part", 
languageStr);
// Get the Relationship name
String sRelName = getAdminI18NString("Relationship", "EBOM", 
languageStr);
%>
//************************************************************

About User Default Language for Notifications

Users can choose a default language for notifications.

See Choosing a Language for Notifications for details. ENOVIA Business Process Services uses these properties in emxSystem.properties to build the list of languages a user can select from in their Preferences:

emxFramework.IconMailLanguagePreference=English German French Italian 
Japanese
emxFramework.IconMailLanguageLocaleEnglish=en
emxFramework.IconMailLanguageLocaleGerman=de
emxFramework.IconMailLanguageLocaleFrench=fr
emxFramework.IconMailLanguageLocaleItalian=it
emxFramework.IconMailLanguageLocaleJapanese=ja

When a user chooses a language preference, the system creates an administrative property called IconMailLanguagePreference and sets the value for the property equal to the corresponding IconMailLanguageLocal property. For example, if a person chooses French for the preferred language, the system creates an IconMailLanguagePreference property with the value fr.

The emxFrameworkStringResource.properties file (for English) uses these properties to define the text in the drop-down list:

emxFramework.IconMailLanguageEnglish=English
emxFramework.IconMailLanguageGerman=German
emxFramework.IconMailLanguageFrench=French
emxFramework.IconMailLanguageItalian=Italian
emxFramework.IconMailLanguageJapanese=Japanese

The other versions of the StringResource files have an equivalent set of properties with values appropriate for each language.

When an application sends a system notification, it looks for an IconMailLanguagePreference property attached to each recipient's Person administrative object. If it finds one, it sends the notification in the language that corresponds to the property's value (it en fr, and so on.). If it does not find a property (for example, the person has not selected a preference), it sends the notification in the languages defined in the emxFramework.NotificationLanguages property.

When sending a notification to more than one recipient, the application sends one notification for every unique language. For example, suppose there are three recipients: two have Italian as the preferred language and one has French. The application will send one Italian notification to the two Italian speakers and one French notification to the French speaker. The French speaker will only see his name in the recipient fields and the Italian speakers will only see their two names in the recipient fields.

The user-specific language preference works when the recipients are persons and not roles or groups. Currently, the ENOVIA products do not send system notifications directly to roles or groups. ENOVIA Sourcing Central sends some notifications to roles but first obtains a list of all persons in the company with the role and then fills in the recipient fields with those persons.

If you want to remove a language from the list available to the user, see Internationalizing System-Generated Notifications.