System Details

• FluentValidation version: 8.5.0-preview4 (but it applies to all versions that have ScalePrecicisonValidator)

Issue Description

The error message for ScalePrecicisonValidator is ambiguous with what digit means.

Translate<ScalePrecisionValidator>("'{PropertyName}' must not be more than {ExpectedPrecision} digits in total, with allowance for {ExpectedScale} decimals. {Digits} digits and {ActualScale} decimals were found.");

When an input of 1234.12 is validated to have a precision of 4 and scale of 2. The error message given is:

'{PropertyName}' must not be more than 4 digits in total, with allowance for 2 decimals. 4 digits and 2 decimals were found.

To a normal user this will be very confusing to encounter. I know that the precision is total individual digits in the number, and scale is total digits right of the decimal separator.

However the second sentence makes it unclear that {Digits} is supposed to be the digits to the left of the decimal separator. However if is the intented behaviour, then the user is expected to be familiar with the logic of precision and scale, and that Digits = actualprecision - actualscale.

I think an easy fix would be to return the actual precision of the number, so that way the error message would change to:

'{PropertyName}' must not be more than 4 digits in total, with allowance for 2 decimals. 6 digits and 2 decimals were found.

This way no re-translation is needed for any language (except, if any individual language manually fixed the {Digits} placeholder to something else).

This would work for small numbers, because the user can then re-evaluate what they had entered, and deduct how digits were counted, to realize what the problem is.

6 digits were found, I can count 6 digits in total, but it says it needs 4 digits in total. So I can only enter values like "x", "xx", "xxx", "xxxx", "x.x", "x.xx", "xx.x", "xx.xx", "xxx.x". - Possible thought process of a not completely potato user.

However on large precision and scale values, it would be extremely difficult to count with the naked eye, how many digits are where.

Although the issue may lay in the functions of precision and scale allowing vastly different values than a regular common sense user may expect. A precision of 4 and scale of 2 would allow inputs like [4000, 400.1], but not allow [3999.9, 400.15]. To a normal user this sort of logic may not make sense.