Description de l’image : Capture d’écran montrant que le paramètre « Balises de catégorie » d’une catégorie exige 1 balise du groupe de balises « Gestion de projet ».
Pourtant, j’ai pu créer un sujet avec succès sans aucune balise. Ce problème est-il reproductible ailleurs ?
Description de l’image : Capture d’écran d’un sujet intitulé « Est-ce que la balise obligatoire fonctionne ? test » qui a été publié avec succès sans aucune balise.
Vous êtes administrateur sur le site, vous pouvez donc faire ce que vous voulez. Testez avec un compte non-membre du personnel pour voir à quoi cela ressemble.
@neil Désolé que cela ait pris autant de temps pour répondre, mais j’ai tiré parti de votre travail ici dans un nouveau plugin que je suis en train de développer pour mettre en œuvre l’ensemble de fonctionnalités que j’ai décrit ci-dessus. Il utilise une version modifiée de la structure que vous avez ajoutée, qui impose que tous les sujets comportent une balise de langue si un paramètre du site est activé. Alors, merci beaucoup !
Plus d'informations sur le 'plugin multilingue' (en développement) si quelqu'un est intéressé.
J’espère que l’interface utilisateur est relativement intuitive, mais voici quelques remarques sur la nomenclature et le comportement actuel :
Le type « Base » signifie que la langue fait partie de la « liste de base » des langues. Actuellement, cette liste correspond à la liste complète des langues présentes dans le code de Discourse, à savoir cette liste : discourse/config/locales/names.yml at main · discourse/discourse · GitHub. Le plugin est conçu de telle sorte que la liste de base puisse être modifiée ultérieurement si nécessaire (bien que cela nécessite quelques modifications mineures du code).
Vous remarquerez que plusieurs langues de la liste « Base » sont indiquées comme n’ayant « aucune traduction ». Cela reflète le fait que la liste des paramètres régionaux pris en charge dans Discourse est un sous-ensemble de la liste des langues contenue dans names.yml. Sans doute, l’objectif est d’ajouter davantage de paramètres régionaux pris en charge au fil du temps, mais cela dépend de la traduction de Discourse vers différents paramètres régionaux (gérée dans Transifex).
Vous pouvez ajouter de nouvelles langues en téléchargeant un fichier .yml au format :
iso_code: nom natif
iso_code: nom natif
...
Vous pouvez inclure autant de langues que vous le souhaitez dans le fichier. Vous téléchargez le fichier en cliquant sur « Télécharger des langues » et en sélectionnant le fichier .yml. La liste se rafraîchira automatiquement avec la nouvelle langue ajoutée. Les langues ajoutées de cette manière s’afficheront avec le type « Personnalisé ».
Vous pouvez trier la liste par n’importe quel en-tête (sauf « Actions ») en cliquant sur l’en-tête concerné. Vous pouvez également filtrer la liste à l’aide de la zone de filtre située en haut à gauche (un petit problème avec cette fonctionnalité est qu’elle se rafraîchit à chaque caractère saisi ; je corrigerai cela plus tard).
Les cases à cocher dans les colonnes « Contenu » et « Paramètre régional » indiquent si la langue doit être utilisée comme filtre de contenu et/ou comme paramètre régional. La fonctionnalité de gestion des paramètres régionaux n’est pas encore terminée, les cases à cocher de cette colonne ne fonctionneront donc pas correctement (et les langues personnalisées sans traduction de paramètre régional afficheront une case à cocher au lieu de « aucune traduction »).
Les cases à cocher dans la colonne « Contenu » modifieront la disponibilité des langues de contenu pour les utilisateurs, c’est-à-dire que si cette case à cocher est désactivée :
Il n’y aura aucune balise de langue de contenu pour cette langue dans le sélecteur de langue de contenu de l’éditeur.
Un utilisateur ne pourra pas sélectionner la langue de contenu dans son profil.
Notez également que les sélecteurs de langue de contenu et de paramètre régional de l’utilisateur sont regroupés en haut de ses paramètres d’interface.
Notez également que l’initialisation du sélecteur de langue dans l’éditeur (c’est-à-dire l’ajout par défaut de la langue de contenu de l’utilisateur) devrait maintenant fonctionner.
Notez également que le paramètre du site multilingual require language tag détermine si une balise de langue est requise. Il possède trois valeurs possibles : no (non requis pour personne), yes (requis pour tout le monde), non-staff (requis pour les non-membres du personnel).
Bonjour, j’ai jeté un œil : comment obtenir ce type de structure ?
Je comprends que « autres langues » soit une catégorie et que les différentes langues en soient les sous-catégories ?
C’est bien cela ?
Et les contributeurs publient-ils ici selon leur propre langue ?
Ainsi, peuvent-ils poster tous les sujets sans thème défini ?
Merci,
Ne pensez-vous pas qu’il serait formidable d’afficher tout le contenu et l’interface aux utilisateurs dans leur langue maternelle ?
AirBnB le fait depuis des années : chacun écrit dans sa propre langue et voit les réponses dans la langue dans laquelle il écrit.
Cela pourrait être facilement réalisé techniquement avec l’API Google Translate, que, pour être honnête, je trouve vraiment impressionnante par sa qualité.
Je pense que les suggestions ainsi que le « plugin multilingue », si j’ai bien compris sa fonction, ne font que renforcer la ségrégation au lieu de supprimer les barrières linguistiques.
Bien sûr, mais d’après ce que je peux dire, cela ne traduit les publications qu’après avoir cliqué dessus - ou est-ce que cela fonctionne aussi automatiquement et je n’ai pas encore trouvé comment ?
