Circular comprobación e intercambio de APIs para manter o fluxo de traducións

[Simon Lloyd]

Eu teño o meu límite de caracteres para definir a 100.000 google perday así coa miña configuración "Sempre usar Google", "Use Google API V2", "Use Detección Google" cando chegar a ese límite e non obter resultados a partir de Google paga sería posible APIs para libre entón comezar a producir resultados?

Tan para caso i utilizar o meu Google preset o límite e O Google xa non regresa un resultado para min (probabelmente regresando un código de erro como aqueles en o voso código de proba do Google) cando o resultado non é regresado o sería bo se vBET automaticamente recoñeceu o código de culpa e entón petición enviada a outro API como Microsoft (ou moi outros que vBET apoios máis tardíos) deste xeito é asegurado de conseguir algún resultado - para min isto sería moi moi valioso dado que hai límites mesmo con versións pagadas, deixaríache/deixaríate para estender os vosos límites de traducións.

por exemplo
conxunto de Google 100,000 Charcters polo día > utilizado por riba de vBET> movemento a API próximo en Microsoft > de lista 400k por hora ou 4M cando o límite logrou vBET control API próximo e anterior de ver se o límite é levantado ou ten algunha pensión > ningún movemento a API próximo ou atrás a Google pagou cando o límite logrou outra vez > comprobar API próximo....etc E así que o circular comprobando após recieving un código de erro levaría encima, tan bastante moito habilidade constante para ter traducións.

[vBET]

Eu entendo a súa descrición eo seu punto. Agora temos que descubrir como supoñer para traballar tecnicamente.

Un problema que vexo aquí é como imos recoñecer que xa temos límites dispoñibles despois aqueles onde chegou antes.

Pode sinxelamente cada vez preguntar provedor preferido e entón vai ao próximo un. Isto custará rendemento - porque para cada petición a páxina que require tradución, nós feito unsuccessful chamada a provedor preferido, entón a próximo un (así que pode ser varios unsuccessful chamadas cando vBET apoiará máis APIs).

Outra solución sería para almacenar informacións que os provedores preferente non está dispoñible e ir directamente a unha próxima. Iso sería moito máis rápido, porque a verificación variable local é moito máis rápido que esperar a resposta dun servidor externo. Esta vez temos outro problema - non sabemos cando o proveedor preferente está dispoñible. Por suposto, podemos fixo algunhas tarefa programada que solicitar a tradución (short) simple, por exemplo, unha vez por hora / día para verificalo. Así, nesta estratexia, temos que decidir cantas veces por defecto tal tarefa supoñer para traballar. Está claro que ía ocorrer lo só cando algún proveedor está marcado como non dispoñible.
Ademais, se marcados provedores como non dispoñible - o que facer cando sabemos que todos os provedores non están dispoñibles - engadir algunha información para o usuario final ou só traducir o que está na caché eo resto como orixinal, sen ningunha información adicional sobre a falta temporal de prestadores de tradución .

Non importa que forma que será feito, Google vai ser tratado como unha API (v1 ou v2, dependendo da configuración) - non ten sentido división la, porque Google v1 será pechado moi pronto.

Outra cousa é para deixar para configurar provedores queue para cada par de lingua @separately. Neste momento vBET xa deixa para configurar provedor de tradución para cada par de lingua. Pensa que pode mudalo dun valora a vírgula valores separados (CSV). Deste xeito saberemos para cada par de lingua que os provedores apoian esta tradución e o que son preferencias de orde (orde xusta en CSV lista).

COMPRACER NOTA: isto terá algún impacto de rendemento en todo caso. En vez de crear un obxecta para tradución teremos que crear variedade de tales obxectos e obxecto de envoltorio adicional (para facelo transparente para outras partes de código e menos bechos prone). Naturalmente non crearemos os obxectos para provedores saben non é dispoñíbel neste momento.
Solución para iso sería para reconfigurar para o mellor desenvolvemento e eliminar provedores de cola - así como é agora - un provedor os par de idiomas.
Isto non debe ser caro para o desempeño, pero aínda algunha lóxica adicional e consumo de memoria.

Por favor, diga cal é a solución preferida.

[vBET]

E unha solución potencial. Se vai marcar toda API como non dispoñibles e comprobar a tarefa programada é dispoñible agora, non hai que facer cola de provedores. Podemos facelo deste xeito - sempre é creado só un obxecto tradutor (mellor uso de memoria) e nun petición, solicitar a tradución só un provedor (CPU mellor). Se non estará dispoñible, entón ela será marcada como non dispoñibles e os resultados baleira (fiabilidade peor). Pero só un primeiro lugar, porque a próxima vez, imos empregar outro proveedor de cola. E no caso, se ningún proveedor está dispoñible, entón tradutor Dummy será usado - retornar os mesmos valores (pero non caché-lo) para algunhas partes non se traducidas, pero a páxina non terá partes baleiras, por exemplo, cando proveedor non está dispoñible.

[vBET]

Só anuncio rápida - xa estamos aplicando este recurso.

Queremos liberalo rápidos (como BETA) debido a asuntos comúns, causado polos límites postos por provedores de tradución. É tamén buscando outro APIs que pode ser apoiado por vBET :)

[Simon Lloyd]

Os meus pensamentos foron para enviar a tradución primeiro cheque a ver se provedor preferente está dispoñible, así que nos deu código para comprobar que Google ou MS responde, entón no momento da chamada para a tradución de proba googleapi (nome do meu arquivo de proba co seu código de proba ) a tradución é certo uso preffered, a tradución é flase ou o código non é 200 tente próximo proveedor da lista e faga o seu proba antes de usar api.

Podería ter un listbox onde o usuario pode incluír cada un provedor por liña en orde de preferencia (isto permite que cando engadir soporte para outras APIs o usuario pode simplemente poder engadilos á lista), entón a miña lista podería quedar así:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Supoñendo que os nomes foron inseridos Daft i provedores real, na chamada para a tradución de código de proba MS vai correr, se a resposta use MS 200 se non executar o código de comprobación MyTranslator, comprobar a resposta por 200 se si usalo se non executar Google código de proba **** ****** etc

Deste xeito vostede non ten que almacenar calquera información sobre os provedores (se non, podería ter caixas de texto onde os usuarios poderían entrar os seus límites fixados para cada provedor, pero eu creo que esta información wuld ser inútil xa que poderían mudala e iso significaría máis checo e comprobando fronte antes de facer unha tradución), vostede non tería que preocuparse os límites estaban dispoñibles de novo para que non é necesario un traballo cron para realizar a comprobación destes, a carga do servidor para comprobar que unha pequena tradución (o código indicado na FAQ) sería nada.

Espero ok explicou que en canto comeza a miña idea, eu creo que todo podería ser feito só por que o check pequenas e sen gardar nada.

[Simon Lloyd]

Só anuncio rápida - xa estamos aplicando este recurso.

Queremos liberalo rápidos (como BETA) debido a asuntos comúns, causado polos límites postos por provedores de tradución. É tamén buscando outro APIs que pode ser apoiado por vBET :)enviou te un ou dous (nun correo eliminou debido aos vínculos) que podería aproximarse, se quere un beta volunteer i son o voso home :)

[vBET]

Enviou te un ou dous (nun correo eliminou debido aos vínculos) que podería aproximarse, se quere un beta volunteer i son o voso home :)

A vosa mensaxe era suavemente eliminado, porque o seu contido era anuncio escrito por alguén máis, mais ten acceso a esta mensaxe e é nel :)

Nós ata xa mande unha mensaxe pregunta a un destes provedores de traducións sobre os detalles de pagamento. Algúns deses son pagados (aínda que el é descrito como libre non é a nivel de API - o mesmo que ten en Google pode traducir libre polo navegador, pero non por API), pero os prezos poden ser competitivos, polo que aínda é bo (prezos competencia mellor).
Alg investigar son aqueles realmente externo traducións API ou só dicionarios locais escrito por propios usuarios (iso tamén é unha cousa na nosa lista TODO - permiten modificar e poñer propias traducións) - Radek ten esa parte.

Tan é traballando para mellorar vBET e fíxoo tan barato en uso como posíbel :)

[vBET]

É en últimas etapas de tesing funcionalidade nova. Pode xa ver descrición mudada: http://www.vbenterprisetranslator.com/foro/vbet4-troubleshooting/413-faq-2.html#Correo8914 (ve última NOTA)

[Simon Lloyd]

Grazas Michael, i fixo un correo rápido en taht Faq cal sen dúbida terás que tirar porque o seu non o sitio correcto para el :) se gostaríache/gostaríate probar nun un vivir taboleiro que chama moito PM de traducións me e i'll dáche/dáte accede a admincp e raíz de foro, i tamén posto google límite de tradución que i montou e abaixo na vosa orde así que pode probar :)

[vBET]

OK Así que. Provedores queue é aplicado e será incluído en liberacións 3.5.1 e 4.4.3. vBET 3.5.1 será liberado hoxe. vBET4.4.3 é aínda en etapa de proba. Booth As Liberacións serán BETA tan todo o mundo pode probalo en foros máis grandes que proban un. Compracer nota que é xa probando 3.5.1 nun dos nosos foros reais. Aínda debido aos cambios importantes é en etapa de BETA primeiro.

[Simon Lloyd]

Necesita para ser unha tarefa planificada e un o provedor particular apagado para unha hora á vez?, i fixo unha suxestión aquí Circular comprobando e cambiando de APIs para manter fluxo de traducións onde quizais podería sempre inicio na parte superior da nosa lista de provedores e chamada de proba da marca (como o proporcionou para probar resposta de Google e resposta de Microsoft) se resposta de chamada da proba é 200 ou o texto é traducido entón uso que provedor, se a resposta non é 200 ou texto de proba non é traducido (utilizando o mesmo texto para cada proba e o REGEX para comprobar o texto traducido) entón movemento a provedor próximo, cada lata de chamada da tradución entón inicio na parte superior da lista e traballo abaixo

Non habendo un resultado baleiro sería bo porque unha vez ten un regreso baleiro thats como fica, i've xa tivo moitas persoas que se queixan que isto é o caso no meu foro.

[vBET]

Non ten que ser deste xeito, ten razón agora. Grazas Para a vosa nota. Aínda - ningún. Ten ningún sentido. Compracer nota que pedindo a tradución externa é máis o tempo que consome cousa en enteiro vBET (e é non até nosoutros). Non hai ningún sentido a milleiros tolos de petición cando xa logramos límites. Isto increaser tempo de resposta, consumo de CPU e consumo de memoria tamén (máis obxectar creado).

Descubriu que información de Google sobre probabelmente TOS de abuso desaparece após algún tempo. Non sabemos mais quizais se manteremos preguntar cando é xa bloqueado, Google pode bloquear para máis tempo. Quizais non, mais a estratexia real quieta é moito mellor para rendemento. Ao final ten circular comprobando. Se un non é dispoñíbel é marcado tan indispoñíbel e outro é utilizado. Se outro non é dispoñíbel entón a cousa mesma acontece. Xusto non comprobamos éo dispoñíbel outra vez cada un pide o que non ten ningún sentido (pode ser millóns de consultas antes de que será dispoñíbel) xusto unha vez por hora. E se será dispoñíbel o marcado tan volveremos a preferido un - e ten un círculo aquí. Tamén probando cada vez feito os vosos límites lograron máis rápidos ou custa máis alto se utiliza traducións pagadas (aínda conta tan tradución).
Tamén é preparado para ter outros provedores tamén. Cando apoiaremos máis que 2 tal estratexia será unha asasina para o voso server. Imaxina 5 probando chamadas a provedores diferentes e entón tradución real para cada petición de tradución. Non. Grazas Para a vosa idea :) realmente apreciamos ideas de usuarios, este tempo ficaremos con solución real.

Compracer nota que pode mudar como a miúdo vBET tería que comprobar dispoñibilidade de provedores. Agora é un por hora, mais pode reconfigure que en Admin CP -> Tarefas Planificadas -> Director de Tarefa Planificada e posto o por exemplo para cada 10 minutos 0 xusto como Robot de Cartel de RSS de tarefa el agora.

[vBET]

Pouco cambio feito - comprobaremos dispoñibilidade de provedor non unha vez por hora mais cada 10 minutos. Se ti xa upgraded a vBET 3.5.1 antes de que esta mensaxe comprace xusto descargar vBET paquete outra vez e upload ficheiro de produto outra vez.

O cambio foi feito porque atopou no noso foro real que a miúdo o provedor é indispoñíbel para tempo curto. Investigarémolo máis para buscar outras melloras.

[Simon Lloyd]

Traballo grande guys :), i ha upgraded a isto mais descargará o máis tardío arranxar e uso que, i creará un fío novo para feedback nisto.