PDA

Veure la Versió Completa: Ja fet Circular control i commutació de les API per mantenir el flux de les traduccions



Simon Lloyd
04-10-11, 01:10
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
04-10-11, 09:28
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).

NOTA: 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
04-10-11, 18:23
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
04-10-11, 22:31
Només anunci ràpid - ja estem aplicant aquesta funció.

Volem que l'alliberament ràpida (com beta), a causa de qüestions d'interès comú, causada pels límits imposats pels proveïdors de traducció. També estem buscant altres API que pot ser recolzat per VBET:)

Simon Lloyd
04-10-11, 22:36
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
04-10-11, 22:37
Només anunci ràpid - ja estem aplicant aquesta funció.

Volem que l'alliberament ràpida (com beta), a causa de qüestions d'interès comú, causada pels límits imposats pels proveïdors de traducció. També estem buscant altres API que pot ser recolzat per VBET:) m'ha enviat un o dos (en un lloc que ha eliminat a causa dels vincles) que podria acostar-se, si vols un voluntari beta sóc el teu home:)

vBET
04-10-11, 22:57
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 això:)

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 ho va fer tan barat com sigui possible en l'ús:)

vBET
05-10-11, 13:52
Estem en les últimes etapes de tesing nova funcionalitat. Ja es pot veure la descripció canviat: http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.html # post8914 (veure NOTA última)

Simon Lloyd
05-10-11, 18:03
Gràcies Michael, em va fer una entrada ràpida en què Faq que sens dubte haurà d'eliminar perquè no és el lloc correcte per a ella:) si vols posar a prova a bord aa viure que exigeix moltes traduccions me la tarda i vaig a donar l'accés a l'arrel admincp i el fòrum, jo també em va posar límit de traducció de Google que us he posat a dalt i cap avall a la seva disposició perquè pugui provar:)

vBET
06-10-11, 00:50
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.

Simon Lloyd
06-10-11, 06:59
¿Ha de ser una tasca programada i un proveïdor en particular, apagat durant una hora al mateix temps?, Vaig fer un suggeriment aquí Circular de xecs i canvi d'API per mantenir el flux de les traduccions, on potser podria començar sempre a la part superior dels nostres proveïdors llista i fer trucades de prova (com el que vostè sempre per provar la resposta de Google i la resposta de Microsoft) si la resposta de trucada de prova és de 200 o el text és traduït a continuació, utilitzar aquest proveïdor, si la resposta no és 200 o el text de prova no es tradueix (usant la mateixa de text per a cada prova i l'expressió regular per revisar el text traduït) després passar a següent proveïdor, cada trucada de traducció pot començar a la part superior de la llista i anar baixant

No tenir un resultat buit seria bo perquè un cop tenim un retorn buit això és el que queda, ja he tingut molta gent es queixa que aquest és el cas en el meu fòrum.

vBET
06-10-11, 11:33
No té per què ser així, és en aquests moments. Gràcies per la seva nota. No obstant això - no. No té cap sentit. Tingueu en compte que en demanar la traducció externa és més cosa de temps en VBET el seu conjunt (i no depèn de nosaltres). No té sentit a milers boig de la sol licitud quan ja s'assoleixen els límits. Això augmentador de temps de resposta, el consum de CPU i el consum de memòria també (més objecte creat).

Hem descobert que a Google informació sobre S abús probablement desaparegui després d'algun temps. No ho sé, però potser si anem a seguir fent quan ja estem bloquejats, Google pot bloquejar per més temps. Potser no, però l'estratègia actual és molt millor per al rendiment. Al final vostè té control circular. Si un no està disponible, es marca com a no disponible i l'altre s'utilitza. Si un altre no està disponible, passa el mateix. Simplement no veure que torna a estar disponible cada petició el que no té sentit (que pot ser de milions de consultes abans que sigui possible) només un cop per hora. I si es disposa d'ell em va marcar, així que tornarà a preferit - i vostè té un cercle aquí. També les proves cada vegada que es va fer arribar al seu límit més ràpid o major cost si s'utilitza traduccions pagats (encara compta com la traducció).
També estem preparats perquè altres proveïdors també. Quan anem a donar suport més de dues d'aquestes estratègies serà un assassí del seu servidor. Imagineu 5 trucades de prova a diferents proveïdors i després la traducció real de totes les consultes de traducció. No Gràcies a la seva idea:) Realment apreciem idees usuaris, aquest cop ens quedarem amb la solució real.

Tingueu en compte que pot canviar la freqüència VBET de comprovar la disponibilitat proveïdors. Ara és un per hora, però es pot configurar de nou que al CP Admin -> Tasques programades -> Administrador de tasques programades i la va posar, per exemple, per cada 10 minuts 0 igual que la tasca del cartell Robot RSS fer-ho ara.

vBET
06-10-11, 13:34
Pocs canvis fets - anem a comprovar la disponibilitat proveïdor no una vegada per hora, però cada 10 minuts. Si ja ha actualitzat a 3.5.1 VBET abans d'aquest missatge, només ha de descarregar el paquet VBET nou i carregar l'arxiu del producte nou.

El canvi es va fer pel fet que trobem en el nostre fòrum reals que sovint el proveïdor no està disponible per un curt temps. Anem a investigar més a mirar per a un altre millora.

Simon Lloyd
06-10-11, 15:51
Gran treball nois:), i s'han actualitzat a això, però es descarrega l'última solució i l'ús que vaig a crear un nou fil de comentaris sobre això.

Automatic Translations (Powered by Google, Microsoft®, Yandex, SDL Language Cloud, IBM Watson and Apertium):
AfrikaansAlbanianArabicBelarusianBulgarianCatalanChineseCroatianCzechDanishDutchEnglishEstonianFilipinoFinnishFrenchGalicianGermanGreekHaitian CreoleHebrewHindiHungarianIcelandicIndonesianIrishItalianJapaneseKoreanLatvianLithuanianMacedonianMalayMalteseNorwegianPersianPolishPortugueseRomanianRussianSerbianSlovakSlovenianSpanishSwahiliSwedishTaiwaneseThaiTurkishUkrainianVietnameseWelshYiddish
Thanks to vBET 4.10.1 you can enjoy automatic translations