Fwd: ICU proposal: Concise number skeleton syntax

[Shane Carr]

Dear all,

I am making a proposal to amend number skeleton syntax in ICU.  This has implications especially for MessageFormat.  Please send feedback.

Shane

---------- Forwarded message ---------
From: Shane Carr <sf...@google.com>
Date: Thu, Oct 24, 2019 at 9:45 PM
Subject: ICU proposal: Concise number skeleton syntax
To: icu-design <icu-d...@lists.sourceforge.net>

Dear ICU team & users,

I would like to propose additions to the number skeleton syntax for ICU 67.

Ticket: https://unicode-org.atlassian.net/browse/ICU-20418

Please provide feedback by: next Tuesday, 2019-10-29

Designated API reviewer: Markus

tl;dr: where you would currently need to write,

.00 group-off notation/compact-short sign-display/except-zero

you will now be able to write,

+? 0.00 k

This proposal does not change support for existing skeletons.  Existing (long-form) skeletons will always continue to work, and the toSkeleton API will continue to return the long-form skeletons.  This proposal is only to add concise syntax that is intended to be more readable and easier to write.

Number skeletons are used to express locale-agnostic number formatting styles.  They can be used via either the NumberFormatter API or via MessageFormat with the "::" prefix.  They are documented here:

https://github.com/unicode-org/icu/blob/master/docs/userguide/format_parse/numbers/skeletons.md

The concrete additions I propose:

New combined grouping and fraction precision blueprint stem

Proposal: add a new blueprint stem with the following syntax:

1. Starts with either "0" (no grouping) or "0,0" (auto grouping)

2. If this is the end of the token, stop.

3. Expect the next character to be "."

4. Consume the remainder of the token as Fraction Precision.

Examples:

New Concise Skeleton	Equivalent Long Skeleton
0	group-off
0,0	group-auto
0.	group-off precision-integer
0.+	group-off precision-unlimited
0,0.00	group-auto .00

Question: do we want to support the other grouping strategies here? If so, how?

Abbreviated sign display options

Proposal: add shortcut tokens for all sign display options, as shown in the following table.

New Concise Skeleton	Equivalent Long Skeleton
default: no shortcut proposed	sign-auto
+	sign-always
+?	sign-except-zero
+!	sign-never
()	sign-accounting
(+)	sign-accounting-always
(+?)	sign-accounting-except-zero

Allow UTS 35 core unit identifiers

Proposal: accept the UTS 35 core unit identifier syntax, which is the same as the unit identifier except without the type.  CLDR guarantees that the core unit identifiers are unique.  It also allows arbitrary combinations of simple units with "-per-".

New Concise Skeleton	Equivalent Long Skeleton
unit/meter	unit/length-meter
unit/furlong-per-second	unit/length-furlong per-unit/duration-second

Scientific notation blueprint stem

Proposal: accept the following blueprint stem for scientific notation:

1. Start with "E" (capital E)

2. Allow "+", "+?", or "+!" interpreted as an abbreviated sign display option

3. Follow with one or more 0s for exponent min digits

Examples:

New Concise Skeleton	Equivalent Long Skeleton
E0	scientific
E+0	scientific/sign-always
E+?0	scientific/sign-except-zero
E00	scientific/+ee
E+!000	scientific/sign-never/+eee

Other abbreviations: compact notation and percent

Proposal: allow the following abbreviations for popular options.

New Concise Skeleton	Equivalent Long Skeleton
k	compact-short
kk	compact-long
%	percent

Additional suggestions are welcome.

Sincerely,

Shane

[Alan Liu]

Excuse my ignorance, but what's the use case for "sign never," in both decimal formats and in exponents?

--
You received this message because you are subscribed to the Google Groups "Message Format Working Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to message-format...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/message-format-wg/CABxsp%3DkO4jNNWt_Q-evzNKmG6ei%2B%2BXBRN5bfb-FxEkr1jsVtEQ%40mail.gmail.com.

[Shane Carr]

Thanks for the question!

The intent of that option is if you have some other way of displaying the sign, like rendering the number in red, or if you say elsewhere in context that the number is negative. For example, it's conceivable to write a message like (with a custom signum function),

"Your portfolio {0, signum, 1{gained} -1{lost}} {0, num, ::+! currency/USD} today"

However I admit that it's unclear whether this would be used in practice. If you feel that this creates more confusion than it's worth, I'm fine removing the concise syntax for this.

Shane

[Alan Liu]

Got it, thanks for the explanation. Seems like a valid use case for decimal numbers, but I'm struggling a little to imagine a use for exponents. I guess they'd have to format the mantissa and exponent separately, which I don't think we support. Maybe they would post-process by looking for 'E'.

What do you think of keeping "sign never" for decimal numbers, but dropping it for exponents?

[Shane Carr]

> What do you think of keeping "sign never" for decimal numbers, but dropping it for exponents?

SGTM, especially since we're already restricting certain sign formats (accounting format) from appearing in the exponent.

Related note: Although my example uses ICU MessageFormat syntax, my hope is that the syntax for number skeletons (as well as the existing stable UTS 35 date skeletons) would be adopted by whichever overall syntax this working group decides on.  So, you can think of this syntax as a sub-problem of the overall MessageFormat syntax.

[Phillips, Addison]

My mailer failed to pick up the WG address, which gave me the opportunity to correct the typos.

 

From: Phillips, Addison
Sent: Wednesday, October 30, 2019 3:10 PM
To: 'Alan Liu' <liu...@google.com>; Shane Carr <sf...@google.com>
Subject: RE: ICU proposal: Concise number skeleton syntax

 

Off the cuff a few thoughts.

 

An occasionally useful feature of the old SimpleNumberFormat syntax is the ability to zero-fill to the left of the decimal point. There is also the ability to limit the number of decimal places without zero filling, e.g. “000.00#” (for some locales) formats 1.2343 as “001.234” and 1.2 as “001.20”.

 

This suggests that the grouping flag can occur without a symbol to the left of it, e.g. “,” is equivalent to “0,0”.

 

(following is just thinking out loud and not a serious proposal) A different model for this would be printf style notation, adapted for our usage, e.g. things like

 

+04.3d (sign-always, zero filled to 4 digits, 3 digits precision)

0,4i [or ,04i] (zero filled 4-digit integer with grouping)

,i (grouping used integer)

,d (grouping used, unlimited precision decimal)

,.2d (grouping use, 2 decimal digits)

 

Addison

 

Addison Phillips

Sr. Principal SDE – I18N (Amazon)

Chair (W3C I18N WG)

 

Internationalization is not a feature.

It is an architecture.

 

 

 

 

1.     Starts with either "0" (no grouping) or "0,0" (auto grouping)

2.     If this is the end of the token, stop.

3.     Expect the next character to be "."

4.     Consume the remainder of the token as Fraction Precision.

1.     Start with "E" (capital E)

2.     Allow "+", "+?", or "+!" interpreted as an abbreviated sign display option

3.     Follow with one or more 0s for exponent min digits

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/message-format-wg/CAC9cTncPVmPQhf%2BoRygtQLCMXd6iO3%2B07OuxFieOjYe8dO6iiQ%40mail.gmail.com.

[Shane Carr]

Hi Addison,

Thanks for the feedback!  I'll think about ways to add left zero-fill (aka minimum integer digits) to the concise skeletons; they are currently supported in long-form skeletons and API.  Also, if we're okay with ',' being a lead character in the syntax, that opens up some more options, too.

".00#" is already supported (see documentation here).

One design constraint for the new concise syntax is the ease of parsing these skeletons and the extensibility.  We need to temper the desire to add more syntax with the implementation requirements to have a small fast parser for them.

Shane

[addisoni18n]

Thanks Shane. My desire isn't for more syntax, but for one that developers can easily use. A small fast parser is part of that. 

Sent via phone

--

You received this message because you are subscribed to the Google Groups "Message Format Working Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to message-format...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/message-format-wg/CABxsp%3D%3DbfZ2UvUR6EMsyWWURoNLE-rTTV0UM_RTBgJYwhMP%3DnA%40mail.gmail.com.

[Shane Carr]

I have updated the user guide page with the latest suggestions:

https://github.com/unicode-org/icu/pull/903/files?short_path=cd52e01#diff-cd52e018f11dbe12a40414de6523ba46

Changes relative to my first email:

Abbreviated Grouping Options

Table:

New Concise Skeleton

Equivalent Long Skeleton

,^	group-off
,?	group-min2
,	group-auto
,!	group-on-aligned
,,	group-thousands

Integer Width Blueprint Stem

To answer Addison's suggestion, allow one or more zeros to specify the minimum integer width.  For example, "00" means "at least 2 integer digits".

Engineering Notation

In addition to "E" for scientific, allow "EE" for engineering.

Scientific Notation Sign Display

As Alan suggested, do not allow the sign-never option in the concise scientific notation.

Sign-never: Changing ! to ^

To be more consistent with the new grouping skeletons, change +! to +^ for sign-never.

Compact Notation

Capitalize the "k" and "kk" to "K" and "KK" (I made this change to make the optional spacing change below easier to implement).

Concise Optional Spacing

This replaces the "Combined grouping and fraction precision blueprint stem" in my first email.  Instead of just those two tokens, allow combinations of the following popular tokens, in order:

1. Concise sign display

2. Concise grouping (starting with `,`)

3. Concise integer width (starting with `0`)

4. Fraction precision (starting with `.`)

5. Concise notation (starting with `K` or `E`)

6. Concise percent (starting with `%`)

Examples:

Space-Separated Skeleton

Concise Skeleton

Equivalent Long Skeleton

,? .00	,?.00	group-min2 .00
+? 00 %	+?00%	sign-except-zero integer-width/+00 percent
.##/@@@+ %	.##/@@@+%	.##/@@@+ percent
, K	,K	group-auto compact-short
+ , 00 .00 K	+,00.00K	sign-always group-auto integer-width/+00 .00 compact-short

For more details, see the userguide page.

I like the feedback.  Keep it coming!

Shane

[Shane Carr]

Dear all,

We had a design discussion on this topic at Google, in which two alternatives for the sign display and grouping separator options were proposed.  I would like to hear your thoughts.

Grouping separators:

Proposal	Alt 1	Alt 2	Equivalent Long Skeleton	Example
,^	,o	Go	group-off	1234 and 12345
,?	,m	Gm	group-min2	1234 and 12,34,567
,	,	G	group-auto	1,234 and 12,34,567
,!	,a	Ga	group-on-aligned	1,234 and 12,34,567
,,	,t	Gt	group-thousands	1,234 and 1,234,567

Sign display:

Proposal	Alt 1	Alt 2	Equivalent Long Skeleton
default: no shortcut proposed	+	S	sign-auto
+	+a	Sa	sign-always
+?	+e	Se	sign-except-zero
+^	+n	Sn	sign-never
()	+c	Sc	sign-accounting
(+)	+ca	Sca	sign-accounting-always
(+?)	+ce	Sce	sign-accounting-except-zero

Some of the reasoning behind these alternatives:

• Users are less likely to confuse it with regex syntax
• Less confusion about the semantics of the ASCII special characters

Comments?

Shane

[Eemeli Aro]

Maybe I'm missing something, but what's the actual use case for this compact notation? I can understand a relatively small set of shorthands for common usage patterns, but I'm having a hard time figuring out the benefit of having a shorthand for something like group-min2 or sign-accounting-except-zero.

If, however, there is a reason that I'm just missing, then I'd at least prefer all-letter solutions like "Sce", ie. Alt 2 in the above. Those at least have a vague hope of being searchable when first encountered, overlap less with false friends such as regexp and globs, and are far easier to map mentally to a concept-option pattern that the others, which require realising that e.g. ",t" means that the t modifies the , option.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/message-format-wg/CABxsp%3DnjG1wJSvhFqaCHLEOH4DUD0E%3DZ8DgZu7Mq%2BoD9tw-WAg%40mail.gmail.com.

[Shane Carr]

Thanks for the question.

The long-form syntax for number skeletons was designed to have full coverage of number formatting options, with a simple and extensible syntax.  Note: I'm the one who proposed it.  However, I have never been fully satisfied with the syntax for the following reasons:

1. Requires familiarity with the NumberFormatter API to read and write (the meaning of the tokens is not "self-explanatory")
2. Very English-language centric
3. Takes up more space than their date skeleton counterparts

This proposal is my attempt at creating what I intend to be a skeleton syntax where the skeleton "looks more like" the number you are trying to print.  You should be able to get some sense of the number format without having to dig into the docs.  For prior art, I was inspired by libraries like Numeral.js that found a concise way to express number formatting settings in skeleton strings.

I understand the benefits of Alt 2 relative to the other options, but I'm personally not a fan, because it is not "self-explanatory" and still requires an understanding of the NumberFormatter docs.  In my mind, Alt 2 is not an improvement over the status quo.  So, if Alt 2 is better than the other options, then maybe that means the status quo is best and we simply shouldn't make these changes to the syntax.

Shane

[Phillips, Addison]

I tend to agree with your reasoning. So I’m closer to your original proposal than to Alt1 or Alt2 generally.

 

If the syntax ends up with all manner of arcane options (and I think it’s to some degree unavoidable), the recourse to documentation will happen anyway, but if at least the commonly used options were more like picture strings (without, you know, *being* picture strings—because that’s the problem we’re trying to solve), that might be ideal.

 

I tend to prefer default options being on unless you turn them off, hence I prefer not having to say anything about the sign to get “auto”.

 

We might make the syntax more compact by using integers for the number of zero-fill digits, e.g. “+,5.2” is “+,00000.00” in the proposal.

 

FWIW, I favor no-space tokens to make the parsing and handling more reliable when working with message format patterns and such.

[Rafael Xavier]

Hi Shane,

Thanks for sharing your proposal with us all and for collecting our feedback...

Some of the abbreviated forms are very easy to understand, e.g., `k` to denote notation/compact-short. Though, others aren't that much and therefore I am wondering is it worth to give all long-forms (e.g., group-min2, sign-accounting-except-zero) noble abbreviated-forms? I may be missing something in the goal, but otherwise finding a balance (potentially selecting the most used forms) would achieve both optimal readability plus extending the abbreviated expressiveness, which may be desirable because not only developers need to understand it, but linguists.

Thanks and great work

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/message-format-wg/2efa956f7778404899ee8a39998693a5%40EX13D08UWB002.ant.amazon.com.

--

+55 (16) 98138-1583, skype: rxaviers
http://rafael.xavier.blog.br

[Eemeli Aro]

Partly inspired by this thread, I've been recently working on a JavaScript number-format skeleton parser, and one particular feature that made it relatively easy to start with is the space-separation of the tokens. If that assumption would get dropped by Concise Optional Spacing, the associated parsers would need to get a bit more complicated. This correlates somewhat with the increased difficulty in human parsing of these strings; it's by no means obvious that e.g. ,?.00 is two tokens while +,00 is three tokens, or that ,?+ is invalid.

I would also argue that if there is good reason to allow for spacing to be optional, having all of these concise tokens start with a capital letter would make it much easier to separate them.

Furthermore, I'd like to note that not even the symbol-based concise syntax can really escape its English-language roots. For instance, in many continental European languages the . and , symbols hold flipped meanings to those used in English, so the "looks more like" design goal isn't necessarily fulfilled.

[Mihai Nita]

I think that linguists don't need to touch these skeletons. That was needed for full date patterns, which was bad. But it is not needed for date skeletons. And should not be needed for number skeletons.

Mihai

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/message-format-wg/CADdLYsozQO8%2Bax03F4rS61Duozgq8Z5R%3D6et9F_32qzHXOKh%2Bw%40mail.gmail.com.

[Shane Carr]

RE Rafael:

Acknowledged that only selecting the most commonly used tokens could alleviate a lot of the concerns that have been raised about the readability of the more obscure tokens.  I'll go through the list and pick out ones that could make sense to promote.

RE Eemeli:

Awesome to hear about the JavaScript parser!

Yeah, part of the idea of the space-separated tokens was to make the string easier to parse.  The Concise Optional Spacing proposal only applies to a small, limited subset of tokens with "signal characters" that make parsing them more tractable, at least for a greedy look-ahead parser (the type implemented in ICU), but it does definitely make life more difficult for simpler split-by-spaces parsers.  It's just a tradeoff with the desire to have "picture strings", as Addison said.  I'm okay holding back on Concise Optional Spacing for now, and only propose the concise strings.

Acknowledged about the , vs . problem.

If we wanted to introduce capital letters as a core mechanism, in my opinion, we should go back to the drawing board and make it apply to all tokens.  For example, "SaI2F1-3" could mean "Sign always, Integer 2 digits, Fraction 1 to 3 digits" and map to "+ 00 .0##" in the proposed symbol-based concise syntax.  But, I don't necessarily think we should mix those two styles in one syntax.  We already have some symbol-based tokens like ".0##" and "@@@", so I think we should stick with the symbol-based style.

[Shane Carr]

Dear Message Format WG,

Based on feedback from this thread, as well as additional discussions with ICU-TC and others, I have updated my proposal.  The latest proposal can be seen in my PR:

https://github.com/unicode-org/icu/pull/903/files?short_path=cd52e01#diff-cd52e018f11dbe12a40414de6523ba46

Highlights:

• Concise Optional Spacing has been removed.  If you really want it, you can use a zero-width space. :-)
• Concise Scale has been removed and replaced with a single ASCII token "%x100" for the most common use case.
• ICU-TC liked the semantics I had proposed for '?' and '!' to describe grouping strategies, so that has been applied more consistently.  It was also suggested to use '_' to mean "never", and I would like to know what you all think of that suggestion.

In particular, the two most controversial tokens have been the grouping strategy and the sign display.  My proposal now has:

Concise Skeleton	Long Skeleton	Explanation	Example (en-IN)
,_	group-off	Do not show grouping separators.  Grouping is "forbidden".	1234 and 1234567
,?	group-min2	Show grouping separators when there are at least 2 digits in a group.  Grouping is "optional".	1234 and 12,34,567
none	group-auto	Use locale preferences.	1,234 and 12,34,567
,!	group-on-aligned	Always show the grouping separator, even if the locale prefers to hide it. Grouping is "required".	1,234 and 12,34,567
,=	group-thousands	Always show the grouping separator, and group by the thousands, even if the locale prefers otherwise.	1,234 and 1,234,567

The '?' means semantically, "the thing I am describing is optional"; '!' means, "the thing I am describing is required"; and '_' means, "the thing I am describing is forbidden".  Those semantics are also now applied to sign display options:

Concise Skeleton	Long Skeleton	Explanation
none	sign-auto	Show the sign on negative numbers; do not show it on positive numbers.
+!	sign-always	Always show the sign.  The sign is "required".
+?	sign-except-zero	Show the sign on positive and negative numbers, but not on zero.  The sign is "optional".
+_	sign-never	Never show the sign.  The sign is "forbidden".
()	sign-accounting	Use accounting format for negative numbers; do not show the sign on positive numbers.
()!	sign-accounting-always	Use accounting format for negative numbers and show the sign on all other numbers.  The sign, either '()' or '+', is "required".
()?	sign-accounting-except-zero	Use accounting format for negative numbers and show the sign on positive numbers but not zero.  The sign is "optional".

Known imperfection with the latest proposal: The comma is still used to describe grouping, even though a comma could mean a decimal separator to many users.  I acknowledge the problem.  An alternative, which there was not time to discuss with ICU-TC this week, would be to use a standalone character like '^' to mean "group-off", and remove the other concise grouping options.  If anyone feels strongly, I can bring up that alternative.

Look satisfactory?

Shane

[Romulo Cintra]

Thanks Shane, 

Description table is great and gave me a quick overview of use cases . Related with "grouping" i would prefer "^" or "^^" instead of comma ,  to avoid wrong interpretation and usage.

To unsubscribe from this group and stop receiving emails from it, send an email to message-format-wg+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/message-format-wg/CABxsp%3D%3DbfZ2UvUR6EMsyWWURoNLE-rTTV0UM_RTBgJYwhMP%3DnA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Message Format Working Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to message-format-wg+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/message-format-wg/CABxsp%3DnjG1wJSvhFqaCHLEOH4DUD0E%3DZ8DgZu7Mq%2BoD9tw-WAg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Message Format Working Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to message-format-wg+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/message-format-wg/2efa956f7778404899ee8a39998693a5%40EX13D08UWB002.ant.amazon.com.

--

+55 (16) 98138-1583, skype: rxaviers
http://rafael.xavier.blog.br

--
You received this message because you are subscribed to the Google Groups "Message Format Working Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to message-format-wg+unsubscribe@chromium.org.

[Alan Liu]

Shane et al:

It's possible that this is off the main thread of this discussion, but I question the usefulness/advisability of group-thousands.

I can convince myself that all the other options could be useful (sometimes it requires some squinting).

To unsubscribe from this group and stop receiving emails from it, send an email to message-format...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/message-format-wg/CABxsp%3D%3DbfZ2UvUR6EMsyWWURoNLE-rTTV0UM_RTBgJYwhMP%3DnA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Message Format Working Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to message-format...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/message-format-wg/CABxsp%3DnjG1wJSvhFqaCHLEOH4DUD0E%3DZ8DgZu7Mq%2BoD9tw-WAg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Message Format Working Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to message-format...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/message-format-wg/2efa956f7778404899ee8a39998693a5%40EX13D08UWB002.ant.amazon.com.

--

+55 (16) 98138-1583, skype: rxaviers
http://rafael.xavier.blog.br

--
You received this message because you are subscribed to the Google Groups "Message Format Working Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to message-format...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/message-format-wg/CADdLYsozQO8%2Bax03F4rS61Duozgq8Z5R%3D6et9F_32qzHXOKh%2Bw%40mail.gmail.com.

--

You received this message because you are subscribed to the Google Groups "Message Format Working Group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to message-format...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/message-format-wg/84e8fa5b-3bc7-4f4c-adf7-7d835077a211%40chromium.org.

[Eemeli Aro]

On a related note, what's the proper forum for raising issues regarding the number skeleton? Is it this working group list, or e.g. the ICU issue tracker?

Also, is there a more formal definition for it than this? https://github.com/unicode-org/icu/blob/master/docs/userguide/format_parse/numbers/skeletons.md

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/message-format-wg/CAC9cTnfrsAB-9apFW_3ey%2B5g6Gp21LqVojQyY4nYwEssaK2vLA%40mail.gmail.com.

[Shane Carr]

Right now, number skeletons are owned by ICU, so outside this discussion in which I'm explicitly soliciting feedback, the right place to report issues would indeed be the ICU issue tracker.

That markdown file is the source of truth for the syntax as it stands.

I'm optimistic that this can make it into UTS 35 at some point, or into the new standard this group is building for message formats, at which point ICU would just defer to the appropriate standard. I want to make sure this is as close to perfect as possible before putting it in an official standard.

Shane

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/message-format-wg/CAFuwTa54hG9_B07rYmt5C-ytB%3DxA2joii2qypiQJBpa86bPypw%40mail.gmail.com.