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
          julien_viet added a comment -

          I believe that such change would mean portlet container behavior changes but also breakage of existing applications using the current format.

          We should keep the current behavior. We should remove the mention of RFC 1766 that cannot be respected and instead accept a definition that is correct.

          I reviewed the web-facesconfig_2_0.xsd configuration schema that accept both syntaxes and specifies:

          <xsd:complexType name="faces-config-supported-localeType">
          <xsd:annotation>
          <xsd:documentation>

          The "supported-locale" element allows authors to declare
          which locales are supported in this application instance.

          It must be specified as :language:[_:country:[_:variant:]]
          without the colons, for example "ja_JP_SJIS". The
          separators between the segments may be '-' or '_'.

          </xsd:documentation>
          </xsd:annotation>
          <xsd:simpleContent>

          Show
          julien_viet added a comment - I believe that such change would mean portlet container behavior changes but also breakage of existing applications using the current format. We should keep the current behavior. We should remove the mention of RFC 1766 that cannot be respected and instead accept a definition that is correct. I reviewed the web-facesconfig_2_0.xsd configuration schema that accept both syntaxes and specifies: <xsd:complexType name="faces-config-supported-localeType"> <xsd:annotation> <xsd:documentation> The "supported-locale" element allows authors to declare which locales are supported in this application instance. It must be specified as :language:[_:country: [_:variant:] ] without the colons, for example "ja_JP_SJIS". The separators between the segments may be '-' or '_'. </xsd:documentation> </xsd:annotation> <xsd:simpleContent>
          Hide
          msnicklous added a comment -

          Ok, I agree that we can't break existing portlets. In light of this, I would formulate the text as follows.

          Corrected:
          -------------------------
          The supported locales declared in the deployment descriptor should be specified as :language:[:country:[_:variant:]] without the colons, for example "ja_JP_SJIS". The separators between the segments may be '-' or ''.
          -------------------------

          Question – the current text uses “should” … shouldn't it be “must”? (... declared in the deployment descriptor must be specified ...)

          Show
          msnicklous added a comment - Ok, I agree that we can't break existing portlets. In light of this, I would formulate the text as follows. Corrected: ------------------------- The supported locales declared in the deployment descriptor should be specified as :language:[ :country: [_:variant:] ] without the colons, for example "ja_JP_SJIS". The separators between the segments may be '-' or ' '. ------------------------- Question – the current text uses “should” … shouldn't it be “must”? (... declared in the deployment descriptor must be specified ...)
          Hide
          Neil Griffin added a comment -

          @julien: Excellent detective work with the faces-config schema!

          @msnicklous: I agree that the word "must" is necessary when describing firm requirements like this.

          Show
          Neil Griffin added a comment - @julien: Excellent detective work with the faces-config schema! @msnicklous: I agree that the word "must" is necessary when describing firm requirements like this.
          Hide
          msnicklous added a comment -

          Updated spec document accordingly.

          Show
          msnicklous added a comment - Updated spec document accordingly.
          Hide
          Neil Griffin added a comment -

          I think during the call we decided to re-open this issue for discussion to see what the Servlet API supports.

          This page lists all of the Java EE 7 XSD files:
          http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html

          And here is the URL for the web-common_3_1.xsd
          http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/web-common_3_1.xsd

          Inside the file it contains documentation for "localeType" and "locale-encoding-mappingType" elements. If I understand the docs correctly, then I think that both dash and underscore are permitted.

          Show
          Neil Griffin added a comment - I think during the call we decided to re-open this issue for discussion to see what the Servlet API supports. This page lists all of the Java EE 7 XSD files: http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/index.html And here is the URL for the web-common_3_1.xsd http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/javaee/web-common_3_1.xsd Inside the file it contains documentation for "localeType" and "locale-encoding-mappingType" elements. If I understand the docs correctly, then I think that both dash and underscore are permitted.
          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.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: