This chapter describes how to create and manage a term with a set of display names. It also covers topics such status handling, history, alerts and term relations.
The creation of a new term is made in the Manage Term feature. This feature is easily accessed from the navigator entry New Term, see figure 1 below.
Figure 1. Use the navigator entry New Term to start the Manage Term feature in a New mode.
Start off by registering a term name in the Term field. It is recommended to enter a qualified term name, since it semantically defines a concept that should be used consistently across the application. A term name such as "Description" is too vague and needs to be specified further, e.g. "Sales Part Description". It is possible to block the use of certain unwanted names, see Manage Term Basic Data for further information.
The next step is to register the domain where the term is being used, this is done by entering a value for the Term Domain field. You also need to specify an Owner for the term. See figure 2 below. Term domain and owner are validated against user defined basic data, see Manage Term Basic Data.
Figure 2. This figure displays the most essential information for a specific term.
The term is by default set as a preferred term and it is also translatable. If you don't want your term to be translatable then just unselect the Translatable check box. This can be done even if a translations exists, but use this facility with caution as any existing translations will be lost. A warning message will be prompted if this is the case.
If the term name itself is not self-describing then it is worthwhile registering your Intention with the term and adding a Contextual Example of how the term should be used.
A term requires at least one display name, so when creating a new term the actual term name can be defaulted as the full name of the term. Please note that it is the display name and not the term name that will be translated. The defaulted full name can be modified and other display names can be added if needed. The number of display names that are required depends on the number and type of contexts in which the term is likely to be used. A maximum of six different display names can be registered, see figure 3.
Figure 3. This figure displays an example of two display names for a term, where the short name is translatable.
The display names are by default indicated as not translatable when a new
term is created. To set them as translatable, right-mouse click on the display type and select
the Translatable menu option. A translatable display name is indicated with the
icon.
Note: The display name is automatically set to translatable when it's bound (linked) to a label in the application.
New terms start in a preliminary state. These needs to released in order to facilitate translation of the display names. Releases should be enabled only when you believe that the term and its display names are correct. Right-mouse click on the left side of the Manage Term feature to select the Release menu item, see figure 4 below.
Figure 4. Displays how to release a term in a preliminary state.
If the term is released in error it can be set back to a preliminary state, this is done by selecting the Revert Release menu item, see figure above.
Modifications of terms and display names can be monitored on the History tab in the Manage Term feature. The history data can be grouped against the person who made the change, the type of change (Event) and the term revision. The revision number is increased whenever a term is revised.
Figure 5. Term history grouped by event. In this example the state was changed from Translated to Revised.
There are a number of ways to indicate that a term should not be used. You can quality block the term, set it to non-preferred or make it obsolete.
Quality Block should be used when you investigate if there is something that is incorrect within a specific term. A quality blocked term can still have term bindings (linked labels) but new bindings cannot be made, see Bind Terms to Labels for more information. The actual quality block is done by selecting the Quality Blocked check box, see figure 2.
A non-preferred term should be used if you want to restrict the use of this term. Non-preferred terms cannot have any term bindings at all. This is done by clearing the Preferred Term check box, see figure 2.
When a term is indicated as non-preferred then related term functionality can be used. For example if the term "Vendor" is a non-preferred term and you want the term "Supplier" to be used instead. Then start by clearing the Preferred Term check box for the "Vendor" term. Then navigate to the "Supplier" term and select the Related Term tab. Here you can set up the term "Supplier" which can be used for the related term "Vendor", see figure 6 below.
Figure 6. Displays how to terms can be related to each other.
The reason for doing this is so that the system can inform the user that the term "Vendor" is a non-preferred term and that "Supplier" can be used instead.
The last way to prevent the use of a term is to set it to Obsolete. Terms in this state are read only and cannot be used. This option should therefore be used with caution. Right-mouse click on the left side of the Manage Term feature and then select the Make Obsolete menu item, see figure 4.
During development many new terms are created and there is a risk for creating erroneous or duplicated terms. It's therefore possible to alert terms so these can be investigated at a later stage. The alert indicators are managed in the Basic Data feature. An alert is set by register a value in the Term Alert field on the Misc Info tab in the Manage Term feature. It also possible to register additional alert information in the Term Alert Reference field.
Figure 7. Displays how to register an term alert in the Manage Term feature.
Terms are currently the only tool for translations in the new Rich Web Client. All texts that needs to be translated are however not Terms by definition. In order to separate these texts with normal terms can a specific Technical Type be registered, see figure 7. The technical type is defaulted to TERM, but can be changed to TEXT for these particular terms. Example of such terms are error messages and other parameterized texts.
Parameterized texts for the Rich Web Client is done by registering substitute variables inside curly brackets. For instance so can you register a term with a display name that holds the following text; "The customer {0} is not valid.", where {0} is the substitute variable.
If you changed or added a new display name so will the bounded English labels not be visible in the application until the language dictionary cache is refreshed. To refresh the dictionary cache; Right click on the left side of the Manage Term feature as select the Refresh Language Cache, see figure 4 above.
This will menu item will initialize an small dialog where you can select which lbanguages that should be refreshed. Note that if you only changes the display name so is it enough to refresh the English language.