Les notifications inscription/désinscription sont parfois dans une langue étrangères #23

Closed
opened 5 months ago by cerdic · 6 comments
cerdic commented 5 months ago
Owner

Expérimenté par un utilisateur qui clique dans le lien desinscription depuis le réseau mobistar en belgique et reçoit du coup un mail en néerlandais alors que ce n'est pas une langue du site...

Après investigation

Je soupçonne donc que certains opérateurs (mobiles ?) modifient le Accept-Language envoyé par les navigateurs en y ajoutant une langue pour des raisons géographiques ou politiques, à moins les navigateurs mobiles ne prennent en compte le réseau sur lequel on est connecté pour accepter une langue en plus ?

Bref ça mets le brin du coup.

Expérimenté par un utilisateur qui clique dans le lien desinscription depuis le réseau mobistar en belgique et reçoit du coup un mail en néerlandais alors que ce n'est pas une langue du site... Après investigation - les pages de confirmation d'inscription/désinscription sont des minipres - minipres appelle `utiliser_langue_visiteur()` https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/minipres.php#L49 - en l'absence de session `utiliser_langue_visiteur()` bascule vers la première langue valide dans le `HTTP_ACCEPT_LANGUAGE` https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/lang.php#L394 Je soupçonne donc que certains opérateurs (mobiles ?) modifient le Accept-Language envoyé par les navigateurs en y ajoutant une langue pour des raisons géographiques ou politiques, à moins les navigateurs mobiles ne prennent en compte le réseau sur lequel on est connecté pour accepter une langue en plus ? Bref ça mets le brin du coup.
Poster
Owner

Il faut dire qu'au départ les minipres sont des fonctions principalement utilisées par l'espace privé, et donc en principe on a une session et donc un cookie de langue etc.

C'est donc l'utilisation en anonyme qui pose problème, notamment parce que la fonction changer_langue() vérifie la langue par rapport à la meta langues_proposees qui contient "toutes les langues valides connues de SPIP"
https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/lang.php#L43

Peut-être que dans l'espace public le mieux serait d'utiliser uniquement langues_multilingue qui sont les les langues cochées comme étant utilisées dans la configuration multilingue du site ?

A défaut, je pense que le mieux serait de régler la langue dans les actions de mailsubscribers, ce qui règlerait à la fois la langue du minipres et celle de la notification

Il faut dire qu'au départ les minipres sont des fonctions principalement utilisées par l'espace privé, et donc en principe on a une session et donc un cookie de langue etc. C'est donc l'utilisation en anonyme qui pose problème, notamment parce que la fonction `changer_langue()` vérifie la langue par rapport à la meta `langues_proposees` qui contient "toutes les langues valides connues de SPIP" https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/lang.php#L43 Peut-être que dans l'espace public le mieux serait d'utiliser uniquement `langues_multilingue` qui sont les les langues cochées comme étant utilisées dans la configuration multilingue du site ? A défaut, je pense que le mieux serait de régler la langue dans les actions de mailsubscribers, ce qui règlerait à la fois la langue du minipres et celle de la notification
Collaborator

Peut-être que dans l'espace public le mieux serait d'utiliser uniquement langues_multilingue qui sont les les langues cochées comme étant utilisées dans la configuration multilingue du site ?

Ha ben vi, ça me semble très bien ça :)

> Peut-être que dans l'espace public le mieux serait d'utiliser uniquement langues_multilingue qui sont les les langues cochées comme étant utilisées dans la configuration multilingue du site ? Ha ben vi, ça me semble très bien ça :)

Pareil, ne pas utiliser la liste complète des langues dans le public parait une chose à faire dans tous les cas.

Quant aux actions d'envois, sûrement qu'un algorithme de ce genre devrait être vérifié, avant de remettre la langue en cours du hit à la fin (Notifs avancées fait un truc comme ça) :

  • si c'est pour une lettre et qu'elle a une langue un jour, prendre ça en prio
  • sinon, pour une lettre sans langue ou pour les notifs fonctionnelles, si le destinataire a une langue configurée, on prend celle là (lang dans la table des inscrits OU lang du spip_auteurs si on détecte que l'inscrit a un compte utilisateur SPIP, avec son email par ex)
  • sinon, si c'est un envoi où on est sûr que le destinataire correspond à celui qui fait le hit PHP en cours, on regarde si une langue publique correspond à son navigateur qui fait la requête
  • sinon la langue principale du site
Pareil, ne pas utiliser la liste complète des langues dans le public parait une chose à faire dans tous les cas. Quant aux actions d'envois, sûrement qu'un algorithme de ce genre devrait être vérifié, avant de remettre la langue en cours du hit à la fin (Notifs avancées fait un truc comme ça) : - si c'est pour une lettre et qu'elle a une langue un jour, prendre ça en prio - sinon, pour une lettre sans langue ou pour les notifs fonctionnelles, si le destinataire a une langue configurée, on prend celle là (lang dans la table des inscrits OU lang du spip_auteurs si on détecte que l'inscrit a un compte utilisateur SPIP, avec son email par ex) - sinon, si c'est un envoi où on est sûr que le destinataire correspond à celui qui fait le hit PHP en cours, on regarde si une langue *publique* correspond à son navigateur qui fait la requête - sinon la langue principale du site
Poster
Owner

Ça devrait donc être un problème réglé indépendamment du fix du core

Ça devrait donc être un problème réglé indépendamment du fix du core
cerdic closed this issue 5 months ago

Je ne sais pas si j'ai bien saisi : le fait de s'assurer d'avoir la langue "la plus pertinente" oui c'est un problème en plus du fix du core, propre à mailsubscribers (à régler dans les différents endroits où il envoie des emails)… donc… il ne faut pas fermer ce ticket et le laisser ouvert non ?

Je ne sais pas si j'ai bien saisi : le fait de s'assurer d'avoir la langue "la plus pertinente" *oui* c'est un problème en plus du fix du core, propre à mailsubscribers (à régler dans les différents endroits où il envoie des emails)… donc… il ne faut *pas* fermer ce ticket et le laisser ouvert non ?

Aah mais ya eu des commits directs sur le plugin lui-même aussi désolé… (ça on le voit pas dans les notifs emails du ticket) 2d4fd3bc10 et aea310b43c

Aah mais ya eu des commits directs sur le plugin lui-même aussi désolé… (ça on le voit pas dans les notifs emails du ticket) https://git.spip.net/spip-contrib-extensions/mailsubscribers/commit/2d4fd3bc10251b6a9b66a1bd2d46f29c4766603a et https://git.spip.net/spip-contrib-extensions/mailsubscribers/commit/aea310b43c1631d311058f46b829a6af2a9889d2
Sign in to join this conversation.
No Label
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.