Sorry about that @norkunas. Could #59967 (comment) be a solution? If so, we can document this.

As we were already introduce a getTranslatableSubject getter, we might introduce a corresponding new setter (and we should actually support TranslatableInterface)

As we were already introduce a getTranslatableSubject getter, we might introduce a corresponding new setter

I'm not really a fan of this for the reason @nicolas-grekas mentioned in #59967

I have no idea what his suggestion is about. It makes no sense for Email to implement TranslatableInterface.

On the other hand, supporting translatable subjects is probably a use case for any localized project (and would allow avoiding to inject the translator in each place creating an Email object to translate it before calling subject, just like TemplatedEmail is about avoiding to render the Twig template explicitly).

adds cross-cutting concerns to the base class (= combinatory explosion)

This was the specific reason I was referring to. I'm thinking to document #59967 (comment) as the best way to translate the subject. I get that it doesn't work if not using Twig, but in this case, you'd have to have an alternate system to translate the body/html - so why not translate subject within the same system.

Thank you @kbond.