Apertium - tłumaczenia innego interfejsu API będą obsługiwane w vBET?

[vBET]

Witam:)

Chcemy tylko w celu zagwarantowania, że są nam nowe możliwości dla tłumaczenia. W tym momencie pracujemy nad obsługuje tłumaczenie Apertium (http://wiki.apertium.org/wiki/Apertium_web_service) interfejsu API. Po przeczytaniu Terms Of Service stwierdziliśmy, bez ograniczenia zaświadczających go w vBET (nadal wyślemy e-mail z pytaniem, tak aby upewnić się, że).

Interfejs API jest teraz (nie wiemy będzie go przełącza się na zapłacone jednej) obsługuje wiele par językowych i jest nadal w fazie beta. W tej chwili mamy nie idea ograniczeń, jakie mają (możemy wiedzieć że niektóre ograniczenia są ustawione). Także jakość tłumaczenia nie wiadomo jeszcze. Wystarczy rozpocząć eksperymentowanie z nią, także nadal czekamy na odpowiedź z zespołu Apertium, dzięki czemu możemy nie może sprawdzić dużo jeszcze. Nadal chcemy wiedzieć, że chcielibyśmy wsparcia w vBET API tyle możliwie pozwala na większy wybór i tłumaczenia więcej w przypadku limity określone w jeden interfejs API.

Wszelkie istotne informacje o Apertium integracji opublikujemy.

[vBET]

Niektóre informacje po pierwsze testy.

Mamy już, jego pracy w vBET (vBET jest łatwo dodać nowe tłumaczenie API).
Wydajność Apertium tłumaczenia API w tej chwili jest słaba. Krótki wniosek odpowiedzi są w około 300 milisekund, jaka jest OK. Nadal długim żądania odpowiedzi są nawet w 13 sekund (czas reakcji różnych - w naszym kilka badań między 5-13 sekund). Oczywiście możemy zrobić nic w tej dziedzinie,-to jest dla vBET czas oczekiwania — Trwa oczekiwanie na odpowiedź. Nie można powiedzieć, czy wydajność jest ulepszana tutaj - to trzecia strona usługi. To nie jest krytyczny problem ponieważ po buforowanie vBET niezwłocznie pobiera tłumaczenia, nadal dla niektórych forów to można go nie dopuszczalne dla strony do obciążenia 20 sekund - nawet, jeśli to tylko pierwsze tłumaczenie. Z drugiej strony - kto chce mieć szybkie tłumaczenie mają opcje w API płatnego, tak w braku innych wolna interfejsów API (Microsoft będzie nadal wolna tylko dla limitu 2 miliony znaków/miesiąc-, ale będzie on nadal wolna).

Będzie przetestujemy go również na forum badań i rzeczywistym. W tym momencie przekażemy tylko kilka badań (już w kodzie vBET) na forum niewielką ilość.

Również już widzimy że będzie musimy dodać nowe możliwości konfiguracji w vBET - jak możliwość powoływania priorytety dostawców globalnie. Teraz mogą być wykonywane przez edytowanie wielu plików konfiguracyjnych i widzimy, że nie jest sposób. Możemy nie przewidują, iż tak duże zmiany zostaną wprowadzone w rynku tłumaczenia, ale mamy przyjmie:)

[vBET]

Rozpoczęliśmy już, badania Apertium API tłumaczenia na naszym forum rzeczywistego. Ustanowiliśmy dzienniki, więc po pewnym czasie będziemy mogli wiedzieć więcej informacji o rzeczywistych wyników.

W tej chwili vBET obsługuje 30 kierunki tłumaczenia z Apertium (ma więcej, ale nie wspólne dla innych silników tłumaczenia). Widzimy już, że dodanie Apertium do vBET jest dobrym pomysłem, nawet jeśli wydajności nie jest najlepsza (ostatecznie mamy pamięci podręcznej tak netto czas, który jest natychmiastowe). Widzimy w dziennikach - gdzie inne limity osiągnięto obecnie jesteśmy wciąż zdolny do tłumaczenia dzięki Apertium. W tym momencie z dzienników widzimy że są głównie tłumaczenia z języka angielskiego (większość zawartości tutaj jest w języku angielskim) do: es, ca, gl kurs jest obsługiwana więcej.

Aby wyświetlić pełną listę języków obsługiwanych par można znaleźć tutaj: http://api.apertium.org/json/listPairs
Te są kierunki tłumaczenia, których obecnie nie będą (przynajmniej teraz) obsługiwane:


oc => es
es => ca_valencia
oc_aran => ca
an => es
fr => eo
nb => nn_a
ca => en_US
ca => oc_aran
nn => nb
ca => oc
oc_aran => es
es => eo
oc => ca
br => fr
en => eo
ca => eo
es => oc_aran
nn => nn_a
es => pt_BR
es => oc
es => an
eo => en
nn_a => nn
es => en_US
nb => nn

Możemy będzie obsługuje teraz, ponieważ nie jest obsługiwane wszystkie dla wszystkich i innych silników nie mają takich języków. Sprawdzamy będzie nadal, nie jest niektóre kody mogą być po prostu mapowane w przypadku jeśli ten sam język z innymi kodami zastosowano inne tłumaczenie interfejsów API. Mimo to w pierwszym wydaniu wspieranie Apertium nam nie obsługują wszystkie pary.

Firma ma (i są gotowe do zrobić to teraz) umożliwiające Apertium te kierunki tłumaczenia:


bg => mk
ca => en
ca => es
ca => fr
ca => pt
cy => en
da => sv
en => ca
en => es
en => gl
es => ca
es => en
es => gl
es => pt
es => ro
eu => es
fr => cs
fr => es
gl => en
gl => es
gl => pt
is => en
it => ca
mk => bg
mk => en
pt => ca
pt => es
pt => gl
ro => es
sv => da

Powinny być 30 osób. Jeśli bardzo brakuje czegoś napisz do nas. Także jeśli otrzymasz informacje o nowe kierunki tłumaczenia obsługiwane, następnie również proszę dać nam znać.

[Simon Lloyd]

Wielkiej pracy Michael:), więcej kluczy API możemy wkroczyć do różnych API lepsze, nawet jeśli są one wypłacane jedynek, mogłyby wprowadzić pola wyboru dla użytkowników móc włączyć/wyłączyć te zapłacone api firmy, które chcą używać - Nicei zobaczyć rozwijanie mimo to!

[vBET]

Tak już rozważaliśmy też udzielenia opcję, aby włączyć lub wyłączyć niektóre API bez zmian w plikach konfiguracyjnych. W tym momencie myślę, że będzie on po prostu rozpoznawany przez interfejs API klucz. Jeżeli klucz interfejsu API nie jest używana przez niektóre API tłumaczenie API nie jest używany. Dobrze jest nie wprowadzone jeszcze - tylko teraz.

[vBET]

Ponieważ dodamy Apertium wsparcie w następnym wydaniu nastąpi zmiana małych licencji - Apertium zostaną także wyświetlone jako dostawca tłumaczeń.