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.
_______________________________________
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 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:
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:
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
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:
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:
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:
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:
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.
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:
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 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
Bonsoir kerb,
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