DeepL、Google翻訳、AI：.poファイルに最適なのはどれか？

WordPressプラグインから.potをエクスポートし、数百の文字列をDeepLやGoogle翻訳に貼り付け、きれいに整ったドイツ語の列を受け取り、それを.poファイルにドロップし、コンパイルして出荷します。すると、ユーザーから、カートページで商品名が表示されるべき箇所に生々しい%1$sが表示される、あるいはさらに悪いことに、複数形が崩れてしまうために、あらゆる言語で価格の行がYou have 1 itemsと表示される、という報告が来ることがあります。翻訳の品質は問題なかったのです。しかし、翻訳の構造が破壊されていました。

これが、ソースが散文の一節ではなくgettextの.poファイルである場合のDeepL vs Google翻訳論争における核心となる問題です。どちらも自然な文章の翻訳においては世界クラスです。しかし、どちらもprintfプレースホルダー、Gettextの複数形配列、またはmsgctxtによる曖昧さの解消を尊重するようには設計されていません。それらは%1$sを修正すべきタイプミスとして扱い、2つの形式を持つ複数形を、平坦化する単一の文として扱います。マーケティング文言であれば、これは目に見えません。しかし、ソフトウェアのローカリゼーションでは、サイトが機能しなくなります。

この記事では、従来の機械翻訳（DeepLとGoogle翻訳）と、gettextのために特別に構築されたコンテキスト認識型AIパイプラインを比較します。.poファイルにとって本当に重要な点、すなわちプレースホルダーの処理、複数形、コンテキスト、一括ファイルサポート、およびコストに焦点を当てて見ていきます。より深いLLM対LLMの品質に関する議論を知りたい場合は、AI翻訳の品質：Gemini vs GPT-4 vs DeepSeekで取り上げました。ここでは、より限定的で実用的な質問、つまり.poファイルに最適なのは何か、という点に絞って検討します。

DeepL、Google翻訳：何のために作られたか

どちらも、流暢で自然な言語出力を目指して最適化された汎用的な機械翻訳エンジンです。どちらもファイル形式を解析しません。

DeepL - 流暢だが形式を認識しない

DeepLは、特にヨーロッパ言語において、最も自然な響きの出力で広く賞賛されています。しかし、それは構造ではなくテキストを取り込みます。.po msgidに%1$s ordered %2$sが含まれていると、DeepLはプレースホルダー周辺の単語を翻訳する一方で、トークンの順序を変更したり、スペースを入れたり、削除したりすることが頻繁に起こります。なぜなら、DeepLにとってそれらは単なる文中の奇妙な文字だからです。

Google翻訳 - 幅広いカバー範囲、同じ盲点

Google翻訳ははるかに多くの言語をサポートしており、GTranslateのようなプラグインの背後にある費用対効果の高いデフォルトです。そのプレースホルダーの処理能力も優れていません。どちらのエンジンも同じ根本的な限界を共有しています。つまり、文の流暢さを最適化し、gettextのルールに関するモデルがないのです。

本当の問題は品質ではない - 構造である

.poファイルにとって、基本的な言語品質は当然の前提です。本番環境を壊すのは構造的な整合性です。変数は残るか、複数形は複数の形式を保つか、コンテキストは尊重されるか。gettext認識型AIパイプラインがDeepLとGoogle翻訳の両方に優位に立つのは、まさにこの点です。

プレースホルダーと複数形が機械翻訳を壊す理由

.poファイルは散文ではありません。それは厳格なルールを持つコードに隣接するテキストであり、そのルールのうち3つが日常的に古典的なMT（機械翻訳）を破綻させます。

プレースホルダーと変数の破壊

WordPressの文字列は、printf形式のプレースホルダー（%s、%d、%1$s、%2$sのような位置指定形式）でいっぱいです。位置指定形式が重要なのは、一部の言語では文の順序が変更されるため、数値がsprintfにどの引数がどこに入るかを指示するからです。古典的なMTがこれに対して何をするか見てみましょう。

// Source string in your .po file
$msg = sprintf( __( '%1$s left a comment on %2$s', 'mytheme' ), $user, $post );

// What DeepL / Google Translate often return (German):
// "%2$s hat einen Kommentar zu %1$s hinterlassen"  <- reordered, OK
// "% 1$ s hat einen Kommentar..."                   <- spaces injected, BROKEN
// "hat einen Kommentar hinterlassen"                <- placeholders dropped, BROKEN

挿入された単一のスペース（% 1$ s）や脱落したトークンは、PHPの警告を発したり、ユーザーに生のコードを出力したりします。この失敗モードについては、コード変数を壊さずにPOファイルを翻訳する方法で深く掘り下げています。

複数形の崩壊

Gettextの複数形は単一の文字列ではなく、言語の複数形ルールに基づいてキー付けされた配列です。英語には2つの形式があり、ポーランド語には3つ、アラビア語には6つあります。古典的なMTはmsgid_pluralを2つの別々の文として受け取り、それぞれを独立して翻訳するため、それらが一貫性のある多形式セットとして維持されなければならないという認識がありません。その結果、多くの場合、単一の形式が複製され、1 itemと5 itemsが同じように表示されます。

msgid "%d item in your cart"
msgid_plural "%d items in your cart"
msgstr[0] ""
msgstr[1] ""
# A gettext-aware pipeline fills BOTH forms correctly with %d preserved.
# DeepL/Google translate each line in isolation and lose the plural relationship.

コンテキスト（msgctxt）が無視される

Gettextはmsgctxtを使用して同一の文字列を区別します。例えば、名詞の「Post」と動詞の「Post」、あるいはWooCommerceでの名詞の「Order」と動詞の「Order」などです。古典的なMTはそのコンテキストフィールドを認識しないため、推測に頼り、文字列が現れる場所に関わらず、常に同じ方法で推測します。

コマース分野では損害がさらに悪化します。WooCommerceのカタログは、「Order」、「Ship」、「Free」、「View」といった短く曖昧な文字列で溢れており、誤った解釈によって、顧客の言語で間違ったことを言うボタンが生成されてしまいます。DeepLとGoogle翻訳は各文字列を単独で翻訳するため、gettextが意図的にエンコードする周囲のコンテキストを使用できません。msgctxtを読み取る形式認識型パイプラインは、まさにこれらの曖昧さを解決します。これが、誤訳が実際の売上を損なうストアページで最も重要となる理由です。

.poファイルのためのコンテキスト認識型AIアプローチ

専用に構築されたgettextパイプラインは、単に単語を翻訳するだけでなく、ファイル形式を理解し、その構造を保護します。これがカテゴリレベルの違いであり、DeepLとGoogle翻訳の比較が全くの的外れで、従来のMTと形式認識型AIワークフローの比較が正しい理由です。

構文ロックがすべてのトークンを保護する

決定的な技術は構文ロックです。AIがテキストに触れる前に、すべての変数（%s、%1$s、{name}）、HTMLタグ、およびコードトークンがロックされ、脇に置かれます。モデルは人間が読める単語のみを認識し、書き換えます。翻訳後、ロックされたトークンは正しい位置に復元されます。% 1$ sのような破壊は起こり得ません。なぜなら、AIはそもそもプレースホルダーに触れないからです。これは従来のMTには構造的に欠けているセーフティネットであり、手動翻訳 vs AI翻訳：2025年のWordPressローカリゼーションにおいてAIは安全かで詳しく解説しています。

完全な複数形とコンテキストのサポート

gettext認識型パイプラインはmsgid_pluralをセットとして読み取り、ターゲット言語の複数形ルールに必要なすべての形式を生成し、それらすべてにわたってプレースホルダーをそのまま保持します。また、msgctxtを読み取り、それをコンテキストとして使用するため、名詞の「Order」と動詞の「Order」は異なり、かつ正しく翻訳されます。

一括ファイル、コピー＆ペーストではない

DeepLとGoogle翻訳はボックスに貼り付けるツール（または文字単位のAPI）です。クラウドの.poワークフローはファイル全体を取り込みます。スマートバッチングにより、10MB以上のWooCommerce文字列パックは分割され、並行して翻訳され、結合されます。これに対して、コピー＆ペーストのアプローチはそれよりもずっと早く機能しなくなります。手作業で列を結合する代わりに、ファイルをアップロードして.po + .mo + その他の形式をダウンロードできます。

DeepL、Google翻訳、Gettext認識型AIの比較：結論

単純な散文であれば、DeepLとGoogle翻訳は優れています。しかし、.poファイルにとって本番環境での安全性を決定する重要な要素は、プレースホルダー、複数形、コンテキスト、および一括処理であり、形式認識型パイプラインが優位に立つのはまさにこの点です。

比較表

選び方

ブログ記事やマーケティングページを翻訳する場合は、DeepLを使用してトーンを調整しましょう。しかし、本番のWordPressサイト向けである.poまたは.potファイルを翻訳する場合は、流暢さは決定的な要素ではありません。構造的な整合性が重要です。gettext認識型AIパイプラインは、高い言語品質と、コンパイルされた.moまで無傷で残るプレースホルダー、複数形、コンテキストの両方を提供します。

この表では過小評価されているワークフローのコストも考慮すべきです。プラグイン全体をDeepLやGoogle翻訳で処理するということは、文字列の列をボックスにコピーし、結果を貼り付け、すべてのプレースホルダーを手作業で再確認することを意味します。これは、言語が増えるごとに悪化する退屈でエラーが発生しやすいプロセスです。ファイルベースのパイプラインは、それを単一のアップロードとダウンロードに集約し、.poだけでなく、コンパイルされた.moやその他の形式を1つのZIPで返します。そのため、出荷するファイルはAIが生成したファイルであり、新しい間違いが入り込む手動の再構築は不要です。

結論

.poファイルに関するDeepL対Google翻訳の質問への正直な答えは、間違った競争相手について尋ねているということです。どちらも優れた散文翻訳者であり、gettextに対して構造的に盲目です。つまり、.poファイルを読み込むようには作られていないため、%1$sを破壊し、複数形を平坦化し、msgctxtを無視します。ソフトウェアのローカリゼーションにおいては、これがクリーンなリリースと破損したカートページの差になります。

構文ロックを備えたコンテキスト認識型AIパイプラインは、比較を完全に変えます。DeepLやGoogle翻訳に期待される流暢さに匹敵しながら、すべての変数、複数形、コンテキスト情報が無傷で到着することを保証します。そのため、翻訳されたサイトは読みやすいだけでなく、機能するのです。

破壊されたプレースホルダーや崩壊した複数形なしで、.poファイルを翻訳する準備はできていますか？SimplePoTranslateを無料で試す - クレジットカード不要。あなたの.po、.pot、.json、または.xliffをアップロードして、無料プランでgettext対応の安全なAI翻訳を入手しましょう。