WPML Multilingual CMS 5.2.0

リリース日: 2026年10月21日
チャネル: 安定版
テスト済みのWordPress: 7.1
製品: WPML Multilingual CMS

変更履歴

保存とページの高速化、再構築された翻訳ダッシュボード、より明確になった自動翻訳、および355件の修正。

新機能

アカウントの支払いができない場合、自動翻訳はジョブを進行中のままにせず、「請求へ進む」で一時停止し、支払い後に再開します。
翻訳ダッシュボードのコンテンツリストを再構築しました。多くの言語を持つサイトで機能し、各投稿を1回だけリストし、ステータスフィルターが列と一致します。
カスタムフィールドの翻訳設定を変更すると、追跡されるバックグラウンドタスクとして既存のコンテンツが更新され、設定には各オプションの機能が説明されます。
翻訳済みコンテンツに対する小さな編集で、既存の翻訳が失われたり、完全な新規翻訳として課金されたりしなくなりました。
カテゴリーやタグの名前と説明は1回だけ翻訳および課金され、それらを使用する各投稿で再度課金されることはありません。
製品バリエーションは「すべてを翻訳する」の対象外となり、以前に作成された空のバリエーションジョブは廃止されます。
すでに翻訳されたコンテンツのジョブをキャンセルすると、以前の状態に復元されます。
WPMLの管理画面は、右横書き（RTL）言語を含め、管理画面の言語に従います。
コメント数は言語ごとに表示され、投稿ステータスは元の言語と翻訳の間で同期を保ちます。
レビューモードは翻訳バッチごとに保持され、高度な翻訳エディタは元のテキストが変更されたメディアやタクソノミーのテキストをマークします。
マルチサイト：サブサイトのセットアップウィザードは、ユーザーのクエリを破損することなくサイトキーを正しく処理し、サブサイトでサイトキーの不一致が報告されなくなりました。
翻訳優先度は削除され、サイトにセカンダリ言語が残っている間は「WPML をリセット」がブロックされます。
wpml.orgへのサイトのチェックインには、セットアップと自動翻訳の正常性が含まれます。セットアップウィザードと設定にある1つのオプトインチェックボックスで、コンテンツの統計情報とプラグインリストの共有を制御します。
すべてのWPMLアドオンはWPMLと同じソースから構築され、WPMLと同時にリリースされます。
すべてのWPMLアドオンはWPMLと同じ共有ライブラリバージョンを保持しているため、どのプラグインが最初に読み込まれても「WPMLのアップデートが不完全です」の通知は翻訳されたままになります。
セキュリティの強化：保存データのより厳格な処理、リクエスト入力の検証、より安全なファイル削除、ファイル名とインクルードパス、および保存された値のエスケープ。
管理者ロールがWPMLの権限を失った場合、WPMLはそれらを復元するため、新しい管理者はWPMLのすべての機能を確認できます。
セットアップウィザードの最小要件の警告を無視して後で消えてしまうことがなくなりました。
データベースの問題でコンテンツの翻訳への送信に失敗した場合、ポップアップにエラーの詳細が表示されます。
WPMLがアカウントの利用可能な単語数を読み取れない場合、明確なステータスとメッセージが表示されます。
正常に作成されたジョブの横で失敗し続けるジョブが、無制限に再試行されなくなりました。
新しい送信によってのみ終了できる接続障害の間、バナーに再試行のカウントダウンが表示されなくなりました。
翻訳キューでは、ステータスフィルターでチェックを入れたステータスが、ジョブリストの読み込み後もチェックされたままになります。
翻訳ダッシュボードの「自動翻訳の料金がアップグレードされました」の通知が、空のままにならずに内容を表示するようになりました。
「翻訳言語がエンコードされたURLを使用している場合は元の言語からコピーする」を選択すると、エンコードされたURLを使用しているアクティブな言語がない場合に警告が表示されます。
ドロップダウンの言語スイッチャーはキーボードやクリックで開くようになり、スクリーンリーダーに開いているかどうかを伝えます。
言語スイッチャーのドロップダウンアイコンは、選択できる翻訳がある場合にのみ表示されます。
サイトにアクティブな言語が1つしかない場合、言語スイッチャーはオフになります。
カスタム投稿タイプの年別アーカイブの言語スイッチャーは、正しいアーカイブにリンクします。
言語ごとに異なるドメインを持つサイトでは、投稿とページのプレビューに正しいアドレスが使用されます。
投稿リストに、進行中の翻訳の正しいアイコンが表示されます。
time要素を含むコンテンツは、翻訳のために分割されてもHTMLがそのまま維持されます。
複数のブラウザタブで作業しても、ブロックエディタで言語が混在しなくなりました。
高度な翻訳エディタからキャッシュされた言語ペア情報が古くならず、自動的に修復されます。
翻訳を別の翻訳グループに接続する際に、成功を報告しているのに失敗することがなくなりました。
ページなどの階層型投稿タイプの管理リストで、各投稿に対して翻訳クエリを実行しなくなり、クエリサイズを制限するホストでの失敗が解消されました。
カテゴリー、タグ、その他のタームの自動翻訳の信頼性が向上しました。
サポートツールの古い管理アドレスは、個別のコピーではなく1つのサポートページに繋がります。
Meta Boxなどのフィールドベースのビルダーから自動的に検出されたブロックは、テキスト属性のみを翻訳対象として提供します。
Avada：Fusion Post Cardsウィジェットが翻訳されます。
WP User Manager：プロフィールページの言語スイッチャーは、一般的なページではなく、翻訳されたプロフィールページに繋がります。
コピーまたは移動したサイトの再接続に失敗した場合でも、WPMLはサイトキーをクリアしなくなり、アップデートと自動翻訳が引き続き機能します。
base64エンコードとして登録されているが、実際にはプレーンテキストを保持しているショートコード属性を翻訳できるようになりました。

パフォーマンス

Elementorテンプレートを含め、ページやテンプレートを保存する際に、変更されていない翻訳を書き換えなくなったため、多くの言語を持つサイトでの保存が大幅に高速化されました。
WooCommerceサイトのフロントエンドページの読み込みが高速化されました。各製品タームごとにURLルールが再読み込みされなくなりました。
キャッシュされたフロントエンドリクエストが、ページビューごとにWPMLの言語テーブルについてデータベースに問い合わせなくなりました。
フロントエンドリクエストが、アップグレードの進行状況を書き込んだり、WPMLのテーブルレイアウトを再読み込みしたりしなくなりました。
投稿の編集画面で、読み込みごとに翻訳エンジンの検索を待つことがなくなり、失敗した検索が各ページで再試行されなくなりました。
多くのプラグインを使用しているサイトで投稿を編集しても、メモリ不足にならなくなりました。
翻訳されたタームが多いサイトで、翻訳管理ダッシュボードがタイムアウトしなくなりました。
翻訳管理ダッシュボードで単語数をカウントする際に、メモリ不足にならなくなりました。
RedisやWP Engineなどの永続的オブジェクトキャッシュを使用しているサイトで、WPML → 翻訳がメモリ不足にならなくなりました。
URL解決キャッシュテーブルが無制限に増大しなくなり、ルーティング設定の保存時にテーブル全体をカウントしなくなりました。
メニュー、ウィジェット、製品フィルターなどの、長いinclude、exclude、または子リストを持つタームクエリが、1つのデータベースクエリで翻訳されます。
クエリの外部で読み取られた製品タームの翻訳は、リクエストごとに1回検索されます。
ブロックのデフォルトテキストは、リクエストごとのすべての登録済みブロックタイプに対してではなく、ブロックのレンダリング時に翻訳されます。
WP-CLIコマンドのメモリ使用量が減少しました。WPMLはコマンドが必要とする場合にのみインストーラーを読み込みます。
マルチサイト：サイト間の切り替え時に、回復するものがない場合は回復チェックを実行しなくなったため、ネットワーク管理画面の読み込みが再び高速化されました。
WooCommerce製品コレクションブロックで表示される製品の製品翻訳が、1つのクエリで検索されます。
WP Rocketは、各言語ディレクトリと同様にサイトのルートページを最適化し、それに対して「Empty buffer」をログに記録しなくなりました。
Elementorページで、各要素に対してすべてのWooCommerceのdynamic-idコンバーターを実行しなくなりました。
管理画面で、リクエストごとにすべてのサードパーティブロックのデフォルトテキストを再登録しなくなり、多くのデータベースクエリが節約されます。
一部のアップグレードされたサイトでは、言語カタログの更新がリクエストごとではなく1回だけ実行されます。
投稿の保存時に毎回WPMLのテーブルを再確認しなくなり、ブロック投稿は文字列パッケージを1回だけ読み取ります。
ブロックテーマやWooCommerceショップのフロントエンドページでは、ブロックの翻訳、タームスラッグ、翻訳されたURLルールを、使用ごとではなくページごとに1回読み取ります。
WPMLが有効期限なしでキャッシュした値は、期限切れとして削除されるのではなく保持されます。
スラッグによるタームの検索で、リクエスト内の検索ごとに同じ調整を繰り返さなくなりました。
WPMLはホームURLの検索ごとに完全なスタックトレースを取得しなくなり、そのホームURLフィルターがキャッシュされます。
WPMLは、すべての管理画面、RESTリクエスト、AJAX呼び出しでメールテンプレートエンジンを読み込まなくなったため、読み込まれるファイルが少なくなります。
管理画面の読み込みごとに、決定待ちのカスタムフィールドを持つ投稿をカウントしなくなりました。
管理画面が、遅いREST APIの確認やデータ解凍エラーによって遅延しなくなりました。
ページビルダー：1つのリクエストで複数の翻訳を保存する際に、以前のすべての投稿を再度再構築しなくなりました。
投稿リストで、行ごとに翻訳クエリを実行しなくなりました。
AI 翻訳設定ページは、翻訳システムからの応答を待たずに読み込まれます。
大規模な多言語サイトでの投稿の保存が高速化されました。
多くのカスタムフィールドを持つ投稿への翻訳の適用が高速化されました。
非常に多くのタームを持つサイトで、タクソノミーの翻訳ページがタイムアウトしなくなりました。
翻訳ダッシュボードは、翻訳可能なコンテンツタイプをページごとに2回ではなく1回読み取ります。

自動翻訳と「すべてを翻訳する」の修正

「すべてを翻訳する」は、上限が引き上げられたり月がリセットされたりした後も、月額利用上限のために一時停止したままにならなくなりました。
一時停止中の「すべてを翻訳する」ボックスに、現在の月額利用上限と今月の利用量が表示されます。
未翻訳のフォームメッセージなど、以前の翻訳で元の言語からコピーされただけのテキストは、完了として扱われるのではなく自動的に翻訳されるようになりました。一方、翻訳者が意図的に完了したコピーは保持されます。
「すべてを翻訳する」は、画像などHTMLを含む説明を持つタームの翻訳を適用し、失敗したタームジョブはその理由を記載します。
「すべてを翻訳する」のコスト見積もりでは、一時停止中の言語（不足している翻訳が一時停止中の言語のみであるアイテムを含む）が除外されます。
コンテンツの以前の翻訳が削除された場合でも自動翻訳が配信され、1つの失敗したジョブが他のジョブに影響を与えなくなりました。
WPMLが完了した翻訳を要求するサイトは、残りがなくなるまで収集を続けるため、大きなバッチでも数日ではなく数分で到着します。
失敗した自動翻訳ジョブを破棄すると完全に削除され、そのテキストが再び自動翻訳に送信されることはありません。
過去のバッチが多いサイトで、「すべてを翻訳する」の文字列パスが遅延しなくなりました。
投稿、文字列バッチ、文字列パッケージ、またはタームの破棄またはキャンセルされた失敗した自動翻訳は、コンテンツが変更されるまで再送信されません。
「ローカルジョブIDをATEジョブと同期する」アクションは曖昧なジョブマッピングを拒否するため、配信が無関係な翻訳に書き込まれることはありません。
AI 翻訳設定で翻訳エンジンを切り替える際、保存に失敗した場合は「保存済み」と表示されず、失敗として報告されます。
ジョブを破棄した後、「完了できませんでした」のボックスに、すべての詳細がN/Aのジョブがリストされなくなりました。
投稿画面が開いている間に配信された翻訳は、別のプラグインが投稿の保存を処理する場合でも、元の言語とリンクを保持します。
「すべてを翻訳する」は、そのタクソノミーの処理を完了する間に作成されたタームをスキップしなくなりました。
高度な翻訳エディタが言語マッピングについて予期しない応答を返した場合でも、WPMLの管理画面は引き続き機能します。
「すべてを翻訳する」は完了した各アイテムを1回記録し、言語を削除するとNinja FormsとWPFormsのレコードからもクリアされます。
「すべてを翻訳する」のコスト見積もり（セットアップウィザードの見積もりを含む）は、投稿とそのタームフィールド、文字列、文字列パッケージ、タクソノミーラベルを送信時にカウントします。
自動翻訳のコスト見積もりにはカウントされないものがリストされるため、最終的な利用量に驚くことはありません。
「すべてを翻訳する」が管理画面外のブロックウィジェットテキストで停止しなくなり、送信できないコンテンツが後続の投稿をブロックしなくなりました。
「すべてを翻訳する」が、別のリクエストが同時に記録した進行状況を上書きしなくなりました。
「すべてを翻訳する」の単語数テーブルの下にある注記では、最初の翻訳後の編集は無料で、追加された単語に対してのみ支払うことが説明されています。
「すべてを翻訳する」は、ウィジェットが除外されている間に追加されたウィジェット文字列パッケージを、ウィジェットが再び含まれた際に送信します。
WPMLが配信された翻訳を確認するためにサイトにアクセスできない場合、ステータスボックスに確認が停止したことが表示され、今すぐ取得するオプションが提供されます。
翻訳システムがサイトのアドレスを拒否し続ける場合、WPMLはデフォルト言語のマッピングを要求することなく、再接続中であることを表示し、再試行を続けます。
配信確認中に「今すぐ翻訳を取得」を押すと、その確認が終了した直後に翻訳が収集されます。
複数の管理画面で同時に翻訳システムへの再接続が要求された場合でも、WPMLはサイトを1回だけ再登録します。
WPMLの再接続中に「既存のコンテンツを翻訳」で追加された言語は、接続が回復した後に既存のコンテンツが翻訳されます。
WPMLが翻訳システムに再接続している間、「コンテンツを翻訳」ボタンが説明なしに無効化されることがなくなりました。
進行中の翻訳があるサイトは、意図した通りに2分ごとに完了した翻訳を確認し、その確認によってブラウザが停止しなくなりました。
再接続中、翻訳ダッシュボードのステップ2には再試行のカウントダウンや「アクセスできません」のメッセージは表示されず、保留中の「すべてを翻訳する」ボタンにはその理由が説明されます。
「すべてを翻訳する」の見積もりでは、ブロックウィジェットの行が「Widget」や「Widgets」ではなく「Block」という名前になります。
セットアップウィザードのコスト見積もりは、翻訳ダッシュボードと同様に、すでに翻訳されている言語の投稿のカテゴリーをカウントしなくなりました。
翻訳エンジンが翻訳できなかったジョブは、再送信および破棄のオプションとともに、完了できなかったジョブのリストに表示されます。
「すべてを翻訳する」は、ステータス記録が失われた場合にタクソノミーラベルを2回送信して課金することがなくなりました。
WPMLが単にサポート情報を読み取れなかった場合に、「すべてを翻訳する」をオンにするとデフォルト言語がサポートされていないと主張することがなくなりました。
WPMLが翻訳システムに再接続している間、「すべてを翻訳する」ボックスは一時停止状態で表示されたままになり、何が起こっているかを説明します。
適用に失敗し続ける翻訳は3回目の試行後に中止され、再送信および破棄のオプションとともにリストされます。再送信すると新しいジョブが開始されます。
WPMLは翻訳システムからの「言語マッピングの欠落」の応答を認識し、そこでキャンセルされたジョブのエラーアイコンをクリアします。
高度な翻訳エディタから戻る際、翻訳を保存できなかった場合は、WPMLがその理由と次のステップを通知します。
別のプラグインが翻訳の1つの保存に失敗した場合でも自動翻訳は引き続き配信され、管理バーの進行状況がゼロから再開しなくなりました。
WordPressダッシュボードのアカウントウィジェットを通じて支払いを行った後、一時停止中の自動翻訳ボックスがすぐにクリアされます。
従量課金制で、保留中または失敗した支払いによって保留されているジョブは、待機している理由と続行方法を表示します。
翻訳システムとの接続障害は送信が再び機能したときにのみ終了し、再試行によって重複したジョブが通過しなくなりました。
自動翻訳への送信後、結果には実際に作成されたジョブのみがカウントされ、再試行のたびに保留中のジョブが置き換えられることがなくなりました。
「すべてを翻訳する」の送信の一部が失敗した場合、失敗したアイテムは保留され、後で再送信されます。
プロキシページなど、WPMLが読み取れない応答によって、それらのアイテムが自動翻訳から永久にブロックされることがなくなりました。
WPMLが障害の復旧を待っている間、投稿エディタや投稿リストなど、翻訳ダッシュボードの外部からの送信が拒否されなくなりました。
接続に関する通知は、アカウントの問題と高度な翻訳エディタの問題を区別するため、一方が他方を隠すことがなくなりました。
別のリクエストが送信中に以前の障害を閉じたため、新しい接続障害ですぐに「アクセスできません」と表示されることがなくなりました。
失敗した、途中で切断された、一時停止中の言語を対象とした、または拒否された文字列の送信が、空の文字列バッチを残さなくなりました。
失敗したタームジョブを再送信するとタームが保持され、再送信に失敗した場合は失敗として報告されます。
文字列の翻訳中に「すべてを翻訳する」をオフにしても、永久に「翻訳が進行中」のままにならなくなりました。
スマートフォン幅の画面で、「すべてを翻訳するをセットアップする」ウィンドウが画面に収まり、閉じることができるようになりました。
最初のサイト全体のパスがまだ実行されている間にキャンセルしたジョブを、「すべてを翻訳する」が再送信して再度課金することがなくなりました。
アカウントの単語数が不足したために一時停止したタクソノミージョブは、単語が追加されると再開します。
翻訳システムが一度も受け入れていないジョブをダッシュボードが保留中としてカウントしなくなったため、幻の翻訳が取得を待つことはありません。
自動翻訳がサポートする言語をWPMLが読み取れない場合に、コスト見積もりや翻訳ダッシュボードの言語リストが間違っていたり空になったりしなくなりました。
「すべてを翻訳する」は、翻訳するもののないコンテンツタイプを承認待ちとしてリストしなくなりました。
WPBakeryのGrid Builderなど、プラグインが管理画面でのみ登録するコンテンツタイプを、コンテンツ制限の調整から含めることができます。

翻訳エディタと翻訳ジョブの修正

複数のブロックを含むコンテンツの既存のクラシック翻訳エディタでの翻訳は、高度な翻訳エディタで開いたときに保持されます。
クラシック翻訳エディタは、video、audio、picture要素を含むHTMLをプレーンテキストフィールドに表示するため、タグが失われることはありません。
翻訳エディタでは、複数のブロック、ショートコード、または属性で繰り返されるテキストは最初の出現箇所の下にリストされるため、ブロックが欠落しているように見えることはありません。
翻訳ジョブを完了しても、そのジョブ自身の翻訳ではない投稿に書き込んだり、移動したりすることはありません。
クラシック翻訳エディタで、セカンダリ言語をソースとするジョブが、代わりにデフォルト言語のページを読み込むことがなくなりました。
元言語ではなく別の翻訳から送信された翻訳ジョブを開くと、その翻訳がソース言語として保持されます。
高度な翻訳エディタでレビューされた文字列パッケージまたは投稿は、レビュアーが「保存して完了」をクリックすると完了して公開されます。
配信された製品翻訳を再度開いても、空のフィールドを持つ新しいジョブが作成されることはなくなり、エディタは翻訳が収集されるまで待機します。
配信されたXLIFFファイルの空のターゲットがジョブを無効にすることはなくなりました。テキストのないユニットはソースを保持し、不正なユニットはスキップされます。
エディタで翻訳を開いても、翻訳システムがまだ翻訳している自動ジョブを引き継ぐことがなくなりました。
予約投稿のレビュー済み翻訳を承認しても、元の投稿より前に公開されることがなくなりました。
翻訳エディタでは、ページビルダーのショートコードテキストに、現在持っている属性のみがラベル付けされます。
翻訳エディタでは、ブロック内のショートコードがページの順序でリストされ、繰り返されるテキストごとに1つのエントリが表示されます。
翻訳エディタでは、ブロック内にショートコードがあるページは、2つのテキストグループを異なる名前で表示します。
同時の保存によってステータス記録が削除された翻訳に対して翻訳ジョブが作成されなくなり、関連するPHPの警告が解消されました。
翻訳ステータス記録の書き込みに失敗しても、別の翻訳のIDを返すことがなくなりました。
ジョブを持たない翻訳を同時に保存した場合、それぞれに1つずつではなく、1つのベースラインジョブが作成されます。
高度な翻訳エディタでレビューされたターム翻訳が、サイトに再度適用されます。
ダウンロードされた翻訳ジョブアーカイブ内のファイルはWindowsが受け入れる名前を持つため、アーカイブはどこでも展開できます。
翻訳された投稿を作成または更新できない場合、ジョブはその理由とともに失敗として報告され、再度適用できます。
クラシック翻訳エディタは、二重引用符で囲まれた属性内の二重引用符で囲まれたショートコードを正しく表示します。
ジョブIDを含むリンクから翻訳を再度開くと、翻訳者の未保存の進行状況が保持されます。
管理者が完了した翻訳を開いた後、翻訳者を削除したりXLIFFファイルをインポートしたりしても、ジョブは正しい状態に保たれます。
翻訳レビューページで、言語スイッチャーのリンクはレビュー中の言語ではなく、それぞれの言語を指します。

翻訳管理と翻訳ダッシュボードの修正

翻訳者言語ペアを持たないユーザーでも、翻訳された投稿の編集リンクがそのまま表示されます。
複製された投稿の鉛筆アイコンは、選択された翻訳エディタがWordPress エディタである場合、再びWordPress エディタを開きます。
翻訳システムがサイトの新しいアドレスを認識していない間、WordPress エディタで翻訳された投稿は再びそこで開き、ブロックされた翻訳はその理由を表示します。
編集者は、翻訳ステータス列から元の投稿を開く際に、「この言語ペアの翻訳は許可されていません」というエラーを出さずに開くことができます。
翻訳が存在する前に、別の言語からページ、カテゴリー、またはタグを再度送信すると、翻訳ジョブに新しいソース言語が表示されます。
自動文字列登録がオフの場合、翻訳ダッシュボードウィンドウに戻っても文字列処理が開始されなくなりました。
エディタで開けない翻訳は、投稿リストと同様に、翻訳タスクリストの上にその理由を説明します。
自動文字列登録ダイアログの「キャンセル」と「保存」によって、翻訳ダッシュボードから空白ページに移動することがなくなりました。
元の言語を変更すると、その翻訳のソース言語も更新されるため、それらのジョブは翻訳ジョブにリストされたままになります。
言語ペアにターゲット言語がない翻訳者に対して、ジョブリストにデータベースエラーが表示されなくなりました。
翻訳更新メールで、文字列パッケージジョブが同じIDの投稿としてカウントされなくなりました。
ある種類のアイテムがすでに翻訳されている場合でも、混在した選択に対して「コンテンツを翻訳」が利用可能なままになります。
ジョブのマネージャーがユーザーではない場合に、ジョブの概要メールにPHPの警告が表示されなくなりました。
前回の送信で「自分で翻訳」が使用された場合でも、翻訳ダッシュボードは「自動的に翻訳」とマークされたカテゴリーを送信します。

ページビルダーの修正

Elementor：翻訳を編集すると、ページの言語ではなく管理画面の言語でエディタが開きます。
Elementor：テーマウィジェットが現在のドキュメントを必要とする場合や、レンダリング中にウィジェットがエラーになった場合に、翻訳の保存が失敗しなくなりました。
Elementor：翻訳されたページ上の各ボタンは、すべて同じページではなく、それぞれのターゲットの翻訳にリンクします。
Elementor Pro：FormウィジェットのMessageフィールドが翻訳に送信されなくなったため、通知メールは送信されたデータを保持します。
Avada：翻訳されたフォームの通知メール内のアクセント記号付き文字が、エスケープコードとして保存されなくなりました。
WPBakery：カスタムリンクを持つSingle Imageは、翻訳でもその画像とリンクを保持します。
添付ファイルIDのリストではないページビルダーの値が、翻訳時にゼロに書き換えられなくなりました。
Flatsomeおよびその他のショートコードビルダー：同じ名前の2つのショートコード間のテキストが翻訳対象として提供され、翻訳されます。
Beaver Builder：翻訳されたページでは、Patternモジュールとパターンパネルにその言語のパターンのみがリストされます。
Divi 5：元のページのLoopモジュールは翻訳でも保持され、翻訳された投稿をリストします。
Divi：Diviが未使用とマークしたテーマビルダーレイアウトは、翻訳ダッシュボードで提供されたり、「すべてを翻訳する」によって送信されたりしなくなりました。
複数の言語設定ファイルで宣言されたショートコードまたはブロックは、それらすべての属性と設定を保持します。
検索と置換の後、ショートコードベースのビルダーが同じテキストを2回提供しなくなり、ページに存在しなくなったテキストは削除されます。
コンテンツにブロックコメントを含むショートコードで構築されたページに、クラシック翻訳エディタの翻訳が適用されます。
ショートコードID属性の設定が、同じ名前で終わる他の属性も変換することがなくなりました。
ショートコード属性を翻訳しても、同じテキストを持つ別の属性が変更されなくなりました。

ブロックとブロックエディタの修正

文字列翻訳がなくても、翻訳されたページはパターンから挿入されたブロックの設定を保持し、再度翻訳することで以前のページが修復されます。
ブロックウィジェットのテキストを編集すると、置き換えたテキストの翻訳が保持されます。
HTMLタグ、配置、アニメーションタイプなど、コードであるブロック設定は、すべての言語でその値を保持します。
Galleryの画像IDなど、IDのリストを保持するブロック属性は、翻訳されたアイテムを表示します。
カスタムHTMLブロック：SVG画像を保持するCSSがカットされなくなり、エスケープされたマークアップ、アンパサンド、およびノーブレークスペースが記述通りに保持されます。
翻訳されたページで、段落、見出し、またはリスト内のテキストとして記述されたHTMLタグを示すテキストが、実際のマークアップに変換されなくなりました。
翻訳されたブロックは独自の参照を保持します。リンクのコピーは翻訳されたアンカーに従い、画像ブロックは翻訳された添付ファイルを指定します。
Beaver Builder：保存された行、列、モジュール、またはテンプレートを表示するタブやアコーディオンアイテムは、その翻訳を表示します。
GenerateBlocksのボタンなど、マークアップと属性の両方にリンクを保存するブロックが、エディタで破損していると報告されなくなりました。
プラグインやテーマ独自の言語設定が有効化されるとすぐに適用されるようになり、Kadence Blocksなどのブロックをすぐに翻訳できるようになりました。
ブロックエディタの保存には管理画面の言語ではなく投稿の言語が使用されるため、Senseiコースはそのモジュールを保持します。

言語スイッチャーの修正

言語スイッチャーのAJAXナビゲーションは安全にHTMLページの応答のみを読み取るため、他の応答がリソースを読み込んだりコードを実行したりすることはありません。
フッター言語スイッチャーの設定ウィンドウが空白で開くことがなくなり、到着しなかった設定が保存されたと報告されなくなりました。
言語スイッチャーのデータが、リストやループ内の現在の投稿をリセットしなくなりました。
言語ごとに異なるドメインを使用し、リクエストからWP_HOMEが構築される場合、デフォルト言語のスイッチャーリンクは独自のドメインを使用します。
言語スイッチャーブロックは、unfiltered_html権限を持たないユーザーでも機能します。正常に保存され、矢印、スタイル、画像サイズが保持されます。
保存されたマークアップに現在の言語が欠落している言語スイッチャーブロックが、致命的なエラーを引き起こさなくなり、他の言語をリストするようになりました。
ブロックエディタで、言語スイッチャーのドロップダウントグルがスクリーンリーダーを言語リストに誘導します。
1つのページにある2つの言語スイッチャーブロックが、ブロックエディタでサブメニューIDを共有しなくなりました。
カスタム言語スイッチャーの設定に独自のスタイルルールが表示され、スイッチャーを空のまま、またはすべての表示オプションをオフにして保存できなくなりました。
言語スイッチャーのオプションが、すべてのページでレンダリングされるようなテンプレートコードを受け入れなくなりました。
言語スイッチャーブロックは、新しいlibxmlバージョンを使用するホストで、アクセント記号付きおよび非ラテン語の言語名を正しくレンダリングします。
管理画面の言語が英語ではない管理者の場合でも、言語スイッチャーブロックが無効なコンテンツを報告しなくなりました。

カテゴリー、タグ、その他のタクソノミーの修正

説明などのテキストの1つがない状態で配信されたターム翻訳は、完了するのではなく、不足している部分のために開いたままになります。
2つの言語でスラッグが同じタクソノミーアーカイブは、リクエストされた言語のタームを表示し、そのタームは再度保存されます。
タクソノミーのデフォルトタームが言語の切り替えごとに書き換えられなくなり、新しい投稿にはそれぞれの言語のデフォルトタームが割り当てられます。
セカンダリ言語のページにタームが存在するかどうかを確認するプラグインは、その翻訳ではなくそのタームを返します。
カスタムタクソノミーのデフォルトタームを別の言語の管理画面から削除できなくなりました（これにより、WordPressが間違った言語で再作成する問題が解決しました）。
デフォルトのカテゴリーまたはタームがコードやデータベースで削除された場合、WPMLはそれをデフォルト言語で翻訳とともに再作成します。
タクソノミーの翻訳モードを変更すると、すべての投稿がそれぞれの言語のタームに移動します。
別の言語のページからコードによってカテゴリーやタームを削除すると、他のデフォルトを削除することなく、その投稿がそれぞれの言語のデフォルトに分類されます。
別の言語の管理画面から追加された言語は、英語の「Uncategorized」など、独自のデフォルトカテゴリー名を取得します。
WPMLのタームAPIを通じて作成されたターム翻訳は、呼び出し元が指定したソース言語を保持します。
元のタームのIDを指定してAPI経由でターム翻訳を作成することが機能し、元の翻訳グループに参加します。
翻訳されたカテゴリーやタグを再送信する際、元の言語や別の言語がそれを共有している場合に、スラッグの名前が変更されなくなりました。
タクソノミー翻訳画面にアクセスした後、管理画面の言語が以前に閲覧していた言語に戻らなくなりました。
タームIDとタームタクソノミーIDが異なるサイトで、hreflangリンクやカテゴリー数に無関係なタームが含まれなくなりました。
カスタムタクソノミーの英語のデフォルトタームがなくなり、その翻訳が名前を共有している場合、各言語は独自のデフォルトタームを保持します。
遅れて配信された自動翻訳が、手動のターム翻訳を上書きしたり、その更新状態をクリアしたりしなくなりました。

メニューの修正

Redisなどの永続的オブジェクトキャッシュを使用しているサイトで、翻訳されたメニューやタームの翻訳がデフォルト言語のものに置き換えられなくなりました。
メニューで、「Translation of」のプレースホルダーがスペイン語ではなく管理画面の言語で表示されます。
REST、カスタマイザー、またはコードを通じて、「外観」→「メニュー」の外部でメニューを保存しても、翻訳とのリンクが保持されます。
1つのリクエストでコードによって追加されたメニュー項目は、その位置を保持します。
WPメニュー同期は、元の翻訳グループ内に翻訳されたメニューを作成します。
Portoテーマのように、wpml-configファイルがメニュー項目フィールドをコピーするように設定している場合でも、WPメニュー同期が翻訳されたメニューを平坦化しなくなりました。
元のメニューから項目を削除すると、その翻訳されたコピーも削除されます。
同じWPメニュー同期の変更を2回適用しても、2つ目の翻訳されたメニューが作成されなくなりました。
WPメニュー同期が翻訳されたメニューに下書きの翻訳を追加しなくなったため、訪問者に404リンクが表示されることはありません。
元のメニューから親項目を削除しても、翻訳された子項目が削除された項目を指したままにならなくなりました。
デフォルト以外の管理画面の言語でカスタマイザーからメニューの変更を公開しても、その言語の翻訳されたメニューの名前が変更されなくなりました。

リンク、URL、リダイレクトの修正

投稿を一度に複数の言語に翻訳または複製する際に、翻訳されたスラッグを持つカスタム投稿タイプへのリンクが間違った言語で保存されなくなりました。
「ルートページを作成」で作成されたページは、ブロックエディタおよびクラシックエディタで、最初の保存からサイトのルートページになります。
同じスラッグを持つ下書きまたは保留中のページが、別の言語の公開済みページを404に送信しなくなりました。
言語ごとに異なるドメインを使用する場合、非表示フィールドの確認に失敗するのではなく、WPML → 設定 → URLが再び保存されるようになりました。
クローラーによって頻繁にリクエストされる、存在しないカテゴリーで終わるカテゴリーアドレスが、データベースエラーを書き込まなくなりました。
アーカイブやその他のページ以外のアドレスへのリンクが、翻訳時にElementorテンプレートに書き換えられなくなりました。
スラッグが翻訳されている投稿へのリンクは、投稿の元の言語に関係なく、デフォルト言語で正しく変換されます。
非表示の言語のドメインにあるログインページが、デフォルト言語にリダイレクトされなくなりました。
非表示の言語と翻訳されたログインページがある場合、非表示の言語のログインアドレスが常に機能します。
ページの読み込み中にWPMLが欠落しているURLフォーマット設定を復元した場合、そのページの言語リンクは?lang=パラメータではなく保存されたフォーマットを使用します。
保存された言語URL形式を失ったサイトは、引き続き言語ディレクトリを提供し、設定を再度保存します。
スティッキーリンクが保存するように、翻訳されたページへのプレーンリンクを保持する翻訳されたリンクフィールドは、そのページを翻訳の言語で開きます。
?cat=およびlang=アドレスで開かれたカテゴリーアーカイブは、その言語のホームページにリダイレクトするのではなく、アーカイブを表示します。
変換されたページリンク（ACFのLinkフィールドとURLフィールドを含む）は、#anchor、クエリ文字列、およびサブパスを保持します。
ページ分割されたアドレスによって、リンクが間違った投稿を指すことがなくなりました。
古いルートページが完全に削除された後、新しいルートページに言語が割り当てられます。
タームのリンクはタームが保存されるとすぐに更新されるため、SEOプラグインはリダイレクトを作成できます。
変換されたアンカーリンクの#anchorの後に末尾のスラッシュが追加されなくなりました。
翻訳が公開された後、リンクがしばらくの間元の言語のままになることがなくなりました。
言語ごとに異なるドメインを使用するサイトで、未翻訳の投稿へのリンクが404に繋がらなくなりました。

言語とセットアップウィザードの修正

デフォルト言語のみが残っている場合、セットアップウィザードは管理画面をロックするのではなく、言語のステップから再開します。
保存されたデフォルト言語がアクティブでなかった場合でも、セットアップウィザードの言語ステップに空のデフォルト言語が表示されなくなりました。
セットアップウィザードで、サイトが以前に使用していた言語の国別バリアントを追加する際、コンテンツを保持するか新しく開始するかを尋ねられます。
WPMLのカタログにない言語を、独自のコードとロケールを持つカスタム言語として追加できます。
以前のバージョンで空のままになっていた場合、言語カタログの同期によってプリセットの言語が入力されます。
WPMLの言語カタログで修正されたテキストの方向は、言語設定を変更することなく、その言語を使用しているサイトに反映されます。
「0」という言語コードがデフォルト言語へのリンクを送信しなくなりました。影響を受けたサイトは修復され、失敗したコード変更が報告されます。
WPML 5.0以前に、WPMLが現在使用しているコード（de-atなど）で作成されたカスタム言語は、コンテンツを保持したままその組み込み言語になります。
引き継ぐことができないカスタム言語は「マッピングが必要」とマークされ、マッピングされるまで自動翻訳に送信されません。
サイトに中国語（香港）が追加されると、言語検索でカスタム言語として追加するオプションが提供されなくなりました。
PHPの制限時間が短いホストでも言語パックのダウンロードが完了し、最後のパックで停止するのではなく再開します。
言語のデフォルトをリセットする際に、PHP 8.1の非推奨通知が表示されなくなりました。

登録とアップデートの修正

バージョン5.1からアップロードによってWPMLをアップデートする際に、1回限りの致命的なエラーが表示されなくなりました。
アップデート直後にInfiniteWPなどの管理プラグインが投稿を追加した場合でも、WPMLのアップデートによって致命的なエラーのメールが送信されなくなりました。
サブスクリプションタイプがどの製品とも一致しないアカウントでも、致命的なエラーで停止するのではなく、「有効化と更新」が開きます。
「有効化と更新」はすべてのアカウント状態で登録ボックスを表示し、「登録解除」とサイトキーフィールドがあるため、古い登録を置き換えることができます。
WPMLプラグインのプラグイン詳細で、WordPressのポイントリリース時に未テストのWordPressバージョンに関する警告が表示されなくなりました。
登録済みのサイトで、永続的オブジェクトキャッシュを使用している場合に「新しいサイトキーが必要です」と表示されたり、wpml.orgにアクセスできないときにキーが失われたりしなくなりました。
サイトが新しいアドレスに移動し、その翻訳アカウントを保持している場合、WPMLはそれをコピーと呼ぶのではなく、サイトが移動したと表示します。
マルチサイト：「このサイトのキーを取得する」はネットワークのアドレスを指定するため、リンク先のキーが受け入れられます。
移動していないサイトが翻訳システムに再登録した後、サイトコピーの通知が表示されなくなりました。
WPML製品フィードにアクセスできない場合、「有効化と更新」は最後に確認された製品を保持し、何が失敗したかを表示して「再確認」オプションを提供します。
WPMLのアップデートが保留中の間、WP-CLIは警告なしにプラグインをリストします。
プロダクションチャネルに戻した後、「有効化と更新」はプロダクションバージョンをインストールし、インストールするものがないダウンロードの場合はその旨を表示します。
「有効化と更新」の各プラグインのリリースノートには、そのプラグイン自身のノートのみが表示されます。
アップデート後、ブラウザとCDNはキャッシュされた古いものではなく、WPMLの現在のスクリプトとスタイルを読み込みます。
Advanced Custom Fields Multilingualおよびその他のコンパニオンプラグインは、そのバージョンがWPMLが要求するリリースのベータ版である場合に読み込まれます。
複数のアップデート通知が同時に到着した場合でも、サイトが1秒間に何度もキーを再検証することがなくなりました。
wpml.orgが制限（スロットリング）またはタイムアウトした場合でも、wp-config.phpで定義されたサイトキーはその登録を保持します。
プラグインのダウンロードハンドラーは、サイトキーを検証する前にリクエストのセキュリティトークンを確認します。
マルチサイト：異なる事前定義されたサイトキーを持つ1つのネットワーク内の2つのサイトが、交互に再登録を繰り返すことがなくなりました。
セットアップウィザードが読み込まれるたびに、wp-config.phpで定義されたサイトキーを再登録しなくなりました。
サブスクリプションの更新ルートは、サブスクリプションがすでに最新であるサイトに対して成功を返すため、プロキシやモニターが誤った拒否をログに記録しなくなります。
wp-config.php内のサイトキーは、末尾のスペースや改行を含めてコピーされた場合でも正しく保存されます。
Blogライセンスを持つサイトで、欠落している定数に関する致命的なエラーが発生しなくなりました。

WooCommerceサイトの修正

WooCommerce Multilingualを使用しているサイトで、WPMLが勝手にセットアップウィザードに戻り、すべての言語の投稿を表示することがなくなりました。
WooCommerce Multilingualのセットアップウィザードで、WPMLの管理スクリプト、CMS Nav、スティッキーリンクが「addLoadEvent is not defined」で失敗しなくなりました。
製品からカテゴリーを削除すると、すべての言語で翻訳されたカテゴリーの製品数が更新されます。
クラシック翻訳エディタで翻訳された製品は、高度な翻訳エディタで開いたときにバリエーション、属性、カスタムフィールドの翻訳を保持します。
親製品が両方の言語のタームを持っている場合、翻訳されたバリエーション製品のインポートが重複する属性行で失敗しなくなりました。
コンテンツタイプが遅れて登録された場合でも、WooCommerce Multilingualが翻訳されたアカウントとチェックアウトのアドレスを2回再構築しなくなりました。

カスタムフィールドとAdvanced Custom Fieldsの修正

プラグインやインポートによって名前のないカスタムフィールド行が残された場合でも、カスタムフィールド翻訳とカスタムタームメタ翻訳の設定画面が再び開くようになりました。
5.1.0のアップデート後に確認なしでキューに入れられたバックグラウンドタスクは廃止されました。代わりに、新しく翻訳可能になったカスタムフィールドはあなたの決定を待ちます。
カスタムタームメタ翻訳の設定では、翻訳されたフィールドは投稿ではなくタームとともに翻訳されると説明されています。
タクソノミーターム上のネストされたACFフィールド（Flexible Content、Repeater、Group）は、自動的におよびエディタ内で翻訳されます。
「コピー」に設定されたRepeaterおよびFlexible Contentのサブフィールドは、update_field()やフロントエンドのACFフォームなど、投稿エディタの外部で行が追加された場合でも翻訳に反映されるようになりました。
新しく翻訳可能になったカスタムフィールドは、実際にそのフィールドを持つ翻訳された投稿のみを「更新が必要」としてマークします。
ACFフィールドの翻訳設定を変更すると、既存のターム翻訳も更新されます。
ACFフィールドグループのラベルは、Advanced Custom Fields Multilingual 2.2への移行後もその翻訳を保持します。
WPML 4.xからのアップグレードで、不要なデータの読み込みを維持していたAdvanced Custom Fields Multilingualのクリーンアップ後に、古いカスタムフィールド設定が復元されなくなりました。
カスタムフィールド翻訳において、検索結果の読み込み中に選択された設定が、「データが保存されました」の後に失われることなく保持されます。
外部クライアントからREST APIを通じて翻訳を保存する際に、毎回完全なカスタムフィールドの同期が実行されなくなりました。
WPMLが投稿のフィールドをコピーした後に書き込まれたカスタムフィールドも、引き続きその翻訳に反映されます。
タクソノミーの翻訳画面でACFのLinkフィールドの単語を変更しても、翻訳されたリンクが保持されます。
WPML 設定でACFフィールドを「コピー」、「一度だけコピー」、または「翻訳不可」に変更すると、既存の翻訳が更新されます。

メディアと画像の修正

メディア翻訳：オブジェクトキャッシュホスティングで翻訳が保存された後、翻訳されたブロックエディタのページが独自の画像を保持します。
メディアを含む翻訳ジョブを完了しても、すべてのセカンダリ言語に孤立した添付ファイルのコピーが作成されなくなりました。
セカンダリ言語での添付ファイルのクエリは、その翻訳または添付ファイル自体を返すようになり、EnfoldのColor Sectionの背景が修正されました。
ページビルダーがURLで指定する画像に、そのページの言語のメディアテキストが表示されます。
Diviのセクション背景などのページビルダーの画像は、翻訳エディタで正しい元のテキストを表示し、正しい画像に保存されます。
ウィジェットやコンテンツ内に使用可能なアドレスがない画像があっても、ページの読み込みごとにオブジェクトキャッシュエラーが発生しなくなりました。

投稿とページの修正

wpml-config.xmlファイルがタイプを翻訳可能にした後、カスタム投稿タイプの投稿が管理リストから消えることがなくなりました。影響を受けたサイトはアップデート時に修復されます。
スケジュールされたタスクやフロントエンドのフォームから翻訳された投稿を削除、ゴミ箱へ移動、または復元する操作は、管理画面と同様にその翻訳にも適用されます。
データベースの行が消失した投稿を保存しても、致命的なエラーで停止しなくなりました。
投稿をゴミ箱から復元すると翻訳のステータスが保持されます。下書きや非公開の翻訳が公開済みとして戻ることはなくなりました。
公開日が翻訳にコピーされる設定の場合、予約投稿がその日時にゴミ箱内の翻訳や未完成の翻訳を公開することがなくなりました。
フロントエンドリクエストが、現在の言語を解決する際に無限再帰でクラッシュしなくなりました。
無効になっている言語の投稿を更新してもその言語が保持され、投稿を保存しても別の翻訳が切断されなくなりました。
どの投稿にも一致しない投稿IDを確認しても、PHPの警告が発生しなくなりました。

他のプラグインやテーマとの互換性の修正

Slider RevolutionやAvadaのオプションなど、他のプラグインの管理画面がWPMLを有効にした状態で再びスクリプトを読み込むようになりました。
Tatsuビルダーなどの別のプラグインがプラグインの読み込み中に投稿を検索した場合でも、すべてのページで致命的なエラーが発生しなくなりました。
WordPressの読み込み中に別のプラグインが失敗した場合、サイトは空白のページではなく、WordPressの致命的なエラーのページを再び表示します。
WP All Export Proなどの別のプラグインがサイトの言語を切り替えて元に戻さない場合、WPMLがサイトの言語を復元します。
WPMLはページ設定を1回だけ読み取るため、オブジェクトキャッシュをフラッシュするキャッシュプラグインが「Commands out of sync」データベースエラーを引き起こさなくなりました。
WPML SEOがアクティブでない場合、Yoast SEOのサイトマップは各翻訳された投稿をそれぞれのURLでリストします。
WPML SEOは、すべてのRank Mathスキーマタイプのテキスト値を翻訳します。
The Events Calendar：「Integrate events in main blog loop」が有効な場合にルートページが空白で表示されなくなりました。

管理画面と設定の修正

クリーンアッププラグインや部分的な復元によって保存されたWPML設定が削除されたサイトは、WPMLの保存されたコピーからそれを取り戻します。
WPMLがデータベースのアップデートを完了している間に保存された設定が失われなくなりました。
トラブルシューティング：単一のURLのキャッシュの再構築がバックグラウンドで確実に実行され、「再構築」のクリックが失われなくなりました。
「自動翻訳の料金がアップグレードされました」の通知は、翻訳を管理できるユーザーにのみ表示されます。
設定の検索：「テーマとプラグインのローカライズ」のエントリは、互換性の下にあるローカライズオプションにスクロールします。
古い「テーマとプラグインのローカライズ」のアドレスは、テーマとプラグインのスキャンが表示された状態の「設定」→「互換性」に繋がります。
WPML をリセットの実行中のリクエストが、WPMLのテーブルと設定を再作成できなくなりました。
ネットワーク管理からの「WPML をリセット」も、最初にセカンダリ言語を確認します。
翻訳優先度を削除しても、アップグレード中のサイトに誤った「アイテムが削除されました」の記録が書き込まれなくなりました。
WPMLの管理画面の正常性チェックが失敗したときに表示される通知には、失敗したリクエストの名前が記載されます。
「サポート」→「通信ログ」は、サービスを更新した後も読み取り可能なままになります。
翻訳エンジンの変更は、サイトのwpml.orgへの毎日のチェックインで報告されます。
WPMLの言語設定にある「デフォルトと同じ」のツールチップが翻訳できるようになりました。
管理画面のRESTリクエストで、ロケールの切り替えが期待通りに翻訳に適用されます。

データベースとマルチサイトの修正

Percona XtraDBの厳格モードなど、名前付きロックを拒否するデータベースクラスターでは、WPMLはテーブルベースのロックに切り替えて機能し続けます。
WPMLは、MariaDB 11で一致する文字セットと照合順序を使用してテーブルを作成します。
WPMLはすべてのテーブルを1つの文字セットと照合順序で作成し、データベースが作成を拒否したテーブルがある場合は通知にその名前が記載されます。
名前付きロックを拒否するデータベースでは、インストーラーのログがデータベースエラーなしで書き込まれます。
マルチサイト：WPMLが非アクティブ、またはアクティブだがセットアップされていないネットワークサイトで、言語テーブルの欠落に関するエラーがログに記録されなくなりました。

その他の修正

文字列翻訳が、ロケールを共有している非アクティブな言語からある言語の翻訳ファイルを書き込み、文字列が未翻訳のままになることがなくなりました。
文字列翻訳：WooCommerceブロックなど、ブロックのデフォルトテキストから来た削除された文字列が戻ってこなくなりました。
翻訳に内部リンクが含まれる.poファイルをインポートしても、サーバーエラーで失敗しなくなりました。
WordPressがサーバーのファイルシステムルートにインストールされている場合でも、文字列翻訳はテーマとプラグインの翻訳ファイルを登録およびインポートします。

このバージョンの詳細については、WPML 5.2のリリース発表をお読みください。

更新またはダウンロード

このアップデートは有効なサブスクリプションを持つすべてのWPMLクライアントに提供されます。リリースから24時間以内にWordPress管理画面のプラグインページに表示されます。また、プラグイン → 新規追加 → 商用からすぐに確認することもできます。手動でダウンロードしてインストールするには、wpml.orgアカウントのダウンロードにアクセスし（インストール手順を参照）、バージョンを混在させずにすべてのコンポーネントを一緒に更新してください。

サポートが必要な場合やフィードバックを提供したい場合は、テクニカルサポートフォーラム（新しいタブで開く）をご利用ください。

すべてのWPML Multilingual CMSバージョンを表示