Reminder: i18n strawman

[Stanley M. Ho]

Bryan Atsatt 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