Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.2
    • Component/s: Resources
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      887
    • Status Whiteboard:
      Hide

      size_medium importance_medium

      Show
      size_medium importance_medium

      Description

      https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=548
      describes that the current attempt at providing localizable resources is
      irretrievably broken.

      In addition to the issues noted in issue 548, note that the proposed scheme
      doesn't play nicely with versioning. If someone versions a library, that
      particular library version may have support for different locales. That is, the
      library version should be resolved first, then the locale.

      Here is a proposed enhancement (which depends on the implementation of
      https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=885).

      In 2.6.1.3, allow resource identifiers of the form

      [libraryName/][libraryVersion/][locale/]resourceName[/resourceVersion]

      where locale is a regex of the form [A-Za-z]

      {2}(_[A-Za-z]{2}

      (_[A-Za-z]+)?)?

      In 2.6.1.4 function deriveResourceId, require inspection of the directories

      libraryName/language_locale_variant
      libraryName/language_locale
      libraryName/language
      libraryName

      for locating a resource, in the case that localePrefix is null.

      This behavior is what people would expect from a Java SE ResourceBundle.

      Note that this is a compatible change. Anyone who wants the old behavior simply
      adds a ResourceHandler.LOCALE_PREFIX to the application's message bundle. Anyone
      who wants the new behavior doesn't do that but instead adds locale directories.
      If someone does neither, there is no change in behavior.

        Activity

        No work has yet been logged on this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            cayhorstmann
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: