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 elastica library via the Elastica extension or Composer. 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.

Solr backend
Her er de generelle hurtige trin til at installere og konfigurere Solr for TTMServer. Du bør tilpasse dem til din situation. To use Solr backend you also need Solarium library. The easiest way is to  install the Solarium extension. See the example configuration for Solr backend in the configuration section of this page. You can pass extra configuration to Solarium via the  key as done for example  in the.

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

Configuration
All translation aids including translation memories are configured with the  configuration variable.

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:

Currently only MySQL is supported for the database backend.

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.