15 Internationalization 2.4.4

See the light - agile, industrial strength, rapid web application development made easy

(Quick Reference) # 15 Internationalization - Reference Documentation Authors: Graeme Rocher, Peter Ledbrook, Marc Palmer, Jeff Brown, Luke Daley, Burt Beckwith, Lari Hotari Version: 2.4.4 ## Table of Contents # 15 Internationalization Grails supports Internationalization (i18n) out of the box by leveraging the underlying Spring MVC internationalization support. With Grails you are able to customize the text that appears in a view based on the user's Locale. To quote the javadoc for the Locale class: A Locale object represents a specific geographical, political, or cultural region. An operation that requires a Locale to perform its task is called locale-sensitive and uses the Locale to tailor information for the user. For example, displaying a number is a locale-sensitive operation--the number should be formatted according to the customs/conventions of the user's native country, region, or culture. A Locale is made up of a language code and a country code. For example "en_US" is the code for US English, whilst "en_GB" is the code for British English. ## 15.1 Understanding Message Bundles Now that you have an idea of locales, to use them in Grails you create message bundle file containing the different languages that you wish to render. Message bundles in Grails are located inside the `grails-app/i18n` directory and are simple Java properties files. Each bundle starts with the name `messages` by convention and ends with the locale. Grails ships with several message bundles for a whole range of languages within the `grails-app/i18n` directory. For example: messages.properties messages_da.properties messages_de.properties messages_es.properties messages_fr.properties ... By default Grails looks in `messages.properties` for messages unless the user has specified a locale. You can create your own message bundle by simply creating a new properties file that ends with the locale you are interested. For example `messages_en_GB.properties` for British English. ## 15.2 Changing Locales By default the user locale is detected from the incoming `Accept-Language` header. However, you can provide users the capability to switch locales by simply passing a parameter called `lang` to Grails as a request parameter:
    /book/list?lang=es
Grails will automatically switch the user's locale and store it in a cookie so subsequent requests will have the new header. ## 15.3 Reading Messages #### Reading Messages in the View The most common place that you need messages is inside the view. Use the message tag for this:
    <g:message code="my.localized.content" />
As long as you have a key in your `messages.properties` (with appropriate locale suffix) such as the one below then Grails will look up the message:
    my.localized.content=Hola, Me llamo John. Hoy es domingo.
Messages can also include arguments, for example:
    <g:message code="my.localized.content" args="${ ['Juan', 'lunes'] }" />
The message declaration specifies positional parameters which are dynamically specified:
    my.localized.content=Hola, Me llamo {0}. Hoy es {1}.
#### Reading Messages in Controllers and Tag Libraries It's simple to read messages in a controller since you can invoke tags as methods:
    def show() {
        def msg = message(code: "my.localized.content", args: ['Juan', 'lunes'])
    }
The same technique can be used in tag libraries, but if your tag library uses a custom namespace then you must prefix the call with `g.`:
    def myTag = { attrs, body ->
        def msg = g.message(code: "my.localized.content", args: ['Juan', 'lunes'])
    }
## 15.4 Scaffolding and i18n Grails scaffolding templates for controllers and views are fully i18n-aware. The GSPs use the message tag for labels, buttons etc. and controller `flash` messages use i18n to resolve locale-specific messages. The scaffolding includes locale specific labels for domain classes and domain fields. For example, if you have a `Book` domain class with a `title` field:
    class Book {
        String title
    }
The scaffolding will use labels with the following keys:
    book.label = Libro
    book.title.label = Título del libro
You can use this property pattern if you'd like or come up with one of your own. There is nothing special about the use of the word `label` as part of the key other than it's the convention used by the scaffolding. | Quick Reference (hide)