CLDR-17298 Fix problem with unit exponents #4071
Conversation
This is a fix for the problem noted in https://unicode-org.atlassian.net/browse/CLDR-17298?focusedCommentId=177586
macchiati
requested review from
btangmu,
FrankYFTang,
pedberg-icu and
richgillam
|
Hi, I did some wording cleanup; could someone re-review? |
| @@ -951,15 +951,17 @@ Some of the constraints reference data from the unitIdComponents in [Unit_Conver | |||
| </ul></td></tr> | |||
|
|
|||
| <tr><td><a name='unit_constant' href='unit_constant'>unit_constant</a></td><td>:=</td> | |||
| <td>("1"[0-9]+ | [2-9][0-9]*)("e" ("1"[0-9]+ | [2-9][0-9]*))? | |||
| <td>[1-9][0-9]* ("e" [1-9][0-9]*)? | |||
There was a problem hiding this comment.
this will allow "1" in "per-1" . Is that ok?
There was a problem hiding this comment.
That is disallowed by the constraint below.
| <li><em>Note:</em> The <code>e</code> notation is optional: per-100-kilometer and per-1e2-kilometer are equivalent unit_identifiers.</li> | ||
| <li><em>Note:</em> When constructing identifiers, exponents should be greater than 3 and multiples of 3, even though parsers must accept the wider range.</li> |
There was a problem hiding this comment.
but in the previous line you have the example of "per-1e2-kilometer" 1e2 is not "exponents ... greater than 3 and multiples of 3", right?
There was a problem hiding this comment.
Yes. They are equivalent. The following line makes it clear that the 100 is the preferred form in that case for generators of unit identifiers, even thought 1e2 must be accepted by parsers of unit identifiers.
There was a problem hiding this comment.
-
I think what you're saying in this comment is clearer than what you have in the spec right now.
-
Is anything in the tooling enforcing these constraints, or is something else (e.g., the review process) supposed to do that?
| <li><em>Note:</em> The <code>e</code> notation is optional: per-100-kilometer and per-1e2-kilometer are equivalent unit_identifiers.</li> | ||
| <li><em>Note:</em> When constructing identifiers, exponents should be greater than 3 and multiples of 3, even though parsers must accept the wider range.</li> |
There was a problem hiding this comment.
-
I think what you're saying in this comment is clearer than what you have in the spec right now.
-
Is anything in the tooling enforcing these constraints, or is something else (e.g., the review process) supposed to do that?
|
Merging now, but can clean up wording later |
This is a fix for the problem noted in https://unicode-org.atlassian.net/browse/CLDR-17298?focusedCommentId=177586
CLDR-17298
ALLOW_MANY_COMMITS=true