Add url argument to translate tag

[Peter Bittner]

Context

Correct translation of extracted text is difficult without appropriate context. That's why Django offers the "context" argument to the "translate" (former "trans") tag and the "pgettext" functions, to add a text description to the generated entry in PO files.

However, this is rarely enough. Especially for translators, which often are not developers, a description only is not enough, not even when supported by a file location (file name + line number). A supporting image (e.g. screenshot) or a link to the live (Web) application would yield better translation support.

Proposal

Hence, we should add a "url" argument, in addition to "context", to the "translate" tag.

The value of the "url" should generate a "#:" prefixed comment, a reference in PO file terms. See ​https://www.gnu.org/software/gettext/manual/gettext.html#PO-Files

That value may then be flexibly used by translation tools to their liking (e.g. Rosetta may decide to generate links in their Web UI in the "Occurrence(s)" column).

Examples

{% translate "Vote again?" context "Polls app tutorial results page" url "https://examples.djangoproject.org/polls/1/" %}

or

{% url 'polls:detail' question.id as results_page_path %}

{% translate "Vote again?" context "Polls app tutorial results page" url results_page_path %}

would result in

#: polls/templates/polls/results.html:10
#: https://examples.djangoproject.org/polls/1/
#, fuzzy
msgctxt "Polls app tutorial results page"
msgid "Vote again?"
msgstr "Wieder abstimmen?"

See Django's polls app tutorial for a development context, e.g.

• ​https://docs.djangoproject.com/en/stable/intro/tutorial01/
• ​https://docs.djangoproject.com/en/stable/intro/tutorial03/
• ​https://docs.djangoproject.com/en/stable/intro/tutorial04/

Technical notes

For simplicity we may only hold simple text in the "url" value. But, as simple text and hard-coded URL paths outdate fairly easily, we may want to use Django's URL resolving features, namely:

django.shortcuts.resolve_url(to, *args, **kwargs)

The example above shows a way that may need little technical implementation, and no new concepts to learn. To make the generated URL base value useful this may require passing in or specifying (e.g. in the Django settings) some values used for generation of usable URLs.

Related source code

template tag (django.templatetags.i18n)

​https://github.com/django/django/blob/master/django/templatetags/i18n.py

gettext functions (django.utils.module)

​https://github.com/django/django/blob/master/django/utils/translation/__init__.py

management command (django.core.management.commands.makemessages)

​https://github.com/django/django/blob/master/django/core/management/commands/makemessages.py

[Mariusz Felisiak]

Thanks for the report, however I don't see a reason for a new argument. It's already feasible, you can add ​Comments for translators in templates, e.g.

{% comment Translators: https://examples.djangoproject.org/polls/1/%}
{% translate "Vote again?" context "Polls app tutorial results page" %}

You can also add a URL to the context, e.g.

{% translate "Vote again?" context "Polls app tutorial results page, see https://examples.djangoproject.org/polls/1/" %}

[Peter Bittner]

Fair enough, adding a comment is nice. But isn't this too generic?

If you know the translation industry a little bit you may be aware that very few or probably no-one will use the PO files directly. Hence, it's at the mercy of the translation tool to use the information captured in extracted-comments, reference and flag comment fields and the msgctxt fields.

Also, just to understand the motivation for the comment implementation better, why would I prefer a "Translators:" prefixed comment over the dedicated msgctxt? Can you give an example?

The reference type of comments are already dedicated to referring to specific locations (namely source file locations, which can easily be turned into hyper reference links on a Web UI). It would be natural for tools to extend the linking / link detection to actual URLs coming from the PO files. We can't assume the same for comments. The nature of comments is too generic.