Object Design
Home | Profile       FrameMaker | XML | Docbook | DTP | Java | Jython | Python | Markdown | GoogleAppEngine
Home > Index > Trados WinAlign で翻訳メモリをつくる(試行錯誤中...)

Trados WinAlign で翻訳メモリをつくる(試行錯誤中...)

Trados 2007 Freelance にWinAlignという原文と訳文を整合するツールがあります。 対象となるドキュメントがXML(Docbook v4.4)だった場合に、 これを使って翻訳メモリをつくる場合の考え方。

何も考えずに処理するのはどうかと

WinAlignは整合ツールと言われているが何を整合するかというと、 原文と訳文を整合します。

つまり原文ドキュメント中のある部分（セグメント）が翻訳ドキュメント中のどこに該当するのかを 整合すると。

実際に使ってみると、しかし意外にズレます。 人間であれば内容を見て整合させられるので、ズレていることはすぐわかるのですが、 WinAlignは（たぶん）内容は見ていないで、出現順等のいくつかのアルゴリズムで 整合させてきますので、そのアルゴリズムでフォローしきれないデータをWinAlignに 処理させると、期待した結果が得られません。

もちろん、WinAlignはズレが生じることは見越していて、その部分は人間が内容を見て 整合作業をしてください（マウスでクリックして、原文と訳文の対応セグメントを線でつなぎ直す という結構地味＆面倒なことをしなければなりません）ということになっていて、 それはそれでよい方法・・・というかそうするより他に方法がないので、仕方ないとは思いますが。

WinAlign与えるデータを工夫することで、この手間を少しでも減らせないか考えます。

対象ドキュメントがXMLの場合

現在のプロジェクトで翻訳メモリを作り出したいドキュメントはXML(Docbook v4.4)で記述されているので、 何も考えずにそのXMLデータをWinAlignに放り込んで処理させるより、もっとよい方法があるように思えます。

またセグメントの整合の話から離れますが、 WinAlignで整合させてできた翻訳メモリは（普通にTagEditorから生成されるメモリもそうですが） そのセグメント中に含まれる要素(タグ)...たとえば inlinegraphic などは そのままメモリに含まれます。

これでいいのかどうかちょっと気になります。
つまり、この翻訳メモリを使って次回翻訳作業をしたときに、 翻訳メモリ中に含まれているタグがそのまま適用されてしまったときにそのタグは本当に意図した内容なのかな？ ということです。 まあケースバイケースなので、翻訳メモリの使用目的にあわせて、タグを含めたり除去したりするしかないのでしょうが。

XML(Docbook v4.4)を前処理

  1. インライン要素となる < graphic > , < inlinegraphic > , < indexterm > , < xref >, < superscript > , < subscript > などは削除しておく
  2. セグメントが適切に区切られるように改行位置を調整

1)インライン要素の削除

次のようなxslを使ってXML文書中からインライン要素を削除します。

<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform" >


    <xsl:template match="@*|node()" >
        <xsl:copy>
                <xsl:apply-templates select="@*|node()" />
        </xsl:copy>
    </xsl:template>


    <xsl:template match="graphic" />
    <xsl:template match="inlinegraphic" />
    <xsl:template match="indexterm" />
    <xsl:template match="xref" />


    <xsl:template match="superscript" >
        <xsl:apply-templates />
    </xsl:template>
    <xsl:template match="subscript" >
        <xsl:apply-templates />
    </xsl:template>




</xsl:stylesheet>

※superscript や subscript は単純に削除するのではなく、テキストはそのまま残すように変換しています。

2)改行位置の調整方法

XML文書に対して適切な位置に改行を入れるには、XMLの扱えるエディタ等を使えばよいと思います。
わたしの場合は、jdom の org.jdom.output.Format.getPrettyFormat() を使って整形しました。 (InDesignで書き出したXML文書の整形)

JDOMのgetPrettyFormat()では、要素の閉じタグの後に改行が入るため、 あらかじめインライン要素を削除しておくことにより、 結果として、セグメントの区切り＝改行として適切な位置に改行が入ることになります。

インライン要素がそのまま残っていると、改行位置とセグメントの区切りがこちらの 意図通りにはなりません。

まとめ

ここで試した方法は、 前処理として、 セグメントの区切りに改行を入れたデータを作成しておき、 それをWinAlignに渡すことで、 WinAlign上での手動整合作業を減らそうという方針です。

実際にやってみると、何も処理しないでWinAlignにデータをいれたときよりは 状況がよくなりますが、それでもかなり意図しない整合状況になっているため 手動で直す部分がかなり出てきます。

また、WinAlignは（TagEditorでのセグメントの認識方法と異なり） 改行をセグメントの区切りとは考えないようです。 （またそのようなセグメントの区切りに対する設定もないような気がします。 いや実際には設定方法があるのだが大島が知らない可能性も高い。）

以上から、 元データがDocBookのようなXMLでできてる場合は、 WinAlignで整合させるより、 自前のプログラムで原文と訳文の対になるセグメントを抽出した方が 話が早そうだということがわかりました。

関連キーワード