Quoting David Prévot (david@tilapin.org): > En revanche pour éviter que ce genre de programme tombe sous notre > radar, il serait sans doute cohérent de demander au responsable du > paquet de ne pas l'empaqueter comme un paquet natif Debian si ce n'en > est pas un. Pas simple. Si le paquet n'a pas d'upstream, il est logique qu'il soit natif. Et qu'il le soit autant dans Ubuntu que dans Debian. Là, je pense qu'on a un problème sans solution parfaite. C'est l'existence de deux équipes de traduction parallèles qui ets à gérer (loin de moi l'idée de suggérer qu'il ne doit pas y avoir deux équipes parallèles, les outils et méthodes sont trop différents). Pour un paquet natif, difficile de savoir s'il a pour origine Debian ou Ubuntu. Le plus souvent, l'origine est dans Debian, donc je pense que maintenir notre radar sur tous les paquets natifs est une bonne idée. > Sans doute, mais les paquets non-natifs n'ont aucune raison de tomber > sous notre radar (sauf erreur de notre part comme cela a été le cas avec > exaile, mais le problème est réglé). Par commodité, des en-têtes de > fichiers PO à jour permettent de contacter les traducteurs et équipes en > charge, merci d'y veiller, ce n'est pas le cas dans les quatres exemples > précédents. Ça c'est sûr qu'un champ Language-Team à jour, ça aiderait. Par contre, je ne suis pas sûr que Launchpad/Rosetta permette cela. Ces outils ont malheureusement la vilaine habitude de faire des choses pas catholiques avec les fichiers PO, notamment au niveau des en-têtes....
Attachment:
signature.asc
Description: Digital signature