Bonjour à tous et meilleurs voeux pour 2025 ! Je vous fais suivre un extrait d'une dicussion que j'ai eu avec Jean-Paul à l'occasion de l'envoi de traduction terminées Le vendredi 03 janvier 2025 à 13:43 +0100, JP Guillonneau a écrit : > Re, > > Le 03/01/25 11:41 Jean-Pierre a écrit : > > Je viens d'envoyer ps2pdfwr.1 et startx.1. Les deux fichiers avec des > > fins de ligne de style Windows et pas Linux. Donc j'ai converti. > > Chez moi la commande dans le dossier où j’ai copié les fichiers que je > t’ai > envoyé : > > ~: file * > gs.1.po: GNU gettext message catalogue, Unicode text, UTF-8 text > ps2ascii.1.po: GNU gettext message catalogue, Unicode text, UTF-8 text > ps2epsi.1.po: GNU gettext message catalogue, Unicode text, UTF-8 text > ps2pdf.1.po: GNU gettext message catalogue, Unicode text, UTF-8 text > ps2pdfwr.1.po: GNU gettext message catalogue, Unicode text, UTF-8 text > pstops.1.po: GNU gettext message catalogue, Unicode text, UTF-8 text > startx.1.po: GNU gettext message catalogue, Unicode text, UTF-8 text > > Curieux, je n’ai aucune idée d’origine ou de solution du problème. > Je suis sous Trixie. > Pour test, je t’envoie les fichiers en compressé. > > Amicalement. Comme je l'ai fait remarqué à Jean–Paul ainsi qu'à bubu et Lucien, les fichier que je reçois ont parfois des fins de ligne Windows : $ file man1/ps2pdfwr.1.po man1/ps2pdfwr.1.po: GNU gettext message catalogue, Unicode text, UTF-8 text, with CRLF, LF line terminators alors que des fins de ligne Unix/linux sont attendus : $ file man1/ps2pdfwr.1.po man1/ps2pdfwr.1.po: GNU gettext message catalogue, Unicode text, UTF-8 text Après une rapide recherche sur le net, j'ai trouvé cette explication : https://superuser.com/questions/285735/mail-attachment-eol-end-of-line-problem Cette modification est due au traitement de la pièce jointe considérée par le client email comme "quoted printable" quand le fichier n'est pas compressé ou encapsulsé dans un fichier tar ou gzip comme le montre l'affichage de la source du message : --MP_/tGWgLGH3dx/S014taxuYcxQ Content-Type: text/x-gettext-translation;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=startx.1.po # French translation of manpages Dans le cas d'un fichier compressé ou encapsulé, il est considéré comme un binaire encodé en base64 : --MP_/z.GIr+ohpK_xdlDItOnrydS Content-Type: application/gzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=dossier.gz H4sIAAAAAAAAA9xcS3PbSJLuc/+KCnU4RMWSbFKWX2pZO37IPdrwQ2PaPd272ugoAkWq2iBAo wA9 fJrD/oM97c2xp9ZsxN435mb9k/4lm19mAShQtOXeidmmRgebBAuJzKx8Zxamrj/sz7Mv/pZ/A /q7 C'est sans doute la raison pour laquelle les fichiers envoyés au BTS doivent toujours être envoyés compressés et pourquoi, avec certains client de courriel, nous devrions faire de même, même si cela demande une étape de plus dans le traitement des relectures. Avec gnome evolution, il semble que je n'ai pas ce problème : jipege --=-461+gJufDzZpIKCQsAnB Content-Disposition: attachment; filename="sane-pie.5.po" Content-Type: text/x-gettext-translation; name="sane-pie.5.po"; charset="UTF-8" Content-Transfer-Encoding: base64 Je suis assez content de comprendre enfin le problème... Bien amicalement, Jean-Pierre
Attachment:
signature.asc
Description: This is a digitally signed message part