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

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.

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

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

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

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