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
-----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 :
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
Le 28 février 2012 23:23, Cédric Boutillier a écrit :
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 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
^^ Pas sûr que ce soit important de corriger les doubles espaces ici, ils doivent être mangés de toute façon à l'affichage.
[…]
+"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 ».
^^ ^^ Le double espace et le « s » manquant sur cette ligne.
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 : [...]
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 :
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