Кружни проверка и префрлување на API за да се задржи протокот на преводи

[Simon Lloyd]

Имам карактер рок за Google постави до 100.000 perday така со моите опции "Секогаш користете Google", "Користете го Google API V2", "Користете го Google за откривање" Кога ќе стигнат до таа граница и повеќе не се добијат резултати од Google плаќа тоа ќе биде можно бесплатно API-јата, тогаш проектот за производство на резултатите?

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

на пример,
Google постави 100.000 Charcters дневно> искористени> vBET потег за следната API во листата> Мајкрософт 400K на час или 4M кога граница достигна vBET провери следната API и претходната да се види дали ограничување е укината или има некои додаток> или оди на следниот API или Назад кон Google платени кога граница достигна повторно> проверете следниот API .... итн и така на кружни проверка по ДОБИВАЊЕ грешка во кодот ќе ја продолжи, па прилично многу постојана способност да имаат преводи.

[vBET]

Јас разбирам вашиот опис и вашата точка. Сега ние треба да дознаете како тоа да претпоставиме да работат технички.

Едно прашање гледам тука е како ќе се признае дека ние веќе имаат ограничувања на располагање по оние каде стигна пред.

Ние можеме да едноставно секој пат прашам претпочитан давател и потоа оди кон следниот. Ова ќе чини перформанси - затоа што за секое барање на страна која бара превод, ние ќе направи неуспешен повик за претпочитан давател, а потоа во следната (така тоа може да биде неколку неуспешни повици кога vBET ќе го поддржи повеќе APIs).

Друго решение ќе биде да ја запази информацијата дека склопот на услуги не е на располагање и одат директно на следниот. Ова ќе биде многу побрзо, бидејќи проверка локална променлива е многу побрзо отколку на чекање за одговор од надворешен сервер. Овој пат имаме друг проблем - ние не знаеме кога склопот провајдер е на располагање. Ние, се разбира, направи некои закажани задача која ќе побара за едноставни (краток) превод на пример еднаш на час / ден да го проверите. Значи во оваа стратегија треба да одлучите колку често по дифолт како задача да претпоставиме да работат. Се разбира, ние ќе го провериш само кога некој провајдер е означен како не се достапни.
Исто така, ако го одбележуваме провајдери како недостапен - Што да правите кога знаеме дека сите провајдери не се достапни, - додаде некои информации за крајниот корисник или само Преведете она што е во кеш, а остатокот како оригиналот, без никакви дополнителни информации за привремен недостиг на превод на услуги .

Без разлика на кој начин тоа ќе биде направено, Google ќе бидат третирани како еден API (V1 или V2 зависно од конфигурацијата) - нема смисла да се отцепат, бидејќи Google V1 ќе бидат затворени многу наскоро.

Друга работа е да им овозможи да го конфигурирате услуги задача за секој јазичен пар одделно. Во овој момент vBET веќе им овозможува да го конфигурирате обезбедувач на преведувачки услуги за секој јазичен пар. Мислам дека можеме да го менуваат од една вредност на одвоени со запирки вредности (CSV). На овој начин ние ќе знаеме за секој јазичен пар кои услуги поддршка на овој превод и она што се цел параметри (само со цел на CSV листа).

Забелешка: Ова ќе има некои перформанси влијание во секој случај. Наместо за создавање еден објект за превод ќе треба да се создаде низа на таквите објекти и дополнителни обвивката објект (да се направи тоа транспарентни за други делови на кодот и помалку грешки склони). Се разбира, ние нема да креирате објекти за провајдерите не знаеме да се најдат на овој момент.
Решение за ова би било да конфигурирате за подобри перформанси и отстранување на услуги задача - исто како што е сега - еден оператор на јазичен пар.
Ова не треба да биде скап за перформансите, но сепак некои дополнителни логика и потрошувачка на меморија.

Ве молиме кажете за чие решение е најпосакувана.

[vBET]

И уште една можно решение. Ако ние ќе го одбележи целиот API како не се достапни и провери од закажана задача е на располагање во моментов, тогаш ние не треба да се направи ред на давателите на услуги. Ние можеме да го направи тоа на овој начин - секогаш е создадена само еден преведувач објект (подобра меморија употреба) и во едно барање бараме превод само еден оператор (подобро процесорот). Ако тоа нема да биде достапна, тогаш тоа ќе бидат означени како не се достапни и резултатите ќе бидат празни (најлошите сигурност). Но, само првиот, затоа што следниот пат кога ние ќе ги искористиме друг провајдер од задачата. И во случај ако не провајдер е на располагање, тогаш атарот преведувач ќе се користи - враќање истите вредности (но не го кеш), па некои делови нема да бидат преведени но страница нема да има празни делови како сега кога давател на услуги не е на располагање.

[vBET]

Само брз најава - ние сме веќе спроведување на оваа функција.

Ние сакаме да го ослободи брзо (како бета верзија) бидејќи на заедничките прашања, предизвикани од ограничувањата утврдени со превод на услуги. Ние исто така сме во потрага по други API-јата која може да биде поддржана од vBET :)

[Simon Lloyd]

Моите мисли се да се прати превод провери прво да се види ако сакате провајдер е на располагање, па ќе ни даде код за да провериш дали Google или MS реагира, така што во време на повик За преведувачки тест googleapi (името на мојот тест датотеката со пробната кодот ) ако преводот е точно употреба preffered, ако превод е flase или код не е 200, тогаш обидете се следните услуги во листата и ги извршуваат своите API тест пред употреба.

Вие би можеле да имаат listbox каде корисникот може да списокот секој провајдер еден по линија со цел на приоритетни (ова ви овозможува кога ќе додадете и поддршка за други API-јата на корисникот може само да ги додадете на листата), па мојата листа може да изгледа вака:
Мајкрософт
MyTranslator
Google
YourTranslator
AnOtherTranslator

Претпоставувајќи глупав имиња влегов беа вистински услуги, на повик за превод MS тест кодот да се кандидира, ако одговорот 200 користите MS ако не се кандидира MyTranslator тест кодот, проверете одговор за 200 Ако одговорот е да го користи ако не ја стартувате Google тест кодот **** ****** итн

На овој начин никогаш не треба да чува сите податоци на даватели на услуги (инаку би можеле да имаат текст кутии, каде што корисниците би можеле да влезат во зададените граници за секој провајдер, но мислам дека оваа информација wuld се бескорисни, како тие би можеле да го промени и тоа би значело повеќе проверка назад и проверка на напред пред да превод) вие никогаш нема да мора да се грижите ако границите се достапни повторно, па нема потреба од закажана задача да се кандидира за да се провери овие, товарот на серверот за таа една мала превод Проверете (го кодот е предвидено во ЧПП) ќе биде ништо.

Се надевам дека ќе објасни дека Ok, па да се моја идеја, мислам дека сето тоа може да се направи само со таа мала проверка и без да се чуваат ништо.

[Simon Lloyd]

Само брз најава - ние сме веќе спроведување на оваа функција.

Ние сакаме да го ослободи брзо (како бета верзија) бидејќи на заедничките прашања, предизвикани од ограничувањата утврдени со превод на услуги. Ние исто така сме во потрага по други API-јата која може да биде поддржана од vBET :) Јас ви испрати една или две (во еден пост дека избришан бидејќи на врски) што ќе може да пристапат, доколку сакате да имате бета волонтер Јас сум вашиот маж :)

[vBET]

Јас ви испрати една или две (во еден пост дека избришан бидејќи на врски) што ќе може да пристапат, доколку сакате да имате бета волонтер Јас сум вашиот маж :)

Вашата порака беше тивко избришан, бидејќи неговата содржина беше реклама испишана од некој друг, но ние имаме пристап до оваа порака, а ние сме на неа :)

Ние дури веќе Испрати прашање e-mail на еден од оние преводи на услуги за податоци за плаќањето. Некои од нив се платени (дури и кога е опишан како слободна, таа не е на API ниво - исто нешто што треба со Google можете да Преведете слободни од страна на прелистувачот, но не API), но цените да бидат конкурентни, па затоа се уште е добра (повеќе конкуренција подобри цени).
Некои имаме испита се оние кои се навистина надворешни преводи API или само на локалните речници напишани од страна на самите корисници (тоа е една работа на нашата Листа на задачи - Дозволи да се измени и стави свој превод) - Радек има овој дел.

Значи ние се работи на подобрување на vBET и го направи како ефтина во употреба, како е можно :)

[vBET]

Ние сме во последните фази од tesing нова функционалност. Вие веќе може да се види изменета опис: http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.html # post8914 (види последен белешка)

[Simon Lloyd]

Благодарам Мајкл, не сум направил брз пост во taht Помош кои без сомнение ќе мора да се отстранат, бидејќи нејзиниот не се точни место за него :), ако би сакал да ги тестира на АА во живо одбор кој го нарекува многу преводи ме часот и ќе ти дадам ви овозможи пристап до корен admincp и форум, и исто така ќе се стави Google превод ограничување дека јас се постави и долу во вашата команда, па можеш да пробаш :)

[vBET]

OK, па. Давателите на услуги задача е имплементиран и тоа ќе бидат вклучени во изданија 3.5.1 и 4.4.3. vBET 3.5.1 ќе биде објавен денес. vBET4.4.3 се уште е во тест фаза. Бут изданија ќе биде BETA па секој може да го пробате во поголеми форуми кои еден тест. Ве молиме имајте во предвид дека ние сме веќе тестирање 3.5.1 на еден од нашите вистински форуми. Сепак, бидејќи на важни промени тоа е во бета фаза во прв план.

[Simon Lloyd]

Дали тоа треба да биде закажана задача и еден одреден оператор е исклучено за еден час во еден момент?, Не сум направил предлог тука Кружни проверка и префрлување на API за да се задржи протокот на преводи каде што можеби ние секогаш би можеле да почнат во врвот на нашата услуги листа и да тест повик (како оној што се предвидени да се тестираат на Google одговор и Microsoft одговор) Ако тест повик одговор е 200 или текст е преведен потоа ги користат тие услуги, ако одговорот не е 200 или тест текст не е преведен (со користење на истите текст за секој тест и REGEX да се провери на преведениот текст) а потоа се пресели на следната провајдер, секој превод повик тогаш може да почне на врвот на листата и работа надолу

Не има празни резултат ќе биде добро затоа што еднаш имаме празен се врати тоа е начинот на тоа останува, јас сум веќе имаше многу луѓе се жалат дека ова е случај во мојот форум.

[vBET]

Тоа не мора да бидат на овој начин, тоа е во моментов. Ви благодариме за белешка. Уште - не. Тоа нема смисла. Ве молиме имајте предвид дека прашува за надворешни превод е повеќе време одзема нешто во целата vBET (и тоа не е до нас). Нема смисла да се луди илјадници барање кога ние веќе стигнат до граници. Ова ќе increaser време на одговор, процесорот потрошувачка и потрошувачка на меморија исто така (повеќе објекти создадени).

Ние откривме дека Google информации за веројатно злоупотреба TOS исчезнува по некое време. Ние не знаеме, но можеби ако ние ќе го задржи прашуваме кога веќе сме блокирани, Google може да го блокира за повеќе време. Можеби не, но сепак вистинските стратегија е многу подобро за перформанси. На крајот имаш кружни проверка. Ако некој не е на располагање се обележани како што се недостапни, а друг се користи. Ако друг не е достапна, тогаш истото се случува. Ние едноставно не се провери е на располагање повторно секое барање што нема смисла (тоа може да биде милиони пребарувања пред истиот ќе биде достапен) само еднаш на час. И дали тоа ќе биде на располагање ќе ми го одбележа па ние ќе се врати во склопот на еден - и имаш круг тука. Исто така тестирање секој пат кога ќе направи вашите граници достигна побрзо или чини повисоко ако го користите платени преводи (сепак се брои како превод).
Исто така, ние сме подготвени да имаат и други провајдери премногу. Кога ние ќе ја поддржиме повеќе од 2 таква стратегија ќе биде убиец за вашиот сервер. Замислете 5 тестирање повици кон различни провајдери, а потоа реално превод за секој превод барање. Не, благодарам за вашата идеја :) Ние навистина го цениме корисници идеи, овој пат ние ќе остане со реалните решение.

Ве молиме имајте во предвид дека може да го промени колку често vBET треба да се провери на услуги достапност. Сега тоа е еден час, но може да се реконфигурира дека во Админ CP -> закажани задачи -> закажани Task Manager и постави го на пример за секои 10 минути 0 исто како задача RSS Постер роботот го направи тоа сега.

[vBET]

Малку промена направена - ние ќе ги провери провајдер достапноста не еднаш на час но на секои 10 минути. Ако веќе надградена до vBET 3.5.1 пред оваа порака молам само преземете vBET пакет повторно и испратите производот датотеката повторно.

Промената е направена затоа што се најде на нашите вистински форумот кој често провајдер е недостапен за кратко време. Ние тоа ќе го испита повеќе да барате друг подобрувања.

[Simon Lloyd]

Голема работа момци :), јас се надградува за ова, но ќе ги симнете најновите фикс и ја користат таа, јас ќе се креира нова тема за повратни информации за ова.