i18n error: controller and templates use different implicit Langs about playframework HOT 8 CLOSED

Julian's answer @ http://stackoverflow.com/a/9734832 seems reasonably complete:

The play.api.i18n.Messages(key) function takes an additional implicit parameter of type Lang. So when you write Messages("foo") it is expanded to Messages("foo")(l), where l is a value of type Lang taken from the current implicit scope.

There’s always an available default implicit lang (which has a low priority), using your jvm default locale.

But when you are inside a Controller, an implicit value with a higher priority can be found if there is an implicit request. This value looks in the Accept-Language header of the request.

When you are inside a template, the default implicit lang will be used unless your template imports another implicit lang.

That’s why, in your example, messages computed from the Controller use the Accept-Language request header and messages computed from the View use your jvm default locale.

If you add an implicit parameter of type Lang to your template, this parameter will have a higher priority than the default lang and will be used to compute messages:

@(langInController: Lang, msg:String)(implicit request: RequestHeader, lang: Lang)

<div>Lang from controller: @langInController, Message: @msg</div>
<div>Message from view: @Messages("error.required")</div>

When you’ll call the template from a Controller action, its implicit lang will be passed, so the same lang will be used by both your Views and your Controllers.

And his comments go further into detail:

Why can't this be the default behavior? I would imagine most apps would want the implicit Land in the view to be the same one used in the controller. – Ike Mar 16 '12 at 15:01

Making this the default behavior would require to differentiate between templates intended to be used with Java controllers (which can’t provide implicit values) and templates intended to be used with Scala controllers. – Julien Richard-Foy Mar 16 '12 at 15:32

from playframework.

The question is what is to be done here: update the documentation? Differentiate between templates used with Java controllers? It's not clear what the verification is here.

from playframework.

I believe that the solution here is actually quite simple. We can make the implicit conversion that converts an implicit RequestHeader to Lang available in templates.

As for how this works in Java, currently we already differentiate between templates used with Java and Scala, they have different imports. So for Java templates, they get an implicit Lang that comes from the play.mvc.Http.Context.lang, provided by PlayMagicForJava.

So the solution is to create a PlayMagicForScala, factor out the play.api.mvc.Controller.lang implicit conversion so that it is available both there and in PlayMagicForScala, and add PlayMagicForScala to the default templatesImport setting for Scala projects.

Whoever implements this, make sure there are tests that test the following permutations:

• Template takes no parameters
• Template takes an implicit Lang - test that the lang is whatever was passed in to the implicit lang
• Template takes an implicit RequestHeader, test that the lang is whatever came from the request header
• Template takes an implicit Lang and an implicit RequestHeader, test that the lang is whatever was passed in through the implicit Lang.

from playframework.

See also #2628 for performance problems related to Java's current approach.

from playframework.

Also related #3782

from playframework.

Should be ok for me

from playframework.

I believe this should be addressed by the messages refactoring in #6438

from playframework.

Fixed by removal of the default lang in #7319

from playframework.