refactor(form): update validator error messages

[spliffone]

See #1373

Describe in detail what your merge request does and why. Add relevant
screenshots and reference related issues via Closes #XY or Related to #XY.

---

• I confirm that this MR follows the contribution guidelines.

[gemini-code-assist]

Summary of Changes

Hello @spliffone, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request focuses on refining the user experience of form validation by updating and standardizing error messages. The changes aim to provide clearer, more informative feedback to users by making messages more concise and incorporating dynamic values directly into the error text. This ensures that users receive precise guidance when their input does not meet validation criteria.

Highlights

• Standardized Validation Messages: Validation error messages for various form inputs have been updated to be more concise and user-friendly.
• Dynamic Error Values: Error messages for 'min', 'max', 'minlength', and 'maxlength' validators now dynamically include the specific required values (e.g., 'Min. {{min}}', 'Min. {{requiredLength}} characters').
• Improved Clarity for Number and Time Inputs: Error messages for number format, minutes, seconds, and milliseconds have been made clearer, specifying expected input types and ranges (e.g., 'Number required', 'Integer between 0 and 59 required').
• Playwright Snapshot Updates: Several Playwright visual and YAML snapshots have been updated to reflect the changes in the validation error messages and potentially minor UI adjustments in the form elements.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors the form validation error messages to be more concise and user-friendly. The changes are generally an improvement. However, an end-to-end test that asserts one of the old error messages was not updated, which will cause the test suite to fail. Please see the specific comment for details on how to fix the test.

[github-actions]

Documentation.
Examples.
Playwright report.

Coverage Reports:

• element-ng
• element-translate-ng

[Danisand]

Hi @spliffone

I reviewed the strings together with @michael-smt.

Please implement my suggestions and merge them.

[Danisand]

Hi @spliffone and @michael-smt

I have seen the picture for the visual regression test. It seems that the key SI_FORM_CONTAINER.ERROR.PATTERN is concatenated in the tooltip.

Could you please explain me, in which situation SI_FORM_CONTAINER.ERROR.PATTERN is used?

[spliffone]

@Danisand I found two more missing keys, feel free to have a look:

• notSupportedPhoneNumberCountry - SI_FORM_CONTAINER.ERROR.PHONE_COUNTRY
• invalidPhoneNumberFormat - SI_FORM_CONTAINER.ERROR.INVALID_PHONE

[spliffone]

Hi @spliffone and @michael-smt

I have seen the picture for the visual regression test. It seems that the key SI_FORM_CONTAINER.ERROR.PATTERN is concatenated in the tooltip.

Could you please explain me, in which situation SI_FORM_CONTAINER.ERROR.PATTERN is used?

Yes, the error is provided when the app apply the Angular pattern directive (https://angular.dev/api/forms/PatternValidator#adding-a-pattern-validator) and you can assume to have two parameters: { actualValue: "..." requiredPattern: "..." }

[Danisand]

@Danisand I found two more missing keys, feel free to have a look:

• notSupportedPhoneNumberCountry - SI_FORM_CONTAINER.ERROR.PHONE_COUNTRY
• invalidPhoneNumberFormat - SI_FORM_CONTAINER.ERROR.INVALID_PHONE

Hi @spliffone I am not able to find these strings. Are they new?

[Danisand]

Hi @spliffone and @michael-smt
I have seen the picture for the visual regression test. It seems that the key SI_FORM_CONTAINER.ERROR.PATTERN is concatenated in the tooltip.
Could you please explain me, in which situation SI_FORM_CONTAINER.ERROR.PATTERN is used?

Yes, the error is provided when the app apply the Angular pattern directive (https://angular.dev/api/forms/PatternValidator#adding-a-pattern-validator) and you can assume to have two parameters: { actualValue: "..." requiredPattern: "..." }

I see the main issue in the concatenation. In the tool tip are 2 strings concatenated. This must be avoided. Min. 2 characters would be sufficient in example on the image.

• Can we just show 1 validation error at the same time?
• Can we prioritize the validation messages?

[spliffone]

Hi @spliffone and @michael-smt
I have seen the picture for the visual regression test. It seems that the key SI_FORM_CONTAINER.ERROR.PATTERN is concatenated in the tooltip.
Could you please explain me, in which situation SI_FORM_CONTAINER.ERROR.PATTERN is used?

Yes, the error is provided when the app apply the Angular pattern directive (https://angular.dev/api/forms/PatternValidator#adding-a-pattern-validator) and you can assume to have two parameters: { actualValue: "..." requiredPattern: "..." }

I see the main issue in the concatenation. In the tool tip are 2 strings concatenated. This must be avoided. Min. 2 characters would be sufficient in example on the image.

• Can we just show 1 validation error at the same time?
• Can we prioritize the validation messages?

1. Can we just show 1 validation error at the same time?

It is common practice to list all validation errors that is why we used sentences.

2. Can we prioritize the validation messages?

We aren't able to distinguish which error have a higher priority.

[Danisand]

Hi @spliffone and @michael-smt
I have seen the picture for the visual regression test. It seems that the key SI_FORM_CONTAINER.ERROR.PATTERN is concatenated in the tooltip.
Could you please explain me, in which situation SI_FORM_CONTAINER.ERROR.PATTERN is used?

Yes, the error is provided when the app apply the Angular pattern directive (https://angular.dev/api/forms/PatternValidator#adding-a-pattern-validator) and you can assume to have two parameters: { actualValue: "..." requiredPattern: "..." }

I see the main issue in the concatenation. In the tool tip are 2 strings concatenated. This must be avoided. Min. 2 characters would be sufficient in example on the image.

• Can we just show 1 validation error at the same time?
• Can we prioritize the validation messages?

1. Can we just show 1 validation error at the same time?

It is common practice to list all validation errors that is why we used sentences.

2. Can we prioritize the validation messages?

We aren't able to distinguish which error have a higher priority.

Is the concatenation done in the inline validation text also?

[spliffone]

@spike-rabbit I think we should replace the current div's inside the .invalid-feedback container by lists ul / li. I guess this way the accessibility tree would show them not as one concatenated string.

[spike-rabbit]

@spike-rabbit I think we should replace the current div's inside the .invalid-feedback container by lists ul / li. I guess this way the accessibility tree would show them not as one concatenated string.

I don't think we should do that:

(see: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-describedby)

Outside of this PR we could start evaluating:

• if moving to aria-errormessage works
• reference each error seperately

[spliffone]

@spike-rabbit I think we should replace the current div's inside the .invalid-feedback container by lists ul / li. I guess this way the accessibility tree would show them not as one concatenated string.

I don't think we should do that: (see: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-describedby)

Outside of this PR we could start evaluating:

• if moving to aria-errormessage works
• reference each error seperately

The PR has enough changes I will create an issue where we should discuss it first.

[github-actions]