Translation of Field Labels

Core allows the designation of custom text 'group' types via hook_locale() in addition to the build in 'default' one used for code-defined strings. But there are no methods yet in core for implementing an equivalent to t().

In contrib, modules can use the i18nstrings module to provide translation for user defined strings. i18nstrings provides CRUD operations on the core locales_source and locales_target tables for custom text groups.

The closest we've got in core to enabling use of external solutions (like i18nstrings) is the 'title callback' attribute of menu items, which allows the substitution of another callback (like the tt() function used in i18nstrings). So far this doesn't actually work, since tt() requires contextual information, like an ID to identify a string with, so that updates can be registered when a source string changes or is deleted; see this issue.

Ideally, probably, we'd generecize the existing locales_source and locales_target CRUD operations in core to handle none-code strings.

Meanwhile, the field API could use some sort of title callback.

Or, maybe better, implement something like Views has.

• Give user-defined data a 'translatable' = TRUE attribute.
• Send data for altering before being saved, deleted, or viewed, allowing an external module to analyze the data and handle 'translatable' properties.

(Note: this isn't fully implemented in Views yet, but work is underway to do so.)

[Edit: The translatable property in Views currently is used when exporting a view, to ensure that the given property is wrapped in t() in the exported code. This could be applicable to fields, in that when exporting a field properties like the label should be wrapped in t() if the field is to be embedded in code--though not, I guess, if it's to be imported manually into another Drupal install.]