Hello,
Since Django 1.4, it's possible to localize URL patterns with
i18n_patterns. I have a slightly different use case. I need URLs in the
form /<country>/<language>/ in order to implement country-specific behavior
(eg. taxes, local regulations, etc.).
The hard part is to get URL reversing to work correctly without passing the
country and language information explicitly in every {% url %} tag or
reverse() call. They must be looked up in a global (thread-local) variable.
That's how i18n_patterns works.
I came up with this solution : https://github.com/oscaro/django-o18n. I'm
not entirely satisfied because it involves monkey-patching. I had to do
that because:
- the resolver used by reverse() is always a RegexURLResolver
- its reverse_dict attribute is a property whose value depends on
get_language()
For a more detailed explanation, see
https://github.com/oscaro/django-o18n/blob/master/o18n/monkey.py.
Surprisingly, the call to get_language() is in RegexURLResolver, not in
LocaleRegexURLResolver. That's at least a code smell and possibly a flaw in
the current implementation.
My questions are:
1 - Shouldn't it be possible to implement this feature without
monkey-patching ? I suspect this is part of the "URL resolution / reversing
is too inflexible" theme.
2 - Shouldn't it be possible to set the root URL resolver, returned by
get_resolver, to another class than RegexURLResolver? Maybe we could be
preserve the class of urlpatterns in ROOT_URLCONF rather than wrap it in a
RegexURLResolver.
3 - Shouldn't all the implementation of locale-dependent URLs
(i18n_patterns) be contained in LocaleRegexURLResolver? I haven't followed
the development of the feature at the time, so please forgive me if this
has been discussed before.
Thank you,
--
Aymeric.
PS. Of course, I could write one settings module per country and route
requests for each country to a different set of Django processes. I didn't
choose that option because it would make operations more complicated,
especially when serving several small countries.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CANE-7mX0QBVJgATmV2UMNBtuCXxyCwjUzTv%3D7mM%2BN%3DSB4aOLRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
