#13014 closed (fixed)
Document using LANGUAGE_CODE with the cache template tag
Reported by: | yml | Owned by: | |
---|---|---|---|
Component: | Documentation | Version: | dev |
Severity: | Keywords: | ||
Cc: | fgutierrez@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Issue:
The cache templatetag does not take into account the Language (i18n).
Solution:
The cache templatetag[1] should be updated to use the new _i18n_cache_key_suffix[2]. Given context in which this code is evaluated the request is not required :
cache_key = _i18n_cache_key_suffix(request=None, cache_key):
This is in fact a follow up this ticket : #5691 which reported a similar issue with the cache middleware. the infrastructure for this change has been added in r12624 and r12546
[1]http://code.djangoproject.com/browser/django/trunk/django/templatetags/cache.py#L28
[2] http://code.djangoproject.com/browser/django/trunk/django/utils/cache.py#L137
Attachments (2)
Change History (14)
comment:1 by , 15 years ago
milestone: | → 1.2 |
---|---|
Triage Stage: | Unreviewed → Accepted |
by , 15 years ago
Attachment: | 13014.diff added |
---|
comment:2 by , 15 years ago
Component: | Uncategorized → Template system |
---|---|
Has patch: | set |
Owner: | changed from | to
Status: | new → assigned |
Summary: | Cache templatetag and i18n → Cache templatetag is not locale aware |
Version: | 1.1 → SVN |
comment:3 by , 15 years ago
Needs documentation: | set |
---|---|
Triage Stage: | Accepted → Design decision needed |
Yann brought up the point that maybe a user should be told to just do this manually by passing the locale as a cache argument.
Some short docs should be added to explain either the difference in behaviour or the parity.
comment:4 by , 15 years ago
IMO, we should simply mention in the docs that this works well:
{% cache 60 welcome request.LANGUAGE_CODE %} {% trans "Welcome to zombo.com" %} {% endcache %}
It's not exactly the same as the cache/middleware approach, but that's true for fragment caching anyway -- it's built to be flexible in contrast to out of the box caching of the middleware/decorator mechanism.
comment:5 by , 15 years ago
You'd also want to mention that they'd have to pass request in the context, or use the request context processor & a requestcontext.
But sure, if that's enough then someone can just write some nice docs :)
comment:6 by , 15 years ago
Doesn't the i18n context processor put LANGUAGE_CODE
in the context? Seems to me that's the right approach -- "explicit is better than implicit". Any reason we should do anything more than a doc addition?
comment:7 by , 15 years ago
Component: | Template system → Documentation |
---|---|
Has patch: | unset |
Needs documentation: | unset |
Owner: | removed |
Status: | assigned → new |
Summary: | Cache templatetag is not locale aware → Document using LANGUAGE_CODE with the cache template tag |
Triage Stage: | Design decision needed → Accepted |
Good point, Jacob. Definitely just a documentation job.
comment:8 by , 15 years ago
Has patch: | set |
---|
comment:9 by , 15 years ago
Has patch: | unset |
---|
The patch doesn't address the decision made to just document this behavior, Mr Anonymous.
by , 15 years ago
Attachment: | 13014_doc.diff added |
---|
comment:11 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I think that it makes sense to achieve parity between decorator and template tag caching before 1.2