Opened 3 years ago

Last modified 3 years ago

#18394 new Bug

Better docs, and possibly better handling, for 'packages' argument to javascript_catalog

Reported by: ubernostrum Owned by: nobody
Component: Internationalization Version: 1.4
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

The javascript_catalog i18n view's packages argument only accepts modules which are either django.conf or which are also in INSTALLED_APPS. But there are two issues with this:

  1. The documentation for the view hides this a bit, and can create the impression that the restriction only applies to a packages argument passed through the URL.
  1. The view itself does not give you any warning if you're violating this restriction; it just silently discards anything in packages that doesn't meet the requirements.

At the very least, the documentation should be more up-front that this requirement always applies no matter how you're passing packages to the view. Possibly as a bonus, the view should warn that it's discarding any packages that don't conform to the requirements, to aid in debugging.

Change History (1)

comment:1 Changed 3 years ago by aaugustin

  • Component changed from Documentation to Internationalization
  • Triage Stage changed from Unreviewed to Accepted

Two problems are reported in this ticket:

(a) the documentation of javascript_catalog is confusing

(b) invalid package names are silently dropped: yes, silent failure is bad and we should do something. Raising an exception would be backwards incompatible. Raising a warning could be a good compromise.

I've created #18596 to track (a). Let's focus this ticket on (b).

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