I understand, just trying to share some of my own experience and ideas. So, should i create an issue for further discussion or do we just let it be ?
On Tue, Feb 9, 2010 at 18:43, Timothy Perrett <timo...@getintheloop.eu>wrote: > 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<liftweb%2bunsubscr...@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> >> . >> 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<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. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
