[Fedora-trans-fr] [DDR]Fedora RPM Guide → rpm-guide-advanced-packaging

[Gérard]

Le 08. 06. 12 01:18, Kévin Raymond a écrit :
> 2012/6/6 Gérard <geodebay at gmail.com>:
>> Le 04/06/2012 00:33, Dralyab a écrit :
>>
>>> .J'ai verrouillé sur Transifex. J'attends une éventuelle protestation 72
>>> heures, puis je débute la traduction à l'issue de ce délai si personne ne
>>> conteste.
>>
>> Voici une proposition de traduction pour les 100 premières phrases.
>> Dans l'attente de vos remarques...
>>
>> J'attaquerai les 100 suivantes prochainement ; mais n'en déduisez pas que je
>> penserais que 100 ait une vertu particulière.
>>
>> Je m'absente quelques jours. Ne vous étonnez pas d'une non-réponse
>> (éventuelle) à vos remarques.
> Pas de problèmes,
>
>> Je me suis rendu compte, après coup et en tant que petit nouveau, que je
>> m'étais lancé dans la traduction d'un "draft". Ce ne doit pas être du
>> dernier astucieux!! et il doit exister des urgences plus prégnantes. Il ne
>> reste plus qu'à souhaiter qu'il n'y aura pas trop de modifs. A ce propos, je
> Il m'a l'air assez complet déjà.
> une fois publié il sera dans la catégorie draft, comme :
> http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html-single/RPM_Guide/index.html
>
>
>> n'ai pas réussi à faire le planning avec taskjuggler: il bloque
>> "unexpectedly". Je soupçonne gnome et Qt, car ce logiciel est bâti pour KDE.
>> A+
> Hum, Je n'ai pas testé depuis un moment, j'essayerai de regarder plus tard.
> Je l'avais lancé sous GNOME sans aucun problème à l'époque.
>
>
> Voici quelques remarques, n'hésites pas à réagir, ce n'est pas
> forcément tout juste.
>
>
> "Le chapitre précédent a présenté le fichier RPM des spécifications qui"
> …le fichier des spec, des spécifications RPM, qui contrôle… En
> ajoutant « spec » on garde le nom du type de fichier, et son
> extension.
>
>
> # Je propose "fonctionnalité" pour la traduction de "capability" en
> référence aux fonctions contenues dans les paquets. Votre avis?
> #. Tag: para
> #, no-c-format
> msgid ""
> "*Requirements, where one package requires a capability provided by another"
> msgstr ""
> "* prérequises, quand un paquet nécessite des fonctionnalités fournies pas un"
> "autre paquet"
> Je suis d'accord sur fonctionnalités.
> Sinon, prérequis au masculin me vient plus naturellement, on parle des
> prérequis logiciels. Mais oui, s'il s'agit des fonctionnalités ta
> proposition est correct. Mais en fait le sujet c'est « type », d'après
> la phrase précédente. Idem pour les 3 types suivants.
>
>
> # Requires:, Provides:, Obsoletes:, Conflicts: sont des mots-clés du
> fichier de spécifications. Je ne les ai donc pas traduits dans ce
> contexte. J'ai par contre traduit "capability" qui est un placeholder
> pour les fonctionnalités désignées par l'entremise du nom du paquet.
> Votre avis?
> #. Tag: para
> #, no-c-format
> msgid "Requires: capability"
> msgstr "Requires: (fonctionnalité)"
> Oui très bien. Par contre pourquoi l'ajout des parenthèses, pour
> préciser que c'est optionnel ? Sachant que les parenthèses sont
> utilisées pour les modules d'extension, je suis d'avis de les
> supprimer ici.
>
> # Je propose, dans le cas particulier des "fonctionnalités"
> virtuelles, de traduire "capability" par "capacité" au lieu de
> "fonctionnalités" - terme que j'ai retenu pour la traduction de ce
> même mot lorqu'il évoque des "fonctions" bien réelles programmées dans
> un  d'autres paquets.
> #. Tag: title
> #, no-c-format
> msgid "Creating Virtual CAPABILITIES"
> msgstr "Création de CAPACITÉS virtuelles"
> POSSIBILITÉS peut-être ?
> Mais puisqu'on a virtuel d'associé, peut-être pouvons nous garder «
> fonctionnalités ».
> La phrase suivante me dérange un peu en l'état.
>
> "fonctionnalité. D'autres paquets la nécessitent, comme l'agent de"
> "récupération et de transfert Fechmail ou mutt, client pour courrier"
> "électronique."
>
>   transfert Fechmail, ou mutt, client pour courrier
> l'ajout de la virgule permet de savoir que le client est mutt, sinon
> j'allais ajouter un pluriel à client.
>
>
> "fonctionnalité et - plus important - des applications clientes peuvent la"
> Là il faut utiliser un tiret cadratin « — ».
>
> "Bien entendu, il est souhaitable que vous vous assuriez que ces paquets"
> "spécifient bien qu'ils sont en conflit entre eux."
> « qu'ils entrent en conflit » n'est pas plus léger ? (Simple proposition).
>
> msgstr "PreReq: (fonctionnalité)"
> parenthèse en trop ? (Cf plus haut, plusieurs occurrences.)
>
>
> # Je pense qu'il y a un bogue rédactionnel dans cette phrase. De mon
> point de vue, elle devrait être libellée: "RPM guarantees that the
> PreReq: package will be installed prior to the package named in the
> Requires:: dependency."
> #. Tag: para
> #, no-c-format
> msgid ""
> "In most usage, a PreReq: acts just like Requires:, in fact, the PreReq:"
> "directive exists just to allow for a manual order to dependencies. RPM"
> "guarantees that the PreReq: package will be installed prior to the package"
> "that names the PreReq: dependency."
> msgstr ""
> "Dans la plupart des cas, PreReq: agit de la même manière que Requires:. En"
> "fait, la directive PreReq: n'existe que pour permettre un classement manuel"
> "des dépendances. RPM garantit que le paquet PreReq: sera installé"
> "prioritairement au paquet désigné par la dépendance PreReq:."
> En fait, pour moi la chaîne originale est juste :
> « prior to the package that names the PreReq: dependency. » : avant le
> paquet qui désigne (nomme, précise) la dépendance PreReq:. (du verbe «
> to name », désigner, donner un nom. Je ne l'ai jamais entendu comme
> ça, peut-être que ce verbe n’existe pas, en tout cas ça ne me paraît
> pas faut et on a compris la même chose, donc ok pour ta version).
>
>
> "Si votre paquet dépend d'une faàon ou d'une autre d'un autre paquet, un"
> façon
>
>
> "d'avoir un agent de trasport de courrier ou MTA(Mail Transfert Agent). Linux"
> il manque l'espace avant la parenthèse ouvrante
>
>
> msgid "script commands..."
> msgstr "... commandes du script ..."
> Pourquoi les points de suspensions au début ?
> Pas d'espace avant les points de suspension.
>
>
>
> Ah, je crois que je suis arrivé au bout.
> N'hésite pas à faire un diff, ça permet d'être certain d'avoir tout
> relu (personnellement je ne traduis pas forcément chaîne par chaîne).
>
> À bientôt,
>
Voici ma proposition de traduction. Elle porte sur la totalité du 
fichier. Je vous demande de m'en excuser, mais je me suis embrouillé les 
pédales avec les diffs car j'ai oublié de figer le premier jet de ma 
traduction ; j'ai essayé de récupérer, mais alors j'ai perdu (?) les 
insécables, les phrases longues avaient été repliées, etc. Promis la 
prochaine fois je fais un git pour garder les traces.

Elle tient compte des suggestions de Kévin, en partie du moins. Je 
m'explique à propos des deux que je n'ai pas cru devoir retenir:

Sinon, prérequis au masculin me vient plus naturellement, on parle des
prérequis logiciels. Mais oui, s'il s'agit des fonctionnalités ta
proposition est correct. Mais en fait le sujet c'est « type », d'après
la phrase précédente. Idem pour les 3 types suivants.

"espèce de, façon de, genre de, manière de, sorte de, type de", suivis 
d'un nom et  employés avec un complément qui définit l'idée principale 
que l'émetteur souhaite exprimer, s'accordent avec ce complément :
Exemples tirés de http://www.aidenet.eu/grammaire04g.htm
- Une espèce de *gamins* qui ne nous _incitent_ pas à les fréquenter.
- Voici le genre *d'informations* qui ne _sont_ pas à diffuser. 
(L'auteur attache plus d'importance aux mots que représente le terme 
"informations" qu'à l'expression "le genre de").

Dans le cas présent, le sujet principal de l'article est "les 
fonctionnalités d'un paquet", c'est pour cela que je propose de 
conserver le féminin de fonctionnalité au lieu du masculin de type. 
Mais, si tu penses que c'est plus coulant et lisible au masculin, va 
pour le masculin.

« prior to the package that names the PreReq: dependency. » : avant le
paquet qui désigne (nomme, précise) la dépendance PreReq:. (du verbe «
to name », désigner, donner un nom. Je ne l'ai jamais entendu comme
ça, peut-être que ce verbe n’existe pas, en tout cas ça ne me paraît
pas faut et on a compris la même chose, donc ok pour ta version).

Mon problème n'est pas avec la traduction de "to name", mais avec le 
sens global de la phrase. J'ai traduit mot à mot (presque), mais elle me 
paraîtrait plus conforme au bon sens en étant rédigée comme suit:

"Dans la plupart des cas, PreReq: agit de la même manière que Requires:. 
En fait, la directive PreReq: n'existe que pour permettre un classement 
manuel des dépendances. RPM garantit que le paquet PreReq: sera installé 
prioritairement au paquet désigné par la dépendance Requires:.

OK pour tout le reste, qui a été corrigé (j'espère sans oublis).

Je renvoie donc la totalité du po, et, promis, nous ne discuterons plus 
qu'avec les diff.
Bonne lecture.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/trans-fr/attachments/20120613/e916a81d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fedora-rpm-guide_rpm-guide-advanced-packaging.po
Type: text/x-gettext-translation
Size: 85738 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/trans-fr/attachments/20120613/e916a81d/attachment.bin>