Circular control y conmutación de las API para mantener el flujo de las traducciones

[Simon Lloyd]

Yo tengo mi límite de caracteres para google conjunto a 100.000 perday así que con mi configuración "Usar siempre el Google", "El uso de Google API V2", "Uso de detección de Google" cuando llegue a ese límite y ya no obtener los resultados de pago de Google sería posible para las API libre y comienza a producir resultados?

Así por ejemplo yo uso mi límite preestablecido de Google y Google ya no devuelve un resultado para mí (probablemente devolver un código de error como en el código de prueba de Google) cuando se devuelve el resultado no sería bueno si vBET reconoce automáticamente el código de error y luego envió solicitud a otra API como Microsoft (o cualquier otros más tarde admite que traducido) de esta manera estamos seguros de conseguir algún resultado, para mí sería muy muy valiosa Dado que hay límites, incluso con versiones de pago, que permiten extender sus límites de traducciones.

por ejemplo,
Google establece 100.000 características por día > consumido > vBET mover al siguiente API en lista > Microsoft 400 k por hora o 4 M cuando alcanza el límite vBET verificación API siguiente y anterior a ver si el límite es el levantamiento o tiene algún subsidio > bien mover a API próximo o a Google pagada cuando se alcanza el límite de nuevo > comprobar siguiente API.... etc. y así la comprobación circular después de recibir un código de error llevaría, tan lindas mucha posibilidad constante de tener traducciones.

[vBET]

Yo entiendo su descripción y su punto. Ahora tenemos que averiguar cómo se supone que el trabajo técnico.

Un problema que veo aquí es cómo vamos a reconocer que ya tenemos límites disponibles después de aquellas en las que llegó antes.

Nos podemos preguntar simplemente cada vez proveedor preferido y, a continuación, vaya al siguiente. Esto costará rendimiento - porque para cada solicitud de página que requiere traducción, hicimos llamada éxito al proveedor preferido, entonces al siguiente uno (lo que puede ser varias llamadas infructuosas cuando vBET apoyará API más).

Otra solución sería la de almacenar la información que el proveedor preferido no está disponible e ir directamente a la siguiente. Esto sería mucho más rápido, porque la comprobación variable local es mucho más rápido que esperar la respuesta desde un servidor externo. Esta vez tenemos otro asunto - no sabemos cuando el proveedor preferido está disponible. Podemos, por supuesto, hizo una tarea programada que pediría simple (corta) la traducción, por ejemplo, una vez por hora / día para comprobarlo. Así que en esta estrategia que tenemos que decidir con qué frecuencia por defecto dicha tarea supone para el trabajo. Por supuesto que lo comprobaría sólo cuando algún proveedor se marca como no disponible.
Además, si se marca como no disponible proveedores - lo que debe hacer cuando sabemos que todos los proveedores no están disponibles - añadir un poco de información para el usuario final o simplemente traducir lo que está en el caché y el resto como original, sin ningún tipo de información adicional acerca de la falta temporal de proveedores de traducción .

No importa la forma en que se llevará a cabo, Google será tratado como un API (v1 v2 o dependiendo de la configuración) - no tiene sentido para dividirlo, ya que Google v1 se cerrará muy pronto.

Otra cosa es permitir configurar colas de proveedores para cada par de idiomas por separado. En este momento traducido ya permite para configurar proveedores de traducción para cada par de idiomas. Creo que podemos cambiarlo de un valor de valores separados por comas (CSV). Así sabremos para cada par de idiomas que proveedores admiten esta traducción y cuáles son las preferencias de orden (orden justo en lista CSV).

TENGA EN CUENTA: esto tendrá algún impacto en el rendimiento de todos modos. En lugar de crear un objeto de la traducción, tendremos que crear la matriz de objetos, y el objeto envoltorio adicional (para que sea transparente para otras partes de código y menos propensos a errores). Por supuesto no vamos a crear objetos para los proveedores sabemos que no están disponibles en este momento.
Solución para esto sería volver a configurar para un mejor rendimiento y eliminar la cola de los proveedores - como lo es ahora - un proveedor por par de idiomas.
Esto no debe ser caro para el rendimiento, pero aún así algo de lógica adicional y el consumo de memoria.

Por favor, diga cuál es la solución preferida.

[vBET]

Y una solución más potencial. Si vamos a marcar toda la API como no disponible y comprobar que en la tarea programada que está disponible, entonces no tiene que hacer la cola de los proveedores. Podemos hacerlo de esta manera - siempre se crea un único objeto traductor (mejor uso de la memoria) y en una petición, pedir la traducción un solo proveedor (mejor CPU). Si no va a estar disponible, entonces se marcará como no disponible y los resultados se vacía (fiabilidad peor). Pero sólo la primera, porque la próxima vez vamos a utilizar otro proveedor de la cola. Y en caso de que ningún proveedor está disponible, traductor ficticio se utiliza - cambio los mismos valores (pero no la cache) por lo que algunas partes no se traducirán, pero la página no tiene partes vacías, como ahora, cuando el proveedor no está disponible.

[vBET]

Anuncio acaba rápido - ya estamos aplicando esta característica.

Lo queremos liberar rápidos (cuando BETA) debido a asuntos comunes, causados por los límites puestos por proveedores de traducción. También estamos buscando otro APIs cuáles se pueden mantener con vBET

[Simon Lloyd]

Mis pensamientos fueron enviar la traducción de verificación primero para ver si prefería el proveedor está disponible, por lo que nos dio el código para comprobar si google o MS está respondiendo, asi al tiempo de llamada para traducción prueba googleapi (nombre de mi archivo de prueba con el código de prueba) si la traducción es verdadero utilizar preferida, si la traducción es flase o código no es 200 y luego probar proveedor siguiente en la lista y realizar su prueba de api antes de utilizar.

Podría tener un control listbox donde el usuario puede enumerar cada proveedor uno por línea en orden de preferencia (permite al agregar soporte para otras API el usuario sólo puede agregarlos a la lista), por lo que mi lista podría tener este aspecto:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Suponiendo que los nombres daft entré eran proveedores de reales, llamada para código de prueba de traducción MS iría si uso respuesta 200 MS si no ejecutar código de prueba de MyTranslator, compruebe la respuesta para 200 si sí utilizarlo si no ejecuta código de prueba de Google ********** etc.

De esta manera nunca tienes que almacenar toda la información sobre los proveedores (de lo contrario podría tener cuadros donde los usuarios podrían introducir sus límites establecidos para cada proveedor, pero creo que esta wuld de información será inútil como podría cambiarlo y significaría más checking back y comprobación adelante antes de hacer una traducción de texto) nunca tendrá que preocuparse si existían límites nuevamente tan necesidad de un cron no job a ejecutar para comprobar estos, la carga en el servidor para que un cheque de traducción pequeños (el código proporcionado en FAQ) no sería nada.

Esperemos que expliqué bien para obtener mi idea, creo que podrían todos hacer sólo por esa pequeña comprobación y sin almacenar nada.

[Simon Lloyd]

Anuncio acaba rápido - ya estamos aplicando esta característica.

Lo queremos liberar rápidos (cuando BETA) debido a asuntos comunes, causados por los límites puestos por proveedores de traducción. También estamos buscando otro APIs cuáles se pueden mantener con vBET

Te he enviado uno o dos (en un post eliminado debido a los vínculos) que pudiera acercarse, si desea una versión beta voluntarios ' m your man

[vBET]

Te he enviado uno o dos (en un post eliminado debido a los vínculos) que pudiera acercarse, si desea una versión beta voluntarios ' m your man

Su mensaje fue eliminado suavemente, porque su contenido fue publicidad escrita por alguien más, pero tenemos acceso a este mensaje y estamos en el mismo

Incluso ya enviamos correo electrónico pregunta a uno de los proveedores de traducciones sobre detalles de pago. Algunos de los que se pagan (incluso cuando se describe como liberarla no es sobre la API de nivel - lo mismo con Google puede traducir gratuitamente por explorador, pero no por la API), pero los precios pueden ser competitivos, por lo que es todavía buena (precios más competencia mejores).
Algunos nos hemos encargado de investigar son los realmente externas traducciones API o diccionarios locales sólo escritos por los propios usuarios (esto también es una cosa en nuestra lista TODO - permite modificar y poner propias traducciones) - Radek tiene esta parte.

Así que estamos trabajando para mejorar vBET y lo hizo tan barato en uso como posible

[vBET]

Estamos en las últimas etapas de la nueva funcionalidad de comprobando. Ya puede ver descripción modificado: http://www.vbenterprisetranslator.co....html#post8914 (Ver última NOTA)

[Simon Lloyd]

Gracias Michael, hizo una entrada rápida en que preguntas que sin duda tendrá que quitar porque no es el lugar correcto Si desea probar en una Junta de vivo que llama muchas traducciones PM me y yo voy a dar acceso a raíz del Foro y admincp, también será poner límite de traducción de google que he puesto arriba y abajo en su mando por lo que se puede probar

[vBET]

OK lo. Cola de proveedores se implementa y se incluirá en versiones 3.5.1 y 4.4.3. vBET 3.5.1 será lanzado hoy. vBET4.4.3 está todavía en fase de prueba. Comunicados de la cabina será BETA por lo que todo el mundo puede comprobar en los foros más grandes que una prueba. Tenga en cuenta que ya estamos probando 3.5.1 en uno de nuestros foros reales. Aún debido a cambios importantes es en fase BETA en primer lugar.