Je pense qu’il serait très judicieux de prendre en charge cette fonctionnalité. Il existe en réalité cinq niveaux de prise en charge linguistique :
Traduction basée sur le navigateur (et autres traductions ad hoc) vers des localisations arbitraires
Les localisations prises en charge par Discourse (quelques dizaines)
Les localisations traduisibles automatiquement prises en charge par Discourse AI (quelques dizaines)
Les localisations activées sur le site (ici, 10)
Les localisations activées pour la traduction automatique par IA sur le site (ici, 10, souvent encore plus limitées en raison de l’abonnement et/ou des coûts)
De la même manière que Discourse souhaite s’assurer d’une bonne couverture des efforts de localisation avant d’ajouter une localisation prise en charge, les sites individuels voudront s’assurer que leurs, par exemple, directives et autres contenus importants ou saillants sont correctement traduits et pris en charge. Par exemple, nous avons utilisé site_texts pour modifier la signification de certains aspects importants de notre site. Nous devrons nous assurer d’avoir les bonnes traductions de ceux-ci avant d’activer davantage de localisations.
Mais il existe une longue traîne de langues utilisées ! J’apprécierais vivement la possibilité pour quelqu’un appartenant à cette longue traîne de langues de publier dans sa langue maternelle, même si nous n’avons pas encore validé toutes nos traductions de site_texts, de directives et d’autres contenus. Souvent, ces personnes peuvent lire l’anglais suffisamment bien pour s’en sortir (surtout avec l’aide d’une traduction ad hoc)… mais publier est une autre histoire.
Je pense qu’il aurait beaucoup de sens d’avoir un nombre bien plus important de langues prises en charge pour la rédaction de messages. Pourquoi ne pas me permettre de publier dans l’une des localisations prises en charge pour la traduction automatique ? Certes, je n’obtiendrai pas de traduction automatique de premier ordre de retour vers ma langue maternelle, mais il y a assurément un énorme avantage à me permettre de rédiger ainsi ?
Puis-je publier dans une langue non activée en utilisant le menu déroulant pour sélectionner « Non défini » (Not Set)… puis ajouter manuellement une traduction en anglais ? Ou « Non défini » implique-t-il simplement la langue par défaut du site ?
Merci ; j’ai bien cherché et j’ai même trouvé et survolé ce sujet, mais j’ai manqué cette FAQ. Ce sujet semblait être le plus proche de ce que je cherchais, mais apparemment je me suis trompé.
Ce qui m’a embrouillé, c’est que je ne peux pas sélectionner l’espéranto manuellement lors de la rédaction du message… mais l’agent de détection de la langue l’a détecté automatiquement et a marqué le message ci-dessus comme eo !
Donc… voici une demande très minimale : serait-il possible de déclarer manuellement beaucoup plus de langues directement lors de la rédaction d’un message ? Cela rendrait plus évident que l’utilisation de ces langues est autorisée ! En fait, il y a sûrement des langues que le LLM de traduction ne prend pas en charge ; comment savoir lesquelles ?
Je pense que cela dépend du LLM que vous choisissez, et non de la fonctionnalité Discourse que vous utilisez.
Un menu déroulant de locale qui proposerait n’importe quelle langue avec des milliers d’entrées ne rendrait pas le choix de la langue plus facile. Même afficher les ~50 langues que l’interface Discourse prend actuellement en charge, c’est beaucoup, et cela exclurait toujours toutes les autres langues.
Peut-être que vous pourriez masquer le menu déroulant si vous pensez qu’il est décourageant. Dans ce cas, les utilisateurs ne verront pas ces langues dans le composeur. Bien que je sente que je tends à répondre dans une langue que je vois sur le forum, je ne suis donc pas sûr que ce soit le menu déroulant qui m’empêcherait de simplement publier en allemand.
Mais je suis d’accord pour dire qu’une saisie manuelle du code de langue serait une fonctionnalité agréable. Peut-être pas pour les utilisateurs finaux, mais pour le personnel.
Je suis un utilisateur assez atypique ici, car j’évalue et j’essaie de comprendre comment les traductions se comportent sous diverses configurations d’administration… et quelles configurations auront le plus de sens pour notre communauté en particulier. Mais je pense qu’il est très peu intuitif (et plutôt présomptueux !) qu’un utilisateur poste allègrement en espagnol s’il atterrit sur un site qui n’affiche que les langues anglaise et japonaise dans les listes déroulantes (que ce soit au niveau du site ou lors de la rédaction d’une publication) !
Comme je l’ai dit, je pense que je suis beaucoup plus influencé par la langue que je vois sur le forum que par celle affichée dans un menu déroulant. Votre utilisateur japonais verrait tous les messages en japonais s’il n’ajoutait pas l’anglais parmi les langues qu’il comprend. Il lui semblerait donc naturel de répondre dans cette langue. Mais si vous voyez un forum avec uniquement des messages en anglais, vous avez tendance à poster dans cette langue aussi, tant que ce n’est pas un obstacle trop grand.
Si vous voyiez un forum allemand où presque tous les messages sont en allemand, posteriez-vous en français simplement parce qu’il y a un menu déroulant pour choisir le français comme langue de l’interface du forum ?
Vous pouvez activer le sélecteur de langue de localisation du contenu uniquement pour les utilisateurs anonymes et laisser à chacun qui s’inscrit le choix de sa langue préférée dans ses préférences, où toutes les langues prises en charge par l’interface de Discourse sont proposées.
Mais vous verriez toujours les autres utilisateurs poster dans une autre langue.
Et je pense que c’est ce qui me pousse à écrire ceci en anglais. Je veux que vous me compreniez aussi bien que possible. Donc si tout le monde écrit en anglais, j’essaie de faire de même. Les traductions entraînent toujours une perte d’information.
Un exemple issu de Meta :
Voici ce que dit le message en anglais :
Voici ce que dit la traduction en allemand :
Cependant, le script ne fonctionne plus depuis quelques mois et ne renvoie désormais que des erreurs 400.
Si je voulais savoir ce qui a changé, la nuance entre « a cessé de fonctionner le mois dernier » et « ne fonctionne plus depuis quelques mois » est assez importante.
C’est pourquoi j’essaie généralement de rester dans une langue que nous comprenons tous les deux. Le risque de malentendus est moindre, et s’il y en a, je sais au moins pourquoi. Si je ne connais pas la traduction que vous consultez, c’est beaucoup plus difficile.
Donc j’utilise la langue utilisée par les autres utilisateurs de ce forum - non pas à cause d’un menu déroulant quelque part, mais parce que je veux qu’ils me comprennent.
Mon objectif principal est de comprendre comment le site Discourse que j’administre — un site anglophone de dix ans — pourrait commencer à activer la traduction automatisée.
Nous allons tester cela en activant la traduction des publications vers l’anglais, tout en continuant de n’utiliser que l’anglais ! Avec une telle configuration, il n’y a absolument rien qui indique que cela est possible — en fait, le menu multilingue de l’éditeur de publication donne vraiment l’impression que seul l’anglais fonctionne :
C’est vrai, nous pourrions masquer ce menu de composition s’il n’y a qu’une seule langue… Je ne pense pas que nous ayons vraiment envisagé le scénario « publier en Y et nous traduirons en X, mais nous ne traduirons pas tout le reste en Y »… Je crois que nous avons toujours envisagé au moins deux langues prises en charge.
L’agent de détection de la locale détectera n’importe quelle langue et l’appliquera, indépendamment de ce que le site prend en charge dans les paramètres. La prise en charge des langues et la qualité de la détection varieront selon le LLM.
Publier en « non défini » dans une langue non prise en charge par Discourse et définir manuellement une traduction en anglais ne fonctionnera pas sans IA pour le moment. La traduction manuelle nécessite une locale prise en charge afin que le message original puisse être défini.
Autoriser les administrateurs à définir des langues supplémentaires pour utilisation dans le menu de composition pourrait être une option raisonnable à envisager pour ce cas.
