Skip to content

Remove misleading terms/clauses for :currency options and operands #938

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

macchiati
Copy link
Member

We already state near the top of the document that:

Implementations MAY accept additional option values for options defined here.
However, such values might become defined with a different meaning in the future,
including with a different, incompatible name
or using an incompatible value space.
Supporting implementation-specific option values for standard or optional functions is NOT RECOMMENDED.

So there is no need to have a separate statement for particular options saying that X must be either Y or an implementation defined value. Moreover, by calling it out on one option on a function, it makes the readers mistrust whether is actually the case for other options on the function.

Eg, "berries can be added to any desserts" at the top of the menu, then later
"desserts are pancakes (optionally with berries), or waffles".

It makes people question whether you can have waffles with berries even though you say at the top you can.

@aphillips aphillips changed the title Remove misleading terms/clauses Remove misleading terms/clauses for :currency options Nov 15, 2024
@aphillips aphillips changed the title Remove misleading terms/clauses for :currency options Remove misleading terms/clauses for :currency options and operands Nov 15, 2024
@aphillips aphillips added functions Issue pertains to the default function set normative Issue affects normative text in the specification LDML46.1 MF2.0 Draft Candidate labels Nov 15, 2024
@aphillips
Copy link
Member

You're changing the operand definition, which is not the same thing as an option value. All of our functions explicitly allow implementation defined types in the operand section.

Similarly, option values covered by the text you cite (which might not be clear enough) provides permission to use a different value space (which mostly means literal values, which we caution against for good reason). The text you're eliding here permits the same implementation defined types to be used as an option value.

What we're trying to permit is this:

ImmutableMap<String,Object> args = ImmutableMap.of(
   "currency", Currency.getInstance("USD"),
   "value", 123.45
);
MessageFormatter mf2 = MessageFormatter.builder()
    .setPattern("You have: {$value :currency currency=$currency}").build();
System.out.println(mf2.formatToString(args));

We want $currency to be allowed to be a java.util.Currency (or com.ibm.icu.util.Currency) here, not just a literal USD.

Similarly, as we explicitly call out, want to be able to use a specific boxing value (here, ICU4J's CurrencyAmount) for the operand $value:

ImmutableMap<String,Object> args = ImmutableMap.of(
   "value", new CurrencyAmount( 123.45, Currency.getInstance("USD"))
);
MessageFormatter mf2 = MessageFormatter.builder()
    .setPattern("You have: {$value :currency}").build();
System.out.println(mf2.formatToString(args));

@macchiati
Copy link
Member Author

Makes sense, I'll close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
functions Issue pertains to the default function set LDML46.1 MF2.0 Draft Candidate normative Issue affects normative text in the specification
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants