Re: [w3ctag/design-reviews] Unicode MessageFormat 2.0 (Issue #1042)

jyasskin left a comment (w3ctag/design-reviews#1042)

I'll post my review now, in case any of the minor notes can help while finalizing the spec. The soonest we can check whether there's TAG consensus on this is the week of March 17, which might be too late.

----

I appreciate the clarity in the stability guarantees and the design goals.

I _think_ the programming model is that, for each message in the code, the code author writes one MessageFormat 2.0 string in their language which seeds a translation database. Then the translator for a given locale writes a whole new MessageFormat 2.0 string representing the translation of that locale. Then at runtime, the code pulls that translated MF2 string out of the database and formats it with the appropriate dynamic values. This model is implied by documentation like https://messageformat.dev/docs/translators/, but AFAIC it's not explicitly stated anywhere, and it probably should be.

The specification overall looks solid and well-considered. I think we're more likely to have feedback for the Javascript integration in https://github.com/tc39/proposal-intl-messageformat, although I don't see any immediate problems with that either.

Some minor notes on the spec:

https://www.unicode.org/reports/tr35/dev/tr35-messageFormat.html#function uses "function" to refer to what I'd call a "function call" in other specs. This is a little inconsistent with https://www.unicode.org/reports/tr35/dev/tr35-messageFormat.html#default-functions, which uses "function" the way I'd expect. ["Function handler"](https://www.unicode.org/reports/tr35/dev/tr35-messageFormat.html#function-handler) also seems to have the meaning I'd associate with "function", but it seems to only be used with user-defined functions. This isn't a big deal, but maybe a clarifying note would fit somewhere.

"A message with markup that should not be copied:" uses "@can-copy" to mark the text that should _not_ be copied?

I'm concerned about how loose the "[resolved value](https://www.unicode.org/reports/tr35/dev/tr35-messageFormat.html#resolved-values)" interface is. Without care, specifications using resolved values will depend on attributes that aren't guaranteed to exist. Perhaps the extra detail in [the Intl proposal](https://github.com/tc39/proposal-intl-messageformat) will insulate the Web from this ambiguity.

In [option resolution](https://www.unicode.org/reports/tr35/dev/tr35-messageFormat.html#option-resolution), "If rv is a fallback value: If supported, emit a Bad Option error." doesn't say what to do if the BadOption error isn't supported.

"The resolution of markup MUST always succeed.", but it calls option resolution which can fail?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1042#issuecomment-2704094083
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1042/2704094083@github.com>