portletspec3
  1. portletspec3
  2. PORTLETSPEC3-6

Errata: Clarification for section "PLT.25.8.2 Locales supported by the Portlet"

    Details

      Description

      Referring to the working document "JavaTM Portlet Specification, working document 3 (22.04.13)",
      there is a mistake under section PLT.25.8.2 at line 15. RFC 1766 specifies the locale format
      as a language tag that is composed of subtags separated by hyphens, rather than underscore
      characters. The text should be corrected as follows:

      Original:
      -------------------------
      The supported locales declared in the deployment descriptor should follow the
      lang_COUNTRY_variant format as defined by RFC 1766
      (http://www.faqs.org/rfcs/rfc1766.html).
      -------------------------

      Corrected:
      -------------------------
      The supported locales declared in the deployment descriptor should follow the
      lang-COUNTRY-variant format as defined by RFC 1766
      (http://www.faqs.org/rfcs/rfc1766.html).
      -------------------------

        Issue Links

          Activity

          Hide
          msnicklous added a comment -

          Fix discussed on 20130723. Revisit with additional information on locale handling in Java 7.

          Show
          msnicklous added a comment - Fix discussed on 20130723. Revisit with additional information on locale handling in Java 7.
          Hide
          Ed Burns added a comment -

          I've been working on a JSF issue that manifests with IE10 in Chinese locales. The is related to the new "script" subtag in the language tag spec as defined by Internet Best Current Practice 47. <http://tools.ietf.org/html/bcp47>. We are going to have to revise the JSF spec to take this into account. Basically, we need to specify how language tags that include the "script" subtag are converted to Locales that may not.

          This is an issue for JSF 2.2 because we do not require JavaSE 7, and JavaSE 6 does not support these script subtags at all.

          For JSF 2.3, we'll have to revise that language to allow for the script subtag.

          Show
          Ed Burns added a comment - I've been working on a JSF issue that manifests with IE10 in Chinese locales. The is related to the new "script" subtag in the language tag spec as defined by Internet Best Current Practice 47. < http://tools.ietf.org/html/bcp47 >. We are going to have to revise the JSF spec to take this into account. Basically, we need to specify how language tags that include the "script" subtag are converted to Locales that may not. This is an issue for JSF 2.2 because we do not require JavaSE 7, and JavaSE 6 does not support these script subtags at all. For JSF 2.3, we'll have to revise that language to allow for the script subtag.
          Hide
          keilw added a comment -

          While individual JSRs like JSF 2.2 or JBatch (352) indeed require a minimum version of Java (EE) 6, the basis for JSR 362 is said to be Java EE 7, hence the improvements to Locale in Java 7 should be available. Or is there anything on the detail page that's wrong or shall be applied differently?

          Show
          keilw added a comment - While individual JSRs like JSF 2.2 or JBatch (352) indeed require a minimum version of Java (EE) 6, the basis for JSR 362 is said to be Java EE 7, hence the improvements to Locale in Java 7 should be available. Or is there anything on the detail page that's wrong or shall be applied differently?
          Hide
          msnicklous added a comment - - edited

          In light of the the new Locale support in Java 7, it seems that we should move in that direction also. A description similar to the following might be appropriate:

          (updated on 7 Aug 13 to remove the statement regarding compatibility in the text proposal, and to add some additional new information after the proposal)

          The supported locales declared in the deployment descriptor must be specified as a valid language tag according to IETF BCP 47, "Tags for Identifying Languages". A valid language tag is composed of subtags separated by hyphens ("-", ABNF [RFC4234] %x2D) as delimiters. The language tag must begin with the primary language subtag and may be followed by subsequent optional subtags. If specified, the subtags must appear in the order shown below.

          • language - ISO 639 alpha-2 or alpha-3 language code, or registered language subtags up to 8 alpha letters (for future enhancements).
          • script - ISO 15924 alpha-4 script code. You can find a full list of valid script codes in the IANA Language Subtag Registry (search for "Type: script").
          • country (region) - ISO 3166 alpha-2 country code or UN M.49 numeric-3 area code. You can find a full list of valid country and region codes in the IANA Language Subtag Registry (search for "Type: region").
          • variant - Any arbitrary value used to indicate a variation of a Locale.
          • extensions - A map from single character keys to string values, indicating extensions apart from language identification. The extensions in Locale implement the semantics and syntax of BCP 47 extension subtags and private use subtags.

          A valid language tag example would be "ja-JP-SJIS". This tag contains "ja" as the mandatory primary language tag, followed by the "JP" country and the "SJIS" variant subtags. The optional script and extensions subtags are not specified.

          See IETF BCP 47, "Tags for Identifying Languages" for a complete description. See the descriptions of the Java SE 7 Locale, Locale.Builder, and ResourceBundle classes for additional information on how Java processes IETF BCP 47 language tag information.

          Note that this will require a change to the portlet descriptor v3.0 schema as well.

          Backward compatibility will be retained since v2.0 portlet descriptors will be validated with the v2.0 schema, so the old language tag formato for 2.0 portlets will continue to be accepted.

          Show
          msnicklous added a comment - - edited In light of the the new Locale support in Java 7, it seems that we should move in that direction also. A description similar to the following might be appropriate: (updated on 7 Aug 13 to remove the statement regarding compatibility in the text proposal, and to add some additional new information after the proposal) The supported locales declared in the deployment descriptor must be specified as a valid language tag according to IETF BCP 47, "Tags for Identifying Languages". A valid language tag is composed of subtags separated by hyphens ("-", ABNF [RFC4234] %x2D) as delimiters. The language tag must begin with the primary language subtag and may be followed by subsequent optional subtags. If specified, the subtags must appear in the order shown below. language - ISO 639 alpha-2 or alpha-3 language code, or registered language subtags up to 8 alpha letters (for future enhancements). script - ISO 15924 alpha-4 script code. You can find a full list of valid script codes in the IANA Language Subtag Registry (search for "Type: script"). country (region) - ISO 3166 alpha-2 country code or UN M.49 numeric-3 area code. You can find a full list of valid country and region codes in the IANA Language Subtag Registry (search for "Type: region"). variant - Any arbitrary value used to indicate a variation of a Locale. extensions - A map from single character keys to string values, indicating extensions apart from language identification. The extensions in Locale implement the semantics and syntax of BCP 47 extension subtags and private use subtags. A valid language tag example would be "ja-JP-SJIS". This tag contains "ja" as the mandatory primary language tag, followed by the "JP" country and the "SJIS" variant subtags. The optional script and extensions subtags are not specified. See IETF BCP 47, "Tags for Identifying Languages" for a complete description. See the descriptions of the Java SE 7 Locale, Locale.Builder, and ResourceBundle classes for additional information on how Java processes IETF BCP 47 language tag information. Note that this will require a change to the portlet descriptor v3.0 schema as well. Backward compatibility will be retained since v2.0 portlet descriptors will be validated with the v2.0 schema, so the old language tag formato for 2.0 portlets will continue to be accepted.
          Hide
          msnicklous added a comment -

          done.

          Show
          msnicklous added a comment - done.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: