Geert,
It so happens that we discussed this on IRC 2 days ago:
http://servlet.uwyn.com/drone/log/bevinbot/rife/20051128 (check
around 17:05)
Even if i18n is mainly an element's responsability, i like the idea to
be able to get some very specific resource at template level with sth
like "[!V 'L10N:bundlename:key"
My proposal went into a similar direction, except instead of having a
'detect_client_locale' property, I was thinking of having a
'localeProvider' property. This would be an instance of a class that
implements the LocaleProvider interface and have one method:
List<Locale> getLocale(ElementSupport activeElement). RIFE could then
include a ClientLocaleProvider class that obtains the list of locales
that the browser provides as a suggestion. It also opens up the
possibility of any kind of possible locale negotiation.
A LocaleProvider interface is a good idea.
What about the possibility to use a scope argument:
- request i.e. the client locales as above
- application, see L10N_DEFAULT_LANGUAGE ("en" by default) and
L10N_DEFAULT_COUNTRY (null by default)
- template, sth only known at the template level (the "page" scope of
fmt tags in JSP), with a default value which can be set by configuration
- session, a value explicitely given by the user
with:
- by default, the scope would be "request", but this default behavior
can be change (e.g. to "session" if session locales are used) either:
* by a function LocaleProvider.setDefaultScope
* or by a configuration parameter
- when available, application and template locales would be ever supplied
- with session scope, request locales would be supplied if available
- order of priority: application<template<request<session
Regards
Pierre
_______________________________________________
Rife-users mailing list
Rife-users@uwyn.com
http://www.uwyn.com/mailman/listinfo/rife-users
