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 _______________________________________________ Product-Developers mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-product-developers
