#17569 closed New feature (duplicate)
i18n_patterns and set_language
| Reported by: | anonymous | Owned by: | nobody | 
|---|---|---|---|
| Component: | Uncategorized | Version: | 1.4-alpha-1 | 
| Severity: | Normal | Keywords: | i18n_patterns, set_language | 
| Cc: | Triage Stage: | Unreviewed | |
| Has patch: | no | Needs documentation: | yes | 
| Needs tests: | yes | Patch needs improvement: | no | 
| Easy pickings: | no | UI/UX: | no | 
Description
Hi,
I wrote some code to set language with support for i18n_patterns.
from urlparse import urlparse
from django import http
from django.conf import settings
from django.utils import translation
from django.core.urlresolvers import resolve, reverse
from django.utils.translation import check_for_language
def set_language(request):
    next = request.REQUEST.get('next', None)
    if not next:
        next = request.META.get('HTTP_REFERER', None)
    if not next:
        next = '/'
    url = urlparse(next)
    try:
        r = resolve(url.path)
    except:
        next = '/'
    response = http.HttpResponseRedirect(next)
    lang_code = request.GET.get('language', None)
    if lang_code and check_for_language(lang_code):
        translation.activate(lang_code)
        try:
            next = reverse('%s:%s' % (r.namespace, r.url_name), args=r.args, kwargs=r.kwargs)
        except:
            pass
        else:
            response = http.HttpResponseRedirect(next)
        translation.deactivate()
        if hasattr(request, 'session'):
            request.session['django_language'] = lang_code
        else:
            response.set_cookie(settings.LANGUAGE_COOKIE_NAME, lang_code)
    return response
      Change History (4)
comment:1 by , 14 years ago
| Needs documentation: | set | 
|---|---|
| Needs tests: | set | 
comment:2 by , 14 years ago
| Resolution: | → needsinfo | 
|---|---|
| Status: | new → closed | 
comment:3 by , 14 years ago
| Has patch: | unset | 
|---|
If I understand correctly, this is a proposition to make set_language view translate the next it gets. I don't know if adding an extra resolve() is a good idea. Maybe someone can some up with a cleaner solution. Either way, this needs an *actual patch* (in form of a diff against trunk) including tests for new behavior and documentation of the change.
  Note:
 See   TracTickets
 for help on using tickets.
    
This issue quite unspecified. I can't tell what is this about. Closing as needs more info.