Don Norman, une personne bien connue et respectée pour avoir pionniéré le domaine de l’UX dans les années 1990 et au-delà, nous rappelle souvent que le choix des mots est important et que nous devons nous concentrer sur notre objectif d’aider de vraies personnes – pensantes et sensibles – et non des « utilisateurs ». Des humains. Lorsque nous les appelons clients ou utilisateurs, nous prenons de la distance avec les personnes qui utilisent nos produits en les étiquetant et en les objectifiant. - lire l’article complet ici
J’ai toujours préféré éviter le terme « utilisateurs », sauf lorsqu’il s’agit de travaux backend. J’envisage de renommer « Utilisateurs » en quelque chose d’autre, comme « Personnes ». Au départ, je pensais gérer cela dans un thème ou un composant de thème, mais j’ai ensuite pensé que créer un plugin pour charger un fichier de locale personnalisé serait le moyen le plus simple de procéder.
Également tiré du même article que ci-dessus :
Je pense qu’il est acceptable de rester sur le terme « utilisateurs ». Le mot est facile à comprendre, que vous soyez ou non un expert en UX, et il a du sens. Il est généralisable et largement utilisé.
Donc, avant même d’écrire la moindre ligne de code, je souhaiterais solliciter votre avis d’expert : devrais-je poursuivre cet effort ? Cela entraînerait-il des conflits avec le fonctionnement de Discourse ?
À mon avis, en tant que développeur depuis toujours (bien que je ne sois pas un expert de Discourse), la décision de poursuivre cet effort dépend du rapport entre l’impact et l’effort, tel que vous le percevez. L’impact peut être subdivisé en deux catégories : interne (pour votre propre bénéfice) et externe (pour le bénéfice des autres). Bien que nous ayons parfois (ou souvent) besoin de faire certaines choses pour notre propre bien, lorsqu’il s’agit de développer des communautés, je pense que le bénéfice des autres prime sur le nôtre. Après tout, la communauté que vous créez est une expression de vous-même, et en tant qu’architecte, vous devez décider de l’impact que vous souhaitez avoir sur votre _____. Que sont-ils pour vous ? Comment voulez-vous qu’ils se perçoivent ?
Un peu philosophique, je le reconnais, mais j’espère que cela sera utile.
Pas besoin de faire du hacking, car Discourse se prête facilement à la personnalisation de n’importe quel texte. Il suffit de trouver les occurrences spécifiques de « user » et « users » que vous souhaitez modifier.
Bien que modifier le texte soit une option, cela ne changera que la locale actuelle. Il serait utile que les plugins, les thèmes ou les composants de thème puissent gérer des locales personnalisées, comme proposé dans le message d’origine. Existe-t-il une telle fonctionnalité ?
En français, on pourrait utiliser « usager » plutôt que « utilisateur » ou « utilisatrice », ce qui réintroduit une signification récemment disparue : « usager » désignait quelqu’un que l’on sert avec respect et attention, avant que la privatisation des transports publics ne remplace ce terme par « passager » ou même « client ». Il s’agit d’un glissement sémantique mineur, mais il a une grande importance. Dans les langues qui permettent de distinguer les utilisateurs (utilisateurs : ceux qui utilisent le programme) des personnes (usagers : ceux que le programme est censé servir), il peut être très significatif de faire cet effort d’un point de vue intersectionnel.
Obtenir une réaffirmation positive de la part d’un parfait inconnu est toujours ma chose préférée sur Internet
Ah oui. J’ai envisagé cela pour un cas d’usage précis : j’ai besoin que d’autres personnes puissent créer leurs propres communautés en utilisant mon instance Discourse personnalisée (également via Docker, peut-être) qui est déjà configurée pour la localisation. Ces configurations localisées incluraient des améliorations de l’expérience utilisateur (UX), notamment le renommage de « Users » en quelque chose comme « People », entre autres choses. J’imagine que l’utilisation de la fonctionnalité de personnalisation de texte intégrée résoudrait ce cas d’usage. Cependant, ma principale préoccupation concernant l’utilisation de cette fonctionnalité est qu’elle ne modifie pas réellement le mot lui-même, donc il ne serait pas correctement traduit dans d’autres langues, n’est-ce pas ?
Pour illustrer mon propos (les valeurs dans le tableau ci-dessous sont des traductions directes sans contexte) :
Anglais (EN)
Malais (MY)
Chinois (ZH)
User
Pengguna
用户
People
Orang
人们
Permettez-moi d’ajouter plus de contexte à mon message original :
Mon site s’adressera à un large public au sein d’une région géographique très spécifique, à savoir les personnes de Malaisie. Malheureusement pour moi, la Malaisie compte des locuteurs de 137 langues vivantes. Bien que je ne prévoie pas de prendre en charge moi-même les 137 langues, je lance l’effort avec la traduction en malais (car je parle et écris couramment l’anglais et le malais) et j’espère pouvoir faire appel à la foule pour quelques autres langues couramment utilisées ici en Malaisie. J’espère ouvrir la voie à d’autres locuteurs natifs en Malaisie pour qu’ils lancent également l’effort de traduction du site dans leurs langues maternelles respectives, ce qui contribuera à rendre le site plus accessible à davantage de Malaisiens.
Je souhaite rendre le ton de mon site aussi agréable et accueillant que possible. En dehors de la fonctionnalité de remplacement de texte administrateur, je ne peux penser qu’à créer des fichiers de locale alternatifs. Je ne veux pas remplacer les fichiers de locale par défaut de Discourse, c’est pourquoi j’ai pensé à créer un fichier de locale anglais alternatif, à partir duquel n’importe qui pourra ensuite baser ses traductions.
J’aborde ce problème du point de vue de l’UX.
Q : Comment puis-je aider à réduire les frictions pour les personnes non techniques afin qu’elles puissent configurer leur propre communauté en ligne ?
R : Faire ce que Discourse fait déjà : préconfigurer le logiciel dès la sortie de la boîte
Q : Comment puis-je aider à réduire les frictions pour les personnes non techniques afin qu’elles ajoutent un langage personnalisé à leur site ?
R : Euh… télécharger un fichier YML via un plugin ?
Je n’ai pas encore verrouillé celui-ci . Comme mon site est destiné à servir tout mon pays, j’ai initialement pensé utiliser le terme « Malaisiens » plutôt que « Utilisateurs ». Cependant, je ne pense pas devoir restreindre l’inscription aux non-citoyens, alors j’ai créé un groupe « Malaisiens » à la place et je me suis arrêté sur « Personnes » pour l’instant, jusqu’à ce que je trouve un terme plus approprié et plus convivial.
Ce dilemme me semble être un moteur derrière les niveaux de confiance (TL) (Basic, Member, Regular, Leader, Ancien) de Discourse. Les « rôles » que vos ____ peuvent avoir dépendent de la nature de la communauté.
Une hiérarchie exemple pour une communauté liée au commerce pourrait s’inspirer de l’histoire et comporter Apprenti, Compagnon et Maître artisan. Pour nos amis germanophones ici, ces titres seraient traditionnellement Lehrling, Geselle et Meister.
Malaisie. Malheureusement pour moi, 
Je souhaite rendre le ton de mon site aussi agréable et accueillant que possible. En dehors de la fonctionnalité de remplacement de texte administrateur, je ne peux penser qu’à 
. Comme mon site est destiné à servir tout mon pays, j’ai initialement pensé utiliser le terme « Malaisiens » plutôt que « Utilisateurs ». Cependant, je ne pense pas devoir restreindre l’inscription aux non-citoyens, alors j’ai créé un groupe « Malaisiens » à la place et je me suis arrêté sur « Personnes » pour l’instant, jusqu’à ce que je trouve un terme plus approprié et plus convivial.