– DRAFT –
DOM Localization

eemeli: (intro) from Mozilla, chairing the session

martin: chair of Internalization interest group

robwu: from Mozilla working on WebExtensions

carlos: working on WebExtensions

xfq: Fuqiao Xue, W3C i18n lead

others introduce themselves: Fuqia (saji on IRC), Ryusei, Daisuke, Mike

eemeli: (introduces MessageFormat and localization)

eemeli: 95-98% localization addressed by existing solutions; But we should not use "Number of unread messages: 3", but "You have 3 unread messages" (with many locale-specific variants)

eemeli: platform-specific differences, locale-specific differences not even known to the original developer creating a string

eemeli: E.g. in Finnish, he and she have the same word. We use suffixes to modify meanings of words. Localizations to Finnish use unnatural ways

eemeli: We are here today because we want to build systems to help with doing localization, helping people with finding this as the easy solution to serve their needs

eemeli: Fundamental part of this work, in 2019, in JavaScript and the web platform, none of the existing formats support all needs of localization. MessageFormat working group part of unicode ... committee, working on Unicode MessageFormat spec, finished earlier this year

eemeli: (...) not just important; interaction with HTML is also important, file format also needed

eemeli: at Mozilla we are well positioned for this, because this is already how we are localizing Firefox, Thunderbird, our products

Slideset: https://docs.google.com/presentation/d/1ON2yeocyDSVr8r0cg8ZlhgpFfsvloznq1pJqYSADJs8/edit?usp=sharing and archived PDF copy

eemeli: (points to screen showing example of what it looks like in Firefox)

eemeli: reference to established messages, data-l10n-id in HTML to refer to messages in the loaded resources, data-l10n-args to pass arguments to localized messages. Combined with ftl file
… term reference in ftl file
… example of pluralization support in the ftl format

thomas: I learned the hard way that plural is not as simple as singular, plural

eemeli: the example I copied in the doc uses the literal value "1", but in practice many use O and I

eemeli: the example shown is how it works in Firefox. Not exactly what we will be proposing, but pretty close

eemeli: we made choices in Firefox that we would have done differently today; these learnings we also apply here

thomas: CSS content localization?

carlos: CSS with attr() can be used

thomas: Does not work in all scenarios

eemeli: envisioning that the system works in the client, but can also be used in server-side rendering if desired

<tomayac> Would need to look into it in more detail, but `::scroll-marker` might not work with `attr()`: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/::scroll-marker

eemeli: in experience with Firefox and other products such as mozilla.org, these use the same localization system, and they end up doing a lot of the work in the client, which is enough

leo: biggest lessons?

eemeli: Biggest challenges in HTML part of it, async processes. Localization resource marked as potentially needed. When formatting, the formatting call is async. Processes resources async, need fallback processing, which can end up resetting the locale; ... may require loading many files from disk or network. Adding complexity to functions needing to be async. This is the biggest challenge in Firefox
… data-dash is used as a prefix, but on the web we could define an attribute for that
… (showing example on screen) Same example as before, but without data- prefix, and arguments with prefix as attribute name
… different syntax as Fluent. Need a file format. Challenge with existing format such as JSON is that it does not support newlines in JSON. In MessageFormat simple syntax can need multiple lines, in JSON it could be on one line with a separator, but becomes unreadable.
… Big questions: (1) Should we do this? (2) Is Internationalization WG the right venue for the file format, or is there a better place? (3) Where do we draw the line where this can do work? E.g. CSS example we just discussed. There are ways we can make it work, but maybe not the same mechanisms we want for the web platform. Do we want to build a general purpose tool or something specific for localization? In the spec translatable

attributes. Being able to specify class name of element could be powerful, but maybe too powerful. Capabilities for edge cases

thomas: legal requirements, in EU cookie banner may be needed, in other locations not needed, is that too much for this proposal? Having on/off switch for a block

eemeli: specific to locale, not localization

xfq: some markup specific to locales, can it be there?

eemeli: What sort of transform are we comfortable introducing? E.g. cookie banner dialog could have a custom element that might or may be included, and in the localization we can conditionally show it
… this discussion has not happened yet. Figuring out the next steps and places for this next steps
… Maybe a W3 group for File format, Unicode not a fitting place for it

that's kind of related to our guidelines at https://www.w3.org/TR/localizable-manifests/

eemeli: on big question 1, answer probably yes (we should work on localization as a capability of the web platform)

leo: what does the fallback logic look like?

eemeli: Details to be specified. In Firefox we have a solution that works for Fluent. We started with a system where we load a resource, if it is missing we get a 404 internally, but consider that locale as a whole to be corrupt, and switch to a completely different locale, but turns out to be a bad failure mode
… what we do currently, if no resource is available, we do fallbacks per individual messages
… space for how much need to be specified in the standard, or left for the user of the system
… locale negotiation could be completely specified, or building blocks can be simple, simple for users to provide fallbacks
… If we do preprocessing, then we do not need to do stuff at runtime, but removes flexibility for doing intelligent things at runtime

mike: Not clear to me client-side vs server-side. Examples of server-side plus client-side can help with making a case. Concerned about network traffic needed to include resources for different locales, more bits over the wire, memory usage, CPU usage, low end devices or bad connectivity. Also nervous about bundling HTML in the resource file (cookie banner example)

eemeli: related very closely to the question of how much power we want here. To reduce concern, elements could be limited to inline elements (no block-level elements).

mike: Impact on performance metrics
… capabilities all great, request to update explainer to clarify these details, when to choose one approach over another. E.g. image selection, how that affects ability to preload resources

eemeli: question of whether we do support live reload of language, or require a full reload

carlos: About the attributes, coupling the implementation with the locale file, elements/attributes being overwritten. Would it make sense for messages to be reused, to allow attributes to get a specific message directly

eemeli: we could do that

carlos: Would make it easier for devs to do community translations

eemeli: could require specific HTML opt in to declare which HTML attributes are localizable, aria-labels.

thomas: declarative shadow DOM; anything that could break? Probably fine, thoughts?

eemeli: I am not aware of places where it could break with declarative shadow DOM
… conceptually do the same thing as with CSS, shouldn't break

carlos: How do you deal with DOM mutations, such as setting innerHTML or appending elements

eemeli: multiple options. Could be per-element when specific (data-)attributes change, or observing everything under the tree, preventing overriding elements underneath, whether we are interested in localization everything at once (localization frame)... no clear answer. Gut feeling is mutating localized DOM element without touching the localization attribute is fine
… pre-existing content. Do we allow creation or removal, or re-ordering of elements

carlos: properties such as the innerHTML getter would return whatever was applied by localization?

eemeli: yes

thomas: blocking attribute maybe

eemeli: could also be a DocumentFragment that you then insert in the document

thomas: is it mentioned somewhere?

eemeli: I think so

carlos: How would you deal with changes to resource files in the header, dynamically?

eemeli: Treat as an async JS call, and/or emit an event whenever the current set of known localization resources have loaded

robwu: Something like Font loading API?

eemeli: not aware of that API, but could be

eemeli: on fallback, behavior should be user specifiable.

martin: On the question of whether the Internationalization WG is an appropriate forum. On paper I am a member of that group, but I don't participate much due to time zones. One thing to consider is that this would be a big item. The Internationalization WG may be more used to doing smaller things all over the place by necessity. They have bigger work items, but this is quite specific requiring internationalization, but also requires

not knowing just how HTML div works, but shadow DOM etc.

xfq: i18n group has incubated technical things in the past, and proposed to HTML

eemeli: We are at the end of the meeting, we should move over to the other room