Hi - I'm not quite clear about exactly what the issue is here, since the target looks OK to me (other than I would put مم rather than ملم but that's just detail!)  I can see that you're getting an error message, and as Paul says, it would help to see what the error is.  However, if what you want is to see Hindi rather than Arabic/Western numbers - i.e.  rather than 1 2 3 4 (Sorry - had to screen shot the Hindi numbers, as I can't get them to type in this browser window ...) then there is another approach.  It depends, of course, on what your source/target file type is, but on the assumption it's Word, as an example, save the target, then try going (in Word) to File/Options/Advanced and look for the section labelled "Show Document Content".

There, you will see a field marked Numeral:

If you change the setting to Hindi (I'm guessing it's Arabic at the moment), then you will find that although the numerals appear in Arabic/Western form in Studio, when you open the target file in Word, it will display them in Hindi in Word.  There are similar settings for other MS applications.

Apologies if that's not what your issue is - I created a sample file with a few of the lines you showed above, and the numbers were automatically transferred without a problem, so just thought I'd see if this was helpful.

Hello Robert,

Thank you for your reply. 

My question is related to the autosuggestion feature. 

Sure, we use Microsoft Word to convert numbers to Hindi after exporting the files from Trados. The issue is when we see many errors in QA report related to numbers, which makes us review each number again, so it takes much time when there is a file with many numbers. I think Trados should also recognize Arabic/Western numbers in the QA reports.

Best regards,

Hello Mohamed,

As pointed out before, mentioning the error you're getting would help. You seem to refer to two different issues:

1.  The issue in your original post refers to QA errors.
   I am guessing that the error message is "missing number in target segment". If that is the case, it is probably because there is no space between the numbers and their units in the target. This causes an element such as ‏43ملم‏ to be parsed as an alphanumeric element rather than a number in the target. Try using a space between the numbers and their units. That will probably resolve this problem. You will then have to ignore the warning "extra space in target segment".
   
   Also, bear in mind that it in Arabic, it is not standard to concatenate units and numbers without a space between them. So, this is a needed correction anyway.
   
   
2. The issue in your reply to Paul looks like a problem with auto-propagation and/or auto-substitution. This one is interesting because the match result appears as 94%, which means that the number "15" was not recognized as a number. I wonder if there was a hard space in "15 cm" in the source, and if that made a difference in recognition.  This is an interesting problem in itself and may need to be posted separately.

Hello Mohamed,

As pointed out before, mentioning the error you're getting would help. You seem to refer to two different issues:

1.  The issue in your original post refers to QA errors.
   I am guessing that the error message is "missing number in target segment". If that is the case, it is probably because there is no space between the numbers and their units in the target. This causes an element such as ‏43ملم‏ to be parsed as an alphanumeric element rather than a number in the target. Try using a space between the numbers and their units. That will probably resolve this problem. You will then have to ignore the warning "extra space in target segment".
   
   Also, bear in mind that it in Arabic, it is not standard to concatenate units and numbers without a space between them. So, this is a needed correction anyway.
   
   
2. The issue in your reply to Paul looks like a problem with auto-propagation and/or auto-substitution. This one is interesting because the match result appears as 94%, which means that the number "15" was not recognized as a number. I wonder if there was a hard space in "15 cm" in the source, and if that made a difference in recognition.  This is an interesting problem in itself and may need to be posted separately.