Content translation/Developers/Markup/nl

In Content translation (ContentTranslation) vertalen vertalers html-content. HTML bevat alle mogelijke markeringen die een typisch Wikipedia-artikel heeft. Dit betekent dat de machinevertaling op HTML-inhoud is. Maar niet alle MT-engines ondersteunen HTML-inhoud.

Sommige engines, zoals Moses, geven direct informatie over de uitlijning van subzinnen, waarmee wordt getoond welke bronwoorden overeenkomen met welke doelwoorden.

$ echo 'das ist ein kleines haus' | moses -f phrase-model/moses.ini -t

this is |0-1| a |2-2| small |3-3| house |4-4|

De Apertium MT engine vertaalt opgemaakte tekst niet waarheidsgetrouw. Markup zoals HTML-tags wordt behandeld als een vorm van lege ruimte. Dit kan leiden tot semantische veranderingen (als woorden anders worden gerangschikt) of syntactische fouten (als koppelingen niet één op één zijn).

$ echo 'legal <b>persons</b>' | apertium en-es -f html
Personas <b>legales</b>

$ echo 'I <b>am</b> David' | apertium en-es -f html
Soy</b> David

Andere MT-engines hebben vergelijkbare problemen. Dit maakt het moeilijk om machinevertalingen van geformatteerde tekst te leveren. Dit document legt uit hoe deze uitdaging in ContentTranslation wordt aangepakt.

Zoals we in de bovenstaande voorbeelden hebben gezien, kan een MT-engine (machinevertaling engine) de volgende fouten veroorzaken in de vertaalde HTML. De fouten zijn in afnemende volgorde van ernst vermeld.

1. Corrupt markup - Als de ME zich niet bewust is van de HTML-structuur, kunnen ze de HTML-tags mogelijk willekeurig verplaatsen, waardoor het resultaat beschadigd wordt.
2. Wrongly placed annotations - De twee hierboven genoemde voorbeelden illustreren dit. Het is ernstiger als de inhoud links bevat en de verwijzingen van de links zijn verwisseld of willekeurig weergegeven in het resultaat.
3. Missing annotations - Soms laat de MT-engine enkele tags weg in het vertaalproces.
4. Split annotations - Tijdens de vertaling kan één woord in meer dan één woord worden vertaald. Als het bronwoord een markering heeft, zeg de tag ‎<a>. Zal de MT-engine de tag ‎<a> toepassen die beide woorden omvat of op elk woord toepassen?

Al deze problemen kunnen bij vertalers slechte ervaringen veroorzaken.

Naast mogelijke problemen met de overdracht van markup is er nog een ander aspect van het verzenden van HTML-inhoud naar MT-engines. In vergelijking met een gewone tekstversie van een alinea is de HTML-versie groter in grootte (bytes). De meeste van deze extra toevoegingen zijn tags en attributen die niet door de vertaling moeten worden beïnvloed. Dit is onnodig bandbreedtegebruik. Als de MT-engine een gemeten engine is (niet-vrij, API-toegang wordt gemeten en beperkt), zijn we niet economisch bezig.

Overzicht

• De invoer HTML-inhoud wordt vertaald in een LinearDoc, met inline markup (zoals vet en links) opgeslagen als attributen op een lineaire reeks tekststukken. Dit lineair formaat is handig voor belangrijke tekstmanipulatieoperaties, zoals anders rangschikken en opdelen, die moeilijk zijn om uit te voeren op een HTML-string of een DOM-boom.
• De platte tekstzinnen (met alle inline-markering verwijderd) worden naar de MT-engine gestuurd voor vertaling.
• De MT-engine geeft een platte tekst vertaling terug, samen met informatie over de onderverdeling van de subzinnen (met vermelding van welke delen van de brontekst overeenkomen met welke delen van het vertaalde tekst).
• De uitlijningsinformatie wordt gebruikt om de markering opnieuw toe te passen op de vertaalde tekst.

Hierdoor wordt gewaarborgd dat MT-engines alleen gewone tekst vertalen en dat een markering wordt toegepast als na de vertaling.

Om de markering over te dragen, hebben we eerst een algoritme geprobeerd gebaseerd op waarneming van veranderingen in de gevallen. Om de vertaling van een woord te vinden dat mogelijk in vertaalde tekst anders is gerangschikt, wordt een zin vertaald zoals het is en als dat specifieke woord in hoofdletters is. Door de uitvoer van beide te vergelijken, zal de diff vertellen waar de woordvertaling in de vertaling voorkomt. Deze aanpak en de beperkingen daarvan worden hieronder vermeld. Later zien we een meer geavanceerd algoritme.

Annotatietoewijzing met behulp van vertaalde deelrij benadering

Dit is het algoritme (translation subsequence approximation) dat momenteel wordt gebruikt in ContentTranslation. Dit algoritme probeert de beperkingen van het net genoemde hoofdletteralgoritme te overwinnen.

In wezen doet het algoritme een fuzzy match om de doellocaties in vertaalde tekst te vinden om annotaties (aantekeningen of verduidelijkingen van een onderwerp) toe te passen. Ook hier is de inhoud van MT-engines alleen maar gewone tekst.

De stappen zijn hieronder beschreven.

1. Zoek in de te vertalen tekst naar inline annotaties zoals vet, cursief, links, enz. We noemen het subsequenties.
2. Stuur de volledige tekst en de daaropvolgende delen naar de mt-engine voor platte tekst (plaintext). Gebruik een scheidingsteken zodat we de array-toewijzing tussen bronitems (volledige tekst en subsequenties) en vertaalde items kunnen doen.
3. De volledige tekst die wordt vertaald, zal ergens in de tekst de subsequences hebben. Om die in de volledige tekstvertaling te vinden, gebruik een benadering zoekalgoritme
4. Dit zoekalgoritme geeft de startpositie van de match en de lengte van de match terug. Op dat bereik maken we de annotatie van de bron html.
5. De match houdt in dat de bewerkingsafstand tussen woorden in de vertaalde volledige tekst en de vertaalde volgorde wordt berekend. Het zijn geen stringen die worden gezocht, maar ngrammen met n = aantal woorden in de subsequence. Elk woord in de ngram wordt onafhankelijk gematchd.

Om dit te begrijpen, laten we het algoritme in een paar voorbeelden proberen.

1. Vertaal van de Spaanse zin <p>Es <s>además</s> de Valencia</p> naar het Catalaans: de platte tekstversie is Es además de Valencia en de subsequence met annotatie is además. De volledige tekst en de subsequence worden aan MT gegeven. De volledige tekst is vertaald als A més de València, het woord además is vertaald als a més. We zoeken naar a més in de volledige vertaling. De zoekopdracht zal succesvol zijn en de tag ‎<s> zal worden toegepast, het resultaat is <p>És <s>a més</s> de València</p>. De zoekopdracht in dit voorbeeld is een exacte zoekopdracht naar gewone tekst. Maar het volgende voorbeeld toont aan waarom het niet een exacte zoekopdracht kan zijn.
2. Een Engelse zin <p>A <b>Japanese</b> <i>BBC</i> article</p> vertalen naar het Spaans. De volledige tekstvertaling hiervan is Un artículo de BBC japonés.  Een van de subsequence Japanese zal worden vertaald als Japonés. De hoofdletter van J verschilt en het zoeken moet slim genoeg zijn om japonés te identificeren als een match voor Japonés. De woordvolgorde in de brontekst en de vertaling wordt al door het algoritme behandeld. Het volgende voorbeeld zal illustreren dat er niet alleen veranderingen in hoofd/kleine letters plaatsvindt.
3. Vertalen van <p>A <b>modern</b> Britain.</p> naar het Spaans. De platte tekstversie wordt vertaald als Una Gran Bretaña moderna.  en het woord met de annotatie modern wordt vertaald als Moderno. We hebben een match nodig voor moderna en Moderno. We krijgen <p>Una Gran Bretaña <b>moderna</b>.</p>. Dit is een geval van woordverbuiging. Een letter aan het einde van het woord verandert.
4. Laten we nu een voorbeeld zien waar de subsequentie meer dan één woord is en een geval met geneste subsequenties. Een Engelse zin <p>The <b>big <i>red</i></b> dog</p> vertalen naar het Spaans. Hier is de subsequence Big red in het vet en daarbinnen is de red cursief. In dit geval moeten we de volledige tekst vertalen, subsequentie big red en red. We hebben El perro rojo grande als volledige vertaling, Rojo grande en Rojo als vertalingen van subsequenties. Rojo grande moet eerst worden gezocht en de tag voor vet (bold) moet worden aangebracht. Zoek dan naar Rojo en pas de tag voor cursief toe. Dan krijgen we <p>El perro <b><i>rojo</i> grande</b></p>.
5. Hoe werkt het met zwaar gebogen talen zoals Malayalam? Stel dat we <p>I am from <a href="x">Kerala<a></p> in het Malayalam vertalen. De vertaling van de platte tekst is ഞാന്‍ കേരളത്തില്‍ നിന്നാണു്. En de subsequentie Kerala wordt vertaald naar കേരളം. We moeten dus കേരളം en കേരളത്തില്‍ matchen. Ze verschillen door een bewerkingsafstand van 7 en er wijzigingen zijn aan het einde van het woord. Dit toont aan dat we een taalspecifieke aanpassing (maatwerk) nodig hebben om een redelijke uitkomst te kunnen bereiken.

Het algoritme om een benaderende string match te maken kan een Levenshteinafstand zijn, maar wat zou de acceptabele bewerkingsafstand zijn? Dat moet per taalmodule configureerbaar zijn. En het volgende voorbeeld illustreert dat gewoon een op bewerkingsafstand gebaseerde matching niet werkt.

Vertalen van <p>Los Budistas no <b>comer</b> carne</p> naar het Engels. Een platte tekstvertaling is The Buddhists not eating meat. Comer vertaalt zich als eat. Met een bewerkingsafstand benadering, zal eat meer overeenkomen met meat dan eating. Om dit soort gevallen aan te pakken, mengen we een tweede criterium dat de woorden met dezelfde letter moeten beginnen. Dit toont aan dat het algoritme taalspecifieke modules moet hebben.

Toch zijn er gevallen die niet kunnen worden opgelost door het algoritme dat we hierboven hebben genoemd. Bekijk het volgende voorbeeld

Vertalen van <p>Bees <b>cannot</b> swim</p>. De vertaling van de platte tekst naar het Spaans is Las Abejas no pueden nadar en de zin kan niet worden vertaald als Puede no. Hier moeten Puede no en no pueden overeenkomen, wat natuurlijk niet overeenkomt met de aanpak die we tot nu toe hebben uitgelegd.

Om dit geval aan te pakken, beschouwen we de subsequence niet als een tekenreeks, maar als een n-gram waarbij n het aantal woorden in de subsequence is. De fuzzy matching moet per woord in het n-gram zijn en niet voor de hele string. Om Puede fuzzy te matchen met no en pueden, en om no fuzzy te matchen met no en pueden links naar rechts, totdat een match wordt gevonden. Dit zal zorgen voor veranderingen in de woordvolgorde en ook voor verbuigingen.

Als we de 4 soorten fouten opnieuw herzien die er gebeuren bij de annotatieoverdracht, met het algoritme dat tot nu toe is uitgelegd, zien we dat we in het ergste geval de annotaties zullen missen. Er is geen geval van een beschadigde opmaak.

Als ContentTranslation meer taalondersteuning toevoegt, zal een taalspecifieke aanpassing van bovenstaande aanpak vereist worden.