Skip to content

[Validator] Standardizing validation messages #31788

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from

Conversation

toniperic
Copy link
Contributor

Q A
Branch? 3.4
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets ~
License MIT
Doc PR ~

Currently, almost all of the validation messages follow the same format, which I personally like.
Some of the examples are:

This value should be of type {{ type }}.
This value is too long. It should have {{ limit }} characters or less.
This collection should contain only unique elements.
This is not a valid International Bank Account Number (IBAN).

Basically, the format is: reference the subject ("this value", "this collection", "the file"...) and then explain what the actual problem is.

There are two exceptions that I'm seeing:

  1. addressing the client only in some places. In the majority of messages, they have been constructed in such a way that no single individual is being addressed, whereas some of them do.
    This PR fixes this in a way so that the messages which have been addressing anyone no longer do. Examples:
    • "The value you selected is not a valid choice." is now "The selected value is not a valid choice."
    • "You must select at most {{ limit }} choices." is now "At most {{ limit }} choices must be selected."
    • "This password has been leaked in a data breach, it must not be used. Please use another password." is now "This password has been leaked in a data breach. A different password must be used."
  2. avoiding being consistent with aforementioned format.
    This PR fixes that in a way that so that the messages conform to the same format as most of the others (referencing the subject and then stating the problem). Examples:
    • "Invalid card number." is now "This is an invalid card number."
    • "Unsupported card type or invalid card number." is now "This is an unsupported card type or invalid card number."

Also, as an added bonus, since I'm Croatian, I've done the translations for Croatian language in the very same PR + fixed some of the messages that didn't account for Croatian pluralization rules (or have, but implemented incorrectly).

All comments and feedback are appreciated.

Have a nice day!

@toniperic toniperic changed the title Standardizing validation messages [Validator] Standardizing validation messages Jun 1, 2019
@nicolas-grekas
Copy link
Member

I understand what you propose, but I fear this might be a too large BC break: this would invalidate any existing alternative translations. I don't know how/if we can do this.

@nicolas-grekas nicolas-grekas added this to the 3.4 milestone Jun 3, 2019
@toniperic
Copy link
Contributor Author

toniperic commented Jun 3, 2019

Thanks for the feedback @nicolas-grekas.

What I'm seeing that could be done to avoid BC issues is:
create new translation entries, where source of each entry is actually the one being changed through this PR (that is making breaking changes), while keeping whatever the current translations are for those entries.

That way, translations on all languages are kept as-is – so they're conveying pretty much the same understandable message – but from then on developers might provide more precise translations at any point to be in sync with the standard.

I've tried to illustrate this using a simple example which can be seen in this gist.

Also, messages that are not in sync with the standard could be deprecated and removed at some point in the future, where breaking changes are allowed and clearly communicated.

What do you think?

@fabpot
Copy link
Member

fabpot commented Jul 8, 2019

I like this pull request. Having consistent error messages sounds like a nice goal. 👍 for me

@nicolas-grekas
Copy link
Member

@fabpot which forward path do you recommend? Should we go with identifiers instead of messages as source?

@ro0NL
Copy link
Contributor

ro0NL commented Jul 18, 2019

we should leverage #30931 imho, and get this right in one version :)

i.e. define legacy_error_messages under validation, which we can also use for "form validation messages" i guess.

@fabpot
Copy link
Member

fabpot commented Sep 27, 2019

Would it make sense to try to translate all the new messages during SymfonyCon Amsterdam where we have a lot of different countries/languages represented? If we can have enough people, that could work.

@nicolas-grekas
Copy link
Member

Thank you for proposing. The proposed messages are marginally better, but the effort to migrate to using is not worth the effort.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants