On Wed, Feb 10, 2010 at 17:28, David Pollak <[email protected]>wrote:
> 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)). > But this way you would be moving the translated text from the resource bundle into the html right ? I guess it's a design choice but i prefer to keep my html free of localized text and keep all that in resource bundles. > > 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. > I am using the existing facilities, that's why i started this thread. I wanted to make sure that i wasn't missing anything or taking the wrong approach before trying to implement such a solution into Lift. > > On Wed, Feb 10, 2010 at 2:48 AM, Hugo Palma <[email protected]>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 <[email protected]>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<[email protected]> 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 <[email protected] >>> >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 <[email protected]> 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 <[email protected]> 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 [email protected]. >>> > > > > To unsubscribe from this group, send email to >>> > [email protected]<liftweb%[email protected]> >>> <liftweb%[email protected]<liftweb%[email protected]> >>> > >>> > . >>> > > > > 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 [email protected]. >>> > To unsubscribe from this group, send email to >>> > [email protected]<liftweb%[email protected]> >>> <liftweb%[email protected]<liftweb%[email protected]> >>> > >>> > . >>> > 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 [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<liftweb%[email protected]> >>> . >>> 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 [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<liftweb%[email protected]> >>> . >>> 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 [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<liftweb%[email protected]> >> . >> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<liftweb%[email protected]> > . > 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 [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.
