1つのファイルをインプット、5つのフォーマットをアウトプット：WordPress翻訳を将来にわたって活用する方法

WordPressテーマをスペイン語に翻訳するのに3週間費やしました。.poファイルは完璧です — すべての文字列がレビューされ、すべての変数がそのまま残り、すべての複数形が正しい状態です。その後、クライアントが従来のPHPテーマから、フロントエンドにReactを使用したヘッドレス構成に移行することを決定しました。

すると突然、.poファイルは役に立たなくなります。Reactアプリには.jsonが必要です。レガシーPHPウィジェットには依然として.moが必要です。モバイルアプリを担当するフリーランサーは.xliffを求めています。そして、4,000個の文字列を3つの異なるフォーマットに再翻訳する時間はありません。

これは特殊なケースではありません。これは、最新のWordPress開発の現実です。テーマにはPHPとJavaScriptの両方のコンポーネントが同梱され、プラグインはGettextとi18nextを混在させて使用し、クライアントはパスワードを変更するよりも頻繁にアーキテクチャについて考えを変えます。

翻訳ファイル形式がこれまで以上に重要な理由

5年前、WordPressの翻訳は簡単でした。.poファイル（人間が読めるソース）と.moファイル（コンパイルされたバイナリ）がありました。それだけでした。すべてのテーマ、すべてのプラグイン、すべての翻訳ツールが同じ言語を話していました。

今日、WordPressエコシステムは、少なくとも5つの翻訳ファイル形式を本番環境で使用しています。

知っておくべき5つの形式

.po (Portable Object) — GNU Gettextで使用される人間が読めるソース形式。元の文字列(msgid)とその翻訳(msgstr)が含まれています。これは翻訳者が編集するものです。

msgid "Add to Cart"
msgstr "Anadir al carrito"

msgid "Your order has been shipped to %s"
msgstr "Su pedido ha sido enviado a %s"

.mo (Machine Object) — .poファイルのコンパイルされたバイナリバージョン。WordPressはload_textdomain()を使用して、実行時に.moファイルを読み取ります。実行時に.poを解析するよりも高速ですが、人間が編集することはできません。

.json (JavaScript Object Notation) — Gutenbergブロック、Reactコンポーネント、および最新のテーマでJavaScriptベースの翻訳を行うためにwp_set_script_translations()によって使用されます。WordPressは、locale_dataキーを持つ特定のJSON構造を想定しています。

{
  "locale_data": {
    "flavor-starter": {
      "Add to Cart": ["Anadir al carrito"],
      "Your order has been shipped to %s": ["Su pedido ha sido enviado a %s"]
    }
  }
}

.php (PHP Array) — Laravelスタイルの翻訳読み込みを使用するテーマやプラグインでますます人気が高まっている形式。一部の最新のWordPressテーマは、Gettextを完全にバイパスし、パフォーマンスのためにPHP配列から翻訳をロードします。

<?php
return [
    'Add to Cart' => 'Anadir al carrito',
    'Your order has been shipped to %s' => 'Su pedido ha sido enviado a %s',
];

.xliff (XML Localization Interchange File Format) — さまざまなツールやプラットフォーム間での翻訳交換の業界標準。memoQ、Trados、MemsourceなどのCAT（Computer-Assisted Translation）ツールで使用されます。プロの翻訳者と協力する際に不可欠です。

<trans-unit id="1">
  <source>Add to Cart</source>
  <target>Anadir al carrito</target>
</trans-unit>

問題点：フォーマットのロックイン

ほとんどの翻訳ツールは、1つの出力形式を生成します。Poeditは.poと.moを提供します。WPMLは翻訳をデータベースに保存します（ファイルにはまったく保存されません）。Weglotは、翻訳を独自の形式でサーバーに保持します。CrowdinやLokaliseなどのTMSプラットフォームでさえ、プロジェクトごとにエクスポート形式を手動で構成する必要があります。

これにより、フォーマットのロックインが発生します — 翻訳は、現在のツールが生成する形式に閉じ込められます。要件が変更された場合、2つのオプションがあります。

1. 新しい形式ですべてを再翻訳する（費用がかかり、時間がかかり、手動で修正した内容が失われます）
2. カスタム変換スクリプトを作成する（エラーが発生しやすく、特に複雑な複数形と変数の場合）

どちらのオプションも良くありません。どちらも時間と金を無駄にします。どちらもリスクをもたらします。

フォーマットのロックインが問題となる実際のシナリオ

シナリオ1：テーマの最新化 クライアントのテーマがGutenbergブロックで再構築されています。古いPHPテンプレートは.moファイルを使用していました。新しいブロックには、wp_set_script_translations()用の.jsonが必要です。3,000個の翻訳された文字列は、移行中に両方の形式で存在する必要があります。

シナリオ2：代理店のワークフロー 20のクライアントサイトを管理します。一部は従来のテーマ（.mo）を使用しています。一部はヘッドレス構成（.json）を使用しています。カスタムフレームワークを使用してPHP配列を読み取るものもあります。異なるクライアントのために、同じ翻訳を異なる形式で提供する必要があります。

シナリオ3：専門家によるレビュー AI翻訳は95％の精度ですが、ネイティブスピーカーに残りの5％をレビューしてもらいたいと考えています。プロの翻訳者は、.xliffをインポートするCATツールを使用します。翻訳を.xliffにエクスポートし、レビューのために送信し、修正をマージして戻す必要があります。

シナリオ4：プラットフォームの移行 クライアントがWordPressからカスタムNode.jsアプリケーションに移行しています。新しいアプリはi18nextを使用しており、.jsonファイルが必要です。.po形式の5,000個の翻訳された文字列を、単一の変数や複数形を失うことなく変換する必要があります。

解決策：一度翻訳すれば、すべての形式を入手できる

SimplePoTranslateは異なるアプローチを取ります。.po、.pot、.json、または.xliffファイルをアップロードして翻訳を実行すると、5つのすべての形式を含むZIPファイルが返されます。

translations-es_ES.zip
├── flavor-starter-es_ES.po
├── flavor-starter-es_ES.mo
├── flavor-starter-es_ES.json
├── flavor-starter-es_ES.php
└── flavor-starter-es_ES.xliff

これは、エンタープライズ層の背後に隠された「プレミアム機能」ではありません。すべての有料プラン — Pro（月額19ドル）とLifetime（1回限りの399ドル） — には、すべての翻訳ジョブで5つのすべての出力形式が含まれています。

これが将来を見据えた対応策として重要な理由

最初から5つのすべての形式があれば、再翻訳する必要はありません。翻訳は、あらゆる技術的要件に適応する資産です。

• クライアントが従来のテーマからGutenbergに移行しますか？.jsonファイルをデプロイします。
• 新しい開発者がPHP配列を希望しますか？.phpファイルを渡します。
• プロの翻訳者がレビューを希望しますか？.xliffファイルを送信します。
• 別のCMSに移行しますか？.jsonファイルと.xliffファイルはプラットフォームに依存しません。

一度翻訳すれば、必要なときに形式が準備できています。

WordPressでの各形式の動作

どのファイルをどこに配置するかを知ることは、クリーンなデプロイメントに不可欠です。

.moファイルのデプロイ（従来のPHPテーマとプラグイン）

wp-content/languages/plugins/woocommerce-es_ES.mo
wp-content/languages/themes/flavor-starter-es_ES.mo

WordPressは、サイトの言語が一致すると、これらを自動的にロードします。プラグインは不要です。データベースのオーバーヘッドはゼロです。これは、最高のパフォーマンスを実現するアプローチです。

.jsonファイルのデプロイ（GutenbergブロックとJSコンポーネント）

wp-content/languages/plugins/woocommerce-es_ES-{handle}-{md5}.json

ファイル名には、スクリプトハンドルとMD5ハッシュが含まれています。WordPressは、プラグインまたはテーマでwp_set_script_translations()を呼び出すときに、これらを照合します。Gutenbergブロックを構築している場合、これは翻訳されたブロックラベルと説明を正しく表示するファイルです。

.xliffファイルの使用（プロフェッショナルレビューのワークフロー）

.xliffファイルはWordPressにデプロイされません。これらは、翻訳をプロのレビュー担当者に送信したり、CATツールにインポートしたりする必要がある場合の交換形式として使用されます。ワークフローは次のようになります。

1. .poをSimplePoTranslateにアップロードし、ZIPで.xliffを取得します
2. .xliffを翻訳者またはレビュー担当者に送信します
3. 修正された.xliffを受け取ります
4. 修正された.xliffをSimplePoTranslateにアップロードし、更新された.moと.jsonを取得します

SimplePoTranslateの構文ロックは、すべての段階で変数と複数形を保護するため、このラウンドトリップワークフローはすべての変数と複数形を保持します。

ベンダーロックインテスト

現在の翻訳ワークフローにロックインの問題があるかどうかを判断するための簡単なテストを次に示します。

1. 今すぐ翻訳を標準の.poファイルとしてエクスポートできますか？
2. 今日翻訳ツールのサブスクリプションをキャンセルした場合、翻訳されたすべての文字列を保持できますか？
3. 再翻訳せずに、翻訳をまったく異なるツールまたはプラットフォームにインポートできますか？

これらのいずれかの答えが「いいえ」の場合、ロックインされています。WeglotやGTranslateなどのサービスは、3つの質問すべてに失敗します — サブスクリプションをキャンセルすると、翻訳は消えます。WPMLは翻訳をデータベースに保存するため、エクスポートは可能ですが面倒です。Poeditのようなデスクトップツールでさえ、紙の上ではテストに合格しますが、.poと.moのみに制限されます。

SimplePoTranslateを使用すると、3つの質問すべてに対する答えは「はい」です。5つの形式で標準ファイルをダウンロードできます。それらはあなたのものです。明日アカウントを削除しても、これまでに行ったすべての翻訳は引き続き機能します。

フォーマットに依存しない翻訳ライブラリの構築

複数のプロジェクトを管理する代理店や開発者にとって、最も賢明なアプローチは、翻訳ライブラリを構築することです — すべてのクライアントプロジェクトの翻訳済みファイルを保存するGitリポジトリまたは共有フォルダです。

translations/
├── client-acme/
│   ├── es_ES/
│   │   ├── flavor-starter-es_ES.po
│   │   ├── flavor-starter-es_ES.mo
│   │   ├── flavor-starter-es_ES.json
│   │   ├── flavor-starter-es_ES.php
│   │   └── flavor-starter-es_ES.xliff
│   └── de_DE/
│       └── ...
├── client-globex/
│   └── ...

クライアントが新しい形式を必要とする場合、すでに持っています。クライアントがプラットフォームを変更する場合、翻訳は労力をかけずに移行します。新しい開発者がチームに参加すると、翻訳された内容と形式を正確に確認できます。

これが「将来を見据えた対応策」の実際の意味です — クライアントが来年どのテクノロジーを使用するかを予測するのではなく、クライアントが選択したテクノロジーで翻訳が確実に機能するようにすることです。

ファイル形式について心配するのをやめる準備はできましたか？ SimplePoTranslateを無料でお試しください — 1つのファイルをアップロードして、5つの形式を入手してください。変換スクリプトも、再翻訳も、ロックインもありません。