Nous avons remarqué que, sans que nous en soyons informés, de nombreux utilisateurs (environ 50) ont été mis en sourdine. Il s’avère que dans certains cas, lorsqu’un utilisateur tape trop vite, son message est envoyé à la file de révision, mais dans d’autres cas, il ne l’est pas.
Si un message n’est pas envoyé à la file de révision, nous ne sommes pas informés qu’un utilisateur a été mis en sourdine.
Le fait qu’il existe deux méthodes différentes pour gérer les utilisateurs qui tapent trop vite a conduit la plupart de nos modérateurs à croire à tort que tous les cas d’utilisateurs tapant trop vite étaient systématiquement envoyés à la file de révision. C’est une hypothèse raisonnable, car le système est confus en proposant deux façons différentes de gérer la même situation.
Les utilisateurs se sentent souvent découragés lorsqu’ils sont mis en sourdine et que leur message n’est pas publié, et ne prennent pas la peine d’essayer de contacter un modérateur.
Lorsqu’ils sont remis en état, leur message est toujours perdu, ce qui est à nouveau décourageant.
Tout le monde qui tape extrêmement vite n’est pas un bot de spam. Il peut tout aussi bien s’agir d’un utilisateur ayant utilisé Google Translate pour traduire un long texte qu’il avait écrit en anglais avant de le publier.
Veuillez envisager de modifier cela et d’envoyer tous ces messages à la file de révision.
Même constat de mon côté, et je suis d’accord, c’est déroutant.
Y a-t-il une raison particulière derrière ce « certains vont dans la file d’examen, d’autres non » ?
Alors modifiez les paramètres de votre site pour en tenir compte, si vous attendez des utilisateurs qu’ils collent beaucoup de texte (c’est vraiment étrange, d’ailleurs, et une FORTE indication d’un spammeur), alors modifiez min_first_post_typing_time dans les paramètres de votre site.
Non, ce réglage est toujours sur la valeur par défaut de 3000 ms.
Pourquoi devrais-je le changer ? Je peux parfaitement imaginer que des gens utilisent Google Translate, le collent dans le traducteur et appuient sur Entrée, par conséquent, je ne vois aucune raison de jouer avec ce réglage.
Peut-être que je n’ai pas été assez clair dans ma question.
min_first_post_typing_time aide à expliquer :
Durée minimale en millisecondes qu’un utilisateur doit taper lors du premier message, si le seuil n’est pas atteint, le message entrera automatiquement dans la file d’attente d’approbation.
Je comprends cela comme suit : Chaque fois que le seuil n’est pas atteint, le message entrera dans la file d’attente de révision, sans exception.
Ce que j’ai vu dans les “Actions du personnel” : De temps en temps, un utilisateur est réduit au silence par le système pour avoir tapé trop vite, mais il n’y a aucun signe de cet utilisateur dans la file d’attente de révision.
C’est là mon problème. J’aimerais comprendre pourquoi la majorité des utilisateurs qui tapent trop vite vont dans la file d’attente de révision, alors que certains d’entre eux n’y vont pas.
Mon attente est que, indépendamment de la valeur de min_first_post_typing_time, qu’elle soit de 1 seconde ou de 60 secondes, si un message n’atteint pas le seuil, il va dans la file d’attente de révision, sans exception. Ce que je vois en réalité est différent.
C’est juste, mais vous devez ajuster ce paramètre à une valeur inférieure pour résoudre le problème à la racine : vous avez beaucoup d’utilisateurs qui collent du contenu dans les publications comme activité normale. Par conséquent, ce paramètre doit être défini sur une valeur inférieure sur votre instance, car votre public d’utilisateurs a des caractéristiques différentes de celles du public des autres instances Discourse moyennes.
[quote=“codinghorror, post:7, topic:184578”]vous avez beaucoup d’utilisateurs qui collent du contenu dans des messages comme activité normale.
[/quote]
Je ne comprends pas pourquoi cela devrait être la cause première de mon problème, mais j’ai changé min_first_post_typing_time de 3000 à 1500 maintenant.
Je m’attends à ce que cela ne change absolument rien.
Je suis d’accord. Pour votre public de personnes qui collent tout le temps, je pense que vous devriez changer cela à quelque chose de beaucoup plus bas, comme 100 millisecondes. Je ne pense pas que passer de 3 secondes à 1,5 seconde soit suffisant.
La bonne nouvelle est que cette limite ne s’applique qu’aux nouveaux utilisateurs, donc les utilisateurs existants et établis ne seront pas affectés.
pourquoi dites-vous qu’il est bizarre que les gens collent du texte ? Un forum sur lequel je suis actif est dédié au développement d’une application téléphonique. Les commentaires sur cette application proviennent du monde entier, souvent aussi de personnes qui ne parlent pas ou n’écrivent pas l’anglais. Ils utilisent Google Translate pour essayer de donner leurs commentaires en anglais, et donc le collage se produit. Nous pensons que cela se produit chaque semaine.
cela résout le problème de leur message qui est rejeté, mais introduit le problème de l’augmentation du spam comme vous l’avez déjà souligné. Donc, ce que je demande, c’est une manière plus intelligente de gérer ces cas : envoyer ces messages à la file d’attente de révision plutôt que de les rejeter silencieusement. C’est à cela que la file d’attente de révision était destinée en premier lieu, n’est-ce pas ?
Vous appelez le collage bizarre, j’appelle le rejet silencieux des messages bizarre.
J’ai également au moins deux cas où un nouvel utilisateur, qui a été réduit au silence avec : silenced_by_staff: New user typed too fast par l’utilisateur system, et cela n’est jamais apparu dans la file d’attente de révision, et dans l’aperçu du profil de l’utilisateur, il n’y a aucun message de bannière indiquant des publications masquées ou supprimées.
C’est cité dans le sujet Bug pour que les informations soient liées ensemble. Actuellement, j’essaie de trouver une reproduction cohérente afin que nous puissions déterminer où se situe le problème. Si vous avez des détails supplémentaires qui pourraient aider, veuillez les partager sur Automatic silencing for "typing too fast" doesn't notify administrator.
Actuellement, j’essaie de trouver une reproduction cohérente afin que nous puissions déterminer où se situe le problème. Si vous avez des détails supplémentaires qui pourraient aider, veuillez les partager sur 