Цыркуляр праверкі і пераключэнне API, каб захаваць паток перакладаў

[Simon Lloyd]

У мяне ёсць мяжа для Google усталяваны ў 100000 perday так з маімі наладамі "Заўсёды выкарыстоўваць Google", "Выкарыстанне Google API V2", "Выкарыстанне Google Выяўленне", калі я дасягнуць гэтай мяжы і больш не атрымліваць вынікі ад платных Google было б магчыма бясплатна API, затым пачынаюць вырабляць вынікі?

Так, напрыклад, я выкарыстоўваю свой Google зададзенай мяжы і Google больш не вяртае вынік для мяне (верагодна, вяртаўся код памылкі, як тыя, у кодзе тэсту Google), калі вынік не вярнулася, было б добра, калі Б. прадпрыемства аўтаматычна прызналі сваю віну кода і затым адпраўляецца запыт на іншы API, як Microsoft (або любыя іншыя, якія больш познія версіі падтрымліваюць Б. прадпрыемства) Такім чынам, мы ўпэўненыя ў атрыманні нейкі вынік - для мяне гэта было б вельмі і вельмі каштоўна, улічваючы, што ёсць межы нават з платнай версіі, гэта дазволіць вам пашырыць пераклады межы.

напрыклад,
Google ўстаноўлена 100000 Charcters у дзень> выдаткаваў> Б. прадпрыемства для пераходу да наступнага ў спісе API> Microsoft 400k у гадзіну ці 4М, калі дасягнуты мяжа Б. прадпрыемства праверыць наступнае API і папярэднія каб убачыць, калі мяжа падымаецца ці мае некаторыя дапамогі> альбо перайсці да наступнага або API Вярнуцца да Google заплацілі, калі дасягнуты мяжа зноў> праверце наступнае API .... і г.д. і так кругавая праверкі пасля атрымання кода памылкі б працягваць, так у значнай ступені пастаянную магчымасць мець пераклады.

[vBET]

Я разумею ваша апісанне і паставіць кропку. Цяпер мы павінны даведацца, як гэта мяркуюць, каб працаваць у тэхнічным плане.

Адзін з пытанняў, я бачу, вось як мы прызнаем, што ў нас ужо ёсць межы даступныя пасля тых, дзе дасягнута раней.

Мы можам проста кожны раз прасіць пераважнага пастаўшчыка, а затым перайсці да наступнага. Гэта будзе каштаваць выкананне - таму што для кожнага запыту старонкі, якія патрабуюць перакладу, мы зрабілі няўдалую выклік пераважнага пастаўшчыка, то да наступнага (таму ён можа быць некалькі няўдалых званкоў, калі Б. прадпрыемства будзе аказваць падтрымку больш API).

Іншае рашэнне было б для захоўвання інфармацыі, пераважнага пастаўшчыка не даступная і адразу перайсці да наступнага. Гэта было б значна хутчэй, таму што праверка лакальных зменных нашмат хутчэй, чым чакаць адказу ад вонкавага сервера. На гэты раз у нас ёсць іншыя праблемы - мы не ведаем, калі пераважнага пастаўшчыка маецца. Можна, вядома, зрабіў некаторыя запланаваныя задачы, якая б звярнуцца за просты (кароткі) пераклад напрыклад, раз у гадзіну / дзень, каб праверыць яго. Так што ў гэтай стратэгіі мы павінны вырашыць, як часта па змаўчанні, такой задачы, мяркуюць, каб працаваць. Вядома, мы б праверыць яго толькі тады, калі некаторыя пастаўшчык пазначаецца як не даступныя.
Акрамя таго, калі мы адзначаем правайдэраў як недаступныя - што рабіць, калі мы ведаем, што ўсе правайдэры не даступны - дадаць некаторую інфармацыю для канчатковага карыстальніка, ці проста перавесці тое, што знаходзіцца ў кэшы, а астатняе, як арыгінал, без якога-небудзь дадатковую інфармацыю аб часовым адсутнасць перакладу пастаўшчыкоў .

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

Іншая справа, каб наладзіць правайдэраў чаргу для кожнай моўнай пары асобна. У гэты момант Б. прадпрыемства ўжо дазваляе наладзіць пераклад пастаўшчыка для кожнай моўнай пары. Я думаю, што мы можам змяніць яго ад аднаго значэння да значэнняў, падзеленых коскамі (CSV). Такім чынам, мы будзем ведаць, для кожнай моўнай пары, якія правайдэры падтрымліваюць гэтую перакладзе і якія парадку перавагі (справядлівы парадак у спісе CSV).

Звярніце ўвагу: гэта будзе мець некаторы ўплыў на прадукцыйнасць у любым выпадку. Замест таго каб ствараць адзін аб'ект для перакладу мы павінны будзем стварыць масіў такіх аб'ектаў і дадатковы аб'ект ўпакоўка (каб зрабіць яго празрыстым для іншых частак кода і менш памылак схільныя). Вядома, мы не будзем ствараць аб'екты для правайдэраў мы ведаем, не даступныя ў дадзены момант.
Рашэнне для гэтага было б пераналадзіць для лепшай прадукцыйнасці і выдаляць правайдэраў чарзе - гэтак жа, як гэта прама цяпер - аднаму асобе ў моўнай пары.
Гэта не павінна быць дарагім для выканання, але ўсё яшчэ некаторыя дадатковыя логікі і памяці.

Калі ласка, скажыце, які варыянт з'яўляецца пераважным.

[vBET]

І яшчэ адно магчымае рашэнне. Калі мы будзем адзначаць ўвесь API, як няма і праверыць яго на запланаванае заданне яго даступным цяпер, то мы не павінны рабіць чарзе пастаўшчыкоў. Мы можам рабіць гэта такім чынам - заўсёды ствараецца толькі адзін перакладчык аб'екта (лепш, выкарыстанне памяці) і ў адным запыце мы просім аб пераводзе толькі аднаго правайдэра (лепш CPU). Калі ён будзе недаступны, то ён будзе пазначаны як не даступныя, а вынікі будуць пустымі (у горшым надзейнасць). Але толькі першы, бо ў наступны раз мы будзем выкарыстоўваць іншага пастаўшчыка з чаргі. І ў выпадку, калі правайдэр не даступны, то манекен перакладчык будзе выкарыстоўвацца - вярнуць тыя ж значэння (але не кэшаваць яго), так што некаторыя часткі будуць не перакладзены, але старонка не будзе мець пустыя часткі, як цяпер, калі пастаўшчык не даступны.

[vBET]

Проста хутка аб'ява - мы ўжо ажыццяўляюць гэтую функцыю.

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

[Simon Lloyd]

Мае думкі былі адправіць праверыць пераклад першае, каб убачыць, калі пераважнага пастаўшчыка маецца, так што вы далі нам код, каб праверыць, Google або MS рэагуе, таму ў момант заходу на тэставы пераклад googleapi (імя майго тэставага файла з вашага тэставага кода ), калі пераклад дакладна выкарыстоўваць аддаеце перавагу, калі пераклад flase або код не 200, то паспрабуйце наступны правайдэра ў спіс і выконваць свае API тэст перад выкарыстаннем.

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

Мяркуючы, Daft імёны я ўвайшоў былі рэальнымі пастаўшчыкамі, па выкліку для перакладу тэставага кода MS будзе працаваць, калі адказ 200 выкарыстоўваць MS, калі не запускаць код MyTranslator тэст, праверыць адказ на 200, калі так, выкарыстоўваць яго, калі не запускаць Google тэставы код **** ****** і г.д.

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

Спадзяюся, я растлумачыў, што нармальна так што вы атрымаеце мая ідэя, я думаю, усё гэта магло б быць зроблена проста, што малыя і праверыць, ці не захоўваючы нічога.

[Simon Lloyd]

Проста хутка аб'ява - мы ўжо ажыццяўляюць гэтую функцыю.

Мы хочам, каб вызваліць яго хутка (як бэта) з-за агульных праблем, выкліканых абмежаваннямі, устаноўленымі перакладу правайдэраў. Мы таксама шукаем для іншых API, якая можа быць падтрымана Б. прадпрыемства :) Я паслала вам адзін ці два (у пост вы выдалілі з-за спасылкі), што вы маглі б падысці, калі вы хочаце бэта добраахвотніка я да вашых паслуг :)

[vBET]

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

Ваша паведамленне было ціха выдалены, так як яго змест рэкламы напісаны кімсьці іншым, але ў нас ёсць доступ да гэтага паведамлення, і мы на гэта :)

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

Такім чынам, мы працуем над паляпшэннем Б. прадпрыемства і зрабіў яго так танна, як у выкарыстанні магчыма :)

[vBET]

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

[Simon Lloyd]

Дзякуй Майкл, я зрабіў хуткі пост у ТАГТ Faq якія, несумненна, вам прыйдзецца выдаліць, таму што яго не правільнае месца для яго :) Калі вы хочаце выпрабаваць на аа жывы шчыт, які выклікае шмат перакладаў PM мне, і я дам Вам доступ да каранёвым AdminCP і форуму, я таксама паставіць Google пераклад мяжа, які я паставіў уверх і ўніз па вашай камандзе, каб вы маглі праверыць :)

[vBET]

Добра так. Пастаўшчыкі чаргу рэалізавана на і ён будзе ўключаны ў выпусках 3.5.1 і 4.4.3. Б. прадпрыемства 3.5.1 выйдзе сёння. vBET4.4.3 ўсё яшчэ знаходзіцца ў стадыі выпрабаванняў. Бут рэлізы будуць BETA так што кожны можа праверыць яго ў вялікіх форумах, што тэст адзін. Звярніце ўвагу, што мы ўжо пратэставалі яго 3.5.1 на адным з нашых рэальных форумах. Тым не менш з-за важных змен, якія яна ў стадыі бэты першымі.

[Simon Lloyd]

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

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

[vBET]

Гэта не павінна быць так, гэта прама цяпер. Дзякуй за вашу ўвагу. Тым не менш - не. Гэта не мае ніякага сэнсу. Калі ласка, звярніце ўвагу, што просяць у пісьмовым перакладзе адымае больш часу, рэч у цэлым Б. прадпрыемства (і гэта не залежыць ад нас). Там няма сэнсу розуму тысячы запыце, калі мы ўжо дасягаюць межаў. Гэта Increaser час водгуку, узровень загрузкі працэсара і памяці таксама спажыванне (больш за аб'ектна створаны).

Мы выявілі, што Google інфармацыю аб магчыма TOS злоўжывання знікае праз некаторы час. Мы не ведаем, але, магчыма, калі мы будзем пастаянна пытацца, калі мы ўжо заблакаваныя, Google можа заблакаваць больш часу. Можа быць, не, але па-ранейшаму актуальныя стратэгіі значна лепш для прадукцыйнасці. У канцы ў вас ёсць кругавая праверкі. Калі ён не даступны, ён не будзе даступная, а іншая выкарыстоўваецца. Калі іншы не даступная, тое ж самае. Мы проста не праверыць гэта зноў даступны кожнаму запыце, што не мае сэнсу (гэта можа быць мільёны запытаў, перш чым яно будзе даступна) толькі адзін раз у гадзіну. І калі ён будзе даступны ён будзе адзначаны мяне так што мы вернемся да пераважным адзін - і ў вас ёсць кола тут. Таксама тэставанне кожны раз будзе зроблены межы дасягаецца хутчэй або выдаткі вышэй, калі вы выкарыстоўваеце заплаціў пераклады (яна па-ранейшаму лічыцца пераклад).
Акрамя таго, мы гатовыя да таго, іншыя пастаўшчыкі таксама. Калі мы будзем падтрымліваць больш за 2 такая стратэгія будзе забойцам для вашага сервера. Уявіце сабе 5 Тэставанне выклікаў па розных правайдэрам, а затым рэальнага перакладу для кожнага перакладу запыту. Не, дзякуй за вашу ідэю :) Мы вельмі цэнім карыстальнікі ідэй, на гэты раз мы застанемся з фактычным рашэннем.

Звярніце ўвагу, што вы можаце змяніць, як часта Б. прадпрыемства павінна праверыць наяўнасць пастаўшчыкоў. Зараз гэта адзін у гадзіну, але можна пераналадзіць, што ў панэль адміністратара -> Прызначаныя заданні -> Дыспетчар задач па раскладзе і ўсталюйце яго, напрыклад, за кожныя 10 хвілін 0 гэтак жа, як задача робата плакатаў RSS зрабіць гэта цяпер.

[vBET]

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

Змена было зроблена таму, што мы знайшлі на наш рэальны форум, які часта правайдэр недаступны на кароткі час. Мы будзем даследаваць яго больш шукаць іншую паляпшэнняў.

[Simon Lloyd]

Выдатная праца хлопцы :), у мяне падвышаны да гэтага, але будзе загружаць апошнія ўсталёўваць і выкарыстоўваць, што я ствару новую тэму для зваротнай сувязі па гэтым пытанні.