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 bagdel

Meget af det ovenstående gælder også for TTMServer med brug af Solr søgeplatform] som bagdel, undtagen detaljerne om databaselayout og forespørgsler. Resultaterne er som standard ordnet efter Levenshtein-algoritmen på Solr-siden, men andre tilgængelige streng-matchende algoritmer kan også anvendes, som for eksempel ngram matching.

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.

Indledende import
 * 1) Udfør ttmserver-export.php kommandolinje-script for hver wiki der bruger den delte oversættelseshukommelse.

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)

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.