Changements inutiles avec GENDER et PLURAL

Bonjour,

Quel est l’intérêt :

1. de changer {{GENDER:$1|vous}} en {{GENDER:$1|}}vous
2. et de changer {{PLURAL:$1|Message|Messages}} en Message{{PLURAL:$1||s}}

mis à part faire perdre du temps aux relecteurs ? À la limite, quand tu es l’auteur de la traduction, tu fais comme il te chante, mais s’il te plait ne fais pas de modifications inutiles, c’est anticollaboratif !

Faire perdre quel temps ? Ces messages n'avaient jamais été relus avant et était à relire déjà et depuis longtemps. I' y a Deillers de messages jamais relus avdc toutes sortes de fautes, et la revue en masse est à faire. Autant faire court, ce qui est invariable peut être sorti pour justement montrer ce qui l'est clé un simple accord.si u. Terme est totalement invariable i' n'a pas besoin du tout d'être en paramètre, et l'appel de modèle requis peut rester sans paramètre et sera aussi invariable sur le serveur avec moins de cache et de memoire inutile

Il n’y aura pas « moins de cache ni de mémoire inutile » parce que dans un cas comme dans l’autre il n’y a QU’UNE SEULE et unique version du message finale, la raison invoquée n’est donc pas une bonne raison.

Par contre en multipliant les versions dans l’historique, cela accumule des versions intermédiaires et donc au contraire, tu augmentes le besoin en capacité de stockage du serveur.

Quant au temps perdu, j’ignore ce que font les autres traducteurs, mais moi je relis systématiquement les modifications aux messages que j’ai traduit. Donc si, tes modifications complètement inutiles me font perdre du temps, et c’est très désagréable !

AJOUT : et puis ici, comment peux-tu croire que tu fais économiser de la mémoire ?

je parle de l'analyse du message lui-même pour former la chaîne finale en faisant des substitutions conditionnelles. Les chaînes de paramètres vides n'entrainent pas d'allocation, elles sont directement supprimées du flux et traitées atomiquement. Et ici ce qui est constant dans toutes les variantes reste constant hors de l'expansion du modèle.

Le gain de mémoire entre une chaine vide et une constante est sans doute quasiment nul. En tout cas, il n’est pas significatif pour avoir un gain de performance.

Les messages en anglais n’utilisent pas cette bidouille, ça devrait suffire comme argument…

L'idéal serait même de supprimer le marqueur totalement, mais il faut une référence même vide dans l'état actuel (l'interface de translatewiki.net ne permet pas encore de marquer des éléments comme facultatifs, il insite pour qu'on mette ces marqueurs de genre liés à une variable présente dans la version anglaise (même inutiles ou pas positionnés sur le bon mot avec lequel il devraient s'accorder selon une logique anglophone qui n'a pas cette logique), et refuse sinon d'en ajouter là il il faudrait (même si c'est "documenté", mais absent de l'original anglais). L'original n'est pas forcément le bon indicateur de ce qui doit être fait dans la traduction, on doit s'écarter des suggestions fausses.

« L'original n'est pas forcément le bon indicateur de ce qui doit être fait dans la traduction »

Quand il s’agit de langue, non, en effet. Mais quand il s’agit d’une question technique, si. Mais apparemment tu ne veux pas l’entendre.

Où est la "question technique" ?

Économiser de la mémoire cache, c’est ce que je considère comme une question technique.

en l'occurence puisque le tag générère plusieurs versions, il y a déjà plusieurs versions dans le cache, le gain supposé est nul; en revanche tant qu'on devra conserver le tag (même vite) je ne vois pas comment s'en passer; la modif de simplifrcation du contenu économise aussi du traitement sur le serveur pour générer ces versions à partir du message source contenant ces tags. MediaWiki devrait être assez intelligent pour voir que le tag est vide et ne génère pas N version différentes. Et d'une façon générlae simplifer la maintenance en "factorisant" ce qui doit l'être et ne change pas en fonction du tag est bien meilleur (même si on garde un tag vide de contenu pour des raisons d'exigence technique ces tags inutiles mais encore exigés sont plus une gêne qu'autre chose et ne facilitent pas du tout la maintenance). Hors la maintenance c'est non pas du technique mais de l'humain et cette ressource est encore plus limitée (et ne croit pas de façon exponentielle ni même linéaire comme la capacité technique des serveurs).

Moins on les utilise (quand ce n'est pas nécessaire), plus on accroît la possibilité d'avoir plus de gens impliqués dans la maintenance car ils auront moins besoin de comprendre l'aspect technique (dont cette exigence de tags vides qui de toute façon en sont pas traductibles eux-mêmes). Mois je privilégie l'humain, les mainteneurs, c'est le ressource la plus précieuse et la plus difficile à faire croître ou seulement la maintenir active (pour ensuite pouvoir suivre les changements nécessaires quand ils viendront.

Et ce site est avant tout destiné aux humains, des traducteurs, à qui on ne doit pas exiger une compétence technique de plus en plus pointue. Tout ce qui leur facilite la tâche est bienvenu, le reste ce sont les outils d'exports qui régleront ça.

Rebelote. Merci pour ton travail de relecture, mais ne fais de modifications inutiles qui nous font perdre du temps stp.

C'est bien plus lisible à relire et également moins couteux et plus rapide sur le serveur avec des paramètres vides qui indiquent justement que la variable n'a aucun d'effet dans le texte qu'on peu lire tel quel (rappeler que les traducteurs ne sont pas tous techniciens du wiki: plus la partie "technique" est réduite mieux c'est et c'est également plus facile à relire et faire accepter par les correcteurs orthographiques (qui n'aiment pas trop les barres verticales collées entre deux mots pourtant non joints parmi les paramètres qui sont exclusifs les uns des autres. C'est plus léger aussi pour afficher la page des messages et le voir dans son entier sans trop sauts de lignes multiples dans l'interface: on relit plus vite ensuite. La relecture pourtant que je fais relève des fautes d'orthographie et des incohérences de traductions, voire aussi des oublis (et des tas de messages obsolètes non remis à jour): il faut bien que ça se fasse (la plupart des messages dans la masse de ceux de Mediawiki n('ont jamais été révisés, notamment les moins courants de l'interface technique ou des API, journaux, messages d'erreurs, et des interfaces pour administrateurs.

Je trouve aussi ces changements inutiles et font perdre du temps aux relecteurs qui doivent tester si ces bidouilles fonctionnent, cf. [1][2].

Wikipédia a une très bonne page à ce sujet : w:fr:Wikipédia:Ne vous préoccupez pas de performance (adapté de w:en:Wikipedia:Don't worry about performance).

Je ne me préoccupe pas des performances. mais bien de la facilité de lecture, les barres verticales juxtaposées au texte étant moins facile à lire.

Et le groupement proposé en anglais n'a pas de sens même en anglais, souvent cela ne concerne que les langues slaves qui accordent les verbes selon le genre du référent, mais de façon encore différente de nos participes (selon les temps composés, la forme active/passive, les modes et placements de nos compléments d'objets). Sio cela ne fait pas sens en français, on le sort de ce contexte inadéquat pour remettre dans la partie en plein texte, que reconnait mieux les correcteurs d'orthographiques (qui ne signalent pas "d'anomalie" quand il y a deux mots séparés uniquement par des "|" attachés: plus de soulignement ondulé en rouge par exemple, c'est bien une facilité pour la relecture, le navigateur proposant à tord d'insérer une espace voire même de remplacer cette barre verticale).

Ce n'est pas une "perte de temps" que de passer du temps justement sur des tonnes d'endroits où les fautes ont été oubliées et délaissées depuis longtemps. Certes cela fait que des corrections faites ont à relire (parfois à nouveaux car cela n'avait pas été remarqué dans une relecture précédente), mais pour les quelques cas où cela arrive, on est loin d'inonder les relecteurs (qui sont déjà très peu nombreux). se montrer désagréable sur quelque chose qui aurait pu être correct dès le départ et demande juste à être revu une fois (et plus rapidement car les modifs n'ont plus qu'à être acceptées).

Le reste et le plus gros du travail vient des changements et ajouts des sources à traduire: c'est là qu'on passe le plus de temps, mais ensuite du soucis d'homogénéiser le lexique utilisé (autant que possible) tout en évitant autant que possible les confusions (notamment sur les verbes d'action dans l'IHM).

Nobody reproach you for your huge review work, but please stop doing this kind of fully useless edit (other examples: 1, 2, 3). Thank you.

Tu as mal lu : il y a bel et bien des corrections (les féminins corrects, les accords corrects), ce n'est pas inutile comme tu le crois: au passage c'est aussi plus facile à relire si on isole les différences réelles hors des champs spéciaux. Et pourquoi écris-tu ici en anglais sur des traductions en français ? Penses-tu corriger le français sur la base de ton anglais ? Alors que ta page indique une connaissance du français supérieure à l'anglais (à moins que ce soit le contraire !)

Sinon je ne fais aucune traduction automatisée, c'est là que la revue est utile pour repérer les petits trucs gênants ou réellement initules comme passer une chaîne invariable dans un paramètre de fonction sensée faire une sélection. Ne pas passer le paramètre se résout aussitôt sur le serveur car c'est en cache, sans appel interne supplémentaire.

Je sais que la source anglaise a tendance à en mettre un peu partout autour de "you(r)" ou des verbes conjugés (à destination des traducteurs en langues slaves et pour signaler que c'est pris en charge) parce mais pas toujours où il faudrait (et il en manque souvent pour les traductions en forme passives, adjectifs et autres accords ou formes alternatives marquant le genre et le nombre). Mais ce n'est pas une raison d'imiter ça (pour qu'il n'y ait pas d'anomalie signalée je laisse une appel de fonction vide, mais le texte invariable est bien traduit comme invariable et on relit les phrases bien plus facilement ce qui permet aussi de mieux repérer les petits détails. A mon avis ces inclusions inutiles dans les source en anglais ne devraient pas être là, le message devrait plutôt être documenté pour indiquer les variables réellement utilisables pour ces variantes.

Et TWN ne devrait pas exiger une de ces fonctions "manquantes" quand on n'en a en fait pas besoin, ni invalider un ajout (pour certaines langues il faut aussi ajouter des appels à "grammar:", totalement absents en anglais). Et pour l'instant il n'y a pas de prise en charge des élisions nécessaires, et trop souvent des ambiguités en anglais entre verbes et noms. C'est dur de repérer ça, je documente (dans les pages "/qqq") quand je trouve. Et je complète les modèles "Identical/*" pour ensuite réviser le glossaire et avoir une traduction aussi homogène et cohérente que possible (pas simple parfois avec les ambiguités anglophones et les usages d'un même terme dans des sens non unifiés dans une autre langue).

Bref si d'autres passaient autant de temps que moi pour ces relectures (oubliées depuis longtemps), ça arriverait moins souvent mais le plus gros est fait et maintenant je relis les groupes de messages au complet un par un, au moment où je les trouve à changer (il y a beaucoup de groupes dans Mediawiki, Phabricator, et OSM: tous les passer en revue en une fois c'est pas terrible si on veut garder la cohérence d'ensemble et savoir où et quoi corriger s'il faut unifier).

Les pages de doc (/qqq) que je complète servent aussi aux autres langues : cela aussi se passe en revue et s'organise pour que la "mémoire de traduction" soit efficace pour tout le monde. Et je pense que cela accélère ou facilite les traductions dans des tas de langues qui sont en chantier et "se cherchent" un glossaire adéquat mais aussi adapté à leurs différences d'interprétation ou de formulation selon le contexte.

Certains ne sont peut-être pas d'accord avec mes edits, je ne suis pas à l'abri d'une erreur, mais kje fais aussi attention que possible pour faciliter la relecture après moi. Et souvent ceux qui annulent quelques modifs que j'ai faites ont raison (pour une cause que je n'avais pas vue). Mais ça arrive rarement, ou je corrige si on me signale (ici, et pas sur un autre site dans une discussion que je ne suis pas et dont on ne m'avertit même pas).