Ce n'est pas un bug, c'est "voulu" ou presque.
Les notifications par mail (commentaires, utilisateurs, ...) sont envoyés à tous les admins.
C'est la fonction pwg_mail_notification_admins du fichier include/functions_mail.inc.php, le code est même celui-ci
...
switch_lang_to(get_default_language());
Le but est envoyé un seul mail à tous les admins quelque soit la langue.
Et la langue (la meilleure) qui doit être connu de tous, c'est celle guest...
Vous allez me dire bla, bla, bla, j'ai une galerie en chinois dont je ne gère pas le contenu mais les admins ne parlent que anglais... blablabla...
Solutions possibles:
o définir la langue par défaut des admins (dans $conf ou celle du webmaster)
o regrouper les mails par langue mais risque d'envoyer plusieurs mails => mais les mails, c'est long et pas question de faire tout le processus de la NBM.. mais c'est quand même facilement faisable puisque ca a été pour le mail des catégories...
Allez, faites-moi une demande d'évolutions et je vous fais ca...
Hors ligne
Eric a écrit:
VDigital a écrit:
Rub?
Eric, tu nous ouvres le bug.Mantis ou Redmine ? Ou les 2 ?
L'officiel pour l'instant c'est Piwigo Bugtracker
Hors ligne
rub a écrit:
Allez, faites-moi une demande d'évolutions et je vous fais ca...
J'avais pas vu... je me suis assigné la tâche...
Hors ligne
rub a écrit:
Ce n'est pas un bug, c'est "voulu" ou presque.
Les notifications par mail (commentaires, utilisateurs, ...) sont envoyés à tous les admins.
C'est la fonction pwg_mail_notification_admins du fichier include/functions_mail.inc.php, le code est même celui-ci...
switch_lang_to(get_default_language());Le but est envoyé un seul mail à tous les admins quelque soit la langue.
Et la langue (la meilleure) qui doit être connu de tous, c'est celle guest...
Ok, je suis d'accord avec toi concernant l'actuelle fonction pwg_mail_notification_admins() mais, d'après ce que je comprends (et je ne suis pas sûr de moi ;-) ), la fonction pwg_mail() est dans le même cas : C'est la langue du Guest qui est prise en compte.
En tous cas, c'est la seule explication que j'ai trouvée pour l'instant sur le fait que, malgré Extended Description et les balises de langue correctes, les mails aux visiteurs sont toujours dans la langue du Guest.
Hors ligne
Eric a écrit:
Ok, je suis d'accord avec toi concernant l'actuelle fonction pwg_mail_notification_admins() mais, d'après ce que je comprends (et je ne suis pas sûr de moi ;-) ), la fonction pwg_mail() est dans le même cas : C'est la langue du Guest qui est prise en compte.
C'est faux.
pwg_mail() utilise $user['language'] et c'est tout! Pas de modif de langue seul pwg_mail_notification_admins() change les langues.
Eric a écrit:
En tous cas, c'est la seule explication que j'ai trouvée pour l'instant sur le fait que, malgré Extended Description et les balises de langue correctes, les mails aux visiteurs sont toujours dans la langue du Guest.
pwg_mail() et toutes les autres fonctions n'utilise pas la fonction get_user_language_desc().
Je n'ai pas vu les codes des plugins, ni même replonger dans le code de Piwgo pour la création du plugins.
Mais, à mon avis quand le mail est envoyé l'utilisateur actif de la page, c'est encore le guest puisqu'on est entrain de créer le nouveau.
Essaie de forcer $user['language'] avec la bonne langue avant l'envoi du mail.
Ou bien il faut envoyer le mail sur la 1er page où ton nouvelle utilisateur se connecte.
A mon avis, c'est un truc comme ca.
Hors ligne
rub a écrit:
Essaie de forcer $user['language'] avec la bonne langue avant l'envoi du mail.
function UserAdvManager_Adduser($register_user) { ... { ... switch_lang_to($register_user['language']); SendMail2User(1, $register_user['id'], $register_user['username'], $passwd, $register_user['email'], true); switch_lang_back() } }
Essaie de voir si ca fonctionne avec ca...
Si c'est ca, tu as potentiellement le même problème avec les themes et les templates.
Hors ligne
J'ai essayé ce que tu proposes sans meilleur résultat. Mais j'ai poussé le raisonnement un peu plus loin :
Dans ma fonction SendMail2User(), j'ai mis en place une requête Sql pour remonter la langue de l'utilisateur juste avant l'appel à pwg_mail(). Et, au lieu d'envoyer un mail, j'écris le tout dans un fichier log qui comporte la date d'émission du mail, le destinataire, le contenu envoyé et la langue de l'utilisateur selon la requête Sql.
Ce qui donne :
Mon, 30 Nov 2009 20:27:09
test@2.com
[Test web site] Add of test4
Welcome on Test Website,
Here are your connection settings for the gallery and the forum.
test4, please find here your information to login the gallery :
User : test4
Password: test
Email: test@2.com
You have to confirm your registration to be able to browse the gallery without restrictions. Please note that validation key is available for 5 days only. Use this link to confirm your registration:
Please, click on this link to confirm your registration : http://localhost/test/phpwebgallery/./plugins/NBC_UserAdvManager/ConfirmMail.php?key=Gd152JURJBE67G4s
http://localhost/test/phpwebgallery/
Langue de l'utilisateur à l'envoi du mail : fr_FR
Il y a manifestement une incohérence mais l'envoi de mail proprement dit est hors de cause puisque j'ai commenté l'appel à pwg_mail() pour le remplacer par l'écriture du fichier log.
Aux vues du log, la langue de l'utilisateur est bien en base de données, mais ce serait get_user_language_desc() qui ne retrouverait pas la bonne traduction.
Je continue à creuser dans cette voie. J'ai l'impression de ne pas être loin du but ;-)
Hors ligne
Ok, je pense que cette fois je l'ai...
Au début de ma fonction SendMail2User(), j'ai ajouté :
$query =' SELECT user_id, language FROM '.USER_INFOS_TABLE.' WHERE user_id = '.$id.' ;'; $data = mysql_fetch_assoc(pwg_query($query)); $language = $data['language']; switch_lang_to($data['language']);
switch_lang_back() ferme la fonction.
Dans ce cas, j'utilise bien la langue... par défaut du navigateur de l'utilisateur ! Dans un sens, c'est tout à fait logique puisque qu'on a la fonction get_browser_language() de Piwigo qui joue son rôle.
Mais Language Switch dans ce cas ? Il n'intervient que dans l'affichage à l'instant T de la galerie en fonction des choix fait par le visiteur. En aucune façon il n'intervient dans la langue de l'utilisateur inscrit réellement dans la table #_user_infos. Ce n'est pas parce qu'un visiteur choisi un affichage de la galerie dans une langue différente de celle configurée par défaut dans son navigateur qu'il s'inscrira effectivement avec cette langue.
C'est là qu'était mon erreur d'interprétation. Donc je pense que tout est ok pour mon plugin maintenant.
Merci Rub pour le coup de pouce avec switch_lang_to() ;-)
Hors ligne
Eric a écrit:
Merci Rub pour le coup de pouce avec switch_lang_to() ;-)
De rien ;-)
Dommage que $register_user n'est pas la langue de l'utilisateur ca aurait plus simple.
Je pense qu'en faisant l'évolution sur les notifications admin, je vais rajouter dans pwg_mail la langue en paramètre (comme pour les thèmes et template). Ca fera exactement comme tu as fait, le switch_lang_to() et le switch_lang_back(). Mais ca serait peut-être plus simple pour les nouveaux developpeurs.
Hors ligne
Bonjour.
Je me permet de relancer cette discution, car j'aime bien tout comprendre.
Résumé (d'un autre topic où ce pb devenait hors sujet. ):
Lien : http://fr.piwigo.org/forum/viewtopic.ph … 91#p133591
Eric a écrit:
A priori, le pb viendrai de mon plugin NBC_UAM dans la génération des emails personnalisés en fonction de la langue du destinataire. J'utilise les fonctions de Extended Description pour faire cela mais çà m'oblige à changer la langue de la galerie à la volée en fonction de la langue de chaque mail.
C'est le retour à la langue "normale" de la galerie (langue de l'admin) qui ne se fait pas correctement
rub a écrit:
cljosse a écrit:
Eric a écrit:
Il ne me reste plus qu'à essayer de trouver une solution pour la gestion multi-langue dans NBC_UAM ;-)
Lors de la vérification de mon plugin, en cherchant pourquoi il ne marchait pas avec les users d'une autre langue que celle de l'administrateur, je me suis appercu que dans ton plugin qu'avant de faire le switch_to_lang, tu ne sauvais pas la langue de l'"user", pour pouvoir la restituer en fin de routine :
Exemple de modification à faire:
/* And switch gallery to this language before using personalized and multilangual contents */
global $user;
$save_user = $user;
switch_lang_to($data['language']);
load_language('plugin.lang', NBC_UserAdvManager_PATH);
.................................
/* Switching back to default language */
$user=$save_user ;
switch_lang_back();
load_language('plugin.lang', NBC_UserAdvManager_PATH);
Si cela peut t'être utile...Normalement, ce n'est pas nécessaire car c'est la fonction "switch_lang_to()" qui sauvegarder les données "langue" de ton user.
Et la fonction switch_lang_back() la restitue.
Par contre, en lisant la suite, ce qui peut arriver c'est que la langue du plugin ne soit pas (re)chargée.
=> la fonction utilise "trigger_action('loading_lang');" qui peut sans doute être utilisée pour charger les fichiers langues du plugins.
Mes questions:
a) pourquoi si je ne sauve pas l'user ça ne marche pas si cela n'est pas nécessaire?.
b) Dans quel cas langue du plugin est (re)chargée sans refaire un load après un switch ?
A+
Hors ligne
cljosse a écrit:
Mes questions:
a) pourquoi si je ne sauve pas l'user ça ne marche pas si cela n'est pas nécessaire?.
moi aussi, je voudrais bien savoir ;-)
c'est peut-être à cause des "if ($last_language != $language)". essaie de supprimer le test dans les 2 fonctions. dans ce cas, on aurait une erreur si on switch des langues identiques!
cljosse a écrit:
b) Dans quel cas langue du plugin est (re)chargée sans refaire un load après un switch ?
les fonctions reprennent l'état avant switch (et aussi lors du load de la fonction).
tout ce qui est fait après la fonction est perdu.
Hors ligne
Suite a mon analyse des routines:
Si j'ai bien compris:
Le principe de la gestion du switch des langues est un LIFO (last in, first out).
Pourquoi dans la fonction switch_lang_to se compliquer la vie?.
//========================================
if (count($switch_lang['stack']) == 0)
{
$prev_language = $user['language'];
}
else
{
$prev_language = end($switch_lang['stack']);
}
//========================================
Si on écrit :
//----------------------------------------------------------------
function switch_lang_to($language)
{
global $switch_lang, $user, $lang, $lang_info;
//on récupère le language en cours.
$prev_language = $user['language'];
if ($prev_language != $language)
//on empile le language prévu si langue différente.
$switch_lang['stack'][] = $prev_language;
.......
//-------------------------------------------------------------
cela m'a l'air plus simple, mais peut être je n'ai pas tout vu.
De même pour dépiler dans switch_lang_back:
//=========================================
$last_language = array_pop($switch_lang['stack']);
if (count($switch_lang['stack']) > 0){
$language = end($switch_lang['stack']);
} else {
$language = $user['language'];
}
if ($last_language != $language)
{
if (!isset($switch_lang['language'][$language])) // ??? on devrait plutot regarder last_language?
//==========================================
//----------------------------------------------------
function switch_lang_back()
{
global $switch_lang, $user, $lang, $lang_info;
//on dépile le $switch_lang[Stack] et on récupère le dernier language introduit.
if (count($switch_lang['stack']) > 0){
$last_language= array_pop($switch_lang['stack']);
}else{
$last_language= $user['language'];
}
//on récupère le language en cours pour la comparaison.
$language = $user['language'];
if ($last_language != $language)
{
if (!isset($switch_lang['language'][$last_language]))
{
$lang_info = $switch_lang[$last_language]['lang_info'];
$lang = $switch_lang[$last_language]['lang'];
}
$user['language'] = $last_language ;
}
}
//---------------------------------------------------------------------
Peut être des effets de bord non prévu,
A+
Dernière modification par cljosse (2010-02-18 15:13:24)
Hors ligne
C'est une LIFO...
En fait, je voulais faire la comparaison avec le dernier élément ajouté et pas avec le user.
Dans, ton exemple, tu fais la comparaison uniquement avec le user...
Mais, dans tous les cas, je pense que ce n'est pas la bonne solution... il y a des effets de bords liés aux changements qu'on peut faire sur le user.
Je pense qu'on ne devrait plus faire le test.
Ce qui donne:
/* * Switch language to param language * All entries are push on language stack * * @param string language */ function switch_lang_to($language) { global $switch_lang, $user, $lang, $lang_info; $switch_lang['stack'][] = $language; if (!isset($switch_lang['language'][$language])) { // Re-Init language arrays $lang_info = array(); $lang = array(); // language files load_language('common.lang', '', array('language'=>$language) ); // No test admin because script is checked admin (user selected no) // Translations are in admin file too load_language('admin.lang', '', array('language'=>$language) ); trigger_action('loading_lang'); load_language('local.lang', '', array('language'=>$language, 'no_fallback'=>true)); $switch_lang[$language]['lang_info'] = $lang_info; $switch_lang[$language]['lang'] = $lang; } else { $lang_info = $switch_lang[$language]['lang_info']; $lang = $switch_lang[$language]['lang']; } $user['language'] = $language; } /* * Switch back language pushed with switch_lang_to function * * @param: none */ function switch_lang_back() { global $switch_lang, $user, $lang, $lang_info; $language = end($switch_lang['stack']); if (!isset($switch_lang['language'][$language])) { $lang_info = $switch_lang[$language]['lang_info']; $lang = $switch_lang[$language]['lang']; } $user['language'] = $language; }
On supprime toute la partie qui censé optimiser le fait de passer plusieurs fois consécutivement la même langue dans les fonctions switch.
J'ai vraiment supprimé tout ce qui est pouvait poser problème et donc je recharges la langue en cours mais si les tests sont concluants, ca sera un axe à améliorer.
Je n'ai pas testé... donc j'attends les retours de cljosse et Eric.
Dernière modification par rub (2010-02-18 15:37:19)
Hors ligne
Quelques modifications pour ne pas recharger la langue courante.
Si ca vous convient et si c'est ok bien sur, je commite.
/* * Switch language to param language * All entries are push on language stack * * @param string language */ function switch_lang_to($language) { global $switch_lang, $user, $lang, $lang_info; // Treatment with current ingo // Language of current user is saved (it's considered OK) //if (count($switch_lang['stack']) == 0) if (!isset($switch_lang['language'][$user['language']])) { { $switch_lang[$user['language']]['lang_info'] = $lang_info; $switch_lang[$user['language']]['lang'] = $lang; } // Change current infos $switch_lang['stack'][] = $language; $user['language'] = $language; // Load new data if necessary if (!isset($switch_lang['language'][$language])) { // Re-Init language arrays $lang_info = array(); $lang = array(); // language files load_language('common.lang', '', array('language'=>$language) ); // No test admin because script is checked admin (user selected no) // Translations are in admin file too load_language('admin.lang', '', array('language'=>$language) ); trigger_action('loading_lang'); load_language('local.lang', '', array('language'=>$language, 'no_fallback'=>true)); $switch_lang[$language]['lang_info'] = $lang_info; $switch_lang[$language]['lang'] = $lang; } else { $lang_info = $switch_lang[$language]['lang_info']; $lang = $switch_lang[$language]['lang']; } } /* * Switch back language pushed with switch_lang_to function * * @param: none */ function switch_lang_back() { global $switch_lang, $user, $lang, $lang_info; // Get last value $language = end($switch_lang['stack']); // Change current infos if (!isset($switch_lang['language'][$language])) { $lang_info = $switch_lang[$language]['lang_info']; $lang = $switch_lang[$language]['lang']; } $user['language'] = $language; }
Je n'ai pas testé!
Hors ligne
rub a écrit:
En fait, je voulais faire la comparaison avec le dernier élément ajouté et pas avec le user.
Dans, ton exemple, tu fais la comparaison uniquement avec le user...
Mais, dans tous les cas, je pense que ce n'est pas la bonne solution... il y a des effets de bords liés aux changements qu'on peut faire sur le user.
Je voulais éviter de modifier le user à chaque fois et pas l'empilement.
Dans ce que tu proposes en n'empilant pas, on risque d'avoir des effets de bord dans le dépilage.
Hors ligne