• [^] # Re: Traduction approximative

    Posté par (site web personnel, Mastodon) . En réponse à la dépêche GIMP 2.10.14 et 2.10.18 : sans limites. Évalué à 10.

    Je suis plutôt d'avis que c'est l'absence de choix qui fasse perdre du temps. La règle aujourd'hui dans gimp c'est d'avoir les 2 points ? Très bien établissaient le coller une règle et indiquez que pour remettre en cause ces règles il faut de solides arguments (plus qu'une apparente inutilité ou un esthétique subjective).

    Qu'est-ce qui te fait dire que ce n'est pas déjà le cas? Ce n'est peut-être pas une règle écrite (j'en sais rien, ça se trouve, elle l'est; en 25 ans, ils s'en est passé des trucs, et j'ai ai pas vécu tout à fait le tiers), mais en l'occurrence, cela est évidemment une règle implicite (comme je l'ai dit plus haut, certes pas en donnant le terme "règle"). Regarde toutes les boîtes de dialogues. Cette syntaxe est utilisée partout. Pour moi, il y a bien évidemment une règle qui est qu'on met ':' entre un label de widget et le widget lui-même quand il suit le label.

    En aparté, je viens de me rendre compte pourquoi "Color" n'a pas de ':'. Les boîtes de dialogue de filtres pour des opérations GEGL sont générés automatiquement. Donc "Presets:" fait bien partie de GIMP, mais "Color" est un string de GEGL. Et en l'occurrence, c'est tout à fait normal qu'il n'y a pas ':' là car c'est un titre générique de paramètre d'opération que nous utilisons en label de widget. Il y a néanmoins des solutions. On peut rajouter le string "%s:" comme un string traductible (car toutes les langues ne gèrent pas pareil cette ponctuation, on le sait bien, c'est le cas du français). Je regarderai de plus près quand j'y penserai.

    Quoiqu'il en soit, comme tu le vois toi-même, c'est pas parce qu'une règle est établie qu'on ne perd magiquement pas du temps (laisse moi te dire que j'en ai perdu du temps ici malgré cette règle bien présente, ce que j'ai dit dès la première phrase de mon premier message sur le sujet!). Il faut encore répondre aux gens comme ici et expliquer (ou alors on peut aussi ignorer et à ce moment, on nous reproche de ne pas écouter! On ne peut pas "gagner" de toutes façons à ce jeu 🙄😛).

    Au passage, je vais aussi répondre à ce que tu m'as dit dans ton message précédent:

    Souvent quand il y a des remarques faites sur gimp. Tu nous explique que tu t'en occupera. C'est super, mais ça me donne l'impression que tu prends les remarques comme des demandes personnelles. Ça peut très bien être quelqu'un d'autres. Je serais moins surpris qu'au lieu de généralement finir sur toi qui dit « je l'ajoute à ma todo liste » la conclusion soit « il faut l'ajouter à la todo list du projet aka il faut rapporter un bug ». Après je dis ça pour toi, hein :)

    Je ne prends rien comme des demandes personnelles, mais contrairement à ce que certains semblent penser, on écoute énormément les utilisateurs (regardez le nombre de bugs ouverts et fermés quotidiennement sur notre bugtracker, ainsi que les commentaires échangés; je reçois chaque commentaire par email — pas juste des sujets choisis, absolument tous les commentaires de tous les rapports, ça fait beaucoup d'emails quotidiens — et je les lis tous, au moins en diagonal, je peux t'assurer qu'il m'est impossible d'ignorer les remarques d'utilisabilité; et je sais que plusieurs autres contributeurs font la même chose), on travaille d'ailleurs de près avec pas mal d'entre eux, on fait énormément de finition et on est très attaché à avoir une bonne interface. On est constamment en train de fignoler des détails quand ils ont du sens, même si on ne va pas forcément en faire la pub. Si on devait changer ':' quelque part, tu ne verras effectivement cela nulle part sur un article de sortie de GIMP. On y parle de nouveaux effets, d'outils qui ont des améliorations dramatiques, ou autre truc du genre, pas de "j'ai fignolé". Ne pas en parler ne veut pas dire qu'on ne fait pas constamment de la finition. Chacune de nos sorties est bourré de ces petits détails d'amélioration qu'on ne liste jamais au milieu des grands changements.

    Donc oui, quand quelqu'un me fait une remarque qui a du sens (comme ici celles sur la redondance de titre ou le label de référence du calque modifié qui peut être amélioré), je la prends en compte. C'est pas prendre ça comme demande personnelle, juste du "ah oui tu as raison".
    D'ailleurs quand je disais que je suis en plein dans le sujet de la sélection de calque et donc que je regarderai pour ces remarques, ce n'était ni une exagération ni une extrapolation. Ça fait vraiment 2 mois que je suis en plein dans ce sujet, ceux qui suivent le financement de notre travail et les rapports de développement le savent très bien. J'étais d'ailleurs déjà passé sur le code de ces labels de référence à des calques et me souviens bien que je m'étais posé quelques questions. Je sais que je devrai y repasser, et me poserai donc encore davantage de questions pour essayer de les améliorer.

    Quant à demander à faire un rapport de bug pour ça, à part adorer la paperasse ou aimer perdre du temps, pourquoi faire? Les rapports de bug sont extrêmement utiles et même primordiaux pour plein de trucs. Mais ça ne veut pas dire qu'il faut en faire quand on peut s'en passer (en l'occurrence, je suis un des développeurs principaux, je peux m'en passer dans des cas rapides comme ici). Faire des rapports de bug pour un truc aussi mineur et évident que "retirer un titre en double" (bien que pas évident pour 2.10, je le rappelle, mais tout à fait vrai pour master où avec les Client-Side Decorations, on contrôle cette redondance), c'est juste faire perdre du temps au rapporteur, aux contributeurs qui nous aident au triage de bug, et à moi en tant que dév car j'ai déjà dit que ça pouvait être amélioré et peux le faire rapidement.
    En vrai très souvent, je dis aux gens de faire des rapports de bug, mais quand (1) je sais qu'un rapport existe déjà, alors faire un duplicata de rapport n'apporte rien et fait perdre du temps; ou (2) c'est un truc simple que je vais faire et si on fait un rapport, ça va juste faire perdre du temps à discuter de choses déjà discutées, ben non dire "ah oui je vais faire", c'est justement la version où on évite à tous de perdre du temps. 🙂

    Enfin bon, sincèrement je pense que ceux qui nous disent que GIMP est pas fignolé ne l'utilisent tout simplement pas tant que ça, ce qui n'est pas un problème en soi, on ne demande pas à ce que les gens doivent absolument utiliser. Mais clairement par exemple ici critiquer sur des ... screenshots! Et non pas sur l'utilisation... c'est un peu bizarre (désolé Guillaume). Jamais au grand jamais il ne me viendrait d'aller critiquer un logiciel, et pire de parler d'ergonomie et de massacre en règle, à partir d'une capture d'écran (par exemple celles donnée par Guillaume qui franchement ne sont pas suffisantes pour pouvoir dire quoi que ce soit de réaliste sur cet autre logiciel; je ne m'y risquerai jamais).
    Surtout quand on en vient à critiquer le rendu des fontes à partir d'artefacts de compression JPEG (et que les mêmes existent sur les screenshots censé représenter "mieux", de manière amusante).
    GIMP est un logiciel utilisé professionnellement au quotidien (par nous notamment), qui a énormément de retour d'expérience (par des gens qui utilisent vraiment, pas qui regardent des captures). On en fait sans cesse des améliorations de détail et des améliorations d'ergonomie. Rien que dans cet article, on parle d'amélioration d'ergonomie majeure du widget curseur, avec un argument cité par Guillaume qui est justement corrigé dans GIMP 2.10.18, sorti y a quelques mois (puisque cette news linuxfr a du retard par rapport à la sortie officielle). Ce qui me fait dire que lorsque ce reproche a été fait par rapport à un screenshot présent, Guillaume n'a pas encore lu la news entièrement d'une part, et n'utilise vraisemblablement pas GIMP régulièrement (pas depuis plusieurs mois?) d'autre part. Je peux me planter, mais c'est l'impression que ça me donne.
    Ensuite, Guillaume, tu as néanmoins fait quelques remarques pertinentes et utiles, donc je te remercie. Mais j'en profite pour pointer quelques petites incohérences dans l'argumentation, si tu me le permets. 😉

    Enfin dernière remarque sur:

    Il me semble que les devs de GIMP ont aussi une lourde responsabilité.

    En effet, on a une lourde responsabilité, ou plutôt on se l'est créée nous même (c.a.d c'est un choix qui est fait en décidant de contribuer à GIMP). On en est tout à fait conscient. Et c'est bien pour cela que plein de choses sont bien plus compliquées qu'elle n'en ont l'air. Il y a des choses qu'on peut changer sur un coup de tête, et énormément d'autres choses qui ont l'air mineures mais sont en fait plein d'implications et de conséquences.
    En outre, plein de choses ne sont pas si évidentes que les rapporteurs le croient (ou veulent le faire croire parfois).
    Enfin on a aussi la responsabilité de penser en grand, penser global. On a des utilisateurs de tous pays, de toutes activités, des graphistes, des designers, des scientifiques de l'image, des illustrateurs, des animateurs, des photographes, des cinéastes, etc. etc. Beaucoup de gens ne voient que leur petit bout de la lorgnette. Ensuite quand on leur explique, beaucoup se rendent compte que ce n'est pas si simple (d'autres ne veulent pas le voir). Très peu de choses sont simples (même si elles peuvent l'être techniquement) dans le développement d'un tel logiciel. Et c'est ça notre responsabilité. Pas de faire des changements sur des coups de tête parce qu'une ou 2 personnes nous le demandent sans vraiment voir les choses dans le contexte et la globalité. Si on faisait ce genre de choses, je peux assurer que GIMP n'existerait plus depuis des années et aurait juste été devenu un point d'anecdote dans l'histoire du logiciel libre. C'est ça notre responsabilité. Et c'est si on faisait plein de changements sans réfléchir juste pour faire plaisir à quelques personnes au hasard qui commentent sur capture d'écran (et qui en fait s'en fichent donc probablement et ne s'en rendraient possiblement même pas compte au final, si elles n'utilisent pas vraiment GIMP en profondeur), c'est seulement dans ce cas qu'on faillirait à notre responsabilité.

    Enfin voilà, je pense que c'est mon dernier message sur ce thread. J'y ai déjà perdu trop de temps.

    Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]