Reading Time: 2 minutes
In this blog, I will demonstrate how your application can support different languages using Play Framework 2.6.0
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In this blog, I will demonstrate how your application can support different languages using Play Framework 2.6.0
What is Application/Website Internationalization ?
Application/Website Internationalization can be defined as a process of developing and designing an application that supports not only single language but also different languages so that it can be easily adapted by the users from any language, region, or geography. It ensures that the code base of your application is flexible enough to serve a new audience without rewriting the complete code or keeps text separate from the code base.
Let us start the implementation step by step:
1. Specifying Languages for your application
In order to specify Languages for your application, you need Language tags, which are specially formatted strings that indicate specific languages such as “en” for English, “fr” for French, a specific regional dialect of a language such as “en-AU” for English as used in Australia.
First, you need to specify the languages in the conf/application.conf file, Languages tags will be used to create play.api.i18n.Lang instances.
play.i18n.langs = [“en”, “fr”]
2. Externalizing Messages
Externalizing Messages in the conf/messages.xxx files. Here we have two language-specific message files messages.en for English and message.fr for French. If you don’t specify any message file for any specific language than the default conf/messages file matches all the languages.
you can provide messages in each language specific file like this,
default.message = Play Framework Example
3. Message with Controller
Created a controller MySupportController that extends I18nSupport trait.
The I18nSupport trait adds following methods to a Request:
- request.messages return the instance of Messages, using implicit MessagesApi.
- request.lang returns the preferred Lang, using implicit MessagesApi
messagesApi.preferred method, by using this method the preferred language is extracted from the Accept-Language header and matching one of the MessageApi supported languages.
The i18nsupport trait also adds two language cookies supported methods to Result:
- result.withLang(lang: Lang) is used to set the language for future request by storing it in the cookie.
- result.clearingLang is used to discard the language cookie set by withLang.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| class MySupportController @Inject()(component: ControllerComponents, | |
| langs: Langs) extends AbstractController(component) with I18nSupport { | |
| val lang: Lang = langs.availables.head | |
| implicit val messages: Messages = MessagesImpl(lang, messagesApi) | |
| def index = Action { implicit request => | |
| val messages: Messages = messagesApi.preferred(request) // get the messages for the given request | |
| val message: String = messages("default.message") | |
| Ok(views.html.index(message)) | |
| } | |
| def homePageInFrench = Action { | |
| Redirect("/").withLang(Lang("fr")) // set french language in the Play's language cookie for future requests | |
| } | |
| def homePageWithDefaultLang = Action { | |
| Redirect("/").clearingLang // discarding the language cookie set by withLang | |
| } | |
| } |
4. Messages with Twirl Template
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| @(message: String, style: String = "scala")(implicit messages: MessagesProvider) | |
| @defining(play.core.PlayVersion.current) { version => | |
| <section> | |
| <div class="wrapper"> | |
| @if(messages.messages.lang.language.equals("en")) { | |
| <a class = "button" href="@routes.MySupportController.homePageInFrench()">fr</a> | |
| } else { | |
| <a class = "button" href="@routes.MySupportController.homePageWithDefaultLang()">en</a> | |
| } | |
| </div> | |
| </section> | |
| <div id="content" class="wrapper doc"> | |
| <article> | |
| <h1>@message</h1> | |
| <h2>@messages.messages("home.title")</h2> | |
| </article> | |
| </div> | |
| } |
Here Twirl templates take MessageProvider, and it is assumed that a MessageProvider is passed into the template as an implicit parameter.
Well explained
Reblogged this on Play!ng with Scala.