Gnomefr

gnomefr@traduc.org

4 participants
11114 discussions

f-spot - master
by noreply＠gnome.org 16 Nov '10

16 Nov '10

Bonjour, L'état du module f-spot - master - help (français) est maintenant « Traduit ». http://l10n.gnome.org/vertimus/f-spot/master/help/fr Relu. Je soumets ma copie aux critiques de Laurent, et j'attends ses commentaires. AlainLojewski -- Ceci est un message automatique envoyé par l10n.gnome.org.

1 0

Re: [Gnomefr] Adopter l'espace fine insécable ?
by Nicolas Delvaux 15 Nov '10

15 Nov '10

> > Par cette discussion je cherche aussi à savoir s'il reste des > problèmes techniques importants à résoudre en vu de cette > adoption. > > > En clair, tu ne veux pas discuter du gain car tu sais pertinemment > qu'il n'y a aucun espoir de nous convaincre (voir mon commentaire sur > les paragraphes justifiés) ? Et bien disons que tu l'as dis toi même (en semblant d'accord) dans ton dernier mail, c'est purement esthétique. Partant de là, je ne suis pas revenu sur le sujet, vu qu'il me semblait réglé. Je suis d'accord pour dire que ce n'est pas une révolution qui va faire exploser la part de marché de Gnome, mais du moment qu'on réussi à réduire les « risques » et inconvénients au maximum, je ne vois pas pourquoi on ne le ferait pas. > Quand on sait que presque tous les nouveaux traducteurs ne prennent > pas en compte les consignes... > En plus d'oubli naturel des autres (moi inclus) .... > > oui c'est grosso-modo juste cela, en gros faudra qu'on revérifie tout > (je le fais déjà pour les espaces insécables avec un script > et crois-moi, cela me prend déjà pas mal de temps de corriger ces > petites erreurs. Pourrais-je avoir accès à ce script ? Je gagnerais déjà pas mal de temps. > Par exemple, que fais tu lorsque, dans le texte, il y a un > smileys ;-) (espace insécable devant avec ton script ?) > que fais-tu quand, par erreur ou pas, il se trouve qu'il y a un espace > devant un ; dans le texte anglais, il sera converti par ton script ? Ce n'est pas un problème. On dépassera certes la dizaine de ligne que j'envisageais, mais je crois en l'infinie puissance des expressions régulières. ;-) Pour l'histoire des smileys, on pourrait simplement envisager de faire le remplacement sur " : " (pour milieu de chaine) ou sur " :"" (pour la fin de chaine). Tout ça pour dire que c'est techniquement possible, on trouvera toujours un moyen. > > D'autre part, je ne crois pas que tu (Nicolas) te rend > > vraiment compte du temps de travail que cela représente (je > > sais, on te la déjà dit) . > > -- Ce n'est pas un simple remplacement comme tu le dis : > > 1) l'espace insécable n'est pas utilisé que devant les : > > et ; mais il me semble également entre M. et Dupond, avant > > les unités de mesures "15 cm" etc. Doit-on remplacer > > également ceux-là ? > > 2) donc il s'agit plutôt de six remplacements et encore en > > supposant que l'espace > > insécable ne soit jamais séparé du l'élément qui le suit par > > exemple : > > "voici les trois élément à considérer " > > ": le rouge, le bleu..." > > car le remplacement automatique ne marche plus. > > > > > Si on parle ici de remplacement automatique, c'est bien que la > chaine de caractère en question a déjà été traduite. > > > Non par forcément. > Effectivement, il y a déjà deux cas : lorsque l'espace initial est > insécable et lorsqu'il ne l'est pas. J'avais oublié... > En fait trois cas, lorsque le traducteur a oublié de mettre un > espace... Au départ j'envisageais juste un script de conversion qui viendrait en plus du ou des scripts de corrections des erreurs usuelles, mais si je comprends bien tu préfèrerais tout fusionner en un seul. C'est tout aussi faisable sur le principe. > Pour reprendre ton exemple, la chaine ": le rouge, le bleu..." > serait en fait déjà " : le rouge, le bleu..." (avec une espace > insécable devant « : ») dans le fichier .po, donc en partant > de là le remplacement automatique fonctionnerait > parfaitement. ;-) > > > Non > Dans cet exemple, je voulais signaler un cas particulier ou l'espace > (insécable ou pas) se trouve sur la ligne d'AVANT. C'est certes un cas à gérer. > Je ne pense pas que msgcat puisse faire cela (???) mais un traducteur > peut le faire... avec ses petits doigts > > > > Au passage, il semble bien que l'espace entre un nombre et une > unité (comme "cm", "€") puisse également être une espace fine > insécable (à priori les deux sont tolérés, je n'ai pas trouvé > de règle claire et précise sur le sujet). > > > Il te semble... (et pour M. Dupond ? et pour les autres cas ?) Une > étude plus sérieuse me semble nécessaire de tous les cas d'espace > insécable (fine ou pas) pour écrire un script qui tienne la route. Tu > as encore un peu de travail sur la planche, désolé. On est sûr que l'espace fine insécable doit être utilisée devant les caractères "?;!:»" et derrière "«". Quelques sources (dont les règles typographiques actuelles de Gnome) disent qu'il faut une espace insécable classique devant ":»" et derrière "«", ce qui est par exemple en contradiction avec wikipedia et les recommandation de l'université Paris Diderot : http://www.eila.univ-paris-diderot.fr/sysadmin/gestion-docs/typo-francaise#… Partant de là je me dis qu'il serait plus pratique d'utiliser les espaces fines avec ces caractères également, ça évite d'avoir à jongler en permanence (l'espace insécable n'étant alors utilisée que très rarement). Pour les unités, en fait la solution était sous notre nez : http://www.utc.fr/~tthomass/Themes/Unites/typographie/Typo.pdf (lien donné ici : http://traduc.org/gnomefr/Typographie ) L'espace fine doit donc être utilisée comme séparateur entre les unités et comme séparateur entre les nombres (donc aussi valable pour les numéros de téléphone et les codes postaux comme « 42 240 », même s'il y a peut de chances qu'on en rencontre dans le contexte qui nous intéresse ici ;-)) Bref, l'espace insécable classique ne doit être utilisée que dans les noms composés et et après des abréviations comme M. ou Mme. Michu. Je n'ai pas trouvé de document corroborant ce dernier point, mais ça me paraitrait logique. Après, sachant que ces chaines sont rares, si on ne veux pas s'embêter on pourrais également utiliser des fines dans ce cas. Je ne suis pas spécialement pour, mais c'est envisageable. À vous de voir. > En tous cas tu es d'accord, cela ne peut pas être un simple > remplacement des espaces insécables, ouf ! > > > Cependant il est vrai que ma proposition initiale de faire un > bête chercher/remplacer-tous sur le caractère de l'espace > insécable était un peu « violente ». Il serait en effet plus > subtile et sage de chercher/remplacer les chaines suivantes : > " :", " ;", "« ", " »", " !", " ?". > C'est certes un peu plus compliqué, mais la chose est aisément > scriptable si besoin. > > > Aisément, surement mais pas pour moi, je suis traducteur pas > programmeur et pour être sûr que tous les cas sont pris en compte... Ça ne me dérangerais pas d'essayer, ce genre défi m'amuse ^^ Dans le pire des cas, ce n'est pas l'aide sur les forums qui manque. > Sous gedit, il y a un greffons pour les visualiser par un symbole > grisatre différent (même si depuis la 10.10, il ne marche plus comme > avant et cela m'énerve un peu d'ailleurs) , sous Lokalize (il sont > d'une couleur très très trop légèrement différente à mon goût), c'est > tout ce que je connais. > > Est-ce qu'ils font une distinction entre fine ou pas, j'en sais rien, > je te laisse le découvrir ? > mais cela serait bien. Sous gedit, le symbole utilisé pour représenter la fine est le même que pour l'espace insécable. On peut rapporter un bug si nécessaire. Quand à Lokalise, l'espace fine est prise en compte, mais elle est affichée avec une largeur nulle (à cause d'un bug dans Qt). Beaucoup de gens traduisent Gnome avec Lokalise ? > Il est vrai que beaucoup (la plupart) des éditeurs utilisent > par défaut une police à chasse fixe, ce qui implique qu'aucune > différence visible n'est affichée entre une espace fine et une > espace classique. > Cependant, il existe une astuce simple : utiliser un éditeur > de texte qui surligne les résultats de recherche dans tous le > texte. > La plupart (tous sauf le bloc note Windows ?) le font, ce qui > implique qu'une recherche sur le caractère " " surligne (et > donc discrimine) toutes les espaces fines insécables du > fichier en question. > > > > > > simple, pas si le fichier fait quelques milliers de lignes... j'en ai > mal à la molette d'avance... Cliquer sur le bouton « rechercher le suivant » ? Après c'est pas le mode manuel pour rien, l'idéal serait en effet un script. > Partant du principe qu'une nouvelle version de Gnome sort tous > les 6 mois, je me dis qu'une bonne partie des .po sont édités > et commités dans ce laps de temps. > > > Voir le site mais actuellement pour passer à la 3.0 il y a une > trentaine de fichiers (soit à la louche 50 %) > > > Il s'agirait en fait ici de profiter de l'édition d'un .po > (pour traduire de nouvelles chaines par exemple) pour en même > temps passer à la fine. > Tout de suite on perd beaucoup moins de temps. :-) > > > > Et cela fait un truc bancal... moitié fine, moitié pas fine. Tu dis qu'on en est à à peu près 50% pour la 3.0, donc d'ici 4 mois ça fera déjà un bon morceau. S'il subsiste une légère cohabitation pendant quelques temps, je ne pense pas que ça soit un problème vu que la différence entre les deux caractère n'est pas non plus énorme (je ne pense pas que ça dérangera les utilisateurs). > Les commiteurs ont un accès git sur tous les projets ok > > Pour ce qui est de la proposition, je pense également que ce > > travail ne peut se faire que petit à petit au bon vouloir > > des gens, donc pourquoi pas un module précis... si vraiment > > vous y tenez pour tester qu'il n'y a pas de problèmes avec > > GTK. > > > > > Cette décision vous appartiens. Cependant, si vous décidez de > ne partir que sur un seul module pour commencer, je vous > conseillerais un gros module du genre Evolution, histoire > d'être sûr d'avoir des retours en cas de problème (ça ne sert > à rien si le module est trop peu utilisé). > > > > > > Sinon, on peut aussi laisser le travail de conversion à > > Nicolas, en nous chargeant seulement du commit.... > > > > > Donc voilà, ce n'est pas vraiment nécessaire n'est-ce pas ? > > > Pour le script puisque cela a l'air si SIMPLE, qu'attends tu pour nous > en proposer un ? > (n'attends aucune clémence de ma part, au moindre bug, je pense que tu > passeras un sale quart-d'heure :-) ) Donc je veux bien m'y coller. Il faudrait donc que j'ai accès au(x) script(s) que tu utilises (histoire de ne pas réinventer la roue) et que tu me fasses une sorte de micro cahier des charges. Tu veux que le script te demande confirmation avant chaque substitution ? Tu veux qu'il fasse tout directement, quitte à t'afficher un diff entre les deux versions ? Du coup je ne te dis pas que j'aurais fini en 5 minutes (contrairement aux apparences, j'ai également une vie à côté de ça ^^) mais ça reste faisable. > En résumé : > partant d'un script qui convertit correctement les fichiers po > ("espace:", "espaceinséc:", ...) en ("espaceinsécfine:, ...) en > faisant attention à tous les cas particuliers > que j'ai soulevé (mais il y en a peut-être d'autre) > 1) ne pas toucher à la chaînes originale et aux commentaires > 2) faire attention au espace (insec ou pas) en fin de ligne (donc > suivi de ") si la ligne suivante commence pas (":" ou "?", ...) > 3) attention aux smileys > 4) ... > > et d'un éditeur qui m'affiche clairement la différence entre les > espaces, > insécables ou pas, fines ou pas, tout devient possible. > > Tout est possible en informatique > > Donc ok pour un test sur un gros module ? Donc sur le principe je suis d'accord. Bon dimanche, Nicolas

2 3

libgda - master
by noreply＠gnome.org 15 Nov '10

15 Nov '10

Bonjour, L'état du module libgda - master - po (français) est maintenant « Traduit ». http://l10n.gnome.org/vertimus/libgda/master/po/fr à relire malgré la traduction des menus, l'application reste partiellement en anglais pour moi :( Laurent Coudeur -- Ceci est un message automatique envoyé par l10n.gnome.org.

1 0

Fwd: Adopter l'espace fine insécable ?
by annoa.b＠gmail.com 14 Nov '10

14 Nov '10

---------- Message transféré ---------- De : annoa.b(a)gmail.com <annoa.b(a)gmail.com> Date : 14 novembre 2010 13:07 Objet : Re: [Gnomefr] Adopter l'espace fine insécable ? À : Nicolas Delvaux <nicolas.delvaux(a)gmx.com> Le 14 novembre 2010 00:28, Nicolas Delvaux <nicolas.delvaux(a)gmx.com> a écrit : Bonsoir, > > Voici une réponse groupée pour Bruno et Claude : > > > > Malheureusement, comme tu as pu t'en rendre compte dans les différents > échanges, le gain obtenu me (nous ?) semble quand même vraiment faible > par rapport aux inconvénients potentiels > > > Par cette discussion je cherche aussi à savoir s'il reste des problèmes > techniques importants à résoudre en vu de cette adoption. > En clair, tu ne veux pas discuter du gain car tu sais pertinemment qu'il n'y a aucun espoir de nous convaincre (voir mon commentaire sur les paragraphes justifiés) ? Pourquoi ne fais-tu pas une enquête auprès de la population pour savoir si les gens s'en foutent ou pas (c'est peut-être déjà fait ?) Il n'y a aucune honte à avoir un cheval de bataille personnel. Si les gens réclament cette espace fine alors let's go ! > consignes aux traducteurs > > > - C'est pourtant simple, non ? Un petit temps d'adaptation peut-être, mais > vu qu'il s'agit, grosso-modo, de substituer un raccourci clavier par un > autre... > > > Quand on sait que presque tous les nouveaux traducteurs ne prennent pas en compte les consignes... En plus d'oubli naturel des autres (moi inclus) .... oui c'est grosso-modo juste cela, en gros faudra qu'on revérifie tout (je le fais déjà pour les espaces insécables avec un script et crois-moi, cela me prend déjà pas mal de temps de corriger ces petites erreurs. Par exemple, que fais tu lorsque, dans le texte, il y a un smileys ;-) (espace insécable devant avec ton script ?) que fais-tu quand, par erreur ou pas, il se trouve qu'il y a un espace devant un ; dans le texte anglais, il sera converti par ton script ? > > > D'autre part, je ne crois pas que tu (Nicolas) te rend vraiment compte du > temps de travail que cela représente (je sais, on te la déjà dit) . > -- Ce n'est pas un simple remplacement comme tu le dis : > 1) l'espace insécable n'est pas utilisé que devant les : et ; mais il me > semble également entre M. et Dupond, avant les unités de mesures "15 cm" > etc. Doit-on remplacer également ceux-là ? > 2) donc il s'agit plutôt de six remplacements et encore en supposant que > l'espace > insécable ne soit jamais séparé du l'élément qui le suit par exemple : > "voici les trois élément à considérer " > ": le rouge, le bleu..." > car le remplacement automatique ne marche plus. > > > Si on parle ici de remplacement automatique, c'est bien que la chaine de > caractère en question a déjà été traduite. > Non par forcément. Effectivement, il y a déjà deux cas : lorsque l'espace initial est insécable et lorsqu'il ne l'est pas. J'avais oublié... En fait trois cas, lorsque le traducteur a oublié de mettre un espace... Pour reprendre ton exemple, la chaine ": le rouge, le bleu..." serait en > fait déjà " : le rouge, le bleu..." (avec une espace insécable devant « : ») > dans le fichier .po, donc en partant de là le remplacement automatique > fonctionnerait parfaitement. ;-) > Non Dans cet exemple, je voulais signaler un cas particulier ou l'espace (insécable ou pas) se trouve sur la ligne d'AVANT. Je ne pense pas que msgcat puisse faire cela (???) mais un traducteur peut le faire... avec ses petits doigts > Au passage, il semble bien que l'espace entre un nombre et une unité (comme > "cm", "€") puisse également être une espace fine insécable (à priori les > deux sont tolérés, je n'ai pas trouvé de règle claire et précise sur le > sujet). > Il te semble... (et pour M. Dupond ? et pour les autres cas ?) Une étude plus sérieuse me semble nécessaire de tous les cas d'espace insécable (fine ou pas) pour écrire un script qui tienne la route. Tu as encore un peu de travail sur la planche, désolé. En tous cas tu es d'accord, cela ne peut pas être un simple remplacement des espaces insécables, ouf ! > > Cependant il est vrai que ma proposition initiale de faire un bête > chercher/remplacer-tous sur le caractère de l'espace insécable était un peu > « violente ». Il serait en effet plus subtile et sage de chercher/remplacer > les chaines suivantes : " :", " ;", "« ", " »", " !", " ?". > C'est certes un peu plus compliqué, mais la chose est aisément scriptable > si besoin. > Aisément, surement mais pas pour moi, je suis traducteur pas programmeur et pour être sûr que tous les cas sont pris en compte... > > Une telle méthode ne corrigerait certes pas les éventuelles erreurs de > traductions, mais je ne vois pas comment elle en créerait de nouvelles (tout > contre exemple est le bienvenu). > > > Ceux qui voudront tout de même tout vérifier visuellement peuvent le faire > : sachant que les chaines concernées ne sont qu'une petite partie de > l'ensemble, ça doit tout de même pouvoir être fait dans un temps > raisonnable. > > > Il faut bien déjà vérifier que les espaces insécables sont correctement mis. Admettons qu'un fichier po respecte les espaces fines, de nouvelles chaînes arrivent et sont traduites : 1) il faut vérifier que les espaces insécables (fines ou pas) sont bien mis 2) il faut appliquer ton script systématiquement et pour la fin des temps puis que lorsqu'on regarde un diff, on ne voit pas de différences entre fine ou pas... (cela rejoint mes commentaires plus bas) > > Quel logiciel d'édition marque clairement visuellement la différence ? > > > Comment vous faites actuellement pour différencier une espace classique > d'une espace insécable ? > Sous gedit, il y a un greffons pour les visualiser par un symbole grisatre différent (même si depuis la 10.10, il ne marche plus comme avant et cela m'énerve un peu d'ailleurs) , sous Lokalize (il sont d'une couleur très très trop légèrement différente à mon goût), c'est tout ce que je connais. Est-ce qu'ils font une distinction entre fine ou pas, j'en sais rien, je te laisse le découvrir ? mais cela serait bien. > > Il est vrai que beaucoup (la plupart) des éditeurs utilisent par défaut une > police à chasse fixe, ce qui implique qu'aucune différence visible n'est > affichée entre une espace fine et une espace classique. > Cependant, il existe une astuce simple : utiliser un éditeur de texte qui > surligne les résultats de recherche dans tous le texte. > La plupart (tous sauf le bloc note Windows ?) le font, ce qui implique > qu'une recherche sur le caractère " " surligne (et donc discrimine) toutes > les espaces fines insécables du fichier en question. > > > simple, pas si le fichier fait quelques milliers de lignes... j'en ai mal à la molette d'avance... > > -- Ensuite il faut donc commiter les modifs. Pour moi, un commit prend > disons AU MOINS 15 minutes multiplié par le nombre de fichier po, cela fait > déjà pas mal d'heures de travail. > > > Je ne parle bien évidemment pas de faire des commits UNIQUEMENT pour passer > à l'espace fine insécable ! > Ah bonne nouvelle, ce n'était pas clair à mes yeux > > Partant du principe qu'une nouvelle version de Gnome sort tous les 6 mois, > je me dis qu'une bonne partie des .po sont édités et commités dans ce laps > de temps. > Voir le site mais actuellement pour passer à la 3.0 il y a une trentaine de fichiers (soit à la louche 50 %) > Il s'agirait en fait ici de profiter de l'édition d'un .po (pour traduire > de nouvelles chaines par exemple) pour en même temps passer à la fine. > Tout de suite on perd beaucoup moins de temps. :-) > > Et cela fait un truc bancal... moitié fine, moitié pas fine. > Je ne sais pas comment se passe le commit techniquement (file d'attente ? > Le coordinateur a un accès git sur tous les projets ? Envois du .po par mail > au mainteneur ?), mais il y a peut-être moyen d'automatiser en passant tous > les .po par un script de conversion avant chaque commit. > > Il me semble qu'ils utilisent des scripts de ce genre chez Traduc pour > vérifier certains aspects des traductions... À voir. > > > Les commiteurs ont un accès git sur tous les projets > Pour ce qui est de la proposition, je pense également que ce travail ne > peut se faire que petit à petit au bon vouloir des gens, donc pourquoi pas > un module précis... si vraiment vous y tenez pour tester qu'il n'y a pas de > problèmes avec GTK. > > > Cette décision vous appartiens. Cependant, si vous décidez de ne partir que > sur un seul module pour commencer, je vous conseillerais un gros module du > genre Evolution, histoire d'être sûr d'avoir des retours en cas de problème > (ça ne sert à rien si le module est trop peu utilisé). > > > Sinon, on peut aussi laisser le travail de conversion à Nicolas, en nous > chargeant seulement du commit.... > > > Donc voilà, ce n'est pas vraiment nécessaire n'est-ce pas ? > Pour le script puisque cela a l'air si SIMPLE, qu'attends tu pour nous en proposer un ? (n'attends aucune clémence de ma part, au moindre bug, je pense que tu passeras un sale quart-d'heure :-) ) > Sachant qu'il ne s'agit que de l'étape de conversion ; une fois passée (de > façon totalement transparente s'il s'agit d'un script), tout redevient comme > avant (en ayant changé un raccourcis clavier par un autre). > > NON, car il y aura toujours des gens qui traduiront sans espace insécable et cela fera deux lignes supplémentaires de test dans mon script... ;-) et des modifs en plus. En résumé : partant d'un script qui convertit correctement les fichiers po ("espace:", "espaceinséc:", ...) en ("espaceinsécfine:, ...) en faisant attention à tous les cas particuliers que j'ai soulevé (mais il y en a peut-être d'autre) 1) ne pas toucher à la chaînes originale et aux commentaires 2) faire attention au espace (insec ou pas) en fin de ligne (donc suivi de ") si la ligne suivante commence pas (":" ou "?", ...) 3) attention aux smileys 4) ... et d'un éditeur qui m'affiche clairement la différence entre les espaces, insécables ou pas, fines ou pas, tout devient possible. Tout est possible en informatique Donc ok pour un test sur un gros module ? Bruno > > Nicolas > > > > Nicolas, > > Je suis admiratif devant tous les efforts fournis pour faire passer > cette amélioration. Je le pense vraiment. > > Malheureusement, comme tu as pu t'en rendre compte dans les différents > échanges, le gain obtenu me (nous ?) semble quand même vraiment faible > par rapport aux inconvénients potentiels (problème avec le terminal, > saisie sur certains claviers, consignes aux traducteurs, non prise en > charge dans certains outils, …). > > Rien d'insurmontable, mais une balance globale qui peine à pencher d'un > côté ou de l'autre, d'où je pense le manque de motivation. > > Si Bruno le veut bien, on pourrait toutefois utiliser la fine dans un > module GNOME à choisir, un peu comme projet pilote. Bruno, qu'en > penses-tu ? > > Claude > > Le samedi 13 novembre 2010 à 19:21 +0100, Nicolas Delvaux a écrit : > > > > Aller, je me permets une petite relance. > > > > > > Reste-t-il des points à éclaircir ? > > > > > > > > > Salut à tous, > > > > > > pour ceux qui ont oublié, je vous parlais il y a quelques temps de > > > l'espace fine insécable (comme quoi elle devrait être utilisée à la > > > place des espaces insécables devant :!;?» et derrière « ). > > > Vu qu'on manquait de recul et de tests, j'ai rédigé un compte rendu > > > sur le sujet cet été : http://malaria.perso.sfr.fr/fines/fines.pdf > > > > > > Concernant ce qui nous intéresse ici, il ne semble y avoir aucun > > > problème de support de la fine avec les applications GTK et la > > > plateforme Gnome. > > > Je pense que mes tests sont assez exhaustifs, dans le cas contraire > > > j'attends vos suggestions. > > > > > > Bref, sachant que les règles typographiques de Gnome > > > ( http://traduc.org/gnomefr/Typographie ) mentionnent l'espace fine > > > insécable mais déconseillent son usage « du fait de [s]a faible > > > prise en charge » et que nous savons maintenant qu'il n'y a pas/plus > > > de problème technique, pourquoi ne pas profiter de ce nouveau cycle > > > (qui plus est de la 3.0) pour adopter l'espace fine insécable ? > > > > > > La transition n'est pas compliquée, dans la plupart des cas, les > > > traducteurs doivent juste substituer l'espace insécable (Ctrl + Maj > > > + espace) par l'espace fine insécable (Alt Gr + v). > > > Convertir un .po se fait également très simplement, il suffit de > > > faire un « chercher/remplacer tout » sur les espaces insécables (la > > > chose est facilement automatisable/scriptable si nécessaire). > > > > > > Je veux dire par là que la décision me semble reposer uniquement sur > > > une question de volonté, rien d'autre ne semble s'y opposer (AMHA). > > > > > > Bref, qu'en pensez vous ? > > > Y a-t-il encore quelques zones d'ombre qui mériteraient d'être > > > éclaircies avant de se lancer ? > > > > > > > > > Cordialement, > > > Nicolas > > > > > >

1 0

banshee - master
by noreply＠gnome.org 11 Nov '10

11 Nov '10

Bonjour, L'état du module banshee - master - po (français) est maintenant « Traduit ». http://l10n.gnome.org/vertimus/banshee/master/po/fr Deux messages non certains pour moi #: ../src/Hyena/Hyena.Gui/Hyena.Gui.Dialogs/VersionInformationDialog.cs:58 msgid "Assembly Version Information" msgstr "Information de version de l'assemblage" #: ../src/Hyena/Hyena.Gui/Hyena.Gui.Dialogs/VersionInformationDialog.cs:64 msgid "Assembly Name" msgstr "Nom de l'assemblage" Capture d'écran ci-après !!! Bruno Brouard -- Ceci est un message automatique envoyé par l10n.gnome.org.

1 0

banshee - master
by noreply＠gnome.org 11 Nov '10

11 Nov '10

Bonjour, L'état du module banshee - master - po (français) est maintenant « Traduit ». http://l10n.gnome.org/vertimus/banshee/master/po/fr Dépôt pour récupérer les nouvelles chaînes Bruno Brouard -- Ceci est un message automatique envoyé par l10n.gnome.org.

1 0

balsa - master
by noreply＠gnome.org 11 Nov '10

11 Nov '10

Bonjour, L'état du module balsa - master - help (français) est maintenant « Commité ». http://l10n.gnome.org/vertimus/balsa/master/help/fr ok merci Un pavé de moins On avance, on avance Bruno Brouard -- Ceci est un message automatique envoyé par l10n.gnome.org.

1 0

balsa - master
by noreply＠gnome.org 10 Nov '10

10 Nov '10

Bonjour, L'état du module balsa - master - help (français) est maintenant « Relu ». http://l10n.gnome.org/vertimus/balsa/master/help/fr Ouf, enfin terminé. Pas passionnant comme doc, en plus j'ai essayé balsa et il ne marche pas bien... Du coup relecture sans interface sous les yeux, je vous fait confiance pour la traduction des éléments de l'interface.... Bruno Bruno Brouard -- Ceci est un message automatique envoyé par l10n.gnome.org.

1 0

yelp - master
by noreply＠gnome.org 10 Nov '10

10 Nov '10

Bonjour, L'état du module yelp - master - po (français) est maintenant « Relu ». http://l10n.gnome.org/vertimus/yelp/master/po/fr Désolé, mais je n'ai pas pu vérifier les raccourcis clavier. Sur le reste, pas grand chose à dire. Geode -- Ceci est un message automatique envoyé par l10n.gnome.org.

1 0

banshee - master
by noreply＠gnome.org 10 Nov '10

10 Nov '10

Bonjour, L'état du module banshee - master - help (français) est maintenant « Traduit ». http://l10n.gnome.org/vertimus/banshee/master/help/fr Voici ma traduction et mes remarques : 1-certaines entrées du menu ne sont pas traduites dans l'interface, j'ai donc laissé le texte en anglais pour l'instant pour une meilleure compréhension 2-je travaille avec un très vieux P4 et très peu de mémoire : je ne peux pas faire tourner Gimp et ses extensions script pour faire des captures d'écran, désolé. Il y en a une à faire dans ce module 3-pour la même raison, je n'ai pas pu charger la bibliothèque de Banshee (ça bloque mon CPU à 100%). Je n'ai donc pas pu tester certaines fonctionnalités comme le moteur de recherche par exemple. AlainLojewski -- Ceci est un message automatique envoyé par l10n.gnome.org.

1 0

Aller à la page :

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Gnomefr