Translate according to domain

[GoingGlobal]

Hi,

We'd like to run our AppEngine app on two sites (say en.example.com
and fr.example.com), with the first being in English and the second
being in French. Both sites are running against/updating the same
datastore.

I'd like to be able to call something like Lang.get("string_key") to
lookup the text in the appropriate language for the site the current
request is coming from. In JSP code, I can find the domain to
determine the language but then I'd have to pass the language
( Lang.get("en","string_key") ) or pass the request
(Lang.get(request,"string_key"). I don't like that because it's more
work and makes my JSP less readable, but it'll work. But what about
Java code deep inside some other classes without access to the
request?

I could set a static var in Lang to remember the language when a
request first comes in, but that'd only work for single-threaded
Instances and we're multithreaded for performance/cost reasons.

Alternatively, I thought if I could make sure that different App
Engine JVM Instances are used for the different domains, then at
initialization time, it could detect the domain and determine the
language to translate to and save it to a static var in Lang. I
haven't seen anything to suggest that Instances are be reserved for
certain domains, so I doubt this is possible.

Anyone have any advice or other ideas?

Thanks.

[Brandon Wirtz]

You Deploy to sub domain in the AppsForDomain Interface,

You detect the URL from the request headers.

You serve the appropriate page. Pretty standard Mult-tenant set up.

Hi,

Thanks.

--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To post to this group, send email to google-a...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengi...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.

[N. Rosencrantz]

I do this with python 2.7 + Jinja2 with messages.po files. The same app can serve a Brazilian domain in Brazilian Portuguese and an Indian domain in plain English.
I don't use namespaces for this however since namespaces AFAIK you can only select one while a sometimes want to display for all "namespaces" (domains)
So I do the localization low-level and I must also think of that decimal formatting, date formatting and timezones differ within my app and it's this that I'm nowadays working on a solution for.
The library I use for internationalization is the i18n from webapp2_extras and the undocumented approach I use is loading i18n to the Jinja2 library:

jinja_environment.install_gettext_translations(i18n)

Then my logic is basically just checking the host for the domain

            host = self.request.host
            if host.find('.br') > 0:
              i18n.get_i18n().set_locale('pt-br')              

#otherwise default to English

You can get language / locale from HTTP get, HTTP session, HTTP header och cookie and I posted on SO about it.
When you know serverside what locale it is, you also pass it on via javascript to the javascript components if you have.

Thank you

[GoingGlobal]

I should have bolded the main question: "What about Java code deep

inside some other classes without access to the request?"

Everything else in the post is discussing possible ways of dealing
with that.

[GoingGlobal]

In Java, you don't have access to the request except in the JSP or
Servlet classes. Other, deeper, logic classes, don't have access to
the request unless it's passed to them (which would get messy very
quickly). What do other Java programmers do for this?

[GoingGlobal]

I'm now thinking about recording the Locale in a hash map using the
Thread ID as a key when the request first comes in, so that later, any
code can lookup the Locale again and translate appropriately.

[Simon Knott]

Hi,

Can't you just use a static ThreadLocal to hold the Locale, then access that from wherever you need to?  It's what I use for holding the Namespace for an incoming request, to make it available to the rest of the code.

Cheers,

Simon

[GoingGlobal]

Thanks Simon, I didn't know about ThreadLocal. It's exactly what I
needed and actually kind of expected that functionality within Thread.