Support for page and snippet level localization

[Hugo Palma]

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 ?

[Timothy Perrett]

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

> --
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
>
>

[Naftoli Gugenheim]

You can just have separate index html files for different locales, and when the user goes to /index (or / I suppose) Lift selects the correct one.

-------------------------------------

[Timothy Perrett]

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.

Cheers, Tim

[Hugo Palma]

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.

[James Matlik]

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...@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...

[Timothy Perrett]

Some of the code needs adjusting because of an API change since I
wrote this, but this should give you a good overview of lifts
localization and templating:

http://is.gd/81uAi

Cheers, Tim

On Feb 9, 5:29 pm, James Matlik <james.mat...@gmail.com> wrote:
> 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
>

[Timothy Perrett]

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

[Timothy Perrett]

Come to think of it - if you really wanted to have a resource bundle
for each page... you could do that using the resource bundle factories
I listed earlier.

Cheers, Tim

[Hugo Palma]

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.

[Timothy Perrett]

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

[Hugo Palma]

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 ?

[Timothy Perrett]

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

[Naftoli Gugenheim]

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...@gmail.com> wrote:

> liftweb+u...@googlegroups.com<liftweb%2Bunsu...@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 lif...@googlegroups.com.
> To unsubscribe from this group, send email to

> liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>

[Hugo Palma]

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.

[Naftoli Gugenheim]

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?

> <liftweb%2Bunsu...@googlegroups.com<liftweb%252Buns...@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 lif...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > liftweb+u...@googlegroups.com<liftweb%2Bunsu...@googlegroups.com>

> <liftweb%2Bunsu...@googlegroups.com<liftweb%252Buns...@googlegroups.com>

[David Pollak]

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.

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

[cody koeninger]

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.

[Hugo Palma]

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 ?

--

[Hugo Palma]

On Wed, Feb 10, 2010 at 17:28, David Pollak <feeder.of...@gmail.com> 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.

[cody koeninger]

On Feb 10, 12:11 pm, Hugo Palma <hugo.m.pa...@gmail.com> wrote:
> 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 ?

Yes

May seem like a hack, but on the other hand I honestly don't
understand how people deal with mostly textual websites that consist
of templates with nothing but e.g. <wicket:message key="foo"> all over
the place. Webapps with a limited amount of text, sure, but making up
new property keys for every paragraph. . .are you serious?

> If so, where do you keep the translated text at dev time ? Is it still on
> resource bundles ?
>

Yes, translated text is in resource bundles, used by the script that
does the xml translation
(well, we keep a .po version as well as the java properties file,
because of existing gettext toolchain, but that's incidental)