PDA

Zobacz pełną wersję: Już Okrągłe kontroli i przełączania API do utrzymania przepływu tłumaczeń



Simon Lloyd
04-10-11, 01:10
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
04-10-11, 09:28
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: to będzie miało wpływ niektóre wydajności mimo to. Tworzy jeden obiekt do tłumaczenia będzie musimy utworzyć macierz takich obiektów oraz dodatkowe zawijanie obiektu (było przejrzyste dla innych części kodu i mniej błędów podatna). Oczywiście nie stworzymy obiektów do dostawców, których wiemy, nie są dostępne w tym momencie.
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
04-10-11, 18:23
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
04-10-11, 22:31
Ogłoszenie wystarczy szybki - mamy już wdrażają tej funkcji.

Chcemy zwolnić go szybko (jako BETA) ze względu na typowych problemów spowodowanych ustalonych przez dostawców tłumaczenia. Szukamy też innych interfejsów API, które mogą być obsługiwane przez vBET:)

Simon Lloyd
04-10-11, 22:36
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
04-10-11, 22:37
Ogłoszenie wystarczy szybki - mamy już wdrażają tej funkcji.

Chcemy zwolnić go szybko (jako BETA) ze względu na typowych problemów spowodowanych ustalonych przez dostawców tłumaczenia. Są nam również dla innych interfejsów API, które mogą być obsługiwane przez vBET:) wysłany zostanie jedna lub dwie (na stanowisku została usunięta z powodu łącza) może podejścia, jeśli chcesz beta ochotników i:) 'm your man

vBET
04-10-11, 22:57
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 mamy nad poprawy vBET i uczyniła jako tania w sposób użycia możliwie:)

vBET
05-10-11, 13:52
Jesteśmy w ostatnich etapów tesing nowych funkcji. Można już zobaczyć opis zmienionych: http://www.vbenterprisetranslator.com/forum/vbet4-troubleshooting/413-faq-2.html#post8914 (zobacz ostatni PRZYPIS)

Simon Lloyd
05-10-11, 18:03
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
06-10-11, 00:50
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.

Simon Lloyd
06-10-11, 06:59
Jest konieczne jest zaplanowane zadanie i jednego określonego dostawcy wyłączone na godzinę naraz?, utworzyłem propozycję tutaj cykliczne sprawdzanie i przełączania interfejsów API, aby zachować przepływem tłumaczeń gdzie prawdopodobnie będziemy może zawsze zaczynają się od góry naszą listę dostawców i uzupełnić testować wywołań (na przykład jeden użytkownik dostarczone do testowania Google odpowiedzi i reakcja firmy Microsoft) Jeśli wywołania reakcji jest 200 lub tekst jest tłumaczony należy użyć tego dostawcy, jeśli odpowiedź nie jest 200 lub tekst testowy nie są tłumaczone, (przy użyciu tego samego tekstu dla każdego badania i REGEX do sprawdzenia przetłumaczonego tekstu) następnie przejście do następnego dostawcy, każdego wywołania tłumaczenie można następnie uruchomić u góry listy i pracować w dół

Nie ma pusty wynik byłoby ponieważ po mamy puste zwrotu Ręczna robota czyli jak pozostaje miałem już wiele osób wnoszących skargę, jest to sprawa Moje forum.

vBET
06-10-11, 11:33
Nie musi on być w ten sposób, jest teraz. Podziękowania dla redagowanej notatki. Nadal - nr. Posiada nie jest zasadne. Należy pamiętać, że wnioskujących o tłumaczenia zewnętrznego jest bardziej czasochłonne rzeczą w całości vBET (i jest nie do nas). Istnieje nie warto mad tysiące wniosek, gdy dotrzemy już limitów. To będzie czas reakcji increaser, zużycie CPU i zużycie pamięci również (więcej obiekt utworzony).

Odkryliśmy, że Google informacje o prawdopodobnie nadużywanie OT znika po pewnym czasie. Nie znamy, ale może jeśli będzie musimy zadawać na kiedy jesteśmy już są blokowane, Google można zablokować o więcej czasu. Być może nie ale nadal rzeczywistej strategii jest znacznie lepszą wydajność. Na końcu masz cyklicznego sprawdzania. Jeśli nie jest dostępny jest oznaczany jako niedostępny i używany jest inny. Jeśli inny nie jest dostępne samo dzieje się. Po prostu nie sprawdzamy jest ona dostępna ponownie każdego żądania co ma nie jest zasadne (miliony kwerend może być zanim będzie on dostępny) tylko raz na godzinę. I jeśli będzie on dostępny będzie me zaznaczył, dzięki czemu możemy wrócić sprawdza się do preferowana - i tutaj masz okręgu. Również badania za każdym razem będzie dokonane swoje limity osiągnął szybciej lub koszty wyższych, jeśli używasz wypłacone tłumaczenia (nadal liczone jako tłumaczenia).
Również jesteśmy gotowi mają zbyt innych dostawców. Jeśli dostarczymy wsparcia ponad 2 taka strategia będzie tueur dla serwera. Wyobraź sobie 5 wywołania testowania różnych dostawców i następnie rzeczywistą tłumaczenia dla każdego żądania tłumaczenia. No. Dziękujemy za Twój pomysł:) Naprawdę Doceniamy użytkowników pomysły, tym razem, które możemy pozostanie roztworem rzeczywiste.

Należy pamiętać, że można zmienić jak często vBET należy sprawdzić dostępność dostawców. Teraz jest to jedna na godzinę, ale można zmienić konfigurację w Admin PK - > zaplanowane zadania - > zaplanowane Menedżera zadań i zestawu, na przykład przez co 10 minut 0 just like zadań RSS plakatu Robot zrobić to teraz.

vBET
06-10-11, 13:34
Niewielkie zmiany - będzie sprawdzamy dostępność dostawcy nie raz na godzinę, ale co 10 minut. Jeśli już uaktualniony do vBET 3.5.1 przed ten komunikat po prostu Pobierz pakiet vBET ponownie i ponownie przekazać plik produktu.

Wprowadzono zmianę, ponieważ możemy znaleźć na naszym forum rzeczywistego to często dostawca jest niedostępny przez krótki czas. Możemy zbada go więcej poszukać innego ulepszeń.

Simon Lloyd
06-10-11, 15:51
Great work guys:), i został uaktualniony do to ale pobierze poprawka najnowsze i wykorzystania, że mogę utworzyć nowego wątku dla opinii w tej sprawie.

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