Reminder: i18n strawman

[Stanley M. Ho]

On Wed, 16 May 2007 11:15:57 -0700, Bryan Atsatt <bryan.atsatt at ORACLE.COM>
wrote:

>ListResourceBundle cannot be demoted to second-class citizen status in
>the module system (Perhaps you haven't seen my earlier response?).

Yes, I agreed it's important for us to support ListResourceBundle.

>There is a solution to the split package problem, and, while it does
>change the development model slightly, I think that is in line with the
>more significant model change of moving to a module system...
>
>Introduce a package naming convention for resource bundles deployed as
>modules. The convention would allow ResourceBundle.getBundle() to easily
>map from the "base" name to the actual bundle package name.
>
>For example, if we introduce the convention that resource bundle "base"
>names are mapped such that "resources" is appended to the package name,
>then calling ResourceBundle.getBundle with:
>
>   "com.acme.MyResources"
>
>Would actually search for resources with the base name:
>
>   "com.acme.resources.MyResources"
>
>thus sidestepping the split package issue.
>
>Yes, this requires developers to actually define their resources using
>this naming convention, but I don't see that as a significant burden.
>Especially when you consider the benefit of not having to package all
>translations in the primary module.
>
>To avoid potential package name collisions, we should consider using a
>more distinct name than simply "resources", e.g.:
>
>   "com.acme.resource_bundle.MyResources"
>   "com.acme.module_resources.MyResources"
>   "com.acme._resources_.MyResources"
>
>// Bryan

I was under the assumption that we didn't want to change the way developers
define their resources. That said, I am fine with using some packaging
naming convention to sidestep the split package issue.

If we go down this path, I think we will need to expand Bryan's suggestion a
bit. The ResourceBundle API may search multiple resource modules in order to
look up the resources (from more restrictive locales to less restrictive
locales), so it is important for resources in the resource modules for each
locale to have unique package name to avoid potential conflict regardless
the lookup order. e.g.

   "com.acme_en.MyResources"
   "com.acme_ja.MyResources_ja"
   "com.acme_fr.MyResources_fr"
   "com.acme_fr_CH.MyResources_fr_CH"

Note that the locale information is repeated twice. If we want to simplify
it further, we can require the locale information to be specified only as
part of the package name of the resource, but not as part of the filename of
the resource:

   "com.acme_en.MyResources"
   "com.acme_ja.MyResources"
   "com.acme_fr.MyResources"
   "com.acme_fr_CH.MyResources"

- Stanley

P.S. This is another repost. My email problems with jcp.org continue, and
please ignore if you receive more than one copy of my reply.