当サイトを最適な状態で閲覧していただくにはブラウザのJavaScriptを有効にしてご利用下さい。
JavaScriptを無効のままご覧いただいた場合には一部機能がご利用頂けない場合や正しい情報を取得できない場合がございます。
承知しました
本サイトではWebサイトのエクスペリエンスを向上させるために、Cookieを使用しています。Cookieはブラウザの設定から無効にできます。本サイトで使用するCookieについては、プライバシーポリシーをご確認ください。

Blog

ブログ

統合

自動翻訳をワークフローに統合する

By Christopher Jennings  

会社の規模に関係なく、母国語で聴衆にリーチすることは、彼らがあなたの言うことを本当に聞いているかどうかを決定する要因になる可能性があります。

翻訳は複雑で時間がかかります。それを処理する方法はたくさんあり、訓練を受けた翻訳者と協力して最良の結果を得ることができますが、完璧な翻訳が本当に必要でない場合や、ニーズに対して費用効果が高い場合はどうでしょうか。機械翻訳はこれに役立ちます。

機械翻訳の真の力は、その速度とコストにあります。常に100%正確であるとは限りませんが、すぐに入手できます。それはとても速くできるので、これはいくつかの興味深い可能性への扉を開きます。翻訳者が参加しているチームの場合、機械翻訳を使用すると、ほとんど正確な出発点を得ることができます。白紙の状態では機能しないため、より効率的になります。機械翻訳が必要なものに十分対応できる状況では、非常に費用対効果が高くなります。

Kontentでの翻訳の自動化

Kontentで機械翻訳のメリットを享受し、コンテンツ編集者にとってシームレスにすることができます。彼らの観点から、彼らがしなければならないのは、コンテンツを作成し、翻訳したい言語を選択し、コンテンツアイテムを「翻訳保留中」のワークフローステップに移動することだけです。そこから、アイテムが自動的に「翻訳レビュー」ステップに移動し、翻訳されたコンテンツを編集または公開できるようになるまで待機します。 Content Management API v2 、ワークフローイベントによってトリガーされるいくつかのWebhook、 カスタム要素、およびAzure Translator Text APIを使用して、このデモを作成しました。

高レベルでの動作は次のとおりです。

Kentico Kontent

自分で試してみる

変換コネクタのソースコードは、GitHubの2つのリポジトリで利用できます。1つはカスタム要素用で、もう1つはWebhookを処理するAzure関数用です。これらのプロジェクトのREADMEファイルには、セットアップと開発に関する詳細情報がありますが、構成の主な手順を見ていきましょう。

同僚のRyanOvertonがまとめたこのビデオでは、この投稿の残りの部分で取り上げている内容の概要を説明しています。

ステップ1:言語を構成する

最初に行うことは、プロジェクトに1つ以上の言語を追加したことを確認することです。 Codenameを設定するときは、MicrosoftのTranslatorAPIでサポートされている言語コードを使用する必要があります。

スペイン語がどのように構成されるかの例。
スペイン語がどのように構成されるかの例。

ステップ2:カスタム要素を追加する

カスタム要素は、翻訳する必要のあるすべてのコンテンツタイプに存在する必要があります。これを行う最も簡単な方法は、最初にコンテンツスニペットを作成することです。スニペットに必要な要素は、カスタム要素の1つだけです。

  1. Kentico Kontentで、アプリメニューから[コンテンツモデル]を選択します。
  2. [コンテンツタイプスニペット]タブに移動します。
  3. [新規作成]ボタンをクリックします。
  4. スニペットの名前を入力します(例:「翻訳」)
  5. カスタム要素を追加します。
    • タイトル–翻訳設定
    • ホストされているコードのURL–以下を参照してください
    • パラメータ-以下を参照してください
カスタム要素構成の例
カスタム要素構成の例

ホストされているコードのURL

本番ユースケースの場合、 リポジトリをフォークしてカスタム要素を自分でデプロイする必要があります。簡単なテストを行いたいだけの場合は、 https://kontent-translation-connector-custom-element.netlify.com/を使用できます。これは、リポジトリのマスターブランチのデプロイ済みバージョンです。

パラメーター

コンポーネントに必要なJSONパラメーターについては、リポジトリのreadmeのカスタム要素セクションの構成で詳しく説明しています。完全なJSONは次のようになります。

 { 'debug': false, 'cmApiKey': '', 'pendingWorkflowStepId': ''}

最後に、コンテンツタイプスニペットをコンテンツタイプに追加します。

ステップ3:ワークフローステップの構成

プロジェクトに2つのワークフローステップを追加する必要があります。フローのどこにでも追加できます。翻訳保留ステップは、翻訳プロセスを開始するために使用されます。翻訳レビューワークフローステップは、次の言語をトリガーするか、翻訳プロセスを終了し、言語バリアントがレビューの準備ができていることを示すために使用されます。

翻訳が保留され、レビュー手順が追加されたワークフローの例。
翻訳が保留され、レビュー手順が追加されたワークフローの例。

手順4:Azure Translator TextAPIキーを取得する

次のステップでは、Translator TextAPIの認証キーが必要になります。これは次の方法で入手できます。

  1. Azureポータルにログインする
  2. 新しい「翻訳者テキスト」リソースの作成
  3. 新しいリソースを開く
  4. 「キー」に移動し、キーの1つをコピーします

問題が発生した場合に備えて、Microsoftは、Azure Translator TextAPIにサインアップして認証キーを取得するための詳細なハウツーガイドを提供しています。

ステップ5:Webhookハンドラープロジェクトをデプロイする

ワークフローステップの変更に対応できるようにするには、変換コネクタのAzure関数プロジェクトをデプロイする必要があります。このプロジェクトには、2つのサーバーレス機能が含まれています。サーバーレス機能は、プロジェクト全体および関連するホスティングインフラストラクチャを管理する必要なしに、個々の機能をホストおよび実行するための効果的で安価な方法です。私たちのプロジェクトの2つの機能は、翻訳を実行してコンテンツを更新するために、アイテムが監視しているワークフローステップに変更されたという通知をKontentから受信するように設計されています。言い換えれば、これらの機能は私たちの重労働を行います。

このプロジェクトは、他のAzure関数プロジェクトと同じようにデプロイされます。 デプロイを自動化することも、VSCode用のAzureFunctions拡張機能を使用して手動でデプロイすることもできます。リポジトリ内のlocal.settings.template.jsonファイルの名前をlocal.settings.jsonに変更し、プロジェクトの値を反映するように編集する必要があります。期待値の詳細は、リポジトリのreadmeの「 環境変数」セクションにあります。

手順6:Webhookを構成する

Webhookハンドラーが配置されたので、2つのWebhookを構成する必要があります。これらは、アイテムがワークフローステップを変更したときに通知するURLをKontentに通知します。 Kontentがリクエストを送信できるようにするには、デプロイされたAzure関数のURLにパブリックにアクセスできる必要があります。

翻訳保留中のwebhook

最初のWebhookは、実際の翻訳をトリガーするためのものです。このWebhookのURL addressは、このプロジェクトのTranslationPendingHandler URLは次のようになります: https:///api/TranslationPendingHandler

Workflow steps of content items to watchのみを構成して、変換コネクタをトリガーするように設計された専用のワークフローステップへのトリガーを監視する必要があります。名前としてTranslation pendingをお勧めします。トリガーは基本的に次のようになります。

変換保留中のWebhookのWebhookトリガー構成
変換保留中のWebhookのWebhookトリガー構成

翻訳完全なwebhook

2番目のWebhookは、翻訳が終了したことを通知し、次の翻訳を開始するためのものです。このWebhookのURL addressは、このプロジェクトのTranslationReviewHandler URLは次のようになります: https:///api/TranslationReviewHandler

Workflow steps of content items to watchのみを構成して、翻訳が完了し、レビューの準備ができていることを示すように設計された専用のワークフローステップへのトリガーを監視する必要があります。名前としてTranslation reviewをお勧めします。トリガーは基本的に次のようになります。

翻訳レビューWebhookのWebhookトリガー構成
翻訳レビューWebhookのWebhookトリガー構成

ステップ7:翻訳をトリガーする

冒頭で述べたように、コンテンツエディターには、デフォルト言語である英語でコンテンツを作成し、前に追加したカスタム要素を使用して自動的に入力する言語バリアントを選択するオプションがあります。

翻訳をトリガーするために彼らがしなければならない最後のことは、コンテンツアイテムのデフォルトの言語バリアントを翻訳保留ワークフローステップに変更して待つことです。 Webhookハンドラーがトリガーされ、コードが選択された言語バリアントを更新します。

次は何ですか?

この例では、プロジェクトで簡単な機械翻訳を取得する方法を学習しました。

このサンプルをベースラインとして使用すると、これを拡張または調整して、他の機械翻訳プロバイダーを有効にしたり、人間ベースの翻訳を提供する翻訳サービスと統合したりすることができます。 GithubでAzure関数プロジェクトカスタム要素プロジェクトの両方のコードを取得できます。

統合によってコンテンツを強化する方法は他にもたくさんあります。さらにいくつかの例やインスピレーションを探している場合は、他の利用可能な統合を確認してください。

Headless CMSの導入をお考えでしょうか?

クラウドとマルチデバイスに最適化されたKentico Kontentをお試しください