Help:Extension:Translate/Translation memories/nl

De Translate extensie translation memory ondersteunt ElasticSearch. Het doel van deze pagina is het helpen bij de installatie van ElasticSearch, en de specificaties gedetailleerd te beschrijven.

Anders dan andere hulpmiddelen voor vertalen, bijvoorbeeld externe machine vertaal services, worst het vertaalgeheugen steeds bijgewerkt door nieuwe vertalingen in uw wiki. Geavanceerde zoeken in vertalingen is ook beschikbaar via Special:SearchTranslations als u er voor kiest om ElasticSearch te gebruiken.

Vergelijken
De database backend wordt standaard gebruikt: het heeft geen afhankelijkheden en heeft geen configuratie nodig. De database backend kan niet worden gedeeld door meerdere wiki'sen het schaalt niet bij grote hoeveelheden vertaalde tekst. Vandaar dat wij ook ElasticSearch als backend ondersteunen. Het is ook mogelijk om ander vertaalgeheugens te gebruiken als hun web API open is. Ander dan ElasticSearch worden remote backends niet bijgewerkt met vertalingen in de huidige wiki.

Vereisten


ElasticSearch backend
ElasticSearch is relatively easy to set up. If it is not available in your distribution packages, you can get it from their website. You will also need to get the Elastica extension. Finally, please see for specific configuration needed by Translate.

The bootstrap script will create necessary schemas. If you are using ElasticSearch backend with multiple wikis, they will share the translation memory by default, unless you set the index parameter in the configuration.

When upgrading to the next major version of ElasticSearch (e.g. upgrading from 2.x to 5.x), it is highly recommended to read the release notes and the documentation regarding the upgrade process.

Installatie
After putting the requirements in place, installation requires you to tweak the configuration and then execute the bootstrap.

Configuratie
Alle hulpmiddelen voor vertalen inclusief vertaalgeheugen worden ingesteld met de instelling.

The primary translation memory backend must use the key. The primary backend receives translation updates and is used by Special:SearchTranslations.

Voorbeeld van configuratie TTMServers:

Possible keys and values are:

Currently only MySQL is supported for the database backend.

Bootstrap
Once you have chosen ElasticSearch and set up the requirements and configuration, run  to bootstrap the translation memory. Bootstrapping is also required when changing translation memory backend. If you are using a shared translation memory backend for multiple wikis, you'll need to bootstrap each of them separately.

Sites with lots of translations should consider using multiple threads with the  parameter to speed up the process. The time depends heavily on how complete the message group completion stats are (incomplete ones will be calculated during the bootstrap). New translations are automatically added by a hook. New sources (message definitions) are added when the first translation is created.

Bootstrap does the following things, which don't happen otherwise:
 * adding and updating the translation memory schema;
 * populating the translation memory with existing translations;
 * cleaning up unused translation entries by emptying and re-populating the translation memory.

When the translation of a message is updated, the previous translation is removed from the translation memory. However, when translations are updated against a new definition, a new entry is added but the old definition and its old translations remain in the database until purged. When a message changes definition or is removed from all message groups, nothing happens immediately. Saving a translation as fuzzy does not add a new translation nor delete an old one in the translation memory.



TTMServer API
If you would like to implement your own TTMServer service, here are the specifications.

Query parameters:

Your service must accept the following parameters:

Your service must provide a JSON object that must have the key  with an array of objects. Those objects must contain the following data:

Voorbeeld:


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



Database backend
The backend contains three tables:,   and. Those correspond to sources, targets and fulltext. You can find the table definitions in. The sources contain all the message definitions. Even though usually they are always in the same language, say, English, the language of the text is also stored for the rare cases this is not true.

Each entry has a unique id and two extra fields, length and context. Length is used as the first pass filter, so that when querying we don't need to compare the text we're searching with every entry in the database. The context stores the title of the page where the text comes from, for example "MediaWiki:Jan/en". From this information we can link the suggestions back to "MediaWiki:Jan/de", which makes it possible for translators to quickly fix things, or just to determine where that kind of translation was used.

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).