Resource Bundle File NamingThe 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:
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 NamingString 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 Sample of an Internationalized JSPThis 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 TimeThis 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> </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 i18nA 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 IDsWhen 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 ObjectsUse this format to define an administrative object. emxFramework.<Admin Object Type>.<Admin Object Name>=<Translated Value>
Examples (for French translation of schema objects with English names):
Attribute RangesUse this format for defining attribute ranges. emxFramework.Range.<Attribute Name>.<Range Name>= Range Name Translated where:
Examples (for French translation of schema objects with English names):
Policy StatesUse this format for defining policy states. emxFramework.State.<Policy Name>.<State Name>= <State Name Translated> where:
Examples (for French translation of schema objects with English names):
Type Name : Subtype NameUse 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 TranslationsSample 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 NotificationsUsers 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. |