もしTMS(翻訳管理システム)の切り替えを検討していて、誰かが「簡単だよ！と言ったら TMXとTBXファイルをダウンロードして、新しいTMSにアップロードするだけです！” - それは一筋縄ではいかないかもしれません。 TMSの切り替えは、表面上は簡単ですが、痛みのパンドラの箱を開けます。
しかし、この記事では、TMS移行のストレスに関して、恐怖の中で私のお気に入りの痛みの源に焦点を当てます: 翻訳メモリ の活用と採用。
最大の問題は翻訳メモリの活用にあります。 これは、知識ベースに保存されている文が新しく処理されたコンテンツとどのように比較されるかを指す業界用語です。 翻訳メモリは、大幅なコスト削減と時間効率を生み出します。 それが、顧客がエンタープライズグレードのTMSに積極的に投資する理由の一つです。 「The CAT is on the couch.」を翻訳した場合、新しいコンテンツにも「The CAT is on the couch.」が含まれていると、あなたのTMSはこの文が完全に一致していることを認識し、事前に確認したり、そのコンテンツをロックしたりするかもしれませんので、もう触れる必要はありません。
課題は、TMSsが目に見える単語以上の多くの情報を保存することです。シンプルなDOCXファイルでさえ、独自のエンコーディングを持ち、フォーマット、スタイル、その他の目に見えない要素のコードを埋め込んでいます。したがって、「That CAT is on the couch.」という文は「{1}The CAT {1} is on the {2}couch{2}」として保存される可能性があります。 その場合、「The CAT is on the couch.」を再処理すると、完全一致ではなく、95%から99%の一致になるかもしれません。
そして、それが複数の言語で運営されている大規模なコンテンツ基盤を持っている場合には許容できるように思えるかもしれませんが、この活用行動の変化は、数十の言語で再処理を必要とする何十万ものセグメントを引き起こし、費用を負担する人にとっては悪い結果をもたらす可能性があります。このことを踏まえて、どうすればよいのでしょうか？このことを踏まえて、移行する前に、翻訳メモリを広範囲のコンテンツリポジトリやファイルタイプで徹底的にテストし、活用の基準となる期待値を確立してください。 これにより、移行に完全にコミットして元に戻すことができなくなる前に、潜在的な問題に対処できます。
ベースラインが期待どおりに機能しない場合はどうすればよいですか?
ベースラインが期待どおりに機能しない場合、最初のステップは、このレバレッジの喪失の根本原因を探すことです。 それは、あなたの翻訳メモリにある、従来のTMSの解析およびセグメンテーション戦略の痕跡を含むか、新しいTMSの解析およびセグメンテーション戦略に含まれるかのいずれかです。
先に進む前に、解析とセグメンテーションを定義しましょう。
解析
解析は、特定のシステムが入力されたデータを分割する方法です。 例えば、話し言葉での解析は、私たちの耳が音を区別して、別々の単語を理解する方法です。 ローカリゼーションにおけるパースとは、TMSがソースコンテンツを翻訳可能なコンテンツに分解する際に従うルールを指します。 これには、例えば、TMSがフォーマットをどのように記録するか、変数をどのように記録するか、そしてコードを翻訳可能なコンテンツからどのように分離するかが含まれます。
セグメンテーション
セグメンテーションは、文を構成するもののみを指します。 文は特定の句読点によって定義されますか? 改行は新しい文になりますか? これらの異なるルールにより、異なるレバレッジも可能になります。 以前のTMSで、いくつかの文がテキストボックスを回り込むPPTXファイルを翻訳し、TMSがこれらの改行を文の区切りとして理解し、新しいTMSが改行を文の区切りとして無視する場合、その特定の文の活用を失うことになります。 行区切りの損失は、文が全体として認識できなくなる可能性があるため、解析の損失よりもさらに劇的になることがあります。これに対して何ができるでしょうか？
幸いなことに、これらの問題はいくつかの異なるアプローチで処理できます。
ブルートフォースアプローチ
このアプローチでは、TMSの移行が混乱を伴い、いくつかの損失が予想されることを受け入れるしかありません。 レバレッジの損失を単に受け入れ、最初は翻訳がより高価で時間がかかるようになることを理解しますが、コンテンツベースが新しい現実にほぼ適応したら、すぐに平準化し、以前のレベルに戻るでしょう。 このアプローチは特に小規模なプログラム（Program Size = コンテンツ Base Size x Languages）に対しては非常に効果的ですが、より大規模なプログラムを運用している場合には、いくつかの深刻な予算問題を作成する可能性があります。
翻訳メモリのアプローチ
このアプローチでは、TMSエンジニアが翻訳メモリ内のエンコーディングパターンを分析し、これらのパターンを将来のTMS標準により適合するパターンに変換するルールベースのスクリプトを適用する機会を探すことができます。 例えば、あなたのTMには「{1} The CAT {1} is on the {2}couch{2}.」とありますが、新しいTMSはタグ{2}を無視して「{1} The CAT {1} is the couch.」とだけ記録します。 TM に対処することで、{2} タグが導入された条件を理解するスクリプトを実行し、その{2}をさらなる影響なしに削除できると確信している場合は、そのスクリプトを実行します。 反復的に作業し、限界収益が減少するポイントに達するまでテストを行うことができ、それ以上翻訳メモリの最適化努力を進めることが経済的に意味をなさなくなるまで続けることができます。 このアプローチは、あらゆる規模のプログラムに適していますが、TMが予期しない方法で根本的に変更される可能性をもたらし、望ましくない、そして最も重要なことには、予測できない結果を招く可能性があります。
新しい解析とセグメンテーション戦略のアプローチ
このアプローチでは、将来のTMSがコンテンツを解析およびセグメント化する方法に対処し、これらのルールを翻訳メモリにより近づけるように調整できます。 上記と同じ例では、{2} のタグのTMをクリーニングする代わりに、将来のTMSが特定のエンコーディング状況で{2} のタグも導入することを確認して、活用を最大化します。
このアプローチは最もダイナミックであり、翻訳メモリをそのままにしておくことで、各コンテンツタイプに対してニーズに合わせて調整したアプローチを取ることができます。 そのため、たとえば、YAMLファイルとDOCXファイルに対して異なる解析戦略を持つことができ、これにより、今後の柔軟性と予測可能性を最大限に高めることができます。 このアプローチの課題は、通常、実装がより複雑であり、すべての TMS が解析およびセグメンテーション戦略に必要な柔軟性を提供するわけではないことです。
結論
TMSの移行は公園を散歩するような簡単なことではありません。 それは、ペルーのアマゾンを通り、アンデス山脈を上る複雑なトレッキングのようなものです。 潜在的な合併症に早い段階でフラグを立てて対処することが重要であり、ローカリゼーションにおいては、物事が急速に膨れ上がり、指数関数的に増加することがあります。 あなたが何に取り組んでいるのかを正確に把握し、最初から最適化戦略を作成するために、TMSを本当にストレステストすることを確認してください。
Unlock the power of glocalization with our Translation Management System.
Unlock the power of
with our Translation Management System.
