Bugzilla

After some more review and thought triggered by hitting this issue myself when working on bug 1734221, I'm starting to think that the root issue here is not whether `aria-valuetext` is localisable or not, it's that the original solution for bug 922577 has resulted in our current "feature" of resetting all localisable attributes when a node is localised. A particularly code-smell-y aspect of this is that the node's value is _not_ reset even when it's void (though there are good reasons for this current behaviour). Changing these aspects of DOM Localization in general would be breaking changes, so I'd very much prefer to figure out a more specific solution.

In general, DOM Localization does not really play nice when anyone else wants to also control the value of a localisable attribute. Furthermore, DOM Localization is fully async, and guides usage away from directly relying on any localised value. This counts as a feature, though it does make certain usage patterns (somewhat intentionally) more difficult.

In some cases it might be possible to circumvent issues with generally localisable by adding some explicit or implicit way for DOM Localization to ignore them, but this would only make the corner-case smaller and more surprising. With our current API, it would be better to acknowledge that DOM Localization is not suitable for any such mixed use, in particular when the string value of a possibly-localised attribute or contents of an element may be used by other code.

However, `aria-valuetext` is indeed a bit special, as it's meant to directly reflect the node's _value_, and as mentioned we're not treating the value and attributes the same when resetting them. So given its very limited usage, the quirky DOM Localization-specific results of considering an attribute as "localisable", and the nature of `aria-valuetext`, I'd like to update my position above to its opposite from what I stated previously, and recommend that despite `aria-valuetext` being in theory "localisable", we should not consider it so.

This would still allow for the attribute to be localised by including an explicit `data-l10n-attrs="aria-valuetext"`. While this bug has been open, one such usage has been added to m-c, via bug 1779625. That'll need to be patched before landing the patch already attached to this bug.

Jamie, Erik, do you concur?

After some more review and thought triggered by hitting this issue myself when working on bug 1734221, I'm starting to think that the root issue here is not whether `aria-valuetext` is localisable or not, it's that the original solution for bug 922577 has resulted in our current "feature" of resetting all localisable attributes when a node is localised. A particularly code-smell-y aspect of this is that the node's value is _not_ reset even when it's void (though there are good reasons for this current behaviour). Changing these aspects of DOM Localization in general would be breaking changes, so I'd very much prefer to figure out a more specific solution.

In general, DOM Localization does not really play nice when anyone else wants to also control the value of a localisable attribute. Furthermore, DOM Localization is fully async, and guides usage away from directly relying on any localised value. This counts as a feature, though it does make certain usage patterns (somewhat intentionally) more difficult.

In some cases it might be possible to circumvent issues with generally localisable attributes by adding some explicit or implicit way for DOM Localization to ignore them, but this would only make the corner-case smaller and more surprising. With our current API, it would be better to acknowledge that DOM Localization is not suitable for any such mixed use, in particular when the string value of a possibly-localised attribute or contents of an element may be used by other code.

However, `aria-valuetext` is indeed a bit special, as it's meant to directly reflect the node's _value_, and as mentioned we're not treating the value and attributes the same when resetting them. So given its very limited usage, the quirky DOM Localization-specific results of considering an attribute as "localisable", and the nature of `aria-valuetext`, I'd like to update my position above to its opposite from what I stated previously, and recommend that despite `aria-valuetext` being in theory "localisable", we should not consider it so.

This would still allow for the attribute to be localised by including an explicit `data-l10n-attrs="aria-valuetext"`. While this bug has been open, one such usage has been added to m-c, via bug 1779625. That'll need to be patched before landing the patch already attached to this bug.

Jamie, Erik, do you concur?