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)

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.

Installation
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.

Og endelig kan vi udfylde oversættelseshukommelsen med indhold.