Internationalizing Strings
Mule supports internationalization of exception messages and any other type of string message.
Internationalized Messages
Mule uses the Java ResourceBundle class to load messages from properties files on the classpath based on the current system’s locale. Mule provides a full set of messages in English.
Mule’s internationalized messages are represented by the org.mule.config.i18n.Message class. Instances are constructed with a message ID and zero or more message parameters. You can see a list of core messages that Mule provides in META-INF/service/org/mule/i18n/core-messages.properties.
You never create instances of Message directly. Instead, you use subclasses of MessageFactory. The messages for Mule’s core project are accessible through the org.mule.config.i18n.CoreMessages class.
Each of Mule’s modules and transports has such a messages class. Its name is equal to the module with Messages appended. For example, for the JMS transport you uses JmsMessages to retrieve messages.
The dedicated messages class per module/transport has the following advantages:
-
Encapsulation of the message code.
-
Client code is not cluttered with
Messageconstructors. -
Client code has typesafe access to its messages.
-
Client code is not cluttered with formatting of message parameters. Instead, you handle this in the module-specific messages class.
Exceptions
MuleException is the base class of all Mule checked exceptions and can only be constructed using internationalized messages. To create a message for an exception, you use MuleExtension as follows:
MuleException e = new MuleException(CoreMessages.failedToGetPooledObject());
throw e;Using Custom Message Bundles
When writing Mule extensions or applications that uses the Mule internationalization class, you can supply custom message bundles containing messages specific to your extension or application. You create a resource bundle as follows:
1=Error message one
2=Error message with 2 parameters; param {0} and param {1}
...Where the number is the message ID and the actual message comes after. Note that message parameters are specified using '{0}' notation, which is standard when using the Java MessageFormat class.
The file should be named x-messages.properties where x is the identifying name for this bundle. You must place this file either in your JAR file under META-INF/services/org/mule/i18n/x-messages.properties or any other location on the classpath.
To access the messages of your own resource bundle, you create a subclass of MessageFactory as follows:
public class MyMessages extends MessageFactory
{
// getBundlePath puts together the correct path (META-INF/services/org/mule/i18n/my-messages.properties)
private static final String BUNDLE_PATH = getBundlePath("my");
public static Message errorMessageOne()
{
return createMessage(BUNDLE_PATH, 1);
}
public static Message anotherErrorMessage(Object param1, Object param2)
{
createMessage(BUNDLE_PATH, 2, param1, param2);
}
}To load a message from this bundle, pass in the resource bundle name as follows:
Message m = MyMessages.anotherErrorMessage("one", "two");
System.out.println(m.toString());This loads the message with ID 2 from x-messages.properties, formats the message with the parameters "one" and "two", and prints out the message to System.out as follows:
Error message with 2 parameters; param one and param two