1627363 - Provide a test helper for asserting about an elements localisation

Status: NEW

(Core :: Internationalization, enhancement, P3)

Description

[Mark Striemer [:mstriemer]]

In bug 1626937 there are some elements in the shadow DOM that used to be translated, but that no longer happens without explicitly connecting the root (which this element didn't do).

Writing a test for this element is tough since you can assert about the data-l10n-id but since fluent isn't tracking this element that attribute means nothing. Getting a test to fail when it isn't working would involve waiting for the element's text to change and then perhaps comparing it to document.l10n.formatValue(expectedId) (or in this case it would just timeout).

Instead of this it would be nice to have some common test helper that does a few sanity checks on top of just is(doc.l10n.getAttributes(el).id, "some-id", "l10n ID is set").

For my case I don't care much whether the fluent translation has occurred, but more so that it will happen at some point (so no need to await it and compare to the doc.l10n.formatValue() in my mind).

Something like assertTranslated(el, "some-id", { with: "args?" }) could be helpful. This helper could do the simple is check as above, but also check if the element's root is connected to fluent, or the element has been translated with doc.l10n.translateFragment() or some other fluent command.

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

This is an excellent idea. In particular it addresses the struggle with have with being able to verify the right state of the system (mostly via declarative DOM checks) and asynchronously translation application but without locking tests to work in en-US locale only (so, without hardcoding values).

We could produce several helpers:

1. assertL10nAttributes(elem, id, args);
2. (async) assertPendingTranslation(elem, id, args);

and so on.

I'll set P3 mostly because I cannot commit to work on this right now, but would be happy to mentor anyone interested.

Comment 2

[Axel Hecht [:Pike]]

I'm not sure this is a good first bug, given this is potentially hairy async programming.

There's also a bit of connection between the questions here, and the conversation with Gijs on Matrix about having the public API to add a root also hooking up the initial translateFragment?

I.e., there are two questions with the current API:

1. Is there or was there ever a translateFragment call on this node
2. Is there a DOMLocalization that has this node as a child of one of its roots

It might be OK to rephrase the second question to "Does the given DOMLocalization watch for changes to this node?", with the given loc defaulting to document.l10n.

There's also a third question, coming to think of it:

3. Is there no more than one DOMLocalization that watches for this element

Comment 3

[Zibi Braniecki [:zbraniecki][:gandalf]]

(In reply to Axel Hecht [:Pike] from comment #2)

There's also a bit of connection between the questions here, and the conversation with Gijs on Matrix about having the public API to add a root also hooking up the initial translateFragment?

I.e., there are two questions with the current API:

1. Is there or was there ever a translateFragment call on this node
2. Is there a DOMLocalization that has this node as a child of one of its roots

It might be OK to rephrase the second question to "Does the given DOMLocalization watch for changes to this node?", with the given loc defaulting to document.l10n.

This is a separate from DOM annotations being set properly.

As for your (1) and (2), this can be alternatively phrased on "Wait until the translation for this id/args in this l10n context gets applied on that node". This is what I suggested above.

There's also a third question, coming to think of it:

3. Is there no more than one DOMLocalization that watches for this element

This should not be possible to be exceeded as per https://searchfox.org/mozilla-central/source/dom/l10n/DOMLocalization.cpp#93-101

Comment 4

[Axel Hecht [:Pike]]

The third question is about different DOMLocalization instances battling over a single element. Which is what happened for the custom l10n object in the newtab code.