Use thousands separator to ease the reading of numbers with many digits

[zachborboa@…]

diff --git a/contrib/admin/templates/admin/pagination.html b/contrib/admin/templates/admin/pagination.html
index 3588132..a8d744a 100644
--- a/contrib/admin/templates/admin/pagination.html
+++ b/contrib/admin/templates/admin/pagination.html
@@ -1,12 +1,13 @@
 {% load admin_list %}
 {% load i18n %}
+{% load humanize %}
 <p class="paginator">
 {% if pagination_required %}
 {% for i in page_range %}
     {% paginator_number cl i %}
 {% endfor %}
 {% endif %}
-{{ cl.result_count }} {% ifequal cl.result_count 1 %}{{ cl.opts.verbose_name }}{% else %}{{ cl.opts.verbose_name_plural }}{% endifequal %}
+{{ cl.result_count|intcomma }} {% ifequal cl.result_count 1 %}{{ cl.opts.verbose_name }}{% else %}{{ cl.opts.verbose_name_plural }}{% endifequal %}
 {% if show_all_url %}&nbsp;&nbsp;<a href="{{ show_all_url }}" class="showall">{% trans 'Show all' %}</a>{% endif %}
 {% if cl.formset and cl.result_count %}<input type="submit" name="_save" class="default" value="{% trans 'Save' %}"/>{% endif %}
 </p>

[anonymous]

Also requires 'django.contrib.humanize'.

INSTALLED_APPS = (
    'django.contrib.humanize',
)

[Julien Phalip]

Thanks for the report, however the pagination count is already displayed following the active localization rules. For example, if English is active then commas should already be displayed as thousand separators. For other locales (e.g. French), then spaces should be used instead. Forcing the use of |intcomma would bypass the localization rules, which isn't acceptable.

[anonymous]

Thank you for the response. In short, set:

USE_THOUSAND_SEPARATOR = True # False by default
USE_L10N = True # True by default
USE_I18N = True # True by default

[anonymous]

Why should USE_THOUSAND_SEPARATOR not be enabled by default?

[Aymeric Augustin]

USE_THOUSAND_SEPARATOR = True will break any non-trivial application that hasn't been designed to support it from the start.

Random example: a template contains <div data-id="{{ myobj.pk }}>{{ myobj }}</div>, and something in JavaScript uses the pk.

That works perfectly, until a user creates the 1000th post — six months after you consider the site final...

[zachborboa@…]

Would there anything wrong or particularly difficult with excluding localization formatting when accessing an object's primary key (e.g. myobj.pk), but including localization formatting for all other numbers in templates?

[anonymous]

Well, that might fix the specific example I just gave, but that isn't an obviously correct behavior either. If I'm displaying Order #{{ order.pk }}, I expect a thousand separator.

[anonymous]

Replying to anonymous:

Well, that might fix the specific example I just gave, but that isn't an obviously correct behavior either. If I'm displaying Order #{{ order.pk }}, I expect a thousand separator.

I respectfully disagree. Accessing an object's primary key, I don't expect any separators. The pk represents the object's unique identifier in a database or collection -- often used in increasing sequence.