Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#21317 closed New feature (invalid)

Add translation to constants.py

Reported by: Toff Owned by: nobody
Component: contrib.messages Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

It will be great if you can add translation to DEFAULT_TAGS in constant.py,
so we can have a translation of 'info', 'warning', etc in templates by using {{message.tags}}

Attachments (1)

constants.diff (510 bytes ) - added by Toff 10 years ago.

Download all attachments as: .zip

Change History (7)

by Toff, 10 years ago

Attachment: constants.diff added

comment:1 by Toff, 10 years ago

Summary: Add translation to constant.pyAdd translation to constants.py

comment:2 by alasdair, 10 years ago

message.tags is used for CSS - if you translated the DEFAULT_TAGS you would break the styling.

For example, in django/contrib/admin/templates/admin/base.py

{% if messages %}
<ul class="messagelist">{% for message in messages %}
<li{% if message.tags %} class="{{ message.tags }}"{% endif %}>{{ message|capfirst }}</li>
{% endfor %}</ul>
{% endif %}

I understand that you might want to display the translations of "info", "warning" etc to the user, but this would have to be a different attribute than message.tags.

Last edited 10 years ago by alasdair (previous) (diff)

comment:3 by Claude Paroz, 10 years ago

Resolution: invalid
Status: newclosed

IMHO, message tags are not meant as user-visible strings as their first role.
You can always mark those strings as translatable in your own project (i.e. ugettext_noop('debug'), etc.), then create your own template filter or tag to get translated tags.

comment:4 by Aymeric Augustin, 10 years ago

Claude, would you consider an API like message.get_tags_display to provide human-readable versions of the levels?

comment:5 by Claude Paroz, 10 years ago

I don't really see the use case of message.get_tags_display in the sense that there may be multiple space-separated tags returned. Maybe a message.get_level_display (which wouldn't consider extra_tags)? But once again, mixing tag and display roles with the same string doesn't seem very clean to me.
In any case, we would then need a use case common enough to justify it (considering that a custom template tag/filter can easily fill the "gap").

comment:6 by Toff, 10 years ago

You're right, i haven't seen this CSS breakdown.
message.tags is not intented for a direct text rendering.

I'll try an another way, like ugettext_noop as suggest claudep.

Thanks for your rapid answers and all your work.

Note: See TracTickets for help on using tickets.
Back to Top