Home/ Questions/Q 8436423
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-10T07:10:29+00:00

Internalization in Play2 can be done with Message.get(home.title) and language files. What about when

  • 0

Internalization in Play2 can be done with Message.get("home.title") and language files. What about when you internalizate a page full of textual content and not just one specific header or link?

For example doing Messagefile for a long page representing e.g. product info:

_First header_ 
Some paragraphs of text
...
_Tenth header_
Tenth paragraph and more text*

Messagefile

a)
product.info = "<many paragraphs of text including headers>"

or splitting one page into html elements

b) 

   product.info.h1 = "<first header>"
   product.info.p1 = "<first para>"
   product.info.p2 = "<2nd para>"

For me both solutions doesn’t sound right. In first having a vast value for a single key seems bad convention and in latter separating a single page into dozens of keys doesn’t sound good either.

Big websites often follow the convention http://www.site.com/en-us/product/1 of having the language in the URL. So the question is, how do i do in this way and is doing in this way a better way at all? I could easily end up not just translating to dozen languages but doing also dozen times layout changes.

I could use global codesnippets using Messagefile for elements that have a little text and doesn’t change often e.g. navigation /view/global/header/somenavbar.scala.html but then i end up only having a complex folder structure.

Another way, a best practise, in Play 2 for internalization than messagefile?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Take a look to the Joscha Feth’s solution in play_authenticate Java sample.

    There are templates for emails in 3 languages for email confirmation, password reseting etc.

    Template for each ‘type’ of email && each language is kept in single file ie:

    And for each ‘type’ there is an ‘parent’ template, which contains a condition (common Scala’s match check the Tags section of template doc) which returns rendered view depending on detected language:

    Finally, yes, at the beginning I also thought that some kind of madness, but believe me, that technique can be useful. There’s field for further improvements I think. Maybe it would be better to move the language conditioning to the controller, hm I think that depends on many factors and it will be great if you’ll find a time to investigate this topic.

    • 0