We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

No support in turkish locale

Hi Aspose.Word support team,

There is wrong results returned from the following method : builder.MoveToMergeField

When using the Turkish culture under ControlPanel->RagionalSettings (and performing restart as requested…):

You can run the attached solution that demonstrates the problem above and saves the result document with different results for en-US & tr-Tr locales.

We are working with version Aspose.Word 4.0 but the same scenario is seen in the new version 6.5 that I downloaded in order to test this issue.

We must resolve this issue ASAP since it prevent from our customers to use our reporting tool in the product.

There are several articles regarding handling strings in Turkish that I found them very useful:

Hi

Thanks for your request. I managed to reproduce the problem on my side. You will be notified as soon as it is resolved. I reproduced the problem using this code:

CultureInfo currentCulture = Thread.CurrentThread.CurrentCulture;
Thread.CurrentThread.CurrentCulture = new CultureInfo("tr-Tr");
Document doc = new Document(@"Test001\ReportTemplate.doc");
DocumentBuilder builder = new DocumentBuilder(doc);
// The mergefield is located in the third paragraph
builder.MoveToMergeField("as:issuetyperepeaterstart");
Assert.AreEqual(builder.CurrentSection.Body.FirstParagraph, builder.CurrentParagraph);
Thread.CurrentThread.CurrentCulture = currentCulture;

The same code you can use as a workaround of this issue.

CultureInfo currentCulture = Thread.CurrentThread.CurrentCulture;
Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");
// Do Aspose.Words stuff.
Thread.CurrentThread.CurrentCulture = currentCulture;

Best regards.

Thank you for the quıck response to the above problem.

I tried the suggested workaround and it works !

Are you going to update it on the Aspose 4.2.0.0 version ?

(this is the version we are using now since in 6.5 there are alot of changes we should do in our code).

Thanks again,

Dan Oren
AppScan Development team
IBM R&D Software labs, Israel
Office: +972-9-9629838
Cell: +972-52-3416300
DanOren@il.ibm.com

Hi

Thanks for your inquiry. Fixes and upgrades are always included into the next versions. So this issue will be resolved in the one of the upcoming versions. We do not fix anything on the old visions. So you will need to upgrade.

Best regards.

Hi,

Thank you for your request. I have read about the Turkish-I problem and it is quite interesting; frankly I wasn’t aware of it before. But I still don’t think we should use invariant culture for string comparison as suggested in the article, because we use current thread culture for all culture-specific operations throughout the code and that is a priciple of consistency. In your document, you use English names for merge fields, so I think the best way to make the code work as expected would be switching to the en-US culture while working with the document:

CultureInfo currentCulture = Thread.CurrentThread.CurrentCulture;
Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");
builder.MoveToMergeField("as:issuetyperepeaterstart");
Thread.CurrentThread.CurrentCulture = currentCulture;

The issues you have found earlier (filed as 9689) have been fixed in this update.


This message was posted using Notification2Forum from Downloads module by aspose.notifier.