Support complex DOM trees in overlays

[stasm]

Sometimes, the line between UI localization and content localization is thin. A good example is netError.dtd in Gecko:

<!ENTITY dnsNotFound.longDesc1 "
<strong>If that address is correct, here are three other things you can try:</strong>
<ul>
  <li>Try again later.</li>
  <li>Check your network connection.</li>
  <li>If you are connected but behind a firewall, check that &brandShortName; has permission to access the Web.</li>
</ul>
">

Clearly in this case, the UI benefits from a more structured translation. In the past, we focused the design of Fluent on short messages with little structure and we avoided longer forms. With UIs like netError, we might want to find a middle-ground solution for conveniently localizing UI which features longer text and some structure.

The implementation of overlays in fluent-dom currently supports two groups of elements:

1. elements named with the data-l10n-name attribute, as long as a corresponding element is present in the source, and
2. a short list of inline text-level elements as defined by the HTML spec.

Furthermore the current implementation doesn't allow any nested elements. A <li> inside of a <p> wouldn't work even if these elements were allowed.

I'd like to start a discussion about what it would take to support UIs like netError.dtd. A few questions to get us started:

1. Should we allow more elements by default, including block elements? Any translation would be free to use them even if they're not present in the source.
2. How to handle errors in nesting order, if nested elements are allowed?
3. Should we encourage static analysis tools to verify the structure of the DOM found in the translations by comparing it to the reference?
4. Should text-level elements by exempt from this validation step?

[zbraniecki]

Thanks for kicking it off! My first thought is that we should limit such DOM Fragments to be white-listed by the developer. In other words, while I expect text level semantics to be allowed in every element, I expect such model to be only allowed when the developer specifically sets some attribute to say data-l10n-mode="dom-fragment" or something similar.

[Pike]

I agree that we should do this, and that we should make it opt-in.

1. Should we allow more elements by default, including block elements? Any translation would be free to use them even if they're not present in the source.

I'd say no. As Zibi said, I'd make this opt-in.

2. How to handle errors in nesting order, if nested elements are allowed?

Can we classify these errors?

Might also depend on whether opt-in is generic, or specific. Like, data-l10n-mode="fragment" vs data-l10n-fragments="p, ul>li", where the latter would be allow only a specific form of custom element hierarchy.

3. Should we encourage static analysis tools to verify the structure of the DOM found in the translations by comparing it to the reference?

Yep, totally.

4. Should text-level elements by exempt from this validation step?

I think so, yes.

[zbraniecki]

Example of a use case: https://bugzilla.mozilla.org/show_bug.cgi?id=1626064