Home/ Questions/Q 6580703
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T16:03:39+00:00

As an example, the default i18n message in message.properties for blank fields is: default.blank.message=Property

  • 0

As an example, the default i18n message in message.properties for blank fields is:

default.blank.message=Property [{0}] of class [{1}] cannot be blank

If one wants to customize this with a given class (e.g. user) and field (e.g. login), one does

user.login.blank=Your login name must be specified

with the “.message” suffix left-off. This threw me off for a bit (as I had it in there and it didn’t work), so I’m wondering if there is a specific purpose to how the “.message” suffix is used / not used in message.properties?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There seem to be quite a bit of mismatches in the use of message customization, beyond just the use of “.message”. See example below*.

    I believe the grails software developers might include a comment at the top of the message.properties file, guiding the user to look at the right place for defining the custom error messages, e.g. in the Constraints quick reference list, http://www.grails.org/doc/latest/ref/Constraints/matches.html. The top level Contraints section in the quick reference does not include the error code field names, but might it be useful to add there.

    *For example, the default match failure is “default.doesnt.match.message”, but the specific error is, for example, “user.login.matches.invalid”.

    • 0