Circular comprobación e intercambio de APIs para manter o fluxo de 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).

ATENCIÓN: iso vai ter algún impacto no desempeño de calquera maneira. En vez de crear un obxecto para a tradución teremos que crear array de obxectos tales e obxecto participación adicional (para facelo transparente a outras partes do código e erros menos propenso). Está claro que non vai crear obxectos para os provedores que sabemos non están dispoñibles 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.