Allow nested localizable elements (Item 8)

[zbraniecki]

Stas suggested postponing Item 8 since he's worried about the consequences of adding it and the item is not required for any other item to work and we don't know if there's any use-case for it right now.

This issue is meant to discuss the merits of that proposal and find use-cases if possible.

[Pike]

8. Allow nested localizable elements

As a developer, I want to be able to build nested structures of localizable
elements, each with its own data-l10n-id.

<div data-l10n-id="key1">
  <menulist>
    <menuitem data-l10n-id="menuitem1"/>
    <menuitem data-l10n-id="menuitem2"/>
    <menuitem data-l10n-id="menuitem3"/>
  </menulist>
</div>

key1 = Always <menulist/> when opening a new tab.
menuitem1 = sing
menuitem2 = blink
menuitem3 = play a sound 

[Pike]

In case you wonder wth, I pulled in the current state of the proposal so that we have it on one page here.

My take here is that these UXes are hard to localize either way. You have effectively two sides to look at it:

One is that the whole UX should be in one fluent message, so the localizer can understand it.

Another is that the localizer isn't going to understand the whole UX, in particular in cases where the DOM denotes strings that are written in sequence, but shown in parallel. Like in this drop-down example. And that localizing such a UX in chunks would be easier for non-technical people.

My opinion based on absolutely nothing but speculation is that technical people that know DOM, and perhaps have written an HTML form before, would more likely make mistakes in the chunked form. And that non-technical people would make mistakes more likely in the full-blown-string form.

That opinion would like to have a peer-opinion on which group had an easier time fixing the mistakes they make. But I don't have one here.

Looping in @flodolo and @Delphine for more localizer stories.

[flodolo]

A single string exposing all the HTML goop is a lot easier to break, and given the technical level of most localizers these days (compared to 10 years ago), I'd stay away from it.

I don't have a problem with the chunked version. The only risk is when we add a new option, let's say a year after the rest has been translated. Luckily we have section comments, and we can try to mitigate that risk.

[Delphine]

Sorry, this totally fell through the cracks.
I also think the chunk form would be better, given most localizers aren't technical at all (and very often / easily "break" things because of that).

[zbraniecki]

Thank you @flodolo and @Delphine !

To be clear, the example above, as "chunk form" would look like this:

<div data-l10n-id="key1">
  <menulist>
    <menuitem/>
    <menuitem/>
    <menuitem/>
  </menulist>
</div>

key1 = Always 
    <menulist>
        <menuitem>sing</menuitem>
        <menuitem>blink</menuitem>
        <menuitem>play a sound</menuitem>
    </menulist>
    when opening a new tab.

Assuming we allow for automatching of elements (#5). Without it it'll be:

<div data-l10n-id="key1">
  <menulist data-l10n-name="menu">
    <menuitem data-l10n-name="item1"/>
    <menuitem data-l10n-name="item2"/>
    <menuitem data-l10n-name="item3"/>
  </menulist>
</div>

key1 = Always 
    <menulist data-l10n-name="menu">
        <menuitem data-l10n-name="item1">sing</menuitem>
        <menuitem data-l10n-name="item2">blink</menuitem>
        <menuitem data-l10n-name="item3">play a sound</menuitem>
    </menulist>
    when opening a new tab.

I take your position as - this (either version?) is better than Comment 1 example in this thread.

[flodolo]

No, the chuncked form (split up into pieces) is exactly the example in comment 1.

[zbraniecki]

In which case, without #5 we'd end up with:

<div data-l10n-id="key1">
  <menulist data-l10n-name="menu">
    <menuitem data-l10n-name="item1" data-l10n-id="menuitem1" data-l10n-opaque="true"/>
    <menuitem data-l10n-name="item2" data-l10n-id="menuitem2" data-l10n-opaque="true"/>
    <menuitem data-l10n-name="item3" data-l10n-id="menuitem3" data-l10n-opaque="true"/>
  </menulist>
</div>

key1 = Always
    <menulist data-l10n-name="menu">
      <menuitem data-l10n-name="item1"/>
      <menuitem data-l10n-name="item2"/>
      <menuitem data-l10n-name="item3"/>
    </menulist>
    when opening a new tab.

menuitem1 = sing
menuitem2 = blink
menuitem3 = play a sound 

[stasm]

I would like to point out that we can still start without this feature and add it later, once we've seen how often this actually shows up in practice and how hard it is for localizers to get it right. For the time being, I advocate for only allowing the following form:

<div data-l10n-id="key1">
  <menulist>
    <menuitem/>
    <menuitem/>
    <menuitem/>
  </menulist>
</div>

key1 = Always 
    <menulist>
        <menuitem>sing</menuitem>
        <menuitem>blink</menuitem>
        <menuitem>play a sound</menuitem>
    </menulist>
    when opening a new tab.

I understand that the "chunked" form might be easier to non-technical localizers, but I would also like to consider the cognitive cost of adding more features to solve rare use-cases before we fix this.

[Pike]

    <menuitem data-l10n-name="item1" data-l10n-id="menuitem1" data-l10n-opaque="true"/>

I filed #15 to talk about the actual semantics, though, it might be that we don't need a new ticket, but this ticket is actually talking about the semantics.

I think that data-l10n-id="menuitem1"is equivalent to data-l10n-name="^^menuitem1" data-l10n-id="menuitem1" data-l10n-opaque="true".

The ^^ isn't meant seriously, it's just my attempt to indicate that the namespace of data-l10n-id is separate from that of data-l10n-name (and id in #14).