← Back to team overview

lp-l10n-fr team mailing list archive

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

 

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) ]





Follow ups

References