#12650 closed (fixed)
Some contrib apps depend on the i18n context processor to output valid XHTML
| Reported by: | Rob Hudson | Owned by: | Ramiro Morales |
|---|---|---|---|
| Component: | Contrib apps | Version: | 1.1 |
| Severity: | Keywords: | ||
| Cc: | Triage Stage: | Accepted | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Specifically, the contrib.admin and contrib.databrowse expect the context of LANGUAGE_CODE to exist when outputting the <html> tag. Without these, the values for the lang attributes end up empty which is invalid XHTML. If someone disables i18n, would it be safe to assume en-us and convert those to: lang="{{ LANGUAGE_CODE|default:"en-us" }}"?
Attachments (1)
Change History (10)
comment:1 by , 15 years ago
| Triage Stage: | Unreviewed → Design decision needed |
|---|
follow-up: 3 comment:2 by , 15 years ago
I made the assumption that if I'm not using i18n, I could also remove the i18n context processor, which is what provides the default settings to the template and why they are now blank in the admin and databrowse.
comment:3 by , 15 years ago
| Triage Stage: | Design decision needed → Accepted |
|---|
Replying to robhudson:
I made the assumption that if I'm not using i18n, I could also remove the i18n context processor, which is what provides the default settings to the template and why they are now blank in the admin and databrowse.
And right you were, because you are doing something we've document as possible and even suggest to do so: http://docs.djangoproject.com/en/dev/topics/i18n/deployment/#if-you-don-t-need-internationalization (second paragraph).
comment:4 by , 15 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:5 by , 15 years ago
| Resolution: | → worksforme |
|---|---|
| Status: | assigned → closed |
I started to work on this by first creating a test case that set the USE_I18N seting to False, removed 'django.core.context_processors.i18n' from the TEMPLATE_CONTEXT_PROCESSORS setting and then examined the content of the HTML tag of an admin page.
But it showed thing were working (the lang attributes had "en-us" values) even before applying any fix.
Looking at the Django code I see that the i18n context processor sets the LANGUAGE_CODE context var value from the result of a call to django.utils.translation.get_language() and django/utils/translation/trans_null.py (the one used when USE_i18N is False) has get_language = lambda: settings.LANGUAGE_CODE. So LANGUAGE_CODE never can have and empty value.
Tested this against trunk and 1.1.x as of now.
The only other possibility I seas a a reason for getting an empty LANGUAGE_CODE context var value is if you are explicitly deleting the LANGUAGE_CODE setting or setting it to an empty value which isn't the right way to deactivate i18n machinery.
Because of this I'm closing this ticket as worksforme. Please reopen If I've missed anything.
comment:6 by , 15 years ago
I just looked again at 2 of my projects using debug toolbar. If I add the i18n context processor, I see the LANGUAGE_CODE context variable in the templates panel and the HTML looks good. When I disable it, I no longer see the LANGUAGE_CODE available in the context. Checking the settings panel, I do, in fact see that LANGUAGE_CODE='en-us'... it's just not getting into the template context. And if the i18n context processor is disabled, I don't see how it would get there unless manually added in the view.
Unless someone else can see this, I'm not going to re-open it.
by , 15 years ago
| Attachment: | 12650-r12947.diff added |
|---|
Patch fixing issue as devised by robhudson plus tests.
comment:7 by , 15 years ago
| Component: | Uncategorized → Contrib apps |
|---|---|
| Has patch: | set |
| Resolution: | worksforme |
| Status: | closed → reopened |
Please ignore all my babbling about where the i18n context processor gets the value of LANGUAGE_NAME from, the point is such context processor not being present at all.
As for why the test case I had created was showing the LANGUAGE_CODE=en value was present in the context of the admin, the reason was:
- The test machinery hard-codes
LANGUAGE_NAMEto'en'. - The i18n context processor is in the default
TEMPLATE_CONTEXT_PROCESSORSsetting set byglobal_settings.py - The internal list of context processors is generated once from
TEMPLATE_CONTEXT_PROCESSORSand then cached.
This explains why the XHTML header contained 'lang="en" xml:lang="en"' showing no failure (OTOH Rob's and my own live testing with the admin app showed invalid XHTML headers were being generated). Also, the test passed/failed depending if another test case with was run before or not.
Even when I was munging with settings.TEMPLATE_CONTEXT_PROCESSORS to remove the i18n context processor, that change had no effect in the processing of the request made by the test client. I solved this in a somewhat hacky way: I reset the internal cache of context processors used by RequestContext after I modify that setting.
Thanks Rob for insisting on this.
comment:8 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
What's the use case for the LANGUAGE_CODE setting not being there? It's in global_settings, and it's in the template for a new project - how is this problem manifesting for you?