[Product-Developers] Serving locale-specific JavaScript resources

Sean Upton sdupton at gmail.com
Thu Sep 15 17:26:57 UTC 2011


I am polling this list for ideas other add-on developers might have
about serving locale-specific JavaScript resources.  At the moment, an
add-on I have developed for a date widget [1] serves locale-specific
date-parsing JavaScript files (http://datejs.com is localized to
dozens of locales) by:

  (a) Including a link to a view called @@date.js in the JS registry.

  (b) having that view (correctly) parse the locale
language/territory/script from the request [2] and find (if possible)
the appropriate localized resource URL (or some default en-US) to
redirect to.  The view issues a 302 redirect to the locale-specific
resource.

This is simple, easy, cache-safe, and works.  But I dislike the
overhead of an additional HTTP request (if I can avoid it).  This
seems a case that resource registries have not been designed to handle
(??) and a tricky fit for caches to handle on the server side without
including a distinct resource URI per-locale (serving one resource URL
and using the HTTP 1.1 Vary header seems too complicated a solution).

Am I missing some obvious or existing way to do this?  Thoughts?  Ideas?


Sean


[1] uu.smartdate -- see:
http://bazaar.launchpad.net/~upiq-dev/upiq/uu.smartdate  -- I am quite
likely looking to re-package this under a plone.formwidget.* name in
plone svn at some point soon for wider distribution.

[2] ZPublisher's HTTPRequest does not reliably parse the locale
territory or script, so you cannot rely upon getting the locale
identify from the request without a little bit of work:
http://bazaar.launchpad.net/~upiq-dev/upiq/uu.smartdate/view/head:/uu/smartdate/locale.py


More information about the Product-Developers mailing list