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 heeft een aantal invloed op de prestaties toch. In plaats van het creëren van een object voor de vertaling zullen we tal van dergelijke objecten en extra verpakking object (om het transparant te maken voor andere delen van de code en minder bugs gevoelig) te creëren. Natuurlijk zullen we niet maken objecten voor providers we weten niet beschikbaar zijn op dit moment.
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.

[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.

Ik stuurde je een of twee (in een bericht dat je geschrapt, omdat van de links) die u zou kunnen benaderen, als je wilt een beta-vrijwilliger ben ik je man

[vBET]

Ik stuurde je een of twee (in een bericht dat je geschrapt, omdat van de links) die u zou kunnen benaderen, als je wilt een beta-vrijwilliger ben ik je man

Uw bericht werd zachtjes verwijderd, omdat de inhoud is advertentie geschreven door iemand anders, maar we hebben toegang tot dit bericht en we zijn op het

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.

[vBET]

We zijn in de laatste fase van tesing nieuwe functionaliteit. U kunt nu al zien veranderd beschrijving: http://www.vbenterprisetranslator.co....html#post8914 (Zie laatste NOTE)

[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 kunt testen

[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.