Circulara control şi de comutare de API-uri pentru a menţine fluxul de traduceri

[Simon Lloyd]

Am limita mea de caractere pentru google stabilit la 100.000 de perday astfel cu setările mele "Se utilizează întotdeauna Google", "Utilizarea API Google V2", "Utilizarea Google Detection", atunci când am ajunge la această limită şi nu se mai obţine rezultate de la Google plătit ar fi posibil pentru API-uri gratuit apoi începe producerea de rezultate?

Astfel de exemplu folosesc limita presetate meu Google şi Google nu mai întoarce un rezultat pentru mine (probabil se întoarce un cod de eroare cum ar fi cele în codul de testare Google) când rezultatul nu este returnat ar fi bine dacă vBET recunoscute automat codul defectului şi apoi trimis solicitarea unui alt API cum ar fi Microsoft (sau orice alte persoane care vBET sprijină mai târziu) în acest fel putem sunt siguri de Noţiuni de bază unele rezultat - pentru mine, acest lucru ar fi foarte foarte valoroase având în vedere că există limite chiar cu versiunile plătite, aceasta ar permite să se extindă ti limitele de traduceri.

de exemplu,
Google Charcters 100.000 pe zi setat > folosit sus > vBET muta la următoarea API în lista > Microsoft 400 k pe oră sau 4 M când limita atins vBET selectare API următor şi anterior pentru a vedea dacă limita este ridicată sau are unele alocația > fie trece la următoarea API sau înapoi la Google plătite când limita de atinge din nou > Verificaţi următoarea API.... etc şi aşa verificarea circulară după recieving un cod de eroare ar transporta, deci destul de mult capacitatea de constantă a avea traduceri.

[vBET]

Am înţeles descrierea ta şi punctul dumneavoastră. Acum avem pentru a afla cum se presupune a lucra punct de vedere tehnic.

O problemă văd aici este modul în care vom recunoaşte că avem deja limitele disponibile după cele în care a ajuns înainte.

Puteţi pur şi simplu de fiecare dată cerem furnizorul preferat şi apoi atunci du-te la cea următoare. Acest lucru va costa performanţă - pentru că pentru fiecare cerere la pagina care necesită traducere, ne va făcut apel nereuşită la furnizorul preferat, apoi la următorul unul (aşa că poate fi mai multe apeluri nereuşite când vBET va sprijini API-uri mai mult).

Altă soluţie ar fi pentru a stoca informaţii că furnizorul preferat nu este disponibil si a merge direct la următoarea. Acest lucru ar fi mult mai rapid, deoarece verificarea variabile locale este mult mai rapid decât de aşteptare pentru un răspuns de la server extern. De data aceasta avem alta problema - nu ştim când furnizorul preferat este disponibil. Putem, desigur, a făcut unele activitate programata care s-ar cere pentru simplu (pe scurt) obţinute, de exemplu, o dată pe oră / zi pentru a verifica. Deci, în această strategie trebuie să decidem cât de des în mod implicit de activitate astfel să presupunem că la locul de muncă. Desigur, am l-ar verifica numai atunci când unele prestatorul este marcat ca nu este disponibilă.
De asemenea, dacă vom marca furnizorilor indisponibil - ce să fac atunci când ştim că toţi furnizorii nu sunt disponibile - adăugaţi câteva informaţii pentru utilizatorul final sau doar traduce ceea ce este în cache, iar restul ca versiunea originală, fără nici o informaţii suplimentare despre lipsa temporara de furnizorii de traducere .

Indiferent ce fel se va face, Google vor fi tratate ca un API (v1 sau v2, în funcţie de configuraţie) - nu există nici un sens să-l împărţi, deoarece Google V1 va fi închis foarte curând.

Un alt lucru este de a permite pentru a configura furnizorii coadă pentru fiecare pereche limbă separat. În acest moment vBET deja permite configurarea traducere furnizor pentru fiecare pereche limbă. Cred că putem schimba aceasta dintr-o singură valoare la valori separate prin virgulă (CSV). Acest fel va ştim pentru fiecare pereche limbă care furnizorii de sprijin această traducere şi ceea ce sunt ordinea Preferinţe (Ordinul doar pe lista CSV).

Vă rugăm să reţineţi: acest lucru va avea un impact asupra performanţei oricum. În loc de a crea un obiect pentru traducere vom avea pentru a crea matrice acestor obiecte și obiect suplimentare de încadrare (pentru a face transparente pentru alte piese de cod şi mai puţin de bug-uri predispus). Desigur nu vom crea obiecte pentru furnizorii ştim nu sunt disponibile în acest moment.
Soluţie pentru acest lucru ar fi să reconfiguraţi pentru performanţă mai bună şi eliminarea furnizorii de coadă - la fel ca ea este acum - un singur furnizor pentru fiecare pereche de limbi.
Acest lucru nu ar trebui să fie scump pentru performanţă, dar încă unele suplimentare de logică şi de consumul de memorie.

Vă rugăm să spuneţi ce soluţie este preferată.

[vBET]

Şi unul mai mult potenţial soluţie. Dacă vom marca API întregi, care nu sunt disponibile şi verificaţi-l de activitate programata este disponibil acum, atunci nu avem de a face coadă de furnizori. Putem face în felul acesta - întotdeauna este creat de un singur obiect traducator (utilizarea mai buna a memoriei) şi într-o singură cerere cerem obţinute de un singur furnizor (mai bună CPU). În cazul în care nu va fi disponibil, atunci acesta va fi marcat ca disponibile şi rezultatele nu vor fi goale (fiabilitate cel mai rău). Dar numai o în primul rând, pentru că data viitoare vom folosi un alt furnizor din coadă. Şi, în cazul în care furnizorul nu este disponibil, atunci traducator manechinului va fi utilizat - retur aceleaşi valori (dar nu-l cache), astfel încât unele părţi nu vor fi traduse, dar pagina nu vor avea piese de gol ca şi acum, când furnizorul nu este disponibil.

[vBET]

Doar anuntul rapidă - suntem de punere în aplicare deja această facilitate.

Vrem să-i elibereze rapid (ca BETA) datorită unor probleme comune, cauzate de limitele stabilite de către furnizorii de traducere. Suntem, de asemenea, în căutarea pentru alte API-uri care poate fi susţinută de vBET:)

[Simon Lloyd]

Gândurile mele au fost pentru a trimite traducerea verificaţi mai întâi pentru a vedea dacă furnizorul preferat este disponibil, asa ca ne-a dat codul pentru a verifica dacă Google sau MS răspunde, astfel încât în momentul de apel pentru traducere de testare googleapi (numele fişierului mea de test cu codul de test ) în cazul în care traducerea este utilizarea adevărat preferat, în cazul în care traducerea este flase sau cod nu este de 200 apoi încercaţi să furnizorul următor în listă şi de a efectua testele lor inainte de a folosi API-ul.

Ai putea avea un listbox în cazul în care utilizatorul poate listă fiecare un singur furnizor de pe linie, în ordinea preferinţei (aceasta permite, atunci când adăugaţi suport pentru API-urile alte utilizatorul poate doar să adăugaţi-le la lista), astfel încât lista mea ar putea arăta în felul următor:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Presupunând că numele tâmpit am intrat au fost furnizorii de reale, pe apel pentru codul de testul de traducere MS va rula, în cazul în care răspunsul folosi MS 200, dacă nu test cod MyTranslator, verificaţi de răspuns pentru 200 dacă da-l utilizaţi dacă nu rulaţi Google cod de încercare **** ****** etc

În acest fel nu trebuie să vă stoca orice informaţii privind prestatorii (altfel ai putea avea casete de text în care utilizatorii ar putea intra limitele lor stabilite pentru fiecare furnizor, dar cred că această informaţie wuld fi inutil ca acestea ar putea schimba şi ar însemna mai mult control înapoi şi verificarea transmite înainte de a face o traducere) pe care nu ar trebui să vă faceţi griji dacă limitele au fost disponibile din nou, deci nu este nevoie de un loc de muncă cron pentru a executa pentru a verifica aceste, sarcina pe server pentru a verifica faptul că o traducere mică (codul pe care îl prevăzute în FAQ) ar fi nimic.

Să sperăm că am explicat ca ok astfel încât să obţineţi ideea mea, cred ca ar putea fi efectuată doar prin faptul că a verifica mici şi fără stocarea nimic.

[Simon Lloyd]

Doar anuntul rapidă - suntem de punere în aplicare deja această facilitate.

Vrem să-i elibereze rapid (ca BETA) datorită unor probleme comune, cauzate de limitele stabilite de către furnizorii de traducere. Suntem, de asemenea, în căutarea pentru alte API-uri care poate fi susţinută de vBET:) am trimis una sau două (într-un post pe şters din cauza de link-uri) că aţi putea abordare, dacă doriţi o versiune beta voluntar eu sunt omul tău:)

[vBET]

Am trimis una sau două (într-un post pe şters din cauza de link-uri) că aţi putea abordare, dacă doriţi o versiune beta voluntar eu sunt omul tău:)

Mesajul a fost şters încet, deoarece conținutul său a fost publicitate scrise de altcineva, dar noi avem acces la acest mesaj şi suntem pe ea:)

Am deja chiar trimite e-mail întrebare la unul dintre aceste furnizorii de traduceri cu privire la detaliile de plată. Unele dintre acestea sunt plătite (chiar şi atunci când este descrisă ca liber nu este la nivel de API - acelasi lucru aveţi cu Google poţi traduce gratuit prin browser-ul, dar nu prin API), dar preţurile pot fi competitive, astfel încât este încă bine (preţuri mai bune de concurenţă).
Unele le-am investiga sunt cele cu adevărat externe traduceri API sau doar dicţionare locale, în scris de către utilizatori proprii (acest lucru este, de asemenea, un lucru pe lista de priorităţi - să permită să modifice şi să pună traduceri proprie) - Radek are această parte.

Deci ne sunt de lucru pentru a îmbunătăţi vBET şi a făcut ca ieftine în utilizarea posibil:)

[vBET]

Suntem în ultimele faze ale tesing noua funcţionalitate. Puteţi vedea deja schimbat Descriere: http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.html#post8914 (a se vedea nota ultima)

[Simon Lloyd]

Michael Multumesc, am făcut un post rapid în că Faq care fără îndoială veţi avea pentru a elimina deoarece nu sa locul corect pentru ea:) dacă doriţi pentru a testa pe o un bord vii care solicită multe traduceri PM-mă şi voi oferi acces la rădăcină admincp si forum, voi pune, de asemenea, google traducere limită care am stabilit sus şi în jos la comanda astfel încât puteţi testa:)

[vBET]

OK acest lucru. Furnizorii de coada este pusă în aplicare şi acesta va fi inclusă în versiunile 3.5.1 și 4.4.3. vBET 3.5.1 va fi lansat astăzi. vBET4.4.3 este încă în stadiu de testare. Booth lansări va fi BETA, astfel încât toată lumea să testaţi-l în forumuri mai mari care unul de testare. Vă rugăm să reţineţi că ne sunt testarea deja 3.5.1 pe una din forumurile noastre reale. Încă din cauza schimbări importante este în stadiu BETA prima.

[Simon Lloyd]

Ea are nevoie să fie o activitate programată şi un singur furnizor special dezactivat pentru o oră la un moment dat?, am făcut o sugestie aici Circular de verificare şi de comutare de API-uri pentru a menţine fluxul de traduceri în cazul în care probabil am putea întotdeauna încep de la partea de sus a lista noastră furnizori şi face testul apel (cum ar fi unul tu furnizate pentru a testa răspuns Google şi Microsoft răspuns) dacă testul apel răspunsul este de 200 sau textul este tradus apoi utilizaţi acel furnizor, dacă răspunsul nu este 200 sau textul de testare nu este tradus (folosind acelaşi text pentru fiecare test şi REGEX pentru a verifica textul tradus) apoi trece la următoarea furnizor, fiecare apel de traducere poate apoi începe în partea de sus a listei şi să lucreze în jos

Neavând un gol rezultat ar fi bine pentru că odată ce avem o thats de întoarcere gol cum ramane, am avut deja mulţi oameni plângându-se că acest lucru este în cazul în forumul meu.

[vBET]

Nu trebuie să fie în acest fel, este chiar acum. Multumesc pentru notă. Încă - nu. Ea are nici un sens. Vă rugăm să reţineţi că asking pentru traducere externe este mai consumatoare de timp de lucru în vBET întregi (şi nu este până la noi). Nu există nici un sens pentru a supărat mii de cereri când ajungem deja limitele. Acest lucru ar increaser răspuns timp, consumul de CPU și memorie ocupat, de asemenea, (mai multe obiect creat).

Am descoperit că Google informaţii despre abuz, probabil, TOS dispare după o perioadă de timp. Noi nu ştim, dar poate că dacă ne va tot intrebi atunci când am sunt blocat deja, Google poate bloca pentru mai mult timp. Poate nu, dar strategia încă reală este mult mai bine pentru performanta. La sfârşitul aveţi controlul circulară. În cazul în care una nu este disponibilă este marcat ca indisponibile şi altul este utilizat. Dacă un alt nu este disponibil apoi acelaşi lucru întâmplă. Am doar verifica este aceasta disponibile din nou fiecare solicita ce are nici un sens (acesta poate fi milioane de interogări, înainte de a va fi disponibil) doar o dată pe oră. Şi dacă acesta va fi disponibil va ma marcate astfel încât vom merge înapoi la unul preferat - şi aveţi un cerc aici. Testarea, de asemenea, de fiecare dată va face ti limitele ajuns mai repede sau costurile mai mari dacă utilizaţi plătite traduceri (este încă contează ca traducere).
De asemenea, suntem pregătiţi să aibă alţi furnizori prea. Când vom susţine mai mult de 2 astfel de strategie va fi un criminal pentru server. Imaginaţi-vă apelurile testare 5 furnizorii de diferite şi apoi reale traducere pentru fiecare cerere de traducere. nu. Vă mulţumim pentru ideea ta:) Apreciem într-adevăr utilizatorii idei, de această dată ne va sta cu soluţie reală.

Vă rugăm să reţineţi că aveţi posibilitatea să modificaţi frecvenţa vBET ar trebui să verificaţi disponibilitatea furnizori. Acum este unul pe oră, dar vă puteţi reconfigura în Admin CP - > Activităţi programate - > programată Task Conducător şi set de exemplu pentru fiecare 10 minute 0 la fel ca activitate RSS Poster Robot face it acum.

[vBET]

Modificare pic - vom verifica disponibilitatea furnizorul nu o dată pe oră, dar fiecare 10 minute. Dacă aveţi deja upgraded la spre vBET 3.5.1 înainte de acest mesaj vă rugăm să doar să descărcaţi vBET pachet din nou şi încărcaţi fişierul produs din nou.

Schimbarea a fost făcut pentru că am gasit pe forumul nostru reale care de multe ori furnizorul nu este disponibilă pentru scurt timp. Am va investiga mai mult pentru a căuta un alt îmbunătăţiri.

[Simon Lloyd]

Baieti mare lucru:), am au actualizat la acest dar va descărca cele mai recente fix şi utilizarea, va crea un thread nou pentru feedback-ul pe acest.