Cirkulär kontroll och byte av API: er för att hålla flödet av översättningar

[Simon Lloyd]

Jag har min begränsningen för Google in till 100.000 perday så med mina inställningar "Använd alltid Google", "Använd Googles API V2", "Använd Google Detection" När jag når den gränsen och inte längre få resultat från betalda Google skulle det vara möjligt gratis API sedan börja producera resultat?

Så till exempel jag använder mitt Google förinställd gräns och Google returnerar inte längre ett resultat för mig (förmodligen återvänder en felkod som i koden Google test) när resultatet returneras inte det skulle vara bra om vBET erkännas automatiskt felkoden och därefter skickas begäran till en annan API som Microsoft (eller alla andra att vBET senare stöder) detta sätt vi är förvissade om att få vissa resultat - det skulle vara mycket mycket värdefullt för mig med tanke på att det finns gränser även med betalda versioner, skulle det kan du utöka din översättningar gränser.

t.ex.
Google ange 100 000 tecken per dag > används > vBET flyttar till nästa API i listan > Microsoft 400 k per timme eller 4 M när gränsen nåtts vBET kryssrutan nästa API och tidigare se om gränsen hävs eller har några bidrag > flyttar till nästa API eller tillbaka till Google som betalas när gränsen nåtts igen > kontrollera nästa API.... osv så cirkulär kontroll efter mottar en felkod skulle bedriva, så pretty mycket konstant möjligheten att ha översättningar.

[vBET]

Jag förstår din beskrivning och dina poäng. Nu måste vi ta reda på hur det förmodar att fungera tekniskt.

En fråga som jag ser här är hur vi kommer att inse att vi redan har begränsningar som finns tillgängliga efter sådana där nått förut.

Vi kan helt enkelt varje gång be föredragna leverantören och sedan gå till nästa. Detta kommer att kosta prestanda - eftersom för varje begäran till sidan som kräver översättning, vi kommer att misslyckas anropet till önskad leverantör, sedan till nästa en (så att det kan vara flera misslyckade samtal när vBET kommer att stödja mer API: er).

Annan lösning skulle vara att lagra information som föredragna leverantören inte är tillgänglig och gå direkt till nästa. Detta skulle vara mycket snabbare, eftersom kontrollera lokala variabeln är mycket snabbare än att vänta på svar från extern server. Den här gången har vi andra problem - vi vet inte när föredragna leverantören finns tillgänglig. Vi kan naturligtvis gjort en del schemalagd aktivitet som skulle be om enkel (kort) översättning av exempelvis en gång per timme / dag för att kontrollera det. Så i denna strategi måste vi bestämma hur ofta som standard en sådan uppgift antar att arbeta. Vi skulle naturligtvis kolla det först när någon leverantör är markerat som saknas.
Även om vi markerar leverantörer som otillgänglig - vad man ska göra när vi vet att alla leverantörer finns inte - lägga till lite information för slutanvändaren eller bara översätter vad som finns i cachen och resten som originalet, utan någon ytterligare information om tillfällig avsaknad av översättning leverantörer .

Oavsett vilket sätt det kommer att ske, kommer Google att behandlas som ett API (v1 eller v2 beroende på konfiguration) - det finns ingen mening med att dela upp det, eftersom Google V1 kommer att stängas inom kort.

En annan sak är att konfigurera leverantörer kö för varje språkpar separat. Just nu kan vBET redan konfigurera översättningsprovider för varje språkpar. Jag tror att vi kan ändra det från ett värde till semikolonavgränsade värden (CSV). Detta sätt kommer vi att veta för varje språkpar vilka tjänsteleverantörer stöder denna översättning och vad är ordning inställningar (bara ordning på CSV lista).

OBS: Detta kommer att ha någon påverkan på prestanda ändå. Istället för att skapa ett objekt för översättning vi måste skapa utbud av sådana föremål och ytterligare emballage objekt (för att göra det transparent för andra delar av kod och mindre buggar benägna). Naturligtvis kommer vi inte att skapa objekt för leverantörer vi vet är inte tillgänglig just nu.
Lösning på detta skulle vara att konfigurera för bättre prestanda och avlägsna leverantörer kön - precis som det är just nu - en leverantör per språk par.
Detta bör inte vara dyrt för prestanda, men några ytterligare logik och minne konsumtion.

Tala om vilken lösning som är att föredra.

[vBET]

Och en möjlig lösning. Om vi kommer att markera hela API som inte finns och kontrollera den genom att schemalagd uppgift är det tillgängligt nu, så vi behöver inte göra kö av leverantörer. Vi kan göra det så här - alltid skapas bara en översättare objekt (bättre minne) och en begäran vi ber om översättning finns bara en leverantör (bättre CPU). Om det kommer inte vara tillgängliga, så kommer det att markeras som inte är tillgängliga och resultat kommer att vara tom (sämst tillförlitlighet). Men bara första, eftersom nästa gång vi kommer att använda en annan leverantör från kön. Och i fallet om ingen leverantör är tillgänglig kommer dummy översättare kommer att användas - retur samma värderingar (men inte cachen det) så vissa delar kommer inte att översättas, men sidan kommer inte att ha tomma delar ut nu när leverantören inte är tillgänglig.

[vBET]

Bara snabbt tillkännagivande - vi genomför redan den här funktionen.

[Simon Lloyd]

Mina tankar var att skicka kryssrutan översättningen först för att se om prioriterad leverantör är tillgänglig, så du gav oss kod för att kontrollera om google eller MS svarar, så vid tiden för samtal till översättning testet googleapi (namnet på min testfil med testa koden) om översättningen är sant använder preffered, om översättningen är flase eller koden inte är 200 och sedan försöker nästa leverantör i listan och utföra deras api test innan du använder.

Du kan ha en listruta där användaren kan ange varje provider en per rad i prioritetsordning (detta gör när du lägger till stöd för andra API användaren kan bara läggas till listan), så min lista skulle kunna se ut så här:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Antar daft namn jag angav var verkliga leverantörer, jour för översättning MS testa kod körs, om svar 200 använda MS om inte köra MyTranslator Provningsmetod, kontrollera svar för 200 om ja använda det om inte kör Google Provningsmetod ********** m.m.

Detta sätt som du aldrig behöver lagra all information på leverantörer (annars du kunde ha textrutor där användarna kan ange sina ange gränser för varje provider men jag tror att denna information wuld vara värdelös som de skulle kunna ändra den och det skulle innebära mer kontroll tillbaka och kontrollera fram innan gör en översättning) skulle du aldrig behöver oroa dig om gränser som var tillgängliga igen så behöver inte ett cron jobb för att köra för att kontrollera dessa, belastningen på servern för att en liten translation-check (koden du i FAQ) vore ingenting.

Jag förklarade förhoppningsvis ok så att du får min idé, tror jag det kan alla göras bara genom att små kontroll och utan att lagra något.

[Simon Lloyd]

Bara snabbt tillkännagivande - vi genomför redan den här funktionen.

Jag skickade en eller två (i en post som du har tagit bort på grund av länkarna) att du skulle kunna närma sig, om du vill att en beta volontär jag är din man

[vBET]

Jag skickade en eller två (i en post som du har tagit bort på grund av länkarna) att du skulle kunna närma sig, om du vill att en beta volontär jag är din man

Ditt meddelande togs försiktigt bort, eftersom dess innehåll var annons skrivna av någon annan, men vi har tillgång till detta meddelande och vi är på det

Vi skickar även redan fråga e-post till någon av dessa översättningar providers om betalningsinformation. Några av dem betalas (även när den beskrivs som fri det är inte på API nivå - samma sak som du har med Google kan du översätta gratis genom webbläsaren, men inte genom API), men priserna kan vara konkurrenskraftig, så är det fortfarande bra (mer konkurrens bättre priser).
Vissa vi måste undersöka är de verkligen externa översättningar API eller bara lokala ordlistor skriven av egna användare (detta är också en sak på vår TODO lista - tillåta att ändra och sätta egna översättningar) - Radek har denna del.

[vBET]

Vi är i sista stadierna av tesing nya funktioner. Du kan redan se ändrade beskrivning: http://www.vbenterprisetranslator.Co....html#post8914 (se sista NOT)

[Simon Lloyd]

Tack Michael, jag gjorde en snabb inlägg i det Faq där ingen tvekan om att du måste ta bort eftersom det inte rätt plats för det Om du vill testa på AA leva ombord som kräver många översättningar PM mig och jag ger dig tillgång till admincp och forum rot, kommer jag också lagt skrevs på gränsen att jag har upp och ner på ditt kommando så att du kan testa

[vBET]

OK så. Leverantörer kö genomförs och det kommer att ingå i utgåvor 3.5.1 och 4.4.3. vBET 3.5.1 kommer att släppas i dag. vBET4.4.3 är fortfarande i Testa scenen. Booth utgåvor kommer att BETA så alla kan testa det i större forum som testar en. Observera att vi redan testar 3.5.1 på en av våra verkliga forum. Fortfarande på grund av viktiga förändringar är i BETA-stadiet först.