Circulaire controleren en schakelen van API's om stroom van vertalingen te houden

[Simon Lloyd]

Ik heb mijn tekenlimiet voor google ingesteld op 100.000 perday dus met mijn instellingen "Always Gebruik Google", "Gebruik Google API V2", "Gebruik Google Detection" Toen ik te bereiken dat de grens en niet meer te krijgen de resultaten van Google betaald zou het mogelijk zijn gratis API's en starten met het produceren van resultaten?

Zo bijvoorbeeld ik gebruik mijn vooraf ingestelde limiet van Google en Google niet langer een resultaat voor mij (waarschijnlijk een foutcode zoals die in uw Google test code retourneert) wanneer het resultaat wordt niet geretourneerd het zou goed zijn als vBET automatisch erkend de probleemcode en vervolgens verzoek naar een andere API als Microsoft verzonden (of alle andere dat vBET hoger ondersteunt) zo zijn we zeker op het krijgen van sommige resultaat - voor mij zou dit zeer zeer waardevol gezien het feit dat er grenzen zelfs met betaalde versies zijn, zou het u toestaan om uw vertalingen grenzen verleggen.

bv
Google instellen 100.000 Charcters per dag > opgebruikt > vBET verplaatsen naar volgende API in lijst > Microsoft 400 k per uur of 4 M wanneer limiet vBET selectievakje volgende API bereikt en voorafgaand aan zie als limiet wordt opgeheven of sommige uitkering heeft > hetzij verplaatsen naar volgende API of terug naar Google betaald als limiet opnieuw bereikt > volgende API.... controleren enz en zodat de circulaire controle na recieving een foutcode zou dragen op, zo mooi veel constante mogelijkheid om vertalingen.

[vBET]

Ik begrijp uw beschrijving en je punt. Nu moeten we om uit te vinden hoe het stel technisch werk.

Een kwestie die ik hier zien, is hoe wij erkennen dat wij nu al beperkt beschikbaar na die waar eerder bereikt hebben.

We kunnen gewoon elke keer vragen preferred provider en ga naar de volgende. Dit kost prestaties - omdat voor elke aanvraag pagina waarvoor de vertaling, zal daaraan mislukte oproepen naar voorkeur provider, dan naar de volgende een (dus het kan verschillende niet-geslaagde oproepen wanneer vBET meer API's steunen zal).

Andere oplossing zou zijn om informatie die preferred provider niet beschikbaar is op te slaan en direct naar volgende. Dit zou veel sneller, omdat het controleren van lokale variabele is veel sneller dan wachten op antwoord via een externe server. Deze keer hebben we andere kwestie - we weten niet wanneer preferred provider beschikbaar. We kunnen natuurlijk gemaakt een aantal geplande taak die eens zou voor eenvoudige (korte) vertaling voor bijvoorbeeld vragen per uur / dag om het te controleren. Dus in deze strategie moeten we beslissen hoe vaak standaard een dergelijke taak veronderstellen aan het werk. Natuurlijk zouden we controleren alleen wanneer een provider is gemarkeerd als niet beschikbaar.
Ook als we markeren aanbieders als onbeschikbaar - wat te doen als we weten dat alle aanbieders niet beschikbaar zijn - voeg wat informatie voor de eindgebruiker of gewoon vertalen wat er in cache en de rest als origineel, zonder enige extra informatie over tijdelijk ontbreken van de vertaling aanbieders .

Het maakt niet uit welke manier dit zal gebeuren, zal Google worden behandeld als een API (v1 of v2, afhankelijk van de configuratie) - er is geen zin om het te splitsen, omdat Google v1 zal zeer binnenkort worden gesloten.

Een ander ding is om aanbieders wachtrij voor elk paar taal afzonderlijk configureren. Op dit moment kunt vBET al configureren vertaling provider voor elk paar taal. Ik denk dat we het van één waarde door komma's gescheiden waarden (CSV veranderen kunnen). Op deze manier zullen we weten voor elk paar taal welke providers ondersteunen deze vertaling en wat zijn bestelling Voorkeuren (gewoon bestellen op CSV-lijst).

Let op: dit zal enige invloed op de prestaties hebben hoe dan ook. In plaats van het creëren van één object voor vertaling er array van dergelijke objecten en extra inwikkeling object (het transparant maken voor andere delen van code en minder bugs gevoelig) maken. We zullen natuurlijk niet objecten maken voor aanbieders die we weten op dit moment niet beschikbaar zijn.
Oplossing voor dit zou opnieuw te configureren voor betere prestaties en verwijder providers queue - net zoals het nu is - een provider per talencombinatie.
Dit moet niet duur te zijn voor de prestaties, maar nog steeds een aantal extra logica en geheugen verbruik.

Vertel welke oplossing de voorkeur heeft.

[vBET]

En nog een mogelijke oplossing. Als we hele API markeren als niet beschikbaar is en controleren door de geplande taak is het nu beschikbaar is, dan doen we niet in de rij van aanbieders te maken. We kunnen het op deze manier - altijd is gemaakt maar een vertaler object (beter geheugengebruik) en in een aanvraag kunnen wij om de vertaling slechts een provider (betere CPU). Als het zal niet beschikbaar zijn, dan wordt het gemarkeerd als niet beschikbaar en de resultaten zullen leeg zijn (slechtste betrouwbaarheid). Maar alleen eerste, want de volgende keer zullen we gebruik maken een andere provider uit de wachtrij. En in het geval als er geen provider beschikbaar is, dan dummy vertaler zal worden gebruikt - terug dezelfde waarden (maar niet in de cache) waardoor sommige delen niet worden vertaald, maar pagina zal niet leeg onderdelen zoals nu bij provider niet beschikbaar is.

[vBET]

Gewoon een snelle aankondiging - we zijn nu al de uitvoering van deze functie.

We willen het snel (als BETA) vrijgeven in verband met gemeenschappelijke problemen, veroorzaakt door grenzen van vertaling aanbieders. We zijn ook op zoek naar andere API's die kan worden ondersteund door vBET:)

[Simon Lloyd]

Mijn gedachten waren om de cheque te sturen vertaling eerst of preferred provider beschikbaar is, dus je gaf ons code om te controleren of Google of MS reageert, dus op tijd van de oproep voor de vertaling te testen googleapi (naam van mijn test-bestand met je test code ) als vertaling waar is gebruik preffered, als vertaling fals of code is niet 200 probeer dan de volgende provider in de lijst en voeren hun api te testen voor gebruik.

Je kon een keuzelijst waar de gebruiker kan elke provider een per regel lijst in volgorde van voorkeur hebben (dit staat wanneer u ondersteuning voor andere API's kan de gebruiker alleen maar toe te voegen aan de lijst), dus mijn lijst kan er als volgt uitzien:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Ervan uitgaande dat de daft namen die ik aangegaan waren echte providers, op afroep voor vertaling MS-test code zou lopen, als reactie 200 gebruik van MS, zo niet lopen MyTranslator testcode, respons te controleren op 200, zo ja gebruiken als niet uitgevoerd Google test code **** ****** enz.

Op deze manier hoeft u nooit enige informatie over aanbieders (anders zou je tekstvakken waarin gebruikers kunnen hun limieten invoeren voor elke provider, maar ik denk dat deze informatie wuld nutteloos zijn als ze konden veranderen en het zou betekenen dat er meer controle terug en het controleren op te slaan voorwaarts voor het maken van een vertaling) je nooit zou moeten maken als limieten werden weer beschikbaar dus geen noodzaak voor een cron job uit te voeren om deze te controleren, zou de belasting op de server voor die ene kleine vertaling te controleren (de code die u hebt opgegeven in de FAQ) worden niets.

Ik hoop dat ik dat goed uitgelegd, zodat je mijn idee, ik denk dat het kan allemaal gedaan worden enkel door die kleine te controleren en zonder op te slaan niets.

[Simon Lloyd]

Gewoon een snelle aankondiging - we zijn nu al de uitvoering van deze functie.

We willen het snel (als BETA) vrijgeven in verband met gemeenschappelijke problemen, veroorzaakt door grenzen van vertaling aanbieders. We zijn ook op zoek voor andere API's die kan worden ondersteund door vBET:) ik stuurde u een of twee (in een bericht u wegens de links geschrapt) dat u kan de aanpak, als u wilt dat een beta vrijwilliger i 'm your man:)

[vBET]

Ik stuurde u een of twee (in een bericht die u wegens de links geschrapt) dat u kan de aanpak, als u wilt dat een beta vrijwilliger i 'm your man:)

Uw bericht is zacht verwijderd, omdat de inhoud ervan advertentie geschreven door iemand anders was, maar we toegang tot dit bericht hebben en we op het zijn:)

We hebben zelfs al vragen sturen e-mail naar een van die vertalingen aanbieders over de betaling details. Sommige van deze zijn betaald (zelfs als het wordt beschreven als gratis is het niet op API-niveau - hetzelfde wat je met Google kunt u gratis vertalen door de browser, maar niet door API), maar de prijzen kunnen concurreren, dus het is nog steeds goed (meer concurrentie betere prijzen).
Sommige hebben we onderzoeken zijn die echt externe vertalingen API of gewoon de plaatselijke woordenboeken geschreven door de eigen gebruikers (dit is ook een ding op onze TODO lijst - te laten wijzigen en zet eigen vertalingen) - Radek heeft dit deel.

Dus we werken aan een verbetering van vBET en maakte het:) als goedkoop in gebruik mogelijk

[vBET]

Wij zijn in de laatste stadia van tesing nieuwe functionaliteit. U kunt al zien gewijzigde beschrijving: http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.html#post8914 (zie laatste noot)

[Simon Lloyd]

Bedankt Michael, ik maakte een snelle post in taht Faq die ongetwijfeld zul je verwijderen omdat zijn niet de juiste plaats voor het:) als u testen willen zou op een een levende board dat roept vele vertalingen PM me en ik u toegang tot wortel admincp en forum geven zal, zal ook ik google vertaling limiet die ik heb ingesteld op en neer op uw opdracht zodat u testen of kunt:)

[vBET]

OK dus. Aanbieders wachtrij wordt uitgevoerd en het zal worden opgenomen in releases 3.5.1 en 4.4.3. vBET 3.5.1 zal worden vrijgegeven vandaag. vBET4.4.3 is nog steeds in test fase. Booth versies zullen Bèta zodat iedereen het kan testen in grotere forums die test. Houd er rekening mee dat wij al 3.5.1 op een van onze echte forums testen. Nog steeds als gevolg van belangrijke veranderingen is het eerst in de BETA fase.

[Simon Lloyd]

Doet op nood voor een geplande taak worden en een bepaalde provider uitgeschakeld voor een uur op een moment?, maakte ik een suggestie hier circulaire controleren en schakelen van API's te houden stroom van vertalingen waar misschien we kunnen altijd beginnen op de top van onze lijst van aanbieders en maken testen of call (zoals de een u verstrekt aan test Google respons en reactie van Microsoft) als test oproep reactie 200 is of tekst is vertaald die provider gebruikt, als het antwoord niet 200 is of test tekst is niet vertaald (met behulp van dezelfde tekst voor elke test en de REGEX te controleren van de vertaalde tekst) dan verplaatsen naar volgende provider, elke vertaling oproep vervolgens kunt beginnen aan de bovenkant van de lijst en werk naar beneden

Niet met een leeg resultaat zou goed zijn, want als we eenmaal een lege terugkeer thats hoe blijft het, ik heb al veel mensen klagen dat dit het geval in mijn forum is.

[vBET]

Het hoeft niet te worden op deze manier, het is nu. Bedankt voor uw opmerking. Nog steeds - nee. Het heeft geen zin. Houd er rekening mee dat vraagt om externe vertaling meer tijd in beslag in hele vBET is (en het is niet aan ons). Er is geen zin om te gek van duizenden verzoek wanneer we al grenzen bereiken. Dit zou vermeerdering reactietijd, CPU verbruik en geheugenverbruik ook (meer object gemaakt).

We hebben ontdekt dat Google informatie over waarschijnlijk misbruik TOS verdwijnt na enige tijd. We weten niet, maar misschien als we blijven vragen zal wanneer wij al worden geblokkeerd, kan Google blokkeren voor meer tijd. Misschien niet, maar nog steeds werkelijke strategie is veel beter voor prestaties. Aan het eind heb je circulaire controleren. Als die niet beschikbaar is wordt deze gemarkeerd als niet-beschikbaar en een ander wordt gebruikt. Als een andere niet beschikbaar is dan hetzelfde gebeurt. We gewoon niet controleren is hij beschikbaar weer elk verzoeken wat heeft geen zin (het kan zijn miljoenen query's voordat het beschikbaar zal zijn) slechts een keer per uur. En als het beschikbaar zal zijn het zal me gemarkeerd zodat gaan we terug naar voorkeur één - en je hebt een cirkel hier. Ook testen elke keer zal je grenzen bereikt sneller gemaakt of kosten hoger als u betaalde vertalingen (het telt nog steeds als vertaling).
Wij zijn ook bereid om andere aanbieders te hebben. Wanneer wij meer dan 2 steunen zullen zullen dergelijke strategie een killer voor uw server. Stel je 5 testen oproepen naar verschillende aanbieders en vervolgens echte vertaling voor elke vertaalopdracht. Nr. Bedankt voor uw idee:) Wij zowaar zich opwaarderen gebruikers ideeën, deze keer die we met werkelijke oplossing verblijven zullen.

Houd er rekening mee dat u hoe vaak wijzigen kunt vBET aanbieders beschikbaarheid moet controleren. Nu is het een per uur, maar u kunt de configuratie die in Admin CP - > geplande taken - > geplande taak zetbaas en reeks het bijvoorbeeld voor elke 10 minuten 0 net als taak RSS Poster Robot doen nu.

[vBET]

Weinig gewijzigd - we zullen beschikbaarheid provider niet een keer per uur, maar elke 10 minuten. Als u al een naar vBET 3.5.1 voordat dit bericht upgrade gewoon download vBET pakket opnieuw en product bestand opnieuw te uploaden.

De wijziging is aangebracht omdat we op onze echte forum dat vaak gevonden provider is niet beschikbaar voor korte tijd. We zullen onderzoeken het meer op zoek naar een andere verbeteringen.

[Simon Lloyd]

Grote het werkkerels:), ik hierop een upgrade hebt uitgevoerd maar zal de laatste correctie en het gebruik dat, ik tot een nieuwe draad voor feedback op dit leiden zal downloaden.