Locale and languages

[Tim Perrett]

Guys,

Just working something through and would like a bit of input from
lifted :-)

Im debating how im going to store my locale data and present that
information to the user in a sensible way. Right now, im thinking of
using MappedLocale to hold locale type information in my database, and
then have a one-to-many (locale -> translation). This seems fairly
reasonable, but i've changed my mind several times now so would be
ever so grateful for some other input :-)

Cheers, Tim

[Derek Chen-Becker]

That seems reasonable, although IIRC it means that you need two queries to the database to fetch a translation using mapper strictly. Of course, you could use the raw SQL queries on DB to fetch things with one join.

Derek

[Jon Hancock]

I am also interested in locale strategies.
I would like to build a website which will be in Mandarin and
English. The English is mostly for my use as most users will see
mandarin. I expect it will be easiest to have most of my decorative
info (link names, static info) in the views themselves. The DB
content will be what it is (mostly mandarin), no need for multiple
copies.
I guess I first want to sniff the request (or maybe do a geo query on
the IP) and decide if I should serve up EN or CN views and
subsequently allow the user to click a preference (English or Chinese
link) to override my guesswork and set a cookie for the preference. I
do see how I would set the cookie. How to manage two sets of views I
do not see.
How have others done this with lift?

thanks, Jon

On Mar 2, 7:59 am, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
> That seems reasonable, although IIRC it means that you need two queries to
> the database to fetch a translation using mapper strictly. Of course, you
> could use the raw SQL queries on DB to fetch things with one join.
>
> Derek
>

[Tim Perrett]

Hi Jon,

I have a working implementation of this now :-)

To give you some background, we have a locale calculator in lift and
its default behavior looks at the incoming request headers to asses
what locale should be set. Whilst in normal operation this has no
affect on your application, it becomes extremely useful when you want
to localize based on a whole bunch of parameters. Check out the scala
docs for S here:

http://scala-tools.org/mvnsites/liftweb/lift-webkit/scaladocs/net/liftweb/http/S$object.html

Because java.util.Locale has really neat features for presenting
localized country names etc, i just use a something like:

S.locale.getDisplayName(S.locale) // => Might return "italiano" for
instance

As for the database content - I have a database backed resource bundle
subclass that feeds into an LRU cache when lift boots up. The bundle
then talks with the LRU cache to return the correct string.

Sorry if that doesnt make much sense! If anything is not clear, then
just post back and i'll try to me more succinct.

Thanks

Tim

[David Pollak]

On Mon, Mar 2, 2009 at 8:43 AM, Jon Hancock <shell...@gmail.com> wrote:

I am also interested in locale strategies.
I would like to build a website which will be in Mandarin and
English.  The English is mostly for my use as most users will see
mandarin.  I expect it will be easiest to have most of my decorative
info (link names, static info) in the views themselves.  The DB
content will be what it is (mostly mandarin), no need for multiple
copies.
I guess I first want to sniff the request (or maybe do a geo query on
the IP) and decide if I should serve up EN or CN views and
subsequently allow the user to click a preference (English or Chinese
link) to override my guesswork and set a cookie for the preference. I
do see how I would set the cookie.  How to manage two sets of views I
do not see.
How have others done this with lift?

First, there's the LiftRules.localeCalculator  This is a function that lets you determine the locale for the current request.  By default, the function just looks at the current request, but should be extended to check the current user, etc. for Locale.  This can be used with a cookie-based mechanism or some sort of user-who-has-logged-in state. (To add a cookie, use S.addCookie(Cookie))

Lift chooses the template based on the current locale.  So, if Lift is looking for "index" and the locale is en_US, Lift will look for index_en_US.html and then index_en.html and then index_US.html and then index.html.  So, you can put your index_en.html and index_cn.html templates in the directory and that's it.  See sites/example/src/main/webapp/lang_*.html

Thanks,

David


 

thanks, Jon

On Mar 2, 7:59 am, Derek Chen-Becker <dchenbec...@gmail.com> wrote:
> That seems reasonable, although IIRC it means that you need two queries to
> the database to fetch a translation using mapper strictly. Of course, you
> could use the raw SQL queries on DB to fetch things with one join.
>
> Derek
>

> On Sun, Mar 1, 2009 at 2:54 PM, Tim Perrett <timo...@getintheloop.eu> wrote:
>
> > Guys,
>
> > Just working something through and would like a bit of input from
> > lifted :-)
>
> > Im debating how im going to store my locale data and present that
> > information to the user in a sensible way. Right now, im thinking of
> > using MappedLocale to hold locale type information in my database, and
> > then have a one-to-many (locale -> translation). This seems fairly
> > reasonable, but i've changed my mind several times now so would be
> > ever so grateful for some other input :-)
>
> > Cheers, Tim

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp