> so basically @mounirlamouri says that we should set lang/dir on the translated dom nodes even if it was not here before, and even if it's not the direct target.

Yes but “translated nodes” here means “every node that carries a `data-l10n-id` attribute”, which means that:
* it would not apply to the `<html>` element itself — so we’d still have to write some code to set the lang/dir attributes on the document element;
* we should set lang/dir attributes for **every** translated element — not only the argument of `mozL10n.translate()` — and I’m afraid it would have a very significant performance impact.

That’s why I proposed a simpler approach, where `mozL10n.translate(element)` would set the lang/dir attributes on `element` **only** (= the document element, by default) and only if the target `element` already has lang/dir attributes. I think it’d make sense but I’d prefer to get a WebAPI blessing first.

> the code would not kick in if window.frames.length is 0 anyway, so it would not slow down l10n.js for most applications. This would make l10n.js magically work for slide-based apps too ;)

If we can let `l10n.js` set the lang/dir attributes of the target element, I agree it would be nice to factorize this code and that would be a good reason for letting `l10n.js` handle frames; if we must leave lang/dir alone, then we couldn’t factorize much code because we’ll have to write this code anyway (it would only avoid the line with `mozL10n.translate()` but we’d still have to write the rest for every app).

> If that's too expensive to access and translate all frames, maybe we can add a data marker on the frames that need a translation?

I’d prefer to avoid adding new data attributes. Maybe we could think of a smart use of the `lang` attribute for this case?