Boilerplate Text
This entity specifies a 'fixed' text item, used in the user interface. Examples are field labels, menu labels, headers. These boilerplate texts can be translated into new languages and/or adapted to conform to customer specific business terminology.
A Boilerplate Text has the following attributes:
Code | The unique code for this boilerplate text |
---|---|
Text Value |
The text value for this boilerplate text |
Insurance Type [1] |
The insurance type to which this text applies |
Boilerplate texts are seeded upon installation, but the text value can be changed. The use of boilerplate text entries, that is where the text appears on a page, is controlled by the system. A set of naming conventions for the Code value is used to clarify the usage in Oracle Health Insurance. See sections below.
It is also possible to add additional boilerplate text for user interface customization (see the Oracle Health Insurance applications - Installation Guide for the specifics) or for Insurance Type specific customization.
Insurance Type Specific Boilerplate Text
A boilerplate text can be customized for a specific insurance type. This allows the user interface to reflect the commonly used terminology within an insurance type even if multiple insurance types are configured in the system. The system determines the insurance type based on the contents of the page. This means that the labels in the user interface for an object in one specific insurance type can differ from the labels in that same UI when displaying that same object for a different insurance type.
For example: if Persons are used in a Health Insurance insurance type and in a Life Insurance insurance type, a UI label for Persons may be different when a person is displayed in the context of Health Insurance from when a person is displayed in the same page but now in the context of a Life Insurance.
An insurance type specific boilerplate text can be created by copying an existing boilerplate text, give the copy a reference to an insurance type, update the text to the required value and save the new boilerplate text. Insurance type specific boilerplate text does not necessarily include the full set of boilerplate text, where a language specific boilerplate text does. It is possible to have only one or a few boilerplate texts for a specific insurance type.
An insurance type specific boilerplate text can have translations. If the generic boilerplate texts is available in the system in two languages, creating an insurance type specific boilerplate text will probably (but not necessarily) require two new copies of the boilerplate text, one for each language.
An insurance type can refer to more than one insurable entity type. This means that the system applies the boilerplate text that is specific for a certain insurance type to all insurable entity types in that insurance type.
The display name of dynamic fields or the display name of dynamic field usages in a dynamic record is not boilerplate text. These display names are not insurance type dependent. |
Insurance type specific boilerplate text is used only in a restricted number of UI pages. In those UI pages that use insurance type specific boilerplate text, the system will first search if a boilerplate text for the specific item for the specific insurance type exists. If such a boilerplate text does not exist it will display the not-insurance type specific text.
A reference to an insurance type can be applied to all not system specific boilerplate text. The system does not restrict what boilerplate text can be made insurance type specific. However only the UI pages that use insurance type specific boilerplate text will display these texts. All other UI pages and the menu will ignore insurance type specific boilerplate text.
Examples
The UI can be customized by changing the fixed texts used in the Messages and Boilerplate Text (fixed labels in the User Interface, like page headers, field labels, button labels, etc.).
They can be changed using the Boilerplate, Messages, and Bulk Translation pages within Oracle Health Insurance. The changes are effective immediately, for users running in the language in which the changes were made.
The language in which the changes are made, cannot be a System Specific language like System English. The texts can only be changed in other languages like regular English. |
When using the Bulk Translation page for boilerplate and messages (FN0031), all occurrences of the exact same term will be translated in the "Term To". So plurals will be translated too. Like if a boilerplate contains "person" and this needs to be replaced by "party", "persons" turns into "partys". Either translate the plurals first or put spaces in front and at the end of the terms: " person " to " party ".
The following sections explain the naming conventions for the boilerplate text code, to derive for which page components they are used.
Domain Keys
Domain Keys are used in drop-down lists. The code of the boilerplate starts with the prefix 'DOMAIN', followed by the Domain Name and the Domain Value:
DOMAIN_<Domain Name>_<Domain Value> = "<Domain Meaning>"
Examples:
-
DOMAIN_GENDER_M = "Male"
-
DOMAIN_GENDER_F = "Female"
Subtype domains use the convention DOMAIN_<Entity>SUBTYPE_<4 letter abbreviation. A subtype domain is used when different subtypes of a supertype can be handled in one page. For example, in the Relations page, both Organizations and Persons are shown.
Examples:
-
DOMAIN_RELATIONSUBTYPE_PERS = "Person"
-
DOMAIN_RELATIONSUBTYPE_ORGA = "Organization"
Entity-Specific Keys
Entity related keys are prefixed with the 3 letter subsystem abbreviation that is also used for the corresponding database table, and the entity name in uppercase (for example, COD_FLEXCODE, or PAS_SEGMENTGROUP). That way they are grouped together with other entities in the same subsystem. Table below summarizes the different types of entity specific keys.
Convention | Usage and Example |
---|---|
<Prefix>_<Entity>_TITLE_PLURAL |
For headings of multi-row data
blocks within a page. |
<Prefix>_<Entity>_TITLE_SINGULAR |
For headings of single-row
data blocks within a page. |
<Prefix>_<Entity>_TITLE_<FunctionCode> |
In menu labels. |
<Prefix>_<Entity>_TITLE_LOV |
In List-of-values |
<Prefix>_<Entity>_TITLE_BREADCRUMB |
For breadcrumb labels of the page. (A breadcrumb is created when
navigating to another page using a deeplink). |
<Prefix>_<Entity>_TITLE_REGION_<Region> |
For region titles. |
<Prefix>_<Entity>_TITLE_<logical name> |
For any other titles
related to the entity. |
<Prefix>_<Entity>_DELETE_WARNING |
For delete warning. A delete warning is shown in a popup before the
actual delete. |
<Prefix>_<Entity>_BUTTON_<logical name> |
For command buttons
specific to an entity. |
Item Generic Keys
For items that occur in all/many pages, a generic key is applied for all entities that have such an item.
See table below for conventions used:
Key | Usage |
---|---|
GEN_FIELD_STARTDATE |
Start date. |
GEN_FIELD_ENDDATE |
End date. |
GEN_FIELD_ACTIVE |
Active checkbox. |
GEN_FIELD_SUBTYPE |
Subtype discriminator. |
Item-Specific Keys
An item specific key is created for each individual item on a page following the convention: <Prefix>_<Entity>_FIELD_<Field>_<SUFFIX>. In case the field of the entity points to another entity, a field of the other entity is added: <Prefix>_<Entity1>_FIELD_<FieldToEntity2>_<Field>_<SUFFIX>
<SUFFIX> is used to distinguish between different places an item can occur. See table below:
Suffix | Usage |
---|---|
DEFAULT |
Default suffix |
DEFAULT_FROM |
Default suffix used for a search from field. |
DEFAULT_TO |
Default suffix used for a search from field. |
TABLE |
Suffix used for a deviating label in a table layout. |
FORM |
Suffix used for a deviating label in a form layout. |
SEARCH |
Suffix used for a deviating label in a search layout. |
SEARCH_FROM |
Suffix used for a deviating label of a from field in a search layout. |
SEARCH_TO |
Suffix used for a deviating label of a to field in a search layout. |
Examples:
-
PAS_PRODUCT_FIELD_CODE_DEFAULT="Code"
-
CLA_CLAIMFORM_FIELD_CODE_DEFAULT_TO = "Code To"
-
CLA_CLAIM_FIELD_CLAIMFORM_CODE_DEFAULT = "Claim Form"
-
REL_PERSON_FIELD_ADDRESSLIST_DEFAULT = "Addresses"
Module-Specific Keys
(JET-only)Boilerplates needed for specific pages/modules that are not an entity title / attribute / domain boilerplate.
Examples:
-
M_CLAIMS_ prefix for the JET Claims search and edit pages, including subpages
-
M_CLAIMS_LINKTOTASKSWITHERRORS
-
-
M_REPROCESS_ prefix for the JET Reprocess Claim pages
-
M_REPROCESS_COUNT_BUTTON
-