<div dir="ltr"><div>Salut,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 9 juin 2022 à 13:35, steve <<a href="mailto:stax@ik.me">stax@ik.me</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Le 09-06-2022, à 13:20:39 +0200, Xavier Besnard (Perso) a écrit :<br>
<br>
>>Tu commites (on a pas une traduction française pour commiter ?) <br>
>>avant la relecture ?<br>
><br>
>Grand problème pour traduire "commit": valider n'est pas terrible. <br>
>Toute idée est la bienvenue.<br>
<br>
J'ai beau me creuser la tête, rien ne vient :)<br>
<br></blockquote><div><br></div><div>c'est bien "commiter" :D. C'est un terme vraiment technique et ce serait le dénaturer que d'essayer de le traduire.</div><div>Après, il faut aussi le contexte, un commit git est différent d'un commit svn :).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>Sauf avis contraire, le gestionnaire de version SVN permet ce mode de <br>
>fonctionnement.<br>
><br>
>Je charge ta version comme première version et je mets à jour le <br>
>fichier avec les résultats de relecture.<br>
><br>
>Au moins, chacune des versions est bien identifiée ainsi que les <br>
>différences.<br>
<br>
Je comprends, mais je trouve que c'est du travail supplémentaire<br>
inutile que de garder des versions de travail. Non ?<br>
<br></blockquote><div><br></div><div>Alors, en tant que dev (plutôt sous Git avec pull/merge requests), le mieux est quand même d'appliquer une relecture avant (dans le cas du code pour éviter d'avoir à un moment une erreur "volontaire") et s'assurer qu'on commite quelque chose de validé.</div><div>Et ça évite aussi d'avoir une traduction avec potentiellement plein d'erreurs sur un gros fichier qu'on corrige au fur et à mesure, avec le risque qu'une version apparaisse entre et que la traduction ne soit pas "suffisamment" bonne.</div><div>Etant donné que ce ne sont que des typos en général et pas un gros travail de fond, on peut considérer que cela reste le travail de la personne qui a fourni le fichier.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>Je suppose qu'il doit y avoir un moyen simple de faire une différence <br>
>entre 2 versions avec SVN, voire de revenir en arrière en cas de gros <br>
>soucis...<br>
<br>
Je connais très mal svn mais j'imagine que ça doit pouvoir se faire,<br>
c'est quand même la base d'un système de gestion de versions. <br>
<br></blockquote><div><br></div><div>D'expérience, c'est pas agréable donc si on peut éviter des commits je dis pas non. Surtout avec les scripts de reformattage qui passe la nuit, c'est compliqué de trouver parfois : le fichier est formatté par le script, la personne modifie et commite -> on perd le formattage et tout le fichier est reformatté (quand on enregistre avec Lokalize par exemple). Le premier diff entre les 2 versions est illisible. Ensuite, le script retourne pour reformatter le fichier modifié par la personne et donc on se retrouve une nouvelle fois avec le fichier complètement modifié.</div><div>On peut faire un diff entre les 2 versions formattées, mais il faut les chercher et c'est pas agréable :).</div><div><br></div><div>Johnny</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>>>J'ai une préférence pour traduire "spacer" en  élément séparateur <br>
>>>(choix pour plasmashell) voire espaceur.<br>
>><br>
>>Espaceur fait très cosmique mais a l'avantage sur « élément séparateur »<br>
>>de n'avoir qu'un mot. Choix cornélien :)<br>
>J'ai pris « élément séparateur »<br>
<br>
ok<br>
<br>
>Relecture faite et peu de chose à signaler. Une coquille d’orthographe <br>
>et quelques légères retouches, sinon tout bon, y compris avec pology. <br>
>Bravo et merci.<br>
<br>
Avec plaisir :)<br>
</blockquote></div></div>