[Bese-devel] [ucw] i18n

[Marco Baringer]

before i explain the i18n stuff i need to explain what's been going on 
with the rerl api lately. As anyone who has tried to load (let alone 
compile) ucw from patch-104 onwards knows: NOTHING EVER WORKED! sorry, 
it was painfull but neccessary, i probably should have done the work on 
a seperate branch, but when i started it was just a minor touchup here 
and there and the change kind of snowballed from there.

We now have a real protocol which defines how the various "phases" of 
the request-response loop work. The protocol is defined in the aptly 
named src/rerl/procotocl.lisp, methods are defined in terms of generic 
"application", "server", "session" abjocts and implementations are 
providide via "standard-server", "standard-application", ... objects. 
This protocol is designed to allow changes to request-response handling 
to be done in a modular and clean way without having to go in and 
change the ucw core. the i18n application is the test of this protocol.

Now, i18n. Our goal is to make it easy to handle requests differently 
based an the languages the client prefers. We have a class 
i18n-application (sub class of standard-application) which, at 
request-context creation time, inspects the request and choses, among 
the locales the application knows about, the "best" one (based on the 
client's accept-language header). The collest thing (from a design 
point of view) is that this i18n stuff is done by defining 2 new 
clasess and 2 new methods, in theory i could have done without access 
to the ucw source code.

Currently the only visible change is that when you call render-template 
we first look for a locale specific version of the template, if that 
fails we fall back to a generic un specified version. We would really 
like this voodoo to happen when a tal:include tag is found, i'm 
currently looking into how to best redefine that tag. I've decided that 
people who use the yaclml macros are own their own, they can always get 
at the current locale vio the context, but ucw isn't going to do much 
more code side.

Next on the list is a collection of tags for formatting and parsing 
dates and numbers (preferably integrated with the ucw:accessor 
attributes), then we'll see about pluging into resource bundles to 
provide translated messages nested inside templates without having to 
create a whole now template.

Since i've learned my lesson i'm leaving the ucw--dev branch alone and 
all this work is being done on ucw at common-lisp.net/ucw--i18n--0.1 
branch.

this isn't really ready enough that i can say "GO! HACK IT 'TILL IT 
BREAKS!", however if anyone has any comments to make regarding the 
integration of i18n and ucw i'd like to hear them now, as opposed to 
months from now.
--
Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
	-Leonard Cohen