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 have nogle indflydelse på ydeevnen alligevel. 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.

Vi vil frigive det hurtigt (som BETA) grund af fælles problemer forårsaget af lofter ved oversættelse udbydere. Vi ser også til andre API'er, der kan støttes med vBET:)

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

Vi vil frigive det hurtigt (som BETA) grund af fælles problemer forårsaget af lofter ved oversættelse udbydere. Vi ser også til andre API'er, der kan støttes med 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:)

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

Så vi arbejder på at forbedre vBET og gjort det som billig i brug som muligt:)

[vBET]

Vi er i sidste fase af tesing nye funktionalitet. Du kan allerede se ændrede beskrivelse: http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.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.

[Simon Lloyd]

Behøver det at være en planlagt opgave og én bestemt udbyder slået fra for en time på et tidspunkt?, jeg fremsatte et forslag her cirkulære kontrol og skifte af API'er til at holde strøm af oversættelser hvor måske vi kunne altid starter øverst på vores liste over udbydere og gøre teste opkald (ligesom du forudsat for at teste Google svar og Microsoft response) Hvis testen opkald svar er 200 eller tekst er oversat derefter bruge denne provider, hvis svaret er ikke 200, eller test tekst ikke er oversat (ved hjælp af den samme tekst til hver prøve og REGEX kontrollere den oversatte tekst) derefter flytte til næste udbyder, hvert oversættelse kald kan derefter starte øverst på listen og arbejde ned

Ikke have et tomt resultat ville være godt, fordi når vi har en tom tilbagevenden thats hvordan det fortsat, jeg allerede har haft mange mennesker klager over, at dette er tilfældet i min forum.

[vBET]

Det behøver ikke at være måde, det er lige nu. Tak for din note. Stadig - nr. Det har ingen mening. Bemærk venligst at bede om ekstern oversættelse er mere tidskrævende ting i hele vBET (og det er ikke op til os). Der er ingen mening i at mad tusindvis af anmodning, når vi allerede nå grænser. Dette ville increaser responstid, CPU forbrug og hukommelsesforbrug også (flere objekt oprettet).

Vi opdagede at Google oplysninger om sandsynligvis misbrug TOS forsvinder efter et stykke tid. Vi ved ikke, men måske hvis vi vil holde spørger når vi allerede er blokeret, Google kan blokere for mere tid. Måske ikke, men stadig faktiske strategi er meget bedre ydeevne. Ved udgangen har du cirkulære kontrol. Hvis ikke der findes det er markeret som ikke-tilgængelige og anden bruges. Hvis en anden ikke er tilgængelig derefter sker samme ting. Vi ikke kontrollerer blot, er den tilgængelig igen hver anmode hvad har ingen mening (det kan være millioner af forespørgsler, før det bliver tilgængeligt) én gang i timen. Og hvis det bliver tilgængeligt det vil mig markeret så vi vil gå tilbage til foretrukne én - og du har en cirkel her. Også test hver gang vil foretaget dine grænser, nåede hurtigere eller betalte omkostninger højere, hvis du bruger oversættelser (det stadig tæller som oversættelse).
Vi er også rede til også har andre udbydere. Når vi vil støtte mere end 2 vil sådan strategi være en morder til din server. Forestil dig 5 test opkald til forskellige udbydere og derefter reelle oversættelse for hver oversættelse anmodning. Nej. Tak for din IDE:) Vi værdsætter virkelig brugere idéer, denne gang, vi vil bo med faktiske løsning.

Bemærk, at du kan ændre, hvor ofte vBET skal kontrollere udbydere tilgængelighed. Nu er det én pr. time, men du kan omkonfigurere i Admin CP - > planlagte opgaver - > planlagt Jobliste og sæt det for eksempel for hvert 10 minut 0 ligesom opgave RSS plakat Robot gøre det nu.

[vBET]

Lille ændring foretaget - vi vil kontrollere udbyder tilgængelighed ikke én gang pr. time, men hvert 10 minut. Hvis du allerede har opgraderet til vBET 3.5.1 før denne meddelelse venligst blot hente vBET pakke igen og overføre produkt fil igen.

Ændringen blev foretaget, fordi vi blev fundet på vores virkelige forum der ofte provider er ikke tilgængelig for kort tid. Vi vil undersøge det mere til at søge en anden forbedringer.

[Simon Lloyd]

Store arbejde guys:), jeg har opgraderet til dette men vil hente de nyeste rettelse og brug, at jeg vil oprette en ny tråd for tilbagemelding på dette.