La préposition « en » est ambigu

Je sais très bien comment fonctionne GENDER, je l’ai utilisé uniquement comme bidouille pour faire croire au logiciel que j’utilise la variable alors qu’en fait non.

Comme je l’ai écrit dans mon message, j’ai déjà essayé d’utiliser les commentaires HTML pour cela, mais cela ne fonctionne pas (ils s’affichent tels quels).

J'ai constaté un problème avec le "hack" GENDER qui arrivait parfois à afficher quelque chose quand le nom de langue dans $1 correspond aussi à un nom d'utilisateur.

Suite à ton revert (désolé si j'ai oublié cette vieille discussion d'il y a 3 ans car j'avais retraduit suite à une modif récente dans la source, sans me souvernir que "$1" donne en fait le nom de langue en anglais), j'ai utilisé un autre "hack" basé sur PLURAL, mais en lui passant une valeur explicitement donnée (2), de sorte que la pseudo-forme ($1) supposée passée pour le singulier ne soit jamais retournée, et en laissant alors la vide la 2e forme pour le pluriel.

Il reste quand même que ce genre de discussion passée aurait dû faire l'objet d'une remontée d'anomalie vers Phabricator pour signaler que $1 n'a pas la valeur escomptée et est inutilisable dans une bonne traduction, et d'un FIXME ajouté dans la page "/qqq" pointant vers cette discussion ici et vers la fiche d'anomalie sur Phabricator, afin d'en faire le suivi! Cela ne concerne en effet pas que le français mais toutes les traductions de ces 3 messages.

Pour référence, cela concerne ces 3 messages:

• Tux-sst-outdated ("Outdated translations from $1")
• Tux-sst-translated ("Translations from $1")
• Tux-sst-untranslated ("No translation from $1")

En attendant, la vieille anomalie T111175 ne semble pas avoir été solutionnée car sans doute pas comprise dans son effet sur ces messages.

Comment alors indiquer la langue originale. OK c'est souvent l'anglais... mais pas toujours: la page source à traduire avec l'extension peut avoir un code de langue différent; il y a des exemples par exemple sur MetaWiki et Commons (avec une langue source variable qui peut être le français, le chinois, le russe, l'espagnol, l'italien...), et sur les wikis utilisant une autre langue par défaut mais qui proposent aussi des traductions. Les pages de Wikimedia France (par exemple les comptes rendus d'activité, les réunions, rapports, présentations, organisation d'événements) sont traduites depuis le français vers d'autres langues. La lanue source est définie dans les métadonnées de cetet page et n'est pas forcément non plus la langue par défaut du wiki (on a le cas sur MetaWiki et Commons où la langue par défaut est l'anglais, sur Wikipédia francophone on a des pages sources en anglais pour certaines pages communautaires, on pourrait avoir aussi des pages sources dans des langues régionales, par exemple des sous-pages spécialisées de certains groupes qui doivent ensuite traduire leurs textes sources vers le français et où le français traduit n'est pas la référence; on pourrait avec des exemples encore avec des documents de nature juridique comme des traités internationaux, des jugements de cours internationale ou de régulateurs extranationaux dans des diférents où la France, la Belgique ou le Canada seraient une partie, ou bien encore avec des documents africains ou du Moyen-Orient où la langue source est l'arabe...).

---

Et plutôt que d'utiliser un tel "hack" **dans** le message traduit, ce serait bien que Translate UI puisse permettre de "marquer" (dans une métadonnée attachée au message) qu'une variable est volontairement omise. (C'est possible sur ce wiki qui dispose de "Semantic Metawiki", mais pas directement sur MetaWiki ou Commons pour la traduction de leurs pages).

• Idéalement donc "TranslateUI" devrait proposer d'intégrer un "tag" spécial dans la traduction, hors du champ utilisé pour la traduction elle-même.
• De même "TranslateUI" devrait permettre d'attacher certaines métadonnées aux originaux à traduire (ainsi que la liste des variables attachées et prises en charge), pour, par exemple:
  • mentionner une liste de variables supplémentaires utilisables dans les traductions, ou encore les documenter
  • ajouter des contraintes de valeur ou de format des traduction, dont le type de "parser" utilisé, qui n'est pas nécessairement du wikitexte,
  • ajouter le format ou la syntaxe utilisé pour les pluriels,
  • des balises conditionnelles qui permettraient d'adapter un message à certains wikis cibles ou à une version déployée du logiciel traduit.
  • une balise permettant de supprimer une traduction (la rendre volontairement vide afin que son utilisation fasse alors appel aux langues de repli): cela confirmerait que dans la langue traduite, une chaine vide est: soit celle qui est attendue (et qui doit conc outrepasser toute texte de repli dans une autre langue, soit celle de la langue de repli, soit celle de la langue source originale)
  • une balise permettant de marquer qu'il y a un problème non résolu dans la langue source, et que la traduction n'est pas idéale mais fait juste de son mieux; par exemple l'omission de paramètres pour gérer des accords de genre, nombre, cas, ou encore absence de prise en compte facile des élisions.
  • On a des cas comme les ambiguïtés de traduction entre « le $1 » / « la $1 » / « l’$1 », ou entre « un $1 » / « une $1 », ou entre «  la langue $1 » / « les langues $1 » (où une seule forme est correcte mais dépend de la valeur donnée dans « $1 » mais qui ne fournit aucune métadonnée testable); ces cas entachent encore plus fortement les traductions en langues slaves et celtiques qui sont incapables de former des phrases grammaticalement et orthographiquement correctes, et doivent utiliser des formes très lourdes ou pas très lisibles (avec des pseudo-phrases nominales et des incises encadrées de ponctuations, pour éviter des mutations contextuelles).

Ces métadonnées permettraient aussi d'enrichir et améliorer le validateur utilisé par l'extension "Translate"... À réfléchir donc (histoire d'éviter aussi ce genre d'incident qui peut se reproduire à nouveau).

Globalement, cela signifie:

• qu'on ne traduirait pas juste un texte simple dans un autre texte simple, mais
• qu'on traduirait un objet en un autre objet, représentés chacun par un dictionnaire contenant des clés de sélection (dont la clé par défaut pour le texte principal et d'autres clés pour les métadonnées attachées: genre, cas, nombre, "h muet ou voyelle initiale" en français indiquant d'une élision doit avoir dans un article ou une particule placé avant).
• il devrait y avoir une balise spéciale insérable dans le texte de traduction telle que {{#switch:clé|$variable|''valeur''=''texte''|''valeur2'''|'valeur2''=''texte2''|#default=''texte3''}}
• et une autre pour fournir des métadonnées en retour: {{#set:clé|valeur}}</nowiki>.
• Le format de la clé est à définir et décrire dans la documentation "/qqq". Certaines valeurs de clé seraient réservées et utilisées en interne par le validateur (dont le "parseur" utilisé pour valider le texte, si ce n'est pas du wikitexte pour MediaWiki: l'original et sa traduction ont chacun un "modèle de données", de le même façon que les pages wiki en ont un: wikitexte, CSS, JSON, texte simple, texte préformaté, HTML, Gettext, chaine de format pour "*printf()" en C/C++, ou utilisables par des API similaires en Java, PHP, Ruby; ou encore URI, wikilien (avec indication du domaine source pour les résoudre et valider les codes interwikis et préfixes), ou encore entier décimal, horodatage en format ISO... ; indicateur d'un terme traduit invariant dont la casse doit être préservée dans un contexte amont; directionalité du texte; autre forme possible du terme traduit comme une abréviation ou un pronom que le contexte amont ou aval pourrait utiliser à la place s'il le souhaite).
• Le "langage" (ou l'API associée) utilisé pour coder cela devrait être développé conjointement avec Wikifunctions et être relativement compatible avec lui et facilement adaptable à divers contextes d'applications (pas forcément MediaWiki), y compris la syntaxe utilisée par ces balises de métadonnées et qui serait reconnu par leur 'parseur' associé.