2000 年 12 月 15 日
用語管理は翻訳ツールの問題ではありません。これはグローバリゼーションのインフラの一部であり、適切に整備するのは最も安価ですが、改造するのは最も高価です。
用語ベース プロジェクトを潰す方法は、初日に製品マニュアルからすべての単語を集め、途中で疲れ果てて放棄することです。効果的な順序は、誤った場合のコストに応じて決定されます。製品名、安全用語、機能名、および規制上の表現は、誤訳が実際の損害を引き起こすカテゴリであるため、これらを最初に実行してください。通常の説明的な語彙は待つか、完全にスキップすることができます。
最初の用語ベースは大きい必要はありません。数百のエントリで十分です。重要なのは、それらが翻訳プロセス、レビューチェックリスト、製品ドキュメントなどで実際に使用されることです。誰もが従う 200 項目の用語ベースは、誰も読まない 2000 項目の用語ベースよりもはるかに価値があります。
ランキングは単語の頻度ではなく、ビジネスへの影響に基づいて決定されます。誤訳によって安全上のインシデントが発生する珍しい用語は、1 日に 10 回出現する普通名詞よりも上位にあります。
用語ベースが存在した後の最も一般的な問題は、用語ベースが共有ドライブ上に存在し、翻訳者がそれを知らないか、知っていても参照しないことです。つまり、ツールではなくドキュメントになります。効果的なアプローチは、翻訳者が承認された用語を作業インターフェイスで確認できるように、CAT ツールと MTPE プロセスに接続することです。
プロセスに入ると、用語チェックを自動化できます。ほとんどの CAT ツールと QA ツールは用語の一貫性チェックをサポートしており、翻訳で非標準のレンダリングが使用されている場所にフラグを付けることができます。この 1 つのステップにより、用語の遵守が善意からチェックされたプロセスに移行します。
見落とされがちなもう 1 つの層、それがオンボーディングです。翻訳者がプロジェクトに初めて触れる場合、用語ベースは可能な限り最良の説明になります。用語ベースは、製品の名前、機能の名前の付け方、即興で使用してはいけない単語などを伝えます。最初の課題の前に用語ベースを調べておくと、後で修正するよりも節約できます。
用語ベースは、構築して完成する資産ではありません。メンテナンスが必要であり、メンテナンスには所有者が必要です。誰か (1 人または小グループ) が、いつ用語を変更するか、誰が承認するか、および変更が影響を受ける全員にどのように伝達されるかを決定します。このような取り決めがなければ、用語ベースは衰退してしまいます。翻訳者は推測に戻り、内容は静かに古くなっていくのです。
通常の構造は、用語の所有者に加えて、製品、マーケティング、翻訳から選出されたレビューパネルです。新しい用語や変更は、送信、レビュー、承認、ベース入力、通知という固定ルートに従います。ルートは複雑である必要はありませんが、存在し、記録されなければなりません。
同じ理由で、用語変更のバージョン履歴も重要です。条件は静的なものではありません。製品は進化し、市場は移動します。また、昨年の標準的な表現は今年は正しくない可能性があります。しかし、変更は追跡可能でなければなりません。問題は組織的なものです。製品を変更するチームとドキュメントを管理するチームは同じ人物ではないことがよくあります。変更を自動的に反映するには、何らかのメカニズムが必要です。手動で監視することはできません。
最もよく使用される用語を四半期ごとにレビューするようにスケジュールを立て、適用されなくなったエントリを廃止します。廃止されたモデルの名前、名前が変更された機能、規制変更によって廃止された配合など、これらすべては基本から明らかにされる必要があります。翻訳者はそれらがまだ有効であると想定するため、それらを残しておくと、節約される利便性よりもコストが高くなります。
レビューには隠れた 2 番目の利点があります。それは、用語体系のギャップが表面化する瞬間であるということです。誰も使用しないエントリは、対応する機能が翻訳されていないか、翻訳者がその用語の存在を知らないことを意味している可能性があります。これらのシグナルは、データを定期的に調べることによってのみ得られます。
用語管理はツールではなくインフラストラクチャに帰着します。基礎を正しく身につければ、言語を追加するかどうかは量の問題です。それをスキップすると、言語を追加するたびにドリフトが再び蓄積されます。 FangService は、用語管理を多言語プロジェクトのフロントエンド ステップとして扱います。製品資料を持参し、用語の最初のバッチから始めます。
あるクライアントは、海外の認証中に、同じコンポーネントに 3 世代の製品マニュアルにわたって 3 つの名前があることを発見しました。初期はヒートシンク、その後は冷却モジュール、最新バージョンは熱管理ユニットです。認証機関は、これらは 3 つの異なる部分である可能性があると結論付け、説明を求めましたが、そのやり取りには 1 か月かかりました。初期の用語集が単に維持されていれば、その説明は決して必要ではなかったでしょう。用語集管理によって節約されるのは、翻訳費用だけであることはほとんどありません。それは手戻り、明確化、認証の遅れです。
用語集を維持するための現実的なアプローチには 3 つのステップがあります。まず、製品定義、パラメータ名、認証用語、ブランド名など、必須のものだけを収集します。次に、2 つの失敗モードをキャプチャします。1 つの用語に複数の翻訳が含まれているものと、1 つの翻訳に複数の原文用語が含まれているものです。これは、苦情とやり直しが発生するためです。 3 番目に、所有者とレビューのリズムを割り当てます。これにより、製品の世代が変更されると用語のレビューが開始されます。 FangService は、禁止された翻訳と該当するコンテキストについて注釈が付けられた各エントリを含むバイリンガル用語ベースを構築し、用語集をプロジェクト バージョンに結び付け、モデル番号やブランド名などの翻訳不可能な項目をスキップするように翻訳パイプラインを構成して、機械翻訳によって書き換えられないようにします。
用語管理はシステム プロジェクトとして説明されやすいため、決して開始されません。実際には、最初の 3 か月間で 3 つのアクションを実行すれば、結果を確認するのに十分です。製品定義とパラメータ名を製品ラインごとに強制的に適用します。すでに苦情や再作業の原因となっているレンダリングをマークする禁止翻訳リストを作成します。また、翻訳パイプラインに用語の事前チェックを追加して、頻度の高い用語が発送前にスクリーニングされるようにします。
これら 3 つはどれも大規模な投資を必要とせず、すぐに 2 つのクラスの問題を軽減します。1 つの製品に複数の名前が付いていることによる明確化と再作業、もう 1 つはすでに間違っていることがわかっているレンダリングが再び現れることです。他の場所からコピーした一般的なリストではなく、実際の製品を反映しているのであれば、30 の用語から始まる用語集で十分です。
FangService は、製品自体からクライアントの用語ベースを構築します。高頻度の必須用語が最初に、コンテキストと禁止されたレンダリングで注釈が付けられ、プロジェクトのバージョンにバインドされ、翻訳パイプラインの事前チェックとして実行されます。用語管理は、成果が出始めて初めてシステムと呼ばれる権利を獲得します。