Hi Laurent Pierret,

Queue method does not cover create process.

You can use the following code to upload an xliff to an existing server tm:

var uri = new Uri(@"uri");

var translationProviderServer = new TranslationProviderServer(uri, false, "user name", "password");

//Import to existing tm
var guid = new Guid("Existing TM Guid");
var tm = translationProviderServer.GetTranslationMemory(guid, TranslationMemoryProperties.None);
var langDirection = tm.LanguageDirections;

var import = new ScheduledServerTranslationMemoryImport(langDirection[0]);
import.Source = new FileInfo(@"path to xliff");
import.Queue();

Hi Andrea,

I am following your code step by step, but when the code reaches import.Queue(), the method never returns. On the GroupShare server I can see that the scheduled import operation has finished successfully, but in my code I can never get past import.Queue(). Is there anything I am missing?

Using Studio 2021 ver 16.0.1.2917. Is this a bug that may be fixed in CU4 ?

Thanks,

Attila  

Hi Attila,

After the import.Queue() method, you need to evaluate importer status and refresh the importer. importer.refresh(). Please refer to below trados-studio-api sample. 

https://github.com/sdl/trados-studio-api-samples/blob/master/LanguagePlatform/Sdl.SDK.LanguagePlatform.Samples.TmAutomation/ServerImporter.cs

Another alternative for importing into server based TM is using GroupShareKit. TranslationMemoriesClient has ImportTm method. 

github.com/.../TranslationMemoriesClient.cs

Regards,

Özkan

Hi,

I am coming across the same issue both when using the scheduled import and the normal import against server translation memories. The import file is uploaded and processed but the code does not continue running to the next line. It seems as if some event was being triggered which should be processed but there is nothing in the documentation.

I am using exactly the class described here suggested by Özkan:

https://github.com/sdl/trados-studio-api-samples/blob/master/LanguagePlatform/Sdl.SDK.LanguagePlatform.Samples.TmAutomation/ServerImporter.cs

which is basically the code shown by Andrea-Melinda Ghisa 

It includes the code to evaluate the import.queue() but the problem is that the code never returns to that line.

Has anybody found a workaround?

Daniel

Hi,

I am coming across the same issue both when using the scheduled import and the normal import against server translation memories. The import file is uploaded and processed but the code does not continue running to the next line. It seems as if some event was being triggered which should be processed but there is nothing in the documentation.

I am using exactly the class described here suggested by Özkan:

https://github.com/sdl/trados-studio-api-samples/blob/master/LanguagePlatform/Sdl.SDK.LanguagePlatform.Samples.TmAutomation/ServerImporter.cs

which is basically the code shown by Andrea-Melinda Ghisa 

It includes the code to evaluate the import.queue() but the problem is that the code never returns to that line.

Has anybody found a workaround?

Daniel

I reply my own question to report that I found a solution or at least a workaround.

It seems that the methods import.Queue(); and import.refresh(); are run asynchronously in the background.

The following fix worked for me.

Instead of calling the methods directly, I created a task to run them:

Using the example code from here:
 github.com/.../ServerImporter.cs

I changed this code:
#region "upload"
importer.Queue();
#endregion

To this:

#region "upload"
Task LaunchImport = new Task(() => importer.Queue());
LaunchImport.Start();
#endregion

Then, further down in the sample code, I had to change the code to refresh the status:

I changed this code:

case ScheduledOperationStatus.Recovery:
continueWaiting = true;
importer.Refresh();
break;

To this:

case ScheduledOperationStatus.Recovery:
continueWaiting = true;
Task LaunchRefresh = new Task(() => importer.Refresh());
LaunchRefresh.Start();
break;

With these two changes, the code keeps polling the status of the task until it is flagged as completed and then it finishes correctly.

There are probably easier ways to handle this but this worked for me.

I hope this is still useful somehow for Laurent Pierret  and Attila Grozli-Nagy  after so many years.

Surely my workaround can be improved a lot but it would be great if the sample code could somehow reflect this possibility.

Daniel

Hi Daniel,

Happy to read that you found a workaround.

To be honest, I can't remember how I solved the problem back then and it is not long current for us since we moved all our translation memories to WorldServer for approx. 3 years.

I have a vague recollection that I finally did not need it and could make it work without. But as I said, it has been a long time.

Best wishes to Frankfurt from a sunny and snowy Munich.

Regards,

Laurent