There are only two values permitted: yes and no.

The wikitext input should be trimmed and downcased. If it is matching the expected values, that attribute shoud be issued.

Benevolent input of wikitext editors should be granted: "0" and "1" and "-" might be translated. Perhaps true and false as well. Also <span translate> and translate="" and translate="translate" shold be converted into translate="yes" to satisfy all our XML and HTML dialects.

Seems reasonable. Probably not a "we'll do it right now" due to Content-Platform-Team backlog, but this wouldn't be too hard to add to the Sanitizer in a way which would work for both the legacy parser and parsoid. I'd lean strongly against a lot of the normalizing suggested in T161486#6803542 though. Authors should be encouraged to write correct syntax, and the way we communicate that clearly is by things *not* working if they use the wrong syntax. We should allow 'yes' and 'no' and strip or display a visible error for the other options, as the Sanitizer already does for other bogus attribute values.

Note that the parent task T273873: <syntaxhighlight> should always declare translate="no" supercedes and *does not require this*, since extension output can/does bypass the Sanitizer. Since source code is probably the most logical use of this tag (wikis have other mechanisms for translation and today don't typically use automatic machine translation services directly on the output HTML) that task should probably be done before we consider adding this as a wikitext feature.

For now, would it make sense to have common class names to apply, e.g. translate-yes and translate-no? That'd be useful for T371098: Providing machine translation for Community Wishlist mainspace pages on demand