Répondre

Traduction de Gramps en français

mathieumd
Messages : 29
Saisie : Geneweb
Voir son arbre
Sujet créé pour pouvoir discuter de ce que devrait être la traduction en français de Gramps.
(continuation de la discussion qui a commencé initialement sur le bugtracker : http://www.gramps-project.org/bugs/view ... 648#c23533 )
romjerome a écrit : J'avoue n'avoir jamais eu le courage de regarder en détail ces espacements (ils sont souvent modifiés durant le développement). À la vue du patch, je vois toutes ces petites erreurs conservées au fil des versions ...horrible ... :(
Saisissons cette occasion pour reprendre la bonne direction ! ;-)
romjerome a écrit : Les types "francisés" (7. 8.) étaient en général des demandes.
N'est-ce pas typiquement le genre de demande qui ferait mieux d'être remontée au niveau du code plutôt que de la traduction ?
romjerome a écrit :
Ces dernières années, il y a eu peu de vérifications comme la tienne ! :)
La dernière devait dater de 2007 ...
Je ne garantis pas avoir toujours du temps pour, mais je crois que le virus de la généalogie m'a touché ; je ne serais probablement jamais bien loin, même si avec des périodes de mois d'absences.

D'où l'intérêt d'en discuter en public sur ce forum (où ailleurs, si tu as une meilleure idée) plutôt que sur le bugtracker ;-)
romjerome a écrit : Pour la référence au latin, on m'avait fait remarquer qu'il *fallait* utiliser 'media/item' !
Ah ben si il *faut*, il faut... :-/
romjerome a écrit : Pour medium, effectivement, il y avait aussi une référence artistique (medium = support numérique et pas TV, journaux), mais je ne retrouve plus la discussion originelle.
Pour désigner des fichiers multimédias, je persiste néanmoins ; pour le forum, je me cite :
Néanmoins, je préférerais utiliser « média, médias » que « medium, media » parce que c'est plus intuitif (et c'est du français correct ! ;-))
http://fr.wikipedia.org/wiki/M%C3%A9dia#.C3.89tymologie « Le terme media reste peu employé, hormis chez quelques puristes »
romjerome a écrit : Il y a des corrections d'erreur qu'il faudra aussi backporter (Gramps 3.3.x):
postal, majuscule sur les parties du nom, Nomsdefamillebrut, typo, surnom n'est pas surname, fêtes juives, etc ...
Je n'ai pas creusé, mais j'ai cru comprendre qu'il y avait une fonction « Sync » pour ce genre de choses sur Lokalize...

Au fait, tu utilises quel logiciel pour traduire ?
romjerome a écrit : Après, les modifs sur les formes plurielles, absentes du code devront être écrites en dur pour les autres et aussi les anglais. ;)
Corriger les strings originales quand ça semble pertinent, ça me plaît ;-)
romjerome a écrit : > Bon courage !

Ce n'est que le début, non ?
Tu ne souhaites pas continuer ?
Si si, bien sûr !

On devrait par contre se répartir le travail, je ne voudrais pas qu'on bosse sur la même tâche en doublon ;)
romjerome a écrit : Le raccourcissement était nécessaire pour les additions de parties du nom (Préférences) : PasPatronyme, Principal, etc... Rapidement, on se trouvait hors écran ! Oui, les «ComboBox» posent problème, mais aussi les labels.
Pour les labels (parle-t-on bien de la même chose ? Je parle du texte qui s'affiche par exemple à gauche d'un menu déroulant) je pense qu'il est important de conserver la compréhension du sens du label ; il vaut mieux un texte un peu trop long (Nb. d'années avant et après les dates « vers ») qu'un texte incompréhensible (Date about range).

Pour les menus déroulant on peut imaginer une taille maximum limitée (en insérant des « ... » au milieu de la chaîne) quand le widget n'est pas déroulé, quitte à le dérouler pour lire l'intégralité de la ligne.
romjerome a écrit : > « Noms de famille brut » ne fonctionnait tout simplement pas.
les espaces supplémentaires, sans doute ;)
Exact ;-)

C'est surtout ce genre de coquille qu'il faudrait absolument éviter ; un utilisateur standard ne peut pas comprendre pourquoi ça ne marche pas.
romjerome a écrit : Les fonctions et méthodes spécifiques utilisées par Gramps sont, pour la plupart, listées sur le wiki: http://www.gramps-project.org/wiki/inde ... ct_classes
Comme avec les actions de l'historique, les chaînes de Gramps ne sont pas toujours consistantes, chaque développeur ayant son vocabulaire et sa logique. En général, ces chaînes sont améliorées à l'usage ...
Je n'étais pas tombé sur cette page du wiki, merci.
romjerome a écrit : En revanche, je ne suis pas trop pour aller dans l'interprétation et l'ajout de formes plurielles ou de virgules. Il faudrait corriger cela sur le code pour que les anglais et les autres traducteurs puissent en bénéficier.
Ce n'est pas moi qui vais te contredire !
romjerome a écrit : Oui, la traduction contient déjà ce type de personnalisation (ex: outils: 'vérification des données' (données utilisateur), plutôt que 'vérifier la base de données' (les erreurs dans la base de données). Ces améliorations pourront enrichir le code du tronc (Gramps 3.4.x étant en «strings freeze») : c'est prévu (TODO) !
OK
romjerome a écrit : > D'ailleurs, ce n'est pas forcément mauvais : avoir exactement le même libellé d'opération que celui effectivement utilisé dans le logiciel permet de se retrouver plus facilement. (une action donnée n'a qu'un seul et unique nom quel que soit le contexte)

Je ne comprends pas !
Pour l'historique, par exemple, tu penses sincèrement que "Éditer le lieu (%s)" sonne mieux que "Édition du lieu (%s)" dans les actions effectuées ?
On efface ou annule l'édition !
On annule une « édition », qui est le résultat de l'opération « éditer ».

Les deux ont leur logique ; ce que je veux dire c'est qu'il faut n'avoir qu'une seule logique : soit « édition » soit « éditer ».

Mais quand on est dans un contexte à partir duquel on déclenche l'action, le phrasé correct est alors « éditer » et non pas « édition ». D'où ma préférence pour l'infinitif, puisque Gramps (pour l'instant du moins) ne distingue pas les deux contexte.
romjerome a écrit : Beaucoup d'outils présents dans Gramps ont une approche très technique, qu'il a souvent fallu lisser pour les utilisateurs via une traduction souple.
Je pense que dès qu'une tournure de phrase n'est plus explicite, on prends un risque d'avoir une fonctionnalité ignorée par les utilisateurs par manque de compréhension.

Ça vaut sans doute la peine de débattre chaque cas systématiquement.
romjerome a écrit : Les espaces absents sont liés à glade.
On ne peut rien y faire, les anglais n'utilisant pas les mêmes conventions.
Une histoire de «design»...
Mauvais design, changer design ;-)

J'ai surtout vu des « : » ajouté en dur dans le code. C'est pertinent puisque ça évite d'avoir deux chaînes sémantiquement identiques à traduire (« Name » et « Name: » par exemple), mais alors il faut aussi faire traduire le « : » (« + _(": ") ») plutôt que l'ajouter en dur (« + ": " »).
romjerome a écrit : On peut s'amuser à maintenir cette logique, mais il faudra commenter tout çà (pour les prochaines traductions...) et ignorer les retours du script «check_po» (ou update_po.py) sur les tests de ponctuation et fin de ligne.
J'ai mis des commentaires à chaque fois (sauf omission involontaire), et le résultat de check_po avait d'ailleurs déjà des centaines de chaînes se terminant par un « . » qui n'existait pas dans la chaîne originale ; ce qui est négligeable non ? (personnellement je ne mettrais pas de point à la fin des chaînes utilisées pour décrire une action (affichées quand on survole une option par exemple))

romjerome
Messages : 1007
[quote]

oui et non !
Tu verras que les développeurs te diront que c'est spécifique aux francophones.  ???
Au départ on traduit simplement de l'anglais au français, puis on se rend compte que l'usage nécessite l'emploi d'une traduction adaptée.  :(
Une partie des événements hérités du Gedcom (ex: christening, will/probate) est anglo-saxon. L'ajout de nouveaux types semble logique. La migration pour les événements n'est pas très difficile, côté utilisateur, il suffit d'utiliser l'outil pour renommer un événement par un autre ou aller dans la vue Événements.  ;)

[quote]

Un traducteur KDE de + ...  :P

Je maintenais la traduction mais je crois avoir fait le tour ces dernières années ...
Répondre aux requêtes, essayer de corriger des bogues, maintenir le manuel et la traduction, les addons, c'est au détriment de mes recherches généalogiques ... J'ai essayé de rassembler certaines aides, via un ensemble de commandes, dans un outil du tronc. Ce n'est pas un code super propre, mais çà doit permettre d'éviter certains pièges que les traducteur(rice)s ont rencontré au cours des années.

Gramps essaye de sortir 2/3 versions de maintenance et une version majeure par an. Si tu prends un peu de temps avant la sortie d'une version majeure, alors tu auras plusieurs mois sans gros changements sur les chaînes à traduire.

[quote]

Çà devait être en 2006/2007, avant la dernière révision !
Il y a quelques années, je l'aurai bien modifié...
Finalement, j'ai conservé l'ancienne logique et le travail des précédents traducteurs.

Nouveau traducteur = nouveau dynamisme, nouvelle charte, nouveau schéma
C'est peu être l’occasion de ...

[quote]

Je suis sous GNOME...  :-[
gtranslator ou poedit !

Sérieusement, j'avais bien aimé 'transolution', un outil en python, une interface d'édition et des outils puissants (support XLIFF, TM, etc ...). Je n'accroche pas à 'Translate Toolkit/Pootle/Virtaal' (pourtant en python). Les outils centralisés pour les distributions et bureaux (ex:Transifex) posent trop de problèmes avec des projets indépendants comme Gramps, leurs traductions ne sont pas testées dans le contexte (base d'utilisateurs/traducteurs).

[quote]

Ah oui, j'avais aussi essayé KBabel (ancêtre de Lokalize).
Mais je n'arrive pas à suivre toutes les versions de KDE ... Je n'ai pas les libs KDE 4 !!!  :-[

Backport relatif ... c'est la série de maintenance (pas certain qu'il y aura un Gramps 3.3.2 !).

J'ai utilisé gedit avec support UTF-8 ...  :o
J'ai modifié les chaînes qui étaient fausses (adresse postal, clés des noms pour l'affichage, traduction des fêtes juives, typo, etc ...). Le reste c'est de la formulation, on ne va pas introduire de nouvelles traductions dans cette série. Les vraies améliorations sont pour la versions 3.4.0 !  ;)

[quote]

Tu les listes et les proposes à la mailing liste (devel).
Tu remplis un rapport de bogue ou de fonctionnalité.
Tu argumentes un petit peu.
Et en général , les développeurs sont bien contents qu'un regard extérieur amène à plus de précision ou offre une bonne solution.
Gramps n'a pas besoin d'être compilé, les corrections peuvent être très rapides.  8)

[quote]

C'est aussi lié.
Dans l'exemple de l'onglet Dates, les champs sont libres, mais imagines avec une boîte de sélection dont les entrées sont déjà très longues. C'est le cas avec le dialogue NarrativeWeb (Saga)... Le développeur n'utilise pas toujours (rarement) une version localisée et parfois il faut également jongler avec les labels. NB: pour la version 3.4.0, une des chaînes liée à l'importation, envoie dans une colonne, des données Gedcom tronquées (20 caractères, il me semble). C'est un truc à voir avec le développeur, sûrement pour la prochaine version majeure (tronc) !

[quote]

Comme tu veux, mais j'aimerai bien que la série 3.4.x soit ma dernière migration en tant que traducteur pour le programme Gramps ... Je maintenais aussi le manuel (docbook puis wiki) plus ou moins dans les temps lors des migrations majeures. Comme tu veux, tu as carte blanche pour Gramps 3.4.0, mais il nous faut informer les autres développeurs car je gère également des traductions extérieures, étant en contact avec les autres traducteurs actifs.

[quote]

J'ai vu, il y en a d'autres !
Ton fichier avait quelques coquilles ou des suppressions à revoir avec les développeurs (date de naissance => naissance, pluriel ou non, etc ...)

La version SVN actuelle est la tienne.
Les nouveaux commentaires sont là comme des références à ces chaînes personnalisées ou à tester.

mathieumd
Messages : 29
Saisie : Geneweb
Voir son arbre
romjerome a écrit :
23 mars 2012, 15:34

oui et non !
Tu verras que les développeurs te diront que c'est spécifique aux francophones.  ???
Au départ on traduit simplement de l'anglais au français, puis on se rend compte que l'usage nécessite l'emploi d'une traduction adaptée.  :(
Une partie des événements hérités du Gedcom (ex: christening, will/probate) est anglo-saxon. L'ajout de nouveaux types semble logique. La migration pour les événements n'est pas très difficile, côté utilisateur, il suffit d'utiliser l'outil pour renommer un événement par un autre ou aller dans la vue Événements.  ;)
Renommer c'est une chose, mais répartir dans deux (hypothétiques) événements ce qui avait été saisi en un seul semble plus compliqué.

Si j'y repasse, je lancerais éventuellement le sujet sur la liste devel.
romjerome a écrit :
23 mars 2012, 15:34
Je maintenais la traduction mais je crois avoir fait le tour ces dernières années ...
Répondre aux requêtes, essayer de corriger des bogues, maintenir le manuel et la traduction, les addons, c'est au détriment de mes recherches généalogiques ... J'ai essayé de rassembler certaines aides, via un ensemble de commandes, dans un outil du tronc. Ce n'est pas un code super propre, mais çà doit permettre d'éviter certains pièges que les traducteur(rice)s ont rencontré au cours des années.
Tu devrais peut-être, au fur et à mesure, compléter la page Translation into French du wiki pour documenter et pérenniser toutes les informations que tu me donnes souvent, y compris sur ces outils dont tu parles (où dans le tronc ?)
romjerome a écrit :
23 mars 2012, 15:34

Nouveau traducteur = nouveau dynamisme, nouvelle charte, nouveau schéma
C'est peu être l’occasion de ...
Si on se met d'accord, je me chargerais de les remplacer. Mais comment prendre une décision « démocratique » ? Il y a d'autres francophones sur la liste devel ?
romjerome a écrit :
23 mars 2012, 15:34


OK. Je ferais de mon mieux, mais reste dans le coin quand même encore un peu hein ;-)



Pour la date de naissance, je crois que je l'avais changé à un endroit qui s'affichait surtout dans les entêtes des colonnes de la vue Individus ; c'était dans l'espoir de réduire sa largeur.


Répondre

Revenir à « Gramps »