Implementations SHOULD provide mechanisms for users to use user-defined function handlers for default functions

[eemeli]

As reported by Matt O'Conor on Slack:

Hello my fellow message-format friends!

we're trying to decouple the formatting locale from the selection locale in our MF2 wrapper. We want en-US number formatting but locale-correct plural selection (Russian few/many, etc.). We tried setting the MessageFormatter locale to the message locale and registering custom en-US-pinned formatters for :number/:integer via setFunctionRegistry(). But lookupFormatterFactory() in ICU 78 checks the standard registry before the custom one, so built-in formatters always win and ours are never reached.

Is there a recommended way to override a built-in formatter while keeping the built-in selector? Or a different pattern for "format in locale A, select in locale B"

Let me know! Thanks

And my reply:

Filing a bug in the ICU issue tracker does seem appropriate for this, as overriding the default :number and :integer functions should be possible. We don't have explicit spec language to ensure that, but I'll submit a spec PR shortly to that effect.

This PR adds a new normative SHOULD to help avoid this problem recurring, as it should be possible to override default function handlers.

[moconor]

To add a bit more detail for the relevant use-case:

Bloomberg requires US formatted dates, numbers, and times. It is a problem we are very much trying to solve, but it will require a lot more work before we can universally enable locale-sensitive formatting across the firm. It has been the case for so long that therein lies material risk that dates would be misinterpreted since even non-US clients have come to expect the US date format on the Terminal. For financial data and transactions, this potential ambiguity is sort of unacceptable so we need a very robust release control plan and phased rollout that we're not in a good position to do right now. Therefore, we require the split-locale formatting and plural selection.

[moconor]

The relevant bit of code that is preventing my custom functions from working would seem to be this https://github.com/unicode-org/icu/blob/426cea1b85e82e632dc5c0b35c7d329c0eb4af7b/icu4c/source/i18n/messageformat2_formatter.cpp#L319

Since there is already a built-in function, it is always returned as-is and the custom function is never reached. I would think a simple-fix would be to return the custom function first if it happens to exist. But that may have unintended consequences.

[mihnita]

We had a very long thread about this on Slack.
And we are very far from any agreement.

I think this should start with a design doc, or at least an issue, where we discuss pros and cons.
Not a PR changing the spec out of nowhere without any history and any tracking of what was discussed.

[aphillips]

I think "SHOULD" is overdoing it. An implementation that doesn't provide such a mechanism is still conformant. I'd even avoid normative language here.

Also I'd probably allow for tailoring.

Note that I'm not arguing against this proposal. I have many times needed to override the behavior of the default implementation without explicitly using a namespaced replacement because I wanted to avoid creating messages that don't work without custom code installed.

Suggested change

	Implementations SHOULD provide mechanisms for users to
	use user-defined _function handlers_ for _default functions_.
	Implementations often provide a mechanism to tailor performance or
	use user-defined _functions handlers_ for _default functions_.
	This allows users to modify the behavior or output of the _default functions_
	without writing _messages_ that use custom syntax.

[mihnita]

I will create a ticket and copy-paste there the discussion we had in Slack.
Not summarize it, but exact copy-paste, so there is no room for interpretation (other than what happens by default in written communication, in a chat, which I don't see as a good medium for well thought-out discutions :-)