Internationalizing components

In common cases, you can store messages using a properties file in your component module to use internationalization.

This properties file must be stored in the same package as the related components and named Messages. For example, org.talend.demo.MyComponent uses org.talend.demo.Messages[locale].properties.

This file already exists when you import a project generated from the starter.

Default components keys

Out of the box components are internationalized using the same location logic for the resource bundle. The supported keys are:

Name Pattern Description


Display name of the family


Display name of the category ${category} in the family ${family}.


Display name of a configuration type (dataStore or dataSet). Important: this key is read from the family package (not the class package), to unify the localization of the metadata.


Display name of an action of the family. Specifying it is optional and will default on the action name if not set.


Display name of the component (used by the GUIs)


Display name of the option.


Equivalent to @Documentation("…​") but supporting internationalization (see Maven/Gradle documentation goal/task).


Placeholder of the option.


Display name of the option using its class name.


See ${property_path}._documentation.


See ${property_path}._placeholder.


Display name of the enum_name value of the enum_simple_class_name enumeration.

${property_path or simple_class_name}._gridlayout.${layout_name}._displayName

Display name of tab corresponding to the layout (tab). Note that this requires the server option to be set to true and it is not yet supported by the Studio.

Example of configuration for a component named list and belonging to the memory family (@Emitter(family = "memory", name = "list")):

memory.list._displayName = Memory List

Internationalizing a configuration class

Configuration classes can be translated using the simple class name in the messages properties file. This is useful in case of common configurations shared by multiple components.

For example, if you have a configuration class as follows :

public class MyConfig {

    private String host;

    private int port;

You can give it a translatable display name by adding ${simple_class_name}.${property_name}._displayName to under the same package as the configuration class. = Server Host Name = Enter Server Host Name...

MyConfig.port._displayName = Server Port
MyConfig.port._placeholder = Enter Server Port...
If you have a display name using the property path, it overrides the display name defined using the simple class name. This rule also applies to placeholders.
Scroll to top