Циркуляр перевірки і перемикання API, щоб зберегти потік перекладів

[Simon Lloyd]

У мене моє обмеження кількості символів для google встановити до 100000 perday, так що мої налаштування "Завжди використовувати Google", "Використання Google API V2", "Використання Google виявлення" коли я досягти цю межу і більше не отримати результатів від платних Google можна буде безкоштовно API потім почати виробництво результатів?

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

Наприклад
Google встановити 100000 Charcters за день > використовували > vBET переміщення до наступного API у списку > Microsoft 400K на годину або 4 М, коли досягнуто межі vBET перевірки наступний API і назад, щоб побачити, якщо ліміт підняли або має деякі посібники > або переміщення до наступного API або повернутися до Google, гроші, коли досягнуто межі знову > перевірити наступного API.... тощо і тому кругової перевірка після отримання код помилки будуть вести, тому досить багато постійну можливість мати переклади.

[vBET]

Я розумію, що ваш опис і вашу точку. Тепер ми повинні з'ясувати, як це припустимо, на роботу у технічно.

Одне питання, я бачу тут є, як ми визнаємо, що ми вже доступні після тих, де досягло до межі.

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

Іншим рішенням було б для зберігання інформації, що бажаний постачальник не є доступним і перейти безпосередньо до наступного один. Це було б набагато швидше, тому що перевірка локальної змінної, набагато швидше, ніж очікування відповіді від зовнішнього сервера. Цього разу, у нас є інші питання - ми не знаємо, коли бажаних постачальників надається. Ми можемо, звичайно, зробив деякі заплановані завдання, яка б попросити простий (короткий) Переклад наприклад один раз на годину на день перевірити його. Так, у цій стратегії ми повинні вирішити як часто за замовчуванням таке завдання припустити, щоб працювати. Звичайно, ми б перевірити це, тільки тоді, коли деякі постачальник позначено як не доступна.
Також, якщо ми позначити постачальників як недоступно - те, що робити, коли ми знаємо, що всі постачальники недоступні - додати деяку інформацію для кінцевого користувача, або просто перекласти те, що є в кеш-пам'яті та інші як оригінальний, без будь-яких додаткових інформація про тимчасову відсутність перекладу провайдерів.

Незалежно від того, яким чином це буде зроблено Google буде розглядатися як один API (v1 або v2 залежно від конфігурації) - немає сенсу щоб розділити його, тому що Google v1 буде закрито дуже скоро.

Інша річ, дозволяють налаштувати провайдерів черги для кожної пари мов окремо. На даний момент vBET вже дозволяє налаштувати переклад постачальника для кожної пари мов. Я думаю, що ми можемо змінити це від одного значення до значень із роздільниками-комами (CSV). Таким чином, ми будемо знати, для кожної пари мов постачальників, які підтримують цей переклад і які уподобання порядку (просто замовлення на список CSV).

Зверніть увагу: це матиме вплив на продуктивність будь-якому випадку. Замість того щоб створити один об'єкт для перекладу ми повинні створити масив таких об'єктів і додаткові обтікання об'єкта (щоб зробити його прозорим для інших частин коду і менше помилок схильним). Звичайно ми не створимо об'єктів для постачальників послуг, ми знаємо, недоступні в даний момент.
Рішення для цього було б переналаштувати для кращої продуктивності і видалити провайдерів черги - як це прямо зараз - одного постачальника за пара мов.
Це не повинні бути дорогими для продуктивності, але все-таки деякі додаткові логіки і пам'яті споживання.

Будь ласка, скажіть, що рішення є кращим.

[vBET]

І один більше потенціал рішення. Якщо ми позначити весь API як недоступні і перевірити на Заплановане завдання це його доступні зараз, тоді ми не повинні робити черги провайдерів. Ми можемо це зробити це шляхом - завжди створюється лише один об'єкт Перекладач (краще використання пам'яті) та в одне прохання ми просимо для перекладу тільки одного постачальника (краще КПУ). Якщо буде не доступні, то будуть позначені як недоступні, і результати будуть порожній (найгірших надійності). Але лише перше тому що наступного разу ми будемо використовувати іншого постачальника з черги. У випадку якщо немає постачальника, вона потім фіктивний Перекладач буде використовуватися - повернення однакові значення (але не кешувати його), і тому деякі частини будуть не переведені, але сторінка не буде мати порожній частин, як тепер коли постачальник не доступна.

[vBET]

Просто швидко оголошення - ми вже є реалізацією цієї функції.

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

[Simon Lloyd]

Мої думки були відправити перевірити переклад по-перше, щоб побачити, якщо основний постачальник доступний, так що ви дали нам код, щоб перевірити, якщо google або MS реагує, так що час виклику для перекладу тест googleapi (ім'я мій тесту з тестування коду) Якщо Переклад true використовувати переживання бажане, якщо Переклад flase або код не 200, то спробуйте наступне постачальника у списку і виконувати свої випробування api, перед використанням.

Ви могли б списку, де користувач може список кожної пошукової служби, одна одній лінії за уподобанням (що дозволяє під час додавання підтримки для інших API для користувача просто їх можна додати до списку), так що мій список може виглядати наступним чином:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Припускаючи, що daft імен після вводу були реальні постачальники, за викликом для перекладу MS тестування коду буде працювати, якщо відповідь 200 використання MS, якщо не запускати MyTranslator тестування коду, перевірити відповідь за 200, якщо так, використовувати його, якщо не запускати Google тестування коду ********** та ін

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

Сподіваюся, я пояснив, що ОК так що ви отримаєте Моя ідея, я думаю, що це все можна зробити тільки шляхом що невелика перевірка і без зберігання, що.

[Simon Lloyd]

Просто швидко оголошення - ми вже є реалізацією цієї функції.

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

[vBET]

Я послав вам одну або дві (на посаді, що ви видалили з-за посиланнями), що ви могли б підійти, якщо потрібно бета добровольців, я ваш чоловік:)

Ваше повідомлення тихо видалено, тому що її зміст був реклами, написана кимось іншим, але ми маємо доступ до повідомлення і ми на ньому:)

Ми вже навіть відправити запитання електронною поштою до однієї з цих провайдерів переклади, про платежу. Деякі з них платні (навіть коли воно описане як вільний, він не є на API рівня - те ж саме, що у вас з Google ви можете перевести безкоштовно, браузер, а не API), але ціни можуть бути конкурентоспроможними, так як і раніше добре (більше конкуренція краще ціни).
Деякі ми маємо розслідування, ці дійсно зовнішніх переклади API або просто локальні словники, Автор власної користувачів (це також одна річ на наш список ЗАВДАНЬ - дозволяє змінювати і покласти власні переклади) - Радек має цю частину.

Так ми працюємо, щоб поліпшити vBET і зробив це як дешеві використання якомога:)

[vBET]

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

[Simon Lloyd]

Завдяки Майкл, я зробив швидкий пост в що Faq, які без сумніву, вам доведеться видалити, оскільки його не правильне місце для його:), якщо ви хотіли б перевірити на це жити ради, яка вимагає багато перекладів Вечора мені і я дам вам доступ до форуму admincp і кореня, я також поклав google Переклад межа, що я поставив вгору і вниз на ваші команди так що ви можете тестувати:)

[vBET]

ИТАК. Реалізовано провайдерів черги, і його буде включено в релізи 3.5.1 і 4.4.3. vBET 3.5.1 буде випущена сьогодні. vBET4.4.3 все ще перебуває в стадії тестування. Стенд релізи будуть бета, так що кожен може протестувати його у великих форумах, які випробування одного. Зверніть увагу, що ми вже тестування 3.5.1 на одному з наших реальні форумах. Ще через важливі зміни це у стадії бета-ВЕРСІЇ вперше.

[Simon Lloyd]

Вона повинна бути Заплановане завдання і одного конкретного постачальника вимкнуто протягом години в той час?, я зробив пропозицію тут Циркуляр, перевірка і перемикання API йти в потоці перекладів де можливо ми могли б завжди початок у верхній частині нашого списку постачальників і зробити тест виклику (як той, який ви надали перевірити відповідь Google і Microsoft відповідь) Якщо тестовий дзвінок відповідь 200 або текст перекладено потім за допомогою цього постачальника, якщо відповідь не 200 або тест-текст не перекладено (використовуючи той же текст для кожного тесту і до REGEX перевірити перекладеного тексту) то перейти до наступного постачальника, кожен Переклад виклику можна потім у верхній частині списку і почав працювати вниз

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

[vBET]

Він не повинен бути таким чином, це прямо зараз. Дякуємо за ваше зауваження. Все-таки - ні. Вона не має сенсу. Зверніть увагу, що просять за зовнішні Переклад є більше часу, що в цілому vBET (і це не нам). Немає сенсу щоб mad тисячі запит, коли ми вже досягнення межі. Це буде increaser час відгуку, використання Процесорного часу та споживанням пам'яті також (більше об'єкт, створений).

Ми виявили, що Google інформація про ймовірно зловживання ГС зникає після деякого часу. Ми не знаємо, але може бути якщо ми будемо постійно питати, коли ми вже заблоковано, Google може блокувати більше часу. Може й ні, ще фактичного стратегії, але набагато краще для продуктивності. В кінці вас кругової перевірки. Якщо один не доступна відзначається як недоступні, і інший використовується. Якщо інший доступний не потім, те ж саме відбувається. Ми просто не перевірити це, вона доступна знову кожен запит те, що не має сенсу (це може бути мільйони запитів, перш ніж вона буде доступна) лише один раз на годину. І якщо вона буде доступна його буде мене позначені, так що ми повернутися до бажаних один - і у вас тут коло. Також тестування кожного разу, коли буде зробив свої межі, досягнуто швидше або витрати вище, якщо ви використовуєте заплатив переклади (він як і раніше вважається перекладу).
Також ми готові мати інші постачальники теж. Коли ми будемо підтримувати більш, ніж 2 такої стратегії буде вбивцею для вашого сервера. Уявіть собі 5 тестування дзвінки на різних постачальників і потім реальні перекладу для кожного запиту перекладу. Ні. Спасибі за вашу ідею:) Ми дуже цінуємо користувачів ідеї, цього разу ми будемо залишатися з фактичним рішенням.

Зверніть увагу, що можна змінити частоту vBET слід перевіряти наявність провайдерів. Тепер це одна за годину, але ви можете переналаштувати що в Admin CP - > запланованих завдань - > заплановано Диспетчер завдань і набір, наприклад за кожні 10 хвилин 0 так само, як завдання RSS плакат робот, зробити це зараз.

[vBET]

Невеликі зміни, зроблені - ми перевіримо постачальник наявність не раз на годину, але кожні 10 хвилин. Якщо ви оновили в vBET 3.5.1 до цього повідомлення будь ласка просто повторно завантажити пакет vBET і завантажувати продукт файл знову.

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

[Simon Lloyd]

Хлопці велика робота:), я вже оновлений до цього але буде завантажити останню виправити і використання, що буде створити новий потік для зворотного зв'язку з цього.