Bonjour,
Une nouvelle version vient de sortir. J'ai fait une première mise à jour, il reste quelques chaînes : intro: 1826t 8f 2u (David Prévot) memory: 840t 8f 5u (David Prévot) sched: 451t 4f 2u (Cédric Boutillier) socket: 872t 18f 2u (Cédric Boutillier) stdio: 1592t 8f 1u (David Prévot) unistd: 2630t 12f 7u (personne) La personne entre parenthèses est le dernier traducteur, qui peut aussi décider de passer son tour ;-) Je vise une sortie de perkamon-fr pour le week-end prochain.
Pour rappel, les sources se trouvent sur http://gitorious.org/perkamon/man-pages-fr et les bonnes volontés sont toujours les bienvenues pour aider à traduire.
Denis
Afficher les réponses par date
Le 28 février 2012 00:53, D. Barbier a écrit :
Bonjour,
Une nouvelle version vient de sortir. J'ai fait une première mise à jour, il reste quelques chaînes : intro: 1826t 8f 2u (David Prévot) memory: 840t 8f 5u (David Prévot) sched: 451t 4f 2u (Cédric Boutillier) socket: 872t 18f 2u (Cédric Boutillier) stdio: 1592t 8f 1u (David Prévot) unistd: 2630t 12f 7u (personne) La personne entre parenthèses est le dernier traducteur, qui peut aussi décider de passer son tour ;-) Je vise une sortie de perkamon-fr pour le week-end prochain.
Pour rappel, les sources se trouvent sur http://gitorious.org/perkamon/man-pages-fr et les bonnes volontés sont toujours les bienvenues pour aider à traduire.
Merci d'avoir été aussi rapide. Je vais m'occuper d'unistd, puisqu'apparemment cela ne vous tente pas ;-)
Denis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Le 28/02/2012 15:24, D. Barbier a écrit :
Je vais m'occuper d'unistd, puisqu'apparemment cela ne vous tente pas ;-)
Merci (on n'attendait que « personne » réagisse ;-). Au passage, j'ai remarqué plusieurs détails comme la traduction parfois bancale de « flag », des « crypter » qui traînent, des « ceci » qui mériteraient d'être des « cela », etc. (quand on commence à regarder ce genre de choses, il y en a plein qui surgissent…). Je veux bien commencer à faire un tour d'homogénéisation frénétique quand perkamon sera synchronisé avec man-pages 3.36 (Denis, si tu préfères publier la traduction dès qu'elle est finie, ne m'attends pas, ça servira toujours pour la prochaine version ou une révision mineure) .
Je n'ai pas vérifié la tendance, mais que dites de vous de « paramètre » pour traduire « flag » dans les cas courants ?
Amicalement
David
Le 28 février 2012 20:40, David Prévot a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Le 28/02/2012 15:24, D. Barbier a écrit :
Je vais m'occuper d'unistd, puisqu'apparemment cela ne vous tente pas ;-)
Merci (on n'attendait que « personne » réagisse ;-). Au passage, j'ai remarqué plusieurs détails comme la traduction parfois bancale de « flag », des « crypter » qui traînent, des « ceci » qui mériteraient d'être des « cela », etc. (quand on commence à regarder ce genre de choses, il y en a plein qui surgissent…). Je veux bien commencer à faire un tour d'homogénéisation frénétique quand perkamon sera synchronisé avec man-pages 3.36 (Denis, si tu préfères publier la traduction dès qu'elle est finie, ne m'attends pas, ça servira toujours pour la prochaine version ou une révision mineure) .
Je vais sortir perkamon-fr 3.36 d'abord, mais tu peux te créer une branche si tu veux commencer de suite, j'incorporerai tes changements après.
Je n'ai pas vérifié la tendance, mais que dites de vous de « paramètre » pour traduire « flag » dans les cas courants ?
J'aime pas trop, pour moi il y a dans flag la notion de valeur choisie parmi un nombre limité de valeurs possibles, qu'on ne retrouve pas dans paramètres.
Denis
Bonsoir,
On Tue, Feb 28, 2012 at 09:43:40PM +0100, D. Barbier wrote:
Le 28 février 2012 20:40, David Prévot a écrit :
Je n'ai pas vérifié la tendance, mais que dites de vous de « paramètre » pour traduire « flag » dans les cas courants ?
J'aime pas trop, pour moi il y a dans flag la notion de valeur choisie parmi un nombre limité de valeurs possibles, qu'on ne retrouve pas dans paramètres.
Parmi les pages dont j'ai traduit des morceaux, j'ai trouvé « attribut » comme traduction de « flag », que je trouve raisonnable.
Cédric
Le 28 février 2012 23:23, Cédric Boutillier a écrit :
Bonsoir,
On Tue, Feb 28, 2012 at 09:43:40PM +0100, D. Barbier wrote:
Le 28 février 2012 20:40, David Prévot a écrit :
Je n'ai pas vérifié la tendance, mais que dites de vous de « paramètre » pour traduire « flag » dans les cas courants ?
J'aime pas trop, pour moi il y a dans flag la notion de valeur choisie parmi un nombre limité de valeurs possibles, qu'on ne retrouve pas dans paramètres.
Parmi les pages dont j'ai traduit des morceaux, j'ai trouvé « attribut » comme traduction de « flag », que je trouve raisonnable.
Je ne suis pas certain qu'il faille uniformiser partout. J'ai déjà lu « drapeau » ou « indicateur », en particulier lorsqu'ils sont accolés à un déterminant. Par exemple, « carry flag » est souvent traduit par « indicateur de retenue ». Pour des termes plus génériques, attribut me semble pas mal.
Denis
Le 28 février 2012 21:43, D. Barbier a écrit :
Le 28 février 2012 20:40, David Prévot a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Le 28/02/2012 15:24, D. Barbier a écrit :
Je vais m'occuper d'unistd, puisqu'apparemment cela ne vous tente pas ;-)
Merci (on n'attendait que « personne » réagisse ;-). Au passage, j'ai remarqué plusieurs détails comme la traduction parfois bancale de « flag », des « crypter » qui traînent, des « ceci » qui mériteraient d'être des « cela », etc. (quand on commence à regarder ce genre de choses, il y en a plein qui surgissent…). Je veux bien commencer à faire un tour d'homogénéisation frénétique quand perkamon sera synchronisé avec man-pages 3.36 (Denis, si tu préfères publier la traduction dès qu'elle est finie, ne m'attends pas, ça servira toujours pour la prochaine version ou une révision mineure) .
Je vais sortir perkamon-fr 3.36 d'abord, mais tu peux te créer une branche si tu veux commencer de suite, j'incorporerai tes changements après.
Bonsoir,
Voici le diff d'unistd.
Denis
Le 02/03/2012 16:57, D. Barbier a écrit :
Voici le diff d'unistd.
Pas de vraie remarque, juste une coquille et un peu de pinaillage.
@@ -8570,9 +8563,10 @@ msgstr ""
[…]
+"gestionnaires de bifurcation (Ndt : fork) établis avec B<pthread_atfork>(3)."
Pourquoi pas simplement « bifurcation (« fork ») » (et sinon, plutôt NDT que Ndt, NdT à la rigueur, voire N.d.T. comme dans l'article de Jacqueline Henry [0]) ?
0 : http://id.erudit.org/iderudit/003059ar
@@ -21782,22 +21768,21 @@ msgid "" "differs only in the treatment of the virtual address space, as described " "above." msgstr "" +"Comme avec B<fork>(2), le processus fils créé par B<vfork>() hérite des "
^^ Pas sûr que ce soit important de corriger les doubles espaces ici, ils doivent être mangés de toute façon à l'affichage.
"The requirements put on B<vfork>() by the standards are weaker than those " "put on B<fork>(2), so an implementation where the two are synonymous is " @@ -21864,23 +21841,15 @@ msgid ""
[…]
+"Les exigences que les standards apportent sur B<vfork>() sont plus relâchées " +"que celles sur B<fork>(2), ainsi il est possible d'avoir une implémentation "
[…]
Peut-être plutôt « norme » que « standards » ici, voire tourner la phrase dans l'autre sens, genre « La norme est mois exigeante envers B<vfork>() que B<fork>(2), ce qui permet d'avoir […] ».
Puisqu'il s'agit d'une ancienne chaîne, c'est peut être le genre de truc à gérer lors d'une relecture plus globale avec pour objectif de corriger les « standards » utilisés à la place de « norme », je n'ai donc pas intégré cette proposition dans le correctif joint.
@@ -21891,11 +21860,15 @@ msgid ""
[…]
+"architecturale, et la page de manuel de BSD\ 4.2 indique que «\ cet appel "
^ Une espace insécable s'est introduite entre « de » et « BSD ».
@@ -21917,6 +21892,13 @@ msgid "" "functionality equivalent to B<fork>(2)+B<exec>(3), is designed to be " "implementable on systems that lack an MMU.)" msgstr "" +"B<vfork>(2) peut être implémenté sur des sytèmes sans unité de gestion "
^^ ^^ Le double espace et le « s » manquant sur cette ligne.
+"mémoire (MMU, pour «\ memory-management unit\ »), mais B<fork>(2) ne peut " +"pas être implémenté sur de tels systèmes (POSIX.1-2008 a supprimé B<vfork>() " +"du standard\ ; la raison invoquée par POSIX pour la fonction B<posix_spawn>"
s/du standard/de la norme/ pour éviter d'introduire de nouvelles occurrences.
Amicalement
David
Le 4 mars 2012 06:28, David Prévot a écrit : [...]
@@ -21782,22 +21768,21 @@ msgid "" "differs only in the treatment of the virtual address space, as described " "above." msgstr "" +"Comme avec B<fork>(2), le processus fils créé par B<vfork>() hérite des "
^^ Pas sûr que ce soit important de corriger les doubles espaces ici, ils doivent être mangés de toute façon à l'affichage.
Merci, j'ai tout pris sauf ces suppressions d'espaces. Je n'ai jamais compris pourquoi ces espaces doubles étaient systématiques dans la V.O., et les ai laissés dans la V.F., mais on pourrait peut-être les supprimer globalement.
Denis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Le 04/03/2012 04:21, D. Barbier a écrit :
Le 4 mars 2012 06:28, David Prévot a écrit : [...]
@@ -21782,22 +21768,21 @@ msgid "" "differs only in the treatment of the virtual address space, as described " "above." msgstr "" +"Comme avec B<fork>(2), le processus fils créé par B<vfork>() hérite des "
^^Pas sûr que ce soit important de corriger les doubles espaces ici, ils doivent être mangés de toute façon à l'affichage.
Merci, j'ai tout pris sauf ces suppressions d'espaces. Je n'ai jamais compris pourquoi ces espaces doubles étaient systématiques dans la V.O.
Peut-être po4a qui en fait un peu trop dans les cas suivants (extrait de la V.O.) :
the child process created by .BR vfork () inherits copies of various of the caller's process attributes
Il n'y a pourtant pas d'espace après la parenthèse.
Corriger po4a reviendrait à rendre approximatives un paquets de chaînes, à un paquet d'endroits, donc je ne sais pas s'il faut le corriger si c'est bien lui le coupable (du point de Debian, avec le cycle de publication qui devrait se figer dans moins de quatre mois, il serait peut-être préférable d'attendre après cela pour corriger po4a).
Amicalement
David
Le 4 mars 2012 14:39, David Prévot a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Le 04/03/2012 04:21, D. Barbier a écrit :
Le 4 mars 2012 06:28, David Prévot a écrit : [...]
@@ -21782,22 +21768,21 @@ msgid "" "differs only in the treatment of the virtual address space, as described " "above." msgstr "" +"Comme avec B<fork>(2), le processus fils créé par B<vfork>() hérite des "
^^ Pas sûr que ce soit important de corriger les doubles espaces ici, ils doivent être mangés de toute façon à l'affichage.
Merci, j'ai tout pris sauf ces suppressions d'espaces. Je n'ai jamais compris pourquoi ces espaces doubles étaient systématiques dans la V.O.
Peut-être po4a qui en fait un peu trop dans les cas suivants (extrait de la V.O.) :
the child process created by .BR vfork () inherits copies of various of the caller's process attributes
Il n'y a pourtant pas d'espace après la parenthèse.
Corriger po4a reviendrait à rendre approximatives un paquets de chaînes, à un paquet d'endroits, donc je ne sais pas s'il faut le corriger si c'est bien lui le coupable (du point de Debian, avec le cycle de publication qui devrait se figer dans moins de quatre mois, il serait peut-être préférable d'attendre après cela pour corriger po4a).
Ok, merci d'avoir regardé. Il vaut effectivement mieux ne pas toucher à po4a, on peut corriger la V.F. si on veut.
Denis
-
Cédric Boutillier -
D. Barbier -
David Prévot