Help:Extension:Translate/Translation memories/de

Der Übersetzungsspeicher unterstützt ElasticSearch. Diese Seite soll dich bei der Installation von ElasticSearch unterstützen und dir die Spezifikationen detailliert erklären.

Im Gegensatz zu anderen Übersetzungshilfen wie maschinellen Übersetzungsdienstleistungen wird der Übersetzungsspeicher permanent durch neue Übersetzungen in deinem Wiki aktualisiert. Über die erweiterte Suche Special:SearchTranslations kannst du Übersetzungen durchsuchen, wenn du ElasticSearch verwendest.

Vergleich
Standardmäßig wird das Backend der Datenbank genutzt: es hat keine Abhängigkeiten und muss nicht konfiguriert werden. Das Datenbank-Backend kann nicht unter mehreren Wikis geteilt werden und erreicht keine großen Mengen übersetzter Inhalte. Daher unterstützen wir auch ElasticSearch als Backend. Es ist auch möglich, den Übersetzungsspeicher eines anderen Wikis zu nutzen, wenn dessen Web-API offen ist. Im Gegensatz zu ElasticSearch werden Remote-Backends nicht mit Übersetzungen des aktuellen Wikis aktualisiert.

ElasticSearch-Backend
ElasticSearch kann relativ einfach aufgesetzt werden. Wenn es nicht in deinem Paket enthalten ist, kannst du es von ihrer Webseite erhalten. Außerdem benötigst du die Elastica-Erweiterung. Abschließend siehe bitte für die spezifische Konfiguration, die für die Übersetzungserweiterung erforderlich ist.

Das Bootstrap-Skript wird die nötigen Schemas erstellen. Wenn du das ElasticSearch-Backend mit mehreren Wikis teilst, werden sie sich den Übersetzungsspeicher standardmäßig teilen, außer du setzt in der Konfiguration den Index-Parameter.

Wenn du auf die nächste große Version von ElasticSearch aktualisierst (z.B. Update von 2.x auf 5.x), wird unbedingt empfohlen, die Veröffentlichungshinweise und die Dokumentation im Hinblick auf den Aktualisierungsprozess zu lesen.

Installation
Nachdem du die Anforderungen festgelegt hast, erfordert die Installation, dass du die Konfiguration anpasst und dann den Bootstrap ausführst.

Konfiguration
Alle Übersetzungshilfen, die Übersetzungsspeicher nutzen, werden über die Konfigurationsvariable  konfiguriert.

Das Hauptübersetzungsspeicher-Backend muss den Schlüssel  nutzen. Das Haupt-Backend erhält Übersetzungsaktualisierungen und wird von Special:SearchTranslations genutzt.

Beispielkonfiguration eines TTMServers:

Mögliche Schlüssel und Werte sind:

Derzeit wird nur MySQL für das Datenbank-Backend unterstützt.

Hochfahren
Wenn du ElasticSearch ausgewählt und die Anforderungen und die Konfiguration gesetzt hast, führe  aus, um den Übersetzungsspeicher zu bootstrappen. Bootstrapping ist auch erforderlich, wenn du das Übersetzungsspeicher-Backend änderst. Wenn du ein gemeinsames Übersetzungsspeicher-Backend für mehrere Wikis nutzt, musst du jedes einzeln bootstrappen.

Seiten mit vielen Übersetzungen sollten erwägen, mehrere Threads mit dem -Parameter zu nutzen, um die Geschwindigkeit des Prozesses zu erhöhen. Die Dauer hängt stark davon ab, wie vollständig die Vollständigkeitsstatistik der Nachrichtengruppen ist (unvollständige werden während des Bootstrappings errechnet). Neue Übersetzungen werden automatisch über eine Hook hinzugefügt. Neue Quellen (Nachrichtendefinitionen) werden hinzugefügt, wenn die erste Übersetzung erstellt wird.

Bootstrap bewirkt folgende Dinge, die sonst nicht erfolgen:
 * Hinzufügen und Aktualisieren des Übersetzungsspeicher-Schemas;
 * Befüllen des Übersetzungsspeichers mit vorhandenen Übersetzungen;
 * Entfernen ungenutzter Übersetzungseinträge durch das Leeren und Neubefüllen des Übersetzungsspeichers.

Wenn die Übersetzung einer Nachricht aktualisiert wird, wird die vorherige Übersetzung aus dem Übersetzungsspeicher entfernt. Wenn jedoch Übersetzungen gegen eine neue Definition aktualisiert werden, wird ein neuer Eintrag hinzugefügt und die alte Definition und ihre Übersetzung bleiben in der Datenbank erhalten, bis diese aktualisiert wird. Wenn sich die Definition einer Nachricht ändert oder sie aus allen Nachrichtengruppen entfernt wird, passiert zunächst nichts. Eine Übersetzung als fuzzy zu speichern, fügt keine neue Übersetzung hinzu und löscht keine alte aus dem Übersetzungsspeicher.

TTMServer-API
Wenn du deinen eigenen TTMServer-Dienst implementieren möchtest, findest du hier die Spezifikationen.

Abfrageparameter:

Dein Dienst muss folgende Parameter entgegennehmen:

Dein Service muss ein JSON-Objekt anbieten, das einen Schlüssel  mit einem Bereich von Objekten haben muss. Diese Objekte müssen die folgenden Daten enthalten:

Beispiel:


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

Datenbankunterbau
Das Backend enthält drei Tabellen:,   und. Diese entsprechen Quellen, Zielen und Volltext. Du kannst die Tabellendefinitionen in  finden. Die Quellen enthalten alle Nachrichtendefinitionen. Obwohl sie normalerweise alle in der gleichen Sprache, beispielsweise Englisch, gespeichert werden, wird die Sprache des Textes für seltene Fälle, in denen dies nicht so ist, ebenfalls gespeichert.

Jeder Eintrag hat eine einzigartige ID und zwei zusätzliche Felder, Länge und Kontext. Die Länge wird gewöhnlich als erster Filter genutzt, sodass wir bei einer Abfrage den Text, den wir suchen, nicht mit allen Einträgen der Datenbank abgleichen müssen. Der Kontext speichert den Titel der Seite, aus der der Text stammt, beispielsweise "MediaWiki:Jan/en". Über diese Information können wir die Vorschläge auf "MediaWiki:Jan/de" verlinken, was es Übersetzern ermöglicht, schnell Fehler zu beheben oder festzustellen, wo diese Übersetzung genutzt wurde.

The second pass of filtering comes from the fulltext search. The definitions are mingled with an ad hoc algorithm. First the text is segmented into segments (words) with MediaWiki's. If there are enough segments, we strip basically everything that is not word letters and normalize the case. Then we take the first ten unique words, which are at least 5 bytes long (5 letters in English, but even shorter words for languages with multibyte code points). Those words are then stored in the fulltext index for further filtering for longer strings.

When we have filtered the list of candidates, we fetch the matching targets from the targets table. Then we apply the levenshtein edit distance algorithm to do the final filtering and ranking. Let's define:


 * E : edit distance
 * S : the text we are searching suggestions for
 * Tc : the suggestion text
 * To : the original text which the Tc is translation of

The quality of suggestion Tc is calculated as E/min(length(Tc),length(To)). Depending on the length of the strings, we use: either PHP's native levenshtein function; or, if either of the strings is longer than 255 bytes, the PHP implementation of levenshtein algorithm. 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).