PDA

Zobrazit plnou verzi: Již udělal Kruhová kontrola a přepínání rozhraní API, aby průtok překlady



Simon Lloyd
04-10-11, 01:10
Mám znaků pro Google nastaven na 100.000 perday, takže se moje nastavení "Vždy používat Google", "Use Google API V2", "Use Google detekce" Když jsem se dosáhne tohoto limitu, a už se výsledky z placených Google by bylo možné zdarma API a začít produkovat výsledky?

Tak například použít přednastavené omezení mi Google a Google již vrátí výsledek pro mě (pravděpodobně vrací kód chyby jako v testovací kód Google) když výsledek není vrácen bylo by dobré, kdyby vBET automaticky uznávána chybového kódu a pak poslal žádost na další rozhraní API jako Microsoft (nebo jakékoli další že vBET později podporuje) tímto způsobem jsou zajištěny získat nějaký výsledek - pro mě by to velmi velmi cenné vzhledem k tomu, že existují limity i s placené verze, umožnil by rozšířit vaše překlady limity.

např.
Google nastavit 100.000 nepovolené znaky za den > spotřebováno > vBET přesunout na další rozhraní API v seznamu > Microsoft 400 táců za hodinu nebo 4 M, pokud je dosaženo limitu vBET kontrola další rozhraní API a předcházející viz pokud limit zrušen nebo má nějaké příspěvek > buď přesunout na další rozhraní API nebo zpět na Google, když znovu dosaženo limitu > zkontrolovat další rozhraní API.... atd, a tak cyklický kontrola po Příjímám kód chyby by vykonávat, tak pěkně mnohem konstantní schopnost mít překlady.

vBET
04-10-11, 09:28
Chápu vaše popis a své místo. Nyní musíme zjistit, jak to asi fungovat technicky.

Jeden problém vidím tady je, jak poznají, že již máme k dispozici od hranice těch, kde předtím.

Můžeme jednoduše pokaždé zeptat upřednostňovaného zprostředkovatele a pak přejít na další stránku. Výkon - to bude stát, protože pro každý požadavek na stránku, která vyžaduje překlad zvládli neúspěšné volání na upřednostňovaného zprostředkovatele, pak na další jeden (takže když vBET bude podporovat více API může být několik neúspěšných volání).

Jiné řešení by bylo pro ukládání informací, že preferovaným dodavatelem není k dispozici, a přejít přímo k další. To by bylo mnohem rychlejší, protože kontrola lokálních proměnných je mnohem rychlejší, než čekat na odpověď z externího serveru. Tentokrát jsme se další problém - nevíme, kdy preferovaným dodavatelem je k dispozici. Můžeme samozřejmě udělal některé naplánované úlohy, které by požádat o jednoduchý (krátký), překlad například jednou za hodinu / den, podívat se na to. Takže v této strategii se musíme rozhodnout, jak často implicitně jako úkol Předpokládám, že se do práce. Samozřejmě, že bychom zkontrolovat pouze v případě některých služeb je označen jako není k dispozici.
Také v případě, označíme poskytovatelé nedostupné - Co dělat, když víme, že všichni poskytovatelé nejsou k dispozici - přidat nějaké informace pro koncové uživatele, nebo jen přeložit, co je v cache a zbytek je původní, a to bez jakékoli další informace o dočasný nedostatek překlady .

Bez ohledu na to, jakým způsobem to bude hotovo, bude Google bude považován za jedno API (V1 a V2 v závislosti na konfiguraci) - Nemá smysl dělit, protože Google V1 bude uzavřena v nejbližší době.

Další věc je umožnit Konfigurovat zprostředkovatele fronty pro každý jazyk pár odděleně. V tomto okamžiku vBET již umožňuje konfigurovat poskytovatel překladů pro každou dvojici jazyk. Myslím, že můžeme změnit ji od jednoho do hodnoty oddělené čárkou (CSV). Tímto způsobem budeme vědět pro každý jazyk pár který zprostředkovatelé podporují tento překlad a co jsou pořadí preferencí (jen pořadí na seznam CSV).

Poznámka: to stejně bude mít nějaký vliv na výkon. Namísto vytvoření jednoho objektu pro překlad budeme muset vytvořit takové objekty a další balení objektu (aby to transparentní pro ostatní části kódu a méně chyb sklonem). Samozřejmě jsme nebude vytvářet objekty pro poskytovatelé, kterou známe v tuto chvíli nejsou k dispozici.
Řešení by to bylo na konfiguraci pro lepší výkon a odstranit poskytovatelů fronta - stejně jako je to teď - jednoho poskytovatele za jazykový pár.
To by nemělo být drahé výkony, ale stále ještě některé další logiky a paměti.

Prosím, řekněte, které řešení je lepší.

vBET
04-10-11, 18:23
A ještě jedno možné řešení. Budeme-li se označení celé API je k dispozici a zkontrolujte, zda pravidelná úkolem je nyní k dispozici, pak nemusíme dělat fronty poskytovatelů. Můžeme udělat to tímto způsobem - vždy je vytvořen pouze jeden překladatel objektu (lepší využití paměti) a v jedné žádosti jsme požádat o překlad pouze jeden poskytovatel (lepší CPU). Pokud to nebude k dispozici, pak to bude označena jako není k dispozici, a výsledky budou prázdné (nejhorší spolehlivost). Ale pouze první, protože příště budeme používat jiného poskytovatele z fronty. A v případě, není-li poskytovatel k dispozici, figuríny překladatel bude použit - vrácení stejné hodnoty (ale ne, že vyrovnávací paměť), takže některé části nebudou přeloženy, ale strana nebude mít prázdné díly, jako je nyní, kdy poskytovatel není k dispozici.

vBET
04-10-11, 22:31
Jen rychlé oznámení - jsme již realizaci této funkce.

Chceme uvolnit to rychle (jako BETA) kvůli společné problémy, způsobené limity stanovené překlad zprostředkovatelů. Také hledáme další rozhraní API, které mohou být doloženy vBET:)

Simon Lloyd
04-10-11, 22:36
Moje myšlenky se poslat šek překladu první, zda preferovaným dodavatelem je k dispozici, takže se nám kód pro ověření, zda Google nebo MS reagovat, tak v době volání na překlad testu googleapi (jméno mé testovací soubor s testovacím kódem ) je-li překlad je pravda použití preferována, je-li překlad flase nebo kód není 200 zkuste další poskytovatele v seznamu a plní své API test před použitím.

Ty by mohly mít listbox, kde si uživatel může každý poskytovatel seznam na každém řádku jeden v pořadí (to umožňuje, když přidáte podporu pro další API tedy stačí je přidat do seznamu), takže můj seznam by mohl vypadat takto:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Za předpokladu, že Daft jména jsem vstoupil byl skutečný poskytovatelů, v pohotovosti pro překlad kódu testovací MS by byl spuštěn, je-li odpověď 200 použití MS, ne-li spustit MyTranslator zkoušení, kontrola reakce na 200, pokud ano, použijte ji, pokud neběží Google testovací kód **** ****** atd.

Tímto způsobem se nikdy nebudete muset uchovávat žádné informace o poskytovateli (jinak byste mohli textových polí, kde uživatelé mohou zadat své nastavit limity pro jednotlivé poskytovatele, ale myslím, že tato informace wuld k ničemu, neboť může změnit, a to by znamenalo větší kontrolu a zpět kontrolu dopředu před tím, než překlad) byste nikdy nebudete muset starat, pokud limity byly dány znovu k dispozici, takže není třeba cron spustit kontrolovat tyto, by se zatížení serveru, že jeden malý překlad check (kód, který uvedené v FAQ) musí být nic.

Doufám, že jsem vysvětlil, že v pořádku, takže vám můj nápad, myslím, že to vše by mohlo být provedeno jen tím, že malé kontrolou a bez uložení cokoliv.

Simon Lloyd
04-10-11, 22:37
Jen rychlé oznámení - jsme již realizaci této funkce.

Chceme uvolnit to rychle (jako BETA) kvůli společné problémy, způsobené limity stanovené překlad zprostředkovatelů. Také hledáme pro jiné rozhraní API, které mohou být doloženy vBET:) jsem vám poslal jeden nebo dva (v příspěvku jste odstranili z důvodu odkazů) že by přiblížit, chcete beta dobrovolníků, já jsem váš člověk:)

vBET
04-10-11, 22:57
Poslal jsem ti jeden nebo dva (v místo, které jste odstranili z důvodu odkazů) že by přiblížit, chcete beta dobrovolníků, já jsem váš člověk:)

Vaše zpráva se tiše byl odstraněn, protože její obsah byl inzerát napsal někdo jiný, ale máme přístup k této zprávy a jsme na to:)

Dokonce jsme už Poslat dotaz e-mailem na jeden z těch překladů služeb o údaje o platbě. Někteří z nich jsou placené (i když to je popisován jako volný to není na úrovni API - to samé můžete mít s Google můžete přeložit zdarma prohlížeč, ale ne API), ale ceny mohou být konkurenceschopné, proto je dobré (více konkurence lepší ceny).
Někteří jsme se prozkoumat, jsou skutečně externí překlady API, nebo jen místní slovníky napsal vlastní uživatele (to je také jedna věc, na našich TODO list - umožňuje upravovat a dát vlastní překlady) - Radek má tato část.

Tak jsme a pracují na zlepšení vBET a bylo jako levné v použití co nejvíce:)

vBET
05-10-11, 13:52
Jsme v posledních fázích nové funkce tesing. Již můžete vidět změněné Popis: http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.html#post8914 (viz poslední poznámka)

Simon Lloyd
05-10-11, 18:03
Díky Michaele, jsem udělal rychlý post v taht Faq, který bezpochyby bude muset odebrat, protože není správné místo pro to:), pokud byste chtěli na test živá deska, která vyžaduje mnoho překladů PM mě a já dám vám přístup na fórum a admincp kořen, a také učiním google překlad omezení, které jsem nastavil nahoru a dolů na váš příkaz tak můžete vyzkoušet:)

vBET
06-10-11, 00:50
Tak dobře. Poskytovatelé fronta je implementováno a budou zahrnuty do verze 3.5.1 a 4.4.3. vBET 3.5.1 bude vydána dnes. vBET4.4.3 je stále v testovací fázi. Booth vydání bude BETA, tak všichni mohou otestovat ve větších fórech, které první zkouška. Prosím uvědomte si, že jsme již testování 3.5.1 na jedné z našich skutečných fóra. Přesto z důvodu významné změny je v BETA fázi první.

Simon Lloyd
06-10-11, 06:59
Nemusí být naplánovanou úlohu a jeden konkrétní zprostředkovatel vypnuté hodiny v době?, jsem udělal návrh zde kulaté přepínání rozhraní API udržet tok překlady a kontrola kde snad bychom mohli vždy začít v horní části seznamu našich poskytovatelů a si vyzkoušet volání (jako jeden vás poskytnuté k testování Microsoft a Google odezvou)-li zkušební hovor reakce je 200 nebo překládají pak použít zprostředkovatele, pokud odpověď není 200 nebo zkušební text není zpracováváno (pomocí stejný text pro každý test a regulární výraz pro kontrolu přeložený text) pak přechod na další zprostředkovatele, každý překlad volání lze pak začít v horní části seznamu a dolů

S prázdnou výsledkem by bylo dobré, protože jakmile máme prázdný návrat to je jak to zůstává, už jsem měl mnoho lidí stěžuje, že jde o případ v mé fóra.

vBET
06-10-11, 11:33
Nemusí to být takhle, je to právě teď. Díky za vzkaz. Stále - ne. Nemá to žádný smysl. Mějte prosím na paměti, že externí překlady je časově náročnější věc v celé vBET (a to není na nás). Není žádný smysl šílený tisíce žádost, když jsme již dosáhnou mezí. To by doba odezvy increaser, CPU a spotřeby paměti také (další objekt vytvořen).

Zjistili jsme, že Google informace o zneužití zřejmě TOS zmizí po nějaký čas. My nevíme, ale možná kdyby jsme se ptá, když jsme již blokován, Google může blokovat pro více času. Možná ne ale stále aktuální strategie je mnohem lepší výkon. Na konci máte kruhové kontrolu. Pokud není k dispozici je označen jako nedostupný a další se používá. Pokud jiný není k dispozici, stává se totéž. Jsme jen zkontrolovat je to dostupných opět každý požadavek co nemá žádný smysl (to může být miliony dotazy před tím, než bude k dispozici) jen jednou za hodinu. A pokud bude k dispozici to budou označeny, takže se vrátíme na preferovanou - a tady máte kruh. Také testování pokaždé, když bude provedena vaše hranice dosáhl rychleji nebo vyšší, pokud používáte náklady zaplacené překlady (stále počítá jako překlad).
Rovněž jsme připraveni také na jiných poskytovatelů. Když budeme podporovat více než 2 takové strategie bude vrah vašeho serveru. Představte si 5 testování volání na různých zprostředkovatelů a pak skutečné překlad pro každou žádost o překlad. Ne. Díky za váš nápad:) Opravdu si vážíme názory uživatelů, tentokrát zůstaneme s vlastní řešení.

Prosím uvědomte si, že můžete změnit jak často vBET by měl zkontrolovat dostupnost poskytovatelů. Teď je to jednou za hodinu, ale že v Admin CP - můžete rekonfigurovat > naplánované úlohy - > naplánovanou úlohu správce a nastavit jako například za každých 10 minut 0 úkolu RSS plakát Robot to teď udělat.

vBET
06-10-11, 13:34
Malá změna - bude kontrolovat dostupnost poskytovatele ani jednou za hodinu, ale každých 10 minut. Pokud jste již upgradovali na vBET 3.5.1 před tuto zprávu prosím jen stáhnout balíček vBET znovu a znovu uložit soubor produktu.

Byla změna provedena, protože jsme našli na naše skutečné fórum tak často poskytovatele není k dispozici pro krátkou dobu. Budeme vyšetřovat to více pro další zlepšení.

Simon Lloyd
06-10-11, 15:51
Skvělá práce kluci:), jsem přešli na to ale bude stahovat nejnovější opravy a používání, bude vytvořit nové vlákno pro zpětnou vazbu o tom.

Automatic Translations (Powered by Google, Microsoft®, Yandex, SDL Language Cloud, IBM Watson and Apertium):
AfrikaansAlbanianArabicBelarusianBulgarianCatalanChineseCroatianCzechDanishDutchEnglishEstonianFilipinoFinnishFrenchGalicianGermanGreekHaitian CreoleHebrewHindiHungarianIcelandicIndonesianIrishItalianJapaneseKoreanLatvianLithuanianMacedonianMalayMalteseNorwegianPersianPolishPortugueseRomanianRussianSerbianSlovakSlovenianSpanishSwahiliSwedishTaiwaneseThaiTurkishUkrainianVietnameseWelshYiddish
Translations delivered by vB Enterprise Translator 4.10.1