Skip to main content
Mitratech Success Center

Client Support Center

Need help? Click a product group below to select your application and get access to knowledge articles, webinars, training content, and release notes or to contact our support team.

Authorized users - log in to create a ticket, view tickets status and check your success plan details.


How are i18n Keys Generated?

For "out of the box" static text that is present in TeamConnect before any customization, all i18n keys are already present. Those keys are permanent and are not editable by you. These elements of static text become rows in the localization spreadsheet. Shown below are examples of spreadsheet entries to show the patterns used in generating such i18n keys.

i18n key and default text examples

Design element

Example i18n key and default text


Static text

account.accountProjectType Posting Project to this Account


Static text

accountView.title Account - {0}

This message accepts a parameter - the name of the account. When localizing it is important to preserve parameter tokens.


objdef.ACCT.block.Account_Children Child Accounts


Button text

button.saveAndPreview Save & Preview



enum.docucontent.26 Rich Text Format

Enumerations can be used to populate fixed drop-down lists, in this case for choosing the file type of a document.


enum.lineitem.adjustmenttarget.neta mount

Net Amount


Error message


Could not parse screen file due to improper use of a tag in file. Please check logs.


Error message


Value "{0}" entered for criterion "{1}" is invalid.

Parameter tokens must be preserved when localizing.

Search view (criterion)

objdef.ACCT.searchview.DefaultTem plate.criterion.Vendorr290c1


Tokens like "r290c1" were used by prior versions of TeamConnect to control the positioning of a criterion on the filter page.

Search view (result column)

objdef.ACCT.searchview.DefaultTem plate.resultscolumn.Balance



System lookup table entry

table.system.CURR.item.CAD Canada, Dollars


Custom field

objdef.CONT.customfield.Eligible Eligibility

"Eligible" is field name. "Eligibility" is field label.

Features that Require Your Attention

The preceding sections described TeamConnect features whose i18n keys are generated automatically. The sections below describe features where you can influence the generation of i18n keys for localization.

Note: Many of the features below use Unique Key fields. Characters entered in those fields must be ASCII letters and numbers.


In order to localize report properties such as data series names, column headers, etc., there must exist an i18n key for each property. Since you can design brand-new reports that didn't exist in the out-of-the-box design, you need a way to assign i18n keys to the new reports' properties.

This need is addressed by the Unique Key fields that are found in the various report design pages. If you do not plan to localize a report, you may leave these fields empty. But if you need to localize the report, each of these fields in the report must have a value.

For details about localizing reports, see Localizing Reports.

Custom Messages

Custom messages are created using the Custom Messages page within System Settings in Designer (for global messages) or using the Custom Messages page within an object definition (for object-specific messages). They consist of an i18n key and default text. The i18n key takes two forms:

  • custom.common.someUniqueKeyfor global messages, where "someUniqueKey" is the only portion of the key that is actually entered by the solution developer.
  • custom.INVC.someUniqueKeyfor object-specific messages (object INVC, in this example), where "someUniqueKey" is the only portion of the key that is actually entered by the solution developer.

Custom messages are exported to the localization spreadsheet and you can supply alternate locales' text to the messages in that spreadsheet.

Custom messages can be used in custom actions to provide localized error messages. Localized text for custom messages is available through the API methods: localize() and localizeNumber().

Custom Blocks

The static text of custom blocks can be localized during design by referencing custom messages rather than typing literal text.

The Screen Designer tool allows you to reference custom messages by key. If you are editing block XML files manually, you can use tags tc:message and tc:messageParam to achieve the same effect.

Text that is added to a block by entering literal text in the Screen Designer, or by using the out tag with literal text, will not be localized. It will always by rendered as it was originally entered.

Portal Panes

The Designer page for Portal Pane Settings provides the opportunity to enter Unique Key values for the pane and its contents, which are converted to full i18n keys during export to the localization spreadsheet.


Each rule has a Unique Key field that is converted to a full i18n key during export to the localization spreadsheet. Unlike some other design elements, the name of a user-invoked rule can be localized so that it appears in the user's locale in the More Actions drop-down list at runtime. There are rows in the spreadsheet related to security rules' message text and validation rules' message text, so those can be localized as well.


Wizard design pages have Unique Key fields in several places, covering the wizard itself plus its text elements. Unique Key values are converted to full i18n keys during export to the localization spreadsheet.

Saved Searches

A saved search is one end user's copy of a search view, edited for the needs of that user and saved under a name that is assigned by the user. Saved searches do not have i18n keys, so there is no action to be taken by the solution developer with regard to localization. However, there is some localization behavior that should be understood. Under one uncommon and specific set of circumstances, a saved search can behave slightly differently from other features, with respect to localization.

The labels of criteria and result fields are always obtained, when possible, from the original search view that underlies the saved search. However, since the end user can remove results and criteria, and add brand-new results and criteria, there can be elements in the saved search that are not found in the original search view. In this case, one of two things will happen:

  • If the element is a custom field, its label will be obtained from the object definition.
  • If the element is not a custom field, the label used will be the one that was in existence at the time the search was saved. Even if that end user is now using a different locale, the label in the saved search will reflect the locale at the time the search was saved.
  • Was this article helpful?