[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFR] po4a://manpages-fr/time.2/po/fr/po



Bonjour,

> Ce fichier a été mis à jour. Merci d'avance pour vos relectures.
> Amicalement,
> jipege
>
des détails et suggestions,
                amicalement,

            bubu
--- extime.2.po	2024-05-15 11:25:16.807229678 +0200
+++ time.2.po	2024-05-15 11:33:13.431690770 +0200
@@ -121,7 +121,7 @@
 "If I<tloc> is non-NULL, the return value is also stored in the memory "
 "pointed to by I<tloc>."
 msgstr ""
-"Si I<tloc> n'est pas NULL, le code de retour est également stockée dans la "
+"Si I<tloc> n'est pas NULL, le code de retour est également stocké dans la "
 "structure de mémoire vers laquelle il pointe."
 
 #. type: SH
@@ -195,7 +195,7 @@
 "implementation provided by the B<vdso>(7)  (so that there is no trap into "
 "the kernel), an invalid address may instead trigger a B<SIGSEGV> signal."
 msgstr ""
-"Sur des systèmes où la fonction enveloppe B<time>() de la bibliothèque C "
+"Sur des systèmes où la fonction enveloppe B<time>() de la bibliothèque C "
 "appelle une implémentation fournie par B<vdso>(7) (pour ne pas créer de "
 "faille dans le noyau), une adresse non valable peut alors provoquer un "
 "signal B<SIGSEGV>."
@@ -225,10 +225,10 @@
 msgstr ""
 "POSIX.1 définit le nombre de I<secondes écoulées depuis l'époque POSIX> "
 "grâce à une formule qui est une approximation du nombre de secondes entre "
-"une date spécifiée et l'époque. Cette formule prend en compte le fait que "
+"une date spécifiée et l'époque POSIX. Cette formule prend en compte le fait que "
 "les années divisibles par 4 sont bissextiles, sauf les années qui sont "
 "divisibles par 100 mais pas par 400. Cette valeur ne correspond donc pas "
-"toujours au véritable nombre de secondes écoulées entre la date et l'époque, "
+"toujours au véritable nombre de secondes écoulées entre la date et l'époque POSIX, "
 "à cause des secondes intercalaires et parce que les horloges système ne sont "
 "pas forcément synchronisées avec une référence standard. Les systèmes Linux "
 "suivent normalement l'exigence de POSIX que cette valeur ignore les secondes "
@@ -307,7 +307,7 @@
 msgstr ""
 "Les codes de retour d'erreur de cet appel système sont indistincts des "
 "retours lorsque l'appel réussit mais que le temps est de quelques secondes "
-"I<avant> Epoch, donc la fonction enveloppe de la bibliothèque C ne "
+"I<avant> l'Epoch, donc la fonction enveloppe de la bibliothèque C ne "
 "positionne jamais I<errno> à la fin de cet appel."
 
 #. type: Plain text
@@ -381,10 +381,10 @@
 msgstr ""
 "POSIX.1 définit le nombre de I<secondes écoulées depuis l'époque POSIX> "
 "grâce à une formule qui est une approximation du nombre de secondes entre "
-"une date spécifiée et l'époque. Cette formule prend en compte le fait que "
+"une date spécifiée et l'époque POSIX. Cette formule prend en compte le fait que "
 "les années divisibles par 4 sont bissextiles, sauf les années qui sont "
 "divisibles par 100 mais pas par 400. Cette valeur ne correspond donc pas "
-"toujours au véritable nombre de secondes écoulées entre la date et l'époque, "
+"toujours au véritable nombre de secondes écoulées entre la date et l'époque POSIX, "
 "à cause des secondes intercalaires et parce que les horloges système ne sont "
 "pas forcément synchronisées avec une référence standard. Cependant elle "
 "reste cohérente au cours du temps. Consultez l'explication A.4.15 de "
@@ -407,7 +407,7 @@
 "32 bits signé et où les tics de l'horloge atteignent ou dépassent 2**31 "
 "secondes (2038-01-19 03:14:08 UTC, en ignorant les secondes intercalaires). "
 "(POSIX.1 permet mais n'exige pas l'erreur B<EOVERFLOW> si les secondes "
-"depuis Epoch ne tiennent pas dans I<time_t>). Au contraire, le comportement "
+"depuis l'Epoch ne tiennent pas dans I<time_t>). Au contraire, le comportement "
 "sur Linux n'est pas défini quand l'heure du système dépasse la plage "
 "I<time_t>. Les applications conçues pour fonctionner après 2038 devraient "
 "utiliser des ABI avec un I<time_t> plus grand que 32 bits."

Reply to: