#32356 closed New feature (invalid)
Add url argument to translate tag
Reported by: | Peter Bittner | Owned by: | nobody |
---|---|---|---|
Component: | Internationalization | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Claude Paroz | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
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
Change History (8)
comment:1 by , 4 years ago
Type: | Uncategorized → New feature |
---|
comment:2 by , 4 years ago
Description: | modified (diff) |
---|
comment:3 by , 4 years ago
Cc: | added |
---|---|
Resolution: | → invalid |
Status: | new → closed |
follow-ups: 6 7 comment:4 by , 4 years ago
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.
comment:5 by , 4 years ago
Description: | modified (diff) |
---|
comment:6 by , 4 years ago
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?
I've just mentioned two available solution, see #10004 for the motivation.
comment:7 by , 4 years ago
Replying to Peter Bittner:
...
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?
msgctxt
is for message disambiguation, that is if you have the "Export" message once used as a verb and once as a substantive, you should use msgctxt
so as languages can translate it differently (it will be separate entries in the po file). If you don't need that and just want to provide some translation context to translators, then use translator comments.
comment:8 by , 4 years ago
(it will be separate entries in the po file)
Good. That is the key to using msgctxt over a comment. Thanks for clarifying!
But, as I said, the point of this request is to generate a reference type of comment (#:
) in the PO file entry. Not an extracted-comments type comment (#.
).
Can developers trigger this as of today?
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.
You can also add a URL to the context, e.g.