It is possible to customize the terminology in QPR applications to better suit your organization's needs. This can be done with the help of a terms.ini file. The terms.ini file is a regular text file residing by default in C:\ProgramData\QPR Software\QPR 2017\2017.1\Servers\Settings. The file in the settings folder for Servers contains the [QPR Terminology] section, which can be used for customizing QPR Portal terminology. However, it is possible to customize also client terminology. To do this, create a file called terms.ini into the C:\ProgramData\QPR Software\QPR 2017\2017.1\Clients\Settings folder and add either or both of the following sections there:
•[PG Terminology]: Settings for QPR Modeling Client terminology
•[SC Terminology]: Settings for QPR Metrics terminology
The sections can contain any number of terms found in the dictionary of the corresponding product. For example, you can replace the Model menu caption with "Process" in QPR Modeling Client by inserting a Model=Process line under the [PG Terminology] section. Note that you don't have to care about possible keyboard shortcuts in the native terms. For example, if the term in the user interface is Model, i.e. Alt + M is a shortcut sequence for that item, the Model=Process line works as well as does &Model=Process. You can also define keyboard shortcuts for the custom terms you have created by placing the ampersand sign (&) before the intended shortcut key. For example, Model=Pro&cess would appear so that the Model menu item is replaced with Process, i.e. Alt + C is the shortcut sequence.
Note also that you will have to customize whole phrases in order for the customization to take effect, so if you are for instance changing the caption of "Integration View" user interface caption, you will have to insert a line such as "Integration View=SQL Import Configuration" into the terms.ini file in order for the phrase to be changed. For example "Integration=SQL Import" does not affect the "Integration View" menu item.
In addition, the following limitations apply to using the terms.ini:
•Language independent strings customizable in QPR .ini files are not affected by terms.ini. These strings include for instance WAS error messages and e-mail notifications. In addition, action-specific customizable strings such status and category options are customizable in actiontypes.ini.
•Context cannot be set for changed strings, i.e. it is not possible to change for instance "Description" label in the Comment actions without affecting also Action Plans and other actions.
•It is not always clearly visible in the user interface whether for instance a colon is part of the dictionary string or whether it is added in the template. In Portal templates the correct source strings can be found by looking for the #LocalizedText tags in the template files. The value which can be replaced is supplied inside the id parameter. For example, in the case the template has a row such as "<#LocalizedText id="Header">:", the colon is added after the term has been translated, and a valid terms.ini entry for changing this is Header=Something. However, in the case the template row is "<#LocalizedText id="Header:">", a corresponding terms.ini entry should be Header:=Something:
The custom terminology is checked at startup, i.e. to get your customizations into use, you will have to restart QPR clients or the QPR Web Application Server depending on the file being customized. The terms.ini file also overrides the dictionary files, i.e. the customized terms are used regardless of the language displayed in the user interface. However, in order for the substitution to work, you have to use the native English user interface captions as the source term. For example the previous example does not work if the translated equivalent of "Integration View" is used.
In the case a pre-made terms.ini file is located in the same directory as the installation package, it is copied to the installation target directory during the installation and overrides possibly existing terms.ini file in that directory. The terms.ini file is then copied from the installation directory under the ProgramData directory.