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

Kévin Raymond shaiton at fedoraproject.org
Thu Jun 7 23:18:14 UTC 2012


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,


-- 
Kévin Raymond
(shaiton)
GPG-Key: A5BCB3A2


More information about the trans-fr mailing list