• Re: [RFR2] po4a://manpages-fr-dev/fmemopen.3/po/fr.po

    From [email protected]@21:1/5 to All on Thu Feb 17 18:10:01 2022
    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 valeu