DOM Parts and Localization

[eemeli]

Hi. Would this be an appropriate forum for discussing the relationship between the DOM Parts proposal and localization? I hosted a breakout session at TPAC on DOM Localization, and unfortunately learned only afterwards that it was at the exact same time as the DOM Parts session.

The core idea of "DOM Localization" is to be able to extract localizable messages from HTML and to provide them separately for inclusion in the DOM, with different contents for each locale. As these messages may include tags, to me this sounds like it might be really close to the templates of DOM Parts, with the caveat that the structure won't always be the same: Even something as simple as Click <a>here</a> to continue will in some locales have the link at the start or end of the message, rather than in its middle. Sometimes the message structure will also change within a locale, depending on e.g. whether the count of some items is zero, one, or more.

Work on DOM localization builds on top of prior (and still current) work in TC39 introducing Intl.MessageFormat, and in the Unicode Consortium's MessageFormat WG, where we're defining "MessageFormat 2" as a new syntax and language for the localizable messages that all of the above requires. We're currently evolving said syntax due to in part feedback we got during TPAC, so everything's a bit in flux.

Would there be interest in considering something like MessageFormat 2 as a syntax for DOM Parts, and/or taking into account in that proposal localization aspects? Or would it be better that DOM Localization be presented as a wholly separate proposal? If there's interest, I'd be happy to participate in a real-time call about all this.

In case it's relevant, DOM localization is structurally very similar to how Firefox and other Mozilla products are currently localized, using Fluent rather than the technologies mentioned above.

[keithamus]

I think there's definitely something worth discussing here.

Is there more detail on how the localisation MessageFormat2 syntax ties in with the HTML syntax? In the example slides you have This <a href=/page>color</a> is gray which maps can be localised with {This {+a}colour{-a} is grey}. I presume the {+a}/{-a} are to partition the content of text that fits within the a tag? And the tag names must match?

[eemeli]

Is there more detail on how the localisation MessageFormat2 syntax ties in with the HTML syntax?

Yes and no. With Fluent, we have a solution to how everything could work, but I don't want to come into all this proposing that as the solution that should be taken for DOM Localization. At this stage I'm primarily interested in getting alignment on this being an interesting problem to solve, and not trying to lock in a solution.

In the example slides you have This <a href=/page>color</a> is gray which maps can be localised with {This {+a}colour{-a} is grey}. I presume the {+a}/{-a} are to partition the content of text that fits within the a tag? And the tag names must match?

Yes-ish. The examples in the presentation are intentionally minimal as there's a lot to all this, but the {+a}/{-a} do indeed primarily position and delimit the link text in that example. However, they could also contain contain values for localizable properties, such as {+a title=Foo} that would need to be merged into the <a href>.

In most messages, elements can be matched by name, but this isn't always the case if e.g. a message contains two links. With Fluent, the matching uses a property data-10n-key that must be set on the DOM <a> as well as the message's corresponding representation, but the details of what might be appropriate for a standardised approach need further consideration.