On 12/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
Shale has a utility class that would deal with this problem (as well as provide programmatic access to the "resource bundle as a map" metaphor, in phases besides Render Response):
http://struts.apache.org/struts-shale/shale-core/apidocs/org/apache/shale/util/LoadBundle.html
The class is modelled as a pure POJO so it is easy to configure as a managed bean (as illustrated in the JavaDocs).
For resources that need to be updated, I've seen similar approaches to the above, but which read the content from a database instead ... either on demand for every request, or periodically checking for updates. Standard Java resource bundles don't help you much there, because they are cached. An additional alternative would be to look at the Commons Resources package ( http://jakarta.apache.org/commons/resources/), which tries to abstract out the storage technique used, and could support updatable resources.
Craig
In fact, I do think that we should all stop using f:loadBundle right
away - it causes too many problems, e.g. with partial page rendering.
Shale has a utility class that would deal with this problem (as well as provide programmatic access to the "resource bundle as a map" metaphor, in phases besides Render Response):
http://struts.apache.org/struts-shale/shale-core/apidocs/org/apache/shale/util/LoadBundle.html
The class is modelled as a pure POJO so it is easy to configure as a managed bean (as illustrated in the JavaDocs).
Instead I'd use some managed-bean for i18n, and retrieve the values
for this managed bean from the database, just as you pointed out. I
have to solve this for a project I'm currently working on - but I
haven't worked out all the use-cases you mention here.
For resources that need to be updated, I've seen similar approaches to the above, but which read the content from a database instead ... either on demand for every request, or periodically checking for updates. Standard Java resource bundles don't help you much there, because they are cached. An additional alternative would be to look at the Commons Resources package ( http://jakarta.apache.org/commons/resources/), which tries to abstract out the storage technique used, and could support updatable resources.
regards,
Martin
Craig
On 12/28/05, Mike Duffy < [EMAIL PROTECTED]> wrote:
> I am sending this [OT] topic to this list in hopes that someone has already solved this design
> problem.
>
> What is the best way to do dynamic updates for internationalization?
>
> Suppose you had a drop-down list and the labels for this list are translated into other locales;
> also, suppose that administrators can dynamically update this list. When an administrator adds a
> new item they would of course be adding the label in the language of their current locale.
>
> It is a given that there would need to a work-flow for translating the values. The basic question
> is, what type of structure should be used to store the values. It seems like a properties file
> would be inadequate and that it would be necessary to store the values in a database.
>
> As a very simple example, if there was a drop-down list for types of "Pets" containing "cat",
> "dog", "fish", etc. and a user added a new value, "hamster", the label would go into the data
> structure in the language of the user's current locale and a translator would be notified to make
> the translations for the other locales. Until the translations are complete, the default value
> could be the original value entered or the system could default to not display any value until the
> translations were complete. There are most likely many other related issues that I have not yet
> thought of.
>
> Please share your thoughts.
>
> Mike
>
>
>
>
>
> __________________________________________
> Yahoo! DSL – Something to write home about.
> Just $16.99/mo. or less.
> dsl.yahoo.com
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
