Tapestry
  1. Tapestry
  2. TAPESTRY-881

Allow global i18n bundle location to be customized

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.1.1
    • Fix Version/s: 4.1.2
    • Component/s: Framework
    • Labels:
      None

      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

        Activity

        Hide
        Jesse Kuhnert added a comment -

        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.

        Show
        Jesse Kuhnert added a comment - 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.
        Hide
        Matt Raible added a comment -

        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!

        Show
        Matt Raible added a comment - 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!
        Hide
        Jesse Kuhnert added a comment -

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

        Show
        Jesse Kuhnert added a comment - 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..)
        Hide
        Matt Raible added a comment -

        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?

        Show
        Matt Raible added a comment - 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?
        Hide
        Matt Raible added a comment -

        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"/>

        Show
        Matt Raible added a comment - 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"/>
        Hide
        Mike Perham added a comment -

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

        Show
        Mike Perham added a comment - I just ran into this too. I guess I have to separate my java l10n and my tapestry l10n.
        Hide
        Mike Perham added a comment -

        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.

        Show
        Mike Perham added a comment - 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.
        Hide
        Matt Raible added a comment -

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

        Show
        Matt Raible added a comment - 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).
        Hide
        Jesse Kuhnert added a comment -

        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)

        Show
        Jesse Kuhnert added a comment - 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)
        Hide
        Matt Raible added a comment -

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

        Show
        Matt Raible added a comment - Any update on this? Also, will this feature be in Tapestry 5?
        Hide
        Jesse Kuhnert added a comment -

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

        Show
        Jesse Kuhnert added a comment - I think I'm going to need a more specific example of exactly where these Properties files are located when the application is running.
        Hide
        Matt Raible added a comment -

        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.

        Show
        Matt Raible added a comment - 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.
        Hide
        Jesse Kuhnert added a comment -

        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.

        Show
        Jesse Kuhnert added a comment - 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.
        Hide
        Matt Raible added a comment -

        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.

        Show
        Matt Raible added a comment - 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.
        Hide
        Jesse Kuhnert added a comment -

        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?

        Show
        Jesse Kuhnert added a comment - 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?
        Hide
        Matt Raible added a comment -

        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)

        Show
        Matt Raible added a comment - 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)
        Hide
        Jesse Kuhnert added a comment -

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

        Show
        Jesse Kuhnert added a comment - Sheww...Ok everything works as requested now, besides multiple message property names.

          People

          • Assignee:
            Jesse Kuhnert
            Reporter:
            Matt Raible
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development