intcomma not locale aware when given a decimal as string

[Jonathan Ströbele]

The ​documentation regarding localization says that for thousand separators USE_THOUSAND_SEPARATOR = True or intcomma can be used. The ​documentation of intcomma says either int/float or string representation works.

This seems to be true for a en locale, but in de locale this doesn't hold up if the input is a string:

en:
9999999999.11   -> 9,999,999,999.11
"9999999999.11" -> 9,999,999,999.11

de:
9999999999.11   -> 9.999.999.999,11
"9999999999.11" -> 9,999,999,999.11

In the case of a decimal value as string in the de-locale the output is wrong, it should be 9.999.999.999,11 (dot (.) as separator).

This seems to be the case because intcomma casts the value to int if its not a float/Decimal (which raises a ValueError for "9999999999.11" and then just puts in commas as thousand separators without any awareness of the current locale.

Also the ​DocBlock of the intcomma functions says "Convert an integer to a string containing commas every three digits." wich contradicts the int/float (or string thereof) in the documentation.

So either the function is not following the documentation or the documentation is wrong (?).

I think this is problematic as the function is communicated as an alternative/equivalent option to USE_THOUSAND_SEPARATOR=True. When a float value is formatted with {{ value|floatformat:2|intcomma}} the floatformat will return a string and as such, intcomma is no longer locale aware (also reported in #33771). This can lead to outputs like 9,999,999,999,11 in the de locale:

9999999999.11 -> floatformat:2 -> "9999999999,11" -> intcomma -> "9,999,999,999,11"

A solution could be to integrate some sort of float casting into intcomma? Or remove the recommendation of using it in favor of just the USE_THOUSAND_SEPARATOR = True setting and clarifying the documentation of intcomma?