[ckan-dev] i18n url rewriting

David Read david.read at okfn.org
Tue Feb 14 10:55:37 UTC 2012


On 14 February 2012 10:23, Toby Dacre <toby.okfn at gmail.com> wrote:

> Hi,
>
> http://trac.ckan.org/ticket/1653
> I've created branch feature-1653-i18n_url_rewriting
>
> This changes the locale to be specified in the url as /<language-code>/url
> - if the default language is used the url does not get rewritten.
>

Hi Toby,
Great to hear this change is ready - this will make the multi-language
support work better behind proxy caches and be no doubt clearer to users
too.


> This change has the following implications:
>
> 1) Cache issues - We do redirects to browser requested languages when no
> locale is present so a call to /home may return the default locale version
> of that page or a redirect eg /fr/home. I spoke to David Raznick and he
> said that disabling the caching for now is the best approach for now.
>

ETags headers have been removed from CKAN and Pylons caching is mostly
removed and what remains is mostly disabled by default. What caching do you
mean?

I'm trying to work out what you mean by "browser requested languages",
"present locale" and "default locale version of that page"? Whirling round
my head are these options: language specified in the URL, the
Accept-Language request header, the previous setting stored in the cookie
or the default locale in the CKAN configuration. Can you be more specific?

BTW is the home page now at /home rather than / ? Why's that?


> 2) Language Selectors - these need to be rewritten as they can now create
> direct urls via h.url(url_required, locale=local_required).  I have
> corrected this in ckan layout_base.html and for ckanext-ecportal but am not
> sure if/where this is also used - I'll fixup if directed where it is used.
>

You're talking about the links in the footer of the template which are used
to change language? And are you wondering if there are any other ways in
which a user might switch the language? The answer to that is no.


>
> 3) Template Context - in lib.base.render() the template context passes the
> default pylons.url() which we now override to handle the locale specific
> urls.  To prevent this being used I have removed it so if it is used
> templates will break ${url(...)} should be replaced with ${h.url(...)}.
> again I've fixed up in core and ec-portal
>

I think it would be useful to document this with the various forms of url
and url_for. Perhaps here is the best place?:
http://docs.ckan.org/en/latest/theming.html#retheming-the-site-with-templates


> 4) Site in subdirectory - This should work but I don't have this setup so
> testing has not been done - does anyone have this setup?
>

Yes, you just need to run CKAN on Apache and add a sub-directory to this
line in your Apache config. e.g.:

        WSGIScriptAlias /sub/dir /home/dread/etc/ckan-pylons.py

Now CKAN's mounted at: http://localhost/sub/dir
For more info on this and running on Apache see
http://wiki.ckan.org/Deployment


David

I've also simplified the querying of available locales
>
> Let me know any feedback
>
> Toby
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20120214/0df4f9a7/attachment-0001.html>


More information about the ckan-dev mailing list