Kruhová kontrola a přepínání rozhraní API, aby průtok překlady

[Simon Lloyd]

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]

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).

UPOZORNĚNÍ: To bude mít nějaký dopad na výkon tak jako tak. Namísto vytvoření jednoho objektu pro překlad, budeme muset vytvořit pole takových objektů a další balení objekt (aby bylo transparentní pro jiné části kódu a méně náchylné chyby). Samozřejmě nebudeme vytvářet objekty pro poskytovatele víme, že nejsou k dispozici v tuto chvíli.
Ř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]

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]

Jen rychlé oznámení - jsme již realizaci této funkce.

[Simon Lloyd]

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]

Jen rychlé oznámení - jsme již realizaci této funkce.

Poslala jsem ti jednu nebo dvě (v místo, které vypouští, protože z odkazů), který jste mohli přiblížit, chcete-li beta dobrovolník Jsem tvůj muž

[vBET]

Poslala jsem ti jednu nebo dvě (v místo, které vypouští, protože z odkazů), který jste mohli přiblížit, chcete-li beta dobrovolník Jsem tvůj muž

Vaše zpráva byla potichu odstraněn, protože jeho obsah byl inzerát napsal někdo jiný, ale máme přístup na tuto zprávu 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.

[vBET]

Jsme v posledních fázích nové funkce tesing. Můžete vidět již změněné Popis: http://www.vbenterprisetranslator.co....html#post8914 (viz poslední Poznámka)

[Simon Lloyd]

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]

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í.