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 On Mar 2, 4:43 pm, Jon Hancock <[email protected]> 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? > > thanks, Jon > > On Mar 2, 7:59 am, Derek Chen-Becker <[email protected]> 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 <[email protected]> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
