Циркуляр проверка и превключване на АПИС, за да се запази потока от преводи

[Simon Lloyd]

Имам моя характер срок за Google, 100000 perday така с моите настройки "Винаги използвай Google", "Използвайте Google API V2", "Използвайте Google Detection", когато аз достигне тази граница и вече не получите резултати от платени Google ще бъде възможно безплатно APIs след това да започне да произвежда резултати?

Така например използвам моя Google предварително лимит и Google вече не връща резултат вместо мен (вероятно връща код на грешка като тези в ви Google тест код) Когато резултатът не се връща би било добре, ако vBET автоматично да се признават код за отказ и след това се изпраща искане до друга API като Microsoft (или всякакви други тази vBET по-късно поддържа) по този начин ще се ползват на получаване на някои резултат - за мен това би било много много ценен като се има предвид, че има ограничения дори с платени версии, позволява ви да разшири граници на преводи.

напр.
Google зададете 100,000 Charcters на ден > изчерпали предоставените им > vBET преминаване към следващия API в списък > Microsoft 400 k на час или 4 M, когато е достигнато ограничението, следващата API за проверка на vBET и преди да вижте ако границата е преустановено или има някои помощи > или преминаване към следващия API или обратно към Google, платени, когато отново да се достигнат лимитът > проверка на следващата API.... и т.н. и така кръгова проверка след recieving ще осъществяват код на грешка, така че нещо много постоянна способност да имате преводи.

[vBET]

Аз разбирам вашето описание и вашата гледна точка. Сега ние трябва да разберете как тя Предполагам, че да работят технически.

Един въпрос, което виждам тук е как ние ще признае, че ние вече имаме наличните лимити, след като тези, където достигна преди.

Може да просто всеки път помолим предпочитан доставчик и след това отидете на следващата. Това ще струва производителността-, защото за всяка заявка към страница, която изисква превод, ние ще прави неуспешни повиквания на предпочитан доставчик, след това за следващия един (така че може да бъде няколко неуспешни повиквания, когато vBET ще поддържа повече Апис).

Друго решение би било да съхранява информация, че предпочитан доставчик не е на разположение и да отидете директно към следващата. Това би било много по-бързо, тъй като проверка на локална променлива е много по-бързо, отколкото да се чака за отговор от външен сървър. Този път имаме друг въпрос - ние не знаем, когато предпочитан доставчик е на разположение. Ние, разбира се, може да направи някои планирана задача, която ще поиска за прости (кратко) превод например веднъж на час / ден, за да го проверите. Така че в тази стратегия, ние трябва да решим как често по подразбиране такава задача, предполагам, за да работят. Разбира се, ние ще го проверя, само, когато някои доставчикът е маркиран като не са налични.
Също така, ако отбелязваме доставчици, че няма наличност - какво да направя, когато ние знаем, че не са налични всички доставчици - добавяне на някаква информация за крайния потребител, или просто да превежда какво е в кеш, а останалите като оригинално, без всякаква допълнителна информация за временна липса на превод доставчици .

Без значение какъв начин ще бъде направено, Google ще се третира като един API (v1 или V2 в зависимост от конфигурацията) - няма смисъл да го разделят, защото Google v1 ще бъдат закрити в най-скоро време.

Друго нещо, е да се позволи да конфигурирате доставчици на опашка за всеки език двойка отделно. В този момент vBET вече позволява да конфигурирате превод доставчик за всяка двойка на език. Аз мисля, че можем да го промените от една стойност на стойности, разделени със запетая (CSV). По този начин, ние ще знаем за всяка двойка на език който доставчици поддържат този превод и какви са поръчка преференции (само ред в CSV списък).

Моля, обърнете внимание: Това така или иначе ще има известно влияние за добро изпълнение. Вместо да се създава един обект за превод ние ще трябва да се създаде масив от такива обекти и допълнителни амбалаж обект (да го направи прозрачен за други части на код и по-малко склонни бъгове). Разбира се, ние няма да създавате обекти за доставчиците, ние знаем, не са на разположение в този момент.
Решение за това ще бъде да преконфигурирате за по-добра производителност и премахване на доставчици на опашката - точно както е в момента - един доставчик за всеки език двойка.
Това не трябва да се скъпи за изпълнение, но все още някои допълнителни логика и изразходването на памет.

Моля, кажете, кое решение е за предпочитане.

[vBET]

И още едно потенциално решение. Ако ние ще се маркира цялата API тъй като не е на разположение и да го проверите, като планирана задача сега е на разположение, тогава ние не трябва да направите опашка на доставчиците. Можем да го направим по този начин - винаги се създава само един преводач обект (по-добро използване на паметта) и в едно искане молим за превод само на един доставчик (по-добри CPU). Ако тя няма да бъде на разположение, а след това това ще бъдат маркирани като не са налични и резултатите ще бъдат празни (най-лошото надеждност). Но само първата, защото следващия път, ние ще използваме друг доставчик от опашката. И в случай, ако не доставчик е на разположение, след това сляпо преводач ще бъдат използвани - връщане на едни и същи ценности (но не кеш), така че някои части ще не бъдат преведени, но няма да има празни части като сега, когато доставчикът не е на разположение.

[vBET]

Просто бързо обявяване - ние сме вече изпълнение на тази функция.

Искаме да го освободим бързо (като БЕТА) поради често срещани проблеми, причинени от лимити, определени от доставчиците на преводи. Търсим и други API, които могат да бъдат подкрепени от vBET

[Simon Lloyd]

Мислите ми бяха да изпрати първата проверка на превода, за да се види, ако предпочитан доставчик е на разположение, така че да ни даде код за да се провери, ако Google или МС е отговор, така че по време на поканата за превод тест googleapi (името на моя тестов файл с теста код ), ако преводът е вярно употреба предпочитано, ако преводът е flase или код не е 200, тогава опитайте следващия доставчик в списък и да изпълняват своите тест API, преди да използвате.

Може да има падащ списък, където потребителят може да списък всеки доставчик по един на ред по реда на предпочитанията (това позволява, когато добавите поддръжка за други APIs потребителят може просто да ги добавите в списъка), така че моя списък може да изглежда така:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Ако приемем, Daft въведените имена и са реални доставчици на повикване за превод тест MS код ще се изпълни, ако отговор 200 използването MS, ако не тече код MyTranslator тест, проверете отговор за 200 ако да го използвате, ако не работи правила за изпитване на Google **** ****** др.

По този начин никога няма да се съхранява всякаква информация за доставчиците (в противен случай бихте могли да имат текстови полета, където потребителите могат да влизат на тяхна установените граници за всеки доставчик, но аз мисля, че тази информация wuld да бъде безполезно, тъй като те биха могли да го променят и това би означавало по-проверка и проверка напред, преди да направи превод) никога не би да се притеснявате, ако ограниченията са отново на разположение, така че няма нужда за Cron работа да тече, за да проверите тези, натоварването на сървъра за една проверка, че малките превод (кода, който сте предоставили в често задавани въпроси) ще бъде нищо.

Надяваме се и обясни, че ОК, така че да получите моята идея, аз мисля, че тя може да бъде направено само от тази малка проверка и без съхраняване нищо.

[Simon Lloyd]

Просто бързо обявяване - ние сме вече изпълнение на тази функция.

Искаме да го освободим бързо (като БЕТА) поради често срещани проблеми, причинени от лимити, определени от доставчиците на преводи. Търсим и други API, които могат да бъдат подкрепени от vBET

Аз ви изпратих един или два (в поста, който сте изтрили, защото на връзките), че бихте могли да подходим, ако искате бета доброволец Аз съм твоят човек

[vBET]

Аз ви изпратих един или два (в поста, който сте изтрили, защото на връзките), че бихте могли да подходим, ако искате бета доброволец Аз съм твоят човек

Вашето съобщение беше тихо заличават, защото съдържанието му е реклама, написани от някой друг, но ние имаме достъп до това съобщение и ние сме на нея

Ние дори вече да изпращат мейл на въпрос на един от тези преводи доставчици за плащане детайли. Някои от тях са платени (дори когато тя е описана като свободни, не е на ниво API - нещо, което трябва с Google можете да превеждате безплатно от браузъра, но не от API), но цените могат да бъдат конкурентни, така че все още е добро (по-голяма конкуренция по-добри цени).
Някои, ние трябва да разследва тези наистина външни преводи API или само местните речници, написана от собствените си потребители (това също е едно нещо, за TODO списъка ни позволява да модифицирате и собствени преводи) - Радек тази част.

Така че ние работим за подобряване на vBET и го направи възможно най-евтини в употреба

[vBET]

Ние сме в последните стадии на tesing нови функции. Вече можете да видите променените описание: http://www.vbenterprisetranslator.Co....HTML#post8914 (вж. последния ЗАБЕЛЕЖКА)

[Simon Lloyd]

Благодаря Майкъл, направих бързо пост в taht въпроси, които несъмнено ще трябва да се премахне, защото му не правилното място за него Ако искате да проверите на живо съвет, която изисква много преводи PM, да ми и аз ще ви даде достъп до admincp и форум корен, аз ще поставите лимит за превод на google, че аз съм записал нагоре и надолу в вашата команда така можете да изпробвате

[vBET]

ОК така. Доставчиците на опашка се прилага и тя ще бъде включена в версии 3.5.1 и 4.4.3. vBET 3.5.1 ще бъдат освободени днес. vBET4.4.3 е все още в стадий на теста. Щандът освобождавания ще бъде бета, така че всеки може да го проверите в по-големи форуми, които един тест. Обърнете внимание, че ние вече са тестването 3.5.1 на един от нашите реалния форуми. Все още поради важни промени е в бета етап първо.