Content translation/Developers/Markup/ar

في يتولى المترجمون ترجمة محتوى إتش تي إم إل. يحتوي نص إتش تي إم إل على كافة الرموز البرمجية المحتملة التي قد تحتوي عليها مقالة ويكيبيديا معتادة. يعني هذا أن الترجمة الآلية تنصب على محتوى إتش تي إم إل. لكن لا تساند كافة محركات الترجمة الآلية محتوى إتش تي إم إل.

بعض محركات الترجمة الآلية، مثل Moses، تضع معلومات محاذاة الجملة الفرعية مباشرة، عارضةً ما هي الكلمات المصدر التي تماثل الكلمات الهدف.

$ 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|

لا يترجم محرك الترجمة الآلية Apertium النصوص المنسقة كما يرام. يتعامل مع الترميز مثل وسوم إتش تس إم إل كما لو كانت واحد من أشكال المسافات الفارغة. قد يؤدي هذا إلى تغييرات دلالية (لو حدث تغيير في ترتيب الكلمات)، أو أخطاء إعرابية (لو كانت حالات الربط ليست بين واحد وآخر).

$ echo 'legal persons ' | apertium en-es -f html Personas legales 

$ echo 'I am David' | apertium en-es -f html Soy  David

ينتج عن محركات الترجمة الآلية الأخرى مشاكل مشابهة. ينتج عن هذا الأمر صعوبة في تقديم الترجمات الآلية للنصوص المنسقة. تبين هذه الوثيقة كيفية التعامل مع هذه الصعوبات في امتداد ترجمة المحتوى.

كما نرى في الأمثلة السالفة، يجوز أن ينتج عن محرك ترجمة آلية الأخطاء التالية في نص إتش تي إم إل المترجم. الأخطاء مذكورة في قائمة مرتبة ترتيبًا تنازليًا من ناحية الخطورة.
 * 1) Corrupt markup - لو لم يكن محرك الترجمة الآلية على دراية ببنية إتش تي إم إل، يحتمل أن ينقل وسوم إتش تي إم إل عشوائيًا وبالتالي حدوث ترميز غير صحيح في نتائج الترجمة الآلية
 * 2) Wrongly placed annotations - المثالين المذكورين سالفًا يبينان هذا الأمر. سيكون مستوى الخطورة أعلى لو كان المحتوى يشتمل على وصلات شبكية ومستهدفات وصلات جرى تغيير مكانها أو خرجت عشوائيًا في خرج الترجمة الآلية.
 * 3) Missing annotations - يجوز أحيانًا أن تغفل محركات الترجمة الآلية بعض الوسوم أثناء عملية الترجمة.
 * 4) Split annotations - أثناء الترجمة، يجوز ترجمة كلمة واحدة إلى أكثر من كلمة. لو كانت الكلمة المصدر تحتوي على ترميز، مثل وسم . هل سينسخ محرك الترجمة الآلية وسم  ليحصر كلتا الكلمتين أم سينسخ الوسم لكل كلمة على حدة؟

يجوز أن ينتج كافة المشاكل سالفة الذكر خبرات سيئة للمترجمين.

خلاف المشاكل المحتملة المتعلقة بنقل الترميز، يوجد جانب آخر يتعلق بإرسال محتوى إتش تي إم إل إلى محركات الترجمة الآلية. مقارنة بنسخ النص الخام لفقرة واحدة، ستكون نسخة إتش تي إم إل أكبر من ناحية الحجم (البايت). القسم الأكبر من هذه الإضافات هو وسوم ونعوت يجب ألا تتأثر بعملية الترجمة. هذا الأمر يعني استخدام غير مطلوب للنطاق الترددي. لو كان محرك الترجمة الآلية محرك يحسب الاستهلاك (أي غير مجاني وهو إمكانية وصول لواجهة برمجة التطبيقات يجري قياسها وبالتالي تقييد حدها الأقصى)، فنحن هكذا لا نتعامل مع الأمر بترشيد الإنفاق.

نظرة عامة

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



ربط التعليقات التوضيحية باستخدام التقريب التتالي للترجمة
This is the algorithm currently used in ContentTranslation. This algorithm tries to overcome the limitations of the previous upper casing algorithm. 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.


 * 1) For the text to translate, find the text of inline annotations like bold, italics, links etc. We call it subsequences.
 * 2) 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.
 * 3) 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
 * 4) 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.
 * 5) 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.


 * 1) Translating the Spanish sentence   to Catalan: the plain text version is  and the subsequence with annotation is   . We give both the full text and subsequence to MT. The full text translation is   and the word    is translated as  . We do a search for   in the full text translation. The search will be successfull and the  tag will be applied, resulting  . The seach performed in this example is plain text exact search. But the following example illustrate why it cannot be an exact search.
 * 2) Translating an English sentence   to Spanish. The full text translation of this is  .   One of the subsequence   will get translated as  . The case of   differs and search should be smart enough to identify   as a match for  . 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.
 * 3) Translating   to Spanish. The plain text version get translated as    and the word with annotation   get translated as   . We need a match for   and  . We get  . This is a case of word inflection. A single letter at the end of the word changes.
 * 4) Now let us see an example where the subsequence is more than one word and the case of nested subsequences. Translating English sentence   to Spanish. Here, the subsequence   is in bold, and inside that, the   is in italics. In this case we need to translate the full text, sub sequence   and  . So we have,   as full translation,   and   as translations of sub sequences.  need to be first located and bold tag should be applied. Then search for   and apply Italic. Then we get.
 * 5) How does it work with heavily inflected languages like Malayalam? Suppose we translate   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  to English. Plain text translation is. translates as. With an edit distance approach,  will match more with   than. 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. Plain text translation to Spanish is  and the phrase cannot translates as. Here we need to match  and   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.  to be fuzzy matched with   and , and   to be fuzzy matched with   and  - 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.