Just out of curiosity, do you have any examples where you have aTranslatable message, that shouldn't be translated?

Don't get me wrong but to me it really smells. ATranslatable object should inherently betranslatable. Setting thedomain to false does not really tell me that it shouldn't be translated, rather I would expect a "default" domain to be used like "messages".

But maybe some examples would clear things up for me why this path was chosen.

Thanks in advance! 🙏🏻

Setting thedomain to false does not really tell me that it shouldn't be translated, rather I would expect a "default" domain to be used like "messages".

Let's just answer this point first@mdeboer, it's the purpose of theNULL domain, you can find it in a lot of "domain" options likehttps://symfony.com/doc/current/reference/forms/types/form.html#translation-domain

Just out of curiosity, do you have any examples where you have aTranslatable message, that shouldn't be translated?

Don't get me wrong but to me it really smells. ATranslatable object should inherently betranslatable.

Sure, for instanceEasyAdmin always translate his labels, title, flash message, and more
https://github.com/EasyCorp/EasyAdminBundle/blob/4.x/templates/flash_messages.html.twig#L12
It use messages or EasyAdminBundle as default translation domains based on the context, but support usingTranslatable object in order to use another domain but doesn't support disabling the translation.

Maybe the right behavior would be:

• to not translate by default
• to ask users to pass translatableMessage instead

but:

• it's a big BC break
• when 99% of labels asked to be translated it ask addingt() everywhere

I find it simpler to allowfalse as translation_domain for such library ; especially because it's not the first library I saw with this "translate by default"...

Thanks for your reply@VincentLanglet

I understand that in case of EasyAdmin it is easier to allow this change, but imho this is a design flaw in EasyAdmin. Why should the framework bend the rules and accommodate this bad design pattern?

Wouldn't something like Rector be of use to refactor EasyAdmin?

Or maybe introduce something like anUntranslatableMessage?

Thanks for your reply@VincentLanglet

I understand that in case of EasyAdmin it is easier to allow this change, but imho this is a design flaw in EasyAdmin. Why should the framework bend the rules and accommodate this bad design pattern?

Wouldn't something like Rector be of use to refactor EasyAdmin?

No, because

• it's mainly translated in the view which are twig templates
• such change would be an HARD BC-break

And while it could be considered as a design flaw, be aware that

• such libs was implemented before the introduction of translatable interface
• it could also be considered as a useful shortcut to automatically translate text when it's the case in 99%.

For instance, form labels are translated by default by Symfony, and they allow a false translation domain now, but you could use the same argument to say it shouldn't translate and wait for TranslateMessage in order to produce a translation, or you should pass the label already-translated.

Or maybe introduce something like anUntranslatableMessage?

Might be better indeed
I update the PR with aNonTranslatableMessage@mdeboer

(cc@nicolas-grekas if you want to re-review since the whole PR changed).

I am not convinced that this really is the way to go. Having something passed around that implements an interface calledTranslatableInterface which then ends up not being translated is unexpected behaviour to me. Thus I am 👎 on adding thisNonTranslatableMessage class.

I am not convinced that this really is the way to go. Having something passed around that implements an interface calledTranslatableInterface which then ends up not being translated is unexpected behaviour to me. Thus I am 👎 on adding thisNonTranslatableMessage class.

What alternative do you propose then for#60935 (comment) ?@xabbuh

Moreover this is still an implementation which can be done in the userland code, but it would be useful to provide it by default, in the same way symfony provides IdentityTranslator which is described with the comment:

IdentityTranslator does not translate anything.

The issue you outline in#60935 (comment) should be adressed in EasyAdminBundle and if it's simply shipping theNonTranslatableMessage class IMO.

The issue you outline in#60935 (comment) should be adressed in EasyAdminBundle and if it's simply shipping theNonTranslatableMessage class IMO.

So instead of creating a NonTranslatableMessage in Symfony, with a really generic behavior of "Keeping the message as if even if someone try to translate it later", you recommend to add this class in every bundle with this need. That seems odd to me :/.

EasyAdminBundle is not the only one bundle with thetranslate by default behavior.

Seems like a classic behavior of Symfony to me when providing an interface to often

• Give the real implementation
• Provide a stub/fixed/basic implementation

If theNonTranslatableMessage does not makes sens, the IdentityTranslator shouldn't have a lot more.

That could also allows to simplify code for some libs when you currently have to supportstring|TranslatableInterface now you could only supportTranslatableInterface...

LiteralMessage? RawMessage? StaticMessage?

I'm fine with all of three.
Can also be IdentityMessage (since we have an IdentityTranslator) or FixedMessage.

Any preference@nicolas-grekas ?

I likeStaticMessage, but just my 2 cents

I renamed it to StaticMessage then@OskarStark@nicolas-grekas

PR body would need an update

Ready for review@xabbuh@stof

Thank you@VincentLanglet.