Circular control i commutació de les API per mantenir el flux de les traduccions

[Simon Lloyd]

Jo tinc la meva límit de caràcters per google conjunt a 100.000 perday així que amb la meva configuració "Utilitza sempre el Google", "L'ús de Google API V2", "Ús de detecció de Google" quan arribi a aquest límit i ja no obtenir els resultats de pagament de Google seria possible per a les API lliure i comença a produir resultats?

Així, per exemple jo faig servir el límit preestablert de Google i Google ja no torna un resultat per a mi (probablement tornar un codi d'error com els del seu codi de prova de Google) quan el resultat no es torna seria bo si VBET servirà per identificar el codi d'error i envia sol.licitud a un altre API, com Microsoft (o qualsevol altre que VBET posterior admet) d'aquesta manera estem segurs d'aconseguir algun resultat - per a mi això seria molt valuós ja que hi ha límits, fins i tot amb versions de pagament, que li permetrà estendre els límits de la seva traducció.

per exemple,
Google conjunt 100.000 charcters per dia> utilitzat> moure VBET API següent a la llista de> 400K Microsoft per hora o 4 milions quan s'ha arribat al límit VBET API de comprovació següent i anterior per veure si el límit s'eleva o té algun marge> o bé passar a l'API que ve o a Google paga quan ha arribat al límit de nou> API de comprovació de la propera .... etc i pel que la comprovació de circular després de rebre un codi d'error podria portar a terme, la capacitat per a més o menys constant de tenir traduccions.

[vBET]

Jo entenc la seva descripció i el seu punt. Ara hem de esbrinar com se suposa que el treball tècnic.

Un problema que veig aquí és com anem a reconèixer que ja tenim límits disponibles després d'aquelles en les que va arribar abans.

Podem simplement cada vegada que demani al proveïdor preferit i després anar a la següent. Això tindrà un cost de rendiment - ja que per cada sol.licitud de pàgina que requereix la traducció, que es fa dir sense èxit als proveïdors preferits, i després a un costat (el que pot ser de diverses trucades sense èxit quan VBET donarà suport més API).

Una altra solució seria la d'emmagatzemar la informació que el proveïdor preferit no està disponible i anar directament a la següent. Això seria molt més ràpid, perquè la comprovació variable local és molt més ràpid que esperar la resposta des d'un servidor extern. Aquesta vegada tenim un altre assumpte - no sabem quan el proveïdor preferit està disponible. Podem, per descomptat, va fer una tasca programada que demanaria simple (curta) la traducció, per exemple, un cop per hora / dia per comprovar-ho. Així que en aquesta estratègia que hem de decidir amb quina freqüència per defecte aquesta tasca suposa per al treball. Per descomptat que ho comprovaria només quan un distribuïdor es marca com a no disponible.
A més, si es marca com a no disponible proveïdors - el que ha de fer quan sabem que tots els proveïdors no estan disponibles - afegir una mica d'informació per a l'usuari final o simplement traduir el que està en la memòria cau i la resta com a original, sense cap tipus d'informació addicional sobre la manca temporal de proveïdors de traducció .

No importa la forma en què es durà a terme, Google serà tractat com un API (v1 v2 o depenent de la configuració) - no té sentit per dividir-lo, ja que Google v1 es tancarà molt aviat.

Una altra cosa és que permeten configurar la cua dels proveïdors per a cada parell d'idiomes per separat. En aquest moment ja VBET permet configurar el proveïdor de traducció per a cada parell d'idiomes. Crec que podem canviar d'un valor als valors separats per comes (CSV). D'aquesta manera sabrem que per a cada parell d'idiomes que els proveïdors de suport a aquesta traducció i quines són les preferències d'ordre (ordre just a la llista CSV).

TINGUI EN COMPTE: això tindrà algun impacte en el rendiment de totes maneres. En lloc de crear un objecte de la traducció, haurem de crear la matriu d'objectes, i l'objecte embolcall addicional (perquè sigui transparent per a altres parts de codi i menys propensos a errors). Per descomptat no anem a crear objectes per als proveïdors sabem que no estan disponibles en aquest moment.
Solució per això seria tornar a configurar per a un millor rendiment i eliminar la cua dels proveïdors - com ho és ara - un proveïdor per parell d'idiomes.
Això no ha de ser car per al rendiment, però tot i així una mica de lògica addicional i el consum de memòria.

Si us plau, digui quina és la solució preferida.

[vBET]

I una solució més potencial. Si anem a marcar tota l'API com a no disponible i comprovar que en la tasca programada que està disponible, llavors no ha de fer la cua dels proveïdors. Podem fer-ho d'aquesta manera - sempre es crea un únic objecte traductor (millor ús de la memòria) i en una petició, demanar la traducció un sol proveïdor (millor CPU). Si no estarà disponible, llavors s'ha de marcar com no disponible i els resultats es buida (fiabilitat pitjor). Però només la primera, perquè la propera vegada anem a utilitzar un altre proveïdor de la cua. I en cas que cap proveïdor està disponible, traductor fictici s'utilitza - canvi els mateixos valors (però no la memòria cau) pel que algunes parts no es traduiran, però la pàgina no té parts buides, com ara, quan el proveïdor no està disponible.

[vBET]

Només anunci ràpid - ja estem aplicant aquesta funció.

El volem soltar ràpids (com BETA) a causa d'assumptes comuns, causat pels límits posats per proveïdors de traducció. També estem buscant altre APIs es poden recolzar quins per vBET

[Simon Lloyd]

Els meus pensaments van ser per a enviar la traducció primer xec per veure si el proveïdor preferit està disponible, de manera que ens va donar el codi per comprovar si Google o Microsoft està responent, de manera que en el moment de la convocatòria de prova de traducció googleapi (nom del meu arxiu de prova amb el codi de prova ) si la traducció és veritable ús preffered, si la traducció és flaixos o el codi no és 200, llavors tractar de proveïdor següent en la llista i fer la seva prova abans d'usar l'API.

Vostè podria tenir un quadre de llista on l'usuari pot llistar cada un d'ells pel proveïdor de línia en l'ordre de preferència (això permet que quan s'agrega compatibilitat amb API altres l'usuari només pot afegir a la llista), així que la meva llista podria ser el següent:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Suposant que els noms de ximple i ha entrat no són proveïdors reals, en l'anomenada per al codi de prova de traducció MS anava a córrer, si la resposta d'usar MS 200, si no executar codi MyTranslator prova, la resposta de per 200 en cas afirmatiu s'ha d'usar si no s'executa codi de Google prova **** ****** etc

D'aquesta manera vostè no haurà de emmagatzemar qualsevol informació sobre els proveïdors (en cas contrari podria haver quadres de text on els usuaris podien entrar en els límits establerts per a cada proveïdor, però crec que aquesta informació wuld ser inútils, ja que podria canviar i que significaria més control cap enrere i comprovar cap endavant abans de fer una traducció) que mai hauria de preocupar si els límits estaven disponibles de nou el que no necessita d'una tasca programada per executar-se a comprovar aquests, la càrrega en el servidor per comprovar que la traducció d'un petit (el codi proporcionat en el FAQ) seria res.

Espero que bé va explicar que perquè pugui obtenir la meva idea, crec que tot es podia fer amb només comprovar que la petita i sense emmagatzemar res.

[Simon Lloyd]

Només anunci ràpid - ja estem aplicant aquesta funció.

El volem soltar ràpids (com BETA) a causa d'assumptes comuns, causat pels límits posats per proveïdors de traducció. També estem buscant altre APIs es poden recolzar quins per vBET

Li vaig enviar una o dues (en una feina que ha eliminat a causa dels vincles) que podria acostar-se, si vols un voluntari beta sóc el teu home

[vBET]

Li vaig enviar una o dues (en una feina que ha eliminat a causa dels vincles) que podria acostar-se, si vols un voluntari beta sóc el teu home

El seu missatge ha estat eliminat en veu baixa, perquè el seu contingut era publicitat escrita per una altra persona, però no tenim accés a aquest missatge i estem en ell

Fins i tot ia enviar un correu electrònic pregunta a un dels proveïdors de traduccions sobre els detalls del pagament. Alguns d'ells són pagats (fins i tot quan es descriu com lliure no està en el nivell API - el mateix que vostè té amb Google pot traduir sense el navegador, però no per API), però els preus poden ser competitius, per la qual cosa segueix sent bona (més els preus de la competència millor).
Alguns hem investigar són els que veritablement externa traduccions API o simplement diccionaris locals escrit pels propis usuaris (és a dir també una cosa a la nostra llista de coses - que permet modificar i posar pròpies traduccions) - Radek ha aquesta part.

Així que estem treballant per millorar vBET i el va fer tan barat en ús tan possible

[vBET]

Estem en les últimes etapes de tesing nova funcionalitat. Ja es pot veure la descripció canviat: http://www.vbenterprisetranslator.co....html # post8914 (Veure l'últim NOTA)

[Simon Lloyd]

Gràcies Michael, vaig fer un post ràpid en taht Faq que sens dubte haurà de treure perquè seu no el lloc correcte per a això Si voleu participar com a prova en un Consell en viu que crida moltes traduccions PM me i vaig a donar accés a admincp i fòrum de root, també a posar límit de traducció de google que he posat cap amunt i cap avall a les seves ordres així pot provar

[vBET]

Acceptar així. Cua dels proveïdors es porta a terme i que s'inclourà en les versions 3.5.1 i 4.4.3. VBET 3.5.1 es donarà a conèixer avui. vBET4.4.3 es troba encara en fase de prova. Versions estand estarà BETA perquè tothom pugui provar en fòrums més amplis que posen a prova una. Tingueu en compte que ja estan provant 3.5.1 en un dels nostres fòrums real. No obstant això a causa dels canvis importants que es troba en fase BETA primer.