WPMLへのページビルダー翻訳サポートの追加

2日前に、ページビルダーでデザインされたサイトをどのように翻訳したいかについてアンケートを実施しました。この記事では、その結果と、それが今後のWPML 3.6の開発にどのような影響を与えるかについて共有したいと思います。

背景 – 現在推奨しているページビルダーを使用したサイトの翻訳方法

Toolset Layoutsを除くすべてのページビルダーにおいて、現在翻訳を行う唯一の方法は言語ごとに個別のデザインを作成することです。

この方法は使えますが、あまり便利ではありません。言語ごとにデザインするのではなく、デザインを1度だけ行い、テキストのみをWPMLで翻訳する方が簡単だと私たちは考えています。ちなみに、現在レイアウトを含むToolsetのすべてを翻訳する方法に関するドキュメントを作成中です。準備ができ次第、それについて記事を書く予定です。

Q: ページビルダーで作成したコンテンツの現在の翻訳方法に満足していますか？

言語ごとに個別にデザインすることを好む人も実際にいます。これは、デザイン全体を微調整する必要がある場合には理にかなっています。サイトのホームページに非常に精密なデザインがある場合、言語ごとに微調整して最適化することは意味があると思います。

ほとんどの人は現状の方法で問題ないとしていますが、1つのデザインを作成してWPMLで翻訳することを好んでいます。また、このアプローチは自分たちには使えないという意見もあります。おそらく、これらは翻訳サービスを利用している人々だと考えられます。外部の翻訳者にページビルダーのデザインを触ってもらうことは、ほぼ不可能であることに私も同意します。WPMLを多くの翻訳サービスと統合する際にも、こうした問題に直面しました。

Q: どのページビルダーをよく使用していますか？

ページビルダーを使用しているサイトの約60%がVisual Composerを使用しています。次に非常に人気があるビルダーはDiviとAvadaです。その他のビルダーもかなり人気があります。

翻訳プロセスはどのようになるか

すでにLayoutsプラグインと完全に統合されて機能しているため（ドキュメントはまだ「作成中」ですが）、Layoutsを例として説明します。

ステップ1）ページビルダーでのデザイン

前述のとおり、ページビルダーでのデザインは1回だけで済みます。すべての翻訳に同じデザインが使用されます。

ステップ2）翻訳への送信

ページがページビルダーを使用している場合、それを「2回」翻訳する必要があります。1回目はページ自体で、これにはページタイトルと使用しているカスタムフィールドが含まれます。2回目はページビルダーのデザインです。これが少し面倒であることは承知しています。これを自動化するよう取り組む予定ですが、おそらく最初のリリースでは実現しないでしょう。

WPML->翻訳管理に移動します。そこに、ページビルダーデザイン用の新しいコンテンツタイプが表示されます。翻訳したいデザインを選択し、翻訳に送信します。サイトのさまざまな要素を確認し、翻訳バスケットに追加できます。翻訳の選択が完了したら、WPML->翻訳管理->翻訳バスケットに移動し、すべてを一度にまとめて送信します。ローカル（WPMLの翻訳エディタを使用）で翻訳するか、外部のお好みの翻訳サービスに送信して翻訳できます。

ステップ3）翻訳

デザインに属するすべてのテキストが並んで表示されます。構造ではなく、テキストのみを翻訳します。翻訳を行い、各フィールドを「完了」としてマークします。保存すると、翻訳は自動的にページビルダーのデザインに適用されます。

ステップ4）フロントエンドでの結果の確認

コンテンツを表示すると、翻訳がフロントエンドに表示されます。翻訳はページビルダー自体を変更しないため、ページビルダー内には翻訳は表示されません。

ステップ5）デザイン更新時の翻訳の更新

ページビルダーでデザインを編集した場合は、翻訳ダッシュボードに移動して翻訳に再送信します。変更されたテキストのみが翻訳対象として表示されます。

WPMLでのページビルダー翻訳統合のロードマップ

手始めにVisual Composerとの統合を開始していますが、残念ながらこれは統合が最も困難なビルダーです。VCはデザインを「コンテンツ」内のショートコードとして保存します。ショートコードにはIDがないため、要素とそのテキストを関連付けることが困難です。私たちはVCの開発者と協力して、セルにIDを追加できるよう努める予定です。いずれにせよ、コンテンツに基づいて文字列を識別するフォールバックメソッドを使用します。これはつまり、テキストが変更された場合、セルを編集する前にそのテキストが何であったかを知る方法がないため、最初から翻訳し直す必要があることを意味します。VCのセルにIDを追加できるよう最善を尽くします。ただし、これが完全に私たちの権限内で解決できる問題ではないことをご理解いただければ幸いです。

他のページビルダーの仕組みは異なります。ビルダーのデザインは「コンテンツ」とは別に保存され、セルには一意の識別子があります。そのため、セルを編集する際には以前の翻訳が表示され、それを更新するだけで済みます。

WPML 3.6には間違いなくVisual Composerのサポートが含まれます。Diviのサポートも含めるよう努めます。このリリースサイクルの一環として、ページビルダーで翻訳用の文字列を登録する方法に関する詳細なドキュメントも作成します。これは非常に簡単で、適切に文書化するだけで済みます。

その後、他のすべてのページビルダーの開発者と協力し、彼らの製品に同様のサポートを統合していく予定です。

フィードバック

いかがでしょうか？他のページビルダーに先に取り組んでほしいと考える方もいらっしゃるでしょう。優先順位をつける必要があるため、最も多くの人に使用されているものから始めています。最終的にはすべてのページビルダーに対応する予定であり、なるべく早く実現したいと考えています。翻訳プロセスや全体的な計画について、皆様からのフィードバックをお待ちしています。アイデア、ご質問、ご提案がありましたら、コメントを残してください。後ほど返信いたします。