Je me demande si pour « general availability » on ne pourrait pas écrire « GA (version finale) ». Ça permet de conserver la relation avec GA tout en disant que c'est la version finale. -- trans-fr mailing list trans-fr(a)lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/trans-fr@lists.fedoraproject.org

Le 09/06/2016 à 20:24, Jean-Baptiste a écrit : > Le 09/06/2016 à 15:11, José Fournier a écrit : >> Je me demande si pour « general availability » on ne pourrait pas écrire >> « GA (version finale) ». >> >> Ça permet de conserver la relation avec GA tout en disant que c'est la >> version finale. >> >> >> >> -- >> trans-fr mailing list >> trans-fr(a)lists.fedoraproject.org >> https://lists.fedoraproject.org/admin/lists/trans-fr@lists.fedoraproject.org >> > Je pense qu'on devrait parler de version finale ou plutôt "version publique", puis préciser entre parenthèse le terme anglophone. Je ne suis pas favorable pour garder le terme anglophone à côté. Pourquoi ? Car je pense que le terme français est suffisamment clair, d'autant que je trouve pour le coup le terme anglais plutôt douteux (je n'ai pas vu d'autres projets utiliser ce terme, qui ne me semble pas si répandu). Je pense que de garder le terme anglais doit être présenté uniquement quand le terme anglais est très populaire, limite plus que la traduction. Je pense à "flux de travail (workflow)" par exemple où effectivement il y a une valeur ajoutée à garder le terme anglais Ici, je n'en suis pas convaincu. Voilà pour mon avis. ;) Charles-Antoine -- trans-fr mailing list trans-fr(a)lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/trans-fr@lists.fedoraproject.org

Le 10/06/2016 à 05:23, José Fournier a écrit :

> ** je penche plus pour « version publique » qui marque bien l'opposition > par rapport à des versions « de diffusion restreinte » que sont Rawhide, > Alpha, Beta, etc. et qui se rapproche du sens de « General Availability ».

J’opterais plutôt pour un principe plus qu'une règle,et dans une version plus courte : * privilégier le terme anglais quand il est indispensable à la bonne compréhension par le lecteur (exemple : Cloud) * si le terme a été traduit, il est possible de rappeler le terme anglais entre parenthèse quand celui-ci est un acronyme utile au lecteur (exemple : GA me semble être un terme important quand on décrit le processus et le cycle de vie de Fedora)

Le 10/06/2016 à 08:13, Jean-Baptiste a écrit : > Le 10/06/2016 à 05:23, José Fournier a écrit : >> ** je penche plus pour « version publique » qui marque bien l'opposition >> par rapport à des versions « de diffusion restreinte » que sont Rawhide, >> Alpha, Beta, etc. et qui se rapproche du sens de « General Availability ». Je ne suis pas favorable. Je trouve en réalité le terme anglais très mal choisi et du coup je ne suis pas fan du fait de s'y coller. Car si les Alpha et Beta ne bénéficient pas d'une grande publicité, elles sont publiques et disponibles théoriquement à tout le monde. Parler de la version finale comme de la version publique serait selon moi un non sens, les autres versions sont aussi publiques et ce serait gênant de prétendre que ce n'est pas le cas aux lecteurs. > J’opterais plutôt pour un principe plus qu'une règle,et dans une version plus courte : > * privilégier le terme anglais quand il est indispensable à la bonne compréhension par le lecteur (exemple : Cloud) > * si le terme a été traduit, il est possible de rappeler le terme anglais entre parenthèse quand celui-ci est un acronyme utile au lecteur (exemple : GA me semble être un terme important quand on décrit le processus et le cycle de vie de Fedora) Je suis d'accord avec ton explication. Pour le terme GA, c'est en effet un terme qu'on retrouve pour le cycle de développement de Fedora. Mais ce qui me chagrine c'est qu'il est peu clair, et surtout spécifique à Fedora uniquement. J'en ai parlé à des collègues informaticiens, ce terme ne leur parle pas non plus et peu de projets libres semblent l'utiliser. Du coup le garder ou le traduire bêtement poserait plus de problème qu'autre chose (selon moi). Charles-Antoine -- trans-fr mailing list trans-fr(a)lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/trans-fr@lists.fedoraproject.org

Le 10 juin 2016 10:15:27 CEST, "José Fournier" <jaaf64(a)zoraldia.com&gt; a écrit : > > Le 10/06/2016 à 08:13, Jean-Baptiste a écrit : >> Le 10/06/2016 à 05:23, José Fournier a écrit : >>> >>> Pour avis et pour conclusion. >>> >>> Tout bien considéré, je trouve que la règle que défend > Charles-Antoine, >>> est intéressante. Je la reformule pour être sûr qu'on se comprend > bien : >>> - Si le terme en anglais est très populaire p. ex. workflow, cloud, > etc. >>> on traduit en gardant le terme en anglais entre parenthèses à côté > ;( la >>> première fois dans une section par exemple, ou s'il n'est pas apparu >>> dans le texte depuis longtemps). >>> - Si le terme en anglais est très spécifique et pas vraiment > consacré >>> par l'usage, on traduit et c'est tout. >>> >>> Une question résiduelle qui se pose c'est que fait-on lorsqu'il > s'agit >>> d'un sigle ? Je prends quelques exemples pour dire ce que je propose > : >>> - Sigle en anglais très populaire sans équivalent en français, p. > ex. >>> MBR : dans ce cas on ne change pas le sigle mais la première fois > qu'on >>> le rencontre dans une section on peut écrire MBR (Master Boot Record > – >>> enregistrement maître de démarrage) puis dans la suite employer le > sigle >>> en anglais sans autre précaution. >>> - Sigle en anglais très spécifique, pas du tout répandu, p. ex. GA : >>> dans ce cas, on abandonne complètement l'anglais, la première fois > on >>> écrit VF (version finale) ou VP (version publique) – quand on se > sera >>> mis d'accord sur la traduction ** – et par la suite on utilise le > sigle >>> en français sans autre précaution. Il y a aussi la possibilité de > faire >>> comme dit Charles-Antoine, traduire et ne pas inventer de sigle ; il >>> suffit que nous nous mettions d'accord sur une de ces deux > possibilités, >>> ou que nous les acceptions toutes les deux. >>> >>> D'une façon générale, je pense qu'il faut traduire un maximum de > choses >>> car les lecteurs ne sont pas des spécialistes ; ils ont besoin de > donner >>> un sens aux termes utilisés et s'ils ne comprennent pas l'anglais, > ils >>> ont du mal à suivre un propos truffé de mots en anglais. Les mots > sont >>> des reposoirs pour l'esprit et c'est toujours mieux quand ils sont > dans >>> une langue que nous comprenons. C'est pourquoi – et là je sais que > tout >>> le monde n'est pas d'accord – je milite pour la traduction de mots > tels >>> que « cloud » par exemple, en employant une première fois « > informatique >>> en nuage (cloud) » puis tout simplement « informatique en nuage ». > Bien >>> sûr les appellations de produits restent à considérer comme des noms >>> propres et ne se traduisent pas « Fedora Cloud ». >>> >>> ------------------------ >>> ** je penche plus pour « version publique » qui marque bien > l'opposition >>> par rapport à des versions « de diffusion restreinte » que sont > Rawhide, >>> Alpha, Beta, etc. et qui se rapproche du sens de « General >>> Availability ». >>> >>> >>> -- >>> trans-fr mailing list >>> trans-fr(a)lists.fedoraproject.org >>> > https://lists.fedoraproject.org/admin/lists/trans-fr@lists.fedoraproject.org >>> >> J’opterais plutôt pour un principe plus qu'une règle,et dans une >> version plus courte : >> * privilégier le terme anglais quand il est indispensable à la bonne >> compréhension par le lecteur (exemple : Cloud) >> * si le terme a été traduit, il est possible de rappeler le terme >> anglais entre parenthèse quand celui-ci est un acronyme utile au >> lecteur (exemple : GA me semble être un terme important quand on >> décrit le processus et le cycle de vie de Fedora) >> >> Après, on ne peut pas tout traduire. Pour mail on a courriel, qui est >> largement compréhensible, pour le reste il faut s'appuyer sur les >> pratiques des autres communautés. >> Si quelqu'un lit le document, le français doit permettre de l'aider à >> comprendre, trop de traduction et de parenthèses mènerait à de >> l'incompréhension. Les notes de version sont destinées à un public >> plutôt large, mais cela reste un public plus technique que la > moyenne. >> Pour le MBR, si je ne vois pas l'intérêt de le traduire n'ayant pas >> cherché où il apparaissait, je préfère largement le terme utilisé par >> Wikipédia : >> https://fr.wikipedia.org/wiki/Master_boot_record > Ok pour principe plutôt que règle, c'est moins coercitif. > Je ne raisonnais pas uniquement sur les notes de version mais d'une > façon générale, d'où peut-être une certaine incompréhension entre nous > (p. ex. à propos de MBR) et pourquoi j'ai tendance à considérer que le > public n'est pas forcément très « technique ». > Je continue à penser que pour un tel public, ne pas traduire est une > erreur et dire « j'adopte ce que font les autres communautés » est un > comportement moutonnier qui ne fait pas évoluer les choses. > Je ne trouve pas la formulation du principe suffisante et > satisfaisante. > J'ai peur qu'en faisant court on ne règle pas le problème. Ce qui me > paraît indispensable à la compréhension c'est une bonne traduction. Le > rappel du terme anglais n'est nécessaire que pour les spécialistes qui > ont l'habitude de l'employer pour montrer que c'est ce terme là qu'on a > traduit. > C'est ma façon de voir les choses. > > Par ailleurs, « zone d'amorce » me convient. Ce n'est pas sur la > traduction elle-même mais plus sur la manière de présenter un sigle qui > pourrait paraître ésotérique (MBR n'est pas le meilleur exemple mais > aucun autre ne me vient à l'esprit tout de suite) à un public non > spécialiste que je voulais insister. De plus ça me fait penser à la > traduction de « Boot » : amorçage ou démarrage ? > Notre différence d'approche vient certainement de notre différence de > parcours dans l'informatique. > > > -- > trans-fr mailing list > trans-fr(a)lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/trans-fr@lists.fedoraproject.org on est face à un cas qui ne peut pas être résolu, d'où mon souhait d'établir un principe général visant à rappeler que le but de la traduction est de rendre le texte compréhensible dans la langue cible. On peut aller plus ou moins loin dans la façon de faire, y mettre plus ou moins d'énergie et je ne me sens pas à l'aise sur la définition de quelque chose de précis car je doute que nous puissions le respecter dans le temps. Traiter au cas par cas quand cela nous choque me semble plus simple. Quand on traduit, je pense qu'on doit rester proche du niveau de complexité que le texte original. Sinon on fait un document à part adapté à la cible qu'on vise, comme ce qu'a fait Renault dans son rôle de promotion. Est ce que cela te semble acceptable José ?