Meeting minutes
DOM Localization
eemeli: I've been working on localization systems for about a decade, but not so much in W3C/WHATWG space.
eemeli: [Goes through slides, explains current flow and possible future flow.]
eemeli: Main goal is to enable client-side localization without scripting.
eemeli: Unicode is working on MessageFormat 2, which provides some of the infrastructure needed for declarative localization
eemeli: [asking the room] Should we do this? And how should we do this if so?
Domenic: I would love to learn more about the use case. In particular why we need client-side localization and cannot use the server.
eemeli: We have an implementation of this functionality in Firefox, called Fluent.
Domenic: I think the experience would be better with server-side translated content.
Mu-An: If localization is not thought about early it's really hard to add it to a website. Having it standardized would make adoption easier.
Domenic: If we implemented this in the server you could get the same developer experience, but a better user experience.
Carlos: many websites already do this client-side, but they don't have a good implementation of this functionality.
Carlos: Are localization files load-blocking?
eemeli: I think that's a question we have to answer.
addison: We clearly have web servers that can handle this. Proof is out there. But there are other kinds of web apps that could use this.
littledan: Organization-wise it might be nice to be able to organize your content in this way.
annevk: I think we should approach this differently. We should start out with a web components library and see if that gets adopted widely.
<addison> "Fluent"
annevk: We would also need new primitives in the DOM to do this properly, such as DOM parts.
Domenic: Not entirely sure we need DOM parts for this.
Domenic: A question here would be how complex the DOM mutations are going to be?
[littledan mentioned some more advanced features of MessageFormat 2 I missed, but they would complicate it a bit more.]
Thomas: DOM structure has to stay the same.
littledan: At what point does it make sense to add it to the browser?
littledan: is the locale-negotiation driven by the browser or the website?
Mu-An: Maybe there could be more indication in the HTML to allow for different links for instance, depending on the language.
annevk: Is there a way for an attribute to reference something in MessageFormat 2?
[littledan helpfully clarifies]
eemeli: That's an open question.
Thomas: I think typically you'd localize everything
eemeli: I can imagine certain scenarios
[<img alt>?]
[Some discussion about design particulars.]
Domenic: [suggests using ID instead of l10n attribute]
Thomas: that might be problematic as currently the value of that attribute is a hash of what is localized
eemeli: That's probably still malleable and using ID might be good
Carlos: potentially we could use Selectors, not sure about perf
Domenic: it seems like a separate namespace for identifying a piece of localizable content has a bunch of benefits based on this discussion
Thomas: It's kinda like ARIA where you want to have your own set of attributes
<hsivonen> only "hash" got minuted, but it was an important point that it's common to have a retranslation trigger process where any change to the original (the language that developers write and that is the source of translation) requires a change of the localization key (not necessary a hash, could be appending a number).
littledan: One thing that's kinda missing from here is how you pass parameters in. Not sure how you do this in Fluent?
eemeli: [explains, finding Fluent documentation left as an exercise for the reader]
Domenic: fairly repeatable process for adding platform features. 1) Motivate use cases better. 2) Going through the tricky cases and identify what your proposed solution is.
eemeli: Intentionally came with an incomplete proposal to find collaborators to finish it.
Thomas: I think it's worth solving. Lots of legacy code that's incompatible.
RRSAgent: make minutes