1 files changed, 18 insertions, 14 deletions
diff --git a/man/fr/deb-changes.pod b/man/fr/deb-changes.pod
index 83b2833..d540dbe 100644
--- a/man/fr/deb-changes.pod
+++ b/man/fr/deb-changes.pod
@@ -24,9 +24,9 @@ I<nom-du-fichier>B<.changes>
 
 Chaque envoi dans Debian est composé d'un fichier de contrôle .changes qui contient un certain nombre de champs au format L<deb822(5)>.
 
-Chaque champ commence par une étiquette, telle que B<Source> ou B<Binary> (la casse n'importe pas), suivie d'un S<« : »,> et du contenu du champ (sensible à la casse à moins que cela ne soit spécifié autrement). Les champs sont séparés seulement par des étiquettes de champ. En d'autres termes, le contenu d'un champ peut s'étendre sur plusieurs lignes, mais les outils d'installation joindront en général les lignes pendant le traitement du contenu du champ (sauf pour les champs à lignes multiples B<Description>, B<Changes>, B<Files>, B<Checksums-Sha1> et B<Checksums-Sha256>, voir ci-dessous).
+Chaque champ commence par une étiquette, telle que B<Source> ou B<Binary> (la casse n'importe pas), suivie d'un « : », et du contenu du champ (sensible à la casse à moins que cela ne soit spécifié autrement). Les champs sont séparés seulement par des étiquettes de champ. En d'autres termes, le contenu d'un champ peut s'étendre sur plusieurs lignes, mais les outils d'installation joindront en général les lignes pendant le traitement du contenu du champ (sauf pour les champs à lignes multiples B<Description>, B<Changes>, B<Files>, B<Checksums-Sha1> et B<Checksums-Sha256>, voir ci-dessous).
 
-Les données de contrôle pourraient être incluses dans une signature OpenPGP S<« ASCII> S<Armored »,> comme spécifié dans la RFC4880.
+Les données de contrôle pourraient être incluses dans une signature OpenPGP « ASCII Armored », comme spécifié dans la RFC4880.
 
 =head1 LES CHAMPS
 
@@ -44,7 +44,7 @@ La valeur de ce champ est habituellement extraite du fichier I<debian/changelog>
 
 =item B<Source:> I<nom-source> [B<(>I<version-source>B<)>] (requis)
 
-Le nom du paquet source. Si la version du source diffère de la version binaire, alors le I<nom-source> sera suivi par une I<version-source> entre parenthèses. Cela peut arriver quand il s'agit d'un envoi seulement binaire NMU S<(« non-maintainer> S<upload »).>
+Le nom du paquet source. Si la version du source diffère de la version binaire, alors le I<nom-source> sera suivi par une I<version-source> entre parenthèses. Cela peut arriver quand il s'agit d'un envoi seulement binaire NMU (« non-maintainer upload »).
 
 =item B<Binary:> I<liste-paquets-binaires> (requis selon le contexte)
 
@@ -52,7 +52,7 @@ Ce champ coupé est une liste, séparée par des espaces, de paquets binaires à
 
 =item B<Architecture:> I<liste-architectures>
 
-Liste des architectures des fichiers actuellement envoyés. Voici quelques architectures S<habituelles :> B<amd64>, B<armel>, B<i386>, etc. Remarquez que l'option B<all> signifie que le paquet est indépendant de toute architecture. Si les sources du paquet sont également envoyées, l'entrée spéciale B<source> est aussi présente. Les architectures joker ne doivent jamais être présentes dans la liste.
+Liste des architectures des fichiers actuellement envoyés. Voici quelques architectures habituelles : B<amd64>, B<armel>, B<i386>, etc. Remarquez que l'option B<all> signifie que le paquet est indépendant de toute architecture. Si les sources du paquet sont également envoyées, l'entrée spéciale B<source> est aussi présente. Les architectures joker ne doivent jamais être présentes dans la liste.
 
 =item B<Version:> I<chaîne-de-la-version> (requis)
 
@@ -64,21 +64,21 @@ Liste une ou plusieurs distributions, séparées par des espaces, dans lesquelle
 
 =item B<Urgency:> I<urgence> (recommandé)
 
-L'urgence de l'envoi. Les valeurs actuelles reconnues sont, par ordre croissant S<d'urgence :> B<low>, B<medium>, B<high>, B<critical> et B<emergency>.
+L'urgence de l'envoi. Les valeurs actuelles reconnues sont, par ordre croissant d'urgence : B<low>, B<medium>, B<high>, B<critical> et B<emergency>.
 
 =item B<Maintainer:> I<nom-complet-et-adresse-électronique> (requis)
 
-Le format de ce champ sera S<« Jean> Dupont S<E<lt>jdupont@example.orgE<gt> »> ; et c'est bien sûr le créateur du paquet, par opposition à l'auteur du programme mis en paquet.
+Le format de ce champ sera « Jean Dupont E<lt>jdupont@example.orgE<gt> » ; et c'est bien sûr le créateur du paquet, par opposition à l'auteur du programme mis en paquet.
 
 =item B<Changed-By:> I<nom-complet-et-adresse-électronique>
 
-Le format de ce champ sera S<« Jean> Dupont S<E<lt>jdupont@example.orgE<gt> »> ; et c'est bien sûr celui qui a préparé les modifications du paquet pour cette version.
+Le format de ce champ sera « Jean Dupont E<lt>jdupont@example.orgE<gt> » ; et c'est bien sûr celui qui a préparé les modifications du paquet pour cette version.
 
 =item B<Description:> (recommandé)
 
 =item S< >I<nom-du-paquet-binaire> B<-> I<résumé-du-paquet-binaire>
 
-Ce champ à lignes multiples contient une liste de noms de paquets binaires suivis d'une espace, d'un tiret S<(« B<-> »)> et de leur description courte éventuellement tronquée. Si l'envoi ne concerne que les sources, le champ est omis (depuis S<dpkg 1.19.3).>
+Ce champ à lignes multiples contient une liste de noms de paquets binaires suivis d'une espace, d'un tiret (« B<-> ») et de leur description courte éventuellement tronquée. Si l'envoi ne concerne que les sources, le champ est omis (depuis dpkg 1.19.3).
 
 =item B<Closes:> I<liste-numéros-bogue>
 
@@ -96,7 +96,7 @@ Ce champ définit une liste, séparée par des espaces, de profils de constructi
 
 =item S< >I<entrées-du-journal-des-modifications>
 
-Ce champ à lignes multiples fournit le texte concaténé de toutes les entrées de changelog faisant partie de cet envoi. Pour rendre ce champ à lignes multiples valable, les lignes vides sont remplacées par un point S<« B<.> »> et toutes les lignes sont indentées par une seule espace. Le contenu exact dépend du format du changelog.
+Ce champ à lignes multiples fournit le texte concaténé de toutes les entrées de changelog faisant partie de cet envoi. Pour rendre ce champ à lignes multiples valable, les lignes vides sont remplacées par un point « B<.> » et toutes les lignes sont indentées par une seule espace. Le contenu exact dépend du format du changelog.
 
 =item B<Files:> (requis)
 
@@ -104,22 +104,26 @@ Ce champ à lignes multiples fournit le texte concaténé de toutes les entrées
 
 Ce champ à lignes multiples fournit une liste de fichiers avec la md5sum, la taille, la section et la priorité de chacun.
 
-La première ligne de la valeur du champ (la partie sur la même ligne que le nom du champ suivi par deux-points) est toujours vide. Le contenu du champ est exprimé sous la forme de lignes de continuation, un ligne par fichier. Chaque ligne consiste en des entrées, séparées par des espaces, décrivant le S<fichier :> la md5sum, la taille du fichier, sa section, sa priorité et son nom.
+La première ligne de la valeur du champ (la partie sur la même ligne que le nom du champ suivi par deux-points) est toujours vide. Le contenu du champ est exprimé sous la forme de lignes de continuation, un ligne par fichier. Chaque ligne consiste en des entrées, séparées par des espaces, décrivant le fichier : la md5sum, la taille du fichier, sa section, sa priorité et son nom.
 
 Ce champ liste tous les fichiers qui composent l'envoi. La liste de fichiers de ce champ doit correspondre à celle présente dans les autres champs relatifs aux B<Checksums>.
 
-=item B<Checksums-Sha1:> (requis)
+B<Note>: The MD5 checksum is considered weak, and should never be assumed to be sufficient for secure verification, but this field cannot be omitted as it provides metadata not available anywhere else.
 
-=item B<Checksums-Sha256:> (requis)
+=item B<Checksums-Sha1:> (required, weak)
+
+=item B<Checksums-Sha256:> (required, strong)
 
 =item S< >I<somme-de-contrôle> I<taille> I<nom-du-fichier>
 
-Ces champs à lignes multiples fournissent une liste de fichiers avec la somme de contrôle et la taille de chacun. Ces champs ont la même syntaxe et ne diffèrent que par l'algorithme de somme de contrôle S<utilisé :> SHA-1 pour B<Checksums-Sha1> et SHA-256 pour B<Checksums-Sha256>.
+Ces champs à lignes multiples fournissent une liste de fichiers avec la somme de contrôle et la taille de chacun. Ces champs ont la même syntaxe et ne diffèrent que par l'algorithme de somme de contrôle utilisé : SHA-1 pour B<Checksums-Sha1> et SHA-256 pour B<Checksums-Sha256>.
 
-La première ligne de la valeur du champ (la partie sur la même ligne que le nom du champ suivi par deux-points) est toujours vide. Le contenu du champ est exprimé par des lignes de continuation, une ligne par fichier. Chaque ligne consiste en des entrées séparées par des espaces décrivant le S<fichier :la> somme de contrôle, la taille du fichier et le nom du fichier.
+La première ligne de la valeur du champ (la partie sur la même ligne que le nom du champ suivi par deux-points) est toujours vide. Le contenu du champ est exprimé par des lignes de continuation, une ligne par fichier. Chaque ligne consiste en des entrées séparées par des espaces décrivant le fichier :la somme de contrôle, la taille du fichier et le nom du fichier.
 
 Ces champs listent tous les fichiers qui composent l'envoi. La liste de fichiers de ce champ doit correspondre à celle présente dans le champ B<Files> et les autres champs relatifs aux B<Checksums>.
 
+B<Note>: The SHA-1 checksum is considered weak, and should never be assumed to be sufficient for secure verification.
+
 =back
 
 =head1 BOGUES