codicoop / boilerplate_django

Plantilla pels nous projectes web amb Django.
GNU General Public License v3.0
0 stars 0 forks source link

Change language #30

Closed nabiu256 closed 2 years ago

nabiu256 commented 2 years ago

Afegit la view django.conf.urls.i18n i un select en la template base per tal que l'usuari pugui canviar l'idioma des de qualsevol view (que extengui de la base).

Ho he tret de la pròpia documentació de Django, aquí.

perepicornell commented 2 years ago

Ara m'adono d'una altra cosa. Entenc lo del dropdown ja que és com ho monta django, cosa que facilita el tema d'enviar-ho via POST (trobo estrany que django hagin fet això via post però bé, això és un altre tema xD) El problema que hi veig és que el dropdown només es justifica quan la llista d'idiomes és llarga. Per 2 o 3 idiomes el que convé per usabilitat és mostrar els enllaços, tal com apareixen ara a develop amb els canvis de la Marta.

De moment en la meva experiència m'he trobat que sempre que algú ha dissenyat un canvi d'idioma m'ho han fet amb enllaços, sense desplegable, cosa que em fa pensar que el que ens passarà serà que en cada projecte que fem servir el boilerplate ens tocarà substituir el desplegable per enllaços. Per això penso que seria més útil ja deixar el boilerplate amb enllaços.

Es pot fer que igualment ho envii per POST, amb un camp hidden, però sent una cosa que es pot processar perfectament via GET no sé si té sentit haver de fer invents amb JS.

He fet un cop d'ull i he trobat aquest template tag:

from django.core.urlresolvers import resolve, translate_url
@register.simple_tag(takes_context=True)
def change_lang(context, lang=None, *args, **kwargs):
    path = context['request'].path
   return translate_url('path',lang)`

No ho he provat encara però per si et resulta útil. Ho he vist als comentaris d'aquí: https://djangosnippets.org/snippets/2875/ I aquest link l'he tret d'una de les respostes d'aquí: https://stackoverflow.com/questions/11437454/django-templates-get-current-url-in-another-language on també es proposa alguna altra alternativa. Tirant de template tag vol dir que al final la URL de canvi d'idioma la pots construir així: href="{% change_lang 'en' %}"

nabiu256 commented 2 years ago

He fet uns canvis amb la template tag que has linkejat (actualitzant-la a la versió actual de Django, que aquesta és de la versió 1.x). Fent-ho així funciona bé com volem, l'única i petita diferència és que amb la manera de Django aquesta retornava una cookie a l'usuari automàticament que mantenia la preferència de l'idioma durant tota la sessió però ara ja no.

Haig de dir que havent-me mirat el codi font de Django, ara sí que no entenc ben bé per què ho plantegen com un POST. Inicialment pensava que d'alguna manera modificaven en algun lloc la preferència d'idioma de l'usuari, i per tant sí que tenia cert sentit, segons RESTful, dir que era un POST. Però mirant el codi de la view que donen, l'únic que fa es redirigir i enviar una cookie. Ni idea.

I igualment, una mica com sempre, si mai vulguessim això de la cookie, ho veig tan senzill com agafar el codi de la font i reimplementar, o simplement fer algun truc per canviar la request de GET a POST entremig i ja.

nabiu256 commented 2 years ago

Pensant en la teva proposta, de per si em sembla bé, però crec que potencialment té algun que altre desaventatge respecte la manera en com ho implmeneta Django (amb la vista especialitzada):

Entenc doncs que hi hauria dues possibilitats, que són:

Diga'm què en penses. Després d'escriure això haig de dir que em semblen bé les dues, i tot i que m'inclino potser més per la de la vista, tampoc és que tingui raons molt fortes per fer-ho.

perepicornell commented 2 years ago

Interessant.. merci! no ho tinc clar, m'agradaria aprendre'n més sobre com es recomana fer-ho o almenys veure exemples, per si de cas ens estem complicant amb una cosa que ja está molt resolta.. Ja miraré què trobo. Si de cas, per no bloquejar, de moment ho podriem deixar com tu prefereixis o et sigui més fàcil i així podem tancar la branch.

Ho apunto al backlog per no oblidar-me'n

El dc., 18 de maig 2022, 16:57, JanaL @.***> va escriure:

Pensant en la teva proposta, de per si em sembla bé, però crec que potencialment té algun que altre desaventatge respecte la manera en com ho implmeneta Django (amb la vista especialitzada):

  • Al no tenir una vista especialitzada pel tema idioma, el servidor haurà d'enviar per cada request una cookie que substitueixi a l'anterior (o suposo que simplement es pot comprovar si l'idioma ha canviat amb la cookie anterior i si no, no fer res? Haig d'admetre que vaig mirar-me just ahir la documentació bàsica de les HTTP Cookies perquè no les havia tocat mai).
  • Tot i que és cert que és un cas marginal, podria donar-se el cas que se li canviés a un usuari el seu idioma preferit sense voler-ho, per exemple, si li envien un link de la web que està en un idioma que no és el seu, el servidor li canviarà la cookie i llavors haurà necessàriament de canviar d'idioma manualment si no vol que les pàgines li segueixin sortint amb aquell idioma.
  • Això ja és més de codi / estructuració, però em dona la sensació de ser el codi més net/estructurat si tenim una view sola que és la que afecta a l'idioma d'un usuari en canvi de que siguin totes les requests les que canviin idioma (que entenc que tampoc seria pas gens complicat, entenc que es podia fer un middleware molt senzill que simplement fes la comprovació que descrius i ja. De fet mirat així sembla bastant senzill també, el que potser si hi ha algun bug resulta més difícil de trobar?)

Entenc doncs que hi hauria dues possibilitats, que són:

  • La teva idea per cada URL, que podria ser implementada amb un middleware nostre que comprovi per cada request la cookie d'idioma i l'idioma de la URL demanada, i faci els canvis necessaris.
  • Una implementació pròpia (o un workaround pel tema del POST) de la implementació de Django, amb el que sigui l'usuari que es canvii la cookie d'idioma a través de donar-li als links d'idioma.

Diga'm què en penses. Després d'escriure això haig de dir que em semblen bé les dues, i tot i que m'inclino potser més per la de la vista, tampoc és que tingui raons molt fortes per fer-ho.

— Reply to this email directly, view it on GitHub https://github.com/codicoop/boilerplate_django/pull/30#issuecomment-1130123750, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFVRQTJKLJLOB4S5Y7J2BTVKUAMVANCNFSM5VYXDKSA . You are receiving this because your review was requested.Message ID: @.***>

nabiu256 commented 2 years ago

D'acord! Doncs per ara ho deixo com més fàcil sigui implementar-ho. Si vols, ja que segurament vas més ocupat, em puc posar jo quan acabi alguna altra cosa del boilerplate a mirar també com fa normalment la gent això amb Django.

perepicornell commented 2 years ago

Si t'ho pots mirar tu perfecte, només que ho baixaria molt de prioritat respecte les altres coses :)

El dc., 18 de maig 2022, 17:42, JanaL @.***> va escriure:

D'acord! Doncs per ara ho deixo com més fàcil sigui implementar-ho. Si vols, ja que segurament vas més ocupat, em puc posar jo quan acabi alguna altra cosa del boilerplate a mirar també com fa normalment la gent això amb Django.

— Reply to this email directly, view it on GitHub https://github.com/codicoop/boilerplate_django/pull/30#issuecomment-1130183626, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFVRQROB2LC6AJP5DFYPMLVKUFVDANCNFSM5VYXDKSA . You are receiving this because your review was requested.Message ID: @.***>

nabiu256 commented 2 years ago

He estat mirant i possiblement fer algun canvi petit on tinguem links que facin onclick=this.parentNode.submit() o alguna cosa així ho soluciona i no sé si és una cosa tan lletja. En tot cas ho he provat de fer però les meves abilitats de front estan molt rovellades, així que simplement ho deixo com està amb la custom tag.