La préposition « en » est ambigu

Verdy_p, je comprends l’idée qui est bonne mais qui introduit un autre problème : utiliser « en » est ambigu : on ne sait pas si c’est la source qui est « en anglais », ou bien si c’est la traduction qui est « en anglais ».

À lire comme ça, je suis désolé, mais moi je comprends que c’est la traduction qui est en anglais alors que c’est le contraire.

Vois-tu une autre solution ? Peut-être en mettant des guillemets : Traduction depuis la langue « anglais » ?

Franchement il n'y a que toi à voir ce genre d'ambiguïté alors que mettre "source en anglais" est très clair. Mettre :

langue "anglais",

même avec les guillemets, sera toujours incorrect car ça reste un adjectif complétant langue, et ça donne un truc horrible aussi comme:

langue "langue des signe française"

où les noms de langues dans $1 ne sont JAMAIS des adjectifs, mais toujours des substantifs ou groupes nominaux et jamais des épithètes.

Et pourquoi pas : La source en $1 a été modifiée depuis la dernière traduction.

Plutôt que d'essayer de justifier une position autant trouver une alternative compatible avec le besoin de clarification.

Malheureusement ça ne convient pas ici, il s’agit du nom d’un onglet. Mais merci pour ton message : en effet, il doit exister une manière de garder la préposition « en » tout en évitant l’ambigüité.

J’ai pensé à d’autres propositions :

1. Traductions à mettre à jour des messages en anglais
2. Traductions désuètes dont la source est en anglais
3. Traductions désuètes pour des messages en anglais

J’ai du mal à trouver plus concis. Le mieux serait sans doute de ne pas traduire le “from English” et d’avoir un simple « Traductions désuètes ».

Ou "Traduction dont l'original a changé".

Je suis d'accord : peu importe la langue de la source (sauf si c'est un critère pour l'utilisateur ou s'il y a un onglet par langue source).

Désuet : c'est.. ambigu, on peut penser que la traduction n'a plus lieu d'être (source supprimée).

Je veux pas jouer les pinailleurs, mais dans ce cas j’aime mieux « Traductions à mettre à jour » qui est plus court. Mais sinon oui, « Traductions dont l’original a changé » me convient tout à fait.

Ça me va aussi.

Désolé pour ces mille modifications, mais c’est en faisant la modification que je me suis rendu compte que ça n’allait pas : on avait un onglet « Traductions » et un onglet « Traduits » ; impossible de comprendre la différence entre les deux pour le visiteur.

En fait, je pense qu’il faut imaginer que la phrase implicite est « Rechercher dans les … ». Ce qui donne dorénavant :

• Rechercher dans les Traductions
• Rechercher dans les Originaux en anglais traduits
• Rechercher dans les Originaux en anglais pas encore traduits
• Rechercher dans les Originaux en anglais dont la traduction est à mettre à jour

Je trouve ça clair, par contre c’est de nouveau beaucoup trop long. Je pense que commencer les messages par « Originaux » est nécessaire (je ne vois pas d’alternative aussi claire) mais si vous avez une idée pour raccourcir tout ça, elle est la bienvenue !

OK sur l'essentiel de ton analyse (que je suppose exacte). Donc je propose (rechercher dans les)

• Traductions
• Originaux traduits (anglais)
• Originaux à traduire (anglais)
• Originaux à retraduire (anglais)

ÀMHA, on peut éliminer (anglais) Et pour faire plus court on peut mettre une ellipse pour les derniers si tous sont visibles en même temps :

• Orig. à traduire (anglais)
• Orig. à retraduire (anglais)

Les parenthèses ainsi placées ne sont pas plus claires pour indiquer si l'anglais (en exemple ici) est la langue de l'original ou celle de la traduction. Si "anglais" est la langue de l'original alors mettre plutôt les parenthèses à coté de "Originaux". Mais alors pourquoi les parenthèses "Originaux (anglais)" et non "Originaux en anglais" (note: on ne peut toujours pas employer "anglais" adjectif, les noms de langue étant tous des substantifs, les accords ne se font pas. Donc "Originaux anglais" serait faux si on remplace "anglais" par "allemand" à cause de l'accord nécessaire de l'adjectif. Le substantif n'est pas non plus nécessairement au singulier ni même au masculin, et on ne peut pas mettre d'article (élisions possibles), en revanche la préposition "en" marche avant tous les substantifs (nombre, genre, commençant ou non par une voyelle ou un h muet). Et on n'a pas d'autre choix aussi évident et simple en français. Sinon supposer que l'original est en anglais peut être faux (la langue par défaut n'est pas toujours l'anglais pour tous les wikis, l'extension de traduction fonctionne aussi sur des wikis dans la langue par défaut est tout autre (exemple sur Wikipédia francophone dans certains espaces de projets communautaires comme les "ambassades", ou pas mal de wikis externes non Wikimedia dont la langue de base des promoteurs n'est pas du tout l'anglais et où les traductions sont à faire de cette autre langue vers l'anglais et d'autres langues, mais la source est bien non anglophone, par exemple le wiki de Wikimedia France qui fournit seulement certaines pages traduites pour d'autres visiteurs non francophones).

Merci pour ta contribution qui montre que les parenthèses ont leur utilité. Et si ce n'est pas anglais mais English, raison de plus pour laisser tomber et simplifier en :

   Traductions
   Originaux traduits
   Originaux à traduire
   Originaux à retraduire

Ou encore :

   Traductions
   Originaux
   À traduire
   À retraduire

Plus court mais moins compréhensible. Si ce sont des onglets c'est bien.

On ne peut mettre une note pour indiquer que l'on a volontairement omis la langue ?

J'aurai peut-être dû préciser : mettre les parenthèses permet aussi et surtout de reporter l'information la moins pertinente à la fin. Ça pourrait aussi être un tiret. En mettant l'information pertinente au début on accélère le choix.

Il faut quand même rappeler qu’à cause du bogue T111175, ce n’est ni « anglais » ni quoi que ce soit, mais « English »…

J’avais essayé de supprimer l’indication de langue en la mettant en commentaire (pour pas que le logiciel se plaigne de l’absence de la variable), mais ça n’avait pas fonctionné. Je viens d’avoir l’idée d’utiliser GENDER pour cela…

Je n’aime pas trop l’idée d’utiliser une abréviation, j’ai peur qu’elle ne soit pas comprise.

En tout cas, merci Trial pour les propositions, c’est nickel.

GENDER ne fait aucun accord, il sélectionne seulement une forme selon le genre connu d'un(e) utilisateur/trice indiqué(e) dont le nom est indiqué en premier paramètre après le ":" (sinon l'utilisateur/trice actuel qui visite la page où s'affiche le message, pour peu qu'il soit au moins identifié) et qu'il/elle a configuré dans ses paramètres personnels, il ne sélectionne pas le genre grammatical d'un objet quelconque qui n'est pas reconnu comme un utilisateur. Ce qu'il retourne par défaut est un des autres paramètres après une barre verticale, il retourne le premier si l'utilisateur s'identifie comme masculin, sinon le deuxième paramètre si l'utilisatrice est féminin, sinon le 3e s'il est "neutre" (de sexe indéterminé ou indéfini, ce qui est la forme par défaut, applicable aussi au robots, même s'il y a un utilisateur pour le contrôler; et il n'y a pas d'autre sexe).

Passer un mot quelconque comme si c'était un utilisateur va lire les données de cet utilisateur, même si au final on décide de ne rien retourner. Au final autant mettre le paramètres entre commentaires HTML pour montrer qu'il est effectivement inutilisé.

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é.