I think this idea is weak. Lift supports localized pages (e.g., index_en_US.html, index_it.html, etc.) Any page-level localization can be accomplished by writing a localized page. Any snippet-level localization can be achieved by passing localized XHTML as parameters to the snippet. Further, as Tim pointed out, there are ways to customize localization based on current state (which includes the current Req(uest)).
I'd suggest using Lift and using the existing facilities for localization. If they are lacking *after you use them* and you find that you are writing additional helpers, then we can see how your helpers integrate into Lift. On Wed, Feb 10, 2010 at 2:48 AM, Hugo Palma <hugo.m.pa...@gmail.com> wrote: > I think a simple inheritance concept would work just fine. > We could have: > > application resource bundle (what Lift has now) -> page resource bundle -> > snippet resource bundle > > This would mean that every snippet would inherit the the resource bundle of > the page where it's being rendered. So yes, the same snippet could translate > the same key to a different value depending on the page where it's rendered. > > Does that make sense to you ? > In the past i've found such an approach very natural and really useful. > > > On Wed, Feb 10, 2010 at 06:38, Naftoli Gugenheim <naftoli...@gmail.com>wrote: > >> If the same snippet is used by two pages you would want two separate >> resource bundles to be used for the same snippet? >> >> ------------------------------------- >> Hugo Palma<hugo.m.pa...@gmail.com> wrote: >> >> So what you're saying is that a page can include a bunch of snippets and >> that's why it doesn't be an advantage to have page resource bundles ? >> >> I'm sorry but i don't see why. >> I'm not sure how people are using resource bundles with Lift now but the >> way >> i would do it would be to create a resource bundle for each page that >> would >> have the properties that are specific to that page and then i would have >> one >> or more bundles with properties that would be used in several >> pages across the application. >> >> I think this makes sense in large applications because it's just a natural >> way of organizing your translated text. >> I realize this is possible with Lift now, but it has the following >> problems: >> >> - Even if you separate in bundles the properties are globally available. >> There's no bundle "namespace" concept. For example, i might want to have >> the >> property page-name with the current page name. And if i'm on the home page >> i >> want it to translate to "Home" and if i'm on the search page i want it to >> translate to "Search". This could be possible with this. >> >> - I have to register every single resource bundle in >> LiftRules.resourceNames. Although not critical this could easily be >> replace >> with automatic bindle discovery like i suggested. >> >> On Tue, Feb 9, 2010 at 17:38, Timothy Perrett <timo...@getintheloop.eu >> >wrote: >> >> > The analogy would be MVC controllers... the index method has an index >> > page and an index resource bundle. Within Lift, we dont use >> > controllers, so there is nothing stopping you calling a whole bunch of >> > snippets on a single page - thus, there would be no single "page" >> > resource bundle (that is, it wouldn't buy you anything IMHO) as >> > different snippets might share localised text or whatever. I guess im >> > just trying to say things are not silo'ed in Lift. >> > >> > Does that add some more clarity to my statement? >> > >> > Cheers, Tim >> > >> > On Feb 9, 2:47 pm, Hugo Palma <hugo.m.pa...@gmail.com> wrote: >> > > Sorry Tim but i don't quite understand what you mean by "page is >> > > scoped to a single snippet" and that invalidates that you have a >> > > resource bundle per page. Sorry is this is clear to everyone else but >> > > i'm new with Lift so i'm still grasping basic concepts. >> > > >> > > On Feb 8, 10:49 pm, Timothy Perrett <timo...@getintheloop.eu> wrote: >> > > >> > > >> > > >> > > > That wouldn't work for Lift as it assumes a page is scoped to a >> single >> > snippet. It works with Tapestry because its an MVC framework. >> > > >> > > > Lift is *not* MVC. >> > > >> > > > Have you seen LiftRules.resourceBundleFactories ? >> > > >> > > > Cheers, Tim >> > > >> > > > On 8 Feb 2010, at 22:11, Hugo Palma wrote: >> > > >> > > > > Lift only support global resource bundles, i think it would be >> very >> > > > > useful if page and snipped level resource bundles were supported. >> > > > > For example, if i have a page "index" it would automatically have >> > > > > access to the index<locale>.properties_ bundle. Obviously this >> bundle >> > > > > would not be accessible from any other page. >> > > >> > > > > I come from an Apache Tapestry background that has page and >> component >> > > > > level localization and it proved very useful. >> > > >> > > > > What do you guys think about this ? >> > > >> > > > > -- >> > > > > You received this message because you are subscribed to the Google >> > Groups "Lift" group. >> > > > > To post to this group, send email to lift...@googlegroups.com. >> > > > > To unsubscribe from this group, send email to >> > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com> >> <liftweb%2bunsubscr...@googlegroups.com<liftweb%252bunsubscr...@googlegroups.com> >> > >> > . >> > > > > For more options, visit this group athttp:// >> > groups.google.com/group/liftweb?hl=en. >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "Lift" group. >> > To post to this group, send email to lift...@googlegroups.com. >> > To unsubscribe from this group, send email to >> > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com> >> <liftweb%2bunsubscr...@googlegroups.com<liftweb%252bunsubscr...@googlegroups.com> >> > >> > . >> > For more options, visit this group at >> > http://groups.google.com/group/liftweb?hl=en. >> > >> > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/liftweb?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Lift" group. >> To post to this group, send email to lift...@googlegroups.com. >> To unsubscribe from this group, send email to >> liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/liftweb?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Lift" group. > To post to this group, send email to lift...@googlegroups.com. > To unsubscribe from this group, send email to > liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/liftweb?hl=en. > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
