<i18n dev> RFR: 8363972: Loose matching of dash/minusSign in number parsing [v4]
Naoto Sato
naoto at openjdk.org
Fri Aug 1 19:11:01 UTC 2025
On Fri, 1 Aug 2025 16:40:27 GMT, Justin Lu <jlu at openjdk.org> wrote:
>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>>
>> flipped again, which was correct
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 422:
>
>> 420: * @implNote The default implementation follows the LDML specification for
>> 421: * {@code parseLenient} elements to interpret minus sign patterns when lenient
>> 422: * parsing is enabled.
>
> IMO, the following is more clear.
>
> `when lenient parsing is enabled` -> `when {@link #isStrict()} returns false`
> `interpret minus sign patterns` -> `enable loose matching of minus sign patterns`
>
> Also, I'm unsure on mentioning `{@code parseLenient} elements` because I'm not sure that users of DecimalFormat will be aware of such LMDL elements. This also seems to be the first time a direct mention of an LDML element is made. I'm not sure of a better alternative ATM.
Thanks, modified as you suggested. For the `parseLenient`, the problem is in the LDML document side, as there is no description for it, and their loose matching description is kind of incorrect (use [:DASH:], which is not the case here. So I just dropped it in this iteration.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26580#discussion_r2248692643
More information about the i18n-dev
mailing list