#6195: Allow caching of the javascript translation library by the client browser
-------------------------------------+-------------------------------------
Reporter: jdetaeye | Owner: nobody
Type: New feature | Status: closed
Component: | Version: master
Internationalization | Resolution: wontfix
Severity: Normal | Triage Stage:
Keywords: i18 javascript | Someday/Maybe
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by aaugustin):
* status: new => closed
* resolution: => wontfix
Comment:
I investigated this issue a few months ago for a project of mine.
I found three non-exclusive ways to decorate `javascript_catalog` to
provide caching.
For providing translations in more than one language, the easiest is to
include the language code in the URL with `i18n_patterns`.
1) Server-side caching
{{{
key_prefix = 'js18n-%s' % get_version()
@cache_page(86400, key_prefix=key_prefix)
}}}
You need a `get_version()` function that returns a different result
whenever the translations change. In production, this isn't difficult, but
it depends on your deployment strategy, making it hard for Django to
provide a generic solution. In development, you have to use the dummy
cache to avoid stale translations.
The full translations catalog will be resent every time, but you'll save
the generation cost.
2) Client-side caching with If-Modified-Since:
{{{
last_modified_date = timezone.now()
@last_modified(lambda req, **kw: last_modified_date)
}}}
`last_modified_date` changes whenever the server is reloaded (in
production, because the code was updated; in development, because the dev
server auto-reloaded). It's even better if you can set
`last_modified_date` to the software release date, but that's a bit more
difficult to get right than version numbers.
3) Client-side caching with Etag:
{{{
etag_value = 'js18n-%s' % get_version()
@etag(lambda req, **kw: etag_value)
}}}
In production, this is perfect. Unfortunately, it doesn't work well in
development, because it's hard to generate an etag_value that's guaranteed
to change when you just edit .po and .mo files.
----
Neither of these techniques can provide proper cache invalidation without
application-supplied information about the software version. Therefore, I
think it's best to leave the implementation of caching to application
developers. The cache framework provides tools to add caching with one-
liners.
--
Ticket URL: <https://code.djangoproject.com/ticket/6195#comment:9>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
