The current behaviour is expected. The LocaleType is a specialised ChoiceType and the ChoiceType 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 from LocaleValidator anymore?

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

In that case, I should instantiate manually the Locale 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 the invalid_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 the messages domain.

Thank for your response. I think this behavior was changed between 3.4.20 and 3.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, the LocaleType 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!