Qarkorja kontrolluar dhe switching e TV për të mbajtur rrjedhjen e përkthimeve

[Simon Lloyd]

Unë kam kufirin e mia karakter për google vendosur për 100.000 perday këtë me vetitë e mia "Gjithmonë përdorni Google", "Përdorimi Google API V2", "Përdorimi Zbulimi Google" kur i arritur që kufizojnë dhe nuk merrni rezultatet nga Google paguar do të jetë e mundur për TV falas pastaj të fillojë prodhimin e rezultateve?

Kështu për shembull, unë përdorni Google limitin e mia paraprakisht dhe Google nuk kthen një rezultat për mua (ndoshta kthehen një kod gabimi si ato në Google kodin tuaj provë) kur rezultati nuk është kthyer ajo do të jetë mirë në qoftë se vBET automatikisht njohur kodin faj dhe dërguar pastaj në një tjetër kërkesë API si Microsoft (apo çfarëdo të tjerë që më vonë mbështet vBET) në këtë mënyrë ne jemi të sigurt për të marrë disa rezultatin - për mua kjo do të jetë shumë e shumë të vlefshme duke pasur parasysh se nuk janë kufizime edhe me versionet e paguar, ajo do të ju lejojnë të zgjeruar kufijtë përkthimet tuaja.

p.sh.
Google vendosur 100.000 Charcters në ditë> përdorura deri> vBET për API lëvizje tjetër në listën e> 400k Microsoft për një orë ose 4m kur kufiri arriti vBET kontrolloni API ardhshëm dhe të mëparshme për të parë nëse kufi hiqet ose nëse ka disa ndihmë> ose të shkojë në API tjetër ose përsëri në Google paguhet kur kufiri arriti përsëri> kontrolloni API ardhshëm .... etj dhe kështu kontrollin rrethore pas marrjen e një kod gabimi do të mbajnë në, kështu që shumë e shumë aftësi të vazhdueshme që të ketë përkthime.

[vBET]

Unë e kuptoj përshkrimin tuaj dhe pika juaj. Tani ne kemi për të gjetur se si mendoj për të punuar teknikisht.

Një çështje unë shoh këtu është se si ne do të pranojmë se ne tashmë kemi në dispozicion, pasi ato kufij ku arriti më parë.

Ne thjesht mund të pyesni ofruesin çdo herë të preferuar dhe pastaj të shkojnë në një tjetër. Kjo do të kushtojë punën - sepse për çdo kërkesë për faqe që kërkon përkthimin, ne do të bërë thirrje të pasuksesshme për ofruesin e preferuar, pastaj një tjetër (kështu që ajo mund të jetë disa telefonata të pasuksesshme, kur vBET do të mbështesë më shumë TV).

Zgjidhje të tjera do të ishte për të ruajtur informacione se ofrues i preferuar nuk është në dispozicion dhe të shkojnë direkt në një tjetër. Kjo do të jetë shumë më shpejt, sepse kontrolluar ndryshueshme lokale është shumë më shpejt se presin përgjigje nga server të jashtëm. Këtë herë ne kemi çështje të tjera - ne nuk e dimë kur ofrues i preferuar është në dispozicion. Ne mund të bëhet sigurisht disa detyra të planifikuara që do të kërkojë për përkthim të thjeshtë (të shkurtra) për shembull një herë në orë / ditë për të kontrolluar atë. Pra, në këtë strategji, ne duhet të vendosë sa shpesh by default detyrë të tillë mendoj për të punuar. Natyrisht ne do të shikoni vetëm kur disa ofrues është i shënuar si jo në dispozicion.
Gjithashtu nëse ne shënojë ofruesit të padisponueshëm - çfarë duhet të bëni kur e dimë se të gjithë ofruesit e nuk janë në dispozicion - të shtoni disa të dhëna për përdoruesit fund ose vetëm përkthejnë atë që është në sasi dhe pjesa tjetër si origjinale, pa ndonjë informacion shtesë në lidhje me mungesën e përkohshme të ofruesve të përkthimit .

Pa marrë parasysh se cilën mënyrë do të bëhet, Google do të trajtohet si një API (v1 v2 ose në varësi të konfigurimit) - nuk ka kuptim për të ndarë atë, sepse Google v1 do të mbyllet shumë shpejt.

Një tjetër gjë është që të lejojë për të konfiguruar ofruesit radhë për secilën palë gjuhën vete. Në këtë moment vBET tashmë lejon të konfiguroni ofruesin e përkthimit për çdo palë gjuhën. Unë mendoj se ne mund të ndryshojë atë nga një vlerë të vlerave të ndara me presje (CSV). Në këtë mënyrë ne do të dimë për secilën palë gjuhën që ofruesit e mbështesin këtë përkthim dhe çfarë janë preferencat e rendit (vetëm qëllim në listën CSV).

PLEASE NOTE: kjo do të ketë ndonjë ndikim të performancës anyway. Në vend të krijimit të një objekt për përkthim do të keni për të krijuar koleksionin e objekteve të tilla dhe objekti shtesë ambalazhi (për ta bërë atë transparent për pjesët e tjera të kodit dhe bugs pak të prirur). Sigurisht që ne nuk do të krijojë objekte për ofruesit e dimë nuk janë në dispozicion në këtë moment.
Zgjidhja për këtë do të jetë për të rikonfiguruar për performancë më të mirë dhe për të hequr ofruesit radhë - ashtu si ai është tani - një ofrues per palë gjuhësore.
Kjo nuk duhet të jetë i shtrenjtë për punën, por ende disa logjikën shtesë dhe konsumin e kujtesës.

Ju lutem më tregoni se cila zgjidhje është e preferuar.

[vBET]

Dhe një zgjidhje më të mundshme. Nëse ne do të shënojë tërë API si jo në dispozicion dhe kontrolloni atë nga detyra të planifikuara është në dispozicion tani, atëherë ne nuk kemi për të bërë radhë të ofruesve. Ne mund ta bëjë këtë në këtë mënyrë - gjithmonë është krijuar vetëm një objekt translator (përdorimin më të mirë kujtesës) dhe në një kërkesë për përkthim ne kërkojmë vetëm një ofrues (CPU më të mirë). Në qoftë se kjo nuk do të jetë në dispozicion, atëherë ajo do të shënohet si jo në dispozicion dhe rezultatet do të jenë të zbrazëta (besueshmërinë keq). Por vetëm një të parë, sepse herën tjetër ne do të përdorim një tjetër ofrues nga radhë. Dhe në rast se nuk ka ofrues është i disponueshëm, atëherë përkthyesi bedel do të përdoret - kthim të njëjtat vlera (por nuk e cache të) kështu që disa pjesë nuk do të përkthehet, por faqja nuk do të ketë pjesë të zbrazët si tani kur ofruesi nuk është në dispozicion.

[vBET]

Vetëm njoftimi të shpejtë - ne jemi tashmë zbatimin këtë funksion.

Ne duam për lirimin e tij të shpejtë (si BETA) për shkak të çështjeve të përbashkëta, të shkaktuara nga limitet e përcaktuara nga ofruesit e përkthimit. Ne jemi gjithashtu duke kërkuar për TV të tjera të cilat mund të mbështetur nga vBET :)

[Simon Lloyd]

Mendimet e mia kanë qenë të dërguar të përkthimit kontrolloni parë për të parë nëse ofrues i preferuar është në dispozicion, kështu që ju na dha kodin për të parë nëse google apo MS është përgjigjur, kështu që në kohën e thirrjes për përkthim provë googleapi (emri i dosjen time provë me kodin tuaj provë ) nëse përkthimi është përdorimi i vërtetë preffered, nëse përkthimi është flase apo kodi nuk është 200 atëherë provoni provider e ardhshme në listë dhe të kryejnë provimin e tyre API para se të përdorni.

Ju mund të keni një listbox ku përdoruesi mund të listës çdo një ofrues për çdo rresht, në mënyrë të preferencës (kjo lejon kur ju të shtoni mbështetje për TV të tjera përdoruesit mund vetëm të shtoni ato në listë), kështu që lista ime mund të duket si ky:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Duke supozuar emrat e paarsyeshëm i hyri ishin të ofruesve të vërtetë, në thirrjen për përkthim kodin MS provë do të kandidojë, në qoftë se 200 përgjigje përdorin MS nëse nuk drejtuar provë kodin MyTranslator, kontrolloni përgjigje për 200 nëse po përdorni atë nëse nuk e drejtuar kodin Google provë **** ****** etj

Në këtë mënyrë ju kurrë nuk keni për të ruajtur çdo informacion mbi ofruesit (përndryshe ju mund të ketë kuti teksti, ku përdoruesit mund të hyjnë në limitet e tyre të vendosur për çdo ofrues, por unë mendoj se ky informacion të jetë i kotë wuld si ata mund të ndryshojë atë dhe kjo do të thotë më shumë kontrollin mbrapa dhe kontrollin e përpara përpara se të bëjnë një përkthim) ju kurrë nuk do të duhet të shqetësohen në qoftë se kufijtë ishin në dispozicion përsëri kështu që nuk ka nevojë për një punë cron për të kandiduar për të kontrolluar këto, ngarkesën në server për këtë kontroll një përkthim të vogël (kodin e keni dhënë në FAQ) do të asgjë.

Shpresojmë i shpjegoi se ok kështu që ju merrni ideja ime, unë mendoj se kjo mund të jetë bërë vetëm nga ajo kontroll të vogla dhe pa ruajtjen asgjë.

[Simon Lloyd]

Vetëm njoftimi të shpejtë - ne jemi tashmë zbatimin këtë funksion.

Ne duam për lirimin e tij të shpejtë (si BETA) për shkak të çështjeve të përbashkëta, të shkaktuara nga limitet e përcaktuara nga ofruesit e përkthimit. Ne jemi gjithashtu duke kërkuar për TV të tjera të cilat mund të mbështetur nga vBET :) Unë të dërgova një ose dy (në një post ju fshihet për shkak të lidhjeve) që ju mund të drejtohen, qoftë se ju doni një vullnetar beta Unë jam njeri :) tuaj

[vBET]

Unë ju dërgoi një ose dy (në një post ju fshihet për shkak të lidhjeve) që ju mund të drejtohen, qoftë se ju doni një vullnetar beta Unë jam njeri :) tuaj

Mesazhi juaj u fshi me zë të ulët, për shkak se përmbajtja e tij është shpallje e shkruar nga dikush tjetër, por ne kemi qasje në këtë mesazh dhe ne jemi në të :)

Ne edhe tani dërgoni një email pyetje për një nga ofruesit e këtyre përkthimeve në lidhje me detajet e pagesës. Disa nga ata janë të paguar (edhe kur ajo është përshkruar si më e lirë se nuk është në nivel API - njëjtën gjë keni me Google ju mund të përkthehet pa nga shfletuesit, por jo me API), por çmimet mund të jetë konkurruese, kështu që është ende e mirë (çmime më të konkurrencës më të mirë).
Disa ne kemi hetuar janë ato me të vërtetë të jashtme përkthime API ose vetëm fjalorë lokale të shkruar nga vetë përdoruesit (kjo është gjithashtu një gjë në listën tonë TODO - të lejojë që të modifikoj dhe të vënë përkthimet e veta) - Radek e ka këtë pjesë.

Pra, ne jemi duke punuar për të përmirësuar vBET dhe e bëri atë si të lirë në përdorimin sa të jetë e mundur :)

[vBET]

Ne jemi në fazat e fundit të tesing funksionalitet të ri. Ju tashmë mund të shihni përshkrimin ndryshua: # post8914 http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.html (shih shënimin e fundit)

[Simon Lloyd]

Thanks Michael, kam bërë një post të shpejtë në taht FAQ cilën nuk ka dyshim që ju do të keni për të hequr sepse nuk e tij vendin e saktë për atë :) në qoftë se ju do të donte për të provuar në bord aa gjallë, që e quan shumë përkthime PM mua dhe unë do të jap ju qasje në admincp forum dhe rrënjë, unë do të vënë kufirin google përkthimit që i kanë ngritur lart dhe poshtë në komandën tuaj kështu që ju mund ta provoni :)

[vBET]

OK kështu. Ofruesit radhë po zbatohet dhe do të përfshihen në 3.5.1 dhe 4.4.3 njoftime. vBET 3.5.1 do të dalë sot. vBET4.4.3 është ende në fazën testuese. Shtyp Kabina do të jetë Beta kështu që të gjithë mund ta provoni atë në forumet më të mëdha që një provë. Ju lutem vini re se ne jemi tashmë testimin 3.5.1 në një nga forumet tona reale. Ende për shkak të ndryshimeve të rëndësishme është në fazën beta e parë.

[Simon Lloyd]

A ka nevojë të jetë një detyrë e caktuar dhe një ofrues të veçantë fikur për një orë në një kohë?, I bëri një sugjerim këtu Qarkorja kontrolluar dhe switching e TV për të mbajtur rrjedhjen e përkthimeve, ku ndoshta ne mund gjithmonë të fillojë në krye të ofruesve tonë lista dhe të bëjë thirrje provë (si e keni dhënë për të provuar përgjigjen Google dhe Microsoft përgjigje) nëse testi përgjigja thirrjes është 200 ose tekst është përkthyer pastaj përdorimin se ofruesi, në qoftë se përgjigja nuk është 200 ose tekst test nuk është përkthyer (duke përdorur të njëjtën tekst për secilin test dhe REGEX për të parë tekstin e përkthyer), pastaj të shkojë në ofruesin e ardhshëm, çdo thirrje në përkthim mund të pastaj të fillojë në krye të listës dhe punës poshtë

Nuk ka një rezultat të zbrazët do të ishte mirë, sepse një herë ne kemi një kthim bosh thats si mbetet, unë kam pasur tashmë shumë njerëz ankohen se ky është rasti në forum time.

[vBET]

Ajo nuk duhet të jetë në këtë mënyrë, kjo është e drejtë tani. Faleminderit për shënimin tuaj. Ende - nr. Ajo nuk ka kuptim. Ju lutemi vini re se duke kërkuar për përkthimin e jashtme është më gjë e konsumon kohë në vBET tërë (dhe kjo nuk varet nga ne). Nuk ka asnjë kuptim për të çmendur mijëra të kërkesës, kur ne tashmë të arritur kufijtë. Kjo do increaser kohë përgjigje, konsumin CPU dhe konsumin e kujtesës (edhe objekti më i krijuar).

Ne zbuluam se informacioni Google lidhje ndoshta TOS abuzimit zhduket pas disa kohe. Ne nuk e dimë, por ndoshta në qoftë se ne do të vazhdojmë pyetur kur ne jemi të bllokuar tashmë, Google mund të bllokojë për më shumë kohë. Ndoshta jo, por ende strategjia aktuale është shumë më mirë për performancën. Në fund ju keni kontrolluar rrethore. Nëse dikush nuk është në dispozicion ajo është e shënuar si të padisponueshme dhe një tjetër është përdorur. Në qoftë se një tjetër nuk është në dispozicion, atëherë e njëjta gjë ndodh. Ne thjesht nuk e kontrolloni sërish është në dispozicion çdo kërkesë që nuk ka kuptim (kjo mund të jetë miliona pyetje para se ai do të jetë në dispozicion) vetëm një herë në orë. Dhe nëse kjo do të jetë në dispozicion do të më shënuar kështu që ne do të kthehemi në një preferuar - dhe ju keni një rreth këtu. Gjithashtu testimi çdo herë do të bëhen kufijtë tuaj të arritur më shpejt ose kostot më të larta qoftë se ju përdorni përkthime të paguar (ajo ende llogaritet si përkthimi).
Gjithashtu ne jemi të përgatitur që të kemi ofruesit e tjerë. Kur ne do të mbështesë më shumë se 2 strategji e tillë do të jetë një vrasës për serverin tuaj. Imagjinoni 5 thirrjet testimit për ofruesit e ndryshme dhe pastaj përkthimi i vërtetë për çdo kërkesë të përkthimit. Faleminderit për Nr :) tuaj idea Ne vlerësojmë përdoruesit ide, këtë herë ne do të qëndrojnë me zgjidhje aktuale.

Ju lutem vini re se ju mund të ndryshoni se sa shpesh vBET duhet të kontrolloni ofruesit disponibilitetin. Tani ajo është një në orë, por ju mund të rikonfiguruar se në CP Admin -> Detyrat e planifikuara -> Menaxher Scheduled Task dhe vendosur atë për shembull për çdo 10 minuta 0 ashtu si detyrë Robot RSS Poster bëjë atë tani.

[vBET]

Bërë pak ndryshim - ne do të kontrolluar disponueshmërinë provider jo një herë në orë, por çdo 10 minuta. Nëse ju upgraded tashmë për të vBET 3.5.1 para se këtë mesazh, ju lutem vetëm shkarko paketë vBET përsëri dhe ngarkoni fotografi produktit përsëri.

Ndryshimi u bë për shkak se kemi gjetur në forumin tonë të vërtetë që shpesh ofrues është i padisponueshëm për kohë të shkurtër. Ne do të hetojë më për të kërkuar një tjetër përmirësime.

[Simon Lloyd]

Djema e madhe puna :), i kanë modernizuar për këtë, por do të shkarkoni dhe të përdorni fix fundit që unë do të krijojë një fije të re për reagime për këtë.