Bon alors après test:
remplacer les entités par les caractères unicode est bien une solution. OmegaT va bien conserver ces caractères et les transférer dans les segments cibles.
Maintenant, ce n'est pas vraiment pratique car lors de la traduction on ne voit pas forcément ce caractère: Ex.: on ne voit pas directement le &nbthinsp; car il apparaît dans OmegaT sous sa forme d'espace fine donc pas très distinguable de l'espace normale...
Conséquence: on risque de l'écraser.
Mais comment résoudre ce problème autrement? Ma solution de béotien serait de rendre visible ces caractères, comme ils apparaissent parfois, dans un carré.
Ma solution actuelle reste pour le cas du Docbook Gazette l'ajout manuel à la fin de la traduction.
Gaël
On 04/12/2011 15:25, Jean-Christophe Helary wrote:
Gaël,
Je te transmet la réponse de Didier, je me couche maintenant. Si tu as une idée pour les séquences "officielles" de DocBook fais moi signe.
JC
Begin forwarded message:
From: "Didier Briel" d.briel@free.fr Date: December 4, 2011 11:08:37 PM GMT+09:00 To: "Jean-Christophe Helary" jean.christophe.helary@gmail.com Subject: RE: [Traduc] Gazette traduction par OmegaT
Bonjour Jean-Christophe,
Non il les fait sauter j'ai put constater qu'il remplaçait les par un espace; les &nbthinsp; par un espace; il semble virer les
—
nbthinsp est définie dans le document, c'est un cas à part.
Pour les autres, elles sont peut-être définies dans DocBook, mais pas directement en tout cas.
Je veux dire que la DTD (http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd) ne les contient pas, elles le sont peut-être par des include.
Je n'en suis pas certain. Tu as une liste de référence ?
Pour nbthinsp, j'ai un petit carré dans OmegaT, le caractère (qui doit être absent de mes polices) est donc bien reconnu.
Je retrouve bien le petit carré dans /target donc, de ce côté là, il semble que tout va bien.
Je suppose que tu utilises des fichiers DocBook ? Dans ce cas l'ensemble
du processus est traité par des librairies spécialisées en XML donc le comportement que tu décris est étonnant,
Au contraire. Comme on utilise des bibliothèques XML, on ne se comporte pas comme VI.
Ou les entités existent : elles sont transformées en caractères affichables dans OmegaT, et seront présentes comme caractères affichables dans le document cible (donc, leur forme entité disparaîtra de toutes façons). Ou les entités n'existent pas : elles sont supprimées ou transformées en espaces selon les cas, il faudrait tracer en détail pour voir quelles circonstances conduisent à supprimer ou transformer en espace. De toutes façons, ce n'est pas très important.
Si pour une raison quelconque on ne reconnaît pas les entités, on se trouve dans le cas 2.
Une solution simple est de remplacer les " entités " (guillemet, parce que je ne suis pas certain qu'elles soient déclarées dans DocBook) *avant* de traduire par leur équivalent à coup de recherche et remplace ou de script.
Pour des geeks linuxiens, ça doit prendre 5 minutes d'écrire ça avec SED.
Didier
Jean-Christophe Helary
fun: http://mac4translators.blogspot.com work: http://www.doublet.jp (ja/en > fr) tweets: http://twitter.com/brandelune
Afficher les réponses par date
Gaël,
Bon alors après test:
remplacer les entités par les caractères unicode est bien une solution. OmegaT va bien conserver ces caractères et les transférer dans les segments cibles.
Oui.
Maintenant, ce n'est pas vraiment pratique car lors de la traduction on ne voit pas forcément ce caractère: Ex.: on ne voit pas directement le &nbthinsp; car il apparaît dans OmegaT sous sa forme d'espace fine donc pas très distinguable de l'espace normale... Conséquence: on risque de l'écraser.
Je suis d'accord avec toi.
Mais comment résoudre ce problème autrement? Ma solution de béotien serait de rendre visible ces caractères, comme ils apparaissent parfois, dans un carré.
Pourquoi pas ? Je pense que si tu choisis une police assez restreinte tu devrais avoir ce genre de rendu.
Ma solution actuelle reste pour le cas du Docbook Gazette l'ajout manuel à la fin de la traduction.
Tu peux aussi utiliser CheckMate du Okapi Framework pour effectuer des tests automatiques qui comparent les contenus de la source et de la cible. Ça te permet de ne pas trop te soucier des caractères pendant la traduction et d'avoir une indication systématique des segments qui sont non valides.
Jean-Christophe Helary ---------------------------------------- fun: http://mac4translators.blogspot.com work: http://www.doublet.jp (ja/en > fr) tweets: http://twitter.com/brandelune
-
Gaël Montreuil -
Jean-Christophe Helary