Traduc

traduc@traduc.org

2802 discussions

Re: [Traduc] [Bug 608631] Re: Visual tag to represent narrow non-breaking spaces
by verdy_p 28 Oct '10

28 Oct '10

> Message du 27/10/10 23:50 > De : "Nicolas Delvaux" <608631(a)bugs.launchpad.net> > A : verdy_p(a)wanadoo.fr > Copie à : > Objet : [Bug 608631] Re: Visual tag to represent narrow non-breaking spaces > > @verdy_p: please translate your comment in French and mail it to > traduc_AT_traduc_DOT_org > > We discuss about the remaining problems with NNBSP support on this > mailing-list (it's a kind of coordination list for all French > translation projects in FOSS). > > Here, it is a bug report about Launchpad. And the relative bug is now fixed. > (The [nnbsp] tag is not yet available, even in edge, but it should land soon). > > ps: as a reminder, I made this report about the current support of NNBSP: http://malaria.perso.sfr.fr/fines/fines.pdf > If you observe something different and/or want to improve it, please raise the topic on the aforementioned mailing-list. > > -- > Visual tag to represent narrow non-breaking spaces > https://bugs.launchpad.net/bugs/608631 OK. voici une traduction de mes deux commentaires envoyés à Lauchpad.net sur la nécessité (qui a finalement été acceptée après moults débats...) de non seulement supporter la fine insécable dans les traductions, mais aussi de les rendre visibles dans l'interface pour les traducteurs avec une balise [nnbsp] (ce qui a été fait et sera effectif d'ici peu). L'original (posté en anglais) était dans la liste des messages du bogue lié ci- dessus. Merci Nicolas. --- [msg #3] (avant résolution du bogue) --- En fait, la balise à afficher dans une version localisée de l'interface pourrait aussi bien être [fine] si on traduit vers le français. Cela se transcrira bien sûr vers le caractère Unicode NNBSP. Et le caractère de ''fallback'' (rendu alternatif) utilisé dans les moteur de rendu (texte/police) doit D’ABORD être le caractère THINSP quand il en existe un mappage dans une police (car les polices n'encodent pas elles- même la propriété sécable/insécable, et parce que cette propriété est mise en œuvre en fait dans le moteur de rendu ou de mise en page.) Autrement, le moteur de rendu ou de mise en page devra établir un fallback en utilisant un avance de la moitié de celle de l'espace standard (SPACE) mappé dans la police (le mappage de THINSP est très fréquent dans les polices depuis longtemps, alors que celui de NNBSP est très peu fréquent et même a été abandonné, par exemple il a été ajouté dans "Times New Roman" très tôt par Microsoft, mais pas dans la police plus récente "Segoe UI" pour Windows 7, considérant que c'était inutile...) Le mappage vers NBSP (U+00A0) ne sera mis en place que dans des moteurs de rendu non graphiques tels que les émulations de terminal ou consoles ou les programmes qui exporte du texte brut via un encodage non-Unicode des caractères qui ne dispose d'une espace fine (sécbale ou non), car il est plus important de préserver une largeur d'espace quelconque mais aussi de préserver la propriété insécable, même si nombre de terminaux en mode texte brut ignorent totalement les propriétés de sécabilité et ne font aucune rupture de ligne intelligente mais peuvent couper une ligne après n'importe quel caractère même en milieu de mot. concernant GetText, un ''patch'' pourrait être ajouté de façon à ce qu'il retourne des chaînes après conversion vers un encodage cible autre qu'Unicode (mais je ne pense pas qu'il s'agit d'une tâche de GetText lui- même, car une telle conversion de l'encodage fait plutôt partie des bibliothèques de transcodage). Ce n'est pas à getText de modifier l'encodage, et en fait il n'a besoin que de retourner le texte tel qu'il est encodé dans les fichiers sources .po/.pot avant qu'il soit compilé dans une forme binaire efficace. Si GetText traite les fichiers .po/.port, ces fichiers devraient seulement être encodés dans un encodage qui est *compatible* avec le jeu invariant ISO 646 IRV (seulement pour en détecter correctement la syntaxe), afin de pouvoir correctment trouver les sauts de lignes, les signes égal, les barres obliques inverses (''backslashes'') et les croisillons qui débutent les lignes de commentaires et les directives signalées juste après ce croisillon avec un caractère de ce sous-jeu limité de l'ASCII. C'est pourquoi GetText peut être utilisé de façon trnsparente sur les fichiers de resources encodés aussi bien comme fichiers textes Windows ou Unix (CR+LF ou CR seulement), utilisant ASCII ou toute partie de l'ISO 8859, ou toute page de code Windows "ANSI" ou "OEM/PC", ou tout codage des normes chinoises GB, ou tout jeu extrait de la norme indienne ISCII. Avec des changements mineurs (utilisant un remappage bijectif 1-à- 1), il peut aussi fonctionner avec des fichiers de ressources encodées avec toute page de code EBCDIC. Ce que cela signifie c'est que c'est à l'application cliente utilisant ces ressources de savoir avec quel encodage elles ont été encodées. La plupart cependant devraient être encodées avec Unicode et toute application aujourd'hui devrait être capable de transcoder depuis Unicode vers *leur* encodage « naturel » utilisé dans l'application et utilisé historiquement dans leurs fichiers de ressources. Et les mêmes programmes devraient aussi fonctionner sans changement en utilisant au minimum UTF-8 comme leur codage natif, même si cela signifie qu'ils devraient supporter des caractères codés sur des longueurs variables, ou devraient être capable de travailler de façon interne avec UTF-16 (avec des "caractères" codés sur au moins 16 bits). (Pourquoi les normes C/C++ refusent encore d'honorer cette contrainte, et ne définissent toujours pas des types standards avec une taille minimale de 16 bits pour travailler sans perte avec des unités de code UTF- 16, ou avec un type standard de 21 bits minimum pour travailler avec des unités de code UTF-32, est toujours un mystère pour moi, alors que la nombre d'autres langages ont défini des types de données avec des tailles binaires standard, et notablement au moins une taille fixe de 16 bits pour ce qu'ils appellent un "char", traité différement des autres entiers.) Notez que le séparateurs des milliers est définitivement pas THINSP (car il est sécable), mais aussi NNBSP (alias notre « fine » française). Si THINSP est encore utilisé sans quelques logiciels, c'est parce que quelques moteurs de rendus ou de mise en page dépendent encore des polices pour mettre en œuvre le caractère NNBSP avec avec un mappage vers quelque glyphe d'espacement, et ces moteurs oublient d'utiliser des "fallbacks" par défaut vers THINSP quand ce dernier est mappé dans les polices (la plupart des polices d'usage général contiennent un mappage pour THINSP, mais toujours pas pour NNBSP dont le support s'est en fait même réduit ! En témoigne ce qu'a fait Microsoft en n'incluant pas NNBSP parmi la liste des caractères que les concepteurs de polices pour Windows devraient inclure dans le mappage de leurs polices ; et je pense que Microsoft à ce sujet a eu raison : la seule différence entre NNBSP et THINSP est l'insécabilité, et cette dernière ne fait de toute façon pas partie des propriétés prises en compte par les polices). En fait le comportement par défaut (la sécabilité) de THINSP était une erreur initialement commise par Unicode dans ses propriétés de caractères. THINSP aurait du être le caractère à utiliser mais Unicode a ajouté des propriétés de sécabilités (qui ne font par partie de la norme ISO 10646 elle-même) en oubliant ce caractère parmi les caractères dotés de l'insécabilité lorsque THINSP a été encodé au début, et les polices n'avaient pas non plu à être conçues pour tenir compte de cette propriété (puisque ce n'est pas leur job) y compris pour les caractères explicites de rupture de ligne (comme CR, LF, ou autre FF!) Le caractère NNBSP a été ensuite rejeté plusieurs fois par le groupe de travail international en charge de l'ISO 10646, considérant que THINSP était destiné à jouer ce rôle. Cependant ils ont du se rendre à l'évidence et admettre que THINSP ne pouvait plus être plus changé pour devenir insécable, et ont donc tardivement admis NNBSP (pour ISO 10646, les deux caractères THINSP et NNBSP restent de parfaits synonymes, la différence n'étant visible que dans les propriétés Unicode, celle de sécabilité étant normative uniquement dans Unicode). Ainsi, NNBSP n'est apparu que très tardivement, bine après que la plupart des polices par défaut conçues pour nos systèmes d'exploitation ont été conçues et inclues dans leur distributions. Mais concernant les applications qui traitent des propriétés de ressources, elles ONT bien besoin de la propriété correcte de sécabilité. Dans tous les cas, les fichiers de ressources ne doivent en aucun cas utiliser THINSP mais toujours NNBSP, quel que soit le langage (THINSP lui-même, tel qu'il est encodé sécable, n'a aucune utilité pratique démontrée dans n'importe quelle langues). Aussi il nous faut mener campagne non pas pour que les polices soient mises à jour pour supporter le mappage de NNBSP (c'est en fait inutile et en fait beaucoup trop compliqué et plus long à obtenir pour corriger des milliers de polices), mais afin que les moteurs de rendu et de mise en page (ils sont peu nombreux et font partie des bibliothèques des systèmes, souvent portables, et incluses aussi dans les navigateurs web) soient mis à jour pour supporter correctement le comportement insécable de NNBSP (et de tous les caractères insécables d'Unicode 5), et qu'ils reflètent aussi l'apparence visuelle en tant que simple espacement (sans même avoir besoin d'un glyphe à dessiner), en utilisant seulement les métriques du caractère THINSP de fallback (quand il est mappé) ou la moitié de l'avance de l'espace standard SPACE (presque toujours présent dans toutes les polices). Les polices ne devraint alors plus besoin non plus de définir un mappage pour NBSP. Et tout ce dont elles auraient besoin c'est la plupart du temps de ne plus définir que l'esapce ASCII standard afin uniquement d'en définir l'avance métrique. Bref c'est au moteur de rendu ou de mise en page de déduire ces mappages par défaut, même s'il reste possible à certaines polices de définir un mappage qui pourrait être nécessaire avec certains designs spécifiques. --- [msg #37] (après résolution) --- En réponse au message #35. Cela n'a aucune importance que le caractère soit incorrectrement rendu ou pas (concernant le support du balisage par [nnbsp] dans l'interface de Launchpad.net et aussi par extension sur TranslateWiki.net qui a le même problème). La décision d'inclure ou non le caractère NNBSP fait partie d'une politique ou convention de codage qui devra être revue au sein de chaque projet de traduction (moins en fonction de la langue de ce projet que du support logiciel sous-jascent). Et quand Bruno Patri a dit que le caractère NNBSP était rendu comme un losange dans les terminaux TTY, cela n'a guère de sens, car cela dépend d'autres facteurs qui dépendent avant tout des conversions de jeux de caractères qui ont lieu soit en seun de l'émulateur de terminal, soit dans son moteur d'affichage, soit encore du côté serveur dans les paramètres de localisation de l'utilisateur connecté à ce serveur, ou des poaramètres de locilisation de ce serveur, ou encore dans l'intégration du terminal su le système (les polices installées, mais surtout comme on l'a vu le moteur de rendu). La plupart des émulateurs de terminaux utilisés aujoudrd'hui supportent UTF-8 comme l'encodage de choix sur le réseau, comme aussi dans les serveurs d'applications (au moins les distributions Linux ou FreeBSD et, maintenant depuis des années, Sun/Oracle Solaris ou IBM AIX). Le problème principal n'est pas en fait la présence de NNBSP dans les ressources traduites, qui de toute façon pouvait déjà être introduit dans les ressources, mais dont le manque de différenciation, quand il était saisi, ne permettait de savoir là où il était présent : c'est pour ça qu'on avait demandé un indice visuel dans l'interface de traduction de Launchpad.net (également demandé dans TranslateWiki.net et à demander dans d'autres systèmes similaires). C'est alors bien à chaque projet de traduction de déterminer quels caractères ils acceptent. La plupart des navigateurs ont maintenant un rendu correct de NNBSP, aussi il n'y a plus de raison de le rejeter (l'affichage correct des espacements est en fait un minimum demandé maintenant pout HTML5 qui décrit plus précisément les propriétés de caractères Unicode que les navigateurs devraient supporter, ce qui comprend la reconnaissance de la propriété d'insécabilité et la propriété d'espacement blanc, deux propriétés qui sont définies comem STABLES dans Unicode, et qui sont aussi nécessaires aussi pour mettre en œuvre IDNA correctement et sûrement). Pour les environnements qui ne supportent pas les sorties codées en Unicode et qui dès lors doivent effectuer des conversions de jeux de caractères codés, ce travail sera à réaliser dans les bibliothèques de conversion (telles que libiconv, ICU, ou les API Windows de conversion MBCS/SBCS pour le support des pages de code). Les terminaux ne devraient pas avoir à se préoccuper eux-mêmes de ces caractères, masi la chaîne correcte d'identification du jue de caractère utilisé doit être préservée. APrès tout, les mêmes terminaux auront des problèmes similaires (et en fait plus compliqués et plus sérieux) s'ils ne procèdent pas ainsi pour l'affichage correct du chinois, du russe, de l'hébreu, des écritures indiennes ou du thaï, et ne devraient donc pas avoir à interdire le caractère NNBSP afin d'obtenir un affichage acceptable. Des polices libres et des moteurs de rendu libres ont disponibles (de même que des équivalents dans les systèmes commerciaux) et devraient être mis à jour pour supporter ensemble ces caractères, même si une police n'a pas nécessairement à supporter NNBSP mais seulement THINSP (y compris dans Windows 7 où par exempel "Segoe UI" n'inclue que THINSP dans sa table de mappage, alors que "Times New Roman" définit depuis longtemps un mappage pour NNBSP qui était fourni déjà dans Windows Vista et dans des services packs pour Windows XP ou pour MS Office : cela n'est plus nécessaire pour Windows 7 qui garantit dans son moteur de rendu système que NNBSP affichera la même glyphe que THINSP quand il est mappé, et peut émuler tous les autres caractères d'espacement et supporter la propriété de sécabilité dans tous les caractères présents au moins dans Unicode 5.0 au moins). Qt est sans aucun doûte en retard sur ce support, mais je pense que c'est tout bonnement car il ne met pas en œuvre le moteur de rendu du texte lui-même mais dépend encore de vieilles versions de moteurs de rendus liés par des bibliothèques mal identifiées sur les systèmes qu'il supporte et pour lequel il a été contruit ou porté. Cela provoques les différences de traitement qu'on a vu selo le système sur lequel on exécutait une application Qt). Qt sur Windows fonctionne bien maintenant et affiche NNBSP correctement, même si la police "Segoe UI" ne mappe pas ce caractère. Un tel mappage par défaut (fallback) peut aussi être réalisé sur les serveurs de polices X11 pour Linux/FreeBSD et autres *nix, même si la bibliothèque du moteur de rendu ne l'implémente pas lui-même (cela ne nécessitera pas nécessairement de mettre à jour les polices elles-mêmes, surtout quand nombre d'entre elles ne sont pas libres ou leurs mise à jour est difficile). Une mise à jour de XFree86 (ou similaire) pourra résoudre le problème facilement (de telles mises à jour sont maintenant fréquentes pour des raisons de sécurité et cela a été facilité par des services de mise à jour système aujourd'hui proposés pour être utilisables par presque tout le monde sans entrer dans les détails techniques ni avoir à installer un compilateur ou recompiler les packages puis les installer ou déboguer ce qui ne marche pas lors de la compilation). Il est de meˆme trsè simple aujourd'hui de mettre à jour son émulateur de terminal (Xterm/telnet et similaires) car ce sont des applications clientes de base qui n'ont que très peu ou pas du tout de dépendance avec le système de base et qui fonctionnent entièrement dans le domaine utilisateur (et non au niveau du noyau, comme cela se fait encore dans Windows pour sa "console" qui intègre le rendu et les conversions de jeux de caractères, ainsi que quelques fonctionnalité de gestion de terminal, avec certaines parties du code incluses dans le noyau de démarrage du système de base). Les seuls environnements restants seront ceux des interfaces de systèmes embarqués avec des capacités de rendu limitées (et souvent pas facile ou presque impossible à mettre à jour). Le besoin de NNBSP est suffisamment démontré que l'on devrait demander le support à leur constructeur (pas facile quand on voit que des constructeurs connus comme Philips, Nokia, LG.... ont encore du mal à supporter déjà tous nos caractères acentués, par exemple "ë / ï / ö / ô" dans les sous-titrages de télévision, dans les noms de chaînes TV HD, dans les jeux proposés pour les SMS...) afin qu'il l'intègre à leur firmwares (on voit là encore le problème des systèmes propriétaires, y compris ceux construits sur des systèmes libres mais dont ils n'ont rien fait pour que ces systèmes soient facilement mis à jour par des tiers et qui n'assurent aucun support réel pour ce qu'ils considèrent comme mineur, tout en ne mettant pas non plus en place un réel support en ligne pour leurs utilisateurs. Mais rien ne se passera chez ces constructeurs de systèmes embarqués s'il n'y a pas d'incitation externe poussant leurs auteurs à prendre en charge la fonctionnalité. Le mieux qu'on puisse faire c'est de documenter les usages qui sont déjà faits, montrer là où ça marche déjà et promouvoir les systèmes qui fonctionnent avec la fonctionnalité demandée afin qu'elle soit de plus en plus utilisée et que son absence soit reconnue comme une réelle anomalie. Grace aux corrections qu'on va demander et obtenir, ils sauront que ce qui manque est réellement demandé et ce qui est attendu par les utilisateurs: s'ils ont été capables d'adapter leurs applications et systèmes pour le chinois simplifié ou traditionnel, ou le coréen, le japonais, l'hébreu ou même simplement le russe ou le bulgare, ils ne devraient plus avoir de difficulté à gérer correctement un simple espacement (et tant qu'à faire tous les espacements d'Unicode 5.0 au moins) et la propriété d'insécabilité de tous les caractères Unicode 5 qui en disposent, ce simple espacement insécable étant en fait nécessaire et utilisé depuis des siècles dans des langues truès utilisées comme le français, l'espagnol ou le russe. quelqu'un doit commencer le travail (évitons la question de la poule et de l'œuf, ou même celle de la charrue avant les bœufs). Les autres suivront rapidement et de plus en plus vite ensuite. On ne progressera jamais si chacun commence par regarder ce que les autres n'ont pas fait (et en fait les premiers pas les plus importants ont été largement faits maintenant par les 5 navigateurs majeurs du marché et dans Windows, ainsi que dans quelques environnement Linux). Il n'est donc pas raisonnable de bloquer le caractère dans Launchpad (et tant pis s'il reste quelques applications non remises à jour qui n'affichent pas le caractère correctement ou au moins d'une façon lisible et acceptable). Il est même sans doûte souhaitable de rendre cette anomalie de manque de support visible d'une façon ou d'une autre afin de pousser les auteurs de ces environnements à proposer des corrections mais aussi pousser les utilisateurs les plus résistants à mettre à jour leurs systèmes: même s'il y a des raisons légitimes pour eux de ne pas mettre à jour, cela ne tiendra pas dans le cas des nouvelles traductions qu'on proposera qui implique de toute façon que ces mêmes utilisateurs "rétifs" aux mises à jour ont déjà installé une version récente d'un logiciel (et donc effectuent des mises à jour). Alors qu'en fait cette décision de bloquer (pour un temps seulement) des caractères ne doit dépendre que de chaque projet de traduction et de la façon dont le projet est réutilisé. On doit mesurer l'impact bénéfices/risques, sachant que les risques en question ne sont pas ceux (légitimement bloquants) liés à la sécurité des systèmes, et en tout cas les bénéfices en terme d'interopérabilité ou d'accessibilité et lisibilité seront supérieurs. La plupart des projets accepteront ce caractère sans problème pour la très grande majorité des emplois qui en sont faits (les autres attendront un peu avant d'appliquer une mise à jour, le temsp que eux aussi s'adaptenr et finissent eux aussi à accepter un caractère bien utile, et que chacun convienne que finalement on conçoit mal comment on avait pu résister à cette évolution). La plupart de ces projets pourront créer et intégrer leur propre petit "patch" sans grande difficulté (soit en mettant à jour les bibliothèques dépendantes, ou en ajoutant des exceptions dans leurs propre code pour supporter tous les espacements d'Unicode 5, ou en intégrant dans leur distribution des polices compatibles avec un mappage explicite du caractère, ou en changeant leurs propres convertisseurs intégrés de jeux de caractères (libiconv par exemple a le support nécessaire, et la mise à jour ne nécessite que l'installation ou le remplacement d'un unique fichier sur le système, ou au pire dans le répertoire de l'application si l'accès au système est limité et nécessite une installation "parallèle" spécifique à l'application, comme cela se fait maintenant couramment sur Windows qui permet à une même bibliothèque d'être installée dans plusieurs versions selon les applications qui en ont besoin ; dans les faits, cela se produit déjà avec les mises à jour des navigateurs Internet, qui constituent de plus en plus une brique de base de tous les systèmes d'exploitation destinée à construire de plus en plus nombreuses applications). Il faut aussi reconnaître que maintenant plus de la moitié du web utilise Unicode et que les anciens jeux de caractères 8 bits (y compris les jeux multipages comme ceux des normes GB chinoises) sont maintenant dans une phase de décroissance et d'abandon rapide (nombre de sites ont converti jusque y compris leurs bases de données). Le point déclenchant de cette évolution a été la décision de l'IETF de rendre le support d'UTF-8 obligatoire dans toutes les nouvelles normes transportant du texte, et en même temps de nombreuses corrections apportées dans les protocoles existants afin d'identifier correctement et supporter Unicode. certains protocoles demandent des changements très complexes (cas de l'IDNA et du protocole DNS en général), mais cela ne concerne qu'une toute petite partie des données textuelles du web, et de plus en plus une partie de moins en moins visible par nombre d'utilisateurs (merci aux moteurs de recherche et à l'intégration dans les navigateurs de moyens fiable d'identifier correctement des noms de domaine "sûrs"). Les environnements de bureau X11 ont aussi fait de gros progrès pour supporter de nombreuses langues et écritures. Plus de 60% des emails échangés sont maintenant codés en Unicode, tandis que le contenu du web commence à être de plus en plus interactif avec une part sous la forme de contenus vidéo qui a explosé et représente déjà le tiers des volumes échangés (Un rapport publié par Cisco récemment en semtembre indique déjà que la consommation de bande passante réalisée aujourd'hui par seulement une vingtaine de "foyers moyens" représente autant de volume que la totalité des échanges sur Internet dans le monde entier en 1995 ! Si vous voulez je retrouverai la référence) On voit donc que face à cette évolution, il a fallu mettre à jour la quasi totalité des systèmes pour accéder à ces contenus, et qu'il n'y a en fait que très peu de résistance au changement. Mettre à jour n'est plus un problème mais une nécessité. Et toutes ces mises à jour sont maintenant entièrement dépendantes, au plan technique, du support correct d'Unicode, dont le support (au minimum UTF-8 pour les protocoles Internet de l'IETF, et par la suite aussi dans les autres languages et systèmes utilisés pour s'y connecter) a été rendu obligatoire. Toutes ces technologies dont l'usage explose (et la part énorme et explosive prise par la Chine dans ces échanges) ne viennent qu'affirmer qu'on ne doit plus se limiter aux anciens jeux ASCII ou ISO 8859. Les caractères NNBSP et THINSP sont une partie microscopique des changements nécessaires. Il n'y a pas lieu de les refuser. Conclusion : avançons et ne nous bloquons plus là-dessus. On n'aura même pas besoin de réellement faire compagne pour que les utilisateurs mettent à jour leurs systèmes, puisqu'ils le font déjà massivement et personne ne contestera ce support, mais de plus en plus nombreux seront ceux qui incendieront les équipes de supports de produits qui refusent de telles changements mineurs et aujourd'hui faciles à intégrer. --- [Conclusion] D'autres messages sont à consulter sur la page de commentaires du bogue sur "Visual tag to represent narrow non-breaking spaces" https://bugs.launchpad.net/bugs/608631 Je n'ai pas traduit la totalité des échanges (en anglais), juste deux de mes messages avec quelques insertions ici (en gardant l'esprit général). L'important est maitenant pour beaucoup de savoir que Launchpad.net supporte officiellement NNBSP en y apportant une facilité destinée aux traducteurs afin qu'ils puissent facilement en identifier l'usage (et que d'autres vont suivre...) Parmi les points évoqués par Nicolas Delvaux dans son document référencé dans sa réponse #38, figure son très intéressant rapport: http://malaria.perso.sfr.fr/fines/fines.pdf Cependant il semble avoir oublié une autre cause de certaines des irrégularités qu'il mentionne : * le support des conversions de jeux de caractères (libiconv et similaire) : comment ils traitent un caractère manquant dans un jeu de caractères codés non Unicode. * ou leur identification dans les protocoles de transport quand ce n'est pas Unicode (ce problème n'est pas spécifique à NNBSP mais est toujours le même que celui qui se produit depuis longtemps pour afficher correctement les caractères NON-ASCII, y compris nos lettres accentuées, ou les autres écritures non latines). Il ne devrait plus être nécessaire d'utiliser autre chose que l'UTF-8 pour le stockage ou le transport, même pour des applications non-web et des systèmes "non connectés". Et la plupart des systèmes utilisent UTF-16 pour leurs traitements interne du texte (ECMAScript, DOM, Java, ...) à l'exception encore de C/C++ (qu'attend encore l'ANSI pour établir un type standard fiable pour les UTF standards ?), et PHP/MediaWiki (dont les situations sont encore ambiguës pour identifier les jeux de caractères utilisés). Philippe.

1 0

sources de la gazette ?
by Jean-Christophe Helary 28 Oct '10

28 Oct '10

Où se trouvent les sources des articles anglais ? Jean-Christophe Helary ---------------------------------------- fun: http://mac4translators.blogspot.com work: http://www.doublet.jp (ja/en > fr) tweets: http://twitter.com/brandelune

12 37

gazette, sources 2
by Jean-Christophe Helary 28 Oct '10

28 Oct '10

Sur le site anglais, il n'existe que des sources en HTML. http://linuxgazette.net/ftpfiles/ J'aimerai savoir pourquoi il est nécessaire que l'équipe française impose le DocBook pour la traduction d'un document qui finalement pourrait être traduit directement dans le HTML. Et non seulement on impose le DocBook, mais en plus il faut créer le document à partir de zéro. C'est n'importe quoi. Il existe des outils modernes pour traduire dans les formats de type HTML/DocBook directement et on impose au traducteur un format qui n'est pas le format source... Forcément, en travaillant comme ça, il faut bien 2 mois pour se farcir un article. On veut faire fuir les traducteurs ? Jean-Christophe Helary ---------------------------------------- fun: http://mac4translators.blogspot.com work: http://www.doublet.jp (ja/en > fr) tweets: http://twitter.com/brandelune

7 9

Fwd: Re: Relecture de la gazette, la balle dans le pied.
by Renaud Flavigny 27 Oct '10

27 Oct '10

Le 27/10/2010 13:21, Gaël Montreuil a écrit : > On 26/10/2010 21:34, Renaud Flavigny wrote: >> >> Le 26/10/2010 19:12, Gaël Montreuil a écrit : >> C'est un bonne idée de limiter l'attribution d'un article pour la >> traduction. J'ai personnellement eu le regret de ne pas pouvoir prendre >> des articles qui m'intéressaient et qui sont restés 'coincés'. >> Je trouve même que deux mois c'est long. Les articles de la gazette sont >> en général courts et ne nécessitent que quelques heures de travail pour >> la traduction. De plus, le rythme de publication de la Gazette est >> mensuel, il faudrait un rythme de traduction proche. Plutôt que de >> relancer l'impétrant traducteur, je suggère un fonctionnement par défaut >> : un mois après l'attribution d'un article, soit la traduction a été >> fournie on passe à l'étape suivante, soit le traducteur demande un jeton >> supplémentaire d'un mois car il est toujours intéressé mais a manqué de >> disponibilité on repart pour un tour, soit il ne se manifeste pas et >> l'article redevient attribuable ce qui n'empêche pas les distraits de >> demander à ce qu'il leur soit réaffecté. > Merci Renaud d'avoir commenté le délais. Que ce soit deux mois avec ton > système ou le miens, cela revient a peu près au même. Je pense donc > partir sur ce temps, en l'absence d'avis contraire. > Tu retiens le délai qui te semble le plus approprié, toutefois la différence entre nos deux propositions tient principalement au travail à fournir par le coordonnateur (en l'occurrence toi). Je suggère simplement d'attendre que le traducteur se manifeste soit pour fournir un livrable dans le délai soit pour demander une rallonge alors que tu te propose de faire des relances régulières : c'est plus de boulot et ça nécessite plus de régularité dans l'ordonnancement du processus. En gros dès que tu affectes un article, tu te mets dans une seringue et tu prend un engagement de faire quelque chose. Maintenant, dans la mesure où c'est toi qui fait (ou pas) tu choisis ! Cordialement R.

1 0

Mise à jour de util-linux-ng
by David Prévot 27 Oct '10

27 Oct '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Salut Milan, Nicolas et la liste, En faisant le tour de traductions à mettre à jour, je remarque qu'aucun traducteur n'est officiellement responsable de util-linux-ng, bien que Nicolas s'en soit occupé jusqu'à il y a un an, et que Milan ait apparemment pris le relais il y a peu, et qu'il reste encore quelques (centaines de) chaînes non traduites. Je me permet du coup de demander, Milan, si tu as l'intention de continuer sur ta lancée, ou si Nicolas s'en chargera ? Amicalement David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkzHnLYACgkQ18/WetbTC/rzXwCgg6j9WGp7KcpqhKkkxxsCfEij bKEAn2kPQ7GshLtHRhxMDUD+ZhSJvuc7 =E08k -----END PGP SIGNATURE-----

3 4

relecture de util-linux-ng 2.18-rc2
by goofy＠babelzilla.org 27 Oct '10

27 Oct '10

Des petits trucs dans util-linux-ng-2.18-rc2.fr.po : ligne 1421 Impossible d'allouer un tampons pour les inodes > tampon ligne 7795 type de ressource inconnue: %s\n > inconnu ligne 9098 mount : attention : %s semble être monté en lectur-écriture\n > lecture ligne 10260 et 10367 no filename specified. Aucune option --date spécifié.\n > Aucun nom de fichier spécifié ligne 10362 no action specified Aucune option --date spécifié.\n > Aucune action spécifiée ligne 10556 %s fournits des informations sur les services pour lesquels vous avez des droits d'accès en mode lecture.\n > fournit ligne 10707 ------ Mémoire partagé Créateur/Dernière-opération --------\n > partagée ligne 10843 ------ Messages: lmites --------\n > limites ligne 215 Formattage en cours ... > Formatage ligne 229 Lecture: > Lecture : ligne 524 Désirez-vous réellement continuer? > Désirez-vous réellement continuer ? ligne 715, 753, 758, 767, 904, 919, 924 etc. * espaces manquants avant les deux-points ligne 1259 Impossible d'allouer un tampons pour les inodes > tampon ligne 1367 Taille erronée d'entête de swap, aucune étiquette n'a été écrite.\n > en-tête ligne 2474 Utilisation intéractive:\n > interactive ligne 3349 comme un volume entête > en-tête ligne 3597 Si vous désirez ajouter des partitions de type DOS, créer d'abord > créez ligne 3662 a été altérée!\n > a été altérée !\n ligne 4343 En détruire/réduire quelques unes > quelques-unes lignes 4479 et 4515 Etendue > Étendue ligne 5240 celles au delà > au-delà lignes 5301 et 5404, 5490 numbre > nombre ligne 5321 Aucun espace pour en accepter d'avantage\n > davantage ligne 5494 Vous pouvez désactiver toutes les vérifications de consistence avec: > cohérence avec : ligne 5615 Identifcateur erroné %lx\n > Identificateur ligne 5673 I don't like these partitions - nothing changed.\n Ces partitions sont questionnables -- rien n'a changé.\n > Ces partitions sont discutables -- rien n'a changé.\n ligne 5893 -a, --alternative parmettre les options de forme longue avec un simple -\n > permettre ligne 6017 On assume que l'horloge matérielle est conservée > On suppose ligne 6084 Heure lu de l'horloge > lue ligne 6121 Aucune option --date spécifié.\n > spécifiée ligne 6190 L'horloge matérielle ne contient de temps valide, aussi on ne peut pas initialisé l'heure du système à partir d'elle.\n > ne contient pas de > aussi ne peut-on pas > initialiser ligne 6234 Pas d'ajustement du facteur de dérive parce l'horloge matérielle contient déjà des donnéez corrompues.\n > parce que > données ligne 6239 L'hitorique étant erroné > historique ligne 6296 Ajustement des paramètres de dérive n'ont pas été mis à jour.\n > Les paramètres d'ajustement de dérive etc. ligne 6336 et présumément ne tournant pas sur un Alpha > et ne tournant probablement pas ligne 6475 Vous ne pouvez qu'en exécuter une à la fois. > Vous ne pouvez en exécuter qu'une à la fois. ligne 6499 %s: avec --noadjfile, vous devez spécifier soit --utc ou --localtime\n > soit localtime ligne 6524 Ne peut accéder l'horloge matérielle > à l'horloge ligne 6599 select() de %s dont l'attente d'un tic d'horloge a expiré le délai de la minuterie\n > a dépassé le délai ligne 6873 Caractères de contrôle ne sont pas permis.\n > Les caractères de contrôle ne sont pas permis.\n ligne 7164 You have new mail.\n Vous avez du courrier.\n > Vous avez un nouveau message.\n ligne 7241 Nombre escessif de sauts de page (linefeeds) > excessif ligne 7347 Le système sera arrête d'ici 5 minutes > arrêté ligne 7356 réamorçé par %s: %s > réamorcé ligne 7570 %s: MAUVAISE EEREUR > %s: ERREUR GRAVE ligne 8099 %s: erreur d,arguement, usage\n > d'argument ligne 9438 ; reste du fichier ignorée > ignoré lignes 10094 et 10103 nombre maxumum > maximum ligne 10148 Ne peut inialiser > initialiser lignes 10435-10440 etc. traduction de queue > file d'attente ligne 10598 ------ Limites de la mémoire partagé --------\n > partagée ligne 10633 pages alloués %ld\n > allouées ligne 10684 Mémoire partagé > partagée ligne 10873 en-têtes utilisées = %d\n > utilisés ligne 11564 gèrant l'alarme RTC > gérant ligne 12213 : !commande non autoirisée en mode rflag.\n > autorisée hop - Goofy -- Think Global, Make Locales!

1 0

relecture de bison-2.4.3.fr.po
by goofy＠babelzilla.org 27 Oct '10

27 Oct '10

De menues coquilles deci-delà : http://translationproject.org/PO-files/fr/bison-2.4.3.fr.po GNU bison 2.4.3-rc1 ligne 300 opérande superflue « %s » > superflu ligne 443 déclaration précédante > précédente lignes 673 et 678 symbole « %s » utilisé plus d'une fois dans une chaîne litérale > littérale ligne 723 paramètre %s ambiguë pour %s > ambigu ligne 738, 743, 748 la cache > le cache ligne 796 Could not open stats file for writing. Ne ouvrir en écriture le fichier de stats. > impossible d'ouvrir le fichier de stats en écriture. hop - Goofy -- Think Global, Make Locales!

2 1

Re: [Traduc] Relecture de la gazette (Re: La Gazette change de coordo)
by Hugo Herbelin 26 Oct '10

26 Oct '10

On Tue, Oct 26, 2010 at 09:55:14PM +0200, Denis Barbier wrote: > Le 26 octobre 2010 18:36, Hugo Herbelin a écrit : > > J'ai évidemment pu voir les coordonnées du traducteur actuel, mais ma > > question de procédure sur la remontée de bug est plus > > générale. D'ailleurs, au moment où j'ai commencé à faire face à des > > problèmes de traduction de make, c'était la version 3.81 et en > > fouillant un peu sur le web, je n'avais pas eu l'impression que le > > précédent responsable fut très réactif (cf > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468281 qui montre le > > problème et qui m'a conduit à m'abonner à traduc). > > Et pour cause : > http://listes.traduc.org/pipermail/traduc/2007-April/005000.html Ah, je vois. > Je suppose qu'on vous a conseillé d'écrire au traducteur, en mettant > éventuellement en copie traduc, ce n'est pas exactement pareil. Pour > l'instant, rien n'indique que le traducteur actuel a reçu le message. C'est fait, j'ai transmis mon message au nouveau coordinateur. > > Sur la procédure donc, je pense que l'utilisation d'un outil > > asynchrone d'archivage de discussions serait un plus pour > > l'accélération du processus de correction des éventuels problèmes de > > traduction. Je pense typiquement à un gestionnaire de bogue, ce qui > > est facile à installer (cf encore l'exemple du gestionnaire de debian, > > qui, s'il n'avait pas existé, ne m'aurait pas permis de savoir que > > d'écrire au responsable d'alors de la traduction make revenait à > > écrire dans le vide, ou, launchpad, tout aussi bien). > [...] > > Bof, ce n'est pas vraiment fiable ; puisque le traducteur a changé, il > est probable que l'actuel est plus réactif, alors que ça ne > transparait pas dans les logs du rapport de bogue. Ce n'est pas qu'une question de réactivité. Mais peut-être que j'attache aussi trop d'importance au cas des outils GNU historiquement pas toujours très bien traduits alors que peut-être, dans le cas général, une fois la traduction bien stabilisée, il n'y a plus grand chose à faire. Hugo Herbelin

2 1

Re: [Traduc] Relecture de la gazette (Re: La Gazette change de coordo)
by Hugo Herbelin 26 Oct '10

26 Oct '10

On Tue, Oct 26, 2010 at 03:30:31PM +0200, Denis Barbier wrote: > Le 26 octobre 2010 12:41, Hugo Herbelin a écrit : > >> >En tant qu' « utilisateur » de traductions, je soutiens entièrement > >> >cette approche. Juste une question toutefois : comment fait-on pour > >> >faire remonter les bogues ? Typiquement, quels sont les projets traduc > >> >qui à l'heure actuelle offrent un canal pour permettre aux > >> >« utilisateurs » de communiquer avec les traducteurs ? > >> > > >> >Hugo Herbelin > >> >(lecteur passif de la liste qui se réjouit très vivement du nouveau > >> >souffle pris par traduc cette année !) > >> > >> Bonjour, > >> > >> Cette liste me semble adaptée à la remontée de erreurs, d'autant que > >> ça nous permet de discuter des erreurs et des corrections. > > > > Oui, il y avait eu un échange sur cette question il y a quelques mois > > et c'est ce que l'on m'avait suggéré de faire. > > > > Alors d'accord, je m'adresse à la liste... > > > > Un des problèmes de traduction auquel j'ai été confronté en tant > > qu'utilisateur est celui de la traduction de l'outil make (qui fait > > donc partie du projet de traduction des logiciels GNU, cf lien > > http://www.traduc.org/Projet_de_traduction). > [...] > > Bonjour, > > Je ne comprends pas, vous avez été capable de trouver que le > responsable de la traduction avait changé, mais vous ne connaissez pas > ses cordonnées pour le contacter directement ? > Elles apparaissent sur http://translationproject.org/domain/make.html > ainsi qu'au début des fichiers make-*.fr.po accessibles depuis cette > page. J'ai évidemment pu voir les coordonnées du traducteur actuel, mais ma question de procédure sur la remontée de bug est plus générale. D'ailleurs, au moment où j'ai commencé à faire face à des problèmes de traduction de make, c'était la version 3.81 et en fouillant un peu sur le web, je n'avais pas eu l'impression que le précédent responsable fut très réactif (cf http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468281 qui montre le problème et qui m'a conduit à m'abonner à traduc). Sur la procédure, une communication bilatérale entre un traducteur et un lecteur peut être efficace, et si c'est la procédure préconisée par traduc, pourquoi pas. Dans le cas présent, si j'ai écrit à traduc, c'est qu'on m'avait suggéré d'écrire à la liste. Sur la procédure donc, je pense que l'utilisation d'un outil asynchrone d'archivage de discussions serait un plus pour l'accélération du processus de correction des éventuels problèmes de traduction. Je pense typiquement à un gestionnaire de bogue, ce qui est facile à installer (cf encore l'exemple du gestionnaire de debian, qui, s'il n'avait pas existé, ne m'aurait pas permis de savoir que d'écrire au responsable d'alors de la traduction make revenait à écrire dans le vide, ou, launchpad, tout aussi bien). Bref, un forum stable tel que celui fourni par les gestionnaires de bogues : - permettrait, en gardant une trace des problèmes soulevés, de travailler de manière asynchrone, sans que le traducteur ait besoin d'agir en direct et d'avoir à faire une gestion particulière de son courrier pour garder trace de ce qui est problème en cours, - permettrait des discussions multilatérales sur certaines difficultés de traduction, ce qui n'empêche pas les traducteurs ou relecteurs, en tant que responsables, d'avoir le dernier mot sur les discussions, - permettrait une adéquation optimale de la bande passante du media aux personnes concernées sans introduire de bruit comme se serait le cas si le media était une liste générale comme traduc, ni de perte d'information comme ce serait le cas avec des échanges bilatéraux, - n'empêcherait pas toute personne intéressée par superviser l'ensemble des traductions d'être au courant de ce qui se passe (ou ne se passe pas) en s'abonnant aux listes de diffusions correspondantes, - permettrait rapidement de déterminer si un projet de traduction ou de maintenance de traduction est actif et d'agir en conséquence. > Absolument, d'ailleurs les problèmes que vous soulevez avec ces « > timer expired » ne sont pas tant des erreurs de traduction que des > imprécisions dans les messages en anglais. L'idéal serait de les > corriger, ça simplifierait ensuite la traduction. C'est souvent un > traducteur qui signale le problème quand il bute sur une traduction. > Vos suggestions semblent pertinentes, il faudrait que vous les envoyez > au traducteur, qui, même s'il est censé lire cette liste, peut ne le > faire qu'en diagonale et de surcroit filtrer les messages en fonction > de leur sujet. Bonne idée, j'ai envoyé un rapport de bogue (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601474). Hugo Herbelin

2 1

relecture de gnunet-gtk-0.8.1
by goofy＠babelzilla.org 26 Oct '10

26 Oct '10

Bonjour, De menues bricoles dans ce fichier http://translationproject.org/PO-files/fr/gnunet-gtk-0.8.1.fr.po ligne 441 et 449 Traffic entrant Traffic sortant > trafic ligne 569 Veuillez lire le exte > texte ligne 1945 Arrêter la recherche et ferme l'onglet > fermer hop - Goofy -- Think Global, Make Locales!

1 0

Aller à la page :

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Traduc