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

Don't get me wrong but to me it really smells. A Translatable object should inherently be translatable. Setting the domain 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 the domain 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 the NULL domain, you can find it in a lot of "domain" options like https://symfony.com/doc/current/reference/forms/types/form.html#translation-domain

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

Don't get me wrong but to me it really smells. A Translatable object should inherently be translatable.

Sure, for instance EasyAdmin 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 using Translatable 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 adding t() everywhere

I find it simpler to allow false 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 an UntranslatableMessage?

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 an UntranslatableMessage?

Might be better indeed
I update the PR with a NonTranslatableMessage @mdeboer

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