Tag pour l'espace fine insécable dans Launchpad

[Bruno Patri]

Le vendredi 8 octobre 2010 09:38:31, Nicolas Delvaux a écrit :
> > J'ai bien compris que c'était upstream qu'il fallait convaincre et que
> > 
> > > vous suivrez automatiquement le mouvement.
> > > 
> > > Je ne veux parler ici que de l'outil de traduction Launchpad. Et de ce
> > > point de vu je conçois assez mal que l'on puisse être contre l'ajout
> > > d'une fonctionnalité.
> > 
> > Je suis contre l'ajout de cette fonctionnalité parce que le bénéfice
> > (amélioration visuelle mineure) me paraît très faible par rapport aux
> > problèmes qu'elle risque d'engendrer.
> 
> Visiblement on ne se comprend pas, quels problèmes peut causer cette
> fonctionnalité si on attend que tout soit au point upstream pour
> l'utiliser ? Il s'agit juste d'adapter Launchpad pour qu'il soit prêt le
> moment venu !

AMHA, c'est prendre le problème à l'envers. La logique voudrait que l'on 
introduise cette fonctionnalité dans Launchpad lorsque comme tu le dis « tout 
sera au point ».
Si une fonctionnalité est présente, il est à peu près sûr qu'elle va être 
utilisée. Il tout aussi probable qu'elle soit utilisée là où il ne le faut pas 
(dans une application Qt par exemple).
Donc nous allons introduire un nouveau marqueur sur Launchpad et expliquer aux 
contributeurs que nous avons un nouveau marqueur pour les espaces insécables 
plus respectueux des règles typographiques, mais qu'il ne faut pas l'utiliser, 
ou plutôt si on peut l'utiliser mais pas partout.
Partant du constat que beaucoup de contributeurs débutants s'interrogent sur 
ces règles typographiques et l'emploi des espaces insécables ; que la lecture 
de FAQ ou documentations à rallonge rebute ; je pense que cela n'est 
clairement pas une bonne idée.


> > S'il est normal que ubuntu-l10n-fr suivent les règles des équipes de
> > 
> > > traduction upstream, il n'en est pas de même pour les projets
> > > indépendants qui eux sont upstream.
> > 
> > Hein ? Je ne comprends pas... Tous les projets utilisant Launchpad comme
> > interface de traduction se doivent, dans la mesure du possible, de
> > respecter les conventions de traductions en français. C'est le cas pour
> > les projets pris en charge par ubuntu-l10n-fr (docs et logiciels
> > spécifiques à Ubuntu) comme pour les autres qui doivent pouvoir
> > s'intégrer correctement quelque soit la distribution (voire la
> > plate-forme), les polices de caractères ou l'encodage utilisé.
> 
> Donc aucune évolution du dogme n'est possible, chacun attend que l'autre
> bouge avant de bouger. Je ne vois vraiment pas où est le drame si un
> projet *indépendant* décide de changer une de ses règles de traduction (et
> tu dis toi même que le changement est mineur, ce n'est pas comme si on
> adoptait les règles typographiques klingonnes !).

Je ne dis pas qu'aucune évolution n'est possible. Celle-ci est même 
souhaitable mais pas immédiatement. J'ai parlé d'amélioration visuelle 
mineure, le changement lui n'est pas sans conséquences.



> 
> ps : et le commentaire que tu as laissé sur le rapport de bug n'est pas
> très fair-play, essayer de saborder le travail effectué depuis des mois si
> prêt du but... Et puis ce n'est pas comme si tu n'avais pas été mis au
> courant de cette discussion assez tôt et que tu n'avais pas eu la
> possibilité de t'exprimer.


Désolé ce n'était pas mon intention, le commentaire du bogue et juste là pour 
exprimer une autre point de vue que le tien et mettre en garde vis à vis des 
conséquences de l'introduction de NNBSP sur Launchpad. Il n'est pas question 
de saborder ton travail, mais de différer ce changement afin d'éviter les 
problèmes.

Je me suis exprimé à plusieurs reprises, mais visiblement tu ne veux pas 
entendre mes arguments.

Je me répète, mais je pense que pour l'instant le rapport risque de 
bogues/bénéfices est trop élevé. 

-- 
Bruno