Krožna preverjanje in preklapljanje API-jev, da tok prevodov

[Simon Lloyd]

Imam običajne omejitve za google nastavljena na 100.000 perday tako z moje nastavitve "Vedno uporabljajte Google", "Uporabi Google API V2", "Uporabi Google Detection", ko sem dosegel, da je meja in ni več dobili rezultate od plačanih Google bi bilo mogoče brezplačno API potem začnejo s proizvodnjo rezultate?

Tako na primer uporabljam Google prednastavljene meje in Google več ne vrne rezultat za mene (verjetno vrača kodo napake, kot so tiste v kodi preizkus Google), ko je rezultat ne vrne bi bilo dobro, če vBET avtomatično priznan kode okvar in potem pošlje zahtevo drugemu API, kot so Microsoft (ali katere koli druge, ki podpira vBET kasneje), na ta način smo prepričani, kako priti nekaj rezultata - zame bi bilo to zelo zelo dragoceno, ker obstajajo meje, tudi s plačano različice, bi vam omogočajo, da razširite prevode meje.

npr
Google je 100.000 Charcters na dan> porabil> vBET premakniti na naslednji API na seznamu> Microsoft 400K na uro ali 4M, ko meja dosežena vBET pregled naslednjih API in prejšnjih da vidim, če je omejitev odpravi ali ima nekatere vrednosti> niti premakniti na naslednji ali API nazaj na Google izplača, ko meje ponovno dosegel> preveri naslednji API .... itd in tako krožni preverjanje po prejemu kodo napake bi bil, da na tako precej stalna sposobnost, da so prevodi.

[vBET]

Jaz razumem vaš opis in vaše točke. Sedaj moramo ugotoviti, kako je možno, da tehnično delo.

Eno vprašanje vidim tukaj je, kako bomo priznati, da že imamo okviru razpoložljivih sredstev po tistih, kjer prej.

Mi lahko preprosto vsakič vprašati prednost ponudnik, nato pa pojdite na naslednjo. To bo stroškovno učinkovitost - zato, ker za vsako zahtevo na stran, ki zahteva prevod, se bomo na neuspešen klic, da prednost ponudnik, nato pa do naslednjega (tako je lahko več neuspešnih klicev, ko bo vBET podporo več API-jev).

Druga rešitev bi bila za shranjevanje podatkov, ki raje ponudnik ni na voljo, in gredo neposredno na naslednjega. To bi bilo veliko hitreje, saj preverjanje lokalna spremenljivka je veliko hitreje, kot čakajo na odgovor iz zunanjega strežnika. Tokrat imamo drugo vprašanje - ne vemo, kdaj ima prednost ponudnik na voljo. Mi lahko seveda naredil nekaj načrtovano opravilo, ki bi prosil za enostavne (kratka) prevod na primer enkrat na uro / dan, da to preveri. Torej, v tej strategiji moramo odločiti, kako pogosto privzeto takšne naloge domnevam, da dela. Seveda bi mi bilo preverjanje samo, ko je nekaj ponudnika označeni, da niso na voljo.
Tudi če bomo oznako ponudniki so na voljo - kaj storiti, ko vemo, da vsi ponudniki niso na voljo - dodati nekaj informacij za končnega uporabnika ali pa samo prevesti, kaj je v cache in ostalo, kot original, brez dodatnih informacij o začasno pomanjkanje prevod ponudnikov .

Ne glede na to, kako bo to potekalo, bo Google obravnava kot en API (v1 in v2, odvisno od konfiguracije) - ni smiselno, da ga po delih, saj bo Google v1 zaprte zelo kmalu.

Druga stvar je, da se omogoči, da nastavite ponudnikom čakalno vrsto za vsak jezikovni par posebej. V tem trenutku vBET že omogoča, da nastavite prevod ponudnika za vsak jezikovni par. Mislim, da bomo lahko to prehod iz ene vrednosti do vrednosti ločene z vejico (CSV). Na ta način bomo vedeli, za vsak jezikovni par, ki podpirajo to storitev prevajanja in kakšne so želje za (samo, da na seznamu CSV).

OPOZORILO: to bo nekaj uspešnost vpliva anyway. Namesto ustvarjanja enega predmeta za prevod bomo morali ustvariti paleto tovrstnih predmetov in dodatnih zavijanje predmet (da bi bilo pregledno za druge dele kode, manj napak nagnjeni). Seveda ne bomo ustvarili predmete za ponudnike vemo, niso na voljo v tem trenutku.
Rešitev za to bi bilo preoblikovati za boljše delovanje in odstranjevanje ponudniki čakalni vrsti - tako kot je zdaj - en ponudnik za par jezika.
To ne bi smelo biti drago za izvajanje, vendar še vedno nekaj dodatne logike in porabo pomnilnika.

Obvestite ki je najprimernejša rešitev.

[vBET]

In še možne rešitve. Če bomo oznako API kot celota ni na voljo in preverite z načrtovano opravilo je na voljo danes, potem nimamo, da bi čakalno vrsto izvajalcev. To lahko storimo, da na ta način - vedno se ustvari le en prevajalec predmeta (boljši spomin navada) in v eni zahtevi bomo prosili za prevod le en ponudnik (boljši CPU). Če ne bo na voljo, potem je označen kot ni na voljo, in rezultatov bo prazen (najslabša zanesljivost). Ampak samo prvi, ker naslednjič, ko bomo uporabili drug ponudnik iz čakalne vrste. In v primeru, če ponudnik ni na voljo, potem lutke prevajalec uporabljati - vrnitev enake vrednosti (a je ne cache), tako da se bodo nekateri deli niso prevedeni, vendar stran ne bo prazna deli, kot so zdaj, ko ponudnik ni na voljo.

[vBET]

Samo hitro obvestilo - smo že izvajajo to funkcijo.

Želimo, da se sprosti hitro (kot BETA) zaradi skupnih vprašanj, ki jih povzroča mejah, ki jih prevod ponudnikov. Prav tako smo iskali za druge API-jev, ki jih je mogoče podpreti z vBET:)

[Simon Lloyd]

Moje misli so bile, da pošljete preveri prevod najprej videti, če je prednost ponudnik na voljo, tako da nam je dal kodo, da preveri, če google ali MS se odziva, tako da v času razpisa za zbiranje Prevod googleapi (ime moj test datoteko s preizkusno kodo ), če je prevod res uporabo plini, če je prevod flase ali koda ni 200 nato poskusite naslednjo storitev na seznamu in opravljajo svoje API test pred uporabo.

Lahko bi seznamsko polje, kjer lahko uporabnik seznamu vsak ponudnik po eno vrstico v prednostnem vrstnem redu (to omogoča, ko boste dodali podporo za druge API lahko uporabnik samo jih dodate na seznam), tako da bi lahko moj seznam izgleda takole:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Ob predpostavki, Daft imena sem vstopil bili pravi izvajalcev, na razpis za prevajanje kode preizkus MS naj bi potekal, če je odgovor 200 uporabljati MS if ne požene kodo MyTranslator test, preveri odgovor za 200 Če je odgovor da uporabite ga, če ne vodijo Google test kodo **** ****** etc

Na ta način ne boste nikoli več za shranjevanje vseh informacij o ponudnikih (sicer bi lahko bili polja z besedilom, kjer lahko uporabniki vnesejo svoje postaviti meje za vsak ponudnik, ampak mislim, da te informacije wuld ne bo pomagal, kot bi jo lahko spremeni in to bi pomenilo več preverjanja nazaj in preverjanje naprej preden prevod) nikoli ne bo treba skrbeti, če omejitve so bili na voljo tako da ni potrebe za cron delo teči za preverjanje teh, bi obremenitev na strežnik za to en majhen pregled prevoda (kodo, ki jo določa FAQ) se ničesar.

Upajmo, da sem pojasnil, da ok, tako da boste dobili moja ideja, mislim, da bi se lahko vse narediti samo, da so mala pregled in brez shranjevanja ničesar.

[Simon Lloyd]

Samo hitro obvestilo - smo že izvajajo to funkcijo.

Želimo, da se sprosti hitro (kot BETA) zaradi skupnih vprašanj, ki jih povzroča mejah, ki jih prevod ponudnikov. Prav tako smo iskali za druge API-jev, ki jih je mogoče podpreti z vBET:) sem ti poslal eno ali dve (v prispevka, ki ga črta zaradi povezav), ki bi lahko pristop, če želite beta prostovoljec Jaz sem tvoj mož:)

[vBET]

Poslal sem si eno ali dve (v prispevka, ki ga črta zaradi povezav), ki bi lahko pristop, če želite beta prostovoljec Jaz sem tvoj mož:)

Sporočilo je bilo mehko črta, ker je njena vsebina je bila reklama napisal nekdo drug, vendar imamo dostop na to sporočilo in mi na njej:)

Smo tudi že poslali vprašanje, email v eno od teh prevodov ponudnikov plačilnih o podrobnostih. Nekateri od teh so plačani (tudi če je kot prost ni na ravni API - isto stvar, ki jo imajo z Google vam lahko prevesti brezplačno brskalnik, vendar ne z API), vendar pa se cene lahko konkurenčni, zato je še vedno dobra (več konkurence boljše cene).
Nekateri smo raziskati, so ti res zunanje prevode API ali samo lokalne slovarje napisali lastne uporabnike (to je tudi ena stvar na naši TODO seznamu - omogoča, da spremeni in dal svoje prevode) - Radek je ta del.

Tako smo si prizadevajo za izboljšanje vBET, saj je tako poceni v uporabi je to mogoče:)

[vBET]

Mi smo v zadnjem obdobju tesing novih funkcionalnosti. Si lahko že videli spremeniti opis: http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.html # post8914 (glej zadnje note)

[Simon Lloyd]

Hvala, Michael, sem se hitro objava v kameram Faq, ki brez dvoma boste morali odstraniti, ker ni pravilno kraj za to:), če želite preskusiti na a žive odbora, da zahteva veliko prevodi PM, in jaz bom vam dostop do admincp in forum koren, bo sem google prevod omejitev, ki so nastavim gor in dol na vaš ukaz tako lahko preskusite:)

[vBET]

OK, tako. Ponudniki čakalne vrste izvaja in se vključi v javnost 3.5.1 in 4.4.3. vBET 3.5.1 bo sprosti danes. vBET4.4.3 je še vedno v preskusni fazi. Booth javnost bo BETA, tako da vsakdo lahko preskusite v večje forumi, da preskus eno. Prosimo, upoštevajte, da smo se že preskušanje 3.5.1 na enega od naše resnično forumi. Še vedno zaradi pomembne spremembe je v BETA fazi najprej.

[Simon Lloyd]

Da bi morala biti načrtovanih opravil in zlasti ponudnik, izklopljena za ure naenkrat?, naredil sem komentar tukaj krožne preverjanje in preklapljanje vmesnikov API, da tok prevodov kjer morda smo lahko vedno začeti na vrhu našega seznama ponudnikov in narediti preskus klic (kot tista, ki jo za preskus Google odzivom in Microsoft) če preskus klic odziv je 200 ali besedilo prevesti nato uporabite ta ponudnik, če odgovora ni 200 ali preskus besedila ni prevedenega (z uporabo istega besedila za vsakega preskus in je REGEX preverite prevedenega besedila) potem premakniti na naslednjo ponudnika, vsak prevod klic lahko nato začeti na vrhu seznama in delo določitvi

Ki ni prazen rezultat bi bilo dobro zato, ker ko smo prazna vračilna to, kako ostane, sem že imel veliko ljudi, ki se pritožuje, da je tako v moji forum.

[vBET]

Ni nujno, da ta način, da je prav zdaj. Hvala za vaš Opomba. Še vedno - št. To nima nobenega smisla. Prosimo, upoštevajte, da prosi za zunanje prevod je več časa stvar v celotno vBET (in ni do nas). Ni smiselno, da mad tisoče zahtevo, ko smo že dosegli omejitve. To bi increaser odzivni čas, CPU porabe in porabe pomnilnika tudi (več predmet ustvarili).

Smo odkrili, da Google informacije o verjetno zlorabe TOS izgine po nekaj časa. Ne vemo, vendar morda če smo bo hraniti prosi, ko smo že blokiran, Google lahko blokirate za več časa. Morda ne, vendar še vedno dejanske strategije je veliko bolje za učinkovitost. Na koncu imate krožne preverjanje. Če ena ni na voljo je označena kot nedostopne in drugo se uporablja. Če drugo ni na voljo, potem se zgodi isto stvar. Smo samo ne preveri, se da na voljo znova vsako zahtevo kaj je nima smisla, (to lahko milijone poizvedbe preden je na voljo) samo enkrat na uro. In če je na voljo bo me označena tako smo bo šel nazaj k raje ena - in tukaj imate krogu. Tudi testiranje vsakič, ko bo na vaše meje, dosegli hitreje ali stroškov, ki so višje, če uporabljate plača prevodi (to še vedno šteje kot prevod).
Prav tako smo pripravljeni so drugi ponudniki preveč. Ko smo bo podpirala več kot 2 taka strategija bo morilec za strežnik. Zamislite si 5 preskušanja klici na različnih ponudnikov in nato resnično prevod za vsako zahtevo prevoda. ne. Hvala za vašo idejo:) Res cenim uporabniki ideje, tokrat smo bo ostal z dejanskim rešitev.

Prosimo, upoštevajte, da lahko spremenite kako pogosto vBET preveriti ponudnikov dostopnost. Zdaj je eno uro, ampak lahko konfigurirajte, v Admin Kp - > razporejena opravila - > načrtovano upravitelj opravil in niz, na primer za vsakih 10 minut 0 samo izgleda opravil RSS plakat Robot storiti zdaj.

[vBET]

Malo spremembo - smo bo razpolo¾ljivost ponudnik ne enkrat na uro, vendar vsakih 10 minut. Če ste že nadgradili v vBET 3.5.1 pred to sporočilo prosim samo Prenesite paket vBET znova in znova prenesti datoteko izdelka.

Spremembe prišlo zato, ker smo našli na naše realne forum, ki pogosto ponudnika ni na voljo za kratek čas. Mi bo razišče več iskati druge izboljšave.

[Simon Lloyd]

Super delo fantje:), i nadgradili na to pa bo prenesete najnovejše pritrditi in uporabe, da bo ustvariti nove niti za povratne informacije o tem.