<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 08. 06. 12 01:18, Kévin Raymond a
écrit :<br>
</div>
<blockquote
cite="mid:CAPwc7DPqq7489_085Aw8zqWJrt9DqiHBPFjfE858S2dRwo8d+A@mail.gmail.com"
type="cite">
<pre wrap="">2012/6/6 Gérard <a class="moz-txt-link-rfc2396E" href="mailto:geodebay@gmail.com"><geodebay@gmail.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Le 04/06/2012 00:33, Dralyab a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">.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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
Pas de problèmes,
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">
Il m'a l'air assez complet déjà.
une fois publié il sera dans la catégorie draft, comme :
<a class="moz-txt-link-freetext" href="http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html-single/RPM_Guide/index.html">http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html-single/RPM_Guide/index.html</a>
</pre>
<blockquote type="cite">
<pre wrap="">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+
</pre>
</blockquote>
<pre wrap="">
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,
</pre>
</blockquote>
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.<br>
<br>
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:<br>
<br>
<pre wrap="">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.
</pre>
<span class="marron"> "espèce de, façon de, genre de, manière de,
sorte de, type de"</span>, 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 :<br>
<span class="exe">Exemples tirés de
<a class="moz-txt-link-freetext" href="http://www.aidenet.eu/grammaire04g.htm">http://www.aidenet.eu/grammaire04g.htm</a><br>
- Une espèce de <b>gamins</b> qui ne nous <u>incitent</u> pas à
les fréquenter.<br>
- Voici le genre <b>d'informations</b> qui ne <u>sont</u> pas à
diffuser.</span> (L'auteur attache plus d'importance aux mots que
représente le terme "informations" qu'à l'expression "le genre de").<br>
<br>
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.<br>
<br>
<pre wrap="">« 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).
</pre>
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:<br>
<br>
"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:.<br>
<br>
OK pour tout le reste, qui a été corrigé (j'espère sans oublis).<br>
<br>
Je renvoie donc la totalité du po, et, promis, nous ne discuterons
plus qu'avec les diff.<br>
Bonne lecture.<br>
</body>
</html>