En Django quiero permitir una cadena de consulta de la forma? ...&lang=&... para establecer la URL actual. Idealmente, lang= se eliminaría de la cadena de consulta y la clave de idioma de la sesión se establecería en el nuevo idioma.
La URL final resultante sería la URL en la que aterriza el navegador. Esto debería suceder para cada URL en el sitio, además de los otros métodos de selección de idioma que i18n pone a disposición (así que supongo que esto sería un middleware).
No me gusta el enfoque POST para ver que parece ser el estándar para django-i18n .
¿Ya existe algo así?
Cadena de consulta de cambio de idioma de Django Middleware ?hl=langcode
https://gist.github.com/teury/5d2213181ed0abe06c316c19431f355e
import django from django.utils import translation from django.shortcuts import redirect, reverse def is_django_greater_than_1_10(): main_version = django.VERSION[0] if main_version > 1: return True sub_version = django.VERSION[1] if main_version == 1 and sub_version >= 10: return True return False if is_django_greater_than_1_10(): from django.utils.deprecation import MiddlewareMixin superclass = MiddlewareMixin else: superclass = object class LanguageMiddleware(superclass): def process_response(self, request, response): if request.resolver_match.view_name is "home": lang_url = request.GET.get('hl') if not lang_url: return response current_language = translation.get_language() if lang_url == current_language: return response translation.activate(lang_url) request.session[translation.LANGUAGE_SESSION_KEY] = lang_url return redirect(reverse('home') + '?hl=' + lang_url) else: return responseHe implementado este sistema en una sola url "home"
cambiar el idioma de acuerdo con el valor clave
Traducir por Google. Idioma nativo = Español
Después de leer la documentación de Django y darme cuenta de que los desarrolladores de Django también parecen estar en el negocio de hacer cumplir sus propios estándares de codificación (y aquí estoy pensando específicamente en este comentario en el código fuente:
Since this view changes how the user will see the rest of the site, it must only be accessed as a POST request. If called as a GET request, it will redirect to the page in the request (the 'next' parameter) without changing any state.) Decidí ir con la solución descrita en esta publicación , que estoy pegando a continuación (casi) literalmente (de ahí el diseño de la tabla no semántica):
<div id="languages"> <table > <tr> {% get_available_languages as languages %} {% for key, item in languages %} <td> <form action="/i18n/setlang/" method="post"> {% csrf_token %} <input type="hidden" name="language" value="{{key}}"/> <input id="lang_select_{{key}}" type = "image" src="/media/img/{{ key }}.gif" alt="{{ item }}"/> </form> </td> {% endfor %} </tr> </table> </div> También se me ocurrió mi propia solución JS, que es un poco más flexible y mucho más complicada, por lo que realmente no vale la pena (aunque proporciona enlaces: pero dado que necesitan un atributo onClick , o un equivalente moral, son inútiles para fines de SEO ).
Por supuesto, tirar del código y eliminar la tonta limitación GET también es una opción, aunque una de mayor mantenimiento.
PD: Aquellos que encuentren mi comentario anterior contradictorio (y también, sin duda, mi búsqueda equivocada) deberían considerar cómo la postura que requiere que POST cambie el idioma va en contra de SE transversal, mientras obliga a saltar a través de este tipo de aros para honrar el convención de diseño establecida de permitir al usuario cambiar de idioma haciendo clic en los iconos de bandera.