aurelia-i18n breaks standard content projection done by aurelia

[mar9000]

I'm submitting a feature request

• Library Version: 1.3.0
• Operating System: gist run
• Browser: Firefox 50.1.0

Current behavior:
As you can see in this gist https://gist.run/?id=c7e1c50ba6073c7c27c0fd2bb277e002 the last checkbox is not displayed correctly. This depends on 2 things, one is the the implementation of the element md-checkbox:

<template>
  <input type="checkbox" id="${controlId}" checked.bind="mdChecked" matcher.bind="mdMatcher" model.bind="mdModel" ref="checkbox" />
  <label for="${controlId}">
    <slot></slot>
  </label>
</template>

See https://github.com/aurelia-ui-toolkits/aurelia-materialize-bridge/blob/master/src/checkbox/checkbox.html
The ladder is the implementation of i18n.updateValue() that in case of translation of textContent executes:

node._newChild = newChild;
while (node.firstChild) {
          node.removeChild(node.firstChild);
}

removing the internal implementation of the checkbox (input and label) at runtime.
See also discussion at the end of this issue #197 (comment) .

Workaround:
As one can see from the same gist the second-last checkbox is working because the element content (the label value) has been wrapped with a span element and the translation moved to this element.

Expected/desired behavior:
As aurelia is actually projecting the element content to the slot element, aurelia-i18n should projects the textContent translation to the slot preserving the internal representation of the custom element. At the moment a developer using aurelia-i18n should be aware of the internal implementation of an certain element when using textContent translation.

[zewa666]

@mar9000 sorry for letting you wait so long. I did some research and I think we can handle those scenarios.
What would be helpful for the first step is to gather some examples we can test a future implementation against. I do envision something like this:

<!-- default slot -->
<div class="simple-tag">
    <div class="header">
      Hello, my name is
    </div>
    <div class="name"><slot></slot></div>
</div>

<!-- default slot, no container -->
<div class="simple-tag">
    <div class="header">
      Hello, my name is
    </div>
    <slot></slot>
</div>

<!-- multiple named slots -->
<div class="name-tag">
    <div class="header">
      Hello, my name is
    </div>
    <slot name="firstname"></slot>
    <slot name="lastname"></slot>
</div>

are those somewhat what you'd expect? Any other concrete examples are welcome

[mar9000]

@zewa666 those are components' internal implementations we are going to test right?
In this case that's what I was thinking about. In fact the first example it's equal to the checkbox implementation from aurelia-materialize-bridge. And names slots it's another important case even if I did not mention at first. More info when I could se the test together with the component use (where i18n will be used) and component implementation.

[zewa666]

When we talk about Slots it also means we do support all standard scenarios like text, pre/append and html. The attribute would then act as usual by replacing/modifying all the slot contents and placing the new. So I guess the first case should be doable pretty soon.

The multi slot is something I'm not sure yet how to support since it would require a totally new syntax. How should the t attribute know, where to put what. Any ideas about that?

Maybe it would also make sense to split this into two issues so things can be delivered sooner? I guess the default slot is something that happens fairly more often then a named case

[mar9000]

The simple slot example from the aurelia doc (http://aurelia.io/hub.html#/doc/article/aurelia/templating/latest/templating-content-projection/2) I think should work this way (supposing that the name Ralphie has a translation in every language):

<name-tag t="ralphie">
  Ralphie
</name-tag>

At runtime the translation of ralphie should substitute <slot></slot> the same way that without translation <slot></slot> is substituted by Ralphie.

The named slots example I think is working correctly, see this new gist https://gist.run/?id=65062bf05b1d4cddcd1c7c6d902b0ceb , at least the basic test case. Don't know the case with pre/post append, inner html etc.

[DickvdBrink]

Exactly the same issue here, the use case @mar9000 above and @zewa666's "default slot, no container" are my use cases.

edit: I can work around it for now btw, but would be nice to see it fixed someday.
I do not really care about pre/append and html, I use text in this case but text/html should be pretty similar I think.