Circular verificação e troca de APIs para manter o fluxo de traduções

[Simon Lloyd]

Eu tenho o meu limite de caracteres para definir a 100.000 google perday assim com a minha configuração "Sempre usar o Google", "Use Google API V2", "Use Detecção Google" quando eu chegar a esse limite e não obter resultados a partir do Google paga seria possível APIs para livre então começar a produzir resultados?

Assim, por exemplo eu uso meu limite predefinido do Google e Google não retorna um resultado para mim (provavelmente retornando um código de erro, como as de seu código de teste do Google) quando o resultado não é retornado que seria bom se vBET reconhecido automaticamente o código de falha e, em seguida, enviou pedido para outra API como a Microsoft (ou qualquer outro que vBET mais tarde suporta) desta forma temos certeza de conseguir algum resultado - para mim, isso seria muito valioso dado que existem limites mesmo com versões pagas, permitirá você estender seus limites de traduções.

por exemplo
Google definir 100.000 caracteres por dia > absorver > vBET mover para próxima API na lista > Microsoft 400 k por hora ou 4 M quando o limite alcançado vBET seleção API próximo e anterior para ver se o limite de levantamento ou tem algum subsídio > quer mover para API Avançar ou voltar para o Google paga ao limite atingido novamente > verificar próxima API.... etc e assim que a verificação de circular após receber um código de erro seria continuar, tão bonita muita capacidade constante de traduções.

[vBET]

Eu entendo a sua descrição e seu ponto. Agora temos que descobrir como ele supor para trabalhar tecnicamente.

Um problema que vejo aqui é como vamos reconhecer que já temos limites disponíveis após aqueles onde chegou antes.

Podemos simplesmente sempre pedir fornecedor preferido e vá para a próxima. Isso vai custar desempenho - porque para cada solicitação de página que requer tradução, fizemos uma chamada sem êxito ao provedor preferencial, então para o próximo um (por isso pode ser várias chamadas sem êxito quando vBET oferecerá suporte a mais APIs).

Outra solução seria para armazenar informações que o provedor preferencial não estiver disponível e ir diretamente para uma próxima. Isso seria muito mais rápido, porque a verificação variável local é muito mais rápido do que esperar a resposta de um servidor externo. Desta vez temos outro problema - não sabemos quando o provedor preferencial está disponível. É claro que podemos fez algumas tarefa agendada que solicitar a tradução (short) simples, por exemplo, uma vez por hora / dia para verificá-lo. Assim, nesta estratégia, temos de decidir quantas vezes por padrão tal tarefa supor para trabalhar. É claro que iria verificar-lo somente quando algum provedor estiver marcado como não disponível.
Além disso, se marcamos provedores como indisponível - o que fazer quando sabemos que todos os provedores não estão disponíveis - adicionar algumas informações para o usuário final ou apenas traduzir o que está no cache eo resto como original, sem qualquer informação adicional sobre a falta temporária de prestadores de tradução .

Não importa que forma isso será feito, Google vai ser tratado como uma API (v1 ou v2, dependendo da configuração) - não faz sentido dividi-la, porque o Google v1 será fechado muito em breve.

Outra coisa é permitir que configurar a fila de provedores para cada par de línguas separadamente. Neste momento vBET já permite configurar o provedor de tradução para cada par de línguas. Eu acho que nós pode alterá-lo de um valor para valores separados por vírgula (CSV). Assim saberemos para cada par de línguas quais provedores de apoiar esta tradução e quais são as preferências de ordem (ordem justa na lista de CSV).

ATENÇÃO: isso vai ter algum impacto no desempenho de qualquer maneira. Em vez de criar um objeto para a tradução teremos que criar array de objetos tais e objeto envolvimento adicional (para torná-lo transparente para outras partes do código e bugs menos propenso). É claro que não vai criar objetos para os fornecedores que sabemos não estão disponíveis neste momento.
Solução para isso seria para reconfigurar para melhor desempenho e remover provedores de fila - assim como é agora - um fornecedor por par de idiomas.
Isto não deve ser caro para o desempenho, mas ainda alguma lógica adicional e consumo de memória.

Por favor, diga qual é a solução preferida.

[vBET]

E mais uma solução potencial. Se vai marcar toda API como não disponíveis e verificar a tarefa agendada é disponível agora, então não temos de fazer fila de fornecedores. Podemos fazê-lo desta maneira - sempre é criado apenas um objeto tradutor (melhor uso de memória) e em um pedido, de solicitar a tradução apenas um fornecedor (CPU melhor). Se ele não estará disponível, então ela será marcada como não disponíveis e os resultados serão vazia (confiabilidade pior). Mas apenas um primeiro lugar, porque da próxima vez, vamos utilizar outro provedor da fila. E no caso, se nenhum provedor está disponível, então tradutor dummy será usado - retornar os mesmos valores (mas não cache-lo) para algumas partes não serão traduzidas, mas a página não terá partes vazias, como agora, quando provedor não está disponível.

[vBET]

Apenas anúncio rápida - já estamos implementando esse recurso.

[Simon Lloyd]

Meus pensamentos foram para enviar a tradução primeiro cheque para ver se fornecedor preferencial está disponível, assim que você nos deu código para verificar se o Google ou o MS está respondendo, então no momento da chamada para a tradução de teste googleapi (nome do meu arquivo de teste com seu código de teste ) se a tradução é verdadeiro uso preffered, se a tradução é flase ou o código não é 200 tente próximo provedor na lista e faça seu teste antes de usar api.

Você poderia ter um listbox onde o usuário pode listar cada um fornecedor por linha em ordem de preferência (isto permite que quando você adicionar suporte para outras APIs o usuário pode simplesmente adicioná-los à lista), então minha lista poderia ficar assim:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Supondo que os nomes foram inseridos daft i fornecedores real, na chamada para a tradução de código de teste MS iria correr, se a resposta use MS 200 se não executar o código de teste MyTranslator, verificar a resposta por 200 se sim usá-lo se não executar o Google código de teste **** ****** etc

Desta forma você nunca tem que armazenar qualquer informação sobre os fornecedores (caso contrário, você poderia ter caixas de texto onde os usuários poderiam entrar os seus limites fixados para cada provedor, mas eu acho que esta informação wuld ser inútil como eles poderiam mudá-la e isso significaria mais checando e verificando frente antes de fazer uma tradução), você nunca teria de se preocupar se os limites estavam disponíveis novamente para que não há necessidade de um trabalho cron para executar a verificação destes, a carga no servidor para verificar que uma pequena tradução (o código fornecido na FAQ) seria nada.

Espero ok explicou que assim que você começa a minha ideia, eu acho que tudo poderia ser feito apenas por que o check pequenas e sem guardar nada.

[Simon Lloyd]

Apenas anúncio rápida - já estamos implementando esse recurso.

Enviei-lhe um ou dois (em uma mensagem você excluído por causa das ligações) que você poderia se aproximar, se você quiser um voluntário beta eu sou seu homem

[vBET]

Enviei-lhe um ou dois (em uma mensagem você excluído por causa das ligações) que você poderia se aproximar, se você quiser um voluntário beta eu sou seu homem

Sua mensagem foi suavemente excluídos, porque seu conteúdo foi propaganda escrita por outra pessoa, mas temos acesso a essa mensagem e estamos nele

Nós até já envie um email pergunta a um desses provedores de traduções sobre os detalhes de pagamento. Alguns desses são pagos (mesmo quando ele é descrito como livre não é em nível de API - a mesma coisa que você tem com Google você pode traduzir livre pelo navegador, mas não por API), mas os preços podem ser competitivos, por isso ainda é bom (preços mais concorrência melhor).
Alguns temos investigar são aqueles realmente externo traduções API ou apenas dicionários locais escrito por próprios usuários (isso também é uma coisa em nossa lista TODO - permitem modificar e colocar próprias traduções) - Radek tem essa parte.

[vBET]

Estamos nos últimos estágios da tesing nova funcionalidade. Você já pode ver descrição alterada: http://www.vbenterprisetranslator.co....html#post8914 (ver última NOTA)

[Simon Lloyd]

Obrigado Michael, eu fiz um post rápido na ECT Faq que sem dúvida você terá que remover porque não é o lugar correto para ele Se você gostaria de testar em um uma placa ao vivo que chama muitas traduções PM me e eu vou lhe dar acesso a raiz admincp e fórum, eu também vou colocar limite de tradução do google que eu tenha definido para cima e para baixo ao seu comando para que você possa testar

[vBET]

OK assim. Fila de provedores é implementada e ele será incluído em versões 3.5.1 e 4.4.3. vBET 3.5.1 será lançado hoje. vBET4.4.3 ainda está em fase de teste. Lançamentos de estande será BETA assim que todos podem testá-lo em fóruns maiores que testar um. Por favor, note que estamos já a testar 3.5.1 dos nossos fóruns reais. Ainda por causa de mudanças importantes, está em fase BETA primeiro.