Cirkulære kontrol og skift af API'er til at holde strøm af oversættelser

[Simon Lloyd]

Jeg har mine tegngrænsen for google indstillet til 100.000 perday så med mine indstillinger "Brug altid Google", "Brug Google API V2", "Brug Google Detection", når jeg når denne grænse og ikke længere få resultater fra betalte Google ville det være muligt gratis API'er derefter begynde at producere resultater?

For eksempel jeg bruge min Google forudindstillet grænse og Google returnerer ikke længere et resultat for mig (sandsynligvis returnerer en fejlkode som dem i din Google test code) når resultatet ikke returneres det ville være godt, hvis vBET automatisk anerkendes fejlkoden og derefter sendt anmodning til en anden API ligesom Microsoft (eller eventuelle andre at vBET senere understøtter) denne måde vi er sikre på at få nogle resultat - for mig ville det være meget meget værdifulde Eftersom der findes grænser selv med betalt versioner, ville det give du udvide dine oversættelser grænser.

fx
Google angive 100.000 Charcters pr. dag > brugt op > vBET flytter til næste API i listen > Microsoft 400 k pr. time eller 4 M når grænsen er nået vBET afkrydsningsfeltet næste API og tidligere til se hvis grænse er ophævet eller har nogle kvoter > enten flytte til næste API eller tilbage til Google betalt, når grænsen er nået igen > kontrollere næste API.... osv og så den cirkulære kontrol efter recieving en fejlkode ville bære, så temmelig meget konstant muligheden for at have oversættelser.

[vBET]

Jeg forstår din beskrivelse og dit punkt. Vi skal nu finde ud af, hvordan det Antag arbejde teknisk.

Et spørgsmål jeg se her er, hvordan vi vil anerkende, at vi allerede har grænser tilgængelige efter dem, hvor nået før.

Vi kan blot hver gang bede, foretrukne udbyder og derefter gå til den næste. Dette vil koste ydeevne - fordi for hver anmodning til side, som kræver oversættelse, vil vi gjort forgæves opkald til foretrukne udbyder, derefter til næste én (så det kan være flere mislykkede opkald, når vBET vil støtte flere API'er).

Anden løsning ville være at gemme oplysninger om den foretrukne udbyder ikke er tilgængelig og gå direkte til næste én. Dette ville være meget hurtigere, fordi kontrol lokale variabel er meget hurtigere end venter på svar fra ekstern server. Denne gang har vi andre spørgsmål - kender vi ikke når foretrukne udbyder er tilgængelig. Vi kan naturligvis gjort nogle planlagte opgave, som vil bede for eksempel for enkel (korte) oversættelse én gang pr. time pr. dag checke det. Så har vi i denne strategi at beslutte hvor ofte som standard sådan opgave Antag for at arbejde. Naturligvis ville vi kontrollere det kun når nogle udbyder er markeret som ikke tilgængelige.
Hvis vi markerer udbydere som ikke-tilgængelig - er hvad du skal gøre, når vi ved, at alle udbydere ikke er tilgængelige - tilføje nogle oplysninger for slutbrugeren eller blot oversætte hvad også i cache og resten som oprindelige, uden nogen yderligere info om midlertidig mangel på oversættelse udbydere.

Uanset, hvordan det vil blive gjort, Google vil blive behandlet som én API (v1 eller v2 afhængigt af konfiguration) - der er ingen mening at opdele det, fordi Google v1 vil blive lukket meget snart.

En anden ting er at tillade for at konfigurere udbydere kø for hvert sprog par separat. I dette øjeblik tillader vBET allerede for at konfigurere oversættelsesudbyder for hvert sprog par. Jeg tror, at vi kan ændre det fra én værdi til kommaseparerede værdier (CSV). Denne måde, vi vil vide for hvert sprog par hvilke providere understøtter denne oversættelse, og hvad er ordre indstillinger (kun bestilles på CSV-liste).

BEMÆRK: Dette vil alligevel har nogle indflydelse på ydeevnen. I stedet for at oprette ét objekt for oversættelse vil vi oprette matrix af sådanne objekter og yderligere indpakning objekt (at gøre den gennemsigtig for andre dele af koden og mindre bugs tilbøjelige). Naturligvis vil vi ikke oprette objekter for udbydere bekendt ikke er tilgængelige i øjeblikket.
Løsning til dette ville være at omkonfigurere bedre ydeevne og fjerne udbydere kø - ligesom det er lige nu - én udbyder pr. sprog par.
Dette bør ikke være dyrt for ydeevne, men stadig nogle yderligere logik og hukommelsen forbrug.

Fortæl, hvilken løsning foretrækkes.

[vBET]

Og én flere potentielle løsning. Hvis vi vil markere hele API som ikke tilgængelig og kontrollere det af planlagt opgave er det tilgængelige nu, derefter behøver vi ikke at gøre kø af udbydere. Vi kan gøre det dette måde - altid oprettes kun én oversætter objekt (bedre hukommelsesforbrug) og i én anmodning anmoder vi om oversættelse kun én udbyder (bedre CPU). Hvis det ikke vil være tilgængelige, så det vil blive markeret som ikke tilgængelige og resultater vil være tom (værste pålidelighed). Men kun første, fordi næste gang vi vil bruge en anden provider fra køen. Og i tilfældet hvis nogen provider er tilgængelig, derefter prøvedukkens oversætter vil blive brugt - returnere samme værdier (men ikke cachelagre det) så nogle dele ikke bliver oversat, men siden vil ikke have tomme dele som nu når provideren er ikke tilgængelig.

[vBET]

Lige hurtig meddelelse - vi gennemfører allerede denne funktion.

[Simon Lloyd]

Mine tanker var at sende afkrydsningsfeltet oversættelsen først at se hvis foretrukne udbyder er tilgængelig, så du gav os at kontrollere hvis google eller MS svarer, så på tidspunktet for opkaldet til oversættelse test googleapi (navnet på min test-fil med din test code) Hvis oversættelse er sand brug foretrukne, hvis oversættelse er flase eller kode er ikke 200 og derefter forsøge næste udbyder på listen og udføre deres api test før ved hjælp af kode.

Du kan have en listbox hvor brugeren kan angive hver udbyder, én pr. linje i prioritetsorden (tillader når du tilføje understøttelse til andre API'er brugeren kan lige føje dem til listen), så min liste kunne ligner dette:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Hvis antager daft navnene i trådte var virkelige udbydere, on call for oversættelse MS test kode ville køre, hvis svar 200 brug MS hvis ikke køre MyTranslator test code, kontrollere svar for 200 Hvis ja bruge det ikke køre Google test kode ********** osv

Denne måde du aldrig har til at gemme alle oplysninger om udbydere (ellers du kunne have tekst bokse hvor brugerne kunne angive deres sæt grænser for hver udbyder, men jeg tror, denne oplysninger wuld være ubrugelig, som de kunne ændre det og det ville betyde mere kontrol tilbage samt kontrol af frem før at foretage en oversættelse) du vil aldrig få at bekymre dig hvis grænser var tilgængelige ikke behov for en cron igen så job skal køres for at kontrollere disse, belastningen på server for at én lille oversættelse check (den kode, du angav i FAQ) ville være intet.

Jeg forklarede forhåbentlig at ok, så du få min idé, jeg tror det kunne alle gøres blot ved at små afkrydsningsfeltet og uden lagring af noget.

[Simon Lloyd]

Lige hurtig meddelelse - vi gennemfører allerede denne funktion.

Jeg sendte dem et eller to (i en post du slettes på grund af hyperlinks) at du kunne nærme sig, hvis du ønsker en beta frivillige jeg er din mand

[vBET]

Jeg sendte dem et eller to (i en post du slettes på grund af hyperlinks) at du kunne nærme sig, hvis du ønsker en beta frivillige jeg er din mand

Din meddelelse blev softly slettet, fordi dens indhold var annonce skrevet af en anden, men vi har adgang til denne meddelelse og vi er på det

Vi sender selv allerede spørgsmål e-mail til en af disse oversættelser udbydere om betalingsoplysninger. Nogle af dem er betalt (selv når det er beskrevet som værende fri det er ikke på API niveau - samme ting du har med Google du kan oversætte fri af browseren, men ikke af API), men priser kan være konkurrencedygtige, så det er stadig godt (mere konkurrence bedre priser).
Nogle vi har undersøge er disse virkelig eksterne oversættelser API eller blot lokale ordbøger skrevet af egne brugere (dette er også én ting på vores gøremålsliste - gør det muligt at redigere og sætte egne oversættelser) - Radek har denne del.

[vBET]

Vi er i sidste fase af tesing nye funktionalitet. Du kan allerede se ændrede beskrivelse: http://www.vbenterprisetranslator.co....html#post8914 (se sidste NOTE)

[Simon Lloyd]

Tak Michael, jeg fremsatte en hurtig stilling i at Faq, som uden tvivl vil du skal fjerne fordi dens ikke det korrekte sted for det Hvis du vil gerne teste på en en levende bestyrelsen, der kalder mange oversættelser PM mig og jeg giver dig adgang til admincp og forum rod, jeg vil også sætte google oversættelse grænse, som jeg har sat op og ned på din kommando, så du kan teste

[vBET]

OK så. Udbydere kø er gennemført, og det vil blive medtaget i udgivelser 3.5.1 og 4.4.3. vBET 3.5.1 vil blive frigivet i dag. vBET4.4.3 er stadig i testen fase. Booth udgivelser vil være BETA, så alle kan teste det i større fora at teste en. Bemærk venligst at vi allerede tester 3.5.1 på en af vores reelle fora. Stadig grund af vigtige ændringer er det i BETA fase først.