Dolibar 3.4.2
Le contenu des mails qui accompagnent l’envoi des factures / commandes / … est traduit dans la langue de l’interface de l’utilisateur au lieu d’être dans la langue du tiers auquel le document est envoyé.
Donc comme utilisateur francophone, j’envoie un email en français pour accompagner ma commande (traduite en allemand) à mon fournisseur allemand. Tandis que ma collaboratrice néerlandophone envoie un email en néerlandais pour accompagner l’offre (générée en français) qu’elle fait à notre client français …
C’est évidemment assez incohérent et illisible pour le destinataire.
A partir du moment où Dolibarr a prévu la traduction des textes d’emails, il faut que la traduction soit faite dans la langue du destinataire, c’est commerialement plus porteur. Qui plus est un utilisateur est souvent capable de rédiger correctement dans sa propre langue, mais l’intérêt des textes pré-traduits est de pouvoir gérer administrativement, rapidement et sans fautes des clients dans une langue étrangère qui n’est pas maitrisée par tout le monde dans la société.
Merci de votre aide, c’est un point assez difficile à gérer en interne pour nous, pauvres belges qui travaillons au quotidien en 4 langues (FR, NL, EN, DE).
Je ne pense pas que ce problème se résoudra aussi simplement, on peut imaginer toutes les situations possibles en terme de langue par défaut à utiliser.
N’avez vous pas la possibilité sinon d’anticiper par avance les traductions et toujours proposer des mails en 2 ou 3 langues à la fois ? Cela éviterait d’avoir à jongler comme vous faite.
Bonjour,
Il n’y a pas tellement de situations possibles. A partir du moment où doli gère la génération du document dans la langue par défaut du client, le mail qui sert à envoyer ce document doit être dans la même langue. C’est assez immédiat comme logique business.
Le seul autre cas serait si Doli gérait la langue des contacts auquel cas, ce serait par défaut la langue du contact chargé de cette tâche (commande, facture) et à défaut celle de la société. La langue d’interfcace de l’utilisateur n’a aucun intérêt, dans la communication externe, elle n’est là que pour le comfort de l’opérateur.
Je travaille depuis 25 ans en environnement multi-lingue et la seule règle valable qui existe c’est de s’adresser à son correspondant dans sa langue dans la mesure du possible, en anglais sinon.
Pour ce qui est de Doli, c’est actuellement la langue du Tiers.
Dans un monde idéal on aurait comme pour les documents une dropdown avec les langues et un bouton générer pour aller chercher les autres langues et résoudre les dernières exceptions sans construire une usine à gaz.
Je suis ouvert à d’autres options, mais une solution rapide me ferait plaisir. Envoyer des mails en 3 langues ça fait un peu amateur à mon goût.
$outputlangs = $langs;
$newlang='';
if ($conf->global->MAIN_MULTILANGS && empty($newlang)) $newlang=$this->param["langsmodels"];
if (! empty($newlang))
{
$outputlangs = new Translate("",$conf);
$outputlangs->setDefaultLang($newlang);
}
// TODO A partir du type, proposer liste de messages dans table llx_models
if ($this->param["models"]=='facture_send') { $defaultmessage=$outputlangs->transnoentities("PredefinedMailContentSendInvoice"); }
elseif ($this->param["models"]=='facture_relance') { $defaultmessage=$outputlangs->transnoentities("PredefinedMailContentSendInvoiceReminder"); }
elseif ($this->param["models"]=='propal_send') { $defaultmessage=$outputlangs->transnoentities("PredefinedMailContentSendProposal"); }
elseif ($this->param["models"]=='order_send') { $defaultmessage=$outputlangs->transnoentities("PredefinedMailContentSendOrder"); }
elseif ($this->param["models"]=='order_supplier_send') { $defaultmessage=$outputlangs->transnoentities("PredefinedMailContentSendSupplierOrder"); }
elseif ($this->param["models"]=='invoice_supplier_send') { $defaultmessage=$outputlangs->transnoentities("PredefinedMailContentSendSupplierInvoice"); }
elseif ($this->param["models"]=='shipping_send') { $defaultmessage=$outputlangs->transnoentities("PredefinedMailContentSendShipping"); }
elseif ($this->param["models"]=='fichinter_send') { $defaultmessage=$outputlangs->transnoentities("PredefinedMailContentSendFichInter"); }
elseif ($this->param["models"]=='thirdparty') { $defaultmessage=$outputlangs->transnoentities("PredefinedMailContentThirdparty"); }
elseif (! is_numeric($this->withbody)) { $defaultmessage=$this->withbody; }
Et dans /comm/propal.php par exemple pour les propal
ligne 2311
// Create form object
include_once DOL_DOCUMENT_ROOT.'/core/class/html.formmail.class.php';
$formmail = new FormMail($db);
$formmail->fromtype = 'user';
ajouté $formmail->param[‹ langsmodels ›]=$object->client->default_lang; comme ceci
// Create form object
include_once DOL_DOCUMENT_ROOT.'/core/class/html.formmail.class.php';
$formmail = new FormMail($db);
$formmail->param['langsmodels']=$object->client->default_lang;
$formmail->fromtype = 'user';
Je vais faire une pull request pour demandé l’intégration de cette fonctionnalité mais ce ne sera pas avant la 3.7 car la 3.6 est déja en phase de freeze.
Je me permet de soulever une ambiguïté au principe que la sélection d’un pays ne permet pas forcément de déterminer la langue (cas proche de nos amis suisse et belges)
idéalement il faudrait utiliser ce qu’il se fait au niveau du choix de la langue pour l’utilisateur
Quand on active l’option multilangue dans Configuration->Affichage on peux choisir la langue du client (et pas encore celle du contact)
C’est bien sur ce couple Option multilaunge/langue du client que je me suis basé pour la prochaine prochaine version (version 3.7)
Pourquoi ne pas sortir une 354 qui corrige ça entre autre ? Il y a encore un paquet de bugs sur la 3.5 et vous sortez une 3.6. Elle est figée qui plus est donc c’est bien malheureux. Le jeu n’est il pas d’avoir une dernière stable qui porte bien son nom plutôt que de sortir une nouvelle release a tout prix ?
Oui je comprends,mais les régles sont définie… En l’occurrence il s’agit bien d’une nouvelle fonctionnalité et non d’une anomalie,car pour le moment cela fonctionne, mais c’est incomplet. Il est courant de sortir cette phrase de Ballmer/Gates de Microsoft, si je ne dit pas de bêtise, « it’s not a bug it’s a feature ». Souvent comme c’est le cas ici c’est un manque de fonctionnalité non implémenté qui pourrait s’apparenter a une anomalie mais qui n’empêche pas le produit de fonctionné.
Par contre il est vrai qu’au vue du nombres d’anomalies contacté et corriger depuis la sortie de la 3.5.3 une 3.5.4 serait la bienvenue.
Entre les anomalies non remontées avant qui apparaissent comme par magie sur le forum (et pas dans le bug tracker… je comprend il est chiant à utilisé)) ou par des clients qui appel pour dire, pourquoi ça ne fonctionne pas « dans ce cas là » (le cas qu’il est le seul à utilisé apparemment, puisque non remonté par d’autres), la cycle des release de Dolibarr est surrement a revoir.
J’ai appliqué la modif mais ça ne marchait pas. Comme j’étais en 3.4.2, je pensais que ça pouvais venir d elà.
Donc j’ai fait un upgrade en 3.5.4
Ca ne marche toujours pas, les mails sont émis dans la langue de l’utilisateur pas du client.
Y a-t-il un autre bout de code à modifier que tu aurais oublié de signaler?
La modification proposée par FHenry n’est pas suffisante :
- En effet elle ne permet de traduire théoriquement que le message, mais celui-ci ne s’affiche pas si on ne charge pas le fichier de langue « other ».
- Le sujet n’est pas traduit.
J’ai effectué les modifications nécessaires afin de corriger ces problèmes pour DomJ et je les ai portées sur la version de développement de Dolibarr afin que celles-ci ne soient pas perdues et qu’il puisse en bénéficier nativement à partir de la version 3.7. Merci de valider mon pull request : https://github.com/Dolibarr/dolibarr/pull/1776
