This scenario describes translation upgrade considerations when you start working with the terms concepts.
Standard core Terms and Translation files should be installed via the Middle Tier Installer. Customized source code should be scanned to find translatable attributes.
All languages that you need translation for should be set as Open For Translation in the Configure Used Language feature. Furthermore you should set up a new term domain and term owner structure for your customization. (Note: This is only available on sites with an IFS Development License.)
Our recommendation is to create a new Term Domain that corresponds to the customer name. All newly created terms for your customizations should be connected to this new domain. You can also change the domain on core terms if you need to make any other change on the term. The reason for doing this is to group all your customized terms together. You could then in the system easily explore and query up all your customized terms.
We strongly recommend you to create a new Term Owner structure and to connect all new terms to any of the newly created term owner sub nodes. The reason for connecting all new terms to a new term owner is that when exporting aggregated terms all new terms will be stored separately. It's wise to avoid mixing customized terms and standard core terms in the same xml files. Do not change owners on customized standard core terms, since this affects where the terms are stored on disk.
If you for instance have a scenario where you have new components for you customization, then create a new term owner for each component. Also create a General term owner for all new terms on existing standard components. E.g. Customizations for customer Acme resulted in that new terms where created and term bound to standard components in IFS Distribution and to a brand new customer component Foo. We then recommend that the following owner structure is registered.
Terms created for customizations in the Foo component are connected to the Foo owner. All other new terms should be connected to the General-Acme owner.
If you don't have any new components for the customization, you should only create the General owner. It's however important to create the owner as a small structure in order for the explore mechanism to work correctly in the application.
The recommendation for handling not term bound customized attributes is to perform a manual term binding. This enables a higher re-use of existing terms and translations. You will also benefit by receiving what's this texts in addition to translations. Manual term binding can require a lot of time depending on the amount of customized attributes. There are however scripting support for automatic term binding. This could be used in scenarios where the resources are scarce and there are a huge amount of non term bound customizations. The list below presents the pros and cons by using automatic term binding.
Pros
Cons
The Logical Unit TermAutoUtil holds a method (Auto_Bind_Term) for automatically binding of terms for a specified component.
The following parameters should be specified:
| Parameter | Description |
|---|---|
| Created Bindings |
Out parameter that returns the number of automatically bounded attributes. |
| Component | Mandatory parameter, determines the component that holds unbound attributes. |
| Term Domain | Any new terms will be created for this domain. |
| Term Owner | Any new terms will be created for this owner. |
| Main Type | Optional parameter that specifies the main type. Use this if you for instance only want to automatically term bound all Java attributes for a component. All main types is considered if this is left out (null). Possible values are null, LU, JAVA, RWC and SO, where SO equals Centura client attributes. |
| Allow Non Unique Translations | The automatically created terms display name also gets auto translated, if possible. The auto translation checks any existing translations that matches the formatted Prog Text. It first checks in the term database and thereafter in the localize translation tables. The translation is performed for all languages that is open for translations. This option determines if you allow the system to translate if several different translations exists for a display name (prog text). |
| Bind Existing Terms | Determines if the system should try to term bind to existing terms. Checks are made against the display name and prog text. If set to TRUE the system will term bound if a one to one relationship exists between a prog text and a term display name. |
| Create New Terms | If set to TRUE the system will create new terms if no existing terms can be used. New terms are translated automatically. No Usage Definition texts can be created automatically. |
| Exclude Form Doc | If set to TRUE the system will indicate that the automatically created term binding will be excluded from documentation. No What's This text will be available. It's recommended that this is set to TRUE since the system cannot automatically select a matching usage definition for binding against existing terms. |
Checklist prior to running the script:
Load the translation (TRS) file (that holds translations for the customer modifications). This step is optional, but loading translation files increases the ratio of auto translations.
Scan the affected source code. (A number of unbound term bindings may now appear, depending on the nature of the customer modification.)
Prepare Basic Data setup.
Run the script.
Commit changes to the database.
Text translations for a language, that isn't handled in core, will no longer be valid (used) for term bound attributes. Script exists for re-using text translations to create term translation in a scenario where you have text translations installed but you lacking term translations.
The Logical Unit TermAutoUtil holds a method
(Auto_Translate_Term) for automatic translation of a term. The script as you can
see below utilizes this method to translate any not translated terms. Click
here to get access to this script.
The script loops over all not translated terms given a specific component and language. It checks both current term translations as well as text translations for any matching translation.