<i18n dev> RFR: 6230751: [Fmt-Ch] Recursive MessageFormats in ChoiceFormats ignore indicated subformats [v2]

[Justin Lu]

On Fri, 1 Dec 2023 21:51:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates an incorrect code example in _java/text/ChoiceFormat_.
>> 
>> ChoiceFormat (and MessageFormat) provide an example of how to produce a pattern that supports singular and plural forms. The ChoiceFormat example is incorrect, as recursive MessageFormats produced by a ChoiceFormat subformat only recognize subformats defined through the MessageFormat pattern syntax, not through the subformats contained within the top level MessageFormat. 
>> 
>> In the original example,
>> `Format[] testFormats = {fileform, null, NumberFormat.getInstance()};` could have been replaced with 
>> `Format[] testFormats = {fileform, null, new ChoiceFormat("0#BROKEN")};` and the original output would have been the same.
>> 
>> This PR replaces the example with the one used in MessageFormat, which is correct. 
>> 
>> This PR also includes a drive-by fix to remove leftover `<blockquote>`s from a previous `@snippet` conversion.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify limitations

src/java.base/share/classes/java/text/MessageFormat.java line 299:

> 297:  * the string produced by a {@code ChoiceFormat} in {@code MessageFormat} is
> 298:  * treated as special; occurrences of '{' are used to indicate subformats, and
> 299:  * cause recursion. A limitation to this behavior is that, if a {@code MessageFormat}

@naotoj Please let me know if the added limitations wording reads clearly to you. I would rather not have a whole dedicated code example to explain a _limitation_, but if needed for better understanding, I can add one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16891#discussion_r1412604775