We have monitoring in place that reports certain errors from production systems, and the translator warnings are among those.

Sometimes, you don't want to go through the hassle of maintaining translation catalogues and put the plain text into the code directly (single-lang apps).

In that case, it would be nice if translations could be disabled.

How do you deal with that at the moment?
I feel like the proposed strategy has too much impact for achieving your use case.
Any other idea that'd be less invasive?

How do you deal with that at the moment?
I feel like the proposed strategy has too much impact for achieving your use case.
Any other idea that'd be less invasive?

Not really, yet. Right now, in such cases, my logs are full with warnings from LoggingTranslator. When I feel that these log messages are getting too much (like dozens of megabytes of log volume per day), I'd change the code to use "real" message-IDs instead, and move the text to a validators message catalogue.

I care mostly about validation constraint messages added when form types are being built. But since the form types come from different bundles and some of them provide translations whereas others do not, I cannot use the solution from #50797 to disable all translations altogether.

#48852 put the logic in place to change or disable the translation domain for individual (project-specific) validators, but does not make this feature available for the built-in constraints.

To me, it felt natural if the same translation_domain parameter that can be used for the form types could be used on for the constraints as well (consider my initial example).

Any other idea that'd be less invasive?

... or do you mean "achieves the same without a repeating code pattern in all constraints and validators"?

Full ack, I do not fancy putting the same change into lots of classes over and over again.

Thanks for the hints. I've no better idea so I feel like this might be good to me.
I'm just wondering: would it make sense to allow defining the translation domain by contraint's FQCN in config/packages/validation.yaml? This way one could say that all #[SomeConstraint] messages should use some domain?

... or do you mean "achieves the same without a repeating code pattern in all constraints and validators"?

That's what I meant yes.
Maybe my config idea could be enough?

validation:
  translation_domains:
    SomeConstraint: some-domain

Not sure – assume you have two bundles that build a FormType each. And in those FormTypes, they both use the NotBlank constraint with message-IDs.

To me, it would make sense if both bundles could keep their respective validation/constraint message in their "own" translation domain, as suggested by the best practice.

That would not be possible with a config setting as suggested, or am I missing something?

Would you be fine with a solution that involves something with traits to plug-in the translation_domain into all the constraints?

Still, that does not allow to pass it as a constructor argument. 🤔

Also, since the validator class calls $this->context->buildViolation() to create the ConstraintViolationBuilder, but never passes it somewhere else, and ends with calling addViolation() without ever passing the Constraint instance, I am afraid there is nothing we can do with the current code design to centralizetranslation_domain handling.

Maybe GitHub Copilot can pull it off for us 😹?

@ro0NL You made a comment about TranslatableMessage support; did you withdraw that for good reasons? Probably makes the change even bigger.

Adding this feature will break the PhpAstExtractor as it is. Actually, to extract translation keys from Constraints, it leverages https://github.com/symfony/symfony/blob/7.3/src/Symfony/Component/Translation/Extractor/Visitor/ConstraintVisitor.php, which is looking keys and extract them in validators domain by default.

Introducing translation_domain option here means to update the ConstraintVisitor to handle the translation_domain option value to extract keys in the correct domain (or validators by default as it is now).

IIUC, the main reason of this feature is:

#48852 put the logic in place to change or disable the translation domain for individual (project-specific) validators, but does not make this feature available for the built-in constraints.

But I'm wondering why do you need to change the translation domain of built-in constraints? Did I miss something?

@welcoMattic thank you for the heads up! If I get you right, I'll need to update the src/Symfony/Component/Translation/Extractor/Visitor/ConstraintVisitor.php as well.

It's not about changing the translation domain for built-in messages; it's great that Symfony ships with translations for those!

My use case is about using the constraints like NotBlank in custom form types, potentially shipped in bundles, with custom validation error messages. For those, I'd like to be able to control the message catalogue. See my initial comment for the example.

Does that make sense?

Still, I have no better idea yet how to approach this apart from making the same kind of change in all constraints. Anyone else?

So, instead of spreading this everywhere, maybe we could just update the NotBlank one?
And maybe a few more constraints where changing the default message makes sense?

I've fixed tests and added an example of what a test case might look like. 

The complete change ain't gonna be fun – so maybe @nicolas-grekas can give me a 👍 that you would indeed merge it if I go the whole way of adding it? 😉

Sorry, we both posted at the same time.

So you'd prefer changing only a few constraints over consistency of usage?

I do yes. Consistency is a superficial thing compared to code complexity.

Up to finish this PR @mpdude ?

I checked out the codebase where I'd benefit from this change and was daunted due to the number of validators actually used 🙈.

Let me think through again whether I really want to go on this journey.