This topic has not yet been written. The content below is from the topic description.
2.2.4. Message interpolation As we will see in Chapter 3, Creating custom constraints each constraint definition must define a default message descriptor. This message can be overridden at declaration time using the message attribute of the constraint. You can see this in Example 2.13, “Driver”. This message descriptors get interpolated when a constraint validation fails using the configured MessageInterpolator. The interpolator will try to resolve any message parameters, meaning string literals enclosed in braces. In order to resolve these parameters Hibernate Validator's default MessageInterpolator first recursively resolves parameters against a custom ResourceBundle called ValidationMessages.properties at the root of the classpath (It is up to you to create this file). If no further replacements are possible against the custom bundle the default ResourceBundle under /org/hibernate/validator/ValidationMessages.properties gets evaluated. If a replacement occurs against the default bundle the algorithm looks again at the custom bundle (and so on). Once no further replacements against these two resource bundles are possible remaining parameters are getting resolved against the attributes of the constraint to be validated. Since the braces { and } have special meaning in the messages they need to be escaped if they are used literally. The following The following rules apply: \{ is considered as the literal { \} is considered as the literal } \\ is considered as the literal \ If the default message interpolator does not fit your requirements it is possible to plug a custom MessageInterpolator when the ValidatorFactory gets created. This can be seen in Chapter 5, Bootstrapping.