← Back to team overview

lp-l10n-fr team mailing list archive

Re: [Fwd: re:  [admin] série spéciale  vacances]

 

Concernant Launchpad j'ai ouvert ce bug :
https://bugs.launchpad.net/rosetta/+bug/608631 (si j'ai le temps
j'essaierais de jeter un œil au code source pour voir si un patch est à
ma portée)

Concernant l'auto-suggestion, il existe ce bug que j'ai mis à jour :
https://bugs.launchpad.net/rosetta/+bug/36977


Pour le reste (remplacement des nnbsp par des nbsp si non supportés), il
faudrait voir s'il n'y a pas déjà un bug de reporté contre gettext et le
reporter sinon.
Vu que tu sembles t'y connaitre bien mieux que moi sur le sujet, ça te
dérangerais de t'en charger ?

Nicolas

ps : Laissons les THINSP de côté pour le moment, ils me semblent avoir
moins d'importance.
Il n'y a pas énormément de HTML sur Launchpad et puis c'est en poussant
derrière nnbsp que son support s'améliorera ;)


Le jeudi 22 juillet 2010 à 10:12 +0200, verdy_p a écrit :

> Tout ceci pour dire que, concernant la stabilité des traductions, c’est bien NNBSP qu’il faudrait coder de 
> préférence partout et non NBSP (qui n’est là que comme une solution de pis-aller temporaire destinée juste à palier 
> les défauts ou limitations des anciens logiciels) :
> 
> 
> * (1) Le remplacement de NNBSP par NBSP peut être effectué automatiquement dans les anciens logiciels qui ne le 
> supportent pas (limités encore à ISO 8859) mais qui utilisent GetText via une sur-API chargée de faire cette 
> substitution.
> 
> ** (1.1) Par exemple pour les logiciels qui fonctionnent en ligne de commande et dont la « locale » ne supporte pas 
> l’intégralité du jeu universel UCS de Unicode/ISO/IEC 10646.
> 
> ** (1.2) Ces substitutions de toute façon sont plutôt destinées à être faites par les émulateurs de terminaux et 
> consoles de type VT220/ANSI (quand il reçoivent une chaîne de caractères codés dans une forme UTF et doivent 
> restreindre le jeu à un codage plus faible).
> 
> ** (1.3) Ces substitutions en définitive devraient à terme être même évitées dans les logiciels eux-mêmes qui 
> devraient être neutres quand au jeu de caractère codés à utiliser, même s’ils peuvent obtenir du terminal 
> d’entrée/sortie des informations quant au jeu de caractères et au codage qu'il supporte ou nécessite, cette 
> information n’ayant strictement rien à faire dans les données de traduction et localisation (qui devraient 
> uniquement supporter le jeu universel et rien d’autre, et probablement uniquement être codées en UTF-8).
> 
> 
> * (2) Les logiciels qui génèrent du HTML à partir des ressources de traduction peuvent automatiquement baliser par 
> un ... et substituer alors NNBSP automatiquement par THINSP (qui est très 
> bien supporté dans les polices des principaux navigateurs web)
> 
> ** (2.1) À terme cette substitution automatique deviendra vite totalement inutile (les distributions récentes de 
> Linux ou les version récentes de Windows ou MacOSX incluent déjà des polices par défaut et/ou des moteurs de rendus 
> qui feront la substitution d’eux-mêmes, si le glyphe associé au caractère NNBSP est absent de la police 
> sélectionnée), et sera parfois trop verbeuse en code HTML/CSS généré, quand le texte complet contenant la ressource 
> est inclu dans un élément HTML déjà totalement insécable; par exemple l’indication d’un attribut de style CSS ou 
> d’une classe CSS au sein de la cellule de table ou du paragraphe destiné à recevoir le texte de la (ou des) 
> ressource(s) qui y sera (seront) inclue(s).
> 
> ** (2.2) Une telle substitution pourra donc être désactivée (au moins la génération du span pour le CSS) dans le 
> logiciel pour gagner en performance, cette substitution étant plutôt du ressort des moteurs de rendu du texte, même 
> s'il restera encore une substitution éventuelle de NNBSP par THINSP.
> 
> 
> Concernant LaunchPad lui-même (à améliorer sur ces points) :
> 
> * Eh oui, il faudra demander à Launchpad qu’il affiche spécialement [NNBSP] et non 
> le caractère NNBSP lui-même, pour afficher les endroits où NNBSP est codé dans les ressources, comme il le fait déjà 
> pour [NBSP].
> 
> * Et au passage il pourrait aussi le faire pour d’autres espaces codées dans Unicode, en affichant leur nom 
> symbolique abrégé entre crochets (par exemple [EMSP], [ENSP], [QUADSP], [THINSP], etc..), avec éventuellement une 
> localisation possible, en minuscules, du nom symbolique en fonction de la langue de l’utilisateur (par exemple dans 
> l’interface francophone il pourrait afficher « [fine] » simplement au lieu de l’abscond « [NNBSP] ».
> 
> * Et il devrait de la même façon le faire pour d’autres caractères de « contrôle de format » Unicode comme les 
> contrôles de comportement directionnel (adéquats dans certaines ressources, mais non recommandés pour les ressources 
> destinées à être utilisées en HTML qui leur préfère nettement l’attribut « dir="rtl/ltr" » là où l'indication de la 
> langue seule par l'attribut « lang="..." » ne suffit pas), afin de bien signaler au traducteur leur présence dans le 
> texte codé (il le fait déjà pour les espaces normales répétées ou en fin de ligne, et pour les contrôles de saut de 
> ligne, en les remplaçant par une image ou une puce colorée). Ces contrôles de format sont parfois nécessaires avec 
> certaines langues à écriture bidirectionnelle (arabe, hébreu, etc.) afin d’éviter les effets de bords à l’affichage 
> des caractères à « direction faible » (comme les parenthèses en fin de ressource, ou les chiffres arabo-européens en 
> tête de ressources) lorsuqe l’algorithme standard «BiDi» d’Unicode ne parvient pas à résoudre les ambiguités.
> 
> * L’interface de traduction peut déjà forcer (à l’affichage ou la modification des ressources) la direction 
> d’écriture à utiliser *par défaut* pour le couple (langue, écriture) normalement ciblé par la traduction (et 
> paramétré par le code de « locale » comme "fr" (direction "ltr" par défaut pour l’écriture latine) ou "az-Arab" 
> (direction "rtl" par défaut pour l’écriture arabe), afin d’éviter des contrôles de format non nécessaires pour 
> forcer la direction d’écriture: l’encapsulation éventuelle de la ressource textuelle dans de tels contrôles de 
> format (ou par d’autres moyens comme un style CSS "bidi-override:" ou un attribut HTML dir="rtl/ltr") est du ressort 
> du logiciel utilisant la ressource selon la façon dont il va l’employer (et GetText, ou bien une sur-API propre au 
> logiciel et basée sur GetText, devrait pouvoir retourner automatiquement pour chaque ressource si elle commence ou 
> finit par des caractères de direction faible et ambigüe, et pourra éventuellement réaliser automatiquement cette 
> encapsulation selon les indications et le format souhaité par le logiciel utilisant cette sur-API).
> 
> * Ce n’est pas à LaunchPad de déterminer comment la ressource traduite sera utilisée, mais il doit signaler au 
> traducteur la présence éventuelle de ces caractères problématiques, qui ne devraient normalement jamais être 
> nécessaires dans les ressources traduites elles-mêmes (à charge pour le concepteur du logiciel de découper 
> correctement les ressources à traduire, puis de générer les encapsulations, concaténations et réordonnancements 
> nécesaires selon la langue, en utilisant des variables de substitution pour les éléments inclus à direction ambiguë, 
> à l’aide de ressources séparées mais recombinées par une ressource formatée contenant ces variables de substitution 
> (dont notamment les éléments syntaxiques à ne pas traduire et qui devraient eux aussi être totalement absents des 
> textes originaux à traduire : si c’est le cas, signaler ces inclusions « parasites » aux concepteurs du logiciel 
> afin qu’ils découpent plus convenablement ces ressources, et permettre de documenter dans LaunchPad la ressource à 
> traduire afin de signaler ces inclusions particulières nécessitant un formatage spécial à conserver absolument dans 
> la traduction).
> 
> * Pour chaque langue cible de traduction, LaunchPad devrait aussi pouvoir proposer des substitutions automatiques en 
> affichant des valeurs alternatives propres aux règles orthographiques établies pour une langue ; par exemple en 
> français il détectera automatiquement toutes les séquences de SPACE+":" qui n'utilisent pas encore NNBSP en 
> permettant de voter immédiatement pour la forme corrigée, là où elle sera plus appropriée, et il pourrait aussi 
> tenter de proposer des substitutions pour le cas où aucune espace n’a été codée. Cela pourrait aussi être un 
> dispositif d’alerte et de confirmation préventive, avant même la validation définitive par le traducteur (afin 
> d’éviter des erreurs et de ne pas forcer non plus la substitution immédiate là où elle serait inappropriée).
> 
> Philippe.
> 
> > Message du 21/07/10 20:50
> > De : "Nicolas Delvaux" 
> > A : "lp-l10n-fr@xxxxxxxxxxxxxxxxxxx" 
> > Copie à : 
> > Objet : [Lp-l10n-fr] [Fwd: re:  [admin] série spéciale  vacances]
> > 
> > Je me permet de transférer à la liste, car c'est intéressant.
> > (faut faire gaffe avec les ML de Launchpad, par défaut le champ réponse
> > est pour l'expéditeur, et pas seulement la liste). 
> > 
> > -------- Message transféré --------
> > De: verdy_p 
> > Reply-to: verdy_p 
> > À: Nicolas Delvaux 
> > Sujet: re: [Lp-l10n-fr] [admin] série spéciale vacances
> > Date: Tue, 20 Jul 2010 23:39:46 +0200 (CEST)
> > 
> > 
> > Le seul ennui avec l'espace insécable, c'est que le code U+00A0 (NBSP : NON BREAKING SPACE, alias " " en HTML) 
> > n'est même pas le bon pour le français, et que celui qui conviendrait le mieux devrait être l'espace FINE 
> insécable. 
> > Et selon les logiciels, il n'est pas toujours possible de l'utiliser. En HTML par exemple la caractère représenté 
> > par " " est bien une fine, mais il n'est PAS insécable.
> > 
> > Si on prend MediaWiki, il recommande de ne PAS l'utiliser du tout et de coder une espace normale. Il fera lui-même 
> > la substitution de la séquence ESPACE plus ponctuation finale, ou ponctuation initiale plus ESPACE en choisissant 
> > automatiquement le caractère approprié à utiliser (pour l'instant c'est encore NBSP qui est utilisé, mais d'autres 
> > options surviennent en HTML car avec CSS on peut contrôler l'insécabilité.)
> > 
> > L'alternative étant le caractère représenté en HTML par &nnsbsp; (NNBSP : NARROW NON-BREAKING SPACE en Unicode), 
> > mais son support dans les polices de caractères est encore trop peu répandu (et n'est pas abolument nécessaire non 
> > plus en HTML si on utilise CSS).
> > 
> > Bref divers choix de représentation pour la fine insécable française :
> > 
> > - SPACE avec substitution automatique (contextuelle? ne marche pas bien pour la fine insécable utilisée comme 
> > séparateur de groupes de chiffres)
> > - NNBSP (si supporté par les polices)
> > - THINSP avec ajout de mise en forme insécable en CSS
> > 
> > et dans ce cas l'espace insécable U+0A0 (NBSP) est la pire des solutions, surtout en HTML où il sert aussi à autre 
> > chose, notamment pour remplir des cellules vides de tableaux, ou comme support de base des diacritiques cités 
> > isolément (conformément à la recommandation Unicode) !
> > 
> > L'idéal étant bien le caractère NNBSP: faudra-t-il revoir à terme toutes les traductions françaises pour remplacer 
> > toutes les ocurences de NBSP par NNBSP ?
> > 
> > Bref ne pas en faire une théologie. Chacun fait avec ce qu'il peut selon ce qu'il sait afficher. NNBSP gagne son 
> > chemin petit à petit, mais encore trop de logiciels libres sont incompatibles Unicode et ne peuvent pas supporter 
> > NNBSP, ce qui nécessiterait pour eux un filtrage avec substitution automatique de NNBSP par NBSP.
> > 
> > Philippe.
> > 
> > > Message du 20/07/10 21:17
> > > De : "Nicolas Delvaux" 
> > > A : "lp-l10n-fr@xxxxxxxxxxxxxxxxxxx" 
> > > Copie à : 
> > > Objet : [Lp-l10n-fr] [admin] série spéciale vacances
> > > 
> > > Salut,
> > > 
> > > avec beaucoup de retard j'ai finalement « liquidé » la série précédente.
> > > Mais, pas de chance (enfin ça dépend du point de vu ;)) il y a
> > > maintenant 4 nouveaux candidats en attente.
> > > 
> > > Voyons ça :
> > > 
> > > https://translations.launchpad.net/~lorkscorguar
> > > 
> > > Il est expérimenté.
> > > Mais j'ai relevé plusieurs fautes grossières comme « à été fermé
> > > » ( https://translations.launchpad.net/androidsfortune/trunk/+pots/fortune/fr/61/+translate )
> > > De plus il n'utilise pas d'espaces (et donc encore moins insécables)
> > > devant les signes de ponctuation.
> > > Et puis certaines de ses tournures me semblent douteuses.
> > > 
> > > Je dirais donc non.
> > > 
> > > 
> > > https://translations.launchpad.net/~stanislas-michalak-live
> > > 
> > > Moins expérimenté que le précédent.
> > > Mêmes problèmes également.
> > > Donc même vote.
> > > 
> > > https://translations.launchpad.net/~steve.grosbois
> > > 
> > > idem.
> > > 
> > > https://translations.launchpad.net/~thibaultfevry
> > > 
> > > C'est le candidat le plus expérimenté qu'on ait eu jusqu'à présent.
> > > Pas d'espaces insécables. (Grr, ça va finir par m'énerver)
> > > Mais à part ça je n'ai pas vu de problème (mais il y en a trop, je n'ai
> > > pas pu tout regarder).
> > > 
> > > Je serais donc pour.
> > > 
> > > 
> > > 
> > > J'ai l'impression d'être plus sévère aujourd'hui.
> > > Si ça ne tenait qu'à moi, je considèrerait le non emploi d'espaces
> > > insécables comme étant éliminatoire (ba oui, d'un côté ça veut quand
> > > même dire que la personne n'a même pas lu les règles de traduction).
> > > Mais j'ai bien conscience que certains membres du groupe ne les
> > > utilisent pas eux même, donc ça serait injuste.
> > > Il faut répandre la bonne parole !
> > > 
> > > Il faut vraiment que je (ou quelqu'un d'autre) trouve le temps d'envoyer
> > > un rappel des règles de traduction sur la ML de la communauté.
> > > 
> > > 
> > > Bonne soirée,
> > > Nicolas
> > > 
> > >
> > > [ (pas de nom de fichier) (0.2 Ko) ]
> > 
> > 
> > 
> > -- 
> > Nicolas Delvaux 
> > 
> >
> > [ (pas de nom de fichier) (0.2 Ko) ]
> 


Attachment: face-wink.png
Description: PNG image


Follow ups

References