PDA

查看完整版本: 已經完成 循環檢查和切換的API,以保持流動翻譯



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

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

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

vBET
04-10-11, 09:28
我理解你的描述和你的觀點。現在,我們必須找出如何假設工作在技術上。

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

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

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

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

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

請注意: 不管怎麼說這有一些性能影響。,而不是創建一個物件的翻譯我們將不得不創建這些物件和額外環繞物件 (以使其透明的其他部分代碼和較低的 bug 俯臥) 的陣列。當然我們不會因為我們知道的供應商在這一時刻不可用創建物件。
這個解決方案將重新配置,以獲得更好的性能和刪除供應商隊列 - 就像它現在是正確的 - 每一個語言對供應商。
這不應該是表現昂貴,但仍有一些額外的邏輯電路和內存消耗。

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

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

vBET
04-10-11, 22:31
只要快速的公告 - 我們已經實施了這項功能。

我們想要釋放它快速 (作為測試版) 由於常見的問題,由翻譯供應商設置限制引起。我們還在尋找其他 Api,它可以由 vBET:) 支援

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

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

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

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

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

Simon Lloyd
04-10-11, 22:37
只要快速的公告 - 我們已經實施了這項功能。

我們想要釋放它快速 (作為測試版) 由於常見的問題,由翻譯供應商設置限制引起。我們亦正為其它 Api,它可以由 vBET: 支援我給你發一個或兩個 (在 post 由於刪除連結) 你可以接近,如果要測試版志願者: 我是你的男人

vBET
04-10-11, 22:57
我送您一個或兩個 (在 post 由於刪除連結) 你可以接近,如果要測試版志願者: 我是你的男人

輕輕地刪除您的郵件,因為其內容是廣告寫的其他人,但我們可以獲得此消息我們:) 在它

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

所以我們正在努力改善 vBET 並作出盡可能使用廉價:)

vBET
05-10-11, 13:52
我們正處於最後階段的測試新功能。你已經可以看到更改的描述: http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.html#post8914 (見最後要注意)

Simon Lloyd
05-10-11, 18:03
感謝邁克爾,我發了一個快速貼在塔赫特常見問題,毫無疑問,你將不得不刪除,因為它不它: 如果你想測試上的正確位置調用很多翻譯和我就把你的訪問給 admincp 和論壇根 PM 的活板,我亦會谷歌翻譯限制,我已將向上和向下您的命令,因此您可以測試:)

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

Simon Lloyd
06-10-11, 06:59
要有一個計畫的任務和一個特定提供程式關閉一小時一次?,我建議在這裡圓檢查和切換的 Api 保持流動的翻譯那裡或許我們可能總是開始我們的供應商清單的頂部,使測試呼叫 (像一個您提供測試回應谷歌和微軟回應) 如果測試呼叫回應是 200 或翻譯文本然後使用該提供程式如果回應不 200 或測試文本不翻譯 (使用相同的文本,每個測試和規則運算式來檢查翻譯的文本) 然後移動到下一個供應商,每一個翻譯電話然後可以開始在清單的頂部,並下工作

因為一旦我們有了空返回這就是它仍然是如何,我已經喝得很多人抱怨這我的論壇的情況,沒有空的結果將是好事。

vBET
06-10-11, 11:33
它並不一定要通過這種方式,是現在。感謝您的便箋。-仍然不是。它有沒有意義。請注意要求外部翻譯是整個 vBET 花費更多時間的東西 (和我們不是)。有瘋成千上萬的請求,我們已達到限制時,毫無意義。這也將增粘劑在回應時間、 CPU 消耗和記憶體消耗 (創建多個物件)。

我們發現,谷歌資訊可能會濫用 TOS 消失一段時間後。我們不知道,但也許我們已經被阻止時老是問我們,如果 Google 可以阻止更多的時間。也許不需要,但仍實際的經營策略是更好的性能。在結束時你有迴圈檢查。如果沒有可用它被標記為不可用,另一個用於。如果另一個沒有類似的事情發生。我們只是不檢查是否可用它再次每個請求什麼東西有沒有意義 (它可以是數以百萬計的查詢,才是可用) 每小時只需一次。如果它將提供標記,以便我們將回到首選一-我會的你這兒有一個圓。此外測試每個時間會使你更快地達到的限制或費用較高,如果您使用支付的翻譯 (它仍算是翻譯)。
我們亦準備也有其它服務提供者。當我們會支援超過 2 這種策略將會為您的伺服器的一個殺手。想像 5 測試調用不同的提供程式和為每個翻譯請求然後實際翻譯。號感謝你的想法:)我們非常感謝使用者的想法,這一次我們會在一起實際解決方案。

請注意您可以更改頻率 vBET 應該檢查供應商的可用性。現在它是每小時,但您可以重新配置,在管理員 CP-> 任務計畫程式-> 計畫工作管理員和集,例如,每隔 10 分鐘 0 就像 RSS 海報機器人任務做它現在。

vBET
06-10-11, 13:34
小小的更改-我們將檢查供應商提供每小時不一次,但每隔 10 分鐘。如果您已經升級到 vBET 3.5.1 這條消息之前請只需再次下載 vBET 包並重新上載產品檔。

已進行了更改,因為我們發現我們真正的論壇上,常對短時間提供程式不可用。我們將調查此事去尋找另一個改善更多。

Simon Lloyd
06-10-11, 15:51
偉大的工作人員:),我已經升級到這但將下載的最新修補程式和使用我將就此創建一個新執行緒的回饋意見。

Automatic Translations (Powered by Google, Microsoft®, Yandex, SDL Language Cloud, IBM Watson and Apertium):
AfrikaansAlbanianArabicBelarusianBulgarianCatalanChineseCroatianCzechDanishDutchEnglishEstonianFilipinoFinnishFrenchGalicianGermanGreekHaitian CreoleHebrewHindiHungarianIcelandicIndonesianIrishItalianJapaneseKoreanLatvianLithuanianMacedonianMalayMalteseNorwegianPersianPolishPortugueseRomanianRussianSerbianSlovakSlovenianSpanishSwahiliSwedishTaiwaneseThaiTurkishUkrainianVietnameseWelshYiddish
Translations supported by vBET 4.10.1