Traduc

traduc@traduc.org

2 participants
2805 discussions

Info
by Jean-Philippe MENGUAL 18 Nov '10

18 Nov '10

Salut à tous, En traduisant une doc, ça renvoie à "info bash". Ça me fait penser que je n'ai jamais vu de pages d'info, ni de paquet info lui-même traduit. Cela dit je les utilise rarement aussi. D'où ma question: y'a-t-il un projet de traduction des pages info? Le soft a-t-il une traduction? Y'a-t-il un paquet du type manpages-fr? Merci de l'éclairage. Cordialement, Jean-Philippe MENGUAL

3 3

La Gazette: publications
by Gaël Montreuil 13 Nov '10

13 Nov '10

Bonjour à tous... juste un point sur les articles mis en ligne sur la Gazette: Revue des principaux environnements de bureau Linux - trad. moi - rel. Jean-Philippe Guérard La magie et la panique - trad. Luc Mioulet - rel. appzer0 La prochaine génération de jeux Linux - GLTron et Armagetron Advanced - trad. Thibaut Lorrain - rel. moi Signatures aléatoires avec Mutt - trad. Camille Saillard - rel. moi L'art subtil du réglage (et du domptage) de Firefox - trad. Thibaut Lorrain - rel. moi Partage d'un clavier et d'une souris avec Synergy (seconde édition) - trad. Hervé Ly-Sunnaram - rel. moi Un guide « revisité » sur GNU Screen - trad. Eric Deschamps - rel. moi De nouvelles options dans le monde de la compression de fichiers - trad. Renaud Flavigny - rel. moi more to come! Bonne soirée, GM Coordinateur Gazette -- identifiant PGP: 69CCC5E4

1 0

[ABS] lien mort
by Eric Deschamps 11 Nov '10

11 Nov '10

Bonjour, Ce message est destiné aux membres de l'équipe ABS. L'entête de http://abs.traduc.org/ pointe sur http://pgsql-fr.tuxfamily.org/ qui ne mène nulle part. En dehors de ça j'utilise quand je le peux ce guide que je trouve excellent. Bonne fin de journée et bonne continuation ! Éric

2 1

Traduction de bfd 2.20.90
by Frédéric Marchal 10 Nov '10

10 Nov '10

Bonsoir, J'essaie de traduire le fichier po de bfd 2.20.90 mais c'est un vrai cauchemar. Le texte contient de nombreux nouveaux messages de ce style: shlstoff : %5u, shrimgcnt : %5u codeadroff: %5u, lpfixoff : %5u qrelfixoff: %5u, lrelfixoff: %5u\n blkend: size: 0x%08x\n rtnbeg\n setfile %u\n Dans certains cas, on peut deviner les mots qui ont été massacrés et agglutinés pour former les messages mais dans d'autres cas c'est carrément mission impossible. De plus, il y a de nombreux mots qui sont issus de spécifications, des constantes ou qui sont des fonctions: psect, USRSTACK, PRVFXD ou set_line_num(w). Quelqu'un aurait-il déjà rencontré ce cas de figure ? Si oui, quelle solution a été appliquée pour traduire les messages ? Puisqu'il s'agit d'une application assez techniques, est-il choquant de laisser les messages les plus torturés en anglais ou peut-être partiellement en français (par exemple: « rtnbeg » devient « début rtn ») ? Frédéric

3 2

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

09 Nov '10

> >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). Il faut d'abord signaler que, même en anglais, make utilise parfois un vocabulaire assez technique, ce qui ne facilite pas le travail de traduction. Un tel exemple de message énigmatique en anglais est "Profiling timer expired" pour lequel on trouve la traduction "Compteur de profiling expiré". Si on regarde, sur la page de man de signal(7), on trouve pour exactement la même expression la traduction "Expiration de la temporisation pour le suivi" qui sonne déjà un peu plus français. Le mot "suivi" est-il un mot conventionnellement adopté pour "profiling" (je crois par exemple que le québec utilise plutôt profilage) ? Le mot "temporisation" est-il la traduction conventionnelle pour "timer" (comparé par exemple à "minuteur" ou "sablier", voire "alarme" dans ce contexte) ? Puisque l'expression "Profiling timer expired" est assez technique (elle informe de la réception du signal SIGPROF), pourquoi ne pas être carrément technique et traduire (par exemple) en "Réception du signal d'expiration du délai de profilage (SIGPROF)". Idem pour "Virtual timer expired" qui pourrait devenir par exemple "Réception du signal d'expiration de l'alarme virtuelle (SIGVTALRM)" plutôt que "Compteur virtuel expiré". Si l'on compare les traductions de make 3.82 et de make 3.81 on peut constater des améliorations très notables à mettre à l'actif du responsable actuel (par exemple "supporté" qui devient "pris en charge"). Il me semble qu'il reste cependant quelques traductions héritées du passé qui continuent de sonner un peu bizarre. Par exemple, ne serait-ce pas plus naturel de traduire "make" par "construire" plutôt que par "fabrication", ce dernier évoquant plutôt une production matérielle, et "recipe" par "action" ou "action à effectuer" plutôt que littéralement par "recette" ? Aussi, plutôt que de traduire "target pattern contains no `%%'" en "le motif de cible ne contient pas « %% »", ne serait-ce pas plus "français" avec un "la cible ne contient pas le motif « %% »" ? Autre exemple encore : "attempt to use unsupported feature: `%s'" ne serait-il pas rendu de manière plus naturelle par "fonctionnalité non gérée : « %s »" que par "tentative d'utiliser une caractéristique non prise en charge : « %s »" ? Une des autres expressions techniques de make est la notion d'"archive member". Veut-on vraiment la traduire par "membre d'une archive" ? Il me semble que, a minima, une expression telle que "élément d'archive" serait meilleure. Enfin, même si la plupart des ":" sont maintenant précédés d'un espace, il en reste une demi-douzaine qui restent "à l'anglaise" (avec aussi un " " manquant après le "unlink:" qui devrait donc être je crois un "unlink : "). Hugo Herbelin

5 5

ping
by Eric Deschamps 09 Nov '10

09 Nov '10

La liste est bien silencieuse, ces temps-ci, que se passe-t-il ? Éric

8 10

relecture de nano 2.2.4pre2
by goofy＠babelzilla.org 30 Oct '10

30 Oct '10

Des bricoles à rectifier : http://translationproject.org/PO-files/fr/nano-2.2.4pre2.fr.po ligne 202 Aucun de motif de recherche défini > Aucun motif de recherche défini ligne 587 Le fichier a été modifié après que vous l'ayez ouvert. Voulez-vous vraiment sauvegarder ? > après que vous l'avez ouvert ligne 1870 Si l'utilisation de « Tab. » pour compléter les noms de fichier n'a pas été désactivé > désactivée ligne 3275 et toute autre personne que nous aurions oublié... > oubliée hop - Goofy -- Think Global, Make Locales!

2 1

Gazette: bio des auteurs
by Gaël Montreuil 30 Oct '10

30 Oct '10

Bonjour, faisant de la relecture je suis tombé sur un article où manque la traduction de la bio de l'auteur. Pour cet article et pour la suite, pensez-vous qu'il soit possible que tous les traducteurs mettent en commun les traductions de bios, afin que les bios ne soient pas inutilement retraduites à chaque fois? GM Coordinateur Gazette -- identifiant PGP: 69CCC5E4

3 8

TR: Launchpad.net [Bug 608631] Visual tag to represent narrow non-breaking spaces
by verdy_p 30 Oct '10

30 Oct '10

Nouvel essai d'envoi de copie suite à discussions sur une autre liste. Certes vous avez sans doute déjà discuté de pas mal de points, mais c'est transmis dans l'état. normalement ce message aurait du passer. Avertissement ce message est long car il contient une suite de messages et en référence d'autres. > 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

Utilisation inappropriée du symbole copyright dans la traduction de la Linux Gazette
by Denis Barbier 29 Oct '10

29 Oct '10

Bonjour, Dans certains articles, les traducteurs ajoutent des symboles © après tout nom de marque, par exemple dans http://ftp.traduc.org/doc-vf/gazette-linux/html/2009/160/lg160-B.html http://ftp.traduc.org/doc-vf/gazette-linux/html/2009/159/lg159-A.html http://ftp.traduc.org/doc-vf/gazette-linux/html/2009/158/lg158-B.html http://ftp.traduc.org/doc-vf/gazette-linux/html/2008/157/lg157-B.html http://ftp.traduc.org/doc-vf/gazette-linux/html/2008/155/lg155-A.html C'est très irritant et parfaitement inutile (et ils ne sont pas dans la V.O.), serait-il possible de les enlever ? Merci. Denis

4 6

Aller à la page :

2026

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

2000

Traduc