On dimanche 26 avr. 09, at 06:41, Bruno Haible wrote:
Je ne veux pas vous décourager, mais je pense qu'uniquement les deux premiers chapitres de ce manuel sont prioritaires pour une traduction.
Pourquoi? Parce que ce manuel s'adresse à trois types d'utilisateurs:
- utilisateurs du programme internationalisé,
- traducteurs,
- programmeurs/développeurs.
Les traducteurs forcément connaissent l'Anglais. La grande majorité des développeurs aussi. Le vrai besoin est donc présent pour les utilisateurs des programmes internationalisés, et uniquement les deux premiers chapitres de la doc s'adresse à eux.
Je me permet d'intervenir même si ce n'est pas vraiment le sujet de la question:
Est-il possible d'envisager un gettext qui fonctionne sans assumer que la source soit en anglais ?
Je pense à des cas évidents où un logiciel est développé localement pour un usage local, donc sans nécessité d'utiliser l'anglais comme langue d'interface, et où son usage va dépasser le cadre local et nécessiter une localisation.
Cette localisation peut se faire vers l'anglais puis par son intermédiaire mais pourquoi pas directement vers d'autres langues.
Une autre raison pour la nécessité de cette "neutralité" de gettext est qu'une grande partie des processus utilisant PO, et ce même pour des processus hors FLOSS sont limités par le fait que PO n'identifie pas la langue source puisqu'elle est l'anglais par défaut. Certain processus utilisent le format PO pour des paires qui n'incluent pas l'anglais et les outils qui vont utiliser ces fichiers peuvent/vont par erreur considérer que l'une des langues est l'anglais.
Par extension, cette neutralité de gettext permettrait de mieux l'intégrer dans des processus impliquant des standards tels que TMX ou XLIFF.
Voili voila.
Jean-Christophe Helary