(continuation de la discussion qui a commencé initialement sur le bugtracker : http://www.gramps-project.org/bugs/view.php?id=5648#c23533 )
Saisissons cette occasion pour reprendre la bonne direction !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 ...
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 : Les types "francisés" (7. 8.) étaient en général des demandes.
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.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 ...
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
Ah ben si il *faut*, il faut... :-/romjerome a écrit : Pour la référence au latin, on m'avait fait remarquer qu'il *fallait* utiliser 'media/item' !
Pour désigner des fichiers multimédias, je persiste néanmoins ; pour le forum, je me cite :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.
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 »
Je n'ai pas creusé, mais j'ai cru comprendre qu'il y avait une fonction « Sync » pour ce genre de choses sur Lokalize...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 ...
Au fait, tu utilises quel logiciel pour traduire ?
Corriger les strings originales quand ça semble pertinent, ça me plaîtromjerome 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.
Si si, bien sûr !romjerome a écrit : > Bon courage !
Ce n'est que le début, non ?
Tu ne souhaites pas continuer ?
On devrait par contre se répartir le travail, je ne voudrais pas qu'on bosse sur la même tâche en doublon
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).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 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.
Exactromjerome a écrit : > « Noms de famille brut » ne fonctionnait tout simplement pas.
les espaces supplémentaires, sans doute
C'est surtout ce genre de coquille qu'il faudrait absolument éviter ; un utilisateur standard ne peut pas comprendre pourquoi ça ne marche pas.
Je n'étais pas tombé sur cette page du wiki, merci.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/index.php?title=Coding_for_translation#Object_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 ...
Ce n'est pas moi qui vais te contredire !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.
OKromjerome 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) !
On annule une « édition », qui est le résultat de l'opération « éditer ».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 !
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.
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.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.
Ça vaut sans doute la peine de débattre chaque cas systématiquement.
Mauvais design, changer designromjerome 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»...
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 (« + ": " »).
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 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.