Grails Internationalization

Grails - Internationalization
Nakul Ashish Pant

Agenda
Introduction
Why Internationalization
Localizing Messages
Using Parameterized Messages
messageSource / g.message
Summary

Introduction
Web applications are really easy to distribute.Web Applications need to adapt
and behave differently under different situations
For a request from Spain the application might want to display messages in
spanish and in english when request is made from New York
The adaptations made by the application may involve more complexity than
simply displaying different versions of text. An application may need to impose
different business rules based on the origin of a particular request.

Let’s see what Grails has in
its arsenal for this problem?

Localizing Messages
One way of providing this capability is to have a separate version of the
application for each language you want to target. That approach has lots of
problems.
Maintaining all those different versions and trying to keep them all in sync
would be an awful lot of work. A much better idea is to have a single version of
the application that is flexible enough to display messages in various
languages using localized messages.

Localizing messages Continued ..
To support localized messages in your Grails application, you should be defining all
user messages in a properties file.
User messages should not be hard-coded in GSP pages, GSP templates, or
anywhere else.
Having messages in a properties file allows you to maintain all of them all in a single
place.
It also lets you take advantage of the localization capabilities provided by Grails.

I18n Directory Structure Continued ..
When a Grails app is created, the project includes a number of localized property
files in the grails-app/i18n/ directory
The messages.properties file in the grails-app/i18n/ directory contains default
validation messages in English. These messages are used when validation fails in a
domain class or command object.
In addition to the default messages.properties file, this directory has several other
properties files that contain the same messages in other languages. For example,
“es” is the language code for Spanish, so messages_es.properties contains
validation messages in Spanish.

I18n Directory Structure Continued ..
Example of a properties file - application.properties
app.grails.version=2.4.4
app.name=smartly
app.servlet.version=3.0
app.version=0.1
Property files are plain text files, which contain name-value pairs.

Retrieving Messages
// GroovyMessages.groovy
def messages = ResourceBundle.getBundle('messages')
def appName = messages.getString('app.name')
println "application name is ${appName}"

Retrieving Messages - message Tag
<body>
...
<g:message code="app.smartly.welcome"/>
... </body>
The code attribute tells the message tag which property value should be retrieved.
By default, Grails will decide which version of the property file to use based on the
locale of the current web request.
A simple way to test your Grails application’s localization is to include a request
parameter named lang and assign it a valid language code, such as “es” for
Spanish

Using URLMapping
A URL Mapping for Localization
class UrlMappings {
static mappings = {
"/store/$lang"(controller:'store')
// ...
}
}
This mapping will map all requests to a URL such as http://localhost:
8080/smartly/en/ or http://localhost:8080/smartly/es/, where “en” and “es” could be
any valid language code.

Using Parameterized Messages
Often a user message may consist of more than simple static text.
The message may need to include some data that is not known until runtime.
Defining a Parameterized Message
# messages.properties
gtunes.purchased.songs=You have purchased ({0}) songs.

Continued
java.text.MessageFormat class uses a zero-based index
{0} in the message is a placeholder for the value of the first parameter.
If the message had multiple parameters, they would be represented in the
value of the message with placeholders like {0}, {1}, {2}, and so on.
The message tag supports an optional parameter named args, and if that
parameter is assigned a value, its value will be treated as a list of
parameters that need to be applied to the message.

Continued
gtunes.purchased.songs=You have purchased [{0}] songs
<div>
<g:message code="gtunes.purchased.songs" args="[97]"/>
</div>

Using messageSource
Grails provides a bean named messageSource that can be injected into any
Grails artefact, including controllers, taglibs, other beans, and so on.
The messageSource bean is an instance of the org.springframework.context.
MessageSource interface
This interface defines three overloaded versions of the getMessage method for
retrieving messages from the source.

Using messageSource Continued ..
String getMessage(String code, Object[] args, Locale locale)
String getMessage(String code, Object[] args, String defaultMessage, Locale locale)
String getMessage(MessageSourceResolvable resolvable, Locale locale)
Since the messageSource bean participates in Grails’s dependency autowiring
process, all you need to do to get a reference to the bean is declare a property named
messageSource in your Grails artefact.

package com.gtunes
class StoreService {
def messageSource
def someServiceMethod() {
def msg = messageSource.getMessage('gtunes.my.music', null, null)
// ...
}
...
}
Note that the second and third arguments are null. The second argument is an Object
[], which would be used to pass parameters to a parameterized message. The third
argument is a java.util.Locale, which may be specified to retrieve a message for any
Locale other than the default Locale for this request.

Example -
class StoreService {
def messageSource
def someServiceMethod() {
def msg = messageSource.getMessage('gtunes.my.music',null,Locale.ITALIAN)
// …
}
...
}

Using g.message
From within a Controller or TagLib artefact, a simpler way to retrieve messages
is to invoke the
message GSP tag as a method on the special g namespace variable available
in those artefacts
def index() {
def msg = g.message(code:'gtunes.my.music')
} //All tag libraries are accessible using the very same technique.

Summary
Retrieving messages from a property file is a snap in a Grails application. The
message tag is very easy to access and use from GSP pages and GSP
templates. The messageSource bean is easily accessible from wherever the
application may need it. All of these enhancements are built on top of proven
and well-understood Java-platform tools, including java.text. MessageFormat
and org.springframework.context.MessageSource.

Grails Internationalization

Recommended

Recommended

More Related Content

Similar to Grails Internationalization

Similar to Grails Internationalization (20)

Recently uploaded

Recently uploaded (20)

Grails Internationalization