i18n javascript_catalog View Pollutes Global Namespace

[Matthew Tretter <matthew@…>]

In addition to the translation functions (gettext, ngettext, etc.), the global variables catalog and formats are created. These variables are required to exist and be in the correct format in order for the translation functions to work.

Seeing as how these are common words, with a relatively high likelihood of being clobbered, I propose we use the module pattern (an immediately invoked function).

This patch also uses vanilla objects for catalog and formats as those are the preferred type for dictionaries in JavaScript.

[Matthew Tretter <matthew@…>]

The patch corresponds to pull request #13 on the github repository.

​https://github.com/django/django/pull/13

[Jannis Leidel]

Accepting in general, but not generally excited about the indentation changes.

[Alexey Boriskin]

What do you think about the following idea: make all the generated javascript to be a string with django template syntax? That would allow us not to worry about indentation changes.

[Matthew Tretter]

New commits have been added to the PR on GitHub to use a template.

[Aymeric Augustin]

The PR no longer applies.

[Matthew Tretter]

I've got ​an updated branch, but I can't update the pull request since the issue is closed. Let me know if want to reopen the PR and have me update it or if I should create a new PR instead.

[Ramiro Morales]

Current PR is almost there but is causing one failure and seven errors in the Django test suite, all of the related to the js i18n catalog.

[Matthew Tretter]

Woops, sorry about that! I've updated the pull request.

[Ramiro Morales <cramm0@…>]

In a506b6981bc48caec30bca3de94d2ac3e6fc1660:

Fixed #18231 -- Made JavaScript i18n not pollute global JS namespace.

Also, use Django templating for the dynamic generated JS code and use
more idiomatic coding techniques.

Thanks Matthew Tretter for the report and the patch.