Polylang と TranslatePress: 2026 年に実際に勝つのはどちらのプラグインですか?

5 つの比較記事を読みました。

彼らは皆、「どちらのプラグインも素晴らしいです。ニーズ次第です。」と同じことを言います。

役に立ちますね?

彼らが教えてくれないことは次のとおりです。 起動後に翻訳プラグインを切り替えるのは致命的です。 移行パスはありません。簡単なボタンはありません。すべてを最初から再翻訳するか、SEO タンクを監視します。

この記事は違います。

実際のパフォーマンスの数値、ありのままの価格設定 (ほとんどのレビューで隠されている隠れたコストを含む)、そして実際にあなたの働き方に適合した意思決定の枠組みが表示されます。

最後に到達するまでに、どのプラグインが「勝った」のかがわかるだけでなく、どちらが勝ったのかもわかるようになります。 あなたの特定の状況に合わせて。そして、それを確実に知ることができるでしょう。

何が問題になっているのか

ポリラング vs TranslatePress 機能の比較ではありません。それはアーキテクチャ上の決定です。

1 つのプラグインは、翻訳を重複した WordPress 投稿として保存します。もう 1 つは、それらをデータベース文字列として保存し、ページのレンダリング時に交換します。これらのアプローチには互換性がありません。間違ったものを選択すると、閉じ込められてしまいます。

時間を無駄にしないようにしましょう。直接行きましょう。

クイック評決マトリックス

あなたの優先事項	これを選んでください	なぜ
パフォーマンス + 開発者コントロール	ポリラング	オーバーヘッドは 1.0 秒に対して 0.7 秒。無料のSEO機能。スケールが良くなる
クライアントハンドオフ + ビジュアル編集	翻訳プレス	フロントエンドインターフェイス。レイアウトの再構築は必要ありません。代理店対応
予算の WooCommerce ストア	翻訳プレス	99 ユーロ/年 vs Polylang の 139 ユーロ/年
大規模なサイト (5,000 以上の投稿)	ポリラング	データベースネイティブのスケーリングは文字列検索よりも優れています
ページビルダーが重い	翻訳プレス	エレメンターフレンドリー。言語ごとの再構築はありません

結論: Polylang はスピードとコントロールの点で優れています。 TranslatePress は、シンプルさと引き継ぎワークフローで優れています。

この決定が見た目よりも重大である理由

機能について詳しく説明する前に、サイトの公開後に翻訳プラグインを切り替えるのは非常に面倒であることを理解してください。お問い合わせフォームのプラグインを交換するようなものではありません。コンテンツの損失、URL 構造の変更による SEO の中断、および何時間もの再翻訳作業が必要になるリスクがあります。

2 つのプラグインは、基本的に互換性のない方法で翻訳を保存します。それらの間にはシームレスな移行パスはありません。

これは、今日の選択が、実質的にサイトの存続期間にわたる選択となることを意味します。だからこそ、正しく理解することが重要なのです。

主要なアーキテクチャの違いを理解する

これはほとんどの比較が無視してしまうセクションですが、必ず読んでいただく最も重要な部分です。

Polylang の仕組み: Duplicate-Post アーキテクチャ

Polylang は、翻訳ごとに完全に個別の WordPress 投稿を作成します。英語でブログ投稿を公開すると、Polylang は完全に独立したスペイン語版を新しい投稿としてデータベースに作成します。これらの投稿は相互にリンクされていますが、それ以外の場合は別個のコンテンツとして扱われます。

このアプローチは、WordPress が動作するように構築された方法を反映しています。各言語バージョンには独自の URL、独自のメタデータ、独自の SEO フィールドがあり、さらに重要なことに、必要に応じて独自のページレイアウトもあります。

訪問者がスペイン語のホームページをリクエストすると、WordPress はデータベースからスペイン語の投稿をロードするだけです。実行時に翻訳処理は行われません。ページは 1 つのものであるため、他の WordPress 投稿と同じくらい速く読み込まれます。

トレードオフ: すべてのコンテンツを手作業で複製し、翻訳する必要があります。 2 つ (またはそれ以上) の並列コンテンツライブラリを管理しているとします。

TranslatePress の仕組み: 文字列置換アーキテクチャ

TranslatePress は重複した投稿を作成しません。代わりに、翻訳をテキスト文字列として別のデータベーステーブルに保存します。訪問者がスペイン語のホームページをリクエストすると、TranslatePress はサイトのレンダリングされた HTML 出力をインターセプトし、すべてのテキスト文字列に相当するスペイン語を検索して置き換え、翻訳されたページを配信します。

これにより、そのビジュアルなフロントエンドエディターが可能になりました。訪問者とまったく同じようにページを表示し、テキストを直接クリックして翻訳できるようになります。

トレードオフ: ページをレンダリングするたびに、文字列検索のための追加のデータベースクエリがトリガーされます。プラグインは、ロードのたびに HTML をインターセプト、解析、書き換え、再発行する必要があります。小規模および中規模のサイトの場合、このオーバーヘッドは管理可能です。大量の翻訳コンテンツを含むトラフィックの多いサイトの場合、他のアーキテクチャには存在しないパフォーマンスの上限が生じます。

この違いが他のすべてに波及する理由

この 1 つのアーキテクチャ上の決定により、次のことが説明されます。

Polylang が生のベンチマークで高速である理由
TranslatePress がより直感的な編集エクスペリエンスを備えている理由
TranslatePress が JavaScript でレンダリングされたコンテンツに苦戦する理由
Polylang が翻訳を維持するためにより多くの手作業を必要とする理由
Polylang ではキャッシュがオプションであるのに、TranslatePress では事実上必須である理由

以下のすべての機能比較は、この根本的な違いに基づいています。

翻訳インターフェースと使いやすさ

Polylang のバックエンドワークフロー

Polylang を使用すると、WordPress 管理内で完全に翻訳できます。投稿リストには、各コンテンツが小さな旗アイコンとともに表示され、どの言語に翻訳があり、どの言語が保留中であるかを示します。アイコンをクリックして翻訳を作成または編集すると、WordPress によってその言語バージョンの標準エディターが開きます。

このワークフローは、WordPress に慣れている人にとっては自然なものです。クリーンで予測可能で、コンテンツ構造を完全に制御できます。スペイン語版のページは、まったく別の投稿であるため、異なる画像、異なるレイアウト、異なる CTA など、英語のオリジナルとはまったく異なる外観にすることができます。

苦労しているところ: コンテンツが Elementor や Divi などのページビルダーで構築されている場合、各ページを翻訳するということは、言語バージョンごとにページビルダーレイアウトを再構築することを意味します。 3 つの言語で 50 ページのサイトの場合、管理するのは 150 ページになります。気持ち良くスケールしません。

TranslatePress のビジュアルフロントエンドワークフロー

TranslatePress は、WordPress カスタマイザーに非常によく似た分割画面インターフェイスを開きます。右側にライブサイトが表示されます。左側は翻訳パネルです。ライブサイト上の任意のテキストをクリックすると、その文字列の翻訳フィールドが左側に表示されます。翻訳を入力して保存すると、変更がすぐに表示されます。

この経験は本当に素晴らしいです。抽象化はありません。訪問者が目にするものを正確に確認できます。 WordPress 管理者に詳しくなくても自分で翻訳を管理する必要があるクライアントにとって、これは驚きです。

ページビルダーにとっては、TranslatePress が最適です。基盤となるデータ構造ではなく、レンダリングされた HTML を変換するため、ページビルダーの出力がどれほど複雑であっても、テキストをキャプチャできます。レイアウトを再構築する必要はありません。

苦労しているところ: JavaScript または AJAX 経由でロードされたコンテンツ (Elementor ポップアップ、ライブ検索、動的製品フィルターで一般的) は、多くの場合、ビジュアルエディターではキャプチャされません。これは、TranslatePress が翻訳用に登録するために、最初のページレンダリング内の文字列を確認する必要があるためです。

UX に関する実際的な判断

翻訳を自己管理する必要があるクライアント向けのサイトを構築している場合は、TranslatePress の方が劇的に優れています。 Polylang のバックエンドシステムと比較すると、学習曲線はほぼゼロです。

あなたが翻訳を自分で管理しており、言語ごとのレイアウト制御が必要な開発者にとって、Polylang のアプローチにより柔軟性が高まります。

パフォーマンスとサイト速度

パフォーマンスでは、アーキテクチャの違いが実数になります。

ベンチマークデータ

複数のソースにわたる独立したテストでは、一貫したパターンが示されています。

ポリラング およそ追加します 0.7秒 ページサイズへの影響を最小限に抑えながらロード時間を短縮します (追加重量が 85 KB 未満)。プラグインは、ページごとに約 4 つの追加データベースクエリを生成します。
翻訳プレス およそ追加します 1.0秒 ロード時間と前後 127KB ページサイズに合わせて。文字列検索プロセスはレンダリングごとに実行されます。

キャッシュされていないページの読み込みでは、特に Google 検索ランキングに直接影響する Core Web Vitals スコアの場合、これは意味のある違いです。

キャッシングに関する注意点

適切なキャッシュを使用すると、パフォーマンスの差が大幅に縮まります。どちらのプラグインも、WP Rocket、W3 Total Cache、および同様のソリューションと互換性があります。キャッシュされたページでは、オーバーヘッドの差ははるかに小さくなります。

ただし、重要な違いがあります。Polylang の場合、優れたキャッシュプラグインはパフォーマンスの向上につながります。 TranslatePress の場合、これは事実上要件です。キャッシュせずに TranslatePress を実行すると、大幅なパフォーマンスが低下します。

さらに、TranslatePress の HTML 書き換えアプローチは、他のプラグインが出力を処理した後に出力をインターセプトするため、一部のキャッシュ設定と予期せず相互作用する可能性があります。

スケーリングに関する考慮事項

小規模から中規模のサイト (投稿数が 5,000 未満、トラフィックが中程度) では、パフォーマンスの違いが実際にはほとんど問題になりません。ホスティングとキャッシュが適切であれば、どちらのプラグインも許容可能な速度を実現します。

大規模なサイト (ニュース出版社、大手 e コマースストア、5 か国語以上のトラフィックの多いブログ) の場合、Polylang のデータベースネイティブのアプローチは、より予測どおりに拡張できます。 TranslatePress のアーキテクチャには上限があり、サイトが成長するにつれて、文字列検索のオーバーヘッドも増加します。

SEO機能

多言語 SEO には特定の技術要件があります。言語の関係を Google に知らせるための hreflang タグ、各言語の翻訳された URL スラグ、言語ごとのメタデータ (タイトル、説明)、個別の XML サイトマップです。

各プラグインがこれらの要件をどのように処理するか、および価格帯は次のとおりです。

Polylang の SEO スタック

Polylang の無料バージョンには次のものが含まれます。

hreflang タグ — 自動的に生成され、正しくフォーマットされる
個別のクロール可能な URL 言語ごと (サブディレクトリ、サブドメイン、または個別のドメイン)
Yoast SEO および Rank Math との完全な統合 — どちらも Polylang の構造を認識し、言語ごとのメタタイトル、説明、ソーシャルタグをネイティブに設定できます
自動正規タグ 重複コンテンツの問題を防ぐため

重要な洞察: 各言語バージョンは個別の WordPress 投稿であるため、Yoast/Rank Math はそれを処理する方法をすでに知っています。 Polylang には独自の SEO レイヤーは必要ありません。すでに使用している SEO プラグインを利用します。

支払う必要があるもの: カテゴリとタクソノミーの URL スラッグ変換には Polylang Pro が必要です。

TranslatePress の SEO スタック

TranslatePress の無料版には以下が含まれます:

基本的な hreflang タグの実装
言語固有の URL

支払う必要があるもの: URL スラッグ、ページタイトル、メタディスクリプション、および XML サイトマップの最適化を翻訳するには、すべて SEOパックアドオン、年間 99 ユーロ (個人層) から始まる有料プランでのみ利用可能です。 SEO Pack を使用しないと、異なる言語バージョンが同じメタデータを共有することになり、ランキング上の重大なデメリットとなります。

SEO コストの現実

予算がゼロの場合、Polylang はより完全な無料の SEO サポートを提供します。 Polylang と Yoast または Rank Math との無料統合は、適切に構成された多言語サイトが SEO に必要とする基本的なすべてをカバーします。

TranslatePress の無料枠では、翻訳されたページがメタデータを共有したままになるため、各言語バージョンがターゲット市場の検索結果でどれだけ効果的に競合できるかが制限されます。

有料ユーザーの場合、両方のプラグインは SEO と完全に同等に達することができます。TranslatePress は魅力的な視覚的利点も追加し、公開前に翻訳されたメタディスクリプションがどのように表示されるかを正確にプレビューできます。

自動翻訳

どちらのプラグインも、無制限の無料自動翻訳を提供しません。しかし、彼らのアプローチは興味深い点で異なります。

Polylang の自動翻訳

Polylang の無料版は完全に手動です。コアプラグインには自動翻訳はありません。自動翻訳を取得するには:

ポリランプロ Pro プランで自動翻訳のための DeepL 統合を有効にします (年間 99 ユーロから)
Lingotek などのサードパーティのプラグインにより、無料版に自動翻訳を追加できます

知っておく価値のある文書化された問題の 1 つ: Polylang Pro の DeepL による自動翻訳には、特定の構成で Elementor と競合することが知られています。 Polylang は独自のドキュメントでこれを認めています。

Google 翻訳は Polylang ではサポートされていません。これは、Polylang が含まれていない数少ない主要な翻訳プラグインの 1 つです。

TranslatePress の自動翻訳

TranslatePress には無料枠で大きな利点があります。新規ユーザーは 2,000 AI 翻訳クレジット サインアップ時に、Google 翻訳や Microsoft Translator などのトップ翻訳モデルから選択する独自の AI サービスを利用します。

有料プランでは、自動翻訳オプションが大幅に拡張されます。

個人 (99 ユーロ/年): 50,000語のAI翻訳 + Google翻訳
ビジネス (199 ユーロ/年): 200,000語のAI翻訳 + DeepL統合
開発者 (年間 349 ユーロ): 500,000 語の AI 翻訳 + すべて

TranslatePress はハイブリッドアプローチもサポートしています。つまり、自動翻訳を使用して最初のドラフトを作成し、次に品質が重要なセクションを手動で修正します。このワークフローは、完全な手動翻訳が現実的ではない大規模なサイトに特に効果的です。

価格の内訳

Polylang の価格設定

プラン	価格	サイト	主な特長
無料	€0	1	手動翻訳、hreflang、無制限の言語、Yoast/Rank Math の統合
プロ	99ユーロ/年	1	+ DeepL 自動翻訳、分類スラッグ翻訳、ACF 統合
WooCommerce アドオン	99ユーロ/年	1	WooCommerce 製品/カート/チェックアウトの翻訳 (Pro が必要)
ビジネスパック	139ユーロ/年	1	Pro + WooCommerce の組み合わせ

WooCommerce ストアの重要な詳細: Polylang を使用して WooCommerce ストアを翻訳するには、少なくとも Business Pack (1 サイトあたり年間 139 ユーロ) が必要です。これが e コマースの本当の参入価格であり、99 ユーロではありません。

TranslatePressの価格設定

プラン	価格	サイト	主な特長
無料	€0	1	ビジュアルエディター、1 つの追加言語、2K AI クレジット、基本的な WooCommerce 文字列
個人的	99ユーロ/年	1	多言語、SEO パック、50,000 AI ワード
仕事	199ユーロ/年	3	DeepL、翻訳者アカウント、自動言語検出、200K AI ワード
開発者	349ユーロ/年	無制限	ビジネスのすべて、500,000 の AI ワード

SEO にとって重要な詳細: SEO パック (スラッグ翻訳、メタ翻訳) は、パーソナルプラン以降にのみ含まれます。無料利用枠にはこの機能がありません。

正直な総所有コスト

単一の標準多言語サイト (WooCommerce ではない) の場合:

ポリ言語: 無料で始められます。自動翻訳と高度な機能は年間 99 ユーロ
翻訳プレス: 無料で始められます。適切な SEO と複数言語の場合は年間 99 ユーロ

WooCommerce ストアの場合:

ポリ言語: 最低 €139/年 (ビジネスパック)
翻訳プレス: 99 ユーロ/年 (個人 — WooCommerce 文字列は有料レベルに含まれます)

TranslatePress は、多言語の WooCommerce セットアップに対して価格的に若干有利です。

WooCommerce の互換性

WooCommerce 用の Polylang

Polylang の WooCommerce 統合は、重複投稿アーキテクチャに従っています。各製品には、個別の WooCommerce 製品として作成された翻訳版が必要です。 Polylang はそれらをリンクし、在庫管理、製品の可用性、カートの動作がすべての言語バージョンで正しく機能することを保証します。

セットアップにはビジネスパック (年間 139 ユーロ) が必要で、完全に異なる製品説明、異なる通貨での異なる価格設定 (サードパーティのプラグイン経由)、言語ごとに異なるプロモーションコピーを作成する機能など、真の奥深さを提供します。

大規模なカタログを管理する代理店にとって、このレベルの言語ごとの制御は貴重です。その代償として、新しい製品を追加するということは、すべての言語で最初から製品を作成することになるということです。

WooCommerce 用の TranslatePress

TranslatePress のビジュアルエディターのアプローチは WooCommerce にも拡張されています。ターゲット言語でストアフロントを参照し、製品名、説明、カートのラベル、チェックアウトのテキストをクリックして、それらを直接翻訳します。翻訳は既存のコンテンツを置き換えるのではなく、上書きするため、製品カタログは 1 つの製品に複数の言語で翻訳され、無駄のないものになります。

ビジュアルエディターは、製品ページ、カテゴリ、チェックアウトフローに適しています。この制限は、AJAX で読み込まれたコンテンツに依存する大幅にカスタマイズされた WooCommerce セットアップで発生します。動的製品フィルター、ライブ検索結果、およびリアルタイムのカート更新がすべてエディターでキャプチャされるわけではありません。

標準の WooCommerce 機能を備えたシンプルなストアの場合、TranslatePress はより高速な翻訳ワークフローを提供します。複雑で大幅にカスタマイズされたストアの場合は、コミットする前に特定の設定を慎重にテストしてください。

ページビルダーの互換性

どちらのプラグインも主要なページビルダー (Elementor、Divi、Beaver Builder、Bricks) をサポートしていますが、エクスペリエンスは異なります。

Polylang + ページビルダー: 翻訳ごとに、その言語用のページビルダーレイアウトを再構築する必要があります。 3 つの言語を含む 30 ページのサイトでは、Elementor で構築された 90 の個別のページを作成することになります。これは管理可能ですが、時間がかかります。 Polylang Pro の DeepL 自動翻訳には Elementor との競合が文書化されていることに注意してください。これについては Polylang 自身のドキュメントで警告されています。

TranslatePress + ページビルダー: ビジュアルエディターは、ページビルダーの出力方法に関係なく、レンダリングされたページに表示されるテキストをキャプチャします。レイアウトを再構築するのではなく、表示されているテキストを翻訳するだけです。これは時間的に大幅なメリットとなります。 Elementor ポップアップまたは AJAX 駆動のウィジェット経由でロードされた動的コンテンツには、依然として回避策が必要な場合があります。

ページビルダーを使用してサイトを構築し、翻訳のためにクライアントに渡す代理店にとって、TranslatePress は実用的な選択肢です。

開発者のエクスペリエンスとカスタマイズ

開発者向けの Polylang

Polylang はクリーンな開発者 API を提供します。

pll_e() そして pll__() カスタムテーマ/プラグイン文字列を翻訳するための関数
カスタム言語切り替えロジック用のフックとフィルター
WordPress マルチサイトとの完全な互換性
クリーンな URL 構造制御 (言語ごとのサブディレクトリ、サブドメイン、またはカスタムドメイン)

各翻訳は標準の WordPress 投稿であるため、WordPress 投稿システムと対話するプラグインやツールと適切に連携します。

注意点: カスタムテーマとプラグインの文字列は、Polylang の翻訳関数を使用するようにコーディングされている場合にのみ翻訳可能になります。 Polylang 互換性を備えて構築されていないテーマやプラグインは、開発者が追加する必要があります。

開発者向けのTranslatePress

TranslatePress のアーキテクチャは、開発者がこれを異なる方法で操作することを意味します。ビジュアルエディターは、ページ上に表示されるほとんどの文字列を自動的に捕捉するため、カスタム関数呼び出しの必要性が減ります。ただし、動的に生成された文字列 (AJAX コンテンツ、JavaScript でレンダリングされた要素) には追加の構成が必要です。

このプラグインは、その動作を拡張するためのフィルターとフックを提供します。また、その文字列ベースのアプローチにより、ポストベースの翻訳とは異なり、翻訳が移植可能になります。

特定の使用例の推奨事項

次の場合は Polylang を選択してください。

パフォーマンスを最優先にして、コンテンツの多いブログやニュースサイトを構築している
言語ごとのレイアウト制御が必要（市場ごとに異なるページデザイン）
開発者は WordPress 管理者での作業に慣れていますか
Yoast SEO または Rank Math に依存しており、無料枠でのシームレスな多言語メタデータ管理が必要な場合
ミリ秒ごとのページ読み込みが重要となる高トラフィックのサイトを構築している
言語市場ごとに大幅に異なるコンテンツ (翻訳だけでなく) を作成する必要がある

次の場合は、TranslatePress を選択してください。

独自の翻訳を管理する必要があるクライアント向けにサイトを構築しています
Elementor や Divi などのページビルダーと幅広く連携します
すぐに使える自動翻訳が必要です (無料枠でも)
限られた予算内で WooCommerce ストアを翻訳する必要がある (Polylang のビジネスパックよりも安い)
多言語サイトを急いで立ち上げており、最初のドラフトとして AI 翻訳を使用したいと考えています
作業中に文脈の中で翻訳を確認することを大切にする

グレーゾーン

複数のクライアント向けに多言語サイトを構築する代理店: どちらも機能しますが、TranslatePress の視覚的な引き継ぎストーリーの方が強力です。クライアントはインターフェイスをすぐに理解します。

小規模な WooCommerce ストア、予算が限られている: TranslatePress は価格面で勝っています。基本的な WooCommerce 翻訳は年間 99 ユーロのパーソナル層で利用できますが、Polylang のビジネスパックは最低でも年間 139 ユーロです。

大規模な e コマース (100 以上の製品、5 言語以上): どちらでも機能しますが、Polylang のアーキテクチャは、カタログサイズが大きくなるにつれて、より予測どおりに拡張できます。

単一ページのサイト、または JavaScript に大きく依存するサイト: どちらのプラグインも、JS でレンダリングされたコンテンツを完全には処理しません。 TranslatePress は視覚的なアプローチで優位性を持っていますが、AJAX コンテンツを見逃す可能性があります。徹底的にテストしてください。

切り替えの問題: 最初の選択が本当に重要な理由

ほとんどの記事では、プラグインを後で切り替えることができると記載されています。現実はもっと厳粛なものだ。

Polylang と TranslatePress は、根本的に異なるデータベース構造に翻訳を保存します。 Polylang 翻訳は重複した投稿に存在します。 TranslatePress の翻訳はカスタム文字列テーブルに存在します。これらの間には公式の移行ツールはありません。

切り替えの意味:

新しいシステムですべてのコンテンツを最初から再翻訳する
既存のインデックス付きページとバックリンクを破壊する URL 構造の変更の可能性
慎重に手動で移行しないと言語ごとのメタデータが失われる
サイトが複雑な場合、開発にかなりの時間がかかる

唯一のクリーンな移行パスは、Polylang → WPML です (Polylang は、この特定の方向向けに無料の移行ツールを提供しています)。他の場所に移動するということは、新たにスタートすることを意味します。

実践的なアドバイス: コミットする前に、ステージングサイトにプラグインをインストールし、ワークフロー全体を通じて 10 ～ 15 の実際のページを変換します。各プラグインの実際の使用感の違いは、すぐに明らかになります。そして、直感レベルのワークフローの適合性は、機能の比較と同じくらい重要です。

よくある質問

Polylang と TranslatePress はどちらが SEO に優れていますか? Polylang は、言語ごとのメタデータの完全な Yoast/Rank Math 統合を含む、より完全な SEO サポートを無料枠で提供します。 TranslatePress では、URL スラッグとページのメタデータを翻訳するには、有料の SEO Pack アドオン (年間 99 ユーロの個人プランから) が必要です。有料ユーザーの場合、どちらも完全な SEO 機能に達します。

どのプラグインが速いですか? 生のベンチマークでは Polylang の方が高速で、読み込み時間が約 0.7 秒増加するのに対し、TranslatePress は約 1.0 秒かかります。 TranslatePress の追加のオーバーヘッドは、ページが表示されるたびに実行される HTML 文字列置換プロセスから発生します。適切にキャッシュを行えば、その差は大幅に縮まります。

自動翻訳は無料で利用できますか? TranslatePress では、サインアップ時に 2,000 の無料 AI 翻訳クレジットを提供します。 Polylang の無料版では自動翻訳は提供されません。

どちらが WooCommerce に適していますか? どちらも WooCommerce の有料プランが必要です。 TranslatePress は WooCommerce の方が年間 99 ユーロ (個人) に対し、Polylang の年間 139 ユーロ (ビジネスパック) よりわずかに安くなります。 Polylang は、製品ごとにさらに深いカスタマイズを提供します。 TranslatePress はより簡単なセットアップを提供します。

後で Polylang から TranslatePress に切り替えることはできますか? これらの間には公式の移行ツールはありません。切り替えるには、新しいシステムですべてのコンテンツを再翻訳する必要があり、URL 構造の変更により SEO が中断されるリスクがあります。発売前に慎重に選択してください。

TranslatePress は Elementor と連携しますか? 一般的にはそうです。 TranslatePress のビジュアルエディターは、Elementor でレンダリングされたテキストをうまくキャプチャします。 Polylang Pro は、DeepL 自動翻訳を使用する際の Elementor との競合を文書化していることに注意してください。これは、TranslatePress が設計上回避しているものです。

どのプラグインがYoast SEOで動作しますか? どちらも Yoast SEO で動作します。 Polylang の統合はネイティブです。Yoast は、追加の構成を行わなくても、翻訳された投稿ごとに言語ごとの SEO フィールドを自動的に提供します。 TranslatePress では、Yoast メタデータを翻訳するために SEO Pack アドオンが必要です。