Bonsoir,
J'ai choisi de ne pas mettre à jour directement depuis le tarball 3.64, car il y avait de nombreux correctifs purement en anglais, bien identifiés.
http://git.kernel.org/cgit/docs/man-pages/man-pages.git/log/?id=8817c2..544a... mis à part 8856aab85
Du coup il y a 3/4 chaînes restant à traduire jusqu'à 8817c2 (pour David et Frédéric), puis unfuzzy massif, puis retraduction jusqu'à 3.64.
Afficher les réponses par date
Bonsoir,
C'est terminé pour cette première phase.
F.
On 04/14/2014 02:53 PM, Simon Paillard wrote:
Bonsoir,
J'ai choisi de ne pas mettre à jour directement depuis le tarball 3.64, car il y avait de nombreux correctifs purement en anglais, bien identifiés.
http://git.kernel.org/cgit/docs/man-pages/man-pages.git/log/?id=8817c2..544a... mis à part 8856aab85
Du coup il y a 3/4 chaînes restant à traduire jusqu'à 8817c2 (pour David et Frédéric), puis unfuzzy massif, puis retraduction jusqu'à 3.64.
On Tue, Apr 15, 2014 at 03:27:17PM -0400, Frédéric Hantrais wrote:
On 04/14/2014 02:53 PM, Simon Paillard wrote:
Du coup il y a 3/4 chaînes restant à traduire jusqu'à 8817c2 (pour David et Frédéric), puis unfuzzy massif, puis retraduction jusqu'à 3.64.
C'est terminé pour cette première phase.
Merci Frédéric et David !
On Mon, Apr 14, 2014 at 08:53:29PM +0200, Simon Paillard wrote:
J'ai choisi de ne pas mettre à jour directement depuis le tarball 3.64, car il y avait de nombreux correctifs purement en anglais, bien identifiés.
http://git.kernel.org/cgit/docs/man-pages/man-pages.git/log/?id=8817c2..544a... mis à part 8856aab85
C'est fait, il reste la régénération des po. Auriez-vous de l'inspiration quant à la catégorie à laquelle attribuer open_by_handle_at.2 ?
Sachant que cette page référence: open(2) stdio libblkid(3) N/A blkid(8) N/A findfs(8) N/A mount(8) filesystem
Et qu'elle est référencée par syscalls.2: unistd capabilities.7: process symlink.7: stdio
Le 16 avril 2014 01:07, Simon Paillard a écrit :
On Mon, Apr 14, 2014 at 08:53:29PM +0200, Simon Paillard wrote:
J'ai choisi de ne pas mettre à jour directement depuis le tarball 3.64, car il y avait de nombreux correctifs purement en anglais, bien identifiés.
http://git.kernel.org/cgit/docs/man-pages/man-pages.git/log/?id=8817c2..544a... mis à part 8856aab85
C'est fait, il reste la régénération des po. Auriez-vous de l'inspiration quant à la catégorie à laquelle attribuer open_by_handle_at.2 ?
Sachant que cette page référence: open(2) stdio libblkid(3) N/A blkid(8) N/A findfs(8) N/A mount(8) filesystem
Et qu'elle est référencée par syscalls.2: unistd capabilities.7: process symlink.7: stdio
Bonjour Simon,
La description est : The name_to_handle_at() and open_by_handle_at() system calls split the functionality of openat(2) into two parts: name_to_handle_at() returns an opaque handle that corresponds to a specified file; open_by_handle_at() opens the file corresponding to a handle returned by a previous call to name_to_handle_at() and returns an open file descriptor.
Je mettrais donc cette page avec openat (=open), c'est-à-dire stdio.
Denis
On Wed, Apr 16, 2014 at 01:24:37AM +0200, D. Barbier wrote:
Le 16 avril 2014 01:07, Simon Paillard a écrit :
On Mon, Apr 14, 2014 at 08:53:29PM +0200, Simon Paillard wrote:
J'ai choisi de ne pas mettre à jour directement depuis le tarball 3.64, car il y avait de nombreux correctifs purement en anglais, bien identifiés.
http://git.kernel.org/cgit/docs/man-pages/man-pages.git/log/?id=8817c2..544a... mis à part 8856aab85
C'est fait, il reste la régénération des po. Auriez-vous de l'inspiration quant à la catégorie à laquelle attribuer open_by_handle_at.2 ?
La description est : The name_to_handle_at() and open_by_handle_at() system calls split the functionality of openat(2) into two parts: name_to_handle_at() returns an opaque handle that corresponds to a specified file; open_by_handle_at() opens the file corresponding to a handle returned by a previous call to name_to_handle_at() and returns an open file descriptor.
Je mettrais donc cette page avec openat (=open), c'est-à-dire stdio.
Merci pour tes conseils, j'ai fait ça.
On Wed, Apr 16, 2014 at 01:07:31AM +0200, Simon Paillard wrote:
On Mon, Apr 14, 2014 at 08:53:29PM +0200, Simon Paillard wrote:
J'ai choisi de ne pas mettre à jour directement depuis le tarball 3.64, car il y avait de nombreux correctifs purement en anglais, bien identifiés.
http://git.kernel.org/cgit/docs/man-pages/man-pages.git/log/?id=8817c2..544a... mis à part 8856aab85
C'est fait, il reste la régénération des po.
Les chaînes à traduire pour 3.64 :
error: 345 messages traduits, 1 traduction approximative, 2 messages non traduits. filesystem: 1052 messages traduits, 2 traductions approximatives. inotify: 133 messages traduits, 28 traductions approximatives, 50 messages non traduits. locale: 813 messages traduits, 14 traductions approximatives. man2: 1545 messages traduits, 2 traductions approximatives, 2 messages non traduits. math: 1338 messages traduits, 1 traduction approximative. memory: 1162 messages traduits, 1 traduction approximative. net: 2365 messages traduits, 1 traduction approximative, 1 message non traduit. signal: 1536 messages traduits, 4 traductions approximatives. socket: 1012 messages traduits, 1 traduction approximative. special: 1931 messages traduits, 1 message non traduit. stdio: 1802 messages traduits, 38 traductions approximatives, 81 messages non traduits. stdlib: 958 messages traduits, 3 traductions approximatives, 1 message non traduit. string: 539 messages traduits, 1 traduction approximative. tty: 747 messages traduits, 5 traductions approximatives, 9 messages non traduits. unistd: 2829 messages traduits, 3 traductions approximatives. 35200 translated, 105 fuzzy, 147 untranslated ==> 99.29%
Bonsoir,
(Michael a sorti 3.65, il a le rythme :)
On Wed, Apr 16, 2014 at 08:27:02PM +0200, Simon Paillard wrote:
Les chaînes à traduire pour 3.64 :
[...]
stdio: 1802 messages traduits, 38 traductions approximatives, 81 messages non traduits.
Frédéric, merci pour tes commits, on approche stdio: 1848 messages traduits, 16 traductions approximatives, 57 messages non traduits
Conformément ton message de commit, j'ai fait une relecture, désormais dans git.
Une remarque: « file handle» se traduit généralement par descripteur de fichier (voir les autres fichiers, par exemple avec: git grep -A10 'file handle' po4a/*/po/fr.po ). Gestionnaire de fichier fait penser à un explorateur genre explorer.exe, ou nautilus.
Bonsoir,
merci de l'info. J'avais parcouru les "handle" des autres fichiers pour arriver à gestionnaire, mais ça me plaisait pas beaucoup, j'espérais trouver mieux avant la fin. Par contre, si on prend comme traduction "descripteur de fichier", comment distingue-t-on "file descriptor" et "file handle" ?
Je vais m'y remettre ce soir ou demain matin, mais je ne suis pas très disponibles ces jours-ci. Je vais faire au mieux.
F.
On 04/20/2014 04:26 PM, Simon Paillard wrote:
Bonsoir,
(Michael a sorti 3.65, il a le rythme :)
On Wed, Apr 16, 2014 at 08:27:02PM +0200, Simon Paillard wrote:
Les chaînes à traduire pour 3.64 :
[...]
stdio: 1802 messages traduits, 38 traductions approximatives, 81 messages non traduits.
Frédéric, merci pour tes commits, on approche stdio: 1848 messages traduits, 16 traductions approximatives, 57 messages non traduits
Conformément ton message de commit, j'ai fait une relecture, désormais dans git.
Une remarque: « file handle» se traduit généralement par descripteur de fichier (voir les autres fichiers, par exemple avec: git grep -A10 'file handle' po4a/*/po/fr.po ). Gestionnaire de fichier fait penser à un explorateur genre explorer.exe, ou nautilus.
Matin,
On Sun, Apr 20, 2014 at 05:53:34PM -0400, Frédéric Hantrais wrote:
merci de l'info. J'avais parcouru les "handle" des autres fichiers pour arriver à gestionnaire, mais ça me plaisait pas beaucoup, j'espérais trouver mieux avant la fin. Par contre, si on prend comme traduction "descripteur de fichier", comment distingue-t-on "file descriptor" et "file handle" ?
Pour moi il n'y en a pas, ce sont des synonymes. D'eilleurs wikipedia redirige File Handle vers File Descriptor https://en.wikipedia.org/w/index.php?title=File_handle&redirect=no
Ils disent cependant: The FILE data structure in the C standard I/O library usually includes a low level file descriptor for the object in question on Unix-like systems. The overall data structure provides additional abstraction and is instead known as a file handle
En français: Le filehandle FILE * de la bibliothèque C d'entrées/sorties standard est techniquement un pointeur vers une structure de données gérées par les routines de cette bibliothèque. Sur les systèmes Unix, l'une de ces structures inclut un descripteur de fichier pour l'objet en question. Puisque le nom de file handle se réfère à cette couche additionnelle, il n'est pas interchangeable avec celui de descripteur de fichier.
Du coup je sais pas quoi proposer..
Je vais m'y remettre ce soir ou demain matin, mais je ne suis pas très disponibles ces jours-ci. Je vais faire au mieux.
Pas de souci, ça t'ennuie si je travaille plutôt la fin du fichier ?
Bonjour,
A la deuxième lecture de bon matin, la différence ne m'apparait pas toujours pas totalement claire... il va falloir insister.
Coté délais, je pense pouvoir finir avant mardi soir (enfin mercredi matin). Si tu en as le temps et l'envie, et si tu souhaites finir rapidement, n'hésite pas travailler dessus.
Amicalement, Frédéric
On 04/21/2014 06:07 AM, Simon Paillard wrote:
Matin,
On Sun, Apr 20, 2014 at 05:53:34PM -0400, Frédéric Hantrais wrote:
merci de l'info. J'avais parcouru les "handle" des autres fichiers pour arriver à gestionnaire, mais ça me plaisait pas beaucoup, j'espérais trouver mieux avant la fin. Par contre, si on prend comme traduction "descripteur de fichier", comment distingue-t-on "file descriptor" et "file handle" ?
Pour moi il n'y en a pas, ce sont des synonymes. D'eilleurs wikipedia redirige File Handle vers File Descriptor https://en.wikipedia.org/w/index.php?title=File_handle&redirect=no
Ils disent cependant: The FILE data structure in the C standard I/O library usually includes a low level file descriptor for the object in question on Unix-like systems. The overall data structure provides additional abstraction and is instead known as a file handle
En français: Le filehandle FILE * de la bibliothèque C d'entrées/sorties standard est techniquement un pointeur vers une structure de données gérées par les routines de cette bibliothèque. Sur les systèmes Unix, l'une de ces structures inclut un descripteur de fichier pour l'objet en question. Puisque le nom de file handle se réfère à cette couche additionnelle, il n'est pas interchangeable avec celui de descripteur de fichier.
Du coup je sais pas quoi proposer..
Je vais m'y remettre ce soir ou demain matin, mais je ne suis pas très disponibles ces jours-ci. Je vais faire au mieux.
Pas de souci, ça t'ennuie si je travaille plutôt la fin du fichier ?
Le 21 avril 2014 13:22, Frédéric Hantrais a écrit :
Bonjour,
A la deuxième lecture de bon matin, la différence ne m'apparait pas toujours pas totalement claire... il va falloir insister.
[...]
Bonjour,
Le terme « file descriptor » désigne spécifiquement un entier. Par exemple, $ ls -l /proc/self/fd liste tous les file descriptors attachés à la commande en cours, ici ls. La structure de données FILE contient cette information, plus d'autres. On récupère le descripteur de fichiers avec fileno.
Apparemment, une nouvelle structure de données file_handle a été introduite http://lwn.net/Articles/395784/ Le terme « handle » peut être lui aussi traduit par descripteur, d'où la confusion. Sur http://fr.wiktionary.org/wiki/handle ils mentionnent « indicateur de fichier » comme traduction de « file handle ». Pour l'instant, je ne vois rien de mieux.
Denis
Bonjour,
J'ai renvoyé stdio, et j'ai laissé "indicateur" pour "file handle". Sans grand enthousiasme, mais je n'ai pas mieux. J'ai aussi retenu "identifiant durable" pour "persistent ID", ce qui ne m'enchante pas non plus.
Bref, si je peux le garder encore un jour ou deux, je vais y repenser et essayer de vous proposer d'autres idées.
Frédéric
On 04/22/2014 03:28 AM, D. Barbier wrote:
Le 21 avril 2014 13:22, Frédéric Hantrais a écrit :
Bonjour,
A la deuxième lecture de bon matin, la différence ne m'apparait pas toujours pas totalement claire... il va falloir insister.
[...]
Bonjour,
Le terme « file descriptor » désigne spécifiquement un entier. Par exemple, $ ls -l /proc/self/fd liste tous les file descriptors attachés à la commande en cours, ici ls. La structure de données FILE contient cette information, plus d'autres. On récupère le descripteur de fichiers avec fileno.
Apparemment, une nouvelle structure de données file_handle a été introduite http://lwn.net/Articles/395784/ Le terme « handle » peut être lui aussi traduit par descripteur, d'où la confusion. Sur http://fr.wiktionary.org/wiki/handle ils mentionnent « indicateur de fichier » comme traduction de « file handle ». Pour l'instant, je ne vois rien de mieux.
Denis _______________________________________________ Perkamon-fr mailing list Perkamon-fr@traduc.org http://listes.traduc.org/cgi-bin/mailman/listinfo/perkamon-fr
bonjour,
Toujours pas de révélation pour le file handle. Pensez-vous que "notice" ou "label" soit mieux qu'indicateur ?
F.
On 04/23/2014 12:30 AM, Frédéric Hantrais wrote:
Bonjour,
J'ai renvoyé stdio, et j'ai laissé "indicateur" pour "file handle". Sans grand enthousiasme, mais je n'ai pas mieux. J'ai aussi retenu "identifiant durable" pour "persistent ID", ce qui ne m'enchante pas non plus.
Bref, si je peux le garder encore un jour ou deux, je vais y repenser et essayer de vous proposer d'autres idées.
Frédéric
On 04/22/2014 03:28 AM, D. Barbier wrote:
Le 21 avril 2014 13:22, Frédéric Hantrais a écrit :
Bonjour,
A la deuxième lecture de bon matin, la différence ne m'apparait pas toujours pas totalement claire... il va falloir insister.
[...]
Bonjour,
Le terme « file descriptor » désigne spécifiquement un entier. Par exemple, $ ls -l /proc/self/fd liste tous les file descriptors attachés à la commande en cours, ici ls. La structure de données FILE contient cette information, plus d'autres. On récupère le descripteur de fichiers avec fileno.
Apparemment, une nouvelle structure de données file_handle a été introduite http://lwn.net/Articles/395784/ Le terme « handle » peut être lui aussi traduit par descripteur, d'où la confusion. Sur http://fr.wiktionary.org/wiki/handle ils mentionnent « indicateur de fichier » comme traduction de « file handle ». Pour l'instant, je ne vois rien de mieux.
Denis _______________________________________________ Perkamon-fr mailing list Perkamon-fr@traduc.org http://listes.traduc.org/cgi-bin/mailman/listinfo/perkamon-fr
Perkamon-fr mailing list Perkamon-fr@traduc.org http://listes.traduc.org/cgi-bin/mailman/listinfo/perkamon-fr
Salut Frédéric,
On Fri, Apr 25, 2014 at 08:13:35AM -0400, Frédéric Hantrais wrote:
Toujours pas de révélation pour le file handle. Pensez-vous que "notice" ou "label" soit mieux qu'indicateur ?
Je pense qu'indicateur n'est pas si mal: * sa proximité avec descripteur rappelle que les sens sont proches * il faut cependant bien faire attention au bon usage des termes, pour éviter de laisser croire à un synonyme..
On 04/23/2014 12:30 AM, Frédéric Hantrais wrote:
J'ai renvoyé stdio, et j'ai laissé "indicateur" pour "file handle". Sans grand enthousiasme, mais je n'ai pas mieux. J'ai aussi retenu "identifiant durable" pour "persistent ID", ce qui ne m'enchante pas non plus.
Bref, si je peux le garder encore un jour ou deux, je vais y repenser et essayer de vous proposer d'autres idées.
On 04/22/2014 03:28 AM, D. Barbier wrote:
Le 21 avril 2014 13:22, Frédéric Hantrais a écrit :
A la deuxième lecture de bon matin, la différence ne m'apparait pas toujours pas totalement claire... il va falloir insister.
[...] Le terme « file descriptor » désigne spécifiquement un entier. Par exemple, $ ls -l /proc/self/fd liste tous les file descriptors attachés à la commande en cours, ici ls. La structure de données FILE contient cette information, plus d'autres. On récupère le descripteur de fichiers avec fileno.
Apparemment, une nouvelle structure de données file_handle a été introduite http://lwn.net/Articles/395784/ Le terme « handle » peut être lui aussi traduit par descripteur, d'où la confusion. Sur http://fr.wiktionary.org/wiki/handle ils mentionnent « indicateur de fichier » comme traduction de « file handle ». Pour l'instant, je ne vois rien de mieux.
Bonsoir,
On Sun, Apr 20, 2014 at 10:26:17PM +0200, Simon Paillard wrote:
(Michael a sorti 3.65, il a le rythme :)
On Wed, Apr 16, 2014 at 08:27:02PM +0200, Simon Paillard wrote:
Les chaînes à traduire pour 3.64 :
[...]
stdio: 1802 messages traduits, 38 traductions approximatives, 81 messages non traduits.
Frédéric, merci pour tes commits, on approche stdio: 1848 messages traduits, 16 traductions approximatives, 57 messages non traduits
Conformément ton message de commit, j'ai fait une relecture, désormais dans git.
Une remarque: « file handle» se traduit généralement par descripteur de fichier (voir les autres fichiers, par exemple avec: git grep -A10 'file handle' po4a/*/po/fr.po ). Gestionnaire de fichier fait penser à un explorateur genre explorer.exe, ou nautilus.
J'ai fait une relecture de open_by_handle_at.2, notamment des histoires de typographie, simplification des formulations :
86bd1f stdio: les commentaires des src sur 80 colonnes eb5e2d stdio: correction format 1c63fa stdio: différentes relectures 20ec79 caller -> appelant, pas besoin de rajouter "composant" 965f34 durable -> persistant 772ff0 stdio: espaces simples en français
Le passage à 80 colonnes des commentaires de code n'est pas fini, et n'est même pas respecté dans la version anglaise..
Je pense que c'est acceptable de publier dans l'état. Si vous voulez faire une relecture, merci de faire signe d'ici dimanche soir, j'aimerais pas tarder.
Bonsoir,
Merci du feedback. J'ai dû aller assez vite cette fois-ci, donc désolé si je t'ai donné du boulot.
Personnellement, je n'aime pas beaucoup "l'appelant" qui ne me semble pas une façon très francophone de formuler la chose. Même chose pour persistant, qui ne me plaisait guère, mais j'ai déjà oublié le contexte... Tout ça est subjectif :)
Pour les 80 colonnes, est-ce qu'on doit faire quelque chose ? je pensais que c'était un traitement automatique.
F.
On 04/26/2014 05:01 PM, Simon Paillard wrote:
Bonsoir,
On Sun, Apr 20, 2014 at 10:26:17PM +0200, Simon Paillard wrote:
(Michael a sorti 3.65, il a le rythme :)
On Wed, Apr 16, 2014 at 08:27:02PM +0200, Simon Paillard wrote:
Les chaînes à traduire pour 3.64 :
[...]
stdio: 1802 messages traduits, 38 traductions approximatives, 81 messages non traduits.
Frédéric, merci pour tes commits, on approche stdio: 1848 messages traduits, 16 traductions approximatives, 57 messages non traduits
Conformément ton message de commit, j'ai fait une relecture, désormais dans git.
Une remarque: « file handle» se traduit généralement par descripteur de fichier (voir les autres fichiers, par exemple avec: git grep -A10 'file handle' po4a/*/po/fr.po ). Gestionnaire de fichier fait penser à un explorateur genre explorer.exe, ou nautilus.
J'ai fait une relecture de open_by_handle_at.2, notamment des histoires de typographie, simplification des formulations :
86bd1f stdio: les commentaires des src sur 80 colonnes eb5e2d stdio: correction format 1c63fa stdio: différentes relectures 20ec79 caller -> appelant, pas besoin de rajouter "composant" 965f34 durable -> persistant 772ff0 stdio: espaces simples en français
Le passage à 80 colonnes des commentaires de code n'est pas fini, et n'est même pas respecté dans la version anglaise..
Je pense que c'est acceptable de publier dans l'état. Si vous voulez faire une relecture, merci de faire signe d'ici dimanche soir, j'aimerais pas tarder.
Soir,
On Sat, Apr 26, 2014 at 05:27:20PM -0400, Frédéric Hantrais wrote:
On 04/26/2014 05:01 PM, Simon Paillard wrote:
J'ai fait une relecture de open_by_handle_at.2, notamment des histoires de typographie, simplification des formulations :
Merci du feedback. J'ai dû aller assez vite cette fois-ci, donc désolé si je t'ai donné du boulot.
Pas de souci, le plus important c'est qu'on partage nos bonnes pratiques pas toujours formalisées...
Personnellement, je n'aime pas beaucoup "l'appelant" qui ne me semble pas une façon très francophone de formuler la chose.
Demandeur pourrait être mieux, ou appeleur (jamais rencontré ?!). http://www.cnrtl.fr/lexicographie/appelant
Même chose pour persistant, qui ne me plaisait guère, mais j'ai déjà oublié le contexte... Tout ça est subjectif :)
J'ai moins de scrupules là, le terme est *très utilisé* en informatique, et correct d'un point de vue lexical. http://www.crisco.unicaen.fr/des/synonymes/persistant
Cela fait peut-être trop longtemps que je vois ces 2 termes dans les traductions, je n'ai plus le recul..
Pour les 80 colonnes, est-ce qu'on doit faire quelque chose ? je pensais que c'était un traitement automatique.
C'est automatique pour les paragraphes de texte classiques.
En revanche, quand il s'agit de code ou plus généralement de paragraphes où les retours à la ligne sont codés en dur (présence de \n dans les chaînes, et attribut "no-wrap" sur la chaîne), il faut le faire à la main, càd placer les \n autour de 80 caractères.
Exemple po4a/stdio/po/fr.po ligne 9420 (open_by_handle_at.2:109).
Je sais pas si l'explication est claire :)
Bonsoir,
La version 3.64 de perkamon-fr vient d'être publiée.
Merci à tous, et particulièrement à Frédéric qui s'est chargé du gros morceau qu'est open_by_handle_at.2.
On Sat, Apr 26, 2014 at 11:01:02PM +0200, Simon Paillard wrote:
On Sun, Apr 20, 2014 at 10:26:17PM +0200, Simon Paillard wrote:
(Michael a sorti 3.65, il a le rythme :)
On Wed, Apr 16, 2014 at 08:27:02PM +0200, Simon Paillard wrote:
Les chaînes à traduire pour 3.64 :
[...]
stdio: 1802 messages traduits, 38 traductions approximatives, 81 messages non traduits.
Frédéric, merci pour tes commits, on approche stdio: 1848 messages traduits, 16 traductions approximatives, 57 messages non traduits
[..]
Je pense que c'est acceptable de publier dans l'état. Si vous voulez faire une relecture, merci de faire signe d'ici dimanche soir, j'aimerais pas tarder.
Le 27 avril 2014 21:44, Simon Paillard a écrit :
Bonsoir,
La version 3.64 de perkamon-fr vient d'être publiée.
Merci à tous, et particulièrement à Frédéric qui s'est chargé du gros morceau qu'est open_by_handle_at.2.
Merci, j'ai mis à jour les sites web.
Denis
-
D. Barbier -
Frédéric Hantrais -
Simon Paillard