translate="attributes"

[Zhang-Junzhi]

The spec says the translate attribute is used to specify whether an element's attribute values and the values of its Text node children are to be translated when the page is localized, or whether to leave them unchanged. It's all-or-nothing.

But there's middle ground use cases where we only want attributes to be translated while keeping content inside unchanged:

<!--We want the aria-label to be translatable but not the content inside the user-edited content-->
<div aria-label="something editor" contenteditable role="textbox" translate="???"></div>

So I suggest adding a new value "attributes" to the translate attribute.

[zcorpan]

Maybe browsers could avoid translating content in editing hosts? Are there other use cases except for contenteditable?

[Zhang-Junzhi]

Maybe browsers could avoid translating content in editing hosts? Are there other use cases except for contenteditable?

I haven't seen any spec paragraphs about the contenteditable attribute that mention translate. Conversely, the same applies.

My personal view is that perhaps enabling translation within contenteditable elements could also meet some needs(For example, the user intentionally wants to translate the content altogether after the edition is completed). So I believe it would be better not to prohibit the translation functionality of contenteditable.

The contenteditable use case I previously raised is widely used in rich media editors. So, I believe that even a sole use case like this might still be an adequate reason to support the new feature.

In response to non-contenteditable use cases: A non-contenteditable scenario that comes to my mind is: in a language learning webpage, some element displays the translation result, and this element has an aria-label attribute.