8370250: Locale should mention the behavior for duplicate subtags #27909
Conversation
|
👋 Welcome back jlu! A progress list of the required criteria for merging this PR into |
|
@justin-curtis-lu This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be: You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 66 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
openjdk
bot
changed the title
openjdk
bot
added
csr
|
@justin-curtis-lu The following labels will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
| * form as a locale type subtag). {@code Locale} does not enforce uniqueness of | ||
| * locale keys nor attributes. For methods in {@code Locale} and {@code Locale.Builder} |
There was a problem hiding this comment.
This could be misleading as we are enforcing uniqueness, by ignoring the duplicates. The validity is what is not enforced here.
There was a problem hiding this comment.
Good point. I updated that sentence. I held off on using "valid" because while rfc5646 mentions duplicates being "invalid", rfc6067 simply mentions that duplicates have no meaning.
| * However, duplicate extension singleton keys and their associated type | ||
| * are accepted but ignored. The same behavior applies to duplicate locale | ||
| * keys and attributes within a U extension. | ||
| * |
There was a problem hiding this comment.
"Note that..." in the prior occurence of this wording might apply here for consistency.
There was a problem hiding this comment.
Locale.forLanguageTag is specified to ignore subsequent subtags on ill-formed input, so a heads up is warranted. Since Lcoale.Builder.setLanguageTag either throws or does not (and duplicate tags do not throw), I think it is implied subsequent subtags are processed. However, that's just my opinion, if you think it is not obvious, I will add it in.
There was a problem hiding this comment.
I think explicity specifying the note would not hurt here, otherwise missing "note" might unnecessarilly make readers wonder why
|
@naotoj The CSR is now updated with the proposed wording. |
openjdk
bot
added
ready
2 participants
Please review this PR which is a first stab at clarifying the behavior of duplicate variants, extension singletons, and U extension keys and attributes for BCP47 subtags in the Locale specification. This is a follow up to https://bugs.openjdk.org/browse/JDK-8369739.
Changes are made under the BCP47 and U extension sections that define "well-formed" in the class description.
Additionally, changes are made under the relevant Locale and Locale.Builder methods themselves.
Will update the CSR accordingly when the proposed wording changes are finalized.
Progress
Issues
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27909/head:pull/27909$ git checkout pull/27909Update a local copy of the PR:
$ git checkout pull/27909$ git pull https://git.openjdk.org/jdk.git pull/27909/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 27909View PR using the GUI difftool:
$ git pr show -t 27909Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27909.diff
Using Webrev
Link to Webrev Comment