Key concepts

To understand how to set up, manage, and work with the MLU in PPM, it is important that you become familiar with the following terms:

  • Boilerplate text.Text that OpenText provides and that is built into the PPM user interface (both the standard interface and the PPM Workbench), and is not configurable by PPM users. Boilerplate text is distinct from custom configurations such as the prompts for fields on a request type. Much of the text that a PPM user sees in a form is a combination of boilerplate text and configured text.

  • Configuration. In this document, configuration refers to entities such as request types, workflows, report types, portlet definitions, user data, and so on that define custom forms and processes. OpenText PPM provides basic versions of some of these entities in the Best Practices content, but a PPM administrator can also customize or create them. Configuration entities typically contain complex business rules, and have migrators associated with them so that you can manage configuration changes using a standardized configuration-management process.

  • Definition language. Language in which a PPM entity is defined. To maintain the highest translation fidelity, we recommend that all translations of custom configuration attributes and master data lists (such as Time Management activities or Portfolio Management scoring criteria) be based on their definition language (rather than on subsequent translations).

    To maintain the integrity of the original business definition of your configuration, PPM configurators are restricted from modifying a configuration entity in any language other than the language in which it was defined. This enforces a clear separation between modifying the business rules of your configuration and translating that configuration.

    Note that, in some cases you may find it necessary to change the definition language of a given configuration, for example, if you needed to transfer ownership of the configuration to a group in another region. PPM does provide a mechanism for changing an entity's definition language.

  • Entity attributes. These are the translatable properties of an entity.

  • Entity ID. A number that identifies a type of entity in PPM, such as "request type." For example, all request types (Bug, Enhancement, Proposal, and so on) in the system share the same entity ID.

  • Fallback. This is the term for the technical mechanism by which an attribute is displayed to the user in its definition language if a translation in that user's session language does not exist.

  • Formatting locale. A user's locale setting (on the Regional Settings tab of the Edit My Profile page) used by PPM to determine how to format dates, numbers, and currency values for display to that user. The formatting locale is distinct from the user's choice of session language (which is selected from the limited set of languages supported in your PPM instance), though often they logically coincide. But PPM supports any locale for formatting purposes, even if the primary language used in that locale is not supported. For example, a user in Norway will want to see dates and numbers formatted according to Norwegian convention even though the Norwegian language is not supported in PPM.

    Note: (Windows) To export data to Microsoft Excel export or synchronize data with Microsoft Project, the user's PPM locale preference must match that of the Windows environment on which they are performing the data export or synchronization. This match ensures that Excel or Microsoft Project can interpret dates and numbers correctly.

  • Master data. Non-transactional data that is configured to support your PPM Center transactional processes. Much of the master data defined in PPM Center is global in nature and thus needs to be translated into multiple languages so that it can be used and comprehended by users who work with PPM Center in different languages. Master data that supports MLU can be translated via the same mechanisms as MLU-enabled configurations: export the attributes into property files, translate them as desired, and import the translated property files back into PPM Center.

    Master data include values for validations, activities, charge codes, scoring criteria, roles, skills, and so on. Except for validations, these do not have complex rules associated with them and are managed directly in the production PPM instance.

  • Reference code. The primary means that PPM uses to identify many (but not all) configuration entities. A reference code is not a translatable attribute, and typically does not change once it is set; you can use the reference code to refer to an entity by its reference code, regardless of whether its name is changed or translated. Most configuration entities that support the MLU have a reference code attribute.

  • Session language. This is the language a user selects when logging on to PPM. (The language set for the browser is the default session language selection.) The languages available for selection depend on which language packs are deployed and enabled on the PPM Server.

    The session language determines which translations of text the user sees in the PPM user interface. This is distinct from the formatting locale preference that the user specifies (on the Regional Settings tab of the Edit My Profile page), which determines how dates, numbers, and currency values are formatted for display to the user.

  • System language. This is the default language for the PPM installation and the language in which server administration is conducted. The system language is the language used to generate system-level information such as server logs, as well as system data that do not support multiple translations (such as PPM-provided reference object type names).

  • Transactional entities. These are particular instances of the forms completed for transactions such as requests, time sheets, projects and programs. These entities hold the data captured in the forms that move through the respective IT business processes.

    PPM currently has no facility for providing multiple translations for transactional data. Note, however, that predefined values for drop-down list fields are displayed in each user's respective session language (assuming translations exist in the system). In some cases you may prefer to divide activities that occur in different languages. For example, if a mix of languages in a single request would cause confusion, you could use separate request types for different languages.

  • Translatable resource. Any entity attribute that support multiple translations in PPM, such as custom field prompts for requests and user data, custom drop-down list validation values, roles, and skills. Translatable resources are addressed in detail in Managing Entity Translations and in Using Translation Management Tools.