PDA

View Full Version: Allerede gjort Rundskriv kontroll og bytte av APIer for å holde flyten av oversettelser



Simon Lloyd
04-10-11, 01:10
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
04-10-11, 09:28
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 innvirkning på ytelsen allikevel. Vi må opprette matrise av slike objekter og ekstra tekstbryting objektet (for å gjøre den gjennomsiktig for andre deler av kode og mindre feil utsatt) i stedet for å opprette ett objekt for oversettelse. Vi vil selvfølgelig ikke opprette objekter for leverandører som vi vet ikke er tilgjengelig for ø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
04-10-11, 18:23
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
04-10-11, 22:31
Bare rask kunngjøring - vi er allerede implementere denne funksjonen.

Vi ønsker å løsne det rask (som BETA) på grunn av vanlige problemer som er forårsaket av grenser angitt av oversettelse leverandører. Vi er også på utkikk etter andre APIer som kan støttes av vBET:)

Simon Lloyd
04-10-11, 22:36
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
04-10-11, 22:37
Bare rask kunngjøring - vi er allerede implementere denne funksjonen.

Vi ønsker å løsne det rask (som BETA) på grunn av vanlige problemer som er forårsaket av grenser angitt av oversettelse leverandører. Vi er også ute for andre APIer som kan støttes av vBET:) jeg sendt deg en eller to (i et innlegg du slettet på grunn av koblingene) at du kunne tilnærming, hvis du ønsker en beta frivillig jeg er din mann:)

vBET
04-10-11, 22:57
Jeg sendte deg en eller to (i et innlegg du slettet på grunn av koblingene) at du kunne tilnærming, hvis du ønsker en beta frivillig jeg er din mann:)

Meldingen ble sakte slettet, fordi innholdet var annonse som er skrevet av noen andre, men vi har tilgang til denne meldingen og vi er 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.

Så vi jobber for å forbedre vBET og gjorde det som billig i bruk som mulig:)

vBET
05-10-11, 13:52
Vi er i siste stadier av tesing ny funksjonalitet. Du kan allerede se endrede beskrivelse: http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.html#post8914 (se siste notat)

Simon Lloyd
05-10-11, 18:03
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
06-10-11, 00:50
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.

Simon Lloyd
06-10-11, 06:59
Betyr det må være en planlagt oppgave og en bestemt leverandør slått av på en time om gangen?, jeg laget et forslag her sirkulær sjekker og bytte av APIer for å holde flyten av oversettelser der kanskje vi kunne alltid starte på toppen av våre leverandører-listen og gjøre teste samtale (som du gitt for å teste Google svar og Microsoft svar) Hvis testen samtale svar er 200 eller tekst oversatt så bruk denne leverandøren, Hvis svaret er 200 eller test tekst blir ikke oversatt (ved hjelp av den samme teksten for hver test og REGEX for å sjekke den oversatte teksten) og flytte til neste leverandør, hvert oversettelse-kall kan deretter starte på toppen av listen og arbeid ned

Ikke å ha et tomt resultat ville være bra fordi når vi har en tom retur dvs hvordan det gjenstår, jeg har allerede hatt mange klager at dette er tilfelle i mitt forum.

vBET
06-10-11, 11:33
Det trenger ikke være på denne måten, er det akkurat nå. Takk for notatet. Fortsatt - Nei. Den har ingen mening. Oppmerksom Vær på at ber for eksterne oversettelse er mer tidkrevende ting i hele vBET (og det er ikke opp til oss). Det er ikke fornuftig å sint tusenvis av forespørsel når vi allerede nå grenser. Dette ville increaser svartid, forbruk av CPU og hukommelse fortæringen også (mer objekt som er opprettet).

Vi oppdaget at Google informasjon om sannsynligvis misbruk TOS forsvinner etter en tid. Vi vet ikke, men kanskje hvis vi vil holde spør når vi allerede er blokkert, Google kan blokkere for mer tid. Kanskje ikke, men fortsatt faktiske strategi er mye bedre for ytelse. På slutten har du sirkulær sjekker. Hvis en slik ikke finnes den er merket som utilgjengelig, og en annen som brukes. Hvis en annen ikke er tilgjengelige deretter hender likt ting. Vi bare ikke kontroller er det tilgjengelig igjen hver be hva har ingen mening (det kan være millioner av spørringer før den blir tilgjengelig) bare én gang per time. Og hvis det blir tilgjengelig vil det meg merket slik at vi vil gå tilbake til foretrukket en - og du har en sirkel her. Tester også hver gang ville gjort grensene nådd raskere eller kostnader som er høyere hvis du bruker betalt oversettelser (det fortsatt teller som oversettelse).
Også er vi forberedt på å ha andre leverandører også. Når vi vil støtte mer enn 2 vil slik strategi være en killer for serveren. Tenk deg 5 testing kall til ulike leverandører og deretter ekte oversettelse for hver oversettelse-forespørsel. nei. Takk for din idé:) Vi setter pris på brukere ideer, denne gangen skal vi bo med faktiske løsning.

Vær oppmerksom på at du kan endre hvor ofte vBET bør kontrollere tilgjengeligheten for leverandører. Nå det er en per time, men du kan rekonfigurere som i Admin CP - > planlagte oppgaver - > planlagt oppgave bestyrer og sett det for eksempel for hvert 10 minutt 0 akkurat som oppgave RSS plakat Robot gjøre det nå.

vBET
06-10-11, 13:34
Liten endring som er gjort - vi ville sjekk tilgjengelighet for leverandøren ikke en gang per time, men hvert 10 minutt. Hvis du allerede har oppgradert til vBET 3.5.1 før denne meldingen kan bare laste ned vBET-pakken på nytt og laste opp produktet filen på nytt.

Endringen ble gjort fordi vi funnet på vårt virkelige forum som ofte leverandøren er ikke tilgjengelig for kort tid. Vi vil undersøke det mer å se etter en annen forbedringer.

Simon Lloyd
06-10-11, 15:51
Flott arbeid fyrene:), jeg har oppgradert til dette men vil laste ned nyeste Fiks og bruk at, jeg vil opprette en ny tråd for tilbakemelding om dette.

Automatic Translations (Powered by Google, Microsoft®, Yandex, SDL Language Cloud, IBM Watson and Apertium):
AfrikaansAlbanianArabicBelarusianBulgarianCatalanChineseCroatianCzechDanishDutchEnglishEstonianFilipinoFinnishFrenchGalicianGermanGreekHaitian CreoleHebrewHindiHungarianIcelandicIndonesianIrishItalianJapaneseKoreanLatvianLithuanianMacedonianMalayMalteseNorwegianPersianPolishPortugueseRomanianRussianSerbianSlovakSlovenianSpanishSwahiliSwedishTaiwaneseThaiTurkishUkrainianVietnameseWelshYiddish
Translations supported by vB Enterprise Translator 4.10.1