Opened 4 years ago

Closed 6 months ago

#19567 closed New feature (fixed)

Make javascript i18n view as CBV and more extensible.

Reported by: Andrei Antoukh Owned by: Claude Paroz
Component: Internationalization Version: master
Severity: Normal Keywords: i18n javascript
Cc: niwi@… Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


The current view populates a global namespace (see but also is very monolitic.

My proposal is create a CBV. I don't understand the use of templates for rendering a view (related ticket).
Now, the initial code is available on this file:

If the proposal is accepted, I will create a patch.

Change History (12)

comment:1 Changed 4 years ago by Russell Keith-Magee

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset
Resolution: needsinfo
Status: newclosed

I'm not sure I see what you're proposing here, or why you're proposing it.

#18231 describes a problem with the javascript catalog; that is an accepted bug that needs to be solved.

I'm not sure I see what moving to a CBV approach gains us. You say the current implementation is 'monolithic' - what problem are you trying to solve that the current implementation prevents?

Before you get to committed to implementing a solution, we need to be clear on what problem you're solving. "It's not a CBV" isn't a problem unless a class-based approach will give flexibility that is actually required, and based on your sample implementation, I'm not sure I see what flexibility we will gain by making the view class-based.

Feel free to reopen with more details on the advantages of going down a class-based approach to the i18n catalog.

comment:2 Changed 4 years ago by Andrei Antoukh

Resolution: needsinfo
Status: closednew

I think the advantages are obvious but I'll try to explain:

  • Allow users to change certain behaviors without completely rewriting the view
  • Allow expose more than one gettext domain (and not force to use only a "djangojs" domain)

It is very useful to expose different domain that "djangojs". A real case: javascript templates.

The current makemessages command not parse well html files with javascript templates (with domain "djangojs"). A clean solution is to create another command which parses only js templates and place it contents in another po file distinct of "djangojs.po".

The current view is monolithic and if you want to change any behavior, the solution is full rewrite. I think what the framework must give some facility for doing this. this plugin allows collect messages from htmls what contains javascript templates in other domain distinct from djangojs and currentlly no way to expose these messages to the js.

comment:3 Changed 4 years ago by Aymeric Augustin

Component: UncategorizedInternationalization
Triage Stage: UnreviewedAccepted
Type: UncategorizedNew feature

comment:5 Changed 3 years ago by Krzysztof Jurewicz

Needs documentation: set
Needs tests: set
Patch needs improvement: set

I’ve made a comment in the pull request.

comment:6 Changed 3 years ago by alejandro

Owner: changed from nobody to alejandro
Status: newassigned

comment:7 Changed 8 months ago by Claude Paroz

Needs tests: unset
Owner: changed from alejandro to Claude Paroz

I have a revised patch with work in progress.

comment:8 Changed 7 months ago by Claude Paroz

Needs documentation: unset
Patch needs improvement: unset

comment:9 Changed 7 months ago by Tim Graham

Patch needs improvement: set

Left some review comments.

comment:10 Changed 7 months ago by Claude Paroz

Patch needs improvement: unset

comment:11 Changed 7 months ago by Tim Graham

Triage Stage: AcceptedReady for checkin

comment:12 Changed 6 months ago by Claude Paroz <claude@…>

Resolution: fixed
Status: assignedclosed

In de40cfbe:

Fixed #19567 -- Added JavaScriptCatalog and JSONCatalog class-based views

Thanks Cristiano Coelho and Tim Graham for the reviews.

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