Allow for nested element localizations

[zbraniecki]

In Firefox Preferences I found an interesting case which may come in play in unison with #169.
Basically, the developer is localizing a widget as part of the sentence. It looks like this:

  <hbox align="center">
    <label>Firefox will</label>
    <menulist>
      <menupopup>
        <menuitem label="Remember history" value="remember"/>
        <menuitem label="Never remember history" value="dontremember"/>
        <menuitem label="Use custom settings for history" value="custom"/>
      </menupopup>
    </menulist>
    <label>.</label>
  </hbox>

One way to approach it would be to do something like:

  <hbox align="center">
    <label data-l10n-id="history-select">
      <menulist data-l10n-static>
        <menupopup>
          <menuitem data-l10n-id="history-remember" value="remember"/>
          <menuitem data-l10n-id="history-dontremember" value="dontremember"/>
          <menuitem data-l10n-id="history-custom" value="custom"/>
        </menupopup>
      </menulist>
    </label>
  </hbox>

history-select = Firefox will <menulist/>.

Not sure if this is the right approach, or what are alternatives. @Pike? @stasm?

[Pike]

Yuck. Before we go too much into the technical detail of solving this, we should make sure that UX really likes the way this works right now. @zbraniecki, can you use your connections there?

Spanish variants might be good to study, as they only have "Firefox" as pre. German UX also looks a tad weird.

I'm tempted to say that we should use a radio button as we do for Cookies and Site Data, now that pref panes scroll anyway?

[stasm]

A few technical notes: other than #169 which @zbraniecki mentions, this would also require translateElement to not break the identity of named elements. This is related to how fluent-dom collects all elements with data-l10n-id and then translates them in a batch. Nested elements with data-l10n-id must be preserved between the collection and the moment when the parent is translated.

The current revision of translateElement not only doesn't keep the identity but it also clones named elements shallowly—thus removing all nested children.

[stasm]

I'd prefer to put this on the back burner for now and find a different way to migrate the Firefox string in question to Fluent. I suspect that we'll eventually end up with preserving the identity of children in the overlays logic and that we'll make it possible to create interfaces like this one with Fluent. For now, however, I wouldn't like to rush the design nor the implementation of this feature. Let's try to collect more use-cases of when it would be useful, so that we can better understand what limitations the new design should be subject to.

[zbraniecki]

I'm very comfortable putting an implementation on the backburner. I'm a bit concerned about not having even a rough idea how we would solve it.

[stasm]

We do. Step 1: Remove the following line:

fluent.js/fluent-dom/src/overlay.js

Line 197 in de35e58

const clone = sourceChild.cloneNode(false);

Step 2: Write a lot of tests.

I don't have time for Step 2 right now.

[stasm]

Step 2 is also about understanding the consequences of keeping the identity. For instance, can developers rely on elements passed into translations if translations can remove them? Etc. I'd say we do have an idea how to solve these challenges but we need more use-cases and data to design them right. So that we don't end up solving the wrong problem.

[zbraniecki]

An example from Gecko where a tricky intermittent papercut is found to result from broken element identity by L10n Overlays - https://bugzilla.mozilla.org/show_bug.cgi?id=1643607#c6