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).

Por favor NOTE: isso terá algum impacto no desempenho de qualquer maneira. Em vez de criar um objeto para tradução, teremos de criar matriz desses objetos e objeto de acondicionamento adicionais (para torná-la transparente para outras partes do código e menos erros propenso). Naturalmente nós não criará objetos para provedores 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.

Queremos libertá-lo rápido (como BETA) por causa dos problemas comuns, causados por limites fixados pelos provedores de tradução. Estamos também procurando outras APIs que podem ser apoiados por vBET:)

[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.

Queremos libertá-lo rápido (como BETA) por causa dos problemas comuns, causados por limites fixados pelos provedores de tradução. Estamos também para outras APIs que podem ser apoiados por vBET:) enviei-lhe um ou dois (em um post que você excluiu por causa dos links) que você poderia aproximar-se, se você quer um beta voluntários eu sou seu homem:)

[vBET]

Enviei-lhe um ou dois (em um post que você excluiu por causa dos links) que você poderia aproximar-se, se você quer um beta voluntários eu sou seu homem:)

Sua mensagem foi removida suavemente, porque seu conteúdo era propaganda escrita por outra pessoa, mas temos acesso a esta 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.

Assim estamos trabalhando para melhorar a vBET e tornava como barata no uso possível:)

[vBET]

Estamos nos últimos estágios da tesing nova funcionalidade. Você já pode ver alterada Descrição: http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.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.

[Simon Lloyd]

Será que ela precisa ser uma tarefa agendada e um determinado fornecedor desligado por uma hora a uma hora?, Eu fiz uma sugestão aqui Circular verificação e troca de APIs para manter o fluxo de traduções, onde talvez pudéssemos iniciar sempre no topo de nossos fornecedores lista e fazer chamada de teste (como aquele que você forneceu para testar Google resposta e Microsoft) se a resposta é chamada de teste de 200 ou texto é traduzido, em seguida, usar esse provedor, se a resposta não é 200 ou texto de teste não é traduzido (usando o mesmo texto para cada teste e os REGEX para verificar o texto traduzido), em seguida, passar para próximo provedor, cada chamada tradução pode então começar no topo da lista e trabalhar para baixo

Não ter um resultado vazio seria bom porque uma vez que temos um retorno vazio que é como ele permanece, eu já tive muitas pessoas reclamando que este é o caso no meu forum.

[vBET]

Ele não tem que ser desta forma, é agora. Obrigado por sua observação. Ainda - não. Ele não tem sentido. Por favor, note que pedindo tradução externa é a coisa mais demorada no vBET todo (e não cabe a nós). Não há nenhum sentido para louco milhares de pedido quando chegamos já limites. Isso seria tempo de resposta de increaser, o consumo de CPU e consumo de memória também (mais objeto criado).

Nós descobrimos que ao Google informações sobre o abuso TOS provavelmente desaparece após algum tempo. Nós não sabemos, mas talvez se vamos continuar perguntando quando já estamos bloqueados, o Google pode bloquear por mais tempo. Talvez não, mas ainda a estratégia real é muito melhor para o desempenho. No final você tem verificação circular. Se um não estiver disponível, é marcado como indisponível e outra é usada. Se outro não estiver disponível, mesma coisa acontece. Nós apenas não verificar é disponível novamente cada pedido que não tem sentido (ele pode ser milhões de consultas antes de ser disponível) apenas uma vez por hora. E se ele estará disponível ele irá me marcou por isso vamos voltar para uma preferenciais - e você tem um círculo aqui. Também o teste de cada tempo será feito alcançado seus limites mais rápido ou custos mais elevados, se você usar traduções pago (ele ainda conta como tradução).
Também estamos dispostos a ter também outros provedores. Quando vamos apoiar mais de 2 tal estratégia será um assassino para seu servidor. Imagine 5 chamadas de testes para provedores diferentes e, em seguida, real tradução para cada solicitação de tradução. N. Obrigado pela sua idéia:) Nós realmente aprecio idéias de usuários, desta vez que vamos ficar com a solução real.

Por favor, note que você pode alterar a frequência com vBET deve verificar disponibilidade de provedores. Agora é um por hora, mas você pode reconfigurar que no Admin CP - > tarefas agendadas - > Gerenciador de tarefas agendadas e conjunto-por exemplo, para cada 10 minutos, 0 como tarefa RSS Poster robô fazem-lo agora.

[vBET]

Pouca alteração feita - vamos verificar disponibilidade do provedor não uma vez por hora, mas a cada 10 minutos. Se você já atualizou para vBET 3.5.1 antes esta mensagem apenas Baixe vBET pacote novamente e fazer o upload do arquivo de produto novamente.

A mudança foi feita porque nós encontramos no nosso fórum real que muitas vezes não está disponível para provedor de tempo curto. Vamos investigá-lo mais para procurar outro melhorias.

[Simon Lloyd]

Grande trabalho caras:), eu tiver atualizado para isso mas baixará a correção mais recente e a utilização que, criarei um novo thread para comentários sobre este.