ICU Design proposal: MF2::Builder::setFormattingLocale

[Steven Loomis]

Please provide feedback by: next Wednesday, 2026-06-24

Designated API reviewer: Markus

Ticket: https://unicode-org.atlassian.net/browse/ICU-<number>

PR: https://github.com/unicode-org/icu/pull/4021

Jira: ICU-23424

This proposes a new setter to the MF2 Builder, setFormattingLocale() .

The use case is a user of MF2 where the pluralization should be based on the specified locale, however, all formatting (date/time/numbers) should be according to a fixed locale, such as en.

The user here is an implementation layer on top of ICU4C, so the messages and inputs are coming in from third parties. 

More Information

We had originally discussed in the CLDR MF2WG  <message-format-wg/issues/1107> the idea of overriding existing MF2 functions (such as date or select) to have the desired behavior. There was not consensus at MF2WG for this approach.

The “current locale” per spec is part of the “Formatting Context” (TR35), which states:

> Implementations MAY include additional fields in their formatting context.

This API proposal is spec-compliant and adds field(s) to the formatting context.

Alternatives

• A0: Instead of (or in addition to) adding setFormattingLocale(), add setSelectorLocale() which will only be used for plural selection. This can have the advantage of being more specific.  Again, if not called, setLocale() would be used.

• A1: Push this back to MF2WG. Allow function overrides, then a client can override standard functions at will.

• A2: From Mihai:  mutate the message to instead use {$foo :custom_date ...} for all formats (instead of :date etc.) 

Note that ICU4C does not expose the MF2 data model, so clients can’t do this kind of mutation just using ICU APIs. They would need an independent MF2 implementation that is capable of this mutation.

• A3: Mutate the message so that instead of .input {$count :number} .match $count one {{…}}
  The message is changed by the user to .input {$count_PLURAL :string} .match $count_PLURAL one {{…}}
  And then the string input named count_PLURAL is injected by the user with the pluralized bucket in the desired locale (one, other, many, etc.)
  This also requires mutation, and adding a new input.

API proposal

For C++ for 79

• MessageFormat2 :: Builder :: setFormattingLocale()

    /**

    * Sets the locale used by formatter factories (:number, :date,

    * etc.) for rendering output. Selector factories (plural rules)

    * continue to use the locale set via setLocale(). 

    * The formatting locale defaults to the same one set by setLocale().

    * @param locale The desired locale

    * @return       A reference to the builder.

    *

    * @internal ICU 79 technology preview

    * @deprecated This API is for technology preview only.

    */

    U_I18N_API Builder& setFormattingLocale(const Locale& locale);

• MessageFormat2 :: getFormattingLocale()

/**

* Acceses the formatting locale that this `MessageFormatter` object

* was created with.  If no formatting locale was explicitly set,

* returns the same locale as getLocale().

*

* @return A reference to the formatting locale.

*

* @internal ICU 79 technology preview

* @deprecated This API is for technology preview only.

*/

U_I18N_API const Locale& getFormattingLocale() { return formattingLocale; }

--

Steven R. Loomis

Code Hive Tx, LLC

https://codehivetx.us

[Tim Chevalier]

On 6/17/26 15:09, Steven Loomis wrote:
> Note that ICU4C does not expose the MF2 data model, so clients can’t
> do this kind of mutation just using ICU APIs. They would need an
> independent MF2 implementation that is capable of this mutation.

I'm confused about this point. ICU4C does expose the MF2 data model:
https://github.com/unicode-org/icu/blob/main/icu4c/source/i18n/unicode/messageformat2_data_model.h

Cheers,

Tim

[George Rhoten]

I support this proposal.  It fits in well with the design of NumberConcept in Unicode Inflection.  The language and the region specific locale formatting aren't necessarily the same.

George 

--
You received this message because you are subscribed to the Google Groups "icu-design" group.
To unsubscribe from this group and stop receiving emails from it, send an email to icu-design+...@unicode.org.
To view this discussion visit https://groups.google.com/a/unicode.org/d/msgid/icu-design/EB40CCEE-4A6D-4E69-AEBB-7A93B1B6CD3F%40unicode.org.
For more options, visit https://groups.google.com/a/unicode.org/d/optout.

--
You received this message because you are subscribed to the Google Groups "ICU - Team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to icu-team+u...@unicode.org.
To view this discussion visit https://groups.google.com/a/unicode.org/d/msgid/icu-team/EB40CCEE-4A6D-4E69-AEBB-7A93B1B6CD3F%40unicode.org.