Help:Extension:Translate/Translation memories/cs

Rozšíření překladové paměti podporuje ElasticSearch. Cílem této stránky je provést vás při instalaci ElasticSearch a podrobněji prozkoumat jeho specifikace.

Na rozdíl od jiných překladových pomůcek, například externích služeb strojového překladu, je překladová paměť neustále aktualizována novými překlady na vaší wiki. Rozšířené vyhledávání v překladech, pokud se rozhodnete použít ElasticSearch, je také k dispozici na stránce Speciál:Hledat Překlady (Special:SearchTranslations).

Srovnání
Ve výchozím nastavení se používá databázový backend (slouží k administraci a ke zpracování dat): Nemá žádné závislosti a nevyžaduje konfiguraci. Databázový backend nelze sdílet mezi více wiki a nelze jej rozšiřovat na velké množství přeloženého obsahu. Proto také podporujeme ElasticSearch jako backend. Je také možné použít překladovou paměť jiné wiki, pokud je otevřené její webové API. Na rozdíl od ElasticSearch nejsou vzdálené backendy aktualizovány překlady z aktuální wiki.

ElasticSearch backend
Nastavení ElasticSearch je relativně snadné. Pokud není ve vašich distribučních balíčcích k dispozici, můžete si jej stáhnout z jejich webových stránek. Budete také muset získat Elastica rozšíření. Nakonec se podívejte na pro konkrétní konfiguraci potřebnou pro překlad.

Skript bootstrapu (samozaváděcího programu) vytvoří potřebná schémata. Pokud používáte backend ElasticSearch s více wiki, budou ve výchozím nastavení sdílet překladovou paměť. Pokud nenastavíte parametr indexu v konfiguraci.

Při aktualizaci na další hlavní verzi ElasticSearch (např. aktualizace z 2.x na 5.x) se důrazně doporučuje přečíst poznámky k verzi a dokumentaci týkající se procesu aktualizace.

Instalace
Po zavedení požadavků instalace vyžaduje, abyste vyladili konfiguraci a poté spustili bootstrap (samozaváděcí program).

Konfigurace
Všechny překladové pomůcky včetně překladových pamětí jsou konfigurovány pomocí konfigurační proměnné.

Backend primární překladové paměti musí používat klíč. Primární backend přijímá aktualizace překladu a používá ho Speciál:Hledat překlady (Special:SearchTranslations).

Příklad konfigurace TTMServers:

Možné klíče a hodnoty jsou:

V současné době je pro backend databáze podporována pouze MySQL.

Bootstrap (samozaváděcí program)
Jakmile vyberete ElasticSearch a nastavíte požadavky a konfiguraci, spusťte  pro zavedení překladové paměti. Bootstrapping je vyžadován také při změně backendu překladové paměti. Pokud používáte backend sdílené překladové paměti pro více wiki, musíte každou z nich zavést samostatně.

Weby s množstvím překladů by měly zvážit, pro urychlení procesu, použití více vláken s parametrem. Čas do značné míry závisí na tom, jak kompletní jsou statistiky dokončení skupiny zpráv (neúplné budou vypočteny během zavádění systému). Nové překlady jsou automaticky přidávány pomocí háčku. Při vytvoření prvního překladu jsou přidány nové zdroje (definice zpráv).

Bootstrap dělá následující věci, které se jinak nedějí:
 * přidávání a aktualizace schématu překladové paměti;
 * naplnění překladové paměti stávajícími překlady;
 * vyčištění nepoužívaných překladových záznamů vyprázdněním a opětovným naplněním překladové paměti.

Po aktualizaci překladu zprávy se předchozí překlad odstraní z překladové paměti. Když se však překlady aktualizují oproti nové definici, přidá se nová položka, ale stará definice a její staré překlady zůstanou v databázi, dokud nebudou vymazány. Když zpráva změní definici nebo je odstraněna ze všech skupin zpráv, nic se nestane okamžitě. Uložení překladu jako fuzzy nepřidá nový překlad ani neodstraní starý překlad v překladové paměti.

TTMServer API
Pokud byste chtěli implementovat vlastní službu TTMServer, zde jsou specifikace.

Parametry dotazu:

Vaše služba musí akceptovat následující parametry:

Vaše služba musí poskytnout objekt JSON, který musí mít klíč  s řadou objektů. Tyto objekty musí obsahovat následující údaje:

Příklad:


 * URL: http://translatewiki.net/w/api.php?action=ttmserver&sourcelanguage=en&targetlanguage=fi&text=january&format=jsonfm
 * Odezva:

Backend databáze
Backend obsahuje tři tabulky:,   a. Odpovídají zdrojům, cílům a fulltextům. Definice tabulky najdete v. Zdroje obsahují všechny definice zpráv. I když jsou obvykle vždy ve stejném jazyce, řekněme anglicky, jazyk textu je také uložen pro vzácné případy, což není běžné.

Každá položka má jedinečné id a dvě další pole, délku a kontext. Délka se používá jako filtr prvního průchodu, takže při dotazování nemusíme porovnávat hledaný text s každou položkou v databázi. Kontext ukládá název stránky, odkud text pochází, například "MediaWiki:Jan/en". Z těchto informací můžeme návrhy propojit zpět na "MediaWiki:Jan/cs", což umožňuje překladatelům rychle opravit věci nebo jen určit, kde byl tento druh překladu použit.

Druhý průchod filtrování pochází z fulltextového vyhledávání. Definice se mísí s ad hoc algoritmem. Nejprve je text rozdělen do segmentů (slov) pomocí  od MediaWiki. Pokud je k dispozici dostatek segmentů, v podstatě odejmeme všechno, co není slovo a normalizujeme případ. Potom vezmeme prvních deset jedinečných slov, která jsou dlouhá alespoň 5 bajtů (5 písmen v angličtině, ale i kratší slova pro jazyky s vícebajtovými kódovými body). Tato slova jsou potom uložena v fulltextovém indexu pro další filtrování pro delší řetězce.

Když jsme vyfiltrovali seznam kandidátů, načteme odpovídající cíle z tabulky cílů. Potom použijeme levenshtein editovací algoritmus vzdálenosti, abychom provedli finální filtrování a hodnocení. Definujme:


 * E: uprava vzdálenosti
 * S: text, kterým hledáme návrhy
 * Tc: text návrhu
 * To: původní text, do kterého Tc překládá

Kvalita návrhu Tc se počítá jako E/min (délka (Tc), délka (To)). V závislosti na délce řetězců používáme: buď nativní funkci levenshteinu PHP. Nebo, pokud je některý z řetězců delší než 255 bajtů, implementace algoritmu levenshtein v PHP. $1 nebylo testováno, zda nativní implementace levenshtein správně zpracovává vícebajtové znaky. To může být další slabou stránkou, pokud zdrojovým jazykem není angličtina (ostatní jsou fulltextové vyhledávání a segmentace).  It has not been tested whether the native implementation of levenshtein handles multibyte characters correctly. This might be another weak point when source language is not English (the others being the fulltext search and segmentation).