@stof can you review this?

Instead of this, which adds cross-cutting concerns to the base class (= combinatory explosion), what about allowing Email objects to implement TranslatableInterface?

So the trans method would act as a subject getter?

Hum, maybe not, I thing I had something else in mind ("static" instead of "string" as return type):

interface TranslatableInterface{publicfunctiontrans(TranslatorInterface$translator, ?string$locale =null):static;}

🤔

For me it doesn't matter if I'd need to call trans or translatableSubject, still it will need to be stored as it's done now, no?

What about having the existing subject accept a stringable object? Then, in the listener (or a translation specific one), check for an instance of TranslatableMessage and translate?

What about having the existing subject accept a stringable object? Then, in the listener (or a translation specific one), check for an instance of TranslatableMessage and translate?

If argument widening is not a BC break then sure

What about having the existing subject accept a stringable object?

Done.

Thank you@norkunas.

Hum, maybe not, I thing I had something else in mind ("static" instead of "string" as return type):

interface TranslatableInterface{    public function trans(TranslatorInterface $translator, ?string $locale = null): static;}

This does not make sense. The return value ofTranslatableInterface::trans is the translated text, which must be a string, not an instance of the current class (it would be impossible to implement that interface properly)

@norkunas, without this pr, you could achieve subject translation in the template I think?

{%do email.setSubject(...translate...) %}

@norkunas, without this pr, you could achieve subject translation in the template I think?

{%do email.setSubject(...translate...) %}

This looks like a workaround :)