Okrągłe kontroli i przełączania API do utrzymania przepływu tłumaczeń

[Simon Lloyd]

Mam limit znaków dla google zestaw do 100.000 perday to z ustawienia "Zawsze używaj Google", "Use Google API V2", "Use Google Detection", kiedy i osiągnięcia tej granicy i nie będą się wyniki z płatnych Google byłoby możliwe za darmo API następnie wywołuje rezultaty?

Tak na przykład używać mojego wstępnie ustawionego limitu Google i Google już zwraca wynik dla mnie (prawdopodobnie zwraca kod błędu podobne w kodzie badania Google) kiedy wynik nie zostanie zwrócona byłoby dobrze, jeśli vBET uznane automatycznie kod usterki i następnie wysyłane żądanie do innego interfejsu API jak Microsoft (lub innych później obsługuje tego vBET) w ten sposób możemy są zapewnione pobieranie niektórych wynik - dla mnie byłoby to bardzo cenne biorąc pod uwagę fakt, że istnieją ograniczenia nawet w płatnej wersji, umożliwiłoby umożliwia rozszerzenie limitów tłumaczenia.

np.
Google ustawić 100,000 znaki dziennie > zużyte > vBET przejść do następnej API liście > Microsoft 400 k na godzinę lub 4 M, kiedy osiągnięty limit czasu vBET wyboru następnego API i wcześniejszych niż stwierdzić, czy limit zostanie zniesione lub ma pewnych > albo przejść do następnej API, albo Wróć do Google płacone po osiągnięciu limitu ponownie > Sprawdź.... następnego API itp i tak cyklicznego sprawdzania po recieving kod błędu będzie prowadzić, więc pretty znacznie stałą możliwość umieszczania tłumaczenia.

[vBET]

Rozumiem opis i punktem. Teraz musimy dowiedzieć się, jak przypuszczam do pracy technicznie.

Jeden problem widzę, o to jak rozpoznamy, że mamy już limity dostępne po te, w których osiągnięto wcześniej.

Można po prostu za każdym razem prosimy preferowanym usługodawcą a następnie przejdź do następnego. Będzie to koszt wydajności-, ponieważ dla każdego żądania do strony, która wymaga tłumaczenia przekażemy Niepomyślne wywołania do preferowanego dostawcy, następnie do następnego jeden (co może być kilka całkowita liczba nieprawidłowych połączeń podczas vBET będzie obsługiwać więcej interfejsów API).

Inne rozwiązanie byłoby do przechowywania informacji preferowanego dostawcy nie jest dostępny i przejść bezpośrednio do następnego. Byłoby to znacznie szybciej, ponieważ sprawdzanie zmiennej lokalnej jest znacznie szybsze niż czekanie na odpowiedź z serwera zewnętrznego. Tym razem mamy innych kwestii - nie wiemy, kiedy preferowanym dostawcą jest dostępna. Możemy oczywiście wykonane niektóre zaplanowane zadanie, które poprosić o prosty (krótki) tłumaczenie na przykład raz na godzinę / dzień to sprawdzić. Tak więc w tej strategii musimy zdecydować, jak często domyślnie takie zadanie załóżmy do pracy. Oczywiście chcielibyśmy to sprawdzić tylko wtedy, gdy jakiś dostawca jest oznaczony jako niedostępny.
Także jeśli znak dostawców jako niedostępne - co zrobić, gdy wiemy, że wszyscy dostawcy nie są dostępne - dodać trochę informacji na użytkownika końcowego lub po prostu przetłumaczyć to, co jest w pamięci podręcznej, a reszta jako oryginalne, bez żadnych dodatkowych informacji o chwilowy brak tłumaczenia .

Bez względu na sposób będzie to zrobione, Google będzie traktowana jako jeden API (v1 lub v2 w zależności od konfiguracji) - nie ma sensu go podzielić, ponieważ Google v1 zostanie zamknięta w najbliższym czasie.

Another thing jest umożliwienie skonfigurować kolejki dostawców dla każdej pary językowej oddzielnie. W tej chwili vBET już pozwala skonfigurować dostawca tłumaczeń dla każdej pary języka. Myślę, że mamy można go zmienić z jednej wartości na wartości rozdzielanych przecinkami (CSV). Dzięki temu wiemy dla każdej pary językowej których dostawców obsługuje tłumaczenie i jakie są kolejności preferencji (tylko zamówienia na liście CSV).

UWAGA: będzie to miało pewien wpływ na wydajność w każdym razie. Zamiast tworzyć jeden obiekt do tłumaczenia będziemy musieli stworzyć tablicę takich obiektów i dodatkowy obiekt opakowania (by była przejrzysta dla innych części kodu i mniej błędów podatne). Oczywiście nie będziemy tworzyć obiekty dla dostawców wiemy, nie są dostępne w tej chwili.
Rozwiązaniem tego byłoby zmienić konfigurację w celu zwiększenia wydajności i usunięcia kolejki dostawców - tak jak jest teraz - jeden dostawca na parze językowej.
Nie powinno to być kosztowne dla wydajności, ale jeszcze kilka dodatkowych logiki i zużycie pamięci.

Powiedz, jakie rozwiązanie będzie preferowanym.

[vBET]

I więcej potencjalnym rozwiązaniem. Będzie oznaczyć cały API jako niedostępne i sprawdzają, czy to przez zaplanowane zadanie jest to dostępne obecnie, następnie nie mamy do kolejki dostawców. Możemy zrobić to sposób - zawsze jest tworzony tylko jeden obiekt tłumacz (lepsze wykorzystanie pamięci) i w jeden wniosek prosimy o tłumaczenie tylko jeden dostawca (lepiej CPU). Jeśli będzie on nie dostępny, a następnie zostanie oznaczony jako niedostępny i wyniki będą puste (najgorszy niezawodność). Ale tylko pierwszy z nich ponieważ następnym razem będziemy używać innego dostawcy z kolejki. I w przypadku jeśli dostawca nie jest dostępna, następnie tłumacz manekina używanego - zwraca te same wartości (ale nie buforuje), niektóre części będą przeliczane nie, ale strona nie przyniesie pustych elementów takich jak teraz, gdy dostawca nie jest dostępne.

[vBET]

Ogłoszenie wystarczy szybki - mamy już wdrażają tej funkcji.

Chcemy go szybko zwolnić (jako BETA) ze względu na wspólne problemy, spowodowane przez limity ustalone przez dostawców tłumaczeń. Szukamy również innych interfejsów API, które mogą być obsługiwane przez vBET

[Simon Lloyd]

Moje myśli było wysłanie tłumaczenie wyboru po raz pierwszy po to, aby sprawdzić, czy preferowany dostawcy jest dostępna, więc możesz dał nam kod do sprawdzania, jeśli google lub MS odpowiada, więc w czasie wywołania do tłumaczenia testu googleapi (nazwa Mój plik testowy w kodzie badania) Jeśli tłumaczenie jest PRAWDA używania preferowanego przez, jeśli tłumaczenie jest flase lub kod nie jest 200, a następnie spróbuj następnego dostawcy na liście i wykonać ich badanie api, przed użyciem.

Może mieć listbox gdzie użytkownika można podać każdy dostawca, jeden na wiersz według priorytetu (dzięki temu po dodaniu wsparcie dla innych interfejsów API użytkownik po prostu dodać je do listy), więc moje listy może wyglądać następująco:
Microsoft
MyTranslator
Google
YourTranslator
AnOtherTranslator

Przy założeniu, że nazwy daft wprowadzonej były prawdziwe dostawców, na zaproszenie do tłumaczenia MS badania kodu zostałby uruchomiony, jeśli użycie odpowiedź 200 MS, jeśli nie wykonywania kodu badania MyTranslator, sprawdź odpowiedź 200, jeśli tak go używać nawet uruchomienie kodu testu Google ********** itd

Dzięki temu nie ma potrzeby przechowywania wszelkich informacji na temat dostawców (w przeciwnym razie może masz tekst pola, gdzie użytkownicy mogą wprowadzać ich ustawianie limitów dla każdego dostawcy, ale myślę to wuld informacji się bezużyteczny, można go zmienić i oznaczałaby więcej sprawdzanie wstecz i do przodu przed dokonywania tłumaczenia) nigdy nie trzeba martwić się gdyby limitów ponownie tak nie potrzeba cron zadania Uruchom, aby sprawdzić te, obciążenia na serwerze dla tego jednego wyboru małych tłumaczenie (kod podany w FAQ) mogłoby mieć wartości nothing.

Mamy nadzieję, że wyjaśniłem, że przycisk ok Aby uzyskać my idea sadze może być wykonywane tylko przez tego wyboru małych i bez przechowywania czegokolwiek.

[Simon Lloyd]

Ogłoszenie wystarczy szybki - mamy już wdrażają tej funkcji.

Chcemy go szybko zwolnić (jako BETA) ze względu na wspólne problemy, spowodowane przez limity ustalone przez dostawców tłumaczeń. Szukamy również innych interfejsów API, które mogą być obsługiwane przez vBET

Wysłany zostanie jedna lub dwie (na stanowisku, które została usunięta z powodu łącza) może podejścia, jeśli chcesz beta ochotników i 'm your man

[vBET]

Wysłany zostanie jedna lub dwie (na stanowisku, które została usunięta z powodu łącza) może podejścia, jeśli chcesz beta ochotników i 'm your man

Wiadomości cicho został usunięty, ponieważ zawartość została anons napisane przez kogoś innego, ale mamy dostęp do tej wiadomości i jesteśmy na nim

Wyślemy nawet już pytanie e-mail do jednego z tych dostawców tłumaczeń o szczegóły płatności. Niektóre z nich są wypłacane (nawet gdy opisano jak uwolnienie jej nie na API poziomu - samo z Google można tłumaczyć bez przeglądarki, ale nie przez interfejs API), ale ceny mogą być konkurencyjni, więc za dobry (więcej konkurencji lepszych cen).
Niektóre mają także sprawdzi są te tłumaczenia naprawdę zewnętrznego interfejsu API lub tylko lokalne słowniki, napisana przez własnych użytkowników (jest to również jedną rzeczą na naszej liście TODO - pozwala modyfikować i umieścić własne tłumaczenia) - Radek ma niniejszej części.

Tak więc pracujemy nad poprawą vBET i uczyliśmy go tak tani w użyciu, jak to możliwe

[vBET]

Jesteśmy w ostatnich etapów tesing nowych funkcji. Można już zobaczyć opis zmian: http://www.vbenterprisetranslator.co...html#post8914 (zobacz ostatni UWAGA)

[Simon Lloyd]

Dzięki Michael, dokonane stanowisku szybkie w argumentuje często zadawane pytania, które bez wątpienia będzie trzeba usunąć, ponieważ jej nie odpowiednie miejsce dla niego Jeśli chcesz przetestować na żywo Zarząd, który wywołuje wiele tłumaczeń PM me i damy ci dostęp do głównego admincp i forum, będzie również zamieszczam limitu tłumaczenie google, która po ustawieniu górę i w dół na polecenie tak można przetestować

[vBET]

OK, tak. Zaimplementowano kolejki dostawców i zostaną uwzględnione w wydaniach 3.5.1 i 4.4.3. vBET 3.5.1 ukaże się dziś. vBET4.4.3 jest nadal w fazie badania. Booth uwolnień będzie BETA, więc wszyscy go przetestować w większych forum, które jeden. Należy pamiętać, że możemy już testowaniu 3.5.1 na jednym z naszych rzeczywistego fora. Nadal z powodu istotnych zmian jest w fazie BETA po raz pierwszy.