On Wed, 24 Jun 2026 18:47:07 GMT, Justin Lu <[email protected]> wrote:

> This PR corrects Locale parsing logic for extra languages. The BCP syntax 
> enforces that extlangs may only follow `2*3 ALPHA` langs. This is also 
> reinforced by the syntax comment described in `LanguageTag.parse` (which is 
> based off the BNF). However, the current implementation does not respect 
> this, and allows extlangs to follow `4ALPHA` (future use) as well as 
> `5*8ALPHA` langs.
> 
> For example, `Locale.forLanguageTag("quux-bar").toLanguageTag()` returns the 
> extlang "bar" when it should return the lang "quux" and discard the extlang 
> "bar".
> 
> This is likely an oversight and should be fixed rather than kept and 
> specified as a BCP deviation, since it is non standard for extlangs to follow 
> those previously mentioned longer tags.
> 
> I can file a release note if deemed warranted since the acceptable inputs 
> shrink as a result (even if the correct behavior). Personally, I would lean 
> towards not filing one since such occurrences would be non-standard as there 
> are no extlangs that follow a non 2-3 length language prefix.
> 
> ---------
> - [x] I confirm that I make this contribution in accordance with the [OpenJDK 
> Interim AI Policy](https://openjdk.org/legal/ai).

`Locale` currently states:

> BCP 47 deviation: this is not the full BCP 47 language production, since it 
> excludes 
> [extlang](https://datatracker.ietf.org/doc/html/rfc5646#section-2.2.2) (as 
> modern three-letter language codes are preferred).

I think this wording is a little ambiguous. The intended meaning seems to be 
that the Locale composition does not separately expose a primary `language` 
_and_ `extlang`. (That is, we just normalize to `language` only.) As currently 
written, it came off to me as though the `Locale` class does not support 
"extlangs" altogether, (including during parsing).

@naotoj, what do you think? Do you think this is worth a clarification in a 
separate issue?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/31663#issuecomment-4793458987

Reply via email to