統合
自動翻訳をワークフローに統合する
By Christopher Jennings
会社の規模に関係なく、母国語で聴衆にリーチすることは、彼らがあなたの言うことを本当に聞いているかどうかを決定する要因になる可能性があります。
翻訳は複雑で時間がかかります。それを処理する方法はたくさんあり、訓練を受けた翻訳者と協力して最良の結果を得ることができますが、完璧な翻訳が本当に必要でない場合や、ニーズに対して費用効果が高い場合はどうでしょうか。機械翻訳はこれに役立ちます。
機械翻訳の真の力は、その速度とコストにあります。常に100%正確であるとは限りませんが、すぐに入手できます。それはとても速くできるので、これはいくつかの興味深い可能性への扉を開きます。翻訳者が参加しているチームの場合、機械翻訳を使用すると、ほとんど正確な出発点を得ることができます。白紙の状態では機能しないため、より効率的になります。機械翻訳が必要なものに十分対応できる状況では、非常に費用対効果が高くなります。
Kontentでの翻訳の自動化
Kontentで機械翻訳のメリットを享受し、コンテンツ編集者にとってシームレスにすることができます。彼らの観点から、彼らがしなければならないのは、コンテンツを作成し、翻訳したい言語を選択し、コンテンツアイテムを「翻訳保留中」のワークフローステップに移動することだけです。そこから、アイテムが自動的に「翻訳レビュー」ステップに移動し、翻訳されたコンテンツを編集または公開できるようになるまで待機します。 Content Management API v2 、ワークフローイベントによってトリガーされるいくつかのWebhook、 カスタム要素、およびAzure Translator Text APIを使用して、このデモを作成しました。
高レベルでの動作は次のとおりです。
自分で試してみる
変換コネクタのソースコードは、GitHubの2つのリポジトリで利用できます。1つはカスタム要素用で、もう1つはWebhookを処理するAzure関数用です。これらのプロジェクトのREADMEファイルには、セットアップと開発に関する詳細情報がありますが、構成の主な手順を見ていきましょう。
同僚のRyanOvertonがまとめたこのビデオでは、この投稿の残りの部分で取り上げている内容の概要を説明しています。
ステップ1:言語を構成する
最初に行うことは、プロジェクトに1つ以上の言語を追加したことを確認することです。 Codename
を設定するときは、MicrosoftのTranslatorAPIでサポートされている言語コードを使用する必要があります。
ステップ2:カスタム要素を追加する
カスタム要素は、翻訳する必要のあるすべてのコンテンツタイプに存在する必要があります。これを行う最も簡単な方法は、最初にコンテンツスニペットを作成することです。スニペットに必要な要素は、カスタム要素の1つだけです。
- Kentico Kontentで、アプリメニューから[コンテンツモデル]を選択します。
- [コンテンツタイプスニペット]タブに移動します。
- [新規作成]ボタンをクリックします。
- スニペットの名前を入力します(例:「翻訳」)
- カスタム要素を追加します。
- タイトル–翻訳設定
- ホストされているコードのURL–以下を参照してください
- パラメータ-以下を参照してください
ホストされているコードのURL
本番ユースケースの場合、 リポジトリをフォークしてカスタム要素を自分でデプロイする必要があります。簡単なテストを行いたいだけの場合は、 https://kontent-translation-connector-custom-element.netlify.com/
を使用できます。これは、リポジトリのマスターブランチのデプロイ済みバージョンです。
パラメーター
コンポーネントに必要なJSONパラメーターについては、リポジトリのreadmeのカスタム要素セクションの構成で詳しく説明しています。完全なJSONは次のようになります。
最後に、コンテンツタイプスニペットをコンテンツタイプに追加します。
ステップ3:ワークフローステップの構成
プロジェクトに2つのワークフローステップを追加する必要があります。フローのどこにでも追加できます。翻訳保留ステップは、翻訳プロセスを開始するために使用されます。翻訳レビューワークフローステップは、次の言語をトリガーするか、翻訳プロセスを終了し、言語バリアントがレビューの準備ができていることを示すために使用されます。
手順4:Azure Translator TextAPIキーを取得する
次のステップでは、Translator TextAPIの認証キーが必要になります。これは次の方法で入手できます。
- Azureポータルにログインする
- 新しい「翻訳者テキスト」リソースの作成
- 新しいリソースを開く
- 「キー」に移動し、キーの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://
。
Workflow steps of content items to watch
のみを構成して、変換コネクタをトリガーするように設計された専用のワークフローステップへのトリガーを監視する必要があります。名前としてTranslation pending
をお勧めします。トリガーは基本的に次のようになります。
翻訳完全なwebhook
2番目のWebhookは、翻訳が終了したことを通知し、次の翻訳を開始するためのものです。このWebhookのURL address
は、このプロジェクトのTranslationReviewHandler
URLは次のようになります: https://
。
Workflow steps of content items to watch
のみを構成して、翻訳が完了し、レビューの準備ができていることを示すように設計された専用のワークフローステップへのトリガーを監視する必要があります。名前としてTranslation review
をお勧めします。トリガーは基本的に次のようになります。
ステップ7:翻訳をトリガーする
冒頭で述べたように、コンテンツエディターには、デフォルト言語である英語でコンテンツを作成し、前に追加したカスタム要素を使用して自動的に入力する言語バリアントを選択するオプションがあります。
翻訳をトリガーするために彼らがしなければならない最後のことは、コンテンツアイテムのデフォルトの言語バリアントを翻訳保留ワークフローステップに変更して待つことです。 Webhookハンドラーがトリガーされ、コードが選択された言語バリアントを更新します。
次は何ですか?
この例では、プロジェクトで簡単な機械翻訳を取得する方法を学習しました。
このサンプルをベースラインとして使用すると、これを拡張または調整して、他の機械翻訳プロバイダーを有効にしたり、人間ベースの翻訳を提供する翻訳サービスと統合したりすることができます。 GithubでAzure関数プロジェクトとカスタム要素プロジェクトの両方のコードを取得できます。
統合によってコンテンツを強化する方法は他にもたくさんあります。さらにいくつかの例やインスピレーションを探している場合は、他の利用可能な統合を確認してください。