Omsendbrief nagaan en die skakel van die vloei van vertalings API's te hou

[Simon Lloyd]

Ek het my karakter limiet vir Google ingestel op 100,000 perday so met my stellings "Altyd gebruik Google", "Gebruik Google API V2", "Gebruik Google Detection" toe ek by daardie perk en nie meer die resultate van betaal Google sou dit moontlik wees vir gratis API's begin met die vervaardiging van resultate?

So byvoorbeeld het ek gebruik om my Google-geprogrammeerde limiet en Google nie meer 'n resultaat vir my (waarskynlik' n fout kode soos dié wat in die kode van jou Google-toets terug nie) wanneer die resultaat is nie teruggestuur word, sou dit goed wees as vBET outomaties die skuld kode erken en dan gestuur word versoek na 'n ander API soos Microsoft (of enige ander dat vBET later ondersteun) op hierdie manier wat ons kry uitslag verseker is - vir my sal wees baie baie waardevol dat daar grense is selfs met betaalde weergawes, sou dit jou toelaat om te verleng jou vertalings grense.

bv.
Google stel 100,000 per dag Charcters> opgebruik> vBET skuif na die volgende API in die lys> Microsoft 400k per uur of 4M wanneer limiet bereik vBET volgende API en vorige nagaan om te sien as die limiet is opgehef of het 'n paar toelae> skuif na die volgende API of Terug na Google betaal wanneer limiet bereik weer> Check die volgende API .... ens en so die omsendbrief kontrole na die ontvangs van 'n fout kode sal uitvoer, so pretty much konstante vermoë om vertalings te hê.

[vBET]

Ek verstaan jou beskrywing en jou punt. Nou het ons om uit te vind hoe dit veronderstel is om te tegnies te werk.

Een kwessie wat ek hier sien, is hoe ons sal erken dat ons reeds beskikbaar perke ná dié waar bereik moet word voordat is.

Ons het elke keer kan net vra voorkeurverskaffer en dan gaan jy na die volgende een. Dit sal koste prestasie - want vir elke versoek aan bladsy wat vertaling vereis, sal ons onsuksesvol oproep gemaak na voorkeurverskaffer, dan na die volgende een (sodat dit kan word om verskeie onsuksesvolle oproepe wanneer vBET meer APIs ondersteun).

Ander oplossing sou wees om inligting wat voorkeur-verskaffer nie beskikbaar is nie te slaan en gaan direk na die volgende een. Dit sou baie vinniger, omdat die kontrolering van lokale veranderlike is baie vinniger as om te wag vir die reaksie van eksterne bediener. Hierdie keer het ons 'n ander saak - ons weet nie wanneer voorkeurverskaffer is beskikbaar. Ons kan natuurlik 'n paar geskeduleerde taak wat vra vir' n eenvoudige (kort) vertaling byvoorbeeld een keer per uur / dag om dit te sien. So in hierdie strategie het ons om te besluit hoe gereeld by verstek sodanige taak veronderstel is om te werk. Natuurlik sou ons kyk dit slegs wanneer 'n verskaffer is gemerk as nie beskikbaar is nie.
Ook as ons merk verskaffers nie beskikbaar nie - wat om te doen wanneer ons weet dat die verskaffers nie beskikbaar is - voeg 'n bietjie inligting vir die eindgebruiker of net vertaal wat in die kas en die res as die oorspronklike is, sonder enige verdere inligting oor die tydelike gebrek aan vertaling verskaffers .

Maak nie saak watter manier waarop dit gedoen sal word, sal Google beskou word as een API (v1 of V2 afhangende van configuration) - daar is geen sin om dit te verdeel nie, omdat Google v1 sal binnekort gesluit word.

Nog 'n ding is om verskaffers tou te stel vir elke taalpaar afsonderlik. Op die oomblik is vBET kan reeds die verskaffer van die vertaling instel vir elke taalpaar. Ek dink dat ons dit kan verander van 'n waarde te kommas geskei waardes (CSV). Op hierdie manier sal ons weet vir elke taalpaar wat bied ondersteuning vir hierdie vertaling en wat is 'n orde voorkeure (net orde op CSV lys).

LET WEL: Dit sal in elk geval sommige prestasie impak. In plaas van die skep van van 'n item vir die vertaling, sal ons die skikking van sodanige voorwerpe en addisionele wikkel voorwerp (deursigtig vir ander dele van die kode en minder foute geneig om dit) te skep. Natuurlik sal ons nie voorwerpe skep vir verskaffers van ons weet nie beskikbaar is nie op hierdie oomblik.
Oplossing vir hierdie sou wees om weer instel vir beter prestasie en verwyder verskaffers queue - net soos dit nou is - 'n verskaffer per taalpaar.
Dit moet nie duur wees vir die prestasie, maar nog 'n paar ekstra logika en geheue verbruik.

Let asseblief vertel wat die oplossing is verkies.

[vBET]

En een moontlike oplossing. As ons die hele API sal merk as dit nie beskikbaar is en maak seker dit deur geskeduleerde taak, is dit nou beskikbaar is, dan is ons nie ry van verskaffers te maak. Ons kan dit doen op hierdie manier - altyd is geskep om slegs een vertaler voorwerp (beter geheue gebruik) en in een versoek ons vra vir vertaling slegs een verskaffer (beter CPU). As dit sal nie beskikbaar is nie, dan sal dit gemerk word as nie beskikbaar is nie en die resultate sal leeg wees (ergste betroubaarheid). Maar slegs die eerste een, want die volgende keer sal ons gebruik maak van 'n ander verskaffer van die tou. En in die geval as daar geen verskaffer beskikbaar is, dan skyn vertaler sal gebruik word - terug dieselfde waardes (maar kas dit nie doen nie), sodat sommige dele sal nie vertaal word, maar sal nie leë dele soos nou wanneer verskaffer nie beskikbaar is nie.

[vBET]

Net vinnige aankondiging - ons is reeds die uitvoering van hierdie funksie.

Ons wil hulle dit so vinnig vrylating (BETA) as gevolg van die algemene probleme wat veroorsaak word deur die grense wat deur vertaling verskaffers. Ons is ook op soek na ander APIs wat deur vBET ondersteun word:)

[Simon Lloyd]

My gedagtes is die tjek vertaling om eerste te stuur om te sien of voorkeurverskaffer is beskikbaar, sodat jy vir ons gegee het kode om seker te maak indien Google of MS reageer, ten tyde van die oproep vir die vertaling toets googleapi (naam van my toets lêer met jou toets kode ) indien die vertaling is 'n ware gebruik voorkeure, as die vertaling is flase of kode nie is 200 en probeer dan die volgende verskaffer in die lys en hul API-toets voor gebruik.

Jy kan 'n keuselys waar die gebruiker elke diensverskaffer een per lyn kan die lys in volgorde van voorkeur (Dit laat wanneer jy ondersteuning vir ander APIs die gebruiker dit kan byvoeg by die lys), so my lys kan soos volg lyk:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Veronderstel die Daft name Ek het reële verskaffers, op roep vir vertaling MS toets kode sou hardloop, as reaksie 200 gebruik MS indien nie MyTranslator toets kode uitgevoer, maak seker die antwoord vir 200 indien ja dit gebruik, indien nie Google toets kode hardloop **** ****** ens.

Op hierdie manier wat jy nog nooit enige inligting oor die verskaffers op te slaan (anders wat jy kan hê teks bokse waar gebruikers hul stel grense vir elke verskaffer kon ingaan, maar ek dink hierdie inligting wuld nutteloos word as hulle dit kan verander en dit sou beteken meer keur terug en kontrolering vorentoe voor die maak van 'n vertaling) wat jy nooit sou hoef te bekommer indien die perke is weer beskikbaar, sodat daar geen behoefte vir' n cron uit te voer om dit te gaan nie, sal die las op die bediener wees vir daardie een klein vertaling tjek (die kode wat u verskaf het in die FAQ) niks.

Hopelik sal ek verduidelik dat ok, sodat jy my idee, dink ek dit kon gedoen word nie net deur daardie klein check en sonder om enigiets te stoor.

[Simon Lloyd]

Net vinnige aankondiging - ons is reeds die uitvoering van hierdie funksie.

Ons wil hulle dit so vinnig vrylating (BETA) as gevolg van die algemene probleme wat veroorsaak word deur die grense wat deur vertaling verskaffers. Ons is ook op soek na ander APIs wat deur vBET ondersteun word:) Ek het julle gestuur een of twee in 'n post wat jy geskrap as gevolg van die skakels wat jy kan aanpak, as jy wil' n beta-vrywilliger Ek is jou man:)

[vBET]

Ek het julle gestuur een of twee in 'n post wat jy geskrap as gevolg van die skakels wat jy kan aanpak, as jy wil' n beta-vrywilliger Ek is jou man:)

Jou boodskap was saggies verwyder, omdat die inhoud daarvan was advertensie wat geskryf is deur iemand anders, maar ons het toegang tot hierdie boodskap, en ons is dit:)

Ons het selfs al stuur vraag e-pos aan een van daardie vertalings verskaffers oor betaling besonderhede. Sommige van dié betaal (selfs wanneer dit word beskryf as dit nie is op die vlak van API - dieselfde ding wat jy het met Google jy kan vry vertaal deur leser, maar nie deur die API), maar die pryse mededingend te wees, so dit is nog steeds goed (meer mededinging beter pryse).
Sommige het ons 'n ondersoek, is dié werklik eksterne vertalings API of net plaaslike woordeboeke geskryf deur eie gebruikers (dit is ook een ding op ons TODO lys - toelaat om aan te pas en eie vertalings) - Radek het hierdie deel.

So ons is besig om vBET te verbeter en dit so goedkoop as moontlik in gebruik gemaak het:)

[vBET]

Ons is in die laaste stadiums van die tesing van nuwe funksionaliteit. Jy kan al sien verander beskrywing: http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.html # post8914 (sien laaste note)

[Simon Lloyd]

Dankie Michael, Ek het 'n vinnige post in die FAQ wat geen twyfel wat jy sal hê om te verwyder omdat sy nie die regte plek daarvoor:) As jy wil graag toets op aa live raad wat roep baie vertalings PM my en ek sal gee jy toegang tot admincp en forum wortel, ek het ook google vertaal limiet dat ek op en af op jou opdrag, sodat jy kan toets:)

[vBET]

OK so. Verskaffers queue geïmplementeer word en dit sal ingesluit word in vrystellings 3.5.1 en 4.4.3. vBET 3.5.1 sal vandag bekend gemaak word. vBET4.4.3 is nog in toets fase. Booth vrystellings sal word BETA sodat almal kan toets dit in groter forums dat die toets een. Neem asseblief kennis dat ons reeds die toets van 3.5.1 op een van ons regte forums. Tog is dit as gevolg van die belangrike veranderinge in beta fase.

[Simon Lloyd]

Is dit nodig om 'n geskeduleerde taak en' n bepaalde verskaffer afgeskakel vir 'n uur op' n slag?, Ek het 'n voorstel hier Omsendbrief nagaan en die skakel van die API's vloei van vertalings waar ons dalk kan altyd begin by die top van ons verskaffers te hou Noem en toets noem (soos die een wat u verskaf het Google reaksie en Microsoft reaksie te toets het) indien die toets oproep reaksie is 200 of teks is vertaal dat die verskaffer, indien die antwoord is nie 200 of toets teks is nie vertaal (met behulp van die dieselfde teks vir elke toets en die RegEx om seker te maak dat die vertaalde teks), dan skuif na die volgende verskaffer, elke vertaling oproep kan dan aan die bokant van die lys begin en werk af

Nie met 'n leë resultaat sal goed wees, want een keer het ons' n leë terugkeer dis hoe dit bly, ek het al het baie mense kla dat dit die geval is in my forum is.

[vBET]

Dit hoef nie so te wees nie, is dit nou. Dankie vir jou boodskap. - Nee. Dit het nie sin nie. Neem asseblief kennis dat die vra vir eksterne vertaling is meer tyd in beslag ding in die hele vBET (en dit is nie aan ons). Daar is geen sin om mal duisende versoek toe ons reeds bereik grense nie. Dit sou ook reaksie tyd, CPU verbruik en geheue gebruik verhogende (meer voorwerp geskep).

Ons het ontdek dat Google inligting oor waarskynlik misbruik TOS verdwyn na 'n tyd. Ons weet nie, maar miskien as ons dit sal bly vra wanneer ons reeds geblok, Google kan sluit vir meer tyd. Miskien nie, maar steeds werklike strategie is baie beter vir die prestasie. Aan die einde het jy 'n omsendbrief nagaan. As 'n mens nie beskikbaar is nie, dit is gemerk as nie beskikbaar nie en die ander gebruik word. As 'n ander nie beskikbaar is nie, dan gebeur dieselfde ding. Ons het net check nie, is dit weer beskikbaar is om elke versoek wat geen sin (dit miljoene navrae kan word voordat dit beskikbaar sal wees) het net een keer per uur. En as dit beskikbaar sal wees, sal dit my gemerk sodat ons sal terug gaan na voorkeur een - en jy het hier 'n sirkel. Ook die toets elke keer gemaak sal jou grense bereik vinniger of koste hoër as jy betaal vertalings (dit nog tel as die vertaling).
Ook ons is bereid om ander verskaffers te hê. Toe ons sal ondersteun meer as 2 so 'n strategie sal' n moordenaar vir jou bediener. Stel jou voor 5 toets oproepe na verskillende verskaffers en dan 'n werklike vertaling vir elke versoek om' n vertaling. No Dankie vir jou idee:) Ons het dit baie waardeer gebruikers idees, hierdie keer sal ons bly met die werklike oplossing.

Let asseblief daarop dat jy kan verander hoe dikwels vBET moet verskaffers beschikbaarheid. Nou is dit een per uur, maar jy kan dit weer instel wat in die Admin CP -> Geplande taken -> gelyste Task Manager en sit dit byvoorbeeld vir elke 10 minute 0 net soos taak RSS Plakkaat Robot doen dit nou.

[vBET]

Min verander - ons sal verskaffer beskikbaarheid check nie een keer per uur, maar elke 10 minute. As jy reeds opgegradeer om te vBET 3.5.1 voor hierdie boodskap laai net asseblief weer vBET pakket en oplaai produk lêer weer.

Die verandering is gemaak omdat ons op ons regte forum wat dikwels verskaffer beskikbaar is vir 'n kort tyd. Ons sal ondersoek instel om te kyk vir 'n ander verbeterings.

[Simon Lloyd]

Groot werk ouens:) Ek het opgegradeer na, maar sal die jongste fix aflaai en gebruik dit, sal ek 'n nuwe draad skep vir terugvoering oor hierdie.