[PORTLETSPEC3-6] Errata: Clarification for section "PLT.25.8.2 Locales supported by the Portlet" Created: 02/May/13  Updated: 22/Jan/16  Resolved: 09/Jul/13

Status: Closed
Project: portletspec3
Component/s: JSR 286 Portlet Specification Errata
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
is related to JAVASERVERFACES_SPEC_PUBLIC-1210 Account for BCP47 Closed


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:

The supported locales declared in the deployment descriptor should follow the
lang_COUNTRY_variant format as defined by RFC 1766

The supported locales declared in the deployment descriptor should follow the
lang-COUNTRY-variant format as defined by RFC 1766

Comment by julien_viet [ 10/May/13 ]

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">

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 '_'.


Comment by msnicklous [ 13/May/13 ]

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

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 ...)

Comment by Neil Griffin [ 13/May/13 ]

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

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

Comment by msnicklous [ 09/Jul/13 ]

Updated spec document accordingly.

Comment by Neil Griffin [ 23/Jul/13 ]

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:

And here is the URL for the 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.

Comment by msnicklous [ 26/Jul/13 ]

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

Comment by Ed Burns [ 26/Jul/13 ]

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.

Comment by keilw [ 29/Jul/13 ]

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?

Comment by msnicklous [ 30/Jul/13 ]

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.

Comment by msnicklous [ 22/Jan/16 ]


Generated at Wed Feb 22 04:20:24 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.