Bonjour,
Une première chose à faire serait de mettre les listes en "réponse à la liste" et non pas à l'auteur :)
On 21 déc. 09, at 00:23, Jean-Philippe MENGUAL wrote:
D'ici là, toutes les idées sont d'ailleurs bienvenues. N'hésitez pas à nous faire part de toutes vos idées autour de l'avenir de Traduc.org: quels projets devraient être maintenus? lesquels pourraient être abandonnés? Doit-on traduire toujours des documents ou élargir (à des applications? livres)? Y'a-t-il des projets non traduits qui devraient l'être? De quelle façon communiquer (présence dans des salons? diffusion sur le Web...)?
10 membres au CA, 17 membres au total, quelques collaborateurs non membres (quel est l'état de la liste orga ?) Une centaine d'abonnés à cette liste.
1) il faut faire en sorte que le côté association de Traduc soit plus visible. 2) un outil commun utilisé par plusieurs communautés est le glossaire, il faudrait rendre sa maintenance plus facile (ça a été suggéré sur la liste de localisation OOo) 3) on pourrait créer un dépôt de traductions de référence sous les formats les plus utilisés (compendium PO, fichiers TMX) 4) on pourrait documenter les outils libres (en ligne/hors ligne) qui peuvent aider les traducteurs 5) on pourrait aussi indiquer les communautés de traduction/localisation qui existent
En bref, maintenant que le travail de localisation du libre est relativement connu, faire de Traduc un centre d'information à ce sujet peut aussi être une vocation.
On parle beaucoup des pages man, et j'ai réalisé à mon grand regret que les pages des BSDs était pour beaucoup fort différentes des pages Linux et que (à moins d'avoir été trompé par le web) elles ne semblent pas exister en français (ou en tout cas ne sont pas si accessibles que celles de Linux). La situation est la même pour Darwin.
En utilisant les compendium PO pour Linux, il devrait être relativement rapide d'organiser la traduction de pages man d'autres systèmes.
La mise en place d'un serveur Pootle pour certains projets (de localisation en particulier) permettrait plus de participation, et en tout cas une participation plus aisée.
Je suis particulièrement sensible au projet de traduction emacs. J'essaye d'utiliser Aquamacs Emacs sur OSX le plus souvent possible. Il y a quelques années j'avais demandé des précisions techniques sur les problèmes relatifs à la localisation de emacs lui même sur la liste emacs-dev, on m'avait plus ou moins fait entendre que ce n'étais pas une priorité parce que un "programmeur qui se respecte doit connaitre l'anglais"... Mais avec ma petite expérience de Scheme (ou une série de "define" permet de "localiser" le langage dans son intégralité) m'avais suggéré que faire une localisation totale de emacs, y compris le nom des commandes n'était pas une idée complètement vaine.
Au sujet de la documentation en général (quel que soit le niveau visé), il faut envisager des procédés qui permettent de travailler plus facilement. J'utilise OmegaT (Java/GPL) au quotidien et l'application est désormais capable de rendre service à beaucoup de traducteurs du monde du libre. C'est le cas dans la communauté OOo/NetBeans/OpenSolaris et dans d'autres que je connais moins.
Voilà, ce sont 2-3 idées lancées et j'espère pouvoir me réveiller pour le prochain CA...
Jean-Christophe Helary --------------------------------- fun: mac4translators.blogspot.com work: www.doublet.jp (ja/en > fr) tweets: @brandelune