Bonjour,
Je vous contacte car plusieurs utilisateurs m'ont adressé des remarques concernant la traduction des abréviations françaises utilisées pour les mois (ex. « aoû » pour « août »).
J'ai joint la copie d'écran que Daniel m'a envoyé, il lui semble qu'il manque un « t » à « aoû » et il n'est pas le premier à me signaler que la traduction des mois sous leur forme contractée est étrange.
Cette traduction est très importante car elle figure par défaut sur le bureau GNOME. La chaîne concernée ne fait pas partie de GNOME mais de la glibc[1], vous pouvez faire le test chez vous en compilant le code source joint (gcc month.c).
Wikipédia[2] fournit des abréviations qui me semblent meilleures qu'en pensez vous ?
J'ai appris que Michel Robitaille quittait son rôle de TP, Pierre Machard est-il son remplaçant ?
Cordialement, Stéphane
[1] http://www.gnu.org/software/libc/ [2] http://fr.wikipedia.org/wiki/Mois#Abr.C3.A9viations [3] http://sourceware.org/bugzilla/
Afficher les réponses par date
Le lundi 27 août 2007 à 09:41 +0200, Stéphane Raimbault a écrit :
Bonjour,
Je vous contacte car plusieurs utilisateurs m'ont adressé des remarques concernant la traduction des abréviations françaises utilisées pour les mois (ex. « aoû » pour « août »).
J'ai joint la copie d'écran que Daniel m'a envoyé, il lui semble qu'il manque un « t » à « aoû » et il n'est pas le premier à me signaler que la traduction des mois sous leur forme contractée est étrange.
Cette traduction est très importante car elle figure par défaut sur le bureau GNOME. La chaîne concernée ne fait pas partie de GNOME mais de la glibc[1], vous pouvez faire le test chez vous en compilant le code source joint (gcc month.c).
J'observe le même comportement. Je crois comprendre qu'il y a une volonté de garder les abréviations sur 3 caractères (et j'espère pas 3 octets) peut être pour des question d'alignements (alignements alors réalisés de manière simpliste)
Wikipédia[2] fournit des abréviations qui me semblent meilleures qu'en pensez vous ?
Qu'elles sont très bien. Je suis pour. Et j'attire l'attention sur le problème de casse aussi.
Et je suis pour supprimer de GNOME toute traduction de mois/jour/truc stupide déjà dans la libc. strftime est normé. Si vous voyez ce genre de trucs, ouvrez systématiquement un bug. Genre http://bugzilla.gnome.org/show_bug.cgi?id=331760
Je ne sais pas ce qui ne va pas avec strftime (norme ANSI, C89), mais on a même droit à un g_date_strftime dans la glib ... il faut donc vraiment le faire exprès.
Je n'ai pas eu de réponse à mon premier courriel. Je me permets de poser la question à nouveau.
Quel est l'actuel mainteneur de la traduction de la glibc ? À défaut, avez-vous une piste pour le retrouver ?
Stéphane
Le 27/08/07, Stéphane Raimbaultstephane.raimbault@gmail.com a écrit :
Bonjour,
Je vous contacte car plusieurs utilisateurs m'ont adressé des remarques concernant la traduction des abréviations françaises utilisées pour les mois (ex. « aoû » pour « août »).
J'ai joint la copie d'écran que Daniel m'a envoyé, il lui semble qu'il manque un « t » à « aoû » et il n'est pas le premier à me signaler que la traduction des mois sous leur forme contractée est étrange.
Cette traduction est très importante car elle figure par défaut sur le bureau GNOME. La chaîne concernée ne fait pas partie de GNOME mais de la glibc[1], vous pouvez faire le test chez vous en compilant le code source joint (gcc month.c).
Wikipédia[2] fournit des abréviations qui me semblent meilleures qu'en pensez vous ?
J'ai appris que Michel Robitaille quittait son rôle de TP, Pierre Machard est-il son remplaçant ?
Cordialement, Stéphane
[1] http://www.gnu.org/software/libc/ [2] http://fr.wikipedia.org/wiki/Mois#Abr.C3.A9viations [3] http://sourceware.org/bugzilla/
Le Wednesday 23 January 2008 14:36:56 Stéphane Raimbault, vous avez écrit :
Je n'ai pas eu de réponse à mon premier courriel. Je me permets de poser la question à nouveau.
Quel est l'actuel mainteneur de la traduction de la glibc ? À défaut, avez-vous une piste pour le retrouver ?
fr.po de la glibc-2.7
msgid "" msgstr "" "Project-Id-Version: GNU libc 2.3.3\n" "POT-Creation-Date: 2004-08-05 09:16+0200\n" "PO-Revision-Date: 2004-08-05 12:00-0500\n" "Last-Translator: Michel Robitaille robitail@IRO.UMontreal.CA\n" "Language-Team: French traduc@traduc.org\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=ISO-8859-1\n" "Content-Transfer-Encoding: 8-bit\n" "Plural-Forms: nplurals=2; plural=(n > 1);\n"
Le 23/01/08, Alain PORTALaportal@univ-montp2.fr a écrit :
Le Wednesday 23 January 2008 14:36:56 Stéphane Raimbault, vous avez écrit:
Je n'ai pas eu de réponse à mon premier courriel. Je me permets de poser la question à nouveau.
Quel est l'actuel mainteneur de la traduction de la glibc ? À défaut, avez-vous une piste pour le retrouver ?
fr.po de la glibc-2.7
msgid "" msgstr "" "Project-Id-Version: GNU libc 2.3.3\n" "POT-Creation-Date: 2004-08-05 09:16+0200\n" "PO-Revision-Date: 2004-08-05 12:00-0500\n" "Last-Translator: Michel Robitaille robitail@IRO.UMontreal.CA\n" "Language-Team: French traduc@traduc.org\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=ISO-8859-1\n" "Content-Transfer-Encoding: 8-bit\n" "Plural-Forms: nplurals=2; plural=(n > 1);\n"
Cf mon premier message :
J'ai appris que Michel Robitaille quittait son rôle de TP, Pierre Machard est-il son remplaçant ?
Quel est l'actuel responsable ?
Bonjour, j'ai accepté d'être le coordinateur TP en remplacement de Pierre Machart.
glibc n'est pas un paquetage pris en compte par le TP (voir site français).
Cela est-il curieux, anormal,...scandaleux même !!!!!!
si je dois faire quelque chose, dites le moi.
Selon Stéphane Raimbault stephane.raimbault@gmail.com:
Le 23/01/08, Alain PORTALaportal@univ-montp2.fr a écrit :
Le Wednesday 23 January 2008 14:36:56 Stéphane Raimbault, vous avez écrit:
Je n'ai pas eu de réponse à mon premier courriel. Je me permets de poser la question à nouveau.
Quel est l'actuel mainteneur de la traduction de la glibc ? À défaut, avez-vous une piste pour le retrouver ?
fr.po de la glibc-2.7
msgid "" msgstr "" "Project-Id-Version: GNU libc 2.3.3\n" "POT-Creation-Date: 2004-08-05 09:16+0200\n" "PO-Revision-Date: 2004-08-05 12:00-0500\n" "Last-Translator: Michel Robitaille robitail@IRO.UMontreal.CA\n" "Language-Team: French traduc@traduc.org\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=ISO-8859-1\n" "Content-Transfer-Encoding: 8-bit\n" "Plural-Forms: nplurals=2; plural=(n > 1);\n"
Cf mon premier message :
J'ai appris que Michel Robitaille quittait son rôle de TP, Pierre Machard est-il son remplaçant ?Quel est l'actuel responsable ?
Liste de discussion Traduc Traduc@traduc.org http://www.traduc.org/mailman/listinfo/traduc [/!\ Les pièces-jointes doivent attendre l'approbation du modérateur.]
Le 24/01/08, ykerb2@free.frykerb2@free.fr a écrit :
Bonjour, j'ai accepté d'être le coordinateur TP en remplacement de Pierre Machart.
glibc n'est pas un paquetage pris en compte par le TP (voir site français).
Cela est-il curieux, anormal,...scandaleux même !!!!!!
Les trois à fois :) Une relecture complète de la traduction est nécessaire car elle contient de nombreuses erreurs, très souvent la casse des messages n'est pas respectée, il manque les espaces avant « : » et elle contient des typos :
#: sysdeps/unix/sysv/linux/lddlibc4.c:64 #, c-format msgid "cannot open `%s'" msgstr "Ne peut ouvrir « %s »"
#: locale/programs/charmap.c:356 locale/programs/charmap.c:373 #: locale/programs/repertoire.c:175 #, c-format msgid "syntax error in prolog: %s" msgstr "Erreur de syntaxe du prologue: %s"
#: iconv/iconvconfig.c:110 msgid "Create fastloading iconv module configuration file." msgstr "Craétion d'un module iconv de chargement rapide du fichier de configuration"
si je dois faire quelque chose, dites le moi.
Une relecture du fr.po ;)
Mon premier objectif est de corriger la traduction française des mois, jusqu'à ce jour, je savais que la trad était côté glibc (et pas GNOME) et maintenant grâce à strace et un bon moteur de recherche, je sais qu'elle est ici :
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/localedata/locales/fr_FR?cvsro...
et les mois sont décrits dans un format Unicode.
Je peux réaliser un patch mais je voudrais savoir à qui le soumettre pour qu'il soit relu et inclus.
Stéphane
Bonsoir,
est-ce que, par hasard, il ne s'agirait pas de ce paquet-ci :
http://translationproject.org/domain/libc.html
Très bonne soirée.
2008/1/24, Jean-Philippe Guérard jean-philippe.guerard@tigreraye.org:
Bonsoir,
est-ce que, par hasard, il ne s'agirait pas de ce paquet-ci :
http://translationproject.org/domain/libc.html
Très bonne soirée.
-- Jean-Philippe Guérard http://tigreraye.org
Au fil de la discussion, nous sommes venus à parler de 2 choses : 1 - la traduction des mois (http://sourceware.org/cgi-bin/cvsweb.cgi/libc/localedata/locales/fr_FR?cvsro...) 2 - la traduction de la glibc (http://translationproject.org/domain/libc.html)
La traduction des mois n'est pas accessible depuis le fr.po de la glibc (2e point).
ykerb2@free.fr (dont je ne connais pas le nom), tu peux utiliser n'importe quel outil d'édition de fichier PO pour effectuer ta traduction (poEdit, gtranslator, Emacs, etc), il te suffit d'ouvrir le fr.po.
Bonjour.
Selon les instructions du site "Traduc" pour les fichiers "po":
j'ai téléchargé le fichier depuis le lien suivant: http://translationproject.org/PO-files/fr/libc-2.7.fr.po
j'ai essayé avec l'éditeur Kwrite, puis kbabel.
Et j'ai un souci d'encodage. Dans Kwrite c'est paramétré avec "utf8" et de changer ce choix n'a aucun effet. Est-ce que cela vient du type de fichier "gettext"?
Dans Kbabel, je peux changer dans le menu "Projet" mais je trouve toujours des caractères ésotériques que ce soit en utf8 ou 8859-15.
où est l'erreur?
Merci.
Stéphane Raimbault a écrit :
2008/1/24, Jean-Philippe Guérard jean-philippe.guerard@tigreraye.org:
Bonsoir,
est-ce que, par hasard, il ne s'agirait pas de ce paquet-ci :
http://translationproject.org/domain/libc.html
Très bonne soirée.
-- Jean-Philippe Guérard http://tigreraye.org
Au fil de la discussion, nous sommes venus à parler de 2 choses : 1 - la traduction des mois (http://sourceware.org/cgi-bin/cvsweb.cgi/libc/localedata/locales/fr_FR?cvsro...) 2 - la traduction de la glibc (http://translationproject.org/domain/libc.html)
La traduction des mois n'est pas accessible depuis le fr.po de la glibc (2e point).
ykerb2@free.fr (dont je ne connais pas le nom), tu peux utiliser n'importe quel outil d'édition de fichier PO pour effectuer ta traduction (poEdit, gtranslator, Emacs, etc), il te suffit d'ouvrir le fr.po.
kerb a écrit :
Bonjour.
Selon les instructions du site "Traduc" pour les fichiers "po":
j'ai téléchargé le fichier depuis le lien suivant: http://translationproject.org/PO-files/fr/libc-2.7.fr.po
j'ai essayé avec l'éditeur Kwrite, puis kbabel.
Et j'ai un souci d'encodage. Dans Kwrite c'est paramétré avec "utf8" et de changer ce choix n'a aucun effet. Est-ce que cela vient du type de fichier "gettext"?
l'encodage est spécifié au début du fichier Là c'est du ISO-8859-1 (et firefox me détecte même du Windows-1252...)
Je suppose qu'il vaut mieux réencoder en UTF-8 Tu peux utiliser iconv pour ça. du style : iconv -f iso8859-1 -t utf-8 libc-2.7.fr.po > libc-2.7.fr.utf8.po
Dans Kbabel, je peux changer dans le menu "Projet" mais je trouve toujours des caractères ésotériques que ce soit en utf8 ou 8859-15.
où est l'erreur?
Merci.
Stéphane Raimbault a écrit :
2008/1/24, Jean-Philippe Guérard jean-philippe.guerard@tigreraye.org:
Bonsoir,
est-ce que, par hasard, il ne s'agirait pas de ce paquet-ci :
http://translationproject.org/domain/libc.html
Très bonne soirée.
-- Jean-Philippe Guérard http://tigreraye.org
Au fil de la discussion, nous sommes venus à parler de 2 choses : 1 - la traduction des mois (http://sourceware.org/cgi-bin/cvsweb.cgi/libc/localedata/locales/fr_FR?cvsro...) 2 - la traduction de la glibc (http://translationproject.org/domain/libc.html)
La traduction des mois n'est pas accessible depuis le fr.po de la glibc (2e point).
ykerb2@free.fr (dont je ne connais pas le nom), tu peux utiliser n'importe quel outil d'édition de fichier PO pour effectuer ta traduction (poEdit, gtranslator, Emacs, etc), il te suffit d'ouvrir le fr.po.
Liste de discussion Traduc Traduc@traduc.org http://www.traduc.org/mailman/listinfo/traduc [/!\ Les pièces-jointes doivent attendre l'approbation du modérateur.]
kerb écriva:
Et j'ai un souci d'encodage. Dans Kwrite c'est paramétré avec "utf8" et de changer ce choix n'a aucun effet. Est-ce que cela vient du type de fichier "gettext"?
Kwrite n'a aucune connaissance particulière des fichiers *.po. Il affiche tout dans l'encoding de ta locale, sans savoir que le fichier spécifie l'encodage dans son entête.
Christophe Combelles répondit:
Je suppose qu'il vaut mieux réencoder en UTF-8
Oui, c'est la meilleure chose qu'on puisse faire dans cette situation.
Tu peux utiliser iconv pour ça. du style : iconv -f iso8859-1 -t utf-8 libc-2.7.fr.po > libc-2.7.fr.utf8.po
Mais ATTENTION! Si tu fais ça, tu dois changer la spécification de l'encodage dans l'entête à la main. Sinon, ça donnera des "caractères ésotériques" pour tout le monde. Le programme «msgconv» le fait correctement: msgconv -t utf-8 libc-2.7.fr.po > libc-2.7.fr.utf8.po
Bruno
Bonjour,
j'interroge TP sur la question.
Sinon, en fevrier je pense avoir un peu de temps. Je pourrais peut-être relire (il faudra peut-être me donne qlq indications sur les outils à utiliser).
Selon Stéphane Raimbault stephane.raimbault@gmail.com:
Le 24/01/08, ykerb2@free.frykerb2@free.fr a écrit :
Bonjour, j'ai accepté d'être le coordinateur TP en remplacement de Pierre Machart.
glibc n'est pas un paquetage pris en compte par le TP (voir site français).
Cela est-il curieux, anormal,...scandaleux même !!!!!!
Les trois à fois :) Une relecture complète de la traduction est nécessaire car elle contient de nombreuses erreurs, très souvent la casse des messages n'est pas respectée, il manque les espaces avant « : » et elle contient des typos :
#: sysdeps/unix/sysv/linux/lddlibc4.c:64 #, c-format msgid "cannot open `%s'" msgstr "Ne peut ouvrir « %s »"
#: locale/programs/charmap.c:356 locale/programs/charmap.c:373 #: locale/programs/repertoire.c:175 #, c-format msgid "syntax error in prolog: %s" msgstr "Erreur de syntaxe du prologue: %s"
#: iconv/iconvconfig.c:110 msgid "Create fastloading iconv module configuration file." msgstr "Craétion d'un module iconv de chargement rapide du fichier de configuration"
si je dois faire quelque chose, dites le moi.
Une relecture du fr.po ;)
Mon premier objectif est de corriger la traduction française des mois, jusqu'à ce jour, je savais que la trad était côté glibc (et pas GNOME) et maintenant grâce à strace et un bon moteur de recherche, je sais qu'elle est ici :
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/localedata/locales/fr_FR?cvsro...
et les mois sont décrits dans un format Unicode.
Je peux réaliser un patch mais je voudrais savoir à qui le soumettre pour qu'il soit relu et inclus.
Stéphane
Bonjour,
j'ai terminé la traduction/relecture de 'libc'. J'ai copié ainsi qu'indiqué sur 'Traduc' avec la commande: cp libc-2.7.fr.mo /usr/share/locale/fr/LC_MESSAGES/
Quel est le moyen de tester? Bon j'imagine, utiliser 'libc' mais comment, faire une compil? de quoi?
Merci.
ykerb2@free.fr a écrit :
Bonjour,
j'interroge TP sur la question.
Sinon, en fevrier je pense avoir un peu de temps. Je pourrais peut-être relire (il faudra peut-être me donne qlq indications sur les outils à utiliser).
Selon Stéphane Raimbault stephane.raimbault@gmail.com:
Le 24/01/08, ykerb2@free.frykerb2@free.fr a écrit :
Bonjour, j'ai accepté d'être le coordinateur TP en remplacement de Pierre Machart.
glibc n'est pas un paquetage pris en compte par le TP (voir site français).
Cela est-il curieux, anormal,...scandaleux même !!!!!!
Les trois à fois :) Une relecture complète de la traduction est nécessaire car elle contient de nombreuses erreurs, très souvent la casse des messages n'est pas respectée, il manque les espaces avant « : » et elle contient des typos :
#: sysdeps/unix/sysv/linux/lddlibc4.c:64 #, c-format msgid "cannot open `%s'" msgstr "Ne peut ouvrir « %s »"
#: locale/programs/charmap.c:356 locale/programs/charmap.c:373 #: locale/programs/repertoire.c:175 #, c-format msgid "syntax error in prolog: %s" msgstr "Erreur de syntaxe du prologue: %s"
#: iconv/iconvconfig.c:110 msgid "Create fastloading iconv module configuration file." msgstr "Craétion d'un module iconv de chargement rapide du fichier de configuration"
si je dois faire quelque chose, dites le moi.
Une relecture du fr.po ;)
Mon premier objectif est de corriger la traduction française des mois, jusqu'à ce jour, je savais que la trad était côté glibc (et pas GNOME) et maintenant grâce à strace et un bon moteur de recherche, je sais qu'elle est ici :
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/localedata/locales/fr_FR?cvsro...
et les mois sont décrits dans un format Unicode.
Je peux réaliser un patch mais je voudrais savoir à qui le soumettre pour qu'il soit relu et inclus.
Stéphane
Revenons à nos moutons concernant la traduction des mois dans la libc : http://sourceware.org/cgi-bin/cvsweb.cgi/libc/localedata/locales/fr_FR?cvsro...
Le 27/08/07, Stéphane Raimbaultstephane.raimbault@gmail.com a écrit :
Bonjour,
Je vous contacte car plusieurs utilisateurs m'ont adressé des remarques concernant la traduction des abréviations françaises utilisées pour les mois (ex. « aoû » pour « août »).
Pour tester la traduction actuelle, j'ai écrit un tout petit programme nommé month.c que vous pouvez compiler par un simple $ gcc month.c et lancé par ./a.out Il affiche ceci : Result string is "jan" Result string is "fév" Result string is "mar" Result string is "avr" Result string is "mai" Result string is "jun" Result string is "jui" Result string is "aoû" Result string is "sep" Result string is "oct" Result string is "nov" Result string is "déc"
Nous avons plusieurs solutions d'abréviations proposées par le lien suivant :
janv. févr. mars avr. mai juin juil. août sept. oct. nov. déc.
Cette nouvelle traduction a un inconvénient, les chaînes n'auront pas toutes la même longueur. Faut-il ajouter le point (abréviations en français) dans la traduction de la glibc et auquel cas, faire de même pour les abréviations des jours ?
Ciao, Stéphane
Bonjour,
j'ai jeté un coup d'oeil aux chaînes à la page http://translationproject.org/PO-files/fr/libc-2.7.fr.po
Je ne connais en rien "libc", mais je pense que les trad ci-dessous ne sont pas juste. Je verrais plutôt "numéro de message en double".
#: catgets/gencat.c:621 msgid "duplicated message number" msgstr "Double messages du numéro"
#: catgets/gencat.c:674 msgid "duplicated message identifier" msgstr "Double identificateurs de message"
Stéphane Raimbault a écrit :
Revenons à nos moutons concernant la traduction des mois dans la libc : http://sourceware.org/cgi-bin/cvsweb.cgi/libc/localedata/locales/fr_FR?cvsro...
Le 27/08/07, Stéphane Raimbaultstephane.raimbault@gmail.com a écrit :
Bonjour,
Je vous contacte car plusieurs utilisateurs m'ont adressé des remarques concernant la traduction des abréviations françaises utilisées pour les mois (ex. « aoû » pour « août »).
Pour tester la traduction actuelle, j'ai écrit un tout petit programme nommé month.c que vous pouvez compiler par un simple $ gcc month.c et lancé par ./a.out Il affiche ceci : Result string is "jan" Result string is "fév" Result string is "mar" Result string is "avr" Result string is "mai" Result string is "jun" Result string is "jui" Result string is "aoû" Result string is "sep" Result string is "oct" Result string is "nov" Result string is "déc"
Nous avons plusieurs solutions d'abréviations proposées par le lien suivant :
janv. févr. mars avr. mai juin juil. août sept. oct. nov. déc.
Cette nouvelle traduction a un inconvénient, les chaînes n'auront pas toutes la même longueur. Faut-il ajouter le point (abréviations en français) dans la traduction de la glibc et auquel cas, faire de même pour les abréviations des jours ?
Ciao, Stéphane
Liste de discussion Traduc Traduc@traduc.org http://www.traduc.org/mailman/listinfo/traduc [/!\ Les pièces-jointes doivent attendre l'approbation du modérateur.]
Le 2008-01-26 14:38:59 +0100, Stéphane Raimbault écrivait :
Revenons à nos moutons concernant la traduction des mois dans la libc : http://sourceware.org/cgi-bin/cvsweb.cgi/libc/localedata/locales/fr_FR?cvsro...
Le 27/08/07, Stéphane Raimbaultstephane.raimbault@gmail.com a écrit :
Bonjour,
Je vous contacte car plusieurs utilisateurs m'ont adressé des remarques concernant la traduction des abréviations françaises utilisées pour les mois (ex. « aoû » pour « août »).
Pour tester la traduction actuelle, j'ai écrit un tout petit programme nommé month.c que vous pouvez compiler par un simple $ gcc month.c et lancé par ./a.out Il affiche ceci : Result string is "jan" Result string is "fév" Result string is "mar" Result string is "avr" Result string is "mai" Result string is "jun" Result string is "jui" Result string is "aoû" Result string is "sep" Result string is "oct" Result string is "nov" Result string is "déc"
Nous avons plusieurs solutions d'abréviations proposées par le lien suivant :
janv. févr. mars avr. mai juin juil. août sept. oct. nov. déc.
Cette nouvelle traduction a un inconvénient, les chaînes n'auront pas toutes la même longueur. Faut-il ajouter le point (abréviations en français) dans la traduction de la glibc et auquel cas, faire de même pour les abréviations des jours ?
Le mieux serait effectivement de mettre à jour la définition des locales de la libc pour obtenir des abréviations françaises correctes (y compris les points abréviatifs).
Très bonne fin de semaine.
Bonjour, au risque de poser des questions qui paraissent triviales:
Q1: est il obligé/conseillé d'utiliser des abréviations?
Q2: si oui, existe t-il une contrainte sur la longueur comme par exemple 3 caractères max (auquel cas "mai" est bon, pas "jui.")?
Q3: qd TP affiche 1132/1326, cela signifie t-il que 294 chaînes ne sont pas traduites sur la page http://translationproject.org/PO-files/fr/libc-2.7.fr.po ?
Ces questions pcq j'envisage de reprendre cette trad, notament d'évaluer la charge.
Merci.
Jean-Philippe Guérard a écrit :
Le 2008-01-26 14:38:59 +0100, Stéphane Raimbault écrivait :
Revenons à nos moutons concernant la traduction des mois dans la libc : http://sourceware.org/cgi-bin/cvsweb.cgi/libc/localedata/locales/fr_FR?cvsro...
Le 27/08/07, Stéphane Raimbaultstephane.raimbault@gmail.com a écrit :
Bonjour,
Je vous contacte car plusieurs utilisateurs m'ont adressé des remarques concernant la traduction des abréviations françaises utilisées pour les mois (ex. « aoû » pour « août »).
Pour tester la traduction actuelle, j'ai écrit un tout petit programme nommé month.c que vous pouvez compiler par un simple $ gcc month.c et lancé par ./a.out Il affiche ceci : Result string is "jan" Result string is "fév" Result string is "mar" Result string is "avr" Result string is "mai" Result string is "jun" Result string is "jui" Result string is "aoû" Result string is "sep" Result string is "oct" Result string is "nov" Result string is "déc"
Nous avons plusieurs solutions d'abréviations proposées par le lien suivant :
janv. févr. mars avr. mai juin juil. août sept. oct. nov. déc.
Cette nouvelle traduction a un inconvénient, les chaînes n'auront pas toutes la même longueur. Faut-il ajouter le point (abréviations en français) dans la traduction de la glibc et auquel cas, faire de même pour les abréviations des jours ?
Le mieux serait effectivement de mettre à jour la définition des locales de la libc pour obtenir des abréviations françaises correctes (y compris les points abréviatifs).
Très bonne fin de semaine.
Bonjour,
Le 2008-01-27 12:40:58 +0100, kerb écrivait :
Bonjour, au risque de poser des questions qui paraissent triviales:
Q1: est il obligé/conseillé d'utiliser des abréviations?
En général, sauf problème de place, l'emploi des abréviations est déconseillé.
Q2: si oui, existe t-il une contrainte sur la longueur comme par exemple 3 caractères max (auquel cas "mai" est bon, pas "jui.")?
Il existe peut-être une contrainte dans la libc, mais, honnêtement, je ne vois aucune raison valable de se limiter à des abréviations de 3 lettres.
Il n'y a que les développeurs de la libc qui pourront le dire. Cela dit, si c'est le cas, cela serait plutôt un défaut de la libc qu'autre chose.
Q3: qd TP affiche 1132/1326, cela signifie t-il que 294 chaînes ne sont pas traduites sur la page http://translationproject.org/PO-files/fr/libc-2.7.fr.po ?
Oui, les chaînes manquants sont soit non traduites, soit ont une traduction approximative (gettext a repris la traduction d'une chaîne qui ressemblait vaguement en espérant que ça collera).
Ces questions pcq j'envisage de reprendre cette trad, notament d'évaluer la charge.
Attention, en reprenant une traduction, il peut être utilise de passer en revue les chaînes déjà traduites, pour s'assurer qu'elles sont toutes correctes.
Très bon dimanche !
Jean-Philippe
Le 27/01/08, Jean-Philippe Guérardjean-philippe.guerard@tigreraye.org a écrit :
Bonjour,
Le 2008-01-27 12:40:58 +0100, kerb écrivait :
Bonjour, au risque de poser des questions qui paraissent triviales:
Q1: est il obligé/conseillé d'utiliser des abréviations?
En général, sauf problème de place, l'emploi des abréviations est déconseillé.
Je suis d'accord avec Jean-Philippe mais dans le cas présent, les abréviations sont obligatoires car c'est la différence entre : strftime(outstr, sizeof(outstr), "%b", ... et strftime(outstr, sizeof(outstr), "%B", qui donne respectivement : jan et janvier.
Q2: si oui, existe t-il une contrainte sur la longueur comme par exemple 3 caractères max (auquel cas "mai" est bon, pas "jui.")?
Il existe peut-être une contrainte dans la libc, mais, honnêtement, je ne vois aucune raison valable de se limiter à des abréviations de 3 lettres.
Il n'y a que les développeurs de la libc qui pourront le dire. Cela dit, si c'est le cas, cela serait plutôt un défaut de la libc qu'autre chose.
Je n'ai vu aucune contrainte à ce sujet dans les commentaires de libc et un petit grep sur abmon permet de constater que la longueur varie entre 2 et 4 caractères suivant les langues. Je vais poser la question aux dév. de la glibc pour être sûr.
Le dimanche 27 janvier 2008 à 12:40 +0100, kerb a écrit :
Bonjour, au risque de poser des questions qui paraissent triviales:
Q1: est il obligé/conseillé d'utiliser des abréviations?
Q2: si oui, existe t-il une contrainte sur la longueur comme par exemple 3 caractères max (auquel cas "mai" est bon, pas "jui.")?
Q3: qd TP affiche 1132/1326, cela signifie t-il que 294 chaînes ne sont pas traduites sur la page http://translationproject.org/PO-files/fr/libc-2.7.fr.po ?
Ces questions pcq j'envisage de reprendre cette trad, notament d'évaluer la charge.
Il me parait extrêmement important que les abréviations des mois ne soit pas modifiés et reste limité à 3 caractères.
Que ce soit en mode console ou en mode graphique, il me parait très important que lorsque des dates abrégés sont affichées en colonne elle soient parfaitement alignées. Dans la mesure ou le mois le plus court fait 3 caractères (mai), les autres abréviations doivent s'aligner. Vouloir rendre les abréviations identique à un tableau présent dans Wikipedia ne me semble pas pertinent ou une raison suffisante pour bouleverser les millions de scripts s'appuyant sur les abréviations existantes.
Librement,
Le 27/01/08, Christophe Merlet (RedFox)redfox@redfoxcenter.org a écrit :
Vouloir rendre les abréviations identique à un tableau présent dans Wikipedia ne me semble pas pertinent ou une raison suffisante pour bouleverser les millions de scripts s'appuyant sur les abréviations existantes.
Aucun programmeur (digne de ce nom) n'irait écrire un script basé sur des abréviations traduites (un script doit avoir un comportement identique suivant la localisation en cours qui est souvent l'anglais par défaut LC_ALL="") et de plus, les abréviations ne sont pas manipulables, c'est pourquoi les programmes utilisent toujours les chiffres associés au mois.
Le dimanche 27 janvier 2008 à 14:35 +0100, Stéphane Raimbault a écrit :
Le 27/01/08, Christophe Merlet (RedFox)redfox@redfoxcenter.org a écrit :
Vouloir rendre les abréviations identique à un tableau présent dans Wikipedia ne me semble pas pertinent ou une raison suffisante pour bouleverser les millions de scripts s'appuyant sur les abréviations existantes.
Aucun programmeur (digne de ce nom) n'irait écrire un script basé sur des abréviations traduites (un script doit avoir un comportement identique suivant la localisation en cours qui est souvent l'anglais par défaut LC_ALL="") et de plus, les abréviations ne sont pas manipulables, c'est pourquoi les programmes utilisent toujours les chiffres associés au mois.
Par expérience j'ai vu que le LC_ALL n'est pas utilisé sur des programme aussi important que le compilateur Fortran Portland il y a a peine quelques mois foirant l'installation. Cette erreur est tout juste corrigé.
Tous programme "digne de ce nom" devrait utiliser LC_ALL. Mais ne pas l'utiliser n'est pas un bug pour autant, mais un manque de portabilité...
Et je n'ose imaginer le nombre de script maison qui ne s'embarrasse pas d'initialiser LC_ALL dont le comportement serait préjudiciablement altéré avec une modification cosmétique de ce genre. Scripts de sauvegarde, d'extraction, ...
Linux n'est pas utilisé que par des Guru dans des grosses boîtes où le moindre scripts est relu par des équipes de 15 personnes, mais aussi par des petites PME/PMI dont le parc informatique est infogéré par des petites SSII de campagne. Les données manipulées par ces scripts n'en sont pas moins importantes.
Librement,
Hello, voilà mon avis sur ces questions
Stéphane Raimbault a écrit :
Result string is "jan" Result string is "fév" Result string is "mar" Result string is "avr" Result string is "mai" Result string is "jun" Result string is "jui" Result string is "aoû" Result string is "sep" Result string is "oct" Result string is "nov" Result string is "déc"
La traduction actuelle n'est clairement pas bonne. Surtout "mar", "aoû", "jun" et "jui". En plus dans une abréviation l'usage est au moins de mettre un point...
J'en profite pour avertir que toutes les traductions qui étaient maintenues par Michel (et il y en a beaucoup) doivent au minimum être relues entièrement, au mieux retraduites complètement, même si elles sont actuellement à 100%... J'ai commencé à m'atteler à la tâche, après gettext et tar, j'en suis à bash, mais ça va prendre des années. Il y a vraiment du boulot.
Nous avons plusieurs solutions d'abréviations proposées par le lien suivant :
janv. févr. mars avr. mai juin juil. août sept. oct. nov. déc.
Les abréviations de la wikipedia me paraissent déjà beaucoup mieux mais je suis d'accord avec Christophe pour le "avr.", donc je mettrais :
janv. févr. mars avril mai juin juil. août sept. oct. nov. déc.
Pour l'alignement et le nombre de caractères, je pense vraiment qu'il n'y a aucune contrainte, il s'agit uniquement d'affichage. AUCUN programme ni programmeur ne doit s'attendre à un nombre de caractère fixe, ni même stable dans le temps. Un mois doit être vérifié par son numéro, et l'alignement se fait avec une tabulation \t. Si le fonctionnement d'un programme dépend de la traduction de l'abréviation des mois, c'est un programme bogué à mort, et je suis sûr qu'il sera cassé pour mille autres raisons avant le changement de traduction de la glibc.
Christophe
Cette nouvelle traduction a un inconvénient, les chaînes n'auront pas toutes la même longueur. Faut-il ajouter le point (abréviations en français) dans la traduction de la glibc et auquel cas, faire de même pour les abréviations des jours ?
Ciao, Stéphane
Liste de discussion Traduc Traduc@traduc.org http://www.traduc.org/mailman/listinfo/traduc [/!\ Les pièces-jointes doivent attendre l'approbation du modérateur.]
Le dimanche 27 janvier 2008 à 22:57 +0100, Christophe Combelles a écrit :
Hello, voilà mon avis sur ces questions
Stéphane Raimbault a écrit :
Result string is "jan" Result string is "fév" Result string is "mar" Result string is "avr" Result string is "mai" Result string is "jun" Result string is "jui" Result string is "aoû" Result string is "sep" Result string is "oct" Result string is "nov" Result string is "déc"
La traduction actuelle n'est clairement pas bonne. Surtout "mar", "aoû", "jun" et "jui". En plus dans une abréviation l'usage est au moins de mettre un point...
Ce que vous semblez avoir du mal à comprendre c'est que la traduction de logiciel, surtout ceux de très bas niveau n'est pas qu'une question de pureté linguistique mais aussi et surtout de norme et de contrainte industrielle.
La GLibc respecte des normes, plein de normes... FIPS, POSIX90, XPG3, XPG4, POSIX96, UNIX98, ISO/IEC 9899:1990, ...
Les Locales sont et doivent être conforme à la norme ISO/IEC TR 14652:2002. L'affichage numérique des dates est normalisé ISO 8601 et NF EN 28601.
Ces normes sont utilisé industriellement pour, par exemple, les étiquetage. Il est des domaines ou les étiquetage doivent être OBLIGATOIREMENT localisé.
Depuis la nuit des temps informatique, les abréviations de jour et de mois sont composés de 3 caractères *exactement* à cause de contrainte de production.
Si vous tenez absolument à ce que GNOME affiche des jolis mois abrégés pour les applets du bureau, faites un rapports d'anomalies et demandez a avoir une troisième catégorie de noms abrégés "linguist compliant".
J'en profite pour avertir que toutes les traductions qui étaient maintenues par Michel (et il y en a beaucoup) doivent au minimum être relues entièrement, au mieux retraduites complètement, même si elles sont actuellement à 100%... J'ai commencé à m'atteler à la tâche, après gettext et tar, j'en suis à bash, mais ça va prendre des années. Il y a vraiment du boulot.
Et un dénigrement du précédent traducteur... Classe !
Librement,
Christophe Merlet (RedFox) a écrit :
Le dimanche 27 janvier 2008 à 22:57 +0100, Christophe Combelles a écrit :
Hello, voilà mon avis sur ces questions
Stéphane Raimbault a écrit :
Result string is "jan" Result string is "fév" Result string is "mar" Result string is "avr" Result string is "mai" Result string is "jun" Result string is "jui" Result string is "aoû" Result string is "sep" Result string is "oct" Result string is "nov" Result string is "déc"
La traduction actuelle n'est clairement pas bonne. Surtout "mar", "aoû", "jun" et "jui". En plus dans une abréviation l'usage est au moins de mettre un point...
Ce que vous semblez avoir du mal à comprendre c'est que la traduction de logiciel, surtout ceux de très bas niveau n'est pas qu'une question de pureté linguistique mais aussi et surtout de norme et de contrainte industrielle.
La GLibc respecte des normes, plein de normes... FIPS, POSIX90, XPG3, XPG4, POSIX96, UNIX98, ISO/IEC 9899:1990, ...
Les Locales sont et doivent être conforme à la norme ISO/IEC TR 14652:2002. L'affichage numérique des dates est normalisé ISO 8601 et NF EN 28601.
Si ce genre de normes dépendent d'un fichier po, il y a un problème encore plus grave. Si la norme définit quelque part que le mois abrégé doit vraiment faire 3 caractères (ce que je n'ai pas trouvé, mais j'ai cherché juste 5 min, faudrait confirmer), c'est au code de respecter la norme et de couper la traduction à 3 caractères, et pas aux traducteurs de se poser ce genre de question. Dans ce cas il faut rapporter un bug tout de suite pour la glibc.
Ces normes sont utilisé industriellement pour, par exemple, les étiquetage. Il est des domaines ou les étiquetage doivent être OBLIGATOIREMENT localisé.
Depuis la nuit des temps informatique, les abréviations de jour et de mois sont composés de 3 caractères *exactement* à cause de contrainte de production.
Si vous tenez absolument à ce que GNOME affiche des jolis mois abrégés pour les applets du bureau, faites un rapports d'anomalies et demandez a avoir une troisième catégorie de noms abrégés "linguist compliant".
Toujours pas d'accord. Là on n'est ni sur une liste de développeurs, ni de norme industrielle. On est sur un canal "linguist compliant" et on fait un boulot "linguist compliant". Je répète que s'il y a une norme qui définit précisément les mois abrégés, ceux-ci doivent être écrits en dur dans le code de la libc. Sinon c'est un bug. Ou alors le strict minimum serait d'avoir une indication précise sous forme de commentaire extrait à destination des traducteurs. Mais ça me parait limite.
J'en profite pour avertir que toutes les traductions qui étaient maintenues par Michel (et il y en a beaucoup) doivent au minimum être relues entièrement, au mieux retraduites complètement, même si elles sont actuellement à 100%... J'ai commencé à m'atteler à la tâche, après gettext et tar, j'en suis à bash, mais ça va prendre des années. Il y a vraiment du boulot.
Et un dénigrement du précédent traducteur... Classe !
Il faut connaître l'historique. Le précédent traducteur en question était "responsable" de dizaines de trads, qu'il n'a manifestement jamais faites relire à personne. Et pour cause, quand j'ai voulu en améliorer une, il n'a rien accepté et m'a envoyé ballader (!!). Il a fallu deux ans et demi pour que la trad améliorée soit finalement acceptée (il s'agit de gettext). Cela dit, je respecte complètement et j'admire la *quantité* de travail qu'il a fourni. Respecter ne veut pas dire qu'on doit tout laisser dans l'état et fermer les yeux. Donner son nom est surtout un moyen de retrouver facilement les traductions sur lesquelles il faut bosser (en dehors de celles qui sont à 0%). Sinon elles vont rester encore longtemps dans cet état et c'est dommage pour tout le monde.
Librement,
Liste de discussion Traduc Traduc@traduc.org http://www.traduc.org/mailman/listinfo/traduc [/!\ Les pièces-jointes doivent attendre l'approbation du modérateur.]
Le 27/01/08, Christophe Combellesccomb@free.fr a écrit :
Les abréviations de la wikipedia me paraissent déjà beaucoup mieux
mais je suis
d'accord avec Christophe pour le "avr.", donc je mettrais :
janv. févr. mars avril mai juin juil. août sept. oct. nov. déc.
Bonjour,
J'ai effectué les changements concernant les abréviations dans la glibc. J'ai joint le fichier source (fr_FR), si vous souhaitez tester la nouvelle traduction, télécharger le tarball de glibc (2.7 p. ex.) : cp glibc-fr_FR-LC_TIME /yourpath/glibc-2.7/localedata/locales/fr_FR localedef -i fr_FR -f UTF-8 ./build sudo cp ./build/LC_TIME /usr/lib/locale/fr_FR.utf8/LC_TIME
Évidemment, les applis en cours ne vont pas aimer le chgt des abréviations à la volée !
Affichage des abréviations des mois en français : janv. févr. mars avril mai juin juil. août sept. oct. nov. déc.
J'ai aussi ajouté un point aux abréviations utilisées pour les jours de la semaine.
Stéphane
PS : si le calendrier utilisait L M M J V S D, il serait plus joli (IMHO).
Le 14/02/08, Stéphane Raimbaultstephane.raimbault@gmail.com a écrit :
Le 27/01/08, Christophe Combellesccomb@free.fr a écrit :
Les abréviations de la wikipedia me paraissent déjà beaucoup mieux
mais je suis
d'accord avec Christophe pour le "avr.", donc je mettrais :
janv. févr. mars avril mai juin juil. août sept. oct. nov. déc.
Bonjour,
J'ai effectué les changements concernant les abréviations dans la glibc. J'ai joint le fichier source (fr_FR), si vous souhaitez tester la nouvelle traduction, télécharger le tarball de glibc (2.7 p. ex.) : cp glibc-fr_FR-LC_TIME /yourpath/glibc-2.7/localedata/locales/fr_FR localedef -i fr_FR -f UTF-8 ./build sudo cp ./build/LC_TIME /usr/lib/locale/fr_FR.utf8/LC_TIME
Évidemment, les applis en cours ne vont pas aimer le chgt des abréviations à la volée !
Affichage des abréviations des mois en français :
janv. févr. mars avril mai juin juil. août sept. oct. nov. déc.
Pour informations, j'ai remarqué que Google Calendar et le Zend Framework utilisaient les mêmes abréviations sauf exception pour le mois d'avril.
<br/> dim. janv. mer. févr. mer. mars sam. avr. lun. mai jeu. juin sam. juil. mar. août ven. sept. dim. oct. mer. nov. ven. déc. </body>
Je pense que ce changement dans la glibc va dans le bon sens même si je suis indécis pour le mois d'avril.
J'aimerais que nous ne tardions pas à inclure la modification dans la glibc, quels sont vos avis ?
Stéphane Raimbault a écrit :
Pour informations, j'ai remarqué que Google Calendar et le Zend Framework utilisaient les mêmes abréviations sauf exception pour le mois d'avril.
<br/> dim. janv. mer. févr. mer. mars sam. avr. lun. mai jeu. juin sam. juil. mar. août ven. sept. dim. oct. mer. nov. ven. déc. </body>
Je pense que ce changement dans la glibc va dans le bon sens même si je suis indécis pour le mois d'avril.
J'aimerais que nous ne tardions pas à inclure la modification dans la glibc, quels sont vos avis ?
salut
'avr.' ne me dérange pas, même si je préfère légèrement 'avril' car la différence de longueur n'est que d'une lettre, le 'l', et ça ne rallonge quasiment pas. Dans tous les cas c'est déjà un bonne amélioration !
Christophe
-
Alain PORTAL -
Benoît Dejean -
Bruno Haible -
Christophe Combelles -
Christophe Merlet (RedFox) -
Jean-Philippe Guérard -
kerb -
Stéphane Raimbault -
ykerb2＠free.fr