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.]