Циркуляр проверки и переключение API, чтобы сохранить поток переводов

[Симон Ллойд]

У меня есть моя символов для google, равным 100 000 perday так с мои настройки «Всегда использование Google», «Использование Google API V2», «Использование Google обнаружение» при достижении этого предела и больше не получить результаты от платных Google можно было бы бесплатно API-интерфейсы запустите результаты?

Так, например я использую пресет предел моих Google и Google больше не возвращает результат для меня (вероятно, возвращая код ошибки как те в вашем Google тестирует код) когда результат не возвращается было бы хорошо, если vBET автоматически признаются код ошибки и затем отправил запрос на другой API как Microsoft (или любые другие, что vBET позднее поддерживает) таким образом, мы уверены получить некоторый результат - для меня это было бы очень полезно учитывая, что существуют пределы даже с платные версии, это позволит вам расширить ваши переводы пределы.

Например
Google установить 100 000 Charcters в день > использовали > vBET перейти к следующему API в списке > Microsoft 400 k за час или 4 М, когда достигнут предел vBET проверка следующих API и назад, чтобы увидеть, если лимит снятия или имеет некоторые пособия > либо перейти к следующему API или в Google, выплатили когда снова достигнут предел > проверить следующий API.... и т.д. и поэтому циклическая проверка после получения код ошибки будет иметь, так что довольно много постоянную возможность иметь переводы.

[vBET]

Я понимаю ваше описание и вашу точку. Теперь мы должны выяснить, как она Предположим для работы технически.

Одной из проблем, я вижу здесь является, как мы признаем, что мы уже доступны после тех, где достигнут до пределов.

Мы можем спросить просто каждый раз, предпочтительный поставщик и затем перейдите к следующему. Это будет стоить производительность - потому, что для каждого запроса к странице, которая требует перевода, мы будет безуспешной призыв к предпочтительного поставщика, затем к следующему один (таким образом, она может быть несколько неудачных звонков, когда vBET будет поддерживать больше APIs).

Другим решением было бы хранить информацию, предпочтительный поставщик не доступны и перейти сразу к следующему. Это было бы намного быстрее, потому что проверка локальной переменной является гораздо быстрее, чем ждать ответа от внешнего сервера. На этот раз, у нас есть другой вопрос - мы не знаем, когда доступен предпочтительный поставщик. Мы можем, конечно, сделал некоторые назначенное задание, которое бы попросить простой (короткое) перевод например раз в час/день проверить его. Так в рамках этой стратегии мы должны решить, как часто по умолчанию, такой задачи предполагается работать. Конечно мы бы проверить, только тогда, когда некоторые поставщик помечается как не имеется.
Также если мы отмечаем поставщиков как недоступный - что делать, когда мы знаем, что все поставщики не доступны - добавить некоторую информацию для конечного пользователя или просто воплотить то, что находится в кэш и остальные как оригинал, без каких-либо дополнительной информации о временное отсутствие служб письменного перевода.

Независимо от того, каким образом это будет сделано Google будет рассматриваться как один API (v1 или v2 в зависимости от конфигурации) - нет смысла разбить его, потому что очень скоро будет закрыт Google v1.

Другая вещь, чтобы настроить очередь поставщики для каждой языковой пары отдельно. В этот момент vBET уже позволяет настроить поставщика перевода для каждой языковой пары. Я думаю, что мы можем изменить ее от одного значения к разделение значений запятыми (CSV). Таким образом, мы будем знать для каждой языковой пары которых поставщики поддерживают этот перевод и каковы порядок предпочтения (справедливый порядок в CSV список).

Обратите внимание: это будет иметь определенное влияние производительность так или иначе. Вместо того, чтобы создать один объект для перевода нам придется создать массив таких объектов и дополнительных обтекания объекта (чтобы сделать его прозрачным для других частей кода и меньше ошибок подверженных). Конечно мы не создадим объекты для поставщиков, мы знаем, не доступны на данный момент.
Решение для этого будет перенастроить для лучшей производительности и удалить очередь поставщики - так же, как это прямо сейчас - один поставщик на языковой пары.
Это не должно быть дорогим для исполнения, но до сих пор некоторые дополнительные логики и потребление памяти.

Пожалуйста, сообщите, какой вариант является предпочтительным.

[vBET]

И одним из нескольких возможных решений. Если мы будем отмечать весь API как не имеется и проверьте, что на запланированной задачи она доступна теперь, то мы не должны сделать очередь поставщики. Мы можем сделать это путь - всегда создается только один переводчик объект (лучшее использование памяти) и в одном запросе для перевода просим только один поставщик (лучше ЦП). Если она не будет доступна, то оно будет помечено как недоступные и результаты будут пустым (наихудший надежности). Но только первый из них потому что в следующий раз мы будем использовать другого поставщика из очереди. И в случае если поставщик не доступен, то манекена переводчик будет использоваться - возвращают одинаковые значения (но не кэшировать) поэтому некоторые части будет не переведены, но страница не будет иметь пустой части, как сейчас, когда поставщик не доступны.

[vBET]

Просто быстро объявление - мы уже осуществляем эту функцию.

Мы хотим выпустить его быстро (как бета-версия) из-за общих проблем, вызванных установленных поставщиков перевода. Мы также ищем других интерфейсов API, которые можно:) поддерживаемых vBET

[Симон Ллойд]

Мои мысли были отправить чек перевод сначала увидеть если предпочтительный поставщик доступен, так что вы дали нам код для проверки, если google или MS реагирует, поэтому во время вызова для перевода тест googleapi (имя моего тестового файла в коде теста) если перевод является true использовать предпочитаемый, если перевод неверно или код не 200, то попробуйте следующий поставщик в списке и выполнить их api тест перед использованием.

Вы могли бы иметь listbox, где пользователь можно перечислить каждый поставщик, один в строке в порядке предпочтения (это позволяет, при добавлении поддержки для других интерфейсов API пользователя можно просто добавить их в список), так что мой список может выглядеть следующим образом:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Предполагая бесшабашный имена, я вошел были реальные провайдеров, по вызову для перевода MS тест код будет выполняться, если ответ 200 использования MS, если не выполните код теста MyTranslator, проверить ответ для 200 да использовать его, если не запустить Google код теста ********** и т.д.

Таким образом, вам никогда не придется хранить любую информацию о поставщиков (в противном случае могли бы иметь текст, коробки, где пользователи могут ввести их установить ограничения для каждого поставщика, но я думаю, эта информация wuld бесполезно, как они могут изменить его, и это будет означать более проверки обратно и проверка вперед, прежде чем сделать перевод) никогда не придется беспокоиться при наличии ограничений снова так нет необходимости cron заданий для запуска проверить эти, нагрузка на сервер для проверки что один небольшой перевод (код, вы предоставили в FAQ) будет ничего.

Надеюсь я объяснил, что ОК так что вы получаете мои идеи, я думаю, что можно все сделать только что эта небольшая проверка и без хранения ничего.

[Симон Ллойд]

Просто быстро объявление - мы уже осуществляем эту функцию.

Мы хотим выпустить его быстро (как бета-версия) из-за общих проблем, вызванных установленных поставщиков перевода. Мы также ищем для других интерфейсов API, которые можно:) поддерживаемых vBET я послал вам один или два (в пост, вы удалили из ссылки) что вы могли бы подход, если вы хотите бета добровольцев я ваш мужчина:)

[vBET]

Я послал вам один или два (в должность, которую вы удалили из ссылки), что вы могли бы подход, если вы хотите бета добровольцев я ваш мужчина:)

Ваше сообщение было мягко удалено, потому что его содержание является реклама, написанного кем-то еще, но у нас есть доступ к этому сообщению и мы на него:)

Мы даже уже напишите вопрос одному из этих переводов поставщиков о детали оплаты. Некоторые из них оплачиваются (даже когда она описывается как бесплатно это не на API уровня - то же самое, вы имеете с Google вы можете перевести бесплатно браузера, но не API), но цены могут быть конкурентоспособными, так что это еще хорошо, (больше конкуренции лучше цены).
Мы исследуем одни эти действительно внешних переводов API или просто локальных словарей, написанных собственных пользователей (это также одна вещь в нашем TODO списке - позволяет изменить и поставить собственные переводы) - Радек имеет эту часть.

Поэтому мы работаем над улучшением vBET и сделал это, как дешево в использовании как можно:)

[vBET]

Мы находимся в последней стадии Тесинг новые функциональные возможности. Вы уже можете увидеть изменения описания: http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.html#post8914 (см. Последнее замечание)

[Симон Ллойд]

Спасибо Майкл, я сделал быстрый пост в что Faq, который несомненно вам придется удалить, так как его не правильное место для него:) Если вы хотели бы протестировать на живой Совет, который вызывает много переводов PM, меня и я дам вам доступ в форум и admincp корень, также я вложу лимит перевода google, который я поставил вверх и вниз на вашей команде так что вы можете проверить:)

[vBET]

OK так. Поставщики очереди осуществляется и будет включаться в выпусках 3.5.1 и 4.4.3. vBET 3.5.1 будет выпущен сегодня. vBET4.4.3 находится в стадии тестирования. Стенд релизы будут бета-версии так что каждый может проверить на крупных форумах, которые протестировать один. Пожалуйста, обратите внимание на то, что мы уже проводим тестирование 3.5.1 на одном из наших реальных форумов. До сих пор из-за важных изменений именно в стадии бета-ТЕСТИРОВАНИЯ сначала.

[Симон Ллойд]

Должен ли он быть запланированного задания и одного конкретного поставщика отключить на час при времени?, Я сделал предложение здесь Циркуляр проверки и переключение API, чтобы сохранить поток переводов, где возможно, мы могли всегда начинаются в верхней части наших поставщиков список и сделать пробный звонок (как тот, который вы указали протестировать Google и Microsoft ответ ответ), если ответ тестовый звонок составляет 200 или текст переводится затем использовать эти связи, если ответа не 200 или проверить текст не переведен (используя тот же текст для каждого испытания и регулярное выражение для проверки переведенного текста), то переход к следующему провайдера, каждый перевод вызова может запустить в верхней части списка и работать вниз

Не имея пустой результат был бы хорош, потому что как только мы возврат порожних вот как оно остается, я уже было много людей жалуются, что дело обстоит именно так в моем форуме.

[vBET]

Она не должна быть таким образом, это прямо сейчас. Спасибо за Вашу записку. Еще - нет. Она не имеет смысла. Пожалуйста заметьте что просят внешний перевод больше времени вещь в целом vBET (и это не для нас). Существует никакого смысла для ума тысячи запросов, когда мы уже достичь пределов. Это будет время отклика increaser, ЦП и потребление памяти (больше объект создан).

Мы обнаружили, что Google информацию о возможно TOS злоупотребления исчезает через некоторое время. Мы не знаем, но, возможно, если мы будем постоянно спрашивать, когда мы уже заблокированы, Google может заблокировать больше времени. Может быть, нет, но по-прежнему актуальны стратегии гораздо лучше для производительности. В конце у вас есть круговая проверки. Если он не доступен, он не будет доступна, а другая используется. Если другой не доступна, то же самое. Мы просто не проверить это снова доступен каждому запросу, что не имеет смысла (это может быть миллионы запросов, прежде чем оно будет доступно) только один раз в час. И если он будет доступен он будет отмечен меня так что мы вернемся к предпочтительным один - и у вас есть круг здесь. Также тестирование каждый раз будет сделан пределы достигается быстрее или издержки выше, если вы используете заплатил переводы (она по-прежнему считается перевод).
Также мы готовы иметь другие поставщики тоже. Когда мы будем поддерживать более чем 2 такая стратегия будет убийца для вашего сервера. Представьте себе 5 тестирования вызовы различных провайдеров и затем реальный перевод для каждого перевода запроса. LOL Спасибо за вашу идею:) Мы действительно ценим идеи пользователей, на этот раз мы будем оставаться с само решение.

Обратите внимание, что вы можете изменить частоту vBET следует проверить наличие провайдеров. Теперь это один час, но вы можете перенастроить в Admin CP - > назначенные задания - > запланированных Диспетчер задач и набор, например на каждые 10 минут 0 как задача RSS плакат робот сделать это сейчас.

[vBET]

Мало изменения - мы проверим наличие поставщика не один раз в час, но каждые 10 минут. Если вы уже повышен до vBET 3.5.1 до этого сообщения просьба скачать пакет vBET снова и снова загрузить файл продукта.

Изменение было сделано потому, что мы обнаружили на наш реальный форум, который часто провайдер недоступен на короткое время. Мы будем исследовать его более искать другую улучшений.

[Симон Ллойд]

Большая работа, ребята:), я повышен до этого, но будет загружать последние исправления и использования, что, я буду создавать новый поток для обратной связи по этому вопросу.