id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
14844	i18n blocktrans tag pluralization feature limited by gettext constraints and shared local tag context	Ramiro Morales	nobody	"In r13998 a pluralization bug in the footer of paginated change list views for the admin app was fixed by switching to rely in the `blocktrans` i18n tag using:

{{{
{% blocktrans with cl.opts.verbose_name as verbose_name and cl.opts.verbose_name_plural as verbose_name_plural count cl.result_count as count %}
{{ count }} {{ verbose_name }}{% plural %}{{ count }} {{ verbose_name_plural }}
{% endblocktrans %}
}}}

Once `makemessages` is run to update a language's PO file, it contains this fuzzy entry:

{{{
#: contrib/admin/templates/admin/pagination.html:9
#, fuzzy, python-format
msgid ""%(count)s %(verbose_name)s""
msgid_plural ""%(count)s %(verbose_name_plural)s""
msgstr[0] ""...""
msgstr[1] ""...""
}}}

After updating the translation, removing the fuzzy marker and when trying to generate a MO file, this somewhat crytic errors is generated for that literal:

{{{
django.po:812: a format specification for argument 'verbose_name', as in 'msgstr[0]', doesn't exist in 'msgid'
}}}

Our documentation warns about this at the bottom of the blocktrans description, pointing to the `ungettext()` notes (http://docs.djangoproject.com/en/1.2/topics/i18n/internationalization/#pluralization-var-notes) because GNU gettext doesn't allow the variable placeholders used to be different.

But if we change the template construct to use :

{{{
{% blocktrans with cl.opts.verbose_name as vname and cl.opts.verbose_name_plural as vname count cl.result_count as count %}
{{ count }} {{ vname }}
{% plural %}
{{ count }} {{ vname }}
{% endblocktrans %}
}}}

and repeat the PO update & compile cycle then the admin always shows the pluralized model name (its `verbose_name_plural`). This is because the template context is unique and the last value bound to the same extra context var is the one that gets used.

This reveals a limitation of ''blocktrans'': The GNU gettext constraint is playing against our need to have correct pluralized names for generic literals like this where the entities at play can be different objects.

This problem can be seen in the admin change list view for the auth User model when using e.g. `'es_AR'` (and `'es'`) and `'fr'` locales (they have two plural forms and the translations of `'user'` and `'users'` differ in these locales, `'de'` doesn't.)

This error also affects the 1.2.X branch.

I think one way to solve this would be providing the blocktrans tag the ability to designate a context var that can take different values depending of if it's being used either in the singular or (fallback) plural branches. I will attach a patch later that implements a `name` subtag similar to the `count` one and auxiliar to it, with syntax `name <filter-or-var-expression-for-the-singular-case> or <filter-or-var-expression-for-the-plural-case> as <new-context-var>`. E.g.

{{{
{% blocktrans count cl.result_count as count name cl.opts.verbose_name or cl.opts.verbose_name_plural as vname %}
{{ count }} {{ vname }}
{% plural %}
{{ count }} {{ vname }}
{% endblocktrans %}
}}}

So blocktrans approaches more the capabilities provided by ungettext() to Python code.

A last note maybe worth adding to the docs as part of this: The plural section of `blocktrans` and the ''plural'' parameter of `ungettext()` are fallbacks in the case no translation is found in the catalog, the correct locale translations from the catalog according to the (possibly more than two) plural rules have greater priority.
"	Bug	new	Internationalization	dev	Normal			4glitch@… Maciej Olko	Accepted	1	1	0	1	0	0