Martin Quinson wrote:
Je suis assez d'accord, mais j'ai un bemol : on a des pages chez Debian, qui ont le look 'page Debian' classique, et on a pas le gout d'en faire 15 sortes...
Si les données statistiques sont dans une base de données, cela permets à chaque équipe de traduction de gérer le look de ses pages web comme il l'entends.
Je suppose que c'est pareil pour tous les projets. En regroupant tout ce qui parle de trad, on disperse ce qui parle de Debian. C'est inévitable.
Pas forcement, quand je parle de l'état des traductions GNOME, je pense à l'état du CVS GNOME à l'instant t. Dans Debian parle de l'état des traductions, c'est de l'état des paquet qu'elle distribue (y compris la description des paquets). Ce sont deux traductions différentes, même si elles sont similaires. Je ne pense pas que cela disperse le travail de l'équipe Debian à partir du moment ou les traductions sont différenciées.
Je suis *vraiment* d'accord avec ce souhait d'universalité du format po.
Je ne pense pas que le format po soit bien adapté à de la documentation, c.a.d. des phrases/textes faisant plus de 10 lignes.
Ben alors ? On est plus d'accord, là. Moi, je pense qu'il faut convertir le XML en po, traduire le po, puis réinjecter le texte dans le XML. Dans ce cas, on peut oublier ces histoires de xmldiff, c'est déja fait par gettext lors de la création des po...
Je suis d'accord avec Mt. Le _vrai_ format de fichier de traduction est le format .po. XML ne doit être au mieux qu'un format intermédiaire.
Oui. gettext rules. Voila pour la famille d'outils. Ensuite, pour l'extraction/la remise en place des chaines à traduire, les gens de KDE ont ca, meme s'il me semble qu'on devrait pouvoir améliorer un peu.
Le projet GNOME utilise intl-tools (ex xml-i18n-tools) pour l'extraction/insertion de chaînes dans tout les types de fichiers d'un paquet contenant des chaînes à traduire et ça marche plutôt bien.
Dans mes reves les plus fous, on aurait des moulinettes pour extraire dans des fichiers po tous les formats existants, afin que les traducteurs et relecteurs puissent faire leur boulot sans se soucier de savoir si c'est un livre, les messages d'un programme, la page man, des fichiers debconf, la description d'un paquet ou dieu sait quoi.
Je me répète, le format po pour de la documentation de ma parait pas du tout adapté.
Ensuite, on utiliserait tous des robots comme celui du projet de traduction GNU. Voire ce robot la exactement, lui meme. Je ne parle pas de cette instance la, mais de ce programme la. Ie, de la meme facon qu'il existe des floppées de bugzilla sur terre, il pourrait y avoir des floppées de TP-Robot.
Ce robot gererait qui traduit quoi, relancerait les traducteurs quand qqch change, demanderait leur avis à quelques relecteurs triés sur le volet avant d'accepter quoi que ce soit, ferait de belles pages webs de statistiques, et ainsi de suite. La vie serait belle, et les coordinateurs pourraient aller dormir (ce que je fais maintenant ;).
Par contre, un robot pour surveiller les changements dans les fichiers de traduction et tenir informer les coordinateurs/traducteurs/relecteurs ça me plait.
Je suis d'accord, car je suis marié à Lyon, alors c'est meme pas la peine de me parler de bouffe à Paris...
M'en fous, j'ai au moins deux espions dans la place : Denis et RedFox... ;)
Je ne suis pas sûr de bien comprendre ta phrase :-/ Je n'était pas à ce repas. Et il y a peu de chance que je participe à un des ces bouffes. J'habites à Pau dans le Sud-Sud-Ouest, c'est encore plus loin que Lyon...