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,