Kruhová kontrola a prepínanie rozhraní API, aby prietok preklady

[Simon Lloyd]

Mám znakov pre Google nastavený na 100.000 perday, takže sa moje nastavenie "Vždy používať Google", "Use Google API V2", "Use Google detekcie" Keď som sa dosiahne tohto limitu, a už sa výsledky z platených Google by bolo možné zadarmo API a začať produkovať výsledky?

Tak napríklad použiť prednastavenému limitu môj Google a Google už vráti výsledok pre mňa (pravdepodobne vracajúci kód chyby rovnako ako v Google testu kód) Ak výsledkom nebude vrátený bolo by dobré, keby vBET automaticky uznané kód poruchy a potom sa zašle žiadosť iného API ako je Microsoft (alebo akékoľvek iné že vBET neskôr podporuje) týmto spôsobom sme zaistená dostať niektoré výsledok - to by pre mňa veľmi veľmi cenné Vzhľadom k tomu, že existujú limity ani s platených verziách, umožnila by ste rozšíriť vaše preklady limity.

napr
Google nastaviť 100.000 nepovolené znaky denne > využité > vBET presunúť do ďalšej API v zozname > Microsoft 400 k za hodinu alebo 4 M, keď dosiahne limit vBET kontrola budúci API a predchádzajúca pozri Ak limit je zrušený alebo má určitý príspevok > buď presunúť na ďalšiu API alebo späť na Google platené opäť dosiahnutí limitu > skontrolovať ďalšie API.... atď a tak kruhové kontrola po príjemcom kód chyby by so sebou, takže docela oveľa konštantný schopnosť mať preklady.

[vBET]

Chápem vaše popis a svoje miesto. Teraz musíme zistiť, ako to asi fungovať technicky.

Jeden problém vidím tu je, ako spoznajú, že už máme k dispozícii od hranice tých, kde predtým.

Môžete jednoducho zakaždým žiadame preferovaný poskytovateľ a potom prejdite na ten ďalší. To bude stáť výkon-, pretože pre každú žiadosť na stránku, ktorá vyžaduje preklad sme urobili ïal¹ích preferovaný poskytovateľa, potom na ďalšiu jeden (tak môže byť niekoľko neúspešné volania, keď vBET bude podporovať ďalšie API).

Iné riešenie by bolo pre ukladanie informácií, že preferovaným dodávateľom nie je k dispozícii, a prejsť priamo k ďalšej. To by bolo oveľa rýchlejšie, pretože kontrola lokálnych premenných je omnoho rýchlejší, než čakať na odpoveď z externého servera. Tentoraz sme sa ďalší problém - nevieme, kedy preferovaným dodávateľom je k dispozícii. Môžeme samozrejme urobil niektoré naplánované úlohy, ktoré by požiadať o jednoduchý (krátky), preklad napríklad raz za hodinu / deň, pozrieť sa na to. Takže v tejto stratégii sa musíme rozhodnúť, ako často implicitne ako úlohu Predpokladám, že sa do práce. Samozrejme, že by sme skontrolovať iba v prípade niektorých služieb je označený ako nie je k dispozícii.
Aj v prípade, označíme poskytovatelia nedostupné - Čo robiť, keď vieme, že všetci poskytovatelia nie sú k dispozícii - pridať niekoľko informácií pre koncových užívateľov, alebo len preložiť, čo je v cache a zvyšok je pôvodná, a to bez akékoľvek ďalšie informácie o dočasný nedostatok preklady .

Bez ohľadu na to, akým spôsobom to bude hotové, bude Google bude považovaný za jedno API (V1 a V2 v závislosti na konfigurácii) - Nemá zmysel deliť, pretože Google V1 bude uzavretá v najbližšej dobe.

Iná vec je umožniť nakonfigurovať poskytovateľov frontu pre každý jazyk pár oddelene. V tejto chvíli vBET už umožňuje konfigurovať preklad poskytovateľa pre každý jazyk pár. Myslím, že môžeme zmeniť ho z jednu hodnotu na hodnoty oddelené čiarkou (CSV). Týmto spôsobom budeme vedieť pre každý jazyk pár ktorých poskytovateľov podporujú tento preklad a aké sú predvoľby poradia (len poradie v zozname CSV).

PLEASE NOTE: to bude mať určitý dosah výkon mimochodom. Namiesto vytvárania jeden objekt na preklad sme budú musieť vytvoriť pole takéto objekty a ďalšie balenie objekt (aby bolo transparentné pre ostatné časti kódu a menej chýb náchylný). Samozrejme nebudeme vytvoriť objekty pre poskytovateľov vieme, nie sú k dispozícii v tejto chvíli.
Riešenie by to bolo na konfiguráciu pre lepší výkon a odstrániť poskytovateľov fronta - rovnako ako je to teraz - jedného poskytovateľa za jazykový pár.
To by nemalo byť drahé výkony, ale stále ešte niektoré ďalšie logiky a pamäte.

Prosím, povedzte, ktoré riešenie je lepšie.

[vBET]

A ešte jedno možné riešenie. Ak sa budeme označenie celej API je k dispozícii a skontrolujte, či pravidelná úlohou je teraz k dispozícii, potom nemusíme robiť fronty poskytovateľov. Môžeme urobiť to týmto spôsobom - vždy je vytvorený len jeden prekladateľ objektu (lepšie využitie pamäte) a v jednej žiadosti sme požiadať o preklad len jeden poskytovateľ (lepší CPU). Ak to nebude k dispozícii, potom to bude označená ako nie je k dispozícii, a výsledky budú prázdne (najhoršie spoľahlivosť). Ale iba prvý, pretože nabudúce budeme používať iného poskytovateľa z frontu. A v prípade, ak nie je poskytovateľ k dispozícii, figuríny prekladateľ bude použitý - vrátenie rovnakej hodnoty (ale nie, že vyrovnávacia pamäť), takže niektoré časti nebudú preložené, ale strana nebude mať prázdne diely, ako je teraz, keď poskytovateľ nie je k dispozícii.

[vBET]

Len rýchle oznámenia - sme už realizáciu tejto funkcie.

Chceme uvoľniť ju rýchlo (ako BETA) z dôvodu spoločné problémy spôsobené limitov stanovených preklad poskytovateľov. Tiež hľadáme pre iné API, ktoré môžu byť podporované vBET:)

[Simon Lloyd]

Moje myšlienky sa poslať šek preklade prvý, či preferovaným dodávateľom je k dispozícii, takže sa nám kód pre overenie, či Google alebo MS reagovať, tak v čase volania na preklad testu googleapi (meno mojej testovací súbor s testovacím kódom ) ak preklad je pravda použitie preferovaná, ak je preklad fľaša alebo kód nie je 200 skúste ďalšie poskytovateľa v zozname a plnia svoje API test pred použitím.

Tie by mohli mať listbox, kde si užívateľ môže každý poskytovateľ zoznam na každom riadku jeden v poradí (to umožňuje, keď pridáte podporu pre ďalšie API teda stačí ich pridať do zoznamu), takže môj zoznam by mohol vyzerať takto:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Za predpokladu, že Daft mená som vstúpil bol skutočný poskytovateľov, v pohotovosti pre preklad kódu testovacie MS by bol spustený, keď je odpoveď 200 použitia MS, ak nie spustiť MyTranslator skúšanie, kontrola reakcia na 200, ak áno, použite ju, ak nebeží Google testovací kód **** ****** atď

Týmto spôsobom sa nikdy nebudete musieť uchovávať žiadne informácie o poskytovateľovi (inak by ste mohli textových polí, kde používatelia môžu zadať svoje nastaviť limity pre jednotlivé poskytovateľov, ale myslím, že táto informácia wuld k ničomu, pretože môže zmeniť, a to by znamenalo väčšiu kontrolu a späť kontrolu dopredu pred tým, než preklad) by ste nikdy nebudete musieť starať, ak limity boli dané opäť k dispozícii, takže nie je potrebné cron spustiť kontrolovať tieto, by sa zaťaženie serveru, že jeden malý preklad check (kód, ktorý uvedené v FAQ) musí byť nič.

Dúfam, že som vysvetlil, že v poriadku, takže vám môj nápad, myslím, že to všetko by mohlo byť vykonané len tým, že malé kontrolou a bez uloženia čokoľvek.

[Simon Lloyd]

Len rýchle oznámenia - sme už realizáciu tejto funkcie.

Chceme uvoľniť ju rýchlo (ako BETA) z dôvodu spoločné problémy spôsobené limitov stanovených preklad poskytovateľov. Tiež hľadáme pre iné API, ktoré môžu byť podporované vBET:) poslal som vám jeden alebo dva (v post ste odstránený, pretože odkazy) že vám mohol prístup, ak chcete beta dobrovoľník som váš muž:)

[vBET]

Poslal som vám jeden alebo dva (v post ste odstránený, pretože odkazy) že vám mohol prístup, ak chcete beta dobrovoľník som váš muž:)

Vaša správa bola mäkko odstránená, pretože jeho obsah bol reklama napísané niekým iným, ale máme prístup na túto správu a sme na to:)

Dokonca sme už Poslať dotaz e-mailom na jeden z tých prekladov služieb o údaje o platbe. Niektoré z nich sú platené (aj keď to je označiť ako voľný to nie je na úrovni API - rovnakú vec, ktorú si s pomocou Google Translate môžete zadarmo prehliadač, ale nie API), ale ceny môžu byť konkurencieschopné, preto je dobré (viac konkurencie lepšie ceny).
Niektorí sme sa preskúmať, sú skutočne externé preklady API, alebo len miestne slovníky napísal vlastné užívateľa (to je tiež jedna vec, na našich TODO list - umožňuje upravovať a dať vlastné preklady) - Radek má táto časť.

Tak sme sa pracuje na zlepšenie vBET a to ako lacné pri používaní možnej:)

[vBET]

Sme v posledných fázach tesing nových funkcií. Môžete už vidieť zmenených popis: http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.html#post8914 (pozri posledná poznámka)

[Simon Lloyd]

Vďaka Michael, som urobil rýchly post v kamerám Faq, ktoré nepochybne budete musieť odstrániť, pretože nie je jeho správne miesto za to:), ak by ste chceli vyskúšať na živé doska, ktorá si vyžaduje veľa prekladov PM mňa a uvidíme dať prístup k admincp a fórum koreňa, tiež dám google preklad limit, že majú nastaviť hore a dole pomocou príkazu tak môžete otestovať:)

[vBET]

OK tak. Poskytovatelia frontu je implementovaná a zahrnie do správy 3.5.1 a 4.4.3. vBET 3.5.1 bude uvoľnená dnes. vBET4.4.3 je stále v testovacej fáze. Stánok uvoľnení budú BETA, takže všetci môžete otestovať vo väčších fóre, že jedna skúška. Upozorňujeme, že sme sa už testovanie 3.5.1 na jednom z našich reálnych fóra. Stále dôvodu dôležitých zmien je v BETA štádiu prvý.

[Simon Lloyd]

Musieť byť naplánovaná úloha a jeden konkrétny poskytovateľ vypnuté za hodinu v čase?, urobil som naznačoval tu obežník kontrolu a prepínanie API udržať toku prekladov, kde snad sme mohli vždy začať na začiatok nášho zoznamu poskytovateľov a make test hovoru (ako jeden vám poskytované na test a Google odozvou Microsoft) Ak hovor reakcii na test je 200 alebo text preložený potom použiť tento poskytovateľ, ak odpoveď nie je 200 alebo testu textu nie je preložený, (použijúc rovnaký text pre každý test a REGEX skontrolovať preložený text) potom presunúť do ďalšej poskytovateľa, každý hovor preklad potom môžete začať v hornej časti zoznamu a práci nadol

Nemajú prázdny výsledok by bolo dobré, pretože akonáhle budeme mať prázdne návratky to je ako zostáva, som už veľa ľudí sťažujú, že toto je prípad v mojom fóre.

[vBET]

Nemá to byť takhle, je to hned. Vďaka za vaše poznámky. Stále - č. To nemá zmysel. Upozorňujeme, že žiadajú o externé prekladateľské je viac časovo náročné vec v celej vBET (a nie je na nás). Neexistuje žiadny zmysel šialených tisíce žiadosť, keď sme už dosiahnuť limitov. To by čas odozvy increaser, spotreby Procesora a pamäte tiež (viac objekt vytvorený).

Sme zistili, že Google informácie o pravdepodobne zneužívania TOS zmizne po určitom čase. Nevieme, ale možná ak sme sa udržať dotazem, keď sme už sú blokované, Google môžete zablokovať pre viac času. Možno nie, ale stále skutočná stratégia je oveľa lepší pre výkon. Na konci máte kruhové kontrolu. Ak jeden nie je k dispozícii je označená ako nedostupné a iného používa. Ak iné, nie je k dispozícii, deje sa to isté. Sme len Nekontrolovať, je k dispozícii opäť každý žiadať čo nemá zmysel (to môže byť milióny dotazy predtým, ako bude k dispozícii) len raz za hodinu. A ak bude k dispozícii bude mi označené, takže sme sa vrátiť k uprednostňovaná - máte kruhu tady. Tiež testuje zakaždým, keď bude vykonané limity dosiahnuté rýchlejšie alebo náklady sú vyššie, ak používate zaplatená preklady (to stále počíta ako preklad).
Tiež sme ochotní mať ostatní poskytovatelia taky. Keď sme podporu viac ako 2 takejto stratégie bude zabijak pre váš server. Predstavte si 5 testovanie vyzýva rozličnými poskytovateľmi a potom skutočné preklad pre každý preklad žiadosti. nie. Vďaka za váš nápad:) Sme naozaj ocenia užívateľov nápady, tentoraz budeme pobyt s skutočné riešenie.

Upozorňujeme, že môžete zmeniť ako často vBET mali skontrolovať dostupnosť poskytovateľov. Teraz je to jedna za hodinu, ale môžete tiež prekonfigurovať že v Admin CP - > plánované úlohy - > naplánované Task Manager a súbor je napríklad pre každých 10 minút 0 rovnako ako úloha RSS plagát Robot to teraz.

[vBET]

Malý zmene - budeme kontrolovať poskytovateľa nie je k dispozícii raz za hodinu, ale každých 10 minút. Ak ste už inovovali na vBET 3.5.1 predtým, než túto správu, prosím stačí stiahnuť balíček vBET znovu nahrať súbor s produktom znova.

Zmena bol urobený, pretože sme našli na našom reálnom fóre ktoré často poskytovateľ nie je k dispozícii na krátky čas. My preskúmame to skôr hľadať ďalšie zlepšenia.

[Simon Lloyd]

Skvelá práca chlapi:), som upgradovať na to ale bude sťahovať najnovšie opravy a použitie, že bude vytvárať nové vlákno pre spätnú väzbu na to.