The current behaviour is expected. TheLocaleType is a specialisedChoiceType and theChoiceType is automatically invalid in case an invalid choice is submitted (there have been bugfixes recently to ensure this behaviour).

Thank you for the response.
IIUC, based on that premise, when I submit a invalid locale through this form type I can't get the violation fromLocaleValidator anymore?

Yes, that's right. But you can use theinvalid_message option of the form type to reuse the message from the validator.

In that case, I should instantiate manually theLocale constraint just to obtain the$message property and pass it as the "invalid_message" option. Moreover, I think this solution doesn't cover (in an easy way) the scenario where the validation constraint has multiple possible messages or when one form field has more than one validation constraint associated to the property which the field represents.

Should we merge this PR? If yes, please rebase to account for short arrays. If needed, please open an issue if there is anything to keep track of.

The added test is failing as expected. I think for cases where the current behaviour is not sufficient enough, having to configure theinvalid_message option yourself is acceptable. You even do not need to instantiate the constraint. Just take a look at the message being used and optionally copy its translations to themessages domain.

Thank for your response. I think this behavior was changed between3.4.20 and3.4.21. I detected this change thanks to a test that I have in a own project, so I think the change, although minor, could be considered a BC break.
Is there any entry at changelog or upgrade files? If not, should I add a note for this change?
Please, let me know.

I think that's because before#29500 was merged, theLocaleType mistakenly was not marked as invalid (not synchronised). Though I do not think we should add a dedicated changelog entry. That PR was just a regular bugfix.

Closing based on the given explanation. Thank you!