GENDER
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