Help:Extension:Translate/Translation memories/da

Jump to navigation Jump to search
This page is a translated version of the page Help:Extension:Translate/Translation memories and the translation is 64% complete.
Outdated translations are marked like this.
Other languages:
Deutsch • ‎English • ‎Lëtzebuergesch • ‎Nederlands • ‎Zazaki • ‎dansk • ‎español • ‎français • ‎lietuvių • ‎polski • ‎português • ‎português do Brasil • ‎български • ‎русский • ‎українська • ‎العربية • ‎فارسی • ‎தமிழ் • ‎中文 • ‎日本語

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.


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 is open. Unlike the others, remote backends are not updated with translations from the current wiki.

Database Fjernbetjent API Solr eller ElasticSearch
Aktiveret som standard Ja Nej Nej
Kan have flere kilder Nej Ja Ja
Opdateret med lokale oversættelser Ja Nej Ja
Åbner database direkte Ja Nej Nej
Adgang til kilde Skribent Link Lokal skribent eller link
Kan deles som en API-tjeneste Ja Ja Ja
Performance Does not scale well Ukendt Reasonable


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 puppet/modules/elasticsearch/files/elasticsearch.yml 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 ttmserver-export.php it fails. This is because elasticsearch will perform an internal migration progress that may create an incompatible mapping with the one ttmserver-export.php wants to update. You have to use the --reindex flag to force a full rebuild of the index.

As a rule of thumb it is recommended to run ttmserver-export.php with the --reindex 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.

# Solr needs java
sudo apt-get install openjdk-6-jre-headless
# Download and extract solr from:
tar xzf apache-solr-*.tgz
cd apache-solr-*/example
# Copy the config from the extension directory
cp .../Translate/ttmserver/schema.xml solr/conf
# Start serveren
java -jar start.jar

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 config nøglen, som det for eksempel gøres i Wikimedia-konfigurationen.


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


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

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

Example configuration of TTMServers:

Standard konfiguration
$wgTranslateTranslationServices['TTMServer'] = array(
        'database' => false, // Passed to wfGetDB
        'cutoff' => 0.75,
        'type' => 'ttmserver',
        'public' => false,
Fjernbetjent API-konfiguration
$wgTranslateTranslationServices['example'] = array(
        'url' => '',
        'displayname' => '',
        'cutoff' => 0.75,
        'timeout' => 3,
        'type' => 'ttmserver',
        'class' => 'RemoteTTMServer',
ElasticSearch backend configuration
$wgTranslateTranslationServices['TTMServer'] = array(
        'type' => 'ttmserver',
        'class' => 'ElasticSearchTTMServer',
        'cutoff' => 0.75,
         * See
         * See
        'config' => This will be passed to \Elastica\Client
ElasticSearch multible backends configuration (supported by MLEB 2017.04)
// Defines the default service used for read operations
// Allows to quickly switch to another backend
$wgTranslateTranslationDefaultService = 'cluster1';
$wgTranslateTranslationServices['cluster1'] = array(
        'type' => 'ttmserver',
        'class' => 'ElasticSearchTTMServer',
        'cutoff' => 0.75,
         * Defines the list of services to replicate writes to.
         * Only "writable" services are allowed here.
        'mirrors' => [ 'cluster2' ],
        'config' => [ 'servers' => [ 'host' => 'elastic1001.cluster1.mynet' ] ]
$wgTranslateTranslationServices['cluster2'] = array(
        'type' => 'ttmserver',
        'class' => 'ElasticSearchTTMServer',
        'cutoff' => 0.75,
         * if "cluster2" is defined as the default service it will start to replicate writes to "cluster1".
        'mirrors' => [ 'cluster1' ],
        'config' => [ 'servers' => [ 'host' => 'elastic2001.cluster2.mynet' ] ]
Solr bagdels-konfigration
$wgTranslateTranslationServices['TTMServer'] = array(
        'type' => 'ttmserver',
        'class' => 'SolrTTMServer',
        'cutoff' => 0.75,
        /* See
        'config' => This will be passed to Solarium_Client

Mulige nøgler og værdier er:

Nøgle Gælder til Beskrivelse
config Solr og ElasticSearch Solr eksempel-konfiguration for Solarium, se nedenfor.
cutoff Alle Minimumsgrænse for matchende forslag. Kun få de bedste forslag er vist, selv hvis der var flere over grænsen.
database Lokal Hvis du ønsker at gemme oversættelses-hukommelsen et andet sted, kan du angive databasenavnet her. Du skal også konfigurere MediaWiki's load balancer, så den ved hvordan der oprettes forbindelse til databasen.
displayname Fjernbejent Teksten vises i værktøjs-tippet når der peges på forslagets kildelink (punkterne).
index ElasticSearch The index to use in ElasticSearch. Default: ttmserver.
public Alle Hvorvidt denne TTMServer kan forespørges via denne wikis api.php
replicas ElasticSearch If you are running a cluster, you can increase the number of replicas. Default: 0.
shards ElasticSearch How many shards to use. Default: 5.
timeout Fjernbetjent Ventetid på et svar fra fjernbetjent service i sekunder.
type Alle TTMServer-type i form af resultat-format.
url Fjernbetjent URL til api.php af den fjernbetjente TTMServer.
use_wikimedia_extra ElasticSearch Boolean, when the extra plugin is deployed you can disable dynamic scripting on elastic v1.x. This plugin is now mandatory for elastic 2.x clusters.
mirrors Writable services Array of strings, defines the list of services to replicate writes to, it allows to keep multiple TTM services up to date. Useful for fast switch-overs or to reduce downtime during planned maintenance operations (Added in MLEB 2017.04)
Du skal bruge nøglen TTMServer som matrixindekset til $wgTranslateTranslationServices, hvis du ønsker at oversættelseshukommelsen skal opdateres med nye oversættelser. Fjernbetjente TTMServer'ere kan ikke anvendes til det, fordi de ikke kan opdateres. As of MLEB 2017.04 the key TTMServer can be configured with the configuration variable $wgTranslateTranslationDefaultService.

I øjeblikket understøttes kun MySQL for databaserne.


When you have chosen Solr or ElasticSearch and set up the requirements and configuration, run ttmserver-export.php 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 --thread 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.


Hvis du ønsker at anvende din egen TTMServer-tjeneste er specifikationerne her.


Din tjeneste skal acceptere de følgende parametre:

Nøgle Værdi
format json
action ttmserver
service Valgfri tjeneste-id, hvis der er flere fælles oversættelseshukommelser. Hvis intet er angivet antages standard-tjenesten.
sourcelanguage Sprogkode som anvendt i MediaWiki, se IETF sprog-mærker og ISO693?
targetlanguage Sprogkode som anvendt i MediaWiki, se IETF sprog-mærker og ISO693?
test Kildetekst på originalsproget

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

Nøgle Værdi
source Oprindelig kildetekst.
target Oversættelses-forslag.
context Lokal id for kilden, valgfrit.
location URL til siden hvor forslaget kan ses i brug.
quality Decimaltal i intervallet [0..1], som beskriver forslagets kvalitet. 1 betyder perfekt.


        "ttmserver": [
                        "source": "January",
                        "target": "tammikuu",
                        "context": "Wikimedia:Messages\\x5b'January'\\x5d\/en",
                        "location": "https:\/\/\/wiki\/Wikimedia:Messages%5Cx5b%27January%27%5Cx5d\/fi",
                        "quality": 0.85714285714286
                        "source": "January",
                        "target": "tammikuu",
                        "context": "Mantis:S month january\/en",
                        "location": "https:\/\/\/wiki\/Mantis:S_month_january\/fi",
                        "quality": 0.85714285714286
                        "source": "January",
                        "target": "Tammikuu",
                        "context": "FUDforum:Month 1\/en",
                        "location": "https:\/\/\/wiki\/FUDforum:Month_1\/fi",
                        "quality": 0.85714285714286
                        "source": "January",
                        "target": "tammikuun",
                        "context": "MediaWiki:January-gen\/en",
                        "location": "https:\/\/\/wiki\/MediaWiki:January-gen\/fi",
                        "quality": 0.85714285714286
                        "source": "January",
                        "target": "tammikuu",
                        "context": "MediaWiki:January\/en",
                        "location": "https:\/\/\/wiki\/MediaWiki:January\/fi",
                        "quality": 0.85714285714286

Database backend

Bagdelen indeholder tre tabeller: translate_tms, translate_tmt og translate_tmf. De svarer til kilder, mål og fuldtekst. Du kan finde tabeldefinitionerne i sql/translate_tm.sql. 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 Language::segmentByWord. 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:

teksten vi søger forslag til
den foreslåede tekst
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. [1] 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:

    <str name="wiki">sandwiki-bw_</str>
    <str name="uri">http://localhost/wiki/MediaWiki:Action-read/bn</str>
    <str name="messageid">MediaWiki:Action-read</str>
    <str name="globalid">sandwiki-bw_-MediaWiki:Action-read-813862/bn</str>
    <str name="language">bn</str>
    <str name="content">এই পাতাটি পড়ুন</str>
    <arr name="group">
    <long name="_version_">1421795636117766144</long>

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

  1. Opret et nyt dokument

Alle eksisterende dokumenter til meddelelsen må være på trapperne, fordi global id er anderledes.

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

  1. Slet wiki:Z meddelelse:Z
  2. Opret dokument (alle sprog)

Eventuelle yderligere ændringer af definitioner eller oversættelser er ikke opdateret til TM.

Oversættelses-hukommelse forespørgsel

  1. Saml lignende meddelelser med strdist("message definition",content)
  2. Saml oversættelse med globalid:[A,B,C]


  1. Find alle ligheder med teksten:"search query"

Kan indsnævres yderligere med sprog-facetter eller gruppe-felt.

Id-felter Feltet globalid identificerer unikt oversættelsen eller meddelelses-definitionen ved at kombinere de følgende felter:

  • wiki identifikator (MediaWiki database id)
  • meddelelse identifikator (titel på basis-siden)
  • meddelelse versions-identifikator (versions-id af meddelelses-definitionssiden)
  • meddelelsessprog

Det anvendte format er wiki-message-version/language.

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