Appreciate where you are coming from, however, the defaults are working quite 
well so perhaps it would be frugal to break some other boxed configurations 
into lift-localization or something... Such as page related resource bundles.

Needs some thinking, but its certainly possible. Lift is extremely flexible in 
this regard.

Cheers, Tim

On 9 Feb 2010, at 17:52, Hugo Palma 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.
> > > > 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.
> 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.
> 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.
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.

Reply via email to