Help:Extension:Translate/Translation memories/da

TTMServer er en server til oversættelses-hukommelse, der følger med Translate-udvidelsen. Den kræver ingen eksterne afhængigheder. Den er aktiveret som standard og erstatter understøttelse af tmserver fra translatetoolkit, som var svær at opsætte. TTMServer er en simpel oversættelses-hukommelse og den bruger ikke nogen avancerede algoritmer. Den drager imidlertid fordel af MediaWikis fremragende understøttelse af sprog og databasens indvindings-funktioner.

Der er 3 forskellige måder at bruge TTMServer:

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

Mulige nøgler og værdier er:

I øjeblikket understøttes kun MySQL for databaserne.

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:

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

Der er et script, der fylder oversættelses-hukommelsen med oversættelser fra de aktive meddelelsesgrupper. Selv store websites bør være i stand til at opstarte hukommelsen i en halv time ved brug af flere tråde med -parameter. Tiden afhænger meget af hvor komplet meddelelsesgruppens færdiggørelsesstatistik er (ufuldstændige vil blive beregnet under opstartsprocessen). Nye oversættelser tilføjes automatisk af en krog. Nye kilder (definitioner) tilføjes når første oversættelse er tilføjet.

Gamle oversættelser som ikke længere anvendes og ikke tilhører nogen meddelelsesgrupper renses ikke automatisk, medmindre du igen kører opstarts-scriptet. Når oversættelsen af ​​en meddelelse er opdateret, fjernes den tidligere oversættelse fra hukommelsen. Når definitionen er opdateret sker der ikke noget med det samme. Når oversættelser er opdateret med den nye definition, vil en ny post tilføjes. Den gamle definition og dens gamle oversættelser bliver i databasen indtil udrensning sker ved kørsel af opstarts-script. Oversættelses-hukommelsen får ikke tilføjet uafklarede oversættelser, ligesom oversættelserne heller ikke fjernes fra hukommelsen.

Solr backend
Much of the above also applies to the TTMServer using the Solr search platform as backend, except the details on database layout and queries. 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.

In Solr there are no tables. Instead we have documents with fields. Here is an example document: Each translation has its own document and message documentation has one too. To actually get suggestions we first perform the search sorted by string similarity algorithm for all documents in the source language. Then we do another query to fetch translations if any for those messages.

We are using lots of hooks to keep the translation memory database updated in almost real time. If user translates similar messages one after another, the previous translation can (in the best case) be displayed as suggestion for the next message.

Initial import
 * 1) Execute ttmserver-export.php command line script for each wiki using the shared translation memory.

New translation (if not fuzzy)
 * 1) Create document

Updated translation (if not fuzzy)
 * 1) Delete wiki:X language:Y message:Z
 * 2) Create document

Updated message definition All existing documents for the message stay around because globalid is different.
 * 1) Create new document

Translation is fuzzied
 * 1) Delete wiki:X language:Y message:Z

Messages changes group membership
 * 1) Delete wiki:Z message:Z
 * 2) Create document (for all languages)

Message goes out of use Any further changes to definitions or translations are not updated to TM.
 * 1) Delete wiki:Z message:Z
 * 2) Create document (for all languages)

Translation memory query
 * 1) Collect similar messages with strdist("message definition",content)
 * 2) Collect translation with globalid:[A,B,C]

Search query Can be narrowed further by facets on language or group field.
 * 1) Find all matches with text:"search query"

Identifier fields Field  uniquely identifies the translation or message definition by combining the following fields: The used format is.
 * wiki identifier (MediaWiki database id)
 * message identifier (Title of the base page)
 * message version identifier (Revision id of the message definition page)
 * message language

In addition we have separate fields for wiki id, message id and language to make the delete queries listed above possible.

Installation
Here are the general quick steps for installing and configuring Solr for TTMServer. You should adapt them to your situation. To use Solrbackend you also need Solarium library. Easiest way is to install the Solarium MediaWiki extensions. See the example configuration for Solr backend at the configuration section of this page. You can pass extra configuration to Solarium via the  key like done for example in the Wikimedia configuration.

And finally we can populate the translation memory with content.