PluralLocalizationFormatter should not try to format pure numeric strings

[axunonb]

In version v3.1.0 and before, the PluralLocalizationFormatter rejected to format bool or string values.

When implicit formatter detection is used - i.e. not named formatters - the following format string was processed by ConditionalFormatter. This is considered as the desired and expected behavior:

Smart.Format("Arg value: {0:{} |is null or empty}", default(object?));
// returns "Arg value: is null or empty"
Smart.Format("Arg value: {0:{} |is null or empty}", "1234");
// returns "Arg value: 1234 "

This behavior changed in v3.2.0.

Smart.Format("Arg value: {0:{} |is null or empty}", "1234");
// returns unexpected "Arg value: is null or empty"

// Using the named formatter:
 Smart.Format("Arg value: {0:cond:{} |is null or empty}", "1234")
// returns "Arg value: 1234 "

Reason for the changed result: PluralLocalizationFormatter kicked in as the first formatter that can handle the format string and arg value.

A workaround for this specific format string was:

Smart.Default.GetFormatterExtension<PluralLocalizationFormatter>().CanAutoDetect = false;

Conclusion:
The behavior of PluralLocalizationFormatter should be reverted to the behavior of version v3.1.0 and before.
Additional unit tests for this use case should be added.

Note:
Implicit formatter detection is comfortable, but is also at risk not detecting the expected formatter.
Using namend formatters is always more safe.

See also this discussion: #344
@sygmond

[sygmond]

Thank you for nicely layout examples and explanation. I understand it now better.

[axunonb]

@karljj1 The issue is because a string is also IConvertible, but shouldn't be processed by PluralLocalizationFormatter. Agree?

[karljj1]

@karljj1 The issue is because a string is also IConvertible, but shouldn't be processed by PluralLocalizationFormatter. Agree?

Yes that does make sense. I recall adding an exception for bools for a similar reason, I guess we also need one for strings.