Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I18N support in jooby. #755

Closed
thomasguo opened this issue May 4, 2017 · 6 comments
Closed

I18N support in jooby. #755

thomasguo opened this issue May 4, 2017 · 6 comments

Comments

@thomasguo
Copy link

Hi @jknack ,

I searched the whole online documentation of Jooby and didn't find content about i18n. Is there any built-in support for i18n in Jooby? Could you please provide some hints or suggestion path to do i18n in my jooby application? Thanks.

@jknack
Copy link
Member

jknack commented May 4, 2017

i18n is/should-be a template engine concern. which template engine are you?

@thomasguo
Copy link
Author

thomasguo commented May 4, 2017

Yes you are right, mostly it is a template engine concern. I am going to choose one from Freemarker and Pebble. I haven't seen information about i18n in Freemarker's documentation. Pebble provides a function i18n(basename, key, args...), which works well. But I don't like to specify the resource bundle basename for every i18n function call in template. I prefer it like i18n(key, args...) because I hope:

  1. Template authors should't care the resource bundle basename. She only needs to know the unique message keys.
  2. End user can specify what locale to use from the UI and system should remember this setting in following requests via cookie, session... something like that. SpringMVC works this way if I am not wrong.
  3. Further, I wish to split my large application into many small subApp/modules vertically. Every subApp has its own message bundle files with different subApp-related names. Wherever in template files we just need to call i18n(key, args...) to retrive the messages. Besides, in routes we could call similar class mthod to get localized messages when necessary.

That's why I post this issue/request. If Jooby doesn't provide this support on framework level, I would have to implement it on application level, or maybe in the form of an jooby extension module.

Would appreciate to have your suggestion. Thanks.

@jknack
Copy link
Member

jknack commented May 4, 2017

Good points.

I implemented an i18n application with handlebars.java and jooby. It was a mix of request local variable and cookie.

A generic module which expose locale to request local variable will be a good addition. Locale might come from cookie, accept-lang header, etc..

@thomasguo
Copy link
Author

Hi @jknack,
I wrote some code for this to organize all resource bundles, and wrote an pebble extension to add a new function named message(key, params). So far so good. But then I found it is impossible to get the dynamic locale information within the function code, beceause the template object was created with a fix locale. I checked the source code of class org.jooby.pebble.PebbleRenderer and saw the code is:
template.evaluate(writer, model);
I think we'd better use the other evaluate method with 3 parameters:
PebbleTemplate.evaluate(Writer writer, Map<String, Object> context, Locale locale),
so that I could retrieve the locale information from pebble function execution context.

So, I proposal that Jooby should provide some built-in support for i18n. Briefly it can dynamically parse locale information from client-side request, store it as a request or session variable, and pass it to the view engine(not limited to Pebble) before rendering. With this supoport we can easily make i18n extensions for all kind of template engines.

@jknack
Copy link
Member

jknack commented May 24, 2017

Going to update pebble (and any other engine with built-in support for locale object).

This is how will works:

firstNonNull(locals.get("locale"), req.locale(), app.locale())

If you do nothing locale is resolved against the Accept-Language header (if present) or fallback to application.lang property.

If none of those works for you, you can set a req local attribute:

use("*", (req, rsp, chain) -> {
  Locale locale = ...; //compute locale from cookie, header or whatever you want
  req.set("locale", locale);
});

Will send a pull request shortly, so you can review it

@thomasguo
Copy link
Author

Perfect. Looking forward to use it in the coming release.

@jknack jknack closed this as completed in 157d6d8 May 24, 2017
jknack added a commit that referenced this issue May 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants