円形のチェックと翻訳の流れを維持するためのAPIの切り替え

[vBET]

私はあなたの説明とあなたのポイントを理解する。今我々はそれが技術的に動作すると仮定方法を見つける必要があります。

私はここで見る一つの問題は、我々はすでに前に到達したところ、それらの後に使用可能な限界を持っていることを認識する方法です。

優先プロバイダーとし、次の 1 つは単にたびを求めることができます。翻訳が必要なページの要求ごとに、私たちがしたので失敗の呼び出し (vBET 個の Api をサポートする場合、いくつかの失敗した呼び出しできるように)、次に 1 つの優先プロバイダーにこのパフォーマンス - の費用がかかります。

他のソリューションでは、優先プロバイダが利用できないという情報を格納し、次のいずれかに直接移動することです。ローカル変数をチェックするのは、外部サーバからの応答を待っているよりもはるかに高速であるため、これは、はるかに高速です。今回は他の問題を持っている - 我々は、優先プロバイダが使用可能な時期は不明です。我々はもちろん、それをチェックする時間/ 1日1回、例えば、単純な（短期）の翻訳を求めるという、いくつかのスケジュールされたタスクを行うことができます。したがって、この戦略では、デフォルトでそのようなタスクが動作すると仮定する頻度を決定する必要があります。もちろん、我々はいくつかのプロバイダが利用できないとマークされている場合にのみ、それをチェックします。
また、我々が使用不可としてプロバイダをマークする場合 - 我々はすべてのプロバイダが利用できないことを知っているときに何をすべきか - 翻訳プロバイダの一時的な不足についての追加情報なしで、エンドユーザーの一部の情報を追加したり、単にキャッシュと元の残りの部分で何かを変換する。

それが行われる方法に関係なく、Googleは一つのAPI（v1またはv2が構成に応じて）として扱われることはありません - Googleはv1が非常にすぐに閉じられてしまうため、それを分割しても意味は、ありません。

プロバイダー キュー各言語ペアを個別に構成できるようにする別のことです。この時点で vBET は既に各言語ペアの翻訳プロバイダーを構成することができます。私は 1 つの値からコンマ区切り値 (CSV) を変更できますと思います。この翻訳はプロバイダーは各言語ペアを知っているこの方法をサポートと順序設定 (CSV 一覧のためだけ)。

ご注意ください： これは、とにかくいくつかのパフォーマンスに影響が出ます。代わりに、翻訳ごとに1つのオブジェクトを作成するので我々はそのようなオブジェクトの配列と追加のラップオブジェクトを（コードと発生しやすいバグも少ないの他の部分のためのそれを透明にする）を作成する必要があります。もちろん、我々は現時点では利用できないことがわかっているプロバイダのためのオブジェクトは作成されません。
このためのソリューションは、パフォーマンスを向上させるために再設定することとプロバイダのキューを削除する - それが今の場合と同様に - 言語の組ごとに1つのプロバイダ。
これにより、パフォーマンスが、まだいくつかの追加のロジックおよびメモリ消費のための高価であってはならない。

ソリューションが好まれている教えてください。