Allow global i18n bundle location to be customized

• Key: TAPESTRY-881
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Jesse Kuhnert
• Reporter: Matt Raible
• Component/s: Framework
• Affects Version/s: 4.1.1
• Fix Version/s: 4.1.2

Description

The current mechanism for specifying a global i18n resource bundle is not very flexible.

http://jakarta.apache.org/tapestry/UsersGuide/localization.html#localization.namespace

It requires you to name your i18n bundles the same as your .application file. Furthermore, it requires that your bundles be places in the WEB-INF directory. Most other web frameworks (and Java applications in general) require you to have the ResourceBundle somewhere in your classpath (generally in the root - WEB-INF/classes).

1. I think the root of the classpath should be the default location - even if you're using the ".application name matches i18n name" mechanism.
2. It should be possible to customize the name of the file. Possibly something like the following in your .application file:

<property name="org.apache.tapestry.global-properties" value="ApplicationResources"/> -> points to WEB-INF/classes/ApplicationResources.properties (and others with _locale.properties
<property name="org.apache.tapestry.global-properties" value="com.myapplication.web.messages"/> - points to /WEB-INF/classes/com/myapplication/web/messages.properties

Comments

[Jesse Kuhnert]

Hope you're happy... ;)

Documentation is coming as well, but the new meta configurable property name is "org.apache.tapestry.namespace-properties-name".

The classpath is search by default in addition to WEB-INF/ for the application spec file as well.

[Matt Raible]

I'm happy all right! We're should I send the Guinness to? If it's fixed in 4.1.1, do you have a target date for this release? Since I'm all Maven-2-repo-ed these days, I'm more interested in when it'll hit a repo. Thanks Jesse!

[Jesse Kuhnert]

Heh. It should be out in about an hour. I still need to update the docs and then deploy. (An hour is probably longer than I'll need but better to be safe I guess..)

[Matt Raible]

I'm using 4.1.1 (downloaded it today) and this doesn't seem to work. In my .application file I have:

<meta key="org.apache.tapestry.namespace-properties-name" value="ApplicationResources"/>

And in src/main/resources, I have a bunch of ApplicationResources*.properties i18n bundles. SiteMesh seems to work fine at resolving the locale, but Tapestry shows things like:

[MAINMENU.HEADING]

[MAINMENU.MESSAGE]

Any ideas?

[Matt Raible]

Is it possible to add the ability to support multiple global bundles? I'd like to have a messages.properties for labels, messages and such and an errors.properties for validation errors.

Example:

<meta key="org.apache.tapestry.namespace-properties-name" value="messages,errors"/>

[Mike Perham]

I just ran into this too. I guess I have to separate my java l10n and my tapestry l10n. :(

[Mike Perham]

Note this is only true in the war's application. For code packaged as a tapestry library in a separate jar, you can share the l10n files. It's only Tapestry 4.0's insistence on using servlet context resources with the appliction that causes a problem.

[Matt Raible]

Is there a timeline on the 4.1.2 release? Or maybe getting this fixed in a snapshot release? We're hoping to release AppFuse 2.0 in the next few weeks and w/o this fix, our Tapestry support is not as good as I'd like it to be. Currently, we have duplicate i18n files (in WEB-INF for Tapestry and WEB-INF/classes for SiteMesh and tests).

[Jesse Kuhnert]

I hadn't noticed these messages before sorry. Assuming I don't have any local pending changes (I don't think I do) I'll fix this next. (which means this week for sure)

[Matt Raible]

Any update on this? Also, will this feature be in Tapestry 5?

[Jesse Kuhnert]

I think I'm going to need a more specific example of exactly where these Properties files are located when the application is running.

[Matt Raible]

Most web frameworks load i18n bundles from the classpath, just like a regular ol' ResourceBundle. With JSP/JSTL, JSF, Struts 1/2 and Spring MVC, my resource bundles are located in WEB-INF/classes.

Right now, Tapestry allows a global (single) ResourceBundle, but the name must match the name of the ApplicationServlet and it must be located in the WEB-INF directory. I'd like to customize both the name and location - so I can load ApplicationResources*.properties from WEB-INF/classes.

[Jesse Kuhnert]

So....are talking about directly in the literal path WEB-INF/classes/ApplicationResources<foo>.properties or is there a more elegant solution others are using? Doesn't seem very hard to support this, just need to make sure I know exactly what is expected.

[Matt Raible]

Yes, that's exactly what I'm talking about - I'm not looking for a more elegant solution at this point. However, most frameworks allow global bundles to be anywhere in the classpath.

[Jesse Kuhnert]

Anywhere in the classpath so long as you specify where or literally "Foo.properties" will be found no matter where you stick it in the classpath?

[Matt Raible]

So as long as you specify where. For example:

ApplicationResources -> WEB-INF/classes/ApplicationResources.properties, as well as any other locales (ApplicationResources_es.properties, etc)
com.foo.ApplicationResources > WEB-INF/classes/com/foo/ApplicationResources.properties (as well as other locales)

[Jesse Kuhnert]

Sheww...Ok everything works as requested now, besides multiple message property names.