循環檢查和切換的API，以保持流動翻譯

[Simon Lloyd]

我有我對谷歌的字符數限制設置為 10萬 perday，所以我的設置“始終使用谷歌”，“使用的Google API V2”，“使用谷歌檢測”當我達到這一限制，不再獲得來自谷歌支付的結果，才有可能免費的API，然後開始產生效果？

例如我用我 Google 預設的限制和谷歌不再返回一個結果，我 （可能返回一個像那些在谷歌測試代碼中的錯誤代碼） 時返回的結果是不如果 vBET 自動確認的故障代碼，然後發送給另一個 API 像微軟的請求就好 （或該 vBET 以後的任何其他支援） 這樣我們可以確保得到某種結果的 — — 對我來說這是非常非常有價值鑒於有限制甚至通過付費版本，它將允許您擴展你翻譯的限制。

例如
谷歌設置每日的 100,000 字元 > 用完 > vBET 移動到清單中的下一個 API > 微軟 400 k 每小時或 4 M vBET 檢查下一個 API 時達到限制和之前，看看是否限制解除或有一些津貼 > 移動到下一個 API 或返回到 Google 支付再次達到限制時 > 檢查下一個 API … … 等，所以將超小型後迴圈檢查錯誤代碼會繼續進行真可愛多常具有翻譯能力。

[vBET]

我理解你的描述和你的觀點。現在，我們必須找出如何假設工作在技術上。

我看到這裡的一個問題是我們如何認識，我們已經有很大的局限性後，另有之前達成。

只是每次的首選提供商，然後轉到下一個，可我們要求。這將花費性能--因為每次請求頁面需要翻譯的我們將作出不成功呼叫到首選供應商，然後向下一個 （這樣可以是幾次不成功調用時，vBET 將支援更多的 Api）。

其他的解決方案將存儲的首選供應商是不提供的信息，並直接進入下一個。這將是要快得多，因為檢查局部變量是比等待來自外部服務器的響應速度快。這一次，我們有其他的問題 - 我們不知道時的首選供應商。我們當然會要求簡單（短）翻譯例如每小時 /天一次，以檢查它一些預定任務。因此，在這一戰略，我們必須決定如何往往默認情況下，這樣的任務，假設工作。當然，我們會檢查它標記為不可用，只有當一些供應商。
此外，如果我們標記為不可用的供應商 - 做什麼時，我們知道，所有供應商都無法使用 - 添加一些最終用戶的信息，或只是翻譯一下在高速緩存中，並作為原始其餘沒有任何關於翻譯提供的臨時缺乏額外信息， 。

無論哪種方式，一定會完成，谷歌將被視為一個 API（v1或v2取決於配置） - 是沒有意義的分裂，因為谷歌V1將很快關閉。

另一件事是允許單獨配置每個語言對供應商的佇列。在這個時刻，vBET 已經允許配置為每個語言對翻譯供應商。我認為我們可以改變它從一個值以逗號分隔值 (CSV)。這種方式，我們將會為每個語言對知道哪個提供程式都支援此翻譯和順序首選項 （CSV 名單上的只是順序） 是什麼。

請注意： 這將有一些性能的影響了。而是創建一個翻譯的對象，我們將要創建這樣的對象和數組的額外的包裝對象（，使其他部分的代碼和更少的錯誤容易發生透明）。當然，我們不會為供應商，我們知道在這一刻不創建的對象。
這個解決方案將重新配置，以獲得更好的性能和刪除供應商隊列 - 就像它現在是正確的 - 每一個語言對供應商。
這不應該是表現昂貴，但仍有一些額外的邏輯電路和內存消耗。

請告訴是首選的解決方案。

[vBET]

和一個潛在的解決方案。 ，如果我們將標記為不可用整個 API和檢查預定的任務，它是現在，那麼我們不提供商的隊列。我們能夠做到這樣 - 總是只創建了一個翻譯對象（更好的內存使用情況），並在一個請求，我們要求翻譯只有一個供應商（更好的CPU）。如果將不可用，那麼它會被標記為不可用和結果將是空的（最壞的可靠性）。但是，只有第一個，因為下一次我們將使用另一個從隊列中的供應商。的情況下，如果沒有可用的提供者是，那麼虛擬翻譯將使用 - 返回相同的值（但不緩存），使一些地區將不翻譯，但空的部分像現在供應商是不提供的，頁面不會有。

[vBET]

只要快速的公告 - 我們已經實施了這項功能。

我們想要快速（作為 BETA ）釋放它，因為由翻譯提供者所設定的限制所造成的一般問題。 我們也在尋找其他可由 vBET 支援的 API

[Simon Lloyd]

我的想法發送檢查翻譯先來看看，如果首選供應商提供，所以你給了我們代碼來檢查，如果谷歌或MS響應，在翻譯測試 googleapi（通話時間，使我與你的測試代碼的測試文件的名稱翻譯）如果是真正的使用較受歡迎的鏈接，如果翻譯是flase或代碼不是200然後嘗試列表中的下一個供應商和使用他們的API測試之前執行。

（這允許當你添加其他API的支持，用戶只需將它們添加到列表），你可以有一個列表框，用戶可以在列表中的優先順序，每行的每個供應商之一，所以我的清單可能看起來像這樣：
微軟公司
MyTranslator
谷歌
YourTranslator
AnOtherTranslator

假設愚蠢的名字，我進入真正的供應商，翻譯 MS測試代碼的調用，運行，如果不能運行，如果響應 200使用MS MyTranslator測試代碼，檢查 200響應，如果是使用它，如果不運行 Google測試代碼 **** ******等

這樣一來，你從來沒有存儲任何對供應商的信息（否則你可以有文本框，用戶可以輸入自己設定的限制，每個供應商，但我認為這個信息wuld是無用的，因為他們可以改變它，這將意味著更多的檢查和檢查提出在翻譯之前），你將永遠不必擔心如果限制再次可用，所以沒有需要運行一個 cron作業來檢查這些服務器上的負載，一個小翻譯檢查（你的代碼中常見問題提供）將什麼。

希望我解釋說，OK，讓你得到我的想法，我覺得這都只是小檢查，並沒有存儲任何。

[Simon Lloyd]

只要快速的公告 - 我們已經實施了這項功能。

我們想要快速（作為 BETA ）釋放它，因為由翻譯提供者所設定的限制所造成的一般問題。 我們也在尋找其他可由 vBET 支援的 API

我送你一個或兩個（在你的鏈接刪除後），你可能方法，如果你想要一個測試的志願者，我是你的的男人

[vBET]

我送你一個或兩個（在你的鏈接刪除後），你可能方法，如果你想要一個測試的志願者，我是你的的男人

輕聲刪除您的郵件，因為它的內容是別人寫的廣告的，但我們已獲得這一消息，我們就可以是

我們甚至已經付款細節問題的電子郵件發送，這些翻譯供應商之一。其中一些支付（即使它是免費的描述是不API級別上 - 同樣的事情你與谷歌，你可以通過瀏覽器翻譯，但不是通過 API），但可以有競爭力的價格，因此它仍然是好的（更多的競爭，更優惠的價格）。
有些我們已經調查是那些真正外部的翻譯 API（這也是有一點我們的TODO列表 - 允許修改，把自己的翻譯） - 自己的用戶所寫的只是本地詞典拉狄克這部分。

因此我們正在努力改進 vBET ，並使其儘可能便宜地使用

[vBET]

我們在最後階段的tesing新功能。你已經可以看到改變的描述： http://www.vbenterprisetranslator.co....html＃post8914 （見最後 注意)

[Simon Lloyd]

感謝邁克爾，我在這 FAQ快速後，你將不得不刪除這無疑是因為其不正確的地方 如果你想測試一個活板，調用許多翻譯 PM我，我給你訪問 admincp和論壇根上，我還將把谷歌翻譯的限制，我已成立，並在您的命令，所以你可以測試

[vBET]

這樣好了。提供程式佇列實現的它將包含在發佈 3.5.1 和 4.4.3。vBET 3.5.1 將於今日 （星期三） 發表。vBET4.4.3 仍處於試驗階段。展位發佈將測試版，因此每個人都可以在測試之一的大論壇中進行測試。請注意我們已經測試 3.5.1 我們真正的論壇之一。仍因的重要改變它首先是處於測試階段。