search

karpenoktem / kninfra

Digital infrastructure of Karpe Noktem
http://karpenoktem.nl/
10 stars 14 forks source link

Maak website meertalig #392

Closed bwesterb closed 8 years ago

bwesterb commented 8 years ago

Zie #388. Draai eerst python manage.py compilemessages

De taal van de website wordt op de volgende manier bepaald.

  1. Als de taal in de URL staat – bijvoorbeeld /nl/over of /en/over, dan wordt deze taal gebruikt. Verder wordt dan ook de voorkeur voor deze taal opgeslagen in de sessie van de gebruiker/gast.
  2. Als in de sessie een voorkeur is opgeslagen, wordt deze voorkeur gebruikt. Als je dus eerst /en/over bezoekt en daarna /agenda, dan zal de agenda in het Engels zijn.
  3. Als geen van de voorgaande het geval is, dan wordt de taal gegokt aan de hand van wat de browser als Accept-Language stuurt. Als de browser geen voorkeur heeft, dan wordt de site in het nederlands getoond. Er is een uitzondering: een voorkeur voor Engels van de browser wordt genegeerd.

screen shot 2016-09-21 at 15 47 10

aykevl commented 8 years ago

Willen we echt de en arr toevoegen? Dat is best wat werk om te vertalen. We kunnen het natuurlijk wel doen, als er mensen zijn die daar de moeite in willen steken. Maar het moet niet alleen vertaald worden, maar de vertaling moet ook bijgehouden worden.

bwesterb commented 8 years ago

Hij valt vanzelf terug naar nederlands: dus alles dat niet vertaald is is in het nederlands en als we iets veranderen zodat de vertaling niet meer klopt, dan valt het terug naar nederlands. Dus het kan niet echt kwaad en ik denk dat sommige mensen hier heel veel plezier uit halen om het te maken :).

bwesterb commented 8 years ago

@aykevl Je zei dat je wou nadenken over hoe we het wisselen tussen talen zouden regelen. Heb jij al een idee?

aykevl commented 8 years ago

Net even met Roel overlegd. Het lijkt ons het handigste om de instelling per account te maken, met een taalswitch voor externen op basis van cookies. Default naar Nederlands, aangezien veel mensen (ik in elk geval, neem aan dat er meer zijn) een browser hebben die op het Engels staat maar toch gewoon Nederlands willen in de website. De taalswitch kan bijvoorbeeld rechts bovenin staan, iets van een Nederlands vlaggetje (en als je daar op klikt krijg je een menuutje met een serie vlaggetjes).

bwesterb commented 8 years ago

Wat dacht je van een eenmalige popup met grote vlaggen als je browser niet op Nederlands staat en dan inderdaad kleine vlaggetjes rechtsonder?

bwesterb commented 8 years ago

Het is zonde als iemand de helft van de tijd de vlaggetjes die kunnen vinden. Misschien moeten we ook URL's maken voor vertalingen zodat Google die direct pakt voor gasten...

bwesterb commented 8 years ago

@aykevl @RoelBouman Technisch is het grootste deel af. Waarschijnlijk wil Ayke zich nog even bemoeien met hoe het taal-uitkies-dingetje er rechtsonder uitziet, maar dan kan het al online. Het grote werk is dan nog (als het al online staat), om alles te vertalen (en te testen of daar geen fouten zijn gemaakt in de speciale tekens). Misschien is dat iets voor jou, @RoelBouman ?

aykevl commented 8 years ago

Snel een reactie per mail. Ik heb het echt heel druk met school, misschien kan ik er van het weekend beter naar kijken.

Ik bedoelde een taalselectie rechtsboven, zei ik rechtsonder? Ik heb nog niet gekeken hoe dat mooi in het design past. Een popup als je de website voor het eerst opent lijkt me minder fraai (in een andere browser / OS, na het wissen van cookies, ...). Veel websites hebben popups en het is best irritant. Misschien is zo'n balk aan de bovenkant van de website mooier? Net als Chrome wel eens doet (deed?), of GitHub soms geeft.

Als URLs per taal werken, dan is er dacht ik een manier (via headers in <head>) om Google te vertellen dat een bepaalde pagina ook in andere talen bestaat (vergelijkbaar met rel=canonical).

Ik denk niet dat we problemen gaan krijgen met speciale tekens, aangezien we die al gebruiken (in sommige namen bijvoorbeeld), maar het is iets om op te letten.

Dat waren even een paar opmerkingen. Hopelijk kan ik binnenkort meer gefundeerde opmerkingen maken.

sankhara-infra commented 8 years ago

Ik bedoelde een taalselectie rechtsboven, zei ik rechtsonder? Ik heb nog niet gekeken hoe dat mooi in het design past.

Ja, en dan met vlaggetjes. Wil jij dat doen?

Een popup als je de website voor het eerst opent lijkt me minder fraai (in een andere browser / OS, na het wissen van cookies, ...). Veel websites hebben popups en het is best irritant. Misschien is zo'n balk aan de bovenkant van de website mooier? Net als Chrome wel eens doet (deed?), of GitHub soms geeft.

Een balk is ook goed, ja. Als het maar opvalt.

Als URLs per taal werken, dan is er dacht ik een manier (via headers in <head>) om Google te vertellen dat een bepaalde pagina ook in andere talen bestaat (vergelijkbaar met rel=canonical).

Dat zit er nu al in :).

Ik denk niet dat we problemen gaan krijgen met speciale tekens, aangezien we die al gebruiken (in sommige namen bijvoorbeeld), maar het is iets om op te letten.

Met speciale tekens bedoelde ik bijvoorbeeld de “%(naam)s” en “\n” die in de te-vertalen-strings staan. Het is makkelijk tijdens het vertalen foutjes te maken door die niet goed over te nemen. Dus dat moet getest worden.

bwesterb commented 8 years ago

(Dat was ik.)

RoelBouman commented 8 years ago

Wat bedoel je precies met de speciale tekens controleren? Of wil je dat ik zelf naar de Engelse vertaling kijk?

bwesterb commented 8 years ago

Een voorbeeld van een lemma om vertaald te worden is de volgende

#: kn/subscriptions/templates/subscriptions/subscription-notification.mail.html:28
#, python-format                                                                 
msgid ""                                                                         
"\n"                                                                             
"Je hebt je afgemeld\n"                                                          
"voor <a href=\"%(BASE_URL)s%(event_url)s\">%(humanName)s</a>.\n"                
msgstr ""

Dat moet dan veranderd worden (voor Engels) in

#: kn/subscriptions/templates/subscriptions/subscription-notification.mail.html:28
#, python-format                                                                 
msgid ""                                                                         
"\n"                                                                             
"Je hebt je afgemeld\n"                                                          
"voor <a href=\"%(BASE_URL)s%(event_url)s\">%(humanName)s</a>.\n"                
msgstr ""
"\n"
"You unsubscribed for\n"
"<a href=\"%(BASE_URL)s%(event_url)s\">%(humanName)s</a>."

Het is belangrijk dat er niet per ongeluk bijvoorbeeld

"<a href="%(BASE_URL)s%(event_url)">%(humanName)s</a>."

in komt te staan (er mist een s en twee \).

Als je naar de Engels vertaling wilt kijken? Graag!

bwesterb commented 8 years ago

De PR is, wat mij betreft, klaar om gemerged te worden. De bal ligt nu bij jou, @aykevl

aykevl commented 8 years ago

Ja, en dan met vlaggetjes. Wil jij dat doen?

Ja. Ik heb er hopelijk binnenkort tijd voor, maar dit staat niet hoog op mijn prioriteitenlijst.

[over hreflang]

Dat zit er nu al in :).

Handig!

Momenteel heb ik een dev server draaien op https://kndev.aykevl.nl/

Ik heb niet echt naar de code gekeken, maar heb wel een paar opmerkingen over de werking.

  1. Op dit moment kun je de taal onderin instellen. Ziet er niet heel fraai uit, maar is functioneel. Later kan dit nog verbeterd worden (nadat de pull request gemergd is).
  2. Als ik het goed zie wordt de taalinstelling puur in de sessie opgeslagen? Ik had eigenlijk gedacht dat die in een aparte cookie opgeslagen zou worden, maar in de sessie werkt ook. Een aparte cookie heeft misschien wel voordelen: Je zou een taalcookie bijvoorbeeld een praktisch oneindige levensduur kunnen geven, waar je dat misschien niet wilt bij een sessie. Verder is het best practice om bij het inloggen de sessie ID opnieuw te genereren en ik vermoed dat Django dit automatisch doet, om session fixation te voorkomen (leden kunnen cookies instellen op karpenoktem.nl via leden.karpenoktem.nl, dus het is goed dat dit gebeurd). Dan verdwijnt de taalinstelling.
  3. Simpelweg naar een URL gaan in een andere taal is genoeg om de taalinstelling te veranderen, dat lijkt me op z'n minst verwarrend en zeker niet de bedoeling. Denk aan een Engelssprekend lid dat met elke link die hij opent (via de mail bijvoorbeeld) de taalinstelling weer moet veranderen (want die link begint mogelijk met /nl/). Dat betekent dus dat de taal selector puur de taalprefix veranderd. Dat lijd mij tot...
  4. De taalprefix is handig voor Google en als je iemand een pagina in een specifieke taal wilt laten zien, maar het lijkt me onverstandig om URLs zonder taal (zoals /over) door te sturen naar URLs met taalprefix (/en/over etc). Sowieso lijkt het me voordelig dat bezoekers normaal gesproken op een webpagina zonder taalprefix zitten - dit is handig als links worden doorgestuurd (zie 3). Verder lijkt het me beter om Nederlandse pagina's in Google standaard te linken naar een URL zonder taalprefix (dit kan denk ik i.c.m. rel=canonical).
  5. Het is niet mogelijk om de taal als lid in je account in te stellen? Dit lijkt me wel praktisch. 1x inloggen en de taal staat goed, in plaats van dat je die apart nog moet aanpassen.

Wat heeft prioriteit, welke taalinstelling is het belangrijkste? Is dat zoals je in de eerste comment aangaf?

Mijn voorkeur gaat uit naar het volgende (geëvalueerd van boven naar beneden):

bwesterb commented 8 years ago

Op dit moment kun je de taal onderin instellen. Ziet er niet heel fraai uit, maar is functioneel. Later kan dit nog verbeterd worden (nadat de pull request gemergd is). Helemaal mee eens. Vlaggetjes zouden beter zijn. En we moeten nog een niet-al-te-in-your-face banner maken voor eerste bezoekers. Als ik het goed zie wordt de taalinstelling puur in de sessie opgeslagen? Ik had eigenlijk gedacht dat die in een aparte cookie opgeslagen zou worden, maar in de sessie werkt ook. Een aparte cookie heeft misschien wel voordelen: Je zou een taalcookie bijvoorbeeld een praktisch oneindige levensduur kunnen geven, waar je dat misschien niet wilt bij een sessie. Verder is het best practice om bij het inloggen de sessie ID opnieuw te genereren en ik vermoed dat Django dit automatisch doet, om session fixation https://en.m.wikipedia.org/wiki/Session_fixation te voorkomen (leden kunnen cookies instellen op karpenoktem.nl via leden.karpenoktem.nl, dus het is goed dat dit gebeurd). Elke gebruiker heeft een “preferred_language” in zijn entiteit staan. Bij het inloggen wordt de taal in de sessie overschreven met deze preferred_language. Bij het bezoeken van URL’s waarin de taal expliciet staat, wordt de preferred_language aangepast. Dit is ook de manier waarop de taal-wisselaar werkt. Simpelweg naar een URL gaan in een andere taal is genoeg om de taalinstelling te veranderen, dat lijkt me op z'n minst verwarrend en zeker niet de bedoeling. Denk aan een Engelssprekend lid dat met elke link die hij opent (via de mail bijvoorbeeld) de taalinstelling weer moet veranderen (want die link begint hoogstwaarschijnlijk met /nl/). Dat lijd mij tot… Dat is wel een punt. Misschien willen we op een aparte pagina de gebruiker kunnen laten instellen dat zijn taal altijd een bepaalde taal is, wat de URL ook is. Het voordeel van aparte URL’s is dat Google dat waarschijnlijk beter begrijpt. Taalinstelling via URL - links gaan naar pagina's met dezelfde taalprefix (of geen prefix als die er niet was). Dus bijvoorbeeld van /en/home kun je naar /en/over en van /nl/home kun je naar /nl/over, maar als je op /home zit kun je naar /over. (Zie 4). Dat zou mooi zijn, maar ik weet niet of Django dat kan door de manier waarop i18n_patterns werkt. Daar moet nog over gedacht worden.

Bas

bwesterb commented 8 years ago

Maar, bottom line, denk je dat we de PR al kunnen mergen? We kunnen de problemen die je aankaart achteraf nog oplossen.

aykevl commented 8 years ago

Elke gebruiker heeft een “preferred_language” in zijn entiteit staan. Bij het inloggen wordt de taal in de sessie overschreven met deze preferred_language. Bij het bezoeken van URL’s waarin de taal expliciet staat, wordt de preferred_language aangepast. Dit is ook de manier waarop de taal-wisselaar werkt.

Ah, dat had ik nog niet gezien.

Mijn voorstel was eigenlijk dat je op 2 plaatsen taalkeuzes hebt (was ik denk ik niet heel duidelijk in). 1 in je account zelf (wat de taal bepaald op het moment dat je niet op een taalgevoelige URL zit), en 1 onderin waarmee puur de URL veranderd (en verder niks). Dus dan heeft de URL altijd de hoogste prioriteit, maar als je op een URL zit zonder taalprefix dat dan de taalvoorkeur uit het account genomen wordt (preferred_language).

Zoiets als dit (groene achtergrond is een userstyle om testsite van echte site te onderscheiden):

screenshot-4

De standaard is dan wat in je profiel staat ingesteld (preferred_language). Als je niet bent ingelogd, is het afhankelijk van wat je browser aangeeft (of eventueel een cookie of sessie variabele).

FWIW: Facebook gebruikt en_PI als Pirate English.

Zoals het nu is, kan het denk ik wel gemergd worden. En aangezien ik nu toch niet echt de tijd hiervoor heb, denk ik niet dat ik echt kan klagen...

Een nitpick: ik vermoed dat agenda in het Engels beter vertaald kan worden als 'agenda'. Het woord 'diary' wordt denk ik meer gebruikt voor dagboek.

bwesterb commented 8 years ago

Mijn voorstel was eigenlijk dat je op 2 plaatsen taalkeuzes hebt (was ik denk ik niet heel duidelijk in). 1 in je account zelf (wat de taal bepaald op het moment dat je niet op een taalgevoelige URL zit), en 1 onderin waarmee puur de URL veranderd (en verder niks). Dus dan heeft de URL altijd de hoogste prioriteit, maar als je op een URL zit zonder taalprefix dat dan de taalvoorkeur uit het account genomen wordt (preferred_language).

Maar hoe stel je dan de taalvoorkeur in? Als je al de taal kunt wijzigingen met een popup rechtsbenden, dan zullen de meeste gebruikers niet snel ergens in een verborgen hoekje de pagina opzoeken met taalinstellingen.

Dat zouden we kunnen oplossen met een “maak standaard” knopje rechts-naast de dropdown?

Verder is er nog steeds het probleem dat hoe Django’s i18n_patterns werkt, ik niet zie hoe we dit makkelijk kunnen implementeren.

Een nitpick: ik vermoed dat agenda in het Engels beter vertaald kan worden als 'agenda'. Het woord 'diary' wordt denk ik meer gebruikt voor dagboek.

IJsbrand heeft de vertaling gemaakt en niet gekeken waar de woorden gebruikt worden. Sowieso is de Engelse vertaling nog niet af, dus daar moet nog doorheen gelopen worden.

Groeten,

Bas

RoelBouman commented 8 years ago

Op zich lijkt het me leuk om naar die vertaling te kijken, maar ik denk niet er al snel veel tijd voor vrij te kunnen maken. Ik gooit het op de todo list;)

2016-09-24 5:36 GMT+02:00 Bas Westerbaan notifications@github.com:

De PR is, wat mij betreft, klaar om gemerged te worden. De bal ligt nu bij jou, @aykevl https://github.com/aykevl

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/karpenoktem/kninfra/pull/392#issuecomment-249342676, or mute the thread https://github.com/notifications/unsubscribe-auth/AOYEVg6PNr0u1FUWmSpo67GhvcRI6xRWks5qtJq9gaJpZM4J50xa .

aykevl commented 8 years ago

Maar hoe stel je dan de taalvoorkeur in? Als je al de taal kunt wijzigingen met een popup rechtsbenden, dan zullen de meeste gebruikers niet snel ergens in een verborgen hoekje de pagina opzoeken met taalinstellingen.

Dat zouden we kunnen oplossen met een “maak standaard” knopje rechts-naast de dropdown?

Verder is er nog steeds het probleem dat hoe Django’s i18n_patterns werkt, ik niet zie hoe we dit makkelijk kunnen implementeren.

Als ik er zin in heb zal ik er nog eens naar kijken, dit is nu functioneel.

bwesterb commented 8 years ago

Graag