Re: [Lift] Re: Support for page and snippet level localization
Interesting. What would an example where two pages in the same locale should have different values for the same key used by the same snippet? - Hugo Palmahugo.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.comwrote: If the same snippet is used by two pages you would want two separate resource bundles to be used for the same snippet? - Hugo Palmahugo.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 indexlocale.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.comliftweb%2bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%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.comliftweb%2bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com . For more options, visit this group at
Re: [Lift] Re: Support for page and snippet level localization
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.comwrote: If the same snippet is used by two pages you would want two separate resource bundles to be used for the same snippet? - Hugo Palmahugo.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 indexlocale.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.comliftweb%2bunsubscr...@googlegroups.com liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com . For
Re: [Lift] Re: Support for page and snippet level localization
I'm not sure i understand your solution, so your build process find an index.html and replaces all the text there to all the languages and creates the appropriate index_lang.html file ? If so, where do you keep the translated text at dev time ? Is it still on resource bundles ? On Wed, Feb 10, 2010 at 17:46, cody koeninger c...@koeninger.org wrote: On Feb 8, 5:07 pm, Timothy Perrett timo...@getintheloop.eu wrote: Generally I find that to be only of use when needed specific adjustments to templates. For instance, english vs german... the german language is significantly more verbose so requires different div heights etc sometimes. Its not generally a strategy one adopts for their entire localisation scheme. We're using the built-in localized template lookup (index_fr.html) in production, and I find it to be better than any alternative I've seen across any web framework. As you noted, most pages aren't actually different, so our build process is scripted to translate index.html to index_fr.html in the target directory. Our source tree isn't cluttered with _fr versions of everything, our templates aren't filled with loc or |/l tags everywhere . . . so far it seems like a win-win to me. Only minor snag we've run into with lift localization was that S.? isn't really parseable by xgettext, so we just used a wrapper function with a different character. To the OP, like David said, try what's there first, chances are it will meet your needs. -- 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.comliftweb%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.
Re: [Lift] Re: Support for page and snippet level localization
On Wed, Feb 10, 2010 at 17:28, David Pollak feeder.of.the.be...@gmail.comwrote: 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 hugo.m.pa...@gmail.comwrote: 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.comwrote: If the same snippet is used by two pages you would want two separate resource bundles to be used for the same snippet? - Hugo Palmahugo.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 indexlocale.properties_ bundle. Obviously this bundle would not be accessible from any other page. I come from an Apache Tapestry
Re: [Lift] Re: Support for page and snippet level localization
I would also be very interested in more detail on this topic. I've been toying with designs with a variety of technologies (a self-driven academic activity this far) to formulate how a massively multilingual site (upwards of 12 languages) could be implemented. I've not had much luck understanding the capabilities and limitations (perhaps a better word is boundaries) of lift's templating system for both language support and performance/resource usage for huge quantities of content. A bit off topic but related... There has been talk before on the mailing list about creating a CMS. Has anything come of that? Regards, James On Feb 9, 2010 9:47 AM, 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 ... 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... -- 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.
Re: [Lift] Re: Support for page and snippet level localization
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.euwrote: 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 indexlocale.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.comliftweb%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.comliftweb%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.
Re: [Lift] Re: Support for page and snippet level localization
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 indexlocale.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.
Re: [Lift] Re: Support for page and snippet level localization
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.euwrote: 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.euwrote: 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 indexlocale.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.comliftweb%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.comliftweb%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
Re: [Lift] Re: Support for page and snippet level localization
mm im not sure who would take this on, as I think i've been doing most of the localisation stuff and I don't have capacity to do anything about this for quite some time unless it becomes an urgent priority. Any discussion must take place on this list, not on (or in) tickets, review board or otherwise. Right now, I think you could service the need yourself using locale calculator and resourceBundleFactories. To that end, the work we are talking about here is helpers rather than core functionality. Not to belittle it, as it could be quite useful - its just a case of working out what needs doing and where. Create a ticket in Assembla, mark it as webkit enhancement and assign it to me. I'll look at it, some when. Cheers, Tim On 9 Feb 2010, at 22:25, Hugo Palma wrote: 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 indexlocale.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
Re: [Lift] Re: Support for page and snippet level localization
If the same snippet is used by two pages you would want two separate resource bundles to be used for the same snippet? - Hugo Palmahugo.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.euwrote: 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 indexlocale.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.comliftweb%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.comliftweb%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. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
