Meilleures pratiques : séparateurs ASCII dans les e-mails ?

Soutien
1

Bonjour à la communauté Discourse —

Tout d’abord, merci d’avoir créé un outil que je trouve excellent, précieux, flexible et (pour la plupart) intuitif. Nous travaillons à modifier plusieurs modes de communication de notre projet pour les basculer vers Discourse, passant des listes de diffusion pour les discussions communautaires aux e-mails générés par script pour nous notifier d’événements clés (nouveaux problèmes, échecs de tests, etc.), et nous sommes enthousiastes à l’idée de ces changements.

L’un des obstacles que j’ai rencontrés lors de la configuration est la suppression automatique du contenu qui suit des lignes comme ----- dans les e-mails envoyés à Discourse. Si j’ai bien compris, cela est fait pour éviter que les messages publiés par e-mail ne transportent toute la chaîne de réponses avec eux, et j’ai généralement été impressionné par la manière dont les réponses par e-mail sont rendues proprement dans Discourse, donc je ne critique absolument pas ce choix dans cette question.

Nous avons traditionnellement utilisé de tels séparateurs fréquemment dans les e-mails de notification générés par script (que nous redirigeons maintenant vers Discourse) pour les rendre faciles à lire, que ce soit avec des technologies anciennes ou modernes. Je suis en train de les supprimer et de les remplacer par des techniques comme « essayons simplement d’utiliser davantage d’espaces verticaux », mais avant de m’engager trop loin dans cet effort, je voulais vérifier s’il existe une autre meilleure pratique recommandée pour créer de tels séparateurs dans les e-mails envoyés à Discourse, ou une façon de les échapper / les faire passer à travers le filtre actuel que je n’aurais pas trouvée (ma meilleure tentative jusqu’à présent a été d’utiliser une ligne de tirets n au lieu de tirets/hyphens/minus ASCII, mais je ne suis pas très enthousiaste à l’idée d’utiliser des caractères non ASCII, pour la simplicité).

Plusieurs d’entre nous ont aussi tendance à utiliser par habitude de petits séparateurs --- dans les e-mails pour délimiter un bloc de code ou quelque chose de similaire, donc je m’inquiète que, même une fois tous nos messages générés par script convertis, cela pose problème aux utilisateurs qui comptent sur l’option « répondre » pour répondre aux sujets Discourse redirigés vers leurs boîtes de réception (mais peut-être que c’est juste une courbe d’apprentissage que nous devrons surmonter ?).

Merci pour tous conseils ou astuces ici,
-Brad

2

Ah… quelque chose que je viens de découvrir moi-même et qui pourrait aider d’autres personnes qui tombent sur ce fil : l’ajout de symboles ASCII non séparateurs ou de ponctuation dans une ligne qui agit autrement comme séparateur permet de contourner le filtrage de Discourse. Ainsi, transformer une ligne comme :

Titre
--------------------------------

en :

--- Titre ---------------------

est une façon de conserver une forme de ligne séparatrice sans que Discourse ne la supprime. Bien sûr, cela n’aide toujours pas les utilisateurs habitués à s’appuyer sur de petites lignes séparatrices ---- pour mettre quelque chose en évidence dans un e-mail, donc je reste curieux de savoir si d’autres ont des recommandations ou des bonnes pratiques à ce sujet.

3

Au risque de continuer à me parler à moi-même, voici un exemple concret qui nous est arrivé aujourd’hui :

L’un des cas où nous utilisons des scripts pour notifier les personnes d’événements consiste à envoyer un courriel aux développeurs lorsque de nouvelles PR sont fusionnées dans notre dépôt GitHub. Nous avons maintenant modifié ces scripts pour qu’ils envoient les messages à une catégorie spécifique de notre site Discourse. Cependant, comme GitHub utilise Markdown pour décrire les PR, nous avons souvent des en-têtes de section comme celui-ci dans nos descriptions de PR :

Détails de cette PR
------------------

qui sont rendus comme des en-têtes de section sur GitHub. Mais lorsque le message est envoyé à Discourse, cette ligne de tirets provoque la suppression du reste du message.

Nous pourrions évidemment former tous nos développeurs à utiliser d’autres styles d’en-têtes qui ne seraient pas supprimés (comme ## Détails de cette PR), mais s’il existait un moyen de modifier notre script pour traiter le message de fusion et protéger ou échapper de tels motifs afin qu’ils soient conservés jusqu’à Discourse, cela nous semblerait plus attractif.