Bonsoir,
dans quel cadre envisagez-vous ce travail? Dans le TranslationProject sont pris en charge : http://translationproject.org/domain/gettext-examples.html http://translationproject.org/domain/gettext-runtime.html http://translationproject.org/domain/gettext-tools.html
Votre travail est-il complémentaire? Merci de m'éclairer sur votre démarche.
Message du 24/04/09 22:45 De : "Mathieu" mathieu.provis@wanadoo.fr A : y.kerb@laposte.net Copie à : Objet : Traduction du manuel de GNU Gettext
Bonjour,
j'ai commencé la traduction en français du manuel de GNU gettext (fichier texinfo du manuel, en utilisant po4a). J'ai l'impression que personne n'avait entrepris ce travail pour le moment.
Où est ce que je peux poster ce texte pour faire partager cette traduction, la soumettre à relecture et éventuellement avoir aussi de l'aide.
Merci
Mathieu
_______________________________________
Créez votre adresse électronique prenom.nom@laposte.net 1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
Afficher les réponses par date
Bonjour Mathieu,
j'ai commencé la traduction en français du manuel de GNU gettext (fichier texinfo du manuel, en utilisant po4a). J'ai l'impression que personne n'avait entrepris ce travail pour le moment.
C'est un travail monumental. Ce manuel a plus de 200 pages!
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.
En plus, les chapitres "Editing PO Files" et "The Translator's View" nécessitent d'abord un travail de rédaction dans l'original, en Anglais. Votre aide dans ce domaine-là, avec votre exprience de traducteur justement, serait bienvenue.
Bruno (développeur en charge de gettext)
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
On Sun, Apr 26, 2009 at 05:09:36PM +0900, Jean-Christophe Helary wrote:
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
Je pense qu'on peut utiliser gettext avec une langue source autre que l'anglais, ensuite de quoi on peut explicitement forcer une autre langue traduite par défaut dans l'application qui utilise le .po (en redéfinissant LC_ALL par exemple).
Cependant je crois que les outils gettext se basent sur des chaines en ASCII, donc s'il s'agit d'une autre langue on va avoir des problèmes d'encodage à gérer.
On dimanche 26 avr. 09, at 17:23, Sylvain Beucler wrote:
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
Je pense qu'on peut utiliser gettext avec une langue source autre que l'anglais, ensuite de quoi on peut explicitement forcer une autre langue traduite par défaut dans l'application qui utilise le .po (en redéfinissant LC_ALL par exemple).
Cependant je crois que les outils gettext se basent sur des chaines en ASCII, donc s'il s'agit d'une autre langue on va avoir des problèmes d'encodage à gérer.
Voilà 2 points qui sont essentiels:
1) permettre l'identification claire des langues source et cible 2) utiliser systématiquement unicode.
Une fois ces deux points solutionnés on aura moins de mauvaises raisons d'utiliser l'anglais de cuisine pour écrire ses interfaces en FLOSS.
En bref, si le logiciel libre vise un tant soi peu à libérer les dévelopeurs et utilisateurs, il est temps qu'il fasse sa révolution linguistique.
Jean-Christophe Helary
- utiliser systématiquement unicode.
Il faudrait d'abord que tous les langages de programmation gèrent correctement les chaînes de caractères unicode, non? ;) Ça ne dépend (malheureusement) pas que de gettext.
Et puis définir quel unicode ;) http://diveintomark.org/archives/2004/07/06/nfc
On dimanche 26 avr. 09, at 18:55, Sylvain Beucler wrote:
- utiliser systématiquement unicode.
Il faudrait d'abord que tous les langages de programmation gèrent correctement les chaînes de caractères unicode, non? ;) Ça ne dépend (malheureusement) pas que de gettext.
Non. Ça n'a rien à voir avec le language de programation. Le code peut être écrit dans un encodage différent, ce qui est le cas de toutes manières. Tu n'imagines pas que les japonais s'amusent à écrire leur code en ascii ?
Ce que je veux dire c'est que gettext doit pouvoir sortir des fichiers en unicode.
Et puis définir quel unicode ;) http://diveintomark.org/archives/2004/07/06/nfc
... Si d'autres processus arrivent à gérer unicode ça doit être à la portée de gettext non ?
Jean-Christophe
Jean-Christophe Helary dit:
Ce que je veux dire c'est que gettext doit pouvoir sortir des fichiers en unicode. ... Si d'autres processus arrivent à gérer unicode ça doit être à la portée de gettext non ?
gettext sait gérer ça depuis longtemps au niveau des outils (xgettext, msgcat, msgmerge etc.)
Dans le cas des langages de programmation comme C, le programmeur doit aussi s'occuper de la transformation d'encodage, pour le cas où gettext ne trouve pas de traduction (ou n'est même pas activé).
Bruno
Sylvain Beucler pensa:
Cependant je crois que les outils gettext se basent sur des chaines en ASCII, donc s'il s'agit d'une autre langue on va avoir des problèmes d'encodage à gérer.
C'était comme ça il y a dix ans. Entretemps, gettext supporte très bien les chaînes 'msgid' qui contiennent des caractères hors d'ASCII. Il suffit - d'écrire le code source en UTF-8, - de passer l'option --from-code=UTF-8 à xgettext, - de faire la conversion d'UTF-8 vers l'encoding de l'utilisateur à l'éxécution du programme. Voir par exemple le module 'propername' de gnulib [1].
Bruno
[1] http://www.gnu.org/software/gnulib/MODULES.html#module=propername
Jean-Christophe Helary posa 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.
Normalement il est plus difficile de trouver un traducteur pour une langue X que pour l'Anglais. Par example, si le logiciel est d'abord en Hongrois, comment va-t-on faire pour trouver un traducteur du Hongrois vers le Chinois? Il y a un certain nombre de Chinois qui apprennent l'Anglais étants jeunes, mais pas le Hongrois.
Mais, oui, le problème peut aussi être inverse: Si on cherche un traducteur du Français vers l'Occitan, ce sera plus facile que de l'Anglais pour l'Occitan.
Il est projeté qu'une version future des fichiers PO et de gettext sache gérer la traduction par un langage intermédaire, par exemple, Anglais -> Français -> Occitan. Mais il sera certes utile si le traducteur a au moins une compréhension minimale de l'Anglais.
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.
Je pense que ces cas sont suffisamment rares et peuvent être traités avec peu d'effort.
Bruno
On dimanche 26 avr. 09, at 19:47, Bruno Haible wrote:
Cette localisation peut se faire vers l'anglais puis par son intermédiaire mais pourquoi pas directement vers d'autres langues.
Normalement il est plus difficile de trouver un traducteur pour une langue X que pour l'Anglais. Par example, si le logiciel est d'abord en Hongrois, comment va-t-on faire pour trouver un traducteur du Hongrois vers le Chinois? Il y a un certain nombre de Chinois qui apprennent l'Anglais étants jeunes, mais pas le Hongrois.
Il y a de grandes chances qu'il y a plus d'utilisateurs russophones en Hongrie que d'utilisateurs anglophones, en particulier des techniciens de haut niveau.
Il y a quantité de groupes linguistiques qui échangent à travers une langue qui n'est pas l'anglais: la plupart des pays de l'ancienne zone soviétique échangent encore avec le Russe, le français est toujours une langue dominante en Afrique de l'Ouest, le Chinois vis-à-vis des langues de sa région.
Mais, oui, le problème peut aussi être inverse: Si on cherche un traducteur du Français vers l'Occitan, ce sera plus facile que de l'Anglais pour l'Occitan.
Mais aussi du français vers d'autres langues romanes. Et du hollandais vers l'allemand, etc.
Mais le problème n'est pas là. Laissons les linguistes se débrouiller pour savoir à partir de quelle langue ils veulent traduire.
Ce que je suggérais c'était la possibilité d'identifier une langue source comme telle, tout simplement en ajoutant un en-tête dans le fichier PO du type: "Language: fr\n" mais pour la source, donc quelque chose comme "Source: en\n".
Rien que ça permettrait de créer des PO valides (hors processus gettext) avec d'autres langues sources, pour des mises en correspondance avec des TMX extérieures etc.
Jean-Christophe Helary
'soir, j'en reviens à ma question. Ce travail est-il à intégrer au TP? Est-ce un nouveau paquetage? Si non, sous quelle forme le rendre publique?
Bruno Haible wrote:
Bonjour Mathieu,
j'ai commencé la traduction en français du manuel de GNU gettext (fichier texinfo du manuel, en utilisant po4a). J'ai l'impression que personne n'avait entrepris ce travail pour le moment.
C'est un travail monumental. Ce manuel a plus de 200 pages!
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.
En plus, les chapitres "Editing PO Files" et "The Translator's View" nécessitent d'abord un travail de rédaction dans l'original, en Anglais. Votre aide dans ce domaine-là, avec votre exprience de traducteur justement, serait bienvenue.
Bruno (développeur en charge de gettext)
Bonsoir kerb,
j'en reviens à ma question. Ce travail est-il à intégrer au TP? Est-ce un nouveau paquetage? Si non, sous quelle forme le rendre publique?
En tant que développeur, je préfère naturellement recevoir un fichier gettext_fr.texi. Je ne suis pas au courant que le TP soit courammment utilisé avec po4a. Et je n'ai pas d'expérience avec po4a non plus. Donc, à mon avis, Mathieu peut tout aussi bien m'envoyer le fichier .texi traduit (ou la partie qu'il décide de traduire) directement.
Bruno
-
Bruno Haible -
Jean-Christophe Helary -
kerb -
Sylvain Beucler -
y.kerb