Radically improved localization, soon in Lift near you

[David Pollak]

Folks,

I've put a patch for issue 635 (per-page localization) on review-board.

Basically, this change uses the templating system available to hold resources.  The advantage is that all resources are stored in XML (and encoded in UTF-8) and can trivially contain tags, sub-tags, etc.

See https://www.assembla.com/wiki/show/liftweb/Localization

Further, you can have per-page localization which can be maintained along-side the page templates.

Thanks,

david

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics

[Heiko Seeberger]

David,

Looks pretty cool!

What happens to the "old style" resource handling, i.e. properties files?

Thanks,

Heiko

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

--
Heiko Seeberger

Company: weiglewilczek.com
Blog: heikoseeberger.name
Follow me: twitter.com/hseeberger
OSGi on Scala: scalamodules.org
Lift, the simply functional web framework: liftweb.net
Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org

[philip]

Hi David,

I have some requirements for the localization for the application I'm
doing as per my customer requirements and the system.

1. The language strings may be updated at runtime. How could this be
implemented? I just need a way to reload from the language string
files at runtime, refresh the cache.
2. The keys of the language strings may be language strings
themselves, ie the key maybe in Chinese and different values in other
languages (but the same value in Chinese as the key). Key may contain
any UTF-8 characters and even html or special characters.
3. Context dependent translation, one string identified by a single
key in English may have two different French translations because of
where the English string was used on the page. In English it didn't
matter, but in French it mattered and the string had to be different
even though in English its the same. This was a real case I had when
working in England and customizing some USA software for European
market.

Can this satisfy my requirements or I can hook something in with
functions?

Thanks, Philip


On Nov 28, 9:56 am, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> Folks,
>
> I've put a patch for issue 635 (per-page localization) on review-board.
>
> Basically, this change uses the templating system available to hold
> resources.  The advantage is that all resources are stored in XML (and
> encoded in UTF-8) and can trivially contain tags, sub-tags, etc.
>

> Seehttps://www.assembla.com/wiki/show/liftweb/Localization

>
> Further, you can have per-page localization which can be maintained
> along-side the page templates.
>
> Thanks,
>
> david
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

[David Pollak]

On Sun, Nov 28, 2010 at 11:59 PM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:

David,

Looks pretty cool!

What happens to the "old style" resource handling, i.e. properties files?

They continue to be supported and will continue to work the same way they always did.
 

[David Pollak]

On Mon, Nov 29, 2010 at 3:46 AM, philip <phili...@gmail.com> wrote:

Hi David,

I have some requirements for  the localization for the application I'm
doing as per my customer requirements and the system.

1. The language strings may be updated at runtime. How could this be
implemented? I just need a way to reload from the language string
files at runtime, refresh the cache.

In non-development mode, the caches are not flushable.

However, you can hook into Lift and supply your own resource bundles via LiftRules.resourceBundleFactory.  Basically:

LiftRules.resourceBundleFactory.append {
  case (_, locale) => return bundle for locale
}
 

2. The keys of the language strings may be language strings
themselves, ie the key maybe in Chinese and different values in other
languages (but the same value in Chinese as the key). Key may contain
any UTF-8 characters and even html or special characters.

In general, this should "just work"  All the ResourceBundle (see http://download.oracle.com/javase/1.4.2/docs/api/java/util/ResourceBundle.html ) keys are Strings.  They can be any value Java String.
 

3. Context dependent translation, one string identified by a single
key in English may have two different French translations because of
where the English string was used on the page. In English it didn't
matter, but in French it mattered and the string had to be different
even though in English its the same. This was a real case I had when
working in England and customizing some USA software for European
market.

There's no way I can think of to achieve this.  You've either got key/value where there's a single value for each key or your don't.  Sorry.
 

Can this satisfy my requirements or I can hook something in with
functions?

Thanks, Philip


On Nov 28, 9:56 am, David Pollak <feeder.of.the.be...@gmail.com>
wrote:

> Folks,
>
> I've put a patch for issue 635 (per-page localization) on review-board.
>
> Basically, this change uses the templating system available to hold
> resources.  The advantage is that all resources are stored in XML (and
> encoded in UTF-8) and can trivially contain tags, sub-tags, etc.
>

> Seehttps://www.assembla.com/wiki/show/liftweb/Localization

>
> Further, you can have per-page localization which can be maintained
> along-side the page templates.
>
> Thanks,
>
> david
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

> Follow me:http://twitter.com/dpp
> Blog:http://goodstuff.im
> 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 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.

--

Lift, the simply functional web framework http://liftweb.net

Beginning Scala http://www.apress.com/book/view/1430219890

[Heiko Seeberger]

David,

Could you please change the lookup to the Java resource bundle way, i.e. _de_DE instead of _deDE?

Thanks,

Heiko

On 28 November 2010 02:56, David Pollak <feeder.of...@gmail.com> wrote:

--

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.

--

[David Pollak]

On Tue, Nov 30, 2010 at 7:22 AM, Heiko Seeberger <heiko.s...@googlemail.com> wrote:

David,

Could you please change the lookup to the Java resource bundle way, i.e. _de_DE instead of _deDE?

Sorry, that would break the existing mechanism that Lift uses to locate templates.