今日の機械翻訳は、多くの場合、人間による翻訳と見分けがつかないほど精度が高くなっています。翻訳サービスは、流暢で慣用表現を駆使し、文体のニュアンスも的確に捉えています。ところが、DPPデータセットを翻訳してみると、突然「rear lock fiber closure」が 「Hinterschloss-Faserverschluss」
という訳になってしまうのです。
この問題は「 専門用語」に起因します。ここでは、製品データが小説のように扱われてはならない理由と、39言語の翻訳版が理解しやすいものとなるよう、Transpareoが提供するツールについて解説します。
根本的な問題：1つの単語、複数の意味
アウトドアジャケットのDPPにおける「Seal」：防水処理。実験室での「Seal」：文脈に応じてアザラシ、あるいはシール。メンテナンス記録における「Seal」：状況によっては封印。
一般的な翻訳モデルは、統計的な文脈に基づいて選択を行います。流暢な文章であれば、これは機能します。小説には豊富な文脈があるからです。しかし、データフィールドの primary_closure: seal の場合、文脈はほとんどありません。モデルは推測するしかありません。
その結果、微妙な誤訳が生じます。「Hinterschloss-Faserverschluss」ほど劇的ではありませんが、重大な影響を及ぼします。ドイツ語で「Dichtung」と呼ばれる部品が、イタリア語のDPPでは突然「guarnizione」ではなく「sigillo」と表記されてしまうのです。 その結果、購買担当者はその交換部品を見つけられなくなってしまいます。
Transpareoが現在提供しているサービス
当社の翻訳システムは、新しいコンテンツを自動的にすべての有効な言語に翻訳します。このシステムには4つの特徴があります：
-マークダウンおよび変数の保持：<a href="/ja/登録する">Pro-Mitgliedschaft</a> のようなプレースホルダーやマークダウン構造は翻訳前に抽出され、純粋なテキストのみが翻訳された後、構造は変更されずに再挿入されます。これにより、リンク、フォーム、レイアウトがすべての言語で一貫性を保ちます。
-中央集約型の翻訳エントリ：翻訳はデータレコード自体には保存されず、共有レイヤーに保存されます。同じ原文を持つ複数のデータレコードが1つの翻訳を共有します。これにより、翻訳コストを削減し、データモデル全体で用語を自動的に統一します。
-変更時の自動再翻訳：原文が変更されると、すべての言語の翻訳が再生成されます。ドイツ語での修正1件に対し、他の38の言語バージョンが自動的に更新されます。
-レコードごとのマーク設定：コンテンツを自動処理の対象から除外したり、既存の翻訳を固定したりすることができます。これは、国際的な製品名や手動による修正などの場合に ## 役立ちます。
顧客による処理の補完
自動翻訳は、説明文、マーケティングテキスト、お手入れ方法などについては、大部分で正確な結果を提供します。しかし、「seal」や「guarnizione」といった重要な専門用語に関しては、一部の誤りが残るため、顧客側の管理者が修正する必要があります。
この場合、管理者は以下の3つの手段を利用できます：
- 言語およびキーごとの手動上書き：各翻訳エントリはアプリケーションマネージャーで開いて、言語ごとに調整できます。「固定」マークを付けると、この手動翻訳は次回の自動翻訳実行時にも保持されます。
- 用語集のインポート：翻訳ツールやPDF用語集にある既存の用語をCSV形式で取り込むことで、直接入力された翻訳エントリを生成できます。
- 運用中の言語ごとの修正：イタリアの営業担当者が誤りに気づき、アプリケーションマネージャーで修正すると、その修正は即座に反映され、その他の翻訳には影響しません。
EU言語の現実
EUの公用語は24言語と多く聞こえますが、実際には3つの層に分かれます：
-主要市場：DE、EN、FR、IT、ES、NL - ここでは、すべての消費者が完璧さを求めています -主要市場：PT、PL、SV、DA、FI ― 水準は高く、時折機械翻訳であることがわかる程度 -使用頻度の低い言語：MT、GA、ET、LV、LT ― マルタのエンドユーザーがスキャンすることなど一度もないにもかかわらず、マルタ語のDPPが求められることがある。それでも義務である。
この義務は任意ではありません。ESPRは、製品が販売される加盟国の言語でのDPPコンテンツを義務付けています。したがって、27カ国に対応する場合、24の言語が関係してきます（言語を共有している国もあります）。
なぜ一元化されたローカライズ層が必要なのか
ほとんどのプラットフォームでは、翻訳をデータレコードの追加フィールドとして保存しています：description_de、description_en、……翻訳可能な属性1つにつき39個のフィールドです。簡単そうに聞こえますが、これには3つの欠点があります：
- テキストが二重に保持される。 同じ素材表記を持つ2つの製品があると、翻訳は1回で39件ではなく、39＋39件生成される
- スケーラビリティが低い。40番目の言語を追加するには、翻訳可能なすべてのモデルにわたるスキーマの移行が必要となる
- 修正をグローバルに適用するのが困難。 「guarnizione」をどこでも修正する場合、すべてのデータレコードを個別に編集する必要があります。
分割された翻訳レイヤーはこの問題を解決します。1つのエントリに対して多数の参照があり、1回の修正ですべてのデータレコードが恩恵を受けます。
まだ実現できていないこと
自動候補検出機能を備えた顧客固有の用語データベースは開発計画に含まれていますが、現時点では提供されていません。今すぐ導入を始める場合でも、既存のツールで十分に対応可能です。手動での上書き、用語集のインポート、および「保留」マークの設定により、最も一般的なユースケースをカバーできます。
私たちは、作業の大部分は機械が行い、人間は本当に必要な場合にのみ介入すべきだと考えています。自動用語認識機能が利用可能になるまでは、手動による操作が透明に行われます。これは、果たされない約束をするよりも誠実な対応だと考えています。