How does Grails support internationalization (i18n)?

Grails inherits Java's standard resource-bundle mechanism for i18n, storing translated text in .properties files under grails-app/i18n, with a base messages.properties file and locale-specific variants (like messages_fr.properties) that Grails automatically selects based on the incoming request's locale.

Rather than hardcoding text in controllers or views, application code looks up a message by key, and GSP templates typically pull translated text through the <g:message code="..."/> tag, which resolves the key against whichever locale-specific properties file matches the current request — falling back to the base messages.properties if no matching translation exists for the current locale. The same message-resolution mechanism also powers validation error messages, so a domain class's constraint violations can be displayed to the user in their own language automatically, provided the corresponding translated message keys exist.

Because this is built directly on the standard Java ResourceBundle mechanism, tooling and conventions familiar from any Java internationalization work carry over directly, rather than Grails inventing its own separate i18n system from scratch.