Adding a plugin triggers bad request (HTTP 400), showing <django.utils.functional.__proxy__ object at 0x1eed4d0> error dialog

[eliasp]

When trying to add a plugin to a placeholder of a page, a browser error dialog pops up with the message:
<django.utils.functional.__proxy__ object at 0x1eed4d0>

The browser console shows a bad HTTP POST request (400) to /admin/cms/page/4/add-plugin/

The corresponding JavaScript backtrace of the browser console triggering this request is:

POST http://mydomain/admin/cms/page/4/add-plugin/ 400 (BAD REQUEST) jquery.min.js:130
c.extend.ajax jquery.min.js:130
(anonymous function) plugin_editor.js:30
c.event.handle jquery.min.js:55
j.handle.o jquery.min.js:49

Some probably related settings:

USE_I18N = False
LANGUAGE_CODE = 'en-us'
LANGUAGES = (
    ('en', 'English'),
    ('de', 'German'),
)
MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'cms.middleware.page.CurrentPageMiddleware',
    'cms.middleware.user.CurrentUserMiddleware',
    'cms.middleware.toolbar.ToolbarMiddleware',
)

There are no non-ASCII values in the config (or somewhere else) which could trigger lazy translation related issues.

No errors are logged by this bad POST request on the server side (Apache's error_log).

Using:
python-2.7
django-1.4.5
django-cms-2.4.1

[eliasp]

The error is triggered by return HttpResponseBadRequest(_("Language must be set to a supported language!")) in cms/admin/pageadmin.py:1149.

I wonder why it returns the string <django.utils.functional.__proxy__ object at 0x1eed4d0> instead of Language must be set to a supported language!.

Does anyone have an idea?

[eliasp]

Removing the wrapping _() from line 1149 makes it work as expected - returning the error string Language must be set to a supported language!.

I wonder whether this is a bug of django.utils.functional doing some weird lazy translation stuff with this string and then fails.

[eliasp]

I can clearly reproduce this issue now on the django shell:

>>> from django.utils.translation import ugettext_lazy as _
>>> print _("Language must be set to a supported language!")
<django.utils.functional.__proxy__ object at 0x171af10>

[ojii]

It should use ugettext instead of ugettext_lazy in that line.

On a sidenote, in case you haven't found your initial issue, you have LANGUAGE_CODE 'en-us' but 'en' in LANGUAGES.

[eliasp]

According to the comments in settings.py, LANGUAGE_CODE = 'en-us' should be correct:

# Language code for this installation. All choices can be found here:
# http://www.i18nguy.com/unicode/language-identifiers.html

While the django-cms documentation suggests:

The django CMS allows you to edit all languages for which Django has built in translations. Since these are numerous, we’ll limit it to English for now:

LANGUAGES = [
    ('en', 'English'),
]

Correcting the configuration to use the full ISO language code for both (LANGUAGE_CODE and LANGUAGES) works around this issue, but only because the if-branch of line 1149 isn't entered anymore.

So a proper solution to this issue is still needed and is very likely to use ugettext instead of ugettext_lazy at this point but as I'm rather new to Django/django-cms I can't tell yet how I'd properly use it at this point (is there a shortcut like _() for ugettext too?).

[ojii]

Correct, my suggestion above was to fix your setup in the meantime with a hotfix. This still needs to be fixed in the CMS.

[eliasp]

Ok, so what still confuses me is that there seem to be different ideas which kind of language code should be used:

django documentation, settings → LANGUAGES:

The list is a tuple of two-tuples in the format (language code, language name) – for example, ('ja', 'Japanese'). This specifies which languages are available for language selection. See Internationalization and localization.

This collides with the comment in generated settings.py which suggests something different:

# Language code for this installation. All choices can be found here:
# http://www.i18nguy.com/unicode/language-identifiers.html

The URL references ISO style language codes (en-us, de-de, etc.).
Some quick skimming of the documentation suggests, that en style language codes are to be used and it's just the comment in the generated settings.py which is outdated.
Does anyone know which one is correct?

[ojii]

First of all, that list linked is not an ISO list, it's a mix between ISO 639 and RFC 4646 (which is good, since that's basically how browsers/HTTP work).

Technicalities aside, both are correct.

However en and en-us are not the same. To make this more clear, en-us and en-gb are not the same (Color vs colour).

But to your question which one should be used: Always use the more generic (en) one unless you really know why you're not. Django will happily fall back en-us users to en.

[mkoistinen]

I'm getting the same cryptic error: <django.utils.functional.__proxy__ object at 0x7ff4645d0250>, but the issue appears to be related to permissions, not languages. This is invoked when a non-superuser staff attempts to add a CMS Plugin. A Superuser can add it on the identical page and the same language without issue.

Any work-arounds for this (except for assigning super-user to all users)? I can reproduce this at will, if I can help.