Re: [RFR2] po4a://manpages-fr-dev/fmemopen.3/po/fr.po
> Correction sujet
bonjour,
détails et suggestions,
amicalement,
bubu
>
> Le 17/02/2022 à 11:45, Lucien Gentis a écrit :
>> Bonjour,
>>
>> Merci à vous deux pour vos remarques.
>>
>> Je préfère "position actuelle" car position est une valeur et "en
>> cours" (ainsi que "courante d'ailleurs) qualifie une action en cours
>> d'exécution.
>>
>> Ligne 94 de ton diff : pourquoi remettre flux en anglais ?
>>
>> En PJ le fichier modifié et le diff correspondant
>>
>> Autres remarques ?
>>
>> Lucien
>>
>>
>> Le 17/02/2022 à 09:49, Jean-Pierre Giraud a écrit :
>>> Bonjour,
>>>
>>> Le 17/02/2022 à 05:59, Md a écrit :
>>>> Le mercredi 16 février 2022 à 17:24 +0100, Lucien Gentis a écrit :
>>>>> Le 16/02/2022 à 15:15, Md a écrit :
>>>>>> Le mercredi 16 février 2022 à 13:02 +0100, Lucien Gentis a écrit :
>>>>>>> Bonjour,
>>>>>>>
>>>>>>> Voici donc une proposition de mise à jour de fmemopen.3.po
>>>>>> Bonjour Lucien,
>>>>>>
>>>>>> un détail de cohérence en lignes 87 et 100.
>>>>>>
>>>>>> des entrées/sorties ...... le mode d'entrée/sortie ?
>>>>>>
>>>>>> Et lignes 162 et 178 : le flux est ouvert en lectures/écritures ?
>>>>>>
>>> De façon constante dans les manpages :
>>> reading and writing (action) ou read-write ou read/write (attribut de
>>> fichier) = (ouvert en) lecture/écriture
>>>
>>> pour I/O = E/S cf manpage aio.7.po :
>>> "aio - Vue d'ensemble des entrées-sorties (E/S) asynchrones POSIX"
>>>>>> Amicalement
>>>>>
>>>>> Pour ma part, j'ai toujours écrit entrées/sorties pour des échanges
>>>>> de
>>>>> données et lecture/écriture pour un mode d'accès.
>>>>>
>>>>> Peut-être que "mode d'entrées/sorties" est maladroit ; on pourrait
>>>>> plutôt dire "mode d'ouverture" (du flux) ?
>>>>>
>>>> Merci pour ces précisions.....cohérentes; je pensais le mode d'accès
>>>> bi-
>>>> directionnel et je cherche toujours la traduction la plus
>>>> techniquement
>>>> explicite. C'est une attention pédagogique qui butte sur mes
>>>> connaissances
>>>> informatiques....et les langues employées.
>>> Je crois qu'il faut conserver les termes techniques précis et pas
>>> (trop) les paraphraser, même si ce peut être un peu "rugueux" ou
>>> maladroit...
>>>> Une parfaite illustration me semble ce retour de JP_Giraud:
>>>>
>>>> "Pour soft errors je suggère plutôt "erreurs transitoires" (cf
>>>> https://fr.wikipedia.org/wiki/Rayonnement_cosmique ) ce sont des
>>>> erreurs
>>>> provoqués par le rayon cosmique sur les composants électroniques
>>>> dans le
>>>> résumé d'une thèse on parle d'erreurs radiatives
>>>> https://ecole-doctorale-353.univ-amu.fr/en/soutenance/163
>>>> La traduction allemande est "erreur douce" "weichen Fehler" "
>>>>
>>>> C'est ma lecture qui est maladroite.
>>>>
>>>> Amicalement.
>>> Par préférence, j'ai converti current en "en cours" ou "actuel" qui
>>> me semblent plus adaptés et compréhensibles (et employé de façon ...
>>> courante dans manpages) et c'est pour moi presque un faux ami.
>>> Amicalement,
>>> jipege
--- fmemopen.3.po 2022-02-17 17:43:05.085250994 +0100
+++ fmemopen.3.relu.po 2022-02-17 17:59:47.320733307 +0100
@@ -343,7 +343,7 @@
"may be useful to detect errors at the time of an output operation:"
msgstr ""
"Essayer d'écrire plus de I<taille> octets dans le tampon crée une erreur. "
-"Par défaut, de telles erreurs ne seront visibles (en absence de données) que "
+"Par défaut, de telles erreurs ne seront visibles (en l'absence de données) que "
"lorsque le tampon I<stdio> sera vidé. Désactiver cette mise en tampon avec "
"l'appel suivant peut s'avérer utile pour détecter les erreurs au moment "
"d'une opération de sortie :"
@@ -528,10 +528,10 @@
"Avec les versions 2.9 à  2.21, l'implémentation dans la glibc de "
"B<fmemopen>() prenait en charge un mode «binaire» qui pouvait être activé en "
"spécifiant la lettre \\(aqb\\(aq comme second caractère de I<mode>. Dans ce "
-"mode, les opérations d'écriture n'ajoutait pas de manière implicite l'octet "
-"de valeur zéro terminal, et B<fseek>(3) B<SEEK_END> définissait la position "
+"mode, les opérations d'écriture n'ajoutaient pas de manière implicite l'octet "
+"de valeur zéro terminal, et B<SEEK_END> B<fseek>(3) définissait la position "
"courante à la fin du tampon (autrement dit la valeur spécifiée par "
-"l'argumentI<taille>), et non à la longueur de la chaîne courante."
+"l'argument I<taille>), et non à la longueur de la chaîne courante."
#. http://sourceware.org/bugzilla/show_bug.cgi?id=12836
#. type: Plain text
@@ -555,7 +555,7 @@
"Binary mode was removed in glibc 2.22; a \\(aqb\\(aq specified in I<mode> "
"has no effect."
msgstr ""
-"Le mode binaire a été supprimé à partir de la version 2.22 de la glibc et un "
+"Le mode binaire a été supprimé à partir de la version 2.22 de la glibc et un "
"\\(aqb\\(aq spécifié dans I<mode> n'a dorénavant aucun effet."
#. type: SH
@@ -667,7 +667,7 @@
"following:"
msgstr ""
"Le programme ci-dessous utilise B<fmemopen>() pour ouvrir un tampon d'entrée "
-"et B<open_memstream>() pour ouvrir un tampon de sortie de taille dynamique. "
+"et B<open_memstream>(3) pour ouvrir un tampon de sortie de taille dynamique. "
"Ce programme scrute la chaîne en entrée (récupérée du premier argument de la "
"ligne de commande du programme) sous forme d'entiers, et écrit le carré de "
"ces entiers dans le tampon de sortie. Voici un exemple de la sortie produite "
Reply to: