[newforms-admin] - incorrect plurals in admin pagination template

See http://groups.google.com/group/django-developers/browse_thread/thread/2d8a06071553eafe/1c6587f10052814a#1c6587f10052814a

My language is really strange. Imagine that you have this grammar:

• 1 contact,
• 2 contacts, 3 contacts, 4 contacts
• 5 contactz, 6 contactz, ...

And expression "5 contacts" is an error. OK, everybody knows what it means - but for perfectionist it is not good enough.

So I propose to enable "translate" this expression in admin. It would be no change for English and for other languages. But I could use this translation:

• msgid "%(count)s %(verbose_name)s"
• msgstr "%(verbose_name)s: %(count)s"

This won't work for languages with more than one plural form. For example, in Russian "1 object, 2 objects, 10 objects" becomes "1 объект, 2 объекта, 10 объектов". I think, the only way to handle it correctly is to use ungettext, possibly via {% blocktrans %} ... {% plural %} ... {% endblocktrans %} template tag.

My language (Czech) is similar - it has also two plural forms. Usually I use ungettext - but it is not possible in this situation what is the reason for this ticket.

For pagination template I have to use Meta class from model which has only two relevant attributes - verbose_name and verbose_name_plural. Therefore I can't use ungettext. So I use trick - I know that "2 объектов" (I supposed it is used now) is a mistake, so I "translate" it as "Oбъектов: 2" which is ok (maybe, I don't speak Russian - but it is ok in my language).

There is another solution: Verbose name could be defined as function with ungettext. I tried it and it worked - but it seems to be too complex for this problem. If Django developers tell it is the preferred variant, I will create a patch - it is no problem for me.

What if we use something like ungettext(u'%%i %s' % verbose_name, u'%%i %s' % verbose_name_plural, n) % n? The only problem is how to mark these dynamically created strings for translation. Maybe make-messages.py could take care of this.

Since there are about a million different proposals for handling pagination in templates in various places, I'd like to consolidate it all into #3169 for now (and, more realistically, in discussion on django-developers).

I don't understand what exactly you propose. I suppose I have this model:

class Object(models.Model):
    # ...
    class Meta:
        verbose_name = _('object')
        verbose_name_plural = _('object')

If the current code would be in python, it would be something as:

if n == 1:
    text = '%i %s' % (count, verbose_name)
else:
    text = '%i %s' % (count, verbose_name_plural)

The result is:

• 1 object; 2 objects; 5 objects - ok in English
• 1 objekt; 2 objekty; 10 objekty - not ok in Czech
• 1 объект; 2 объекта; 10 объекта - probably not ok in Russian

I propose this little change:

if n == 1:
    text = _('%{count}i %{verbose_name}s') % {'count': count, 'verbose_name': verbose_name}
else:
    text = _('%{count}i %{verbose_name_plural}s') % {'count': count, 'verbose_name_plural': verbose_name_plural}

After translation the result would be:

• 1 object; 2 objects; 5 objects - ok in English
• Objekt: 1; Objekty: 2; Objekty: 10 - quite ok in Czech
• Oбъект: 1; Oбъекта: 2; Oбъекта: 10 - maybe quite ok in Russian

I tried another solution:

class Object(models.Model):
    # ...
    class Meta:
        verbose_name = lambda n: ungettext('object', 'objects', n) % {'n' : n}

Then I changed django.db.models.options.Options to check if verbose_name was function. It worked and it was backward-compatible but I think that this problem doesn't deserve such complex solution.

So I try to imagine which patch you propose. Should make-messages.py be smarted? I think it is possible - expressions in models after verbose_name would be considered as pluralized messages. Options class and template would count with it. But is it worth? Is my solution really not good enough for Russian?

I reopened the ticket because it is not about pagination - it is about internationalization in a template. It just happened that the name of the template was "pagination.html".

I see I chose bad summary and bad keywords. So I changed it. Now it shouldn't be misguided.

new version - after autoescape merge

Old admin looks to be no different from newforms-admin for this issue, so this should not block merge.

I don't like this solution. It's too wordy (admin is only a single example of where you might need pluralisation support in this sort of situation). We need a version of blocktrans that can handle plural specifications somehow, I suspect.

I have a memory that this has been discussed on django-developer in the past and we got a bit stuck on the syntax. I'd rather persist with trying to get that right, though. Somebody who has ideas should start a discussion on django-dev to see if we can get some consensus.