Changements inutiles avec GENDER et PLURAL
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.
É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.