MediaWiki talk:Babel-4-n/fr

@Verdy p: Pouvez-vous m'expliquer pourquoi GENDER ne marcherait pas ici ? J'ai fait le test sur User:NickK/BabelTest, et pour tout le babel français (sauf fr-4 que vous venez de modifier) le masculin marche parfaitement. J'ai pris la page d'une femme fr-4 au hasard (j'ai tombé sur User:Elvire), et le féminin marche bien pour tout le babel (par exemple, elle est usuaria en espagnol) sauf le même fr-4. À mon avis le problème n'existe pas et le FUZZY s'affiche pour d'autres raisons

Je suis en phase avec NickK.

De plus, « Cet⸱te utilisat⸱eur⸱rice » est parfaitement illisible et ne correspond en rien aux conventions d’écriture sur Wikipédia.

J’ai aussi fait le test avec « Cet utilisateur » et je n’ai pas de signalisation problématique.

Le FUZZY est pourtant bien là: rafraîchit la page si ça ne s'affiche pas immédiatement: ce que tu saisis est bien enregistré, puis quelques secondes après elle est modifié par un bot interne qui ajoute le préfixe !!FUZZY!! et la traduction réapparaît alors comme "à traduire" (y compris dans les listes de messages à relire: si on enlève cette marque "fuzzy", cela n'a pas d'effet du tout, c'est aussitôt changé. Il faudrait que la source en anglais contienne la variable utilisée dans GENDER, quitte même à ne mettre qu'un texte vide dedans ou un seul texte en anglais, comme cela a été fait presque partout ailleurs. Ce n'est pas le cas ici, on ne peut pas librement ajouter des "GENDER:" sur des variables non marquées dans la source en anglais, même si la doc "/qqq" (pas à jour) mentionne la possibilité de cette variable. Ce n'est pas parce que la doc mentionne des variables possibles qu'on peut toujours les inclure librement. Si la variable est absente dans le message en anglais, rien n'indique que l'application la renseignera correctement, ce n'est pas testé du tout. Si l'appli ne passe pas de valeur correcte, on risque juste d'avoir uniquement le masculin ou le féminin (pas forcément pour le bon nom d'utilisateur). Bref impossible de savoir.

Le GENDER marche oui (pas la peine de "tester", ce n'est pas le problème sur tes tests), mais uniquement là où il a été marqué en anglais. Ce dont tu parles est pour un message particulier où ce n'est pas prévu du tout dans la source (que tu as oublié de mettre en lien, bref tu parles en règle générale).

Quand on fait ce genre de remarque sur une traduction, ne pas indiquer de quel message tu parles ne peut régler AUCUN problème. Bref il faut prendre le lien affiché en haut de chaque unité de traduction (si on passe par l'interface de traduction) ou l'URL de la page (si on édite directement une unité de traduction avec l'interface wikitexte classique)

Si tu mets juste « Cet utilisateur » tu omets le problème, tu ne le signale pas aux auteurs du logiciel qui ne pourront pas corriger.

La forme inclusive « Cet⸱te utilisat⸱eur⸱rice » peut sembler horrible mais pas plus que seulement la forme andro-gendrée « Cette utilisateur »: dans Mediawiki les messages sont genrés selon les préférences des utilisateurs et utilisatrices. À la limite si tu trouves cela trop horrible (pourtant admise maintenant par l'Académie, aussi bien pour le féminin que le pluriel, en utilisant le point médian comme séparateur et non le "/" en milieu de mot, on peut utiliser les parenthèses seulement pour les marques facultatives de féminin ou pluriel), on peut mettre « Cet utilisateur ou cette utilisatrice », mais ça marche mas pour « Cet(te) utilisateur(rice) » car le deuxième mot n'est pas un suffixe ajouté mais remplacé.

À la limite, on pourrait utiliser « Cet(te) utilisat(eur/rice) » cette fois avec un "/" dans les parenthèses pour indiquer ce remplacement du suffixe par un autre, mais les parenthèses suggèrent que l'un et l'autre des deux suffixes sont facultatifs alors qu'il en faut un, et « Cet(te) utilisat[eur/rice] » réglerait le problème.

Au final on attend plutôt de pouvoir utiliser GENDER, mais on ne peut pas l'anticiper avant la correction de la source en anglais.

Il me semble que NickK a bien taggé le message concerné (MediaWiki:Babel-4-n), donc c’est bien un message spécifique, non un cas général. Et ce message indique bien spécifiquement, dans ses variables:

• $4: Username.

Après, il y a peut-être un décalage avec la réalité, mais dans ce cas, c’est à remonter comme bogue.

Dans ce cas, comme ailleurs quand il n’y a pas de variable, par contre, la règle simple du français (courant, je parle, non académique, qui n’est pas vraiment ce qui est utilisable dans les traductions de ce site), c’est qu’en cas de genre indéterminé, on utilise le masculin. Donc mettre « Cet utilisateur » est dans ce dernier cas, à mon sens, la meilleure solution, que tout le monde comprend (au lieu de vouloir à toute force faire rentrer les deux écritures, qui n’apportent rien de plus).

Non justement, c'est un copier-coller de doc sur plusieurs messages, que les variables soient présentes ou pas dans les messages individuels à traduire. Le $4 justement n'est pas dans le message source, c'est pour ça qu'on ne peut pas le mettre (même si la doc "qqq" semble l'affirmer, cette doc n'a aucun rôle dans la validation qui est à la cause du flag "!!FUZZY!!" aussitôt ajouté par le bot validateur, une fois qu'on enregistre.

En apparence ça semble bon (la modif n'a pas immédiatement la "bannière jaune" pour le signaler, car ce statut n'est pas ajouté immédiatement; mais un simple rafraîchissement de la page quelques secondes après le refait apparaître comme fuzzy et à traduire: le validateur ne veut pas de cette variable $4 absente du message source, et le message réapparait pour tout le monde dans la liste des messages à retraduire et revalider, et ne peut pas être exporté tel quel vers les wikis avec les filtres utilisés qui n'exportent QUE les traductions effectivement validées, donc aucune en état "fuzzy").

C'est ça que tu n'as pas compris.

---

Ou alors c'est encore un problème de cache de la base de données et on ne voit pas le message anglais réel mais le mauvais message vendant de Memcached (un problème disséminé un peu partout au hasard depuis un mois, et qui venait des requêtes multipages comme celles de l'outil de traduction qui charge en une seule fois une centaine de messages "à traduire" ou "à relire", et pour chacun les messages sources et documentaires "qqq" correspondants, soit 300 pages en une seule requête: il y a toujours un bogue quand un de ces messages change d'état, l'outil de traduction n'est pas synchronisé correctement quand il y a plusieurs transactions de mise à jour et sélection successives, et réécrit de façon incorrecte dans le cache Memcached les 300 messages sans vérifier leur changement de statut dans une des deux bases SQL et Memcached (ce bogue de cohérence des transactions a été identifié et corrigé dans l'outil de traduction, sachant que s'il vient de mettre quelquechose dans Memcached, il ne revalide pas depuis la base de données, et le robot de vérification lui stocke directement ses modifs dans la base de données SQL principale sans toujours invalider ou remettre à jour l'entrée dans Memcached ou s'il le fait il le fait en différé sur des images pas synchrones; la base Memcached doit encore être purgée des pages pas synchronisées, par un script administrateur qui n'est pas passé partout, et Wikimedia ne veut pas simplement purger tout Memcached pour forcer à nouveau son remplissage à partir de la base SQL, craignant que les bases SQL n'encaissent pas le choc et que cela provoque un gros ralentissement des sites pendant une durée assez longue et trop de "timeout", Wikimedia cherche à minimiser l'impact mais n'a trouvé aucun moyen de relever exhaustivement les cas où Memcached n'est pas à jour; le pire c'est que ce qui est lu souvent de Memcached y retourne assez vite et est gardé longtemps voire infiniment si la ressource est relue plus souvent avant l'expiration du délai de conservation: chaque nouvelle lecture repousse la purge automatique sans forcer une resynchronisation, c'est un modèle trop "optimiste" de gestion des caches qui a un sérieux bogue, pas toujours corrigé dans une partie critique de l'API MediaWiki, et qui n'est pas prête de l'être).

J'ai fait plusieurs tests, et cela ne marche pas. $4 fonctionne pour d'autres messages mais pas pour celui-là. J'ai donc soumis ce problème sur Phabricator: phab:T237537