この問題も発生しています。トランスレータの v1 が廃止された (またはサービスが終了した) ようです。ただし、API の v2 は機能します。
MS datamarket アカウント キー (ここにあるもの: https://datamarket.azure.com/account/keys ) のみを必要とする認証形式を使用していると思います。
この形式の認証では、次のようなコードを使用して変換を行います。
Microsoft.TranslatorContainer xlator = new Microsoft.TranslatorContainer("https://api.datamarket.azure.com/Bing/MicrosoftTranslator/v1/Translate");
xlator.Credentials = new NetworkCredential("account key, "account key");
DataServiceQuery<Microsoft.Translation> xlateQry = xlator.Translate("translate me", "en", "fr");
Microsoft.Translation xlateResult = xlateQry.Execute().First();
translateOutput = xlateResult.Text;
Microsoft 名前空間内の TranslatorContainer クラスと Translation クラスは、MS が翻訳の最初のバージョンで提供した生成コードから取得されます。
これは私たちが行ったことであり、昨日も機能しなくなりました。MS は、新しい認証スキームと API を優先して、この形式の認証を強制的に (そして密かに知る限り) 中止したようです。MS Translate API のホームページからナビゲートする際に、API の v1 のドキュメントにアクセスできなくなったことに注意してください。
ただし、これらの URL で API の v2 の指示に従って、既存のアカウントを使用してアドホック HTTP 翻訳リクエストを正常に作成することができました。
HTTP インターフェイスの使用
アクセストークンの取得
「アクセストークンの取得」を見るときは、特定の URL の下部の PowerShell の例に移動し、POST を使用して認証トークンを取得し、翻訳要求に GET を使用することを忘れないでください。また、認証トークン要求には URL エンコードされたパラメーターを使用することを忘れないでください。アドホック リクエストに対して Chrome で PostMan を使用する例を実行するときに、これらのことが私をつまずかせたからです。
この移行は十分に文書化されている可能性が非常に高いかもしれませんが、変換 API の v1 を使用するアプリケーションを継承している私のような一部の貧弱な SAP にとっては、MS が v1 を使用するすべての人を冷静に放置したように見えます。翻訳 API のドキュメントをナビゲートすると、2 つのバージョンがあり、1 つが廃止されることは明らかです。