Terjemahan konten/Pengembang/Markah
Dalam Terjemahan konten penerjemah menerjemahkan konten html. HTML tersebut berisi semua markah yang mungkin dimiliki artikel Wikipedia biasa. Ini berarti, terjemahan mesin pada konten HTML. Namun, tidak semua mesin terjemahan mendukung konten HTML.
Beberapa mesin MT, seperti Moses, menghasilkan secara langsung informasi tentang subkalimat yang bersesuaian, menunjukkan kata sumber mana yang bersesuaian dengan kata tujuan.
$ 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|
The Apertium MT engine does not translate formatted text faithfully. Markup such as HTML tags is treated as a form of blank space. This can lead to semantic changes (if words are reordered), or syntactic errors (if mappings are not one-to-one).
$ 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
Other MT engines exhibit similar problems. This makes it challenging to provide machine translations of formatted text. This document explains how this challenge is tackled in ContentTranslation.
As we saw in the examples above, a machine translation engine can cause the following errors in the translated HTML.
The errors are listed in descending order of severity.
- Corrupt markup - If the machine translation engine is unaware of HTML structure, they can potentially move the HTML tags randomly, causing corrupted markup in the MT result
- Wrongly placed annotations - The two examples given above illustrate this. It is more severe if content includes links and link targets were swapped or randomly given in the MT output.
- Missing annotations - Sometimes the MT engine may eat up some tags in the translation process.
- Split annotations - During translation a single word can be translated to more than one word. If the source word has a mark up, say
<a>
tag. Will the MT engine apply the<a>
tag wrapping both words or apply to each word?
All of the above issues can cause bad experience to translators.
Apart from potential issues with markup transfer, there is another aspect about sending HTML content to MT engines. Compared to plain text version of a paragraph, HTML version is bigger in terms of size(bytes). Most of these extra addition is tags and attributes which should be unaffected by the translation. This is unnecessary bandwidth usage. If the MT engine is a metered engine(non-free, API access is measured and limited), we are not being economic.
Overview
- The input HTML content is translated into a LinearDoc, with inline markup (such as bold and links) stored as attributes on a linear array of text chunks. This linearized format is convenient for important text manipulation operations, such as reordering and slicing, which are challenging to perform on an HTML string or a DOM tree.
- Plain text sentences (with all inline markup stripped away) are sent to the MT engine for translation.
- The MT engine returns a plain text translation, together with subsentence alignment information (saying which parts of the source text correspond to which parts of the translated text).
- The alignment information is used to reapply markup to the translated text.
This make sure that MT engines are translating only plain text and mark up is applied as a post-MT processing.
To transfer the markup, initially we tried an algorithm based on case change observation. To locate the translation of a word which is potentially reordered in translated text, a sentence is translated as it is and as that particular word uppercased. By comparing the output of both, the diff will tell where the word translation is appearing in translation. This approach and its limitations are listed below. Later we will see an more advanced algorithm.
Annotation mapping using translation subsequence approximation
This is the algorithm currently used in ContentTranslation. This algorithm tries to overcome the limitations of the previous upper casing algorithm.
![](http://upload.wikimedia.org/wikipedia/mediawiki/thumb/a/a6/Cx-annotation-mapping.png/667px-Cx-annotation-mapping.png)
Essentially the algorithm does a fuzzy match to find the target locations in translated text to apply annotations. Here also content given to MT engines is plain text only.
The steps are given below.
- For the text to translate, find the text of inline annotations like bold, italics, links etc. We call it subsequences.
- Pass the full text and subsequences to the plain text machine translation engine. Use some delimiter so that we can do the array mapping between source items(full text and subsequences) and translated items.
- The translated full text will have the subsequences somewhere in the text. To locate the subsequence translation in full text translation, use an approximate search algorithm
- The approximate search algorithm will return the start position of match and length of match. To that range we map the annotation from the source html.
- The approximate match involves calculating the edit distance between words in translated full text and translated subsequence. It is not strings being searched, but ngrams with n=number of words in subsequence. Each word in ngram will be matched independently.
To understand this, let us try the algorithm in some example sentences.
- Translating the Spanish sentence
<p>Es <s>además</s> de Valencia</p>
to Catalan: the plain text version isEs además de Valencia
and the subsequence with annotation isademás
. We give both the full text and subsequence to MT. The full text translation isA més de València
and the wordademás
is translated asa més
. We do a search fora més
in the full text translation. The search will be successfull and the<s>
tag will be applied, resulting<p>És <s>a més</s> de València</p>
. The seach performed in this example is plain text exact search. But the following example illustrate why it cannot be an exact search. - Translating an English sentence
<p>A <b>Japanese</b> <i>BBC</i> article</p>
to Spanish. The full text translation of this isUn artículo de BBC japonés
. One of the subsequenceJapanese
will get translated asJaponés
. The case ofJ
differs and search should be smart enough to identifyjaponés
as a match forJaponés
. The word order in source text and translation is already handled by the algorithm. The following example will illustrate that is not just case change that happens. - Translating
<p>A <b>modern</b> Britain.</p>
to Spanish. The plain text version get translated asUna Gran Bretaña moderna.
and the word with annotationmodern
get translated asModerno
. We need a match formoderna
andModerno
. We get<p>Una Gran Bretaña <b>moderna</b>.</p>
. This is a case of word inflection. A single letter at the end of the word changes. - Now let us see an example where the subsequence is more than one word and the case of nested subsequences. Translating English sentence
<p>The <b>big <i>red</i></b> dog</p>
to Spanish. Here, the subsequenceBig red
is in bold, and inside that, thered
is in italics. In this case we need to translate the full text, sub sequencebig red
andred
. So we have,El perro rojo grande
as full translation,Rojo grande
andRojo
as translations of sub sequences.Rojo grande
need to be first located and bold tag should be applied. Then search forRojo
and apply Italic. Then we get<p>El perro <b><i>rojo</i> grande</b></p>
. - How does it work with heavily inflected languages like Malayalam? Suppose we translate
<p>I am from <a href="x">Kerala<a></p>
to Malayalam. The plain text translation isഞാന് കേരളത്തില് നിന്നാണു്
. And the sub sequence Kerala get translated toകേരളം
. So we need to matchകേരളം
andകേരളത്തില്
. They differ by an edit distance of 7 and changes are at the end of the word. This shows that we will require language specific tailoring to satisfy a reasonable output.
The algorithm to do an approximate string match can be a simple levenshtein distance , but what would be the acceptable edit distance? That must be configurable per language modules. And the following example illustrate that just doing an edit distance based matching wont work.
Translating <p>Los Budistas no <b>comer</b> carne</p>
to English.
Plain text translation is The Buddhists not eating meat
. Comer
translates as eat
.
With an edit distance approach, eat
will match more with meat
than eating
.
To address this kind of cases, we mix a second criteria that the words should start with same letter.
So this also illustrate that the algorithm should have language specific modules.
Still there are cases that cannot be solved by the algorithm we mentioned above. Consider the following example
Translating <p>Bees <b>cannot</b> swim</p>
.
Plain text translation to Spanish is Las Abejas no pueden nadar
and the phrase cannot translates as Puede no
.
Here we need to match Puede no
and no pueden
which of course wont match with the approach we explained so far.
To address this case, we do not consider sub sequence as a string, but an n-gram where n is the number of words in the sequence.
The fuzzy matching should be per word in the n-gram and should not be for the entire string. i.e. Puede
to be fuzzy matched with no
and pueden
, and no
to be fuzzy matched with no
and pueden
- left to right, till a match is found.
This will take care of word order changes as welll as inflections.
Revisiting the 4 type of errors that happen in annotation transfer, with the algorithm explained so far, we see that in worst case, we will miss annotations. There is no case of corrupted markup.
As and when ContentTranslation add more language support, language specific customization of above approach will be required.