#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: | dev |
| 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 |
Description
The current view populates a global namespace (see https://code.djangoproject.com/ticket/18231) 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: https://github.com/niwibe/django-jsgettext/blob/master/djsgettext/views.py
If the proposal is accepted, I will create a patch.
Change History (13)
comment:1 by , 12 years ago
| Resolution: | → needsinfo |
|---|---|
| Status: | new → closed |
comment:2 by , 12 years ago
| Resolution: | needsinfo |
|---|---|
| Status: | closed → new |
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.
https://github.com/niwibe/django-jsgettext 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 by , 12 years ago
| Component: | Uncategorized → Internationalization |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
| Type: | Uncategorized → New feature |
comment:5 by , 11 years ago
| Needs documentation: | set |
|---|---|
| Needs tests: | set |
| Patch needs improvement: | set |
I’ve made a comment in the pull request.
comment:6 by , 11 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:7 by , 9 years ago
| Needs tests: | unset |
|---|---|
| Owner: | changed from to |
I have a revised patch with work in progress.
comment:10 by , 9 years ago
| Patch needs improvement: | unset |
|---|
comment:11 by , 9 years ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
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.