Permettre à l'action "converser" de garder aussi la langue en mémoire SQL pour les visiteurs connectés #4912

Open
opened 1 year ago by rastapopoulos · 3 comments
Owner

Actuellement l'action "converser" n'est pas très polyvalente :

  • soit ça ne change que le cookie public
  • soit ça garde en base + cookie ecrire uniquement si dans ecrire/

Or de très nombreux sites ont des utilisateurices publics : forums, accès restreint, extranet, e-commerce, magazine, adhérents, et j'en passe.

Tout comme de nombreuses évolutions concernant ces comptes publics, l'action de changement de langue devrait évoluer pour mieux les prendre en compte. Elle devrait savoir, soit par défaut soit au moins par un argument, enregistrer en base SQL le choix de langue de ces personnes.

M'est-avis que ça devrait être par défaut (si on détecte un compte connecté, on update son spip_auteurs au passage, tout comme pour le cas ecire/). Sinon avec un argument à donner en plus.

C'est notamment indispensable pour envoyer des notifications dans la bonne langue voulue par ces gens.

Actuellement l'action "converser" n'est pas très polyvalente : - soit ça ne change que le cookie public - soit ça garde en base + cookie ecrire *uniquement* si dans ecrire/ Or de très nombreux sites ont des utilisateurices publics : forums, accès restreint, extranet, e-commerce, magazine, adhérents, et j'en passe. Tout comme de nombreuses évolutions concernant ces comptes publics, l'action de changement de langue devrait évoluer pour mieux les prendre en compte. Elle devrait savoir, soit par défaut soit au moins par un argument, enregistrer *en base SQL* le choix de langue de ces personnes. M'est-avis que ça devrait être par défaut (si on détecte un compte connecté, on update son spip_auteurs au passage, tout comme pour le cas ecire/). Sinon avec un argument à donner en plus. C'est notamment indispensable pour envoyer des notifications dans la bonne langue voulue par ces gens.
rastapopoulos added this to the 4.1 milestone 1 year ago
rastapopoulos added the
amélioration
label 1 year ago
Owner

+1

Un cas d'utilisation typique : le plugin Menu de langue avec liens qui permet de changer sa langue sur le site public.
Et donc là quand on choisit une langue différente de sa langue perso, les notifs ne l'utilisent pas.

Mettre à jour la langue en base pourrait être le défaut, mais rester désactivable (donc param en plus ?) : j'imagine qu'il y a des cas où on voudrait distinguer la langue choisie pour consulter le site (cookie) de sa langue personnelle (sql).

+1 Un cas d'utilisation typique : le plugin [Menu de langue avec liens](https://git.spip.net/spip-contrib-extensions/menu_langues_liens) qui permet de changer sa langue sur le site public. Et donc là quand on choisit une langue différente de sa langue perso, les notifs ne l'utilisent pas. Mettre à jour la langue en base pourrait être le défaut, mais rester désactivable (donc param en plus ?) : j'imagine qu'il y a des cas où on voudrait distinguer la langue choisie pour consulter le site (cookie) de sa langue personnelle (sql).
Poster
Owner

Voici le diff de ce que j'ai ajouté pour l'instant dans une surcharge perso dans mon projet uniquement. Cette modif est pour l'instant sans option (pas seulement si arg=truc comme pour la partie admin), c'est-à-dire que dès qu'on détecte qu'il y a une personne connectée alors ça garde aussi le changement dans son compte en base SQL.

--- /ecrire/action/converser.php
+++ /plugins/plugin-collab/squelettes/action/converser.php
@@ -57,6 +57,18 @@
  */
 function action_converser_changer_langue($update_session) {
 	if ($lang = _request('var_lang')) {
+		// On garde en mémoire SQL et session si la personne est connectée
+		if (isset($GLOBALS['visiteur_session']['id_auteur']) and $GLOBALS['visiteur_session']['id_auteur'] > 0) {
+			sql_updateq('spip_auteurs', array('lang' => $lang), 'id_auteur = ' . $GLOBALS['visiteur_session']['id_auteur']);
+			$GLOBALS['visiteur_session']['lang'] = $lang;
+			$session = charger_fonction('session', 'inc');
+			if ($spip_session = $session($GLOBALS['visiteur_session'])) {
+				spip_setcookie('spip_session', $spip_session, [
+					'expires' => time() + 3600 * 24 * 14
+				]);
+			}
+		}
+		
 		action_converser_post($lang);
 	} elseif ($lang = _request('var_lang_ecrire')) {
 		if ($update_session) {

Voici le diff de ce que j'ai ajouté pour l'instant dans une surcharge perso dans mon projet uniquement. Cette modif est pour l'instant *sans option* (pas seulement si arg=truc comme pour la partie admin), c'est-à-dire que *dès qu'on détecte qu'il y a une personne connectée* alors ça garde aussi le changement dans son compte en base SQL. ``` diff --- /ecrire/action/converser.php +++ /plugins/plugin-collab/squelettes/action/converser.php @@ -57,6 +57,18 @@ */ function action_converser_changer_langue($update_session) { if ($lang = _request('var_lang')) { + // On garde en mémoire SQL et session si la personne est connectée + if (isset($GLOBALS['visiteur_session']['id_auteur']) and $GLOBALS['visiteur_session']['id_auteur'] > 0) { + sql_updateq('spip_auteurs', array('lang' => $lang), 'id_auteur = ' . $GLOBALS['visiteur_session']['id_auteur']); + $GLOBALS['visiteur_session']['lang'] = $lang; + $session = charger_fonction('session', 'inc'); + if ($spip_session = $session($GLOBALS['visiteur_session'])) { + spip_setcookie('spip_session', $spip_session, [ + 'expires' => time() + 3600 * 24 * 14 + ]); + } + } + action_converser_post($lang); } elseif ($lang = _request('var_lang_ecrire')) { if ($update_session) { ```
marcimat modified the milestone from 4.1 to 4.2 10 months ago
Poster
Owner

Pour faire une proposition intégrable dans une branche/PR, il faudrait décider si on veut que ce soit le comportement par défaut, désactivable optionnellement, ou si on veut garder le comportement actuel par défaut, et enregistrer que sur option.

Après réflexion il me semble que ça doit rester le comportement par défaut, car le nombre de langues en public n'est pas forcément le même qu'en admin. Cette dernière est implémentée dans moult langues, et donc si on est russe, on peut mettre en russe, mais le site lui pourrait n'être qu'en anglais et espagnol, donc on va choisir de le lire en anglais par ex, mais on veut pas que notre admin de rédac passe en anglais dans ce cas, puisqu'il y a bien notre langue natale russe.

Donc ce serait plutôt une option à passer dans un param en plus, quand on sait que c'est pour un site/appli qui a plein de visiteurs publics par ex, qui doiventt avoir leur langue gardée en mémoire.

OU BIEN, encore plus intelligent :

  • par défaut pour les admins/rédacs ça n'enregistrent que pour l'admin
  • mais par défaut AUSSI, si on détecte qu'il y a un visiteur public (6forum), alors on enregistre en base en public !
  • une option permet d'activer l'enregistrement en base tout le temps (donc rédac ou visiteur peu importe)
Pour faire une proposition intégrable dans une branche/PR, il faudrait décider si on veut que ce soit le comportement par défaut, désactivable optionnellement, ou si on veut garder le comportement actuel par défaut, et enregistrer que sur option. Après réflexion il me semble que ça doit rester le comportement par défaut, car le nombre de langues en public n'est pas forcément le même qu'en admin. Cette dernière est implémentée dans moult langues, et donc si on est russe, on peut mettre en russe, mais le site lui pourrait n'être qu'en anglais et espagnol, donc on va choisir de le lire en anglais par ex, mais on veut pas que notre admin de rédac passe en anglais dans ce cas, puisqu'il y a bien notre langue natale russe. Donc ce serait plutôt une option à passer dans un param en plus, quand on sait que c'est pour un site/appli qui a plein de visiteurs publics par ex, qui doiventt avoir leur langue gardée en mémoire. OU BIEN, encore plus intelligent : - par défaut pour les admins/rédacs ça n'enregistrent que pour l'admin - mais par défaut AUSSI, si on détecte qu'il y a un visiteur public (6forum), alors on enregistre en base en public ! - une option permet d'activer l'enregistrement en base *tout le temps* (donc rédac ou visiteur peu importe)
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.