Currently, the title showed for a custom field (named "cfname") is:

• translation string from lang files in the form: $s_cfname
• the literal field name: "cfname", if not translation is found

Translation strings are to be defined in custom_strings_inc.php
In documentation this is noted as a feature:
"Had we decided to use start_date as the custom field's name, then it would not have been necessary to modify custom_strings_inc.php, since MantisBT would have used the existing, already localized string from the standard language files"

This may have some issues:

• User who manages custom fields, may not have access to modify physical files (custom_strings_inc.php)
• If a custom field name duplicates a mantis standard string name, the standard string showed may not be what the user really wants.
• If a custom field name duplicates a mantis standard string name, and a translation is included in custom_strings_inc.php, the standard text would also be changed on the UI
• Translation look up for custom fields doesn't tolerate sapces in string variable names, nor matches uppercase/lowercase for defined string names

Some ideas for improving this situation:
1) create a lang function specific for custom texts, wich prepends an identificator to avoid collision with standard string names. Eg: $s_CustomfieldString_xxxx. (like "plugin_lang_get" does)
2) Include option for translations in custom fields management pages. Storing custom fields localization string in database congifuration variables, to allow for web administration.
3) That custom_field_lang_get kind of function (1), can lookup in configuration (2), fallback to lang_files (standard, custom), fallback to literal name