Cylchlythyr wirio a newid y APIs i gadw llif o gyfieithiadau

[Simon Lloyd]

Rwyf wedi fy terfyn cymeriad i google gosod i 100.000 perday felly gyda fy lleoliadau "bob tro Defnyddio Google", "Defnyddio Google API V2", "Defnyddiwch Google Canfod" wrth i gyrraedd y terfyn hwnnw a bellach yn cael canlyniadau o Google talu fyddai'n bosibl am ddim APIs yna cychwyn cynhyrchu canlyniadau?

Felly, er enghraifft, i ddefnyddio fy terfyn preset Google a Google bellach yn dychwelyd o ganlyniad i mi (yn ôl pob tebyg yn dychwelyd mewn cod gwall fel y rhai yn eich cod prawf Google) pan na fydd y canlyniad yn cael ei ddychwelyd byddai'n dda pe vBET adnabod yn awtomatig y cod bai ac Yna, anfonir cais i API arall fel Microsoft (neu unrhyw rai eraill y vBET yn ddiweddarach cefnogi) y ffordd yr ydym yn sicr o gael rhywfaint o ganlyniad i hynny - i mi y byddai hyn yn iawn werthfawr iawn o ystyried bod cyfyngiadau hyd yn oed gyda fersiynau talu, byddai'n caniatáu i chi ymestyn eich terfynau cyfieithiadau.

ee
Google yn gosod 100,000 Charcters y dydd> ddefnyddir busnes> vBET symud tuag at API nesaf yn rhestr> Microsoft 400k yr awr neu 4M pan ddaeth terfyn vBET gwirio API nesaf a blaenorol i weld a oes terfyn yn cael ei godi neu rywfaint o lwfans> naill ai symud i API nesaf yn ôl i Google talu pan gyrhaeddodd terfyn eto> gwirio API nesaf .... ac ati ac felly byddai'r gwirio cylchlythyr ar ôl recieving mewn cod gwall yn parhau, felly 'n bert lawer o allu gyson i gael cyfieithiadau.

[vBET]

Yr wyf yn deall ac yn eich disgrifiad eich pwynt. Nawr mae'n rhaid i ni gael gwybod sut y mae'n debyg i weithio yn dechnegol.

Un mater i weld yma yw sut y byddwn yn cydnabod bod gennym eisoes yn cyfyngu ar gael ar ôl y rhai lle gyrraedd o'r blaen.

Gallwn syml bob tro ofyn i ddarparwr dewisol ac yna ewch i'r un nesaf. Bydd hyn yn costio perfformiad - oherwydd ar gyfer pob cais i dudalen sy'n gofyn am gyfieithu, byddwn yn gwneud galwad aflwyddiannus i ddarparwr ffafrio, yna i un nesaf (fel y gall fod yn nifer o alwadau aflwyddiannus pryd y bydd vBET cefnogi mwy o APIs).

Byddai eraill yn cael eu ateb i storio gwybodaeth nad yw darparwyr a ffafrir ar gael ac yn mynd yn uniongyrchol i'r un nesaf. Byddai hyn yn llawer cyflymach, gan fod gwirio amrywiol lleol yn llawer cyflymach nag aros am ymateb gan gweinydd allanol. Y tro hwn, rydym wedi cyhoeddi eraill - nid ydym yn gwybod pan fydd darparwr gorau ar gael. Gallwn, wrth gwrs, gwneud rhai tasgau trefnu a fyddai'n gofyn am syml (byr) cyfieithu er enghraifft unwaith yr awr / dydd i wirio ei fod. Felly, yn y strategaeth hon mae'n rhaid i ni benderfynu pa mor aml trwy ddiffyg tasg o'r fath yn debyg i'r gwaith. Wrth gwrs, byddem yn gwirio ei fod yn unig pan fydd rhai darparwr ei farcio â ddim ar gael.
Hefyd, os ydym yn nodi darparwyr fel gael - beth i'w wneud pan fyddwn yn gwybod nad yw pob darparwr ar gael - ychwanegu rhywfaint o wybodaeth ar gyfer defnyddiwr terfynol neu dim ond gyfieithu beth sydd yn cache ac mae'r gweddill yn wreiddiol, heb unrhyw wybodaeth ychwanegol am ddiffyg dros dro o ddarparwyr cyfieithu .

Ni waeth pa ffordd y bydd yn cael ei wneud, bydd Google yn cael ei drin fel un API (v1 neu f2 yn dibynnu ar ffurfwedd) - nid oes unrhyw synnwyr i rannu'r iddo, oherwydd bydd Google yn v1 cael ei gau yn fuan iawn.

Peth arall yw caniatáu i ffurfweddu darparwyr ciw ar gyfer pob pâr o ieithoedd ar wahân. Ar hyn o bryd vBET eisoes yn caniatáu i ffurfweddu darparwr cyfieithu ar gyfer pob pâr iaith. Yr wyf yn meddwl y gallwn ei newid o un gwerth i werthoedd gwahanu coma (CSV). Fel hyn, byddwn yn gwybod ar gyfer pob pâr iaith y mae darparwyr yn cefnogi'r cyfieithiad hwn a beth yw'r dewisiadau gorchymyn (ychydig gorchymyn ar restr CSV).

NODER: bydd hyn yn cael rhywfaint o effaith perfformiad beth bynnag. Yn hytrach na chreu un gwrthrych ar gyfer cyfieithu bydd yn rhaid i greu amrywiaeth o wrthrychau o'r fath ac gwrthrych lapio ychwanegol (i'w wneud yn dryloyw ar gyfer rhannau eraill o'r cod a chwilod yn llai tueddol). Wrth gwrs ni fyddwn yn creu gwrthrychau ar gyfer darparwyr rydym yn gwybod nad ydynt ar gael ar hyn o bryd.
Datrysiad ar gyfer y byddai hyn yn cael ei ail-gyflunio'r ar gyfer gwell perfformiad a thynnu darparwyr ciw - yn union fel ei bod yn iawn erbyn hyn - mae un darparwr i bob pâr iaith.
Ni ddylai hyn fod yn ddrud am berfformiad, ond mae rhai yn dal i resymeg ychwanegol a defnyddio cof.

Dywedwch pa ateb ei ffafrio.

[vBET]

Ac un yn fwy ateb posibl. Os byddwn yn nodi API cyfan gan nad yw ar gael ac yn gwirio iddo gan tasg a drefnwyd ar ei fod ar gael erbyn hyn, yna nid oes rhaid i ni wneud rhes o ddarparwyr. Gallwn wneud hynny ar y ffordd hon - bob amser yn cael ei greu dim ond un gwrthrych cyfieithydd (chof chynefod well) ac mewn un cais y byddwn yn gofyn am gyfieithu mai dim ond un darparwr (CPU gwell). Os bydd nad yw ar gael, yna bydd yn cael ei farcio gan nad yw ar gael a chanlyniadau fod yn wag (dibynadwyedd gwaethaf). Ond dim ond un yn gyntaf, oherwydd y tro nesaf byddwn yn defnyddio darparwr arall oddi wrth y ciw. Ac yn achos os oes darparwr ar gael, yna bydd cyfieithydd ffug yn cael ei ddefnyddio - dychwelyd un gwerthoedd (ond nid ydynt yn cache yw'n), felly ni fydd rhai rhannau cael eu cyfieithu, ond ni fydd yn cael rhannau dudalen wag fel yn awr pan na fydd darparwr ar gael.

[vBET]

Just cyhoeddiad cyflym - rydym eisoes yn gweithredu'r nodwedd hon.

Yr ydym am ei rhyddhau cyflym (fel BETA) oherwydd problemau cyffredin, a achosir gan terfynau a osodwyd gan ddarparwyr cyfieithu. Yr ydym hefyd yn edrych ar gyfer APIs eraill y gellir eu cefnogi gan vBET

[Simon Lloyd]

Fy meddyliau oedd i anfon siec y cyfieithiad gyntaf i weld a yw darparwyr a ffafrir ar gael, er mwyn i chi i ni roi cod i weld os google neu MS yn ymateb, felly ar adeg ei galw am gyfieithu prawf googleapi (enw'r fy ffeil prawf gyda eich cod prawf ) os cyfieithiad yn wir preffered defnyddio, os nad yw cyfieithiad flase neu god yw 200 yna ceisiwch darparwr nesaf yn y rhestr ac yn perfformio eu prawf API cyn eu defnyddio.

Gallech gael listbox lle y gall y defnyddiwr rhestr pob un darparwr bob llinell yn nhrefn blaenoriaeth (mae hyn yn caniatáu i pan fyddwch yn ychwanegu cefnogaeth ar gyfer APIs eraill y gall y defnyddiwr yn unig eu hychwanegu at y rhestr), fel y gallai fy rhestr edrych fel hyn:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Gan dybio y byddai'r enwau gwirion i gofnodi eu darparwyr go iawn, ar y galw am brawf cyfieithu cod MS rhedeg, os ymateb yn defnyddio MS 200 os na rhedeg cod prawf MyTranslator, gwirio ymateb ar gyfer 200 os ydych yn ei defnyddio os na rhedeg cod prawf Google **** ****** ac ati

Byth yn y ffordd hon yn rhaid i chi storio unrhyw wybodaeth am ddarparwyr (fel arall, gallech fod wedi blychau testun lle y gallai defnyddwyr fynd i mewn eu terfynau a osodwyd ar gyfer pob darparwr ond fi yn meddwl wuld y wybodaeth hon yn ddiwerth fel y gallent ei newid ac y byddai'n golygu mwy o ddod yn ôl a gwirio ymlaen cyn gwneud cyfieithiad) na fyddai byth yn rhaid i chi boeni os terfynau ar gael eto, felly nid oes angen am swydd cron i redeg i wirio'r rhain, fyddai'r llwyth ar weinydd ar gyfer yr un archwiliad cyfieithiad bach (y cod a ddarparwyd gennych yn y Cwestiynau Cyffredin) yn cael eu dim byd.

Gobeithio i Esboniodd fod iawn fel eich bod yn cael fy syniad, i feddwl y gallai hyn i gyd gael ei wneud yn unig gan y siec bach a heb storio unrhyw beth.

[Simon Lloyd]

Just cyhoeddiad cyflym - rydym eisoes yn gweithredu'r nodwedd hon.

Yr ydym am ei rhyddhau cyflym (fel BETA) oherwydd problemau cyffredin, a achosir gan terfynau a osodwyd gan ddarparwyr cyfieithu. Yr ydym hefyd yn edrych ar gyfer APIs eraill y gellir eu cefnogi gan vBET

Anfonais i chi un neu ddau o (mewn swydd rydych dileu oherwydd y cysylltiadau) y gallech ei dull gweithredu, os ydych am wirfoddolwr beta rwy'n eich dyn

[vBET]

Anfonais i chi un neu ddau o (mewn swydd rydych dileu oherwydd y cysylltiadau) y gallech ei dull gweithredu, os ydych am wirfoddolwr beta rwy'n eich dyn

Eich neges ei ddileu dawel, am ei chynnwys ei hysbyseb ysgrifenedig gan rywun arall, ond rydym yn cael mynediad at y neges hon ac rydym ar ei

Rydym hyd yn oed eisoes yn anfon e-bost gwestiwn i un o'r darparwyr hynny cyfieithiadau am manylion talu. Mae rhai o'r rheiny yn cael eu talu (hyd yn oed pan gaiff ei disgrifio fel rhad ac am ddim nad yw ar API lefel - un peth rydych wedi gyda Google gallwch chi gyfieithu rhad ac am ddim gan porwr, ond nid gan API), ond gall prisiau yn gystadleuol, felly mae'n dal i fod yn dda (prisiau mwy o gystadleuaeth yn well).
Mae rhai yr ydym wedi ymchwilio yw'r rhai a wir yn allanol cyfieithiadau API neu ychydig o eiriaduron lleol a ysgrifennwyd gan ddefnyddwyr ei hun (mae hyn hefyd yn un peth ar ein rhestr todo - yn caniatáu i addasu a'i roi cyfieithiadau eu hunain) - Radek wedi rhan hon.

Felly rydym yn gweithio i wella vBET a wnaed fel rhad yn defnyddio â phosibl

[vBET]

Rydym yng nghyfnodau olaf tesing swyddogaethau newydd. Gall eich bod eisoes yn gweld disgrifiad newid: http://www.vbenterprisetranslator.co....html # post8914 (Gweler para NODYN)

[Simon Lloyd]

Diolch Michael, i wneud swydd yn gyflym yn yr FAQ nad oes unrhyw amheuaeth y bydd yn rhaid i chi ddileu am fod ei nid y lle cywir ar gyfer ei os hoffech i roi prawf ar y bwrdd yn byw aa bod llawer o gyfieithiadau o alwadau PM mi a byddaf yn rhoi mynediad i admincp a fforwm gwraidd, bydd hefyd yn rhoi i gyfyngu ar cyfieithu google bod fi wedi sefydlu ac i lawr yn eich gorchymyn fel y gallwch brofi

[vBET]

Iawn felly. Darparwyr ciw yn cael ei weithredu a bydd yn cael ei gynnwys mewn datganiadau i'r 3.5.1 a 4.4.3. Bydd vBET 3.5.1 yn cael ei ryddhau heddiw. vBET4.4.3 yn dal i fod yng nghyfnod prawf. Bydd datganiadau Booth yn BETA fel y gall pawb ei brofi mewn fforymau mwy sy'n brawf un. Os gwelwch yn dda nodi ein bod eisoes yn profi 3.5.1 ar un o'n fforymau go iawn. Still oherwydd newidiadau bwysig yw yng nghyfnod BETA gyntaf.