Rundskriv kontroll og bytte av APIer for å holde flyten av 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.