Le dimanche 29 août 2010 à 18:09 +0200, Frédéric Delanoy a écrit : 
2010/8/29 Nicolas Delvaux <nicolas.delvaux@gmx.com>:
> C'est exactement ça, si problème il y a ou que des contournements doivent
> être mis en place, c'est au niveau des convertisseurs.
> Les traducteurs devraient pouvoir utiliser des espaces fines insécables
> partout sans avoir à se poser de questions.
> Si ça devient trop compliqué, les équipes de traductions seront
> naturellement réticentes pour l'adopter (enfin j'imagine que des exceptions
> pour un ou deux programmes restes envisageables, mais il faut que ça reste
> minime et que ça soit bien documenté).
>
> Il faudrait donc faire une liste des convertisseurs X → HTML les plus
> utilisés et les tester.

Si besoin est, je peux me charger d'écrire un script convertisseur
HTML -> HTML vite fait (en ruby p.ex.) pour la conversion
- des documents dont l'original est en HTML
- pour les résultats de convertisseurs "foireux"
et le rendre disponible, p.ex. sur traduc pour que les traducteurs
l'utilisent sur leur bécane mais ça risque d'être un peu lourd.
Ou bien peut-être l'intégrer sur traduc.org avec une form + CGI p.ex.,
ou éventuellement utiliser 2 boîtes de texte et un bouton pour
convertir (avec du javascript p.ex.)... les idées sont les bienvenues
(mod_ruby?)

Mais la correction "à la base" est de toute façon préférable

Effectivement tout ce que tu proposes pourrait être utile pour du dépannage en cas de problème, mais ça va être dur de s'en contenter.
À moins que tout le monde soit super motivé pour adopter la fine (et je sais qu'il y a des récalcitrants), il faut vraiment viser l'embêtement zéro pour les traducteurs.

Et sinon, concernant tes idées de conversions HTML → HTML ou HTML "foireux" → HTML, pas la peine de trop en faire non plus.
Tu peux faire quelque chose de simple et ergonomique si tu veux, mais n'oublie pas que dans la plupart des cas un simple coup de "chercher/remplacer tout" dans un éditeur de texte lambda suffira amplement. ;-)

> Il faudrait ensuite militer auprès des développeurs concernés

Ça risque d'être compliqué : je vois mal (tous) les développeurs gérer
la typographie française en particulier; sinon, ils devraient le faire
pour d'autres langues utilisant d'autres conventions... (rien qu'en
français, les conventions typographiques en usage en France et Québec
p.ex. peuvent être différentes).
En l'occurrence il ne s'agit pas de gérer une règle typographique mais plutôt d'implémenter un contournement pour qu'un caractère Unicode soit affiché correctement sur l'ensemble des navigateurs de la planète (à peu de chose près ^^)

> pour soit :
> - remplacer automatiquement les fines par des &nbsp;
> AMHA solution la plus simple techniquement mais sémantiquement incorrecte,
> et puis à quoi bon, par exemple, mettre des fines dans les pages de man si
> elles ne sont ni affichées dans les terminaux (police à chasse fixe) ni dans
> les versions HTML ? Enfin, ça répond tout de même à la prérogative « ne pas
> se poser de questions ».

Parce que les pages de manuel ne peuvent être converties en HTML ?
Mais c'est moins primordial, je te l'accorde bien volontiers.

Et man2html ? (à moins que je n'ai pas compris)

> - utiliser des contournements comme nous l'avons vu précédemment.
> En soit cette solution ne me semble pas plus compliquée que précédemment, il
> s'agirait juste par exemple de remplacer automatiquement les fines par des
> « <span style="font-size: 50%;">&nbsp;</span> » (pas besoin de CSS comme
> ça).

Euh...le span *style*, c'est pas du CSS ?
Si, bien sûr.
Ce que je voulais dire c'est qu'ici le convertisseur n'a pas besoin de générer un *fichier* CSS uniquement pour la fine, c'est vraiment une simple substitution d'un caractère par une chaine ;-)

En tous cas, c'est probablement la seule solution viable dans
l'immédiat, même si la plus lourde...

> Le seul inconvénient ici est que le code généré est plus lourd. À voir si
> c'est vraiment bloquant (modifie-t-on souvent manuellement les fichiers HTML
> générés ?)
> [...]
> Oui, et le grand avantage de HTML c'est qu'il nous offre des solutions de
> contournement, contrairement aux bibliothèques graphiques (qui à dit Qt ?)
>
> Nicolas

Dans l'immédiat, je pense qu'il faudrait
- identifier les différents types de documents de traduc à
traiter/examiner (texte pur, man, po?, docbook, fichiers "info",
latex?) utilisés par Traduc
- identifier les convertisseurs -> HTML/PDF principaux et leur
comportement (ex: man2html, latex2html, ...)


À mon avis il faudrait déjà identifier les convertisseurs qui sont *vraiment* utilisés et surtout ceux qui sont utilisés « automatiquement » (dans des scripts pour mise en ligne automatique...).
Par exemple un site comme celui-ci ( http://www.delafond.org/traducmanfr/index.php ) est fondé sur man2html.
Vis à vis de l'espace fine insécable man2html devrait donc être vérifié et, si besoin, corrigé en priorité.

À contrario, il est à mon avis très rare de convertir de LaTeX vers HTML. De plus, d'après mon expérience, le résultat obtenu est tellement passable que l'on doit de toute façon re-modifier manuellement le fichier obtenu (on peut donc en profiter pour corriger les espaces fines au passage). Il est du coup, je pense, tout à fait acceptable que latex2html et consorts soient en bas de liste (voir qu'on ne s'en préoccupe pas pour le moment).

Bref, c'est une sorte d'appel à témoignage : quels convertisseurs X → HTML utilisez vous ? Devez vous systématiquement modifier le code généré ?

En parallèle, vérifier que les convertisseurs fonctionnent (ou pas),
et rapporter d'éventuels bugs.
Les anciens documents déjà traduits ne devraient être "fine"-ifiés que
lors d'une mise à jour AMA.
Bien entendu.
(sauf si des personnes sont suffisamment motivées pour "fine"-ifier à la chaine ;-))

Nicolas