Product SiteDocumentation Site

Chapter 7. Customizing MantisBT

7.1. Strings / Translations
7.1.1. Custom Strings File Format
7.2. Custom Fields
7.2.1. Overview
7.2.2. Custom Field Definition
7.2.3. Adding/Editing Custom Fields
7.2.4. Linking/Unlinking/Ordering Existing Custom Fields in Projects
7.2.5. Localizing Custom Field Names
7.2.6. Dynamic default values
7.2.7. Dynamic values for Enumeration Custom Fields
7.3. Enumerations
7.4. Email Notifications
7.5. Customizing Status Values
7.6. Custom Functions
7.6.1. Default Custom Functions
7.6.2. Example Custom Function Override

7.1. Strings / Translations

All the strings used in MantisBT including error messages, as well as those defined in plugins, can be customized or translated differently. This is achieved by overriding them in the Custom Strings File (config/custom_strings_inc.php), which is automatically detected and included by MantisBT code.
Defining custom strings in this file provides a simple upgrade path, and avoids having to re-apply changes to modified core language files when upgrading MantisBT to the next release.

Note

The standard MantisBT language strings are sometimes reused in different contexts. If you are planning to override some strings to meet your specific requirements, make sure to analyze where and how they are used to avoid unexpected issues.

7.1.1. Custom Strings File Format

This is a regular PHP script, containing variable assignments and optionally some control structures to conditionally define strings based on specific criteria (see Section 7.2.5, “Localizing Custom Field Names” for an example).
<?php
$s_CODE = STRING;
$MANTIS_ERROR[ERROR_NUMBER] = STRING;
Where
  • CODE = language string code, as called by lang_get() function. Search in lang/strings_english.txt for existing codes.
  • ERROR_NUMBER = error number or constant, see constant_inc.php.
  • STRING = string value / translation.

Note

The custom_strings_inc.php file should only contain variable assignments and basic PHP control structures. In particular, calling MantisBT core functions in it is not recommended, as it could lead to unexpected behavior and even errors depending on context.
If you must use API calls, then anything that expects an active database connection needs to be protected, e.g.
<?php
if( db_is_connected() ) {
	if( helper_get_current_project() == 1 ) {
		$s_summary = 'Title';
	}
}

Warning

NEVER call lang_get_current() from the custom_strings_inc.php. Doing so will reset the active_language, causing the code to return incorrect translations if the default language is different from English. Always use the $g_active_language global variable instead.