• State Suggested Answer
  • +1 person also asked this people also asked this
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 391 subscribers
  • Views 1932 views
  • Users 0 members are here
Options
Related

WorldServer Converter in Studio 2021

Caroline Walle

Hi everyone 

We have switched from Studio 2019 to Studio 2021 a while back and have since had trouble with our program that automatically converts WorldServer packages (.wszx) to regular Studio packages (.sdlppx). The package is then further processed into a Studio project (via ProjectPackageImport). We know that the converter and WorldServer support are no longer integrated in Studio itself but have been moved to a plugin, which we also have installed and everything works fine if we import the WS packages by hand.

In our code, we removed the old WS DLL file and imported the one that we think is the new one from the plugin (Sdl.TranslationStudio.Packaging.WorldServer.dll). There seems to be a method/sub integrated in the new DLL with the same name as in the old WS DLL, however, it doesn’t work. And the DLL is also not active in the imports section. When running the program, it always throws an error (NullReferenceException: object reference not set to an instance of an object) and – obviously – doesn’t convert anything. We have also tried a few other methods/subs that looked promising but nothing worked so far, it always throws the same error.

Is there a way to “call” the plugin and/or the functions within and just convert the WS package to a regular Studio package as was the case for Studio 2019? If so, how would that work? If not, is there a workaround for this, such as a way to programmatically walk through the “Open WorldServer Package” dialog?

Code snippets (Code is originally in VB)
Import (some of the imports are greyed out, not just the one with the comment)

 

Imports Sdl.Desktop.IntegrationApi
Imports Sdl.TranslationStudio.Packaging.WorldServer // this is greyed out
Imports Sdl.MultiTerm.Client.Connectors
Imports Sdl.ProjectAutomation.FileBased
Imports Sdl.ProjectAutomation.Core
Imports Sdl.ProjectApi
Imports Sdl.Core.Settings
Imports Sdl.ProjectAutomation.Settings
Imports Sdl.LanguagePlatform.TranslationMemoryApi
Imports Sdl.Core.Globalization

Code where the conversion should happen

If Not IO.File.Exists(SDLPPX) Then
    Dim XX As New Sdl.TranslationStudio.Packaging.Convertors.WorldServer.WsPackageConvertor
    XX.ConvertPackage(WSXZ, SDLPPX)
    XX = Nothing
End If

 

I’m happy to provide more information if necessary.

Thank you in advance for any hints or tips regarding this topic.

Caroline
Rate translation
×
Suggest better translation
×
  • 0

    Thanks for posting into here. I had a chat with the development team this morning who took a quick look and at first glance think you may have an issue in your code and how you are loading the component.  However, it won't be a 5 minute job to investigate this so we'll have to plan it in.  I doubt this will be very soon as we have some very heavy workloads at the moment as we're preparing for a major release, but we will try to make some time at some point.

    Paul Filkin | RWS Group

    ________________________
    Design your own training!
    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

  • 0 in reply to Paul

    Hi Paul

    Thank you for the heads up and taking the time to have a look at this. I will keep trying to get this to work and if there is any progress, I will post updates as well.

    Caroline
  • 0

    We spent some more time discussing this today and I think it's only fair that you know what our position is so you can plan accordingly.

    Based on the flow you describe you are using internal Studio assemblies and relying on the code written in Studio to automate your process.  This always a risky decision because we may change our internal assemblies as we see fit to accommodate the product evolution.  They are not protected in the same way a public API is.

    The WorldServer converter was never part of the pluginconfig.xml manifest file, and so it was never part of the public API for Trados Studio either.  It's therefore most likely that we will not be doing anything for Trados Studio 2021 that could properly support your effort, but as part of our efforts to migrate the WorldServer Component to a full plugin we will be extending support for 3rd party developers to introduce their own converters.  This work will be part of the new major release due later this year.  We cannot guarantee it will be completely finished in time for the initial release because of many competing priorities, but we are working on it.

    I know this doesn't help you right now, but I hope you can understand why we can't devote anyone's time to help ensure a non-supported application is working correctly.  Longer term, still this year all being well, we will have a public API available which will help you resolve your automation tasks in a properly supported manner.

    If you think I've misunderstood what you are doing here please do let me know, otherwise I hope this clarifies the situation for you?

    Paul Filkin | RWS Group

    ________________________
    Design your own training!
    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

  • 0 in reply to Paul

    Thank you for taking the time to explain this in detail, Paul, it does clarify the situation for me.