Opened 9 years ago

Closed 9 months ago

#13764 closed New feature (wontfix)

i18n in custom javascript

Reported by: Sebastian Noack Owned by: nobody
Component: contrib.admin Version: 1.2
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description (last modified by Ramiro Morales)

The admin javascript is using django.views.i18n for translation. I have added some custom javascript to the admin, which needs i18n, too. It turned out that it is not that easy to add your own translated texts to the admin, without adding another view function to each ModelAdmin that generates i18n javascript. You can subclass the AdminSite and override the i18n_javascript method, but that is not much convenient and you can not have translations per app or per model. I have written a patch that moves the i18n_javascript method from AdminSite to ModelAdmin. In addition it adds the app of the ModelAdmin to the list of translation packages. So you can add your own javascript translations, by just adding them to the app directory.

Attachments (1)

admin-cutom-jsi18n.patch (6.7 KB) - added by Sebastian Noack 9 years ago.

Download all attachments as: .zip

Change History (7)

Changed 9 years ago by Sebastian Noack

Attachment: admin-cutom-jsi18n.patch added

comment:1 Changed 8 years ago by Ramiro Morales

Description: modified (diff)

edited description

comment:2 Changed 8 years ago by Russell Keith-Magee

Patch needs improvement: set
Summary: i18n in custum javascript [PATCH]i18n in custom javascript
Triage Stage: UnreviewedAccepted

I'm going to accept this as a problem description, but not as a proposed fix. The problem clearly exists, but moving i18n into a per-model definition seems like the wrong approach to me. This would result in a proliferation of little jsi18n scripts, when what you really want is one good script that is composed of all the little extensions. There's no reason these extensions can't be defined on a per-model basis, but I don't see why they need to be served on a per-model basis.

comment:3 Changed 8 years ago by Julien Phalip

Severity: Normal
Type: New feature

comment:4 Changed 7 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:5 Changed 7 years ago by Aymeric Augustin

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:6 Changed 9 months ago by Claude Paroz

Resolution: wontfix
Status: newclosed

I don't see this going anywhere. Probably add your custom jsi18n view in a custom base_site.html admin template.

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