「単語単位のトークン化を使用する」の設定について

日本語から英語への翻訳において、「原文がアジア言語の場合に単語単位のトークン化を使用する」の設定の動きを確認させてください。

SDL Trados Blog の 「Trados Studio 2019 – 進歩した日本語原文の解析」というガイドを参考にさせて頂きましたが、どうもこのガイドの説明と実際の動きが合っていないように思えましたので、よろしくお願い致します。

例として、「実行条件」という原文と、「execution condition」という訳文をメモリに登録しました。

 

 ■ 単語単位のトークン化を使用しない場合 (チェックボックスをオフにした場合)

「実行条項」という原文を訳そうとすると、以下のようにメモリがヒットしてきます。

■ 単語単位のトークン化を使用する場合 (チェックボックスをオンにした場合)

「実行条項」という原文に対しては以下のようになり、メモリがヒットしてきません。

 

  

使用している Trados のバージョンは、2017 SR1 CU18 です。

メモリの検索設定は、以下のように、一致率の最小値は 70%、フラグメント一致は有効、にしています。

上記の例はたった 4 文字で、実際の翻訳の分節としては極端に短いので、なんで 82% になるんだろうとか、単純に文字でヒットさせても 75% にはなるんじゃないのとか、そういった細かいことはあまり気にしていません。私が気になっているのは、単語単位のトークン化を使用した方がメモリのヒットが少なくなっていることと、この設定が、解析だけでなく、実際のエディタでの作業にも影響していることです。

私は翻訳会社から翻訳を依頼される個人翻訳者という立場であるため、以下のように考えています。 

・解析時は、従来どおり文字ベースでマッチ率を計算して欲しい

・エディタでの作業時は、フラグメント一致の機能を使いたい

 これを実現してくれるのが「単語単位のトークン化を使用する」の設定かと思っていたのですが、違ったでしょうか???

 

従来どおり文字ベースでマッチ率を計算するには、この設定をオンとオフのどちらにすべきでしょうか。 

また、作業時にフラグメント一致 (upLIFT) の機能を使うには、この設定を変える必要があるでしょうか。

 

ちなみに、パッケージで渡される場合、翻訳者側ではこの設定を変更できません。ですので、もし設定が必要であるのであれば、翻訳会社さんにお願いするしかなく、それはそれでとても面倒なんじゃないかと思っています。

 

長くなりましてすみませんが、よろしくお願い致します。

Top Replies

  • 投稿いただきありがとうございます。「単語単位のトークン化」を使用しない状態では、日本語原文のTM一致は「文字単位でどれだけ一致しているか」という機械的な基準で判定されます。

    これは単純な文字ベースの比較による判定ですが、「より言語的な解析によって単語上の類似性を判定する」ことが「単語単位のトークン化」であるとご理解ください。従いまして、このように文字数の短い文章ではこのオプションを使用しないほうがマッチ率が高いということは確かにありえます…

  • Glad you managed to understand what's happening here.  Also thought I'd share your blog article on this topic which looks very useful for other JP translators:

    http://fanblogs.jp/sakura2translation…

Parents
  • Thank you for your comment.
    I upload the sample file I used. Could you try again?

    1016.sample.zip

    First, translate the first segment and add the following translation pair to the TM:
        Jpn: 実行条件
        Eng: execution condition

    Next, activate the second segment. Then, the situation should be reproduced.

     

    The source text of the second segment is "実行条項". The last letter is different from that of the first segment. 

    Thanks,

  • ok - now I see what you're getting at.  Apologies for being a little slow here.

    If I work without the word-based tokenization I get this with your file:

    If work with this option enabled I get this:

    So the answer to this question:

    I was wondering if "use word-by-word tokenization" was the setting that would make this happen, but is that different? ? ?

    Is yes... this could make this happen.  The reason is because the application is attempting to analyse based on recognised words using spaces between them as opposed to treating each character as a word which is the more traditional method.  I don't know the exact details behind how this is calculated, but I imagine it' something like this very simplistic model I just created in Excel:

    So the same chars, and the same changed character, but calculating based on words as opposed to chars could reduce the leverage from your TM.  So clearly you need to agree something with the agency before you start... although interestingly it looks as though they would have to pay you more for the word-based tokenization since the leverage is lower in your case.  I might not be so quick to point this out!

    If you're comfortable with this you could recreate the project yourself using the files inside their project.  Do the work as you prefer and then put the completed sdlxliff files back into the project created from their package.

Reply
  • ok - now I see what you're getting at.  Apologies for being a little slow here.

    If I work without the word-based tokenization I get this with your file:

    If work with this option enabled I get this:

    So the answer to this question:

    I was wondering if "use word-by-word tokenization" was the setting that would make this happen, but is that different? ? ?

    Is yes... this could make this happen.  The reason is because the application is attempting to analyse based on recognised words using spaces between them as opposed to treating each character as a word which is the more traditional method.  I don't know the exact details behind how this is calculated, but I imagine it' something like this very simplistic model I just created in Excel:

    So the same chars, and the same changed character, but calculating based on words as opposed to chars could reduce the leverage from your TM.  So clearly you need to agree something with the agency before you start... although interestingly it looks as though they would have to pay you more for the word-based tokenization since the leverage is lower in your case.  I might not be so quick to point this out!

    If you're comfortable with this you could recreate the project yourself using the files inside their project.  Do the work as you prefer and then put the completed sdlxliff files back into the project created from their package.

Children
  • Thank you for your detailed explanation.

    My sample file with very short sentences is a rare case, maybe. In actual translation tasks, a typical sentence is probably longer and contains 20 or more words. I guess from your explanation that the sentence length affects the match rate.

    I understand that the word-based tokenization (or upLIFT) is a new feature that was introduced from 2017 SR1 for non-space separated languages, such as Chinese and Japanese. If so, should I enable the feature to leverage TM optimally for most cases? 

    On the other hand, I want the analysis of translation files to be on a character basis. This is because I usually translate Japanese to English and I am paid per character, not per word. In fact, most projects I experienced disabled the word-based tokenization and that is, I might have been paid less!

    Sorry for writing the following in Japanese.

    結局、日本語原文の翻訳作業時に upLIFT の機能を有効活用するためには、やはりこのチェックボックスをオンにする必要があるのでしょうか。

    そうであるとすれば、翻訳会社さんでの解析時にはオフにして、翻訳者の作業時にはオンにして、という運用が必要になってしまうかと思いますが、このような理解であっているでしょうか。

    ただ、私個人の経験の範囲では、このチェックボックスがオンにされていたパッケージはこれまでほとんどなかったような気がします。それでも、upLIFT の機能は使えていたと思いますので、今回サンプルとしてあげたファイルの動作には少し混乱しております。

    upLIFT の有効活用と正しい文字カウントのために、このチェックボックスをどのように使うのがベストなのか、アドバイス頂けると嬉しいです。

  • 投稿いただきありがとうございます。

    「単語単位のトークン化」オプションは「日本語原文のTMあいまい一致」という従来の機能を補強するためのものですので、upLIFTの動作とはまた別の機能オプションとなります。ご認識のとおり、こちらを無効にしてもフラグメント一致を使用することができます。

  • コメント、ありがとうございます。
    「単語単位のトークン化」と upLIFT は別の機能なのですね。同じかと思っていました。


    では、次のような理解で合っているでしょうか。

    ■ 単語単位のトークン化を使用しない場合 (チェックボックスをオフにした場合)

    ・解析結果は、従来どおり文字ベースのカウントになる。(-> マッチ率は従来どおり)
    ・翻訳作業時も、残念ながら、単語単位のトークン化の機能は使われない。


    ■ 単語単位のトークン化を使用する場合 (チェックボックスをオンにした場合)

    ・解析結果は、従来の文字ベースのカウントとは異なってしまう。(-> マッチ率が上がる)
    ・翻訳作業時は、単語単位のトークン化の機能が使われる。


    従来どおりのカウントにしたければ、単語単位のトークン化の効果は享受できない、ということになるでしょうか。残念ですが、カウントが変わってしまうのは困るので、これは仕方ないかもしれません。


    ここで、もう一度、最初のサンプルに戻らせてください。

    サンプルのファイルでは、単語単位のトークン化を使用しない場合の方がマッチ率が上がっています。また、「実行条項」という原文では、「実行」と「条項」という 2 単語が認識されているように見えます。まさにこの動作が「単語単位のトークン化」のように思えるのですが、違うでしょうか。


    今回のサンプルは、非常に短い文なので例外的なマッチ率になっているかもしれませんが、通常は、「単語単位のトークン化を使用した方がマッチ率は上がる」と考えてよろしいでしょうか。(個人翻訳者の立場から本音を言えば、もしマッチ率が下がるのでしたら、わざわざ従来どおりの文字ベースでのカウントにこだわることはありません。)

    以上、何回もお手数ですが、よろしくお願いします。

  • すみません、SDL Trados Blog の 「Trados Studio 2019 – 進歩した日本語原文の解析」というガイドを読み直してみたのですが、私が大きな勘違いしていたような気がしてきました。
    「単語単位のトークン化」という機能は、文字数ではなく単語数を数えるときに影響するもので、それ以外には基本的には関係ないのですね。

    2017 になってからマッチ率がずいぶん上がったと感じていたので、SDL Trados Blog の「翻訳メモリの互換性 SDL Trados Studio 2019 / 2017 / 2015」で説明されている、解析結果の差異と、「単語単位のトークン化」が関係しているのではないかと思ってしまっていました。


    いろいろとお騒がせしましたが、以下の理解でよろしいでしょうか。

    • 「単語単位のトークン化」は、日本語原文でも、文字数ではなく単語数を知りたいときのみ使用する。
    • 「単語単位のトークン化」を使用しないからといって、マッチ率が下がるわけではない。
      (つまり、「単語単位のトークン化」を使用しなくても、TM の単語やフレーズレベルでの一致などの機能強化のメリットは享受できる。)


    ということで、だいぶ理解できたと思うのですが、最後に 1 つだけ、質問させてください。

    上記に挙げたブログで「解析結果の差異が解消された」と説明されていますが、この解析結果というのは、「単語単位のトークン化」を使用しない場合の数字でしょうか。

    この投稿の最初のサンプルに挙げたとおり、「単語単位のトークン化」を使用するかしないかで解析結果のマッチ率が変わってきます。「単語単位のトークン化」はデフォルトでは無効であり、私個人の経験の範囲では、翻訳会社から送られてくるほとんどのパッケージで無効になっていたと思います。ですので、「単語単位のトークン化」を使用しない状態で、解析結果の差異が解消されたということでしたら問題ないと考えています。

    本当に何回もすみません。最初の投稿からは質問の内容も変わってしまいましたが、どうぞよろしくお願いします。

  • 投稿いただきありがとうございます。「単語単位のトークン化」を使用しない状態では、日本語原文のTM一致は「文字単位でどれだけ一致しているか」という機械的な基準で判定されます。

    これは単純な文字ベースの比較による判定ですが、「より言語的な解析によって単語上の類似性を判定する」ことが「単語単位のトークン化」であるとご理解ください。従いまして、このように文字数の短い文章ではこのオプションを使用しないほうがマッチ率が高いということは確かにありえます。

    しかし下記の例のように、「一致している文字数の機械的な比較」だけではヒットしないTM一致も拾い上げることができるようになったこともご理解ください。

    こちらは、単語単位のトークン化により「より言語的に合理性のある比較結果」であると言えます。

    また、ご理解のとおり、ブログでの解析結果の互換性に関しましては、このオプションを使用しない前提でのものとなります。