Help:Extension:Translate/Translation memories/da

The Translate extension translation memory supports multiple backends. The available backends are database, Solr and ElasticSearch. This page helps you install the best one for you and explains their specifications in deeper detail.

Unlike other translation aids, for instance external machine translation services, the translation memory is constantly updated by new translations in your wiki. Advanced search across translations is also available at Special:SearchTranslations if you choose Solr or ElasticSearch.

Comparison
The database backend is used by default: it has no dependencies and doesn't need configuration. The database backend can't be shared among multiple wikis and it does not scale to large amounts of translated content. Hence we also support Solr and ElasticSearch backends. It is also possible to use another wiki's translation memory via their web API if open. Unlike the others, remote backends are not updated with translations from the current wiki.

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. Elastic offers a migration plugin that may help you to prepare your system before installing the next version. Follow these steps carefully otherwise elasticsearch may refuse to upgrade and you may end up in a delicate situation where you cannot rollback to the previous version.

Once the next major version is installed it's probable that the next time you run  it fails. This is because elasticsearch will perform an internal migration progress that may create an incompatible mapping with the one  wants to update. You have to use the  flag to force a full rebuild of the index.

As a rule of thumb it is recommended to run  with the   flag after major upgrades. You will ensure that your indices are always created with the current elasticsearch version which is a requirement for major upgrades.

Solr backend
Her er de generelle hurtige trin til at installere og konfigurere Solr for TTMServer. Du bør tilpasse dem til din situation.

For at bruge Solr-bagdel behøver du også Solarium-bibliotek. Nemmeste måde er at installere Solarium MediaWiki-udvidelserne. Se eksempelkonfigurationen for Solr-bagdel i konfigurationsafsnittet på denne side. Du kan indstille ekstra konfiguration Solarium via  nøglen, som det for eksempel gøres i Wikimedia-konfigurationen.

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

Configuration
Al oversættelses-hjælp, herunder oversættelses-hukommelse er konfigureret med -konfigurationsindstillingen. Eksempel på konfiguration af TTMServers:

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

Example configuration of TTMServers:

Mulige nøgler og værdier er:

I øjeblikket understøttes kun MySQL for databaserne.

Bootstrap
When you have chosen Solr or 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
Hvis du ønsker du at anvende din egen TTMServer-tjeneste er specifikationerne her.

Forespørgselsparametre:

Din tjeneste skal acceptere de følgende parametre:

Din tjeneste skal give et JSON-objekt, der skal have nøglen  med objekt-matrix. Disse objekter skal indeholde følgende data:

Eksempel:


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

Database backend
Bagdelen indeholder tre tabeller:,   og. De svarer til kilder, mål og fuldtekst. Du kan finde tabeldefinitionerne i. Kilderne indeholder alle meddelelses-definitionerne. Selvom de som regel altid er på det samme sprog, dvs. engelsk, opbevares tekstens sprog også i de sjældne tilfælde, at dette ikke er sandt.

Hver post har et unikt id og 2 ekstra felter, længde og kontekst. Længden bruges som første passerings-filter, så ved forespørgsel behøver vi ikke sammenligne teksten vi søger med hver post i databasen. Konteksten gemmer titlen på den side, hvor teksten kommer fra, for eksempel "MediaWiki:Jan/en". Ud fra denne information kan vi linke forslagene tilbage til "MediaWiki:Jan/da", som gør det muligt for oversættere hurtigt at rette ting eller bare at afgøre, hvor den slags oversættelse er brugt.

Den anden filtrerings-passage kommer fra fuldtekst-søgningen. Definitionerne er blandet med en ad hoc-algoritme. Først er teksten opdelt i inddelinger (ord) med MediaWikis. Hvis der er nok inddelinger, fratager vi dybest set alt hvad der ikke er bogstaver og normaliserer bøjningen. Så kan vi tage de første 10 unikke ord, som er mindst 5 bytes lange (5 bogstaver på engelsk, men kortere ord for sprog med multibyte kodepunkter). Disse ord bliver så lagret i fuldtekst-indekset for yderligere filtrering i længere strenge.

Når vi har filtreret listen over kandidater, henter vi de matchende mål fra mål-tabellen. Så anvender vi Levenshteins afstands-algoritme til at lave den endelige filtrering og rangordning. Lad os definere:


 * E : redigerings-afstand
 * S : teksten vi søger forslag til
 * Tc : den foreslåede tekst
 * To : den oprindelige tekst som Tc er oversættelse af

Kvaliteten af forslaget Tc beregnes som E/min(længde(Tc),længde(To)). Afhængigt af længden af strengene bruger vi enten PHP's oprindelige Levenshtein-funktion eller hvis en af strengene er længere end 255 byte, PHP-anvendelse af Levenshtein-algoritmen. Det er ikke blevet testet om den oprindelige anvendelse af Levenshtein håndterer multibyte tegn korrekt. Dette kan være et svagt punkt når kildesproget ikke er engelsk (de andre er fuldtekst-søgningen og inddeling).

Solr bagdel

Solr Solr search platform backend works similar to the database backend, except that it uses a dedicated search engine for increased speed. The results are by default ranked with the levenshtein algorithm on the Solr side, but other available string matching algorithms can also be used, like ngram matching for example.

I Solr der er ingen tabeller. I stedet har vi dokumenter med felter. Her er et eksempel-dokument:

Hver oversættelse har dets eget dokument og meddelelses-dokumentation har også. For faktisk at få forslag udfører vi først søgningen sorteret efter streng-lighedsalgoritme for alle dokumenter på kildesproget. Så laver vi en anden forespørgsel for at hente oversættelser, hvis der er nogen til disse meddelelser.

Vi bruger masser af kroge for at holde oversættelseshukommelse-databasen opdateret næsten øjeblikkeligt. Hvis brugeren oversætter lignende meddelelser én efter én, kan den tidligere oversættelse (i bedste fald) blive vist som forslag til den næste meddelelse.

Ny oversættelse (hvis ikke uafklaret)
 * 1) Opret dokument

Opdateret oversættelse (hvis ikke uafklaret)
 * 1) Slet wiki:X sprog:Y meddelelse:Z
 * 2) Opret dokument

Opdateret meddelelsesdefinition Alle eksisterende dokumenter til meddelelsen må være på trapperne, fordi global id er anderledes.
 * 1) Opret et nyt dokument

Oversættelse er uafklaret
 * 1) Slet wiki:X sprog:Y meddelelse:Z

Meddelelser skifter gruppe-medlemskab
 * 1) Slet wiki: Z besked: Z
 * 2) Opret dokument (alle sprog)

Meddelelse går ud af brug Eventuelle yderligere ændringer af definitioner eller oversættelser er ikke opdateret til TM.
 * 1) Slet wiki:Z meddelelse:Z
 * 2) Opret dokument (alle sprog)

Oversættelses-hukommelse forespørgsel
 * 1) Saml lignende meddelelser med strdist("message definition",content)
 * 2) Saml oversættelse med globalid:[A,B,C]

Søgeforespørgsel Kan indsnævres yderligere med sprog-facetter eller gruppe-felt.
 * 1) Find alle ligheder med teksten:"search query"

Id-felter Feltet  identificerer unikt oversættelsen eller meddelelses-definitionen ved at kombinere de følgende felter: Det anvendte format er.
 * wiki identifikator (MediaWiki database id)
 * meddelelse identifikator (titel på basis-siden)
 * meddelelse versions-identifikator (versions-id af meddelelses-definitionssiden)
 * meddelelsessprog

Derudover har vi separate felter til wiki-id, meddelelses-id og sprog til at muliggøre de ovennævnte sletteforespørgslerne.