Remove `style=percent` from :number and :integer by eemeli · Pull Request #988 · unicode-org/message-format-wg

eemeli · 2025-01-21T22:22:52Z

Fixes #956

A separate :percent function is added, and the style option dropped from :number and :integer.

As proposed in #987, selection is not enabled for :percent.

I've also left out the notation and compactDisplay options, as I'm not aware of any actual use cases combining them with percent formatting.

aphillips · 2025-01-21T23:50:20Z

spec/functions/number.md

+For the purposes of formatting,
+the numeric value of the _operand_ is multiplied by 100.


Since we have a separate function, purpose built for it, should we offer a pre-computed mode?

You mean an option toggling if the input is multiplied or not?

Yes, exactly.

ICU4C calls it "scale" or "multiplier"

ICU4X calls it "multiply_pow10"

I don't think we've had a proper bikeshedding session on this before. I've sort-of named it what I felt like naming it and no one ever pushed back with better names.

Given that we'll be defaulting to a value 1 getting formatted as something like "100%", I think scale makes the most sense, with a default value of 1 and supporting 100 as an alternative. With this approach,

{42 :percent scale=100}

would then be formatted as "42%".

Or is the ICU4C meaning of this option the exact opposite?

Another thought: an enumeration might be appropriate here. Something like:

scalingMode: "scale" scales the number: 0.5 => 50%

scalingMode: "passThrough" passes through the number: 50 => 50%

(sorry for the quad-post)

In that case, scale is a rather sub-optimal choice, as it demonstrably can be understood as either "scale the number by this much" or "the scale extends to this value as the maximum".

More suggestions, with some help from an LLM

enum PercentageScale { Fraction, Percentage } enum InputMode { Decimal, Scaled } enum ValueType { Normalized, Preformatted } enum PercentMode { Ratio, Percent } enum ScaleType { UnitInterval, WholePercent } enum InputScale { PartsPerHundred, FinalPercent } enum Scale { Raw, Scaled }

Maybe style=raw, as an alternative to a default style=scaled?

I would like to avoid any option with the unqualified style name.

aphillips · 2025-01-21T23:54:55Z

spec/functions/number.md

+The _resolved value_ of an _expression_ with a `:percent` _function_
+contains an implementation-defined numerical value
+of the _operand_ of the annotated _expression_ multiplied by 100,
+together with the resolved options' values.


For clarity, and since "resolved value" and "options" are the terms, perhaps:

Suggested change

together with the resolved options' values.

together with the _resolved values_ of the _options_.

Variants of this same snippet are used in nearly all the functions. This change would be better made separately, affecting all of them at once.

But yes, referring to the options' resolved values would be appropriate, but note that this isn't the same as options, given that the resolved options are determined by the function handler. In practice they can include ones coming from the operand as well, and don't necessarily contain all of the options.

Perhaps "resolved values of the resolved list of options"? Oh the pedantry...

sffc · 2025-01-22T16:40:20Z

spec/functions/number.md

+Option values with the following names are however discarded if included in the _operand_:
+
+- `compactDisplay`
+- `notation`
+- `select`


Just say that all options not named in the :percent function's list above are discarded?

That would be different from what we do with other functions, such as :integer, and it would make extensibility difficult.

An implementation could support additional options that are set in the calling code on the value being formatted, and are understood by the formatter. For a somewhat silly example, an implementation could support colour as a property of numbers, and format a "green 0.42" so that the % sign was also green in the output. If we here said that all options not explicitly listed are discarded, this kind of extensibility would not be possible.

sffc · 2025-01-22T17:12:54Z

spec/functions/number.md

+For the purposes of formatting,
+the numeric value of the _operand_ is multiplied by 100.


ICU4C calls it "scale" or "multiplier"

ICU4X calls it "multiply_pow10"

I don't think we've had a proper bikeshedding session on this before. I've sort-of named it what I felt like naming it and no one ever pushed back with better names.

eemeli · 2025-01-27T19:38:42Z

During today's discussion, we noted that percent formatting is already available via :unit unit=percent.

This means that introducing :percent or retaining support for :number style=percent would be duplicating nearly the same functionality by two different means, and I don't think we should do that.

To still support the multiplicative behaviour (which :unit doesn't have), it might be best to add a :math multiply operator. @sffc raised some performance concerns about allowing multiplication by any number, and the digit-size option range (used by :math add and :math subtract) caps out at 99 for literals. Therefore, I'm considering refactoring this PR to:

Drop :number style and :integer style.
Add :math multiply with supported values 10, 100, 1000.

aphillips · 2025-01-27T20:48:43Z

Add :math multiply with supported values 10, 100, 1000.

I'm dubious that this is a good idea. The :math function has a suggestive name. It's reasonable to assume that it will, over time, be extended to other purposes, similar to math functionality in programming languages (such as java.lang.Math in Java). It's convenient to solve specific short term problems using this function now, but we should avoid binding our hands too much.

Note that this would mean that unit=percent would become unscaled ({50 :unit unit=percent} formats as 50%). If we want to provide a :math modifier, perhaps scale or exp.

Also, there are other formats that we're ignoring (because they are much less common) which are supported by CLDR data, which is per-mille and per-myriad formatting. We should just solve the problem. The existence of these suggests a convenience function or maybe a convenience unit.

Consider:

.local $val = {|50|}
.local $pct = {$val :unit unit=percent-scaled}
{{I print {$pct} as 5000% but {$val :unit unit=percent} as 50%}}

sffc · 2025-01-28T04:28:41Z

I still have the weakly held position that :percent carries its own weight, and we should just add it and move on.

It doesn't completely duplicate functionality: you use :percent if you want scaling, and :unit unit=percent if not.

sffc · 2025-02-02T11:11:38Z

Another thought. If we want to try and be more general, I'd be okay with a function such as :dimensionless which supports all dimensionless units and automatically scales values.

This could also be an option on :unit where the only two valid options are "scale dimensionless units" and "do not scale dimensionless units" (not an arbitrary multiplier). Maybe return an error if the option is set on a non-dimensionless unit.

But I still prefer a clean :percent.

eemeli · 2025-02-10T18:18:34Z

Updated as per discussion during today's meeting.

aphillips · 2025-02-10T19:48:41Z

This change was approved in the 2025-02-10 call.

…rg/message-format-wg#988)

eemeli requested review from aphillips and sffc January 21, 2025 22:22

aphillips reviewed Jan 21, 2025

View reviewed changes

sffc reviewed Jan 22, 2025

View reviewed changes

Only remove style=percent

b110596

eemeli force-pushed the percent branch from 7bd49a5 to b110596 Compare February 10, 2025 18:17

eemeli changed the title ~~Add :percent~~ Remove style=percent from :number and :integer Feb 10, 2025

aphillips approved these changes Feb 10, 2025

View reviewed changes

aphillips merged commit b58b1d2 into main Feb 10, 2025

aphillips deleted the percent branch February 10, 2025 19:48

eemeli mentioned this pull request Feb 10, 2025

[FEEDBACK] Please move style percent to its own function #956

Closed

eemeli added a commit to messageformat/messageformat that referenced this pull request Mar 2, 2025

feat(mf2)!: Remove style=percent from :number and :integer (unicode-o…

43f065c

…rg/message-format-wg#988)

eemeli mentioned this pull request Mar 2, 2025

MF2 spec updates for LDML 47 release messageformat/messageformat#440

Merged

XM5jDcsHTyGJtQqlCi added a commit to XM5jDcsHTyGJtQqlCi/messageformat that referenced this pull request Oct 12, 2025

feat(mf2)!: Remove style=percent from :number and :integer (unicode-o…

77b6369

…rg/message-format-wg#988)

		For the purposes of formatting,
		the numeric value of the _operand_ is multiplied by 100.

	together with the resolved options' values.
	together with the _resolved values_ of the _options_.

Uh oh!

Conversation

eemeli commented Jan 21, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eemeli Jan 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eemeli commented Jan 27, 2025

Uh oh!

aphillips commented Jan 27, 2025

Uh oh!

sffc commented Jan 28, 2025

Uh oh!

sffc commented Feb 2, 2025

Uh oh!

eemeli commented Feb 10, 2025

Uh oh!

aphillips commented Feb 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

eemeli Jan 22, 2025 •

edited

Loading