Opened 5 years ago

Last modified 4 years ago

#13764 new New feature

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)

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 5 years ago.

Download all attachments as: .zip

Change History (6)

Changed 5 years ago by sebastian_noack

comment:1 Changed 4 years ago by ramiro

  • Description modified (diff)
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

edited description

comment:2 Changed 4 years ago by russellm

  • Patch needs improvement set
  • Summary changed from i18n in custum javascript [PATCH] to i18n in custom javascript
  • Triage Stage changed from Unreviewed to Accepted

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 4 years ago by julien

  • Severity set to Normal
  • Type set to New feature

comment:4 Changed 3 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:5 Changed 3 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

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