Rundskriv kontroll og bytte av APIer for å holde flyten av oversettelser

[Simon Lloyd]

Jeg har min karakter grense for google satt til 100.000 perday så med mine innstillinger "Always Bruk Google", "Bruk Google API V2", "Bruk Google Detection" når jeg når denne grensen og ikke lenger få resultater fra betalte Google ville det være mulig for gratis APIer da begynne å produsere resultater?

Så for eksempel jeg bruker min forhåndsangitte grensen for Google og Google returnerer ikke lenger et resultatsett for meg (sannsynligvis returnerte en feilkode som de i programmeringskoden for Google-testen) når resultatet returneres ikke det ville være fint hvis vBET anerkjent automatisk feilkoden og sendte forespørsel til en annen API som Microsoft (eller noen andre som vBET senere støtter) på denne måten vi er sikker på å få noen resultatet - for meg dette ville være svært svært verdifull gitt at det er grenser selv med betalte versjoner, ville det tillate du å utvide grensene oversettelser.

f.eks
Google sette 100.000 Konferansenavnet per dag > brukt opp > vBET flytter til neste API i listen > Microsoft 400 k per time eller 4 M når grensen er nådd vBET av neste API og forrige for å se om grensen er opphevet, eller har noen godtgjørelsesbeviset > enten flytte til neste API eller tilbake til Google betalt når grensen er nådd igjen > sjekk neste API.... osv og så sirkulær sjekking etter får en feilkode vil bære, så ganske mye konstant muligheten til å ha oversettelser.

[vBET]

Jeg forstår din beskrivelse og poenget ditt. Nå må vi finne ut hvordan det anta å fungere teknisk.

Ett problem jeg ser her er hvordan vi skal innse at vi allerede har grenser tilgjengelig etter de der nådd før.

Vi kan ganske enkelt hver gang spør foretrukne leverandør og deretter gå til neste. Dette vil koste ytelse - fordi for hver forespørsel til side som krever oversettelse, vil vi gjort mislykket kall til foretrukne leverandør, deretter til neste en (slik at det kan være flere mislykkede samtaler når vBET vil støtte flere APIer).

Annen løsning ville være å lagre informasjon som foretrukket leverandør ikke er tilgjengelig, og gå direkte til neste. Dette ville være mye raskere, fordi sjekker lokal variabel er mye raskere enn å vente på svar fra ekstern server. Denne gangen vi har andre problem - vi vet ikke når foretrukket leverandør er tilgjengelig. Vi kan selvfølgelig gjort noen planlagt oppgave som ville be om enkle (korte) oversettelse for eksempel en gang per time / dag for å sjekke det. Så i denne strategien må vi bestemme hvor ofte standard slik oppgave anta å arbeide. Selvfølgelig ville vi sjekke det bare når noen leverandør er markert som ikke tilgjengelig.
Også hvis vi markerer tilbydere som utilgjengelig - hva de skal gjøre når vi vet at alle tilbydere er ikke tilgjengelig - legge til noen opplysninger for sluttbruker, eller bare oversette det som er i cache, og resten som originalen, uten ekstra info om midlertidig mangel på oversettelse tilbydere .

Uansett hvilken vei det vil bli gjort, vil Google bli behandlet som en API (v1 eller v2 avhengig av konfigurasjon) - det er ingen mening å splitte det, fordi Google v1 vil være stengt meget snart.

En annen ting er å tillate for å konfigurere leverandører-køen for hvert språk par separat. For øyeblikket kan vBET allerede for å konfigurere oversettelsesleverandør for hvert språk-par. Jeg tror at vi kan endre det fra én verdi til kommadelte verdier (CSV). På denne måten får vi vite for hvert språk par hvilke leverandører støtter denne oversettelsen og hva er innstillingene (bare rekkefølge på CSV-listen).

MERK: dette vil ha noen påvirkning på ytelsen uansett. Stedet for å opprette et objekt for oversettelse vil vi skape utvalg av slike gjenstander og ekstra innpakning objekt (for å gjøre den transparent for andre deler av koden og mindre bugs utsatt). Selvfølgelig vil vi ikke lage objekter for tilbydere vi vet ikke er tilgjengelig på dette øyeblikket.
Løsning for dette ville være å rekonfigurere for bedre ytelse og fjerne tilbydere kø - akkurat som det er akkurat nå - en leverandør per språk par.
Dette bør ikke være dyrt for ytelse, men likevel litt ekstra logikk og minneforbruk.

Vennligst fortell hvilken løsning er å foretrekke.

[vBET]

Og enda en potensiell løsning. Hvis vi vil markere hele API som ikke er tilgjengelig, og sjekke det ved planlagte oppgaven er den tilgjengelig nå, da vi ikke har å gjøre kø av tilbydere. Vi kan gjøre det på denne måten - alltid skapes bare ett oversetter objekt (bedre minnebruk) og i en forespørsel vi spør etter oversettelse kun én leverandør (bedre CPU). Hvis det skal ikke tilgjengelig, så vil det bli merket som ikke er tilgjengelig, og resultatene vil være tom (verst pålitelighet). Men bare første, fordi neste gang vil vi bruke en annen leverandør fra køen. Og i tilfelle hvis ingen leverandør er tilgjengelig, så dummy oversetter vil bli brukt - retur samme verdier (men ikke cache det) slik at noen deler vil ikke bli oversatt, men siden vil ikke ha tomme deler som nå når leverandøren ikke er tilgjengelig.

[vBET]

Bare rask kunngjøring - vi er allerede implementere denne funksjonen.

[Simon Lloyd]

Mine tanker var å sende sjekken oversettelse først for å se om foretrukket leverandør er tilgjengelig, slik at du ga oss kode for å sjekke om google eller MS svarer, så på tidspunkt for samtalen for oversettelse test googleapi (navnet mitt testfil med test-kode ) hvis oversettelsen er sant bruk preffered, hvis oversettelsen er flase eller kode er ikke 200 da prøve neste leverandør i listen, og utføre sitt api test før bruk.

Du kunne ha en listeboksen hvor brukeren kan listen hver leverandør en per linje i prioritert rekkefølge (dette gir når du legger til støtte for andre APIer brukeren kan bare legge dem til i listen), så min liste kan se slik ut:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Forutsatt dumme navnene jeg kom var reelle tilbydere, på vakt for oversettelse MS test kode ville kjøre, hvis responsen 200 bruke MS hvis ikke kjøre MyTranslator test kode, sjekk responsen for 200 hvis ja bruke den hvis ikke kjøre Google test kode **** ****** etc

På denne måten trenger du aldri å lagre noen informasjon om leverandører (ellers kan du ha tekstbokser der brukerne kan skrive inn sine sette grenser for hver leverandør men jeg tror denne informasjonen wuld være ubrukelig som de kunne forandre det og det ville bety mer å stikke innom og sjekke fram før en oversettelse) du aldri ville ha å bekymre deg hvis grensene ble tilgjengelig igjen så ikke behov for en cron jobb å kjøre for å sjekke disse, ville belastningen på serveren for at en liten oversettelse sjekk (koden du ga i FAQ) være ingenting.

Forhåpentligvis Jeg forklarte at ok, så du får min idé, tror jeg det kan alt gjøres bare ved at små sjekk og uten å lagre noe.

[Simon Lloyd]

Bare rask kunngjøring - vi er allerede implementere denne funksjonen.

Jeg sendte deg en eller to (i et innlegg du slettet på grunn av koblinger) som du kan tilnærming, hvis du ønsker en beta frivillig jeg din mann

[vBET]

Jeg sendte deg en eller to (i et innlegg du slettet på grunn av koblinger) som du kan tilnærming, hvis du ønsker en beta frivillig jeg din mann

Meldingen ble mykt slettet, fordi innholdet var reklame skrevet av noen andre, men vi har tilgang til denne meldingen og er vi på det

Vi har selv allerede sende spørsmålet email til en av disse oversettelsene leverandørene om betaling detaljer. Noen av disse er betalt (selv når det er beskrevet som gratis er det ikke på API-nivå - det samme du har med Google, kan du oversette gratis ved nettleser, men ikke av API), men prisene kan være konkurransedyktig, så det er fortsatt bra (mer konkurranse bedre priser).
Noen har vi undersøker er de virkelig eksterne oversettelser API eller bare lokale ordbøker som er skrevet av egne brukere (dette er også en ting på våre TODO liste - tillate å endre og sette egne oversettelser) - Radek har denne delen.

[vBET]

Vi er i siste stadier av tesing ny funksjonalitet. Du kan allerede se endrede beskrivelse: http://www.vbenterprisetranslator.co....html#post8914 (se siste NOTE)

[Simon Lloyd]

Takk Michael, jeg gjorde en rask post i at vanlige spørsmål som uten tvil vil du måtte fjerne fordi det er ikke riktig sted for det. Hvis du ønsker å teste på et live bord som kaller mange oversettelser PM meg og jeg skal gi deg tilgang til admincp og forum roten, jeg vil også sette google oversettelse grensen som jeg har satt opp og ned under din beherskelse slik at du kan teste

[vBET]

OK så. Leverandører-køen er implementert, og det vil bli inkludert i utgivelser 3.5.1 og 4.4.3 laste. vBET 3.5.1 vil bli lansert i dag. vBET4.4.3 er fortsatt i test-prøven. Booth utgivelser vil være BETA slik at alle kan teste det i større fora som tester en. Vær oppmerksom på at vi allerede er testing 3.5.1 på en av våre virkelige fora. Fortsatt på grunn av viktige endringer er det i BETA-stadiet først.