@YaFou sure, done

This looks like a BC break to me as it will break most existing translations that contain the@ character. The only viable BC solution that I see would be to create a decorator which contains this logic and that would be an opt-in feature.

This looks like a BC break to me as it will break most existing translations that contain the@ character. The only viable BC solution that I see would be to create a decorator which contains this logic and that would be an opt-in feature.

Good point. A solution may be to add an argument to theTranslator class which controls this option. Also this feature can be applied in version 6 generally which will be a breaking change.

Just found thatDataCollectorTranslator will be broken after this pull request.
I think It's a good idea, but it needs a little bit more work and considerations

Shouldnt we prefer the approach in#37670?

I prefer the approach of translatable objects in#37670 , but my idea is to encode domain in message ID itself, because in my opinion it is easier to store such ids in database

I'm against this change. First, it's a BC break, then, it looks a bit hacky, it's also yet another way to do something we can already do, and last, it does not work well when you are not using translation strings:$this->translator->trans('This is a message to translate@messages', $params).

Thanks for proposing.