• State Suggested Answer
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 391 subscribers
  • Views 304 views
  • Users 0 members are here
Options
Related

Translation Provider Exception when testing Studio 2024 (SR1)

Johan Lapasset

Context

Since few weeks we are facing an issue (translation provider exception, see details below) which prevents to perform the Finalization in our internal application using Studio 2024 (SR1) APIs.

We have already performed several tests in order to try to identify the cause but without success.

Someone would have an idea what could be the cause and how to solve it?

Here are the environment details :

 The code is executed in a separate application (CAT Client), it is not executed in a Plugin.

 Finalization, when launched in CAT Client, triggers the translation provider exception (see details below)

 Finalization, when launched directly in studio 2024, works correctly

 Groupshare version: GS:15.1.13.14280 - GS 2020 SR1 CU13

 Studio Version: Studio 2021 SR2 - 16.2.9.9198

 Studio Version: Studio 2024 SR1 (18.0.2.3255)

Here are the main tests already done:

 CAT Client 3.2.1 with Studio 2021 works without issue

 CAT Client 4.0.0 (last version of our internal application adapted to studio 2024) but using Studio 2021 works without issue

 CAT Client 4.0.0 using Studio 2024 finalization doesn’t work (triggers the translation provider exception)

Description of the issue:

In our C# application, the API method to update the main memory generate a fatal exception if some Groupshare memories are attached and enabled in the project.

The only way to avoid this exception is to disable all remote memories attached to the project before executing the update main memory batch task.

This exception occurs only when the application uses the Studio 2024 API, on a specific set of groupshare servers.

NB: groupshare server are correctly setup in Trados Studio, correctly enabled in the project, and the connection to the servers is correctly established.

C# code used to update the main memory in our application :

ProjectAutomaticTaskRunner taskRunner = new ProjectAutomaticTaskRunner(project); taskRunner.addTemplateTaskId(AutomaticTaskTemplateIds.UpdateMainTranslationMemories); taskRunner.addTemplateTaskId(AutomaticTaskTemplateIds.GenerateTargetTranslations); taskRunner.runTasks(fileIdList);

(optional) List of automatic task used by our application, possibly affected by the issue:

AutomaticTaskTemplateIds.PerfectMatch

AutomaticTaskTemplateIds.Scan

AutomaticTaskTemplateIds.ConvertToTranslatableFormat

AutomaticTaskTemplateIds.CopyToTargetLanguages

AutomaticTaskTemplateIds.AnalyzeFiles

AutomaticTaskTemplateIds.UpdateMainTranslationMemories

AutomaticTaskTemplateIds.GenerateTargetTranslations

Error returned by the exception:

ProjectAutomationException: Unexpected exception when configuring file multiFileConverter for task 'Update Main Translation Memories': Failed to create an instance of translation provider 'sdltm.gsweb-prd-09.net1.cec.eu.int/.../NormativeMem_EN-FR'

NB: in this example, gsweb-prd-09.net1.cec.eu.int is the correct URL of our groupshare server. "/Public/Resources/NormativeMem_EN-FR" is the path where is store the memory, defined in the CSPROJ this way:

<CascadeEntryItem PerformConcordanceSearch="true" Penalty="2" PerformUpdate="true" PerformNormalSearch="true"> <MainTranslationProviderItem Uri="sdltm.">gsweb-prd-09.net1.cec.eu.int/.../NormativeMem_EN-FR" Enabled="true" /> </CascadeEntryItem>

The server is correctly setup in Studio, using the Windows default user authentication (without password).

The content of this memory is correctly accessible in the translation, in Studio Editor.

Complete stacktrace


   at Sdl.ProjectApi.AutomaticTasks.UpdateTm.AbstractUpdateTmContentProcessor.ProcessBuffer()
   at Sdl.ProjectApi.AutomaticTasks.UpdateTm.AbstractUpdateTmContentProcessor.ProcessWaitingParagraphs()
   at Sdl.ProjectApi.AutomaticTasks.UpdateTm.AbstractUpdateTmContentProcessor.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
   at Sdl.FileTypeSupport.Framework.BilingualApi.AbstractBilingualContentProcessor.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
   at Sdl.FileTypeSupport.Filters.Processors.SegmentRenumberingBilingualProcessor.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
   at Sdl.FileTypeSupport.Framework.Core.Utilities.BilingualApi.BilingualContentHandlerAdapter.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
   at Sdl.FileTypeSupport.Framework.Core.Utilities.BilingualApi.BilingualContentHandlerAdapter.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
   at Sdl.FileTypeSupport.Framework.Integration.AbstractBilingualProcessorContainer.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
   at Sdl.FileTypeSupport.Framework.BilingualApi.AbstractBilingualContentProcessor.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
   at Sdl.FileTypeSupport.Framework.Integration.LocationMarkerLocator.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
   at Sdl.FileTypeSupport.Framework.Integration.AbstractBilingualProcessorContainer.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
   at Sdl.FileTypeSupport.Framework.Integration.FileExtractor.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
   at Sdl.FileTypeSupport.Framework.Core.Utilities.BilingualApi.ParagraphUnitBuffer.Release()
   at Sdl.FileTypeSupport.Bilingual.SdlXliff.XliffFileReader.OutputParagraphUnit(IParagraphUnit pu)
   at Sdl.FileTypeSupport.Bilingual.SdlXliff.XliffFileReader.ParseLocalizableParagraphUnit(transunit transunit, LockTypeFlags lockFlags)
   at Sdl.FileTypeSupport.Bilingual.SdlXliff.XliffFileReader.ParseTransUnit(transunit transunit)
   at Sdl.FileTypeSupport.Bilingual.SdlXliff.XliffFileReader.ParseGroup(group group)
   at Sdl.FileTypeSupport.Bilingual.SdlXliff.XliffFileReader.OnGroup(XmlElement group)
   at Sdl.FileTypeSupport.Bilingual.SdlXliff.SdlXliffFeeder.<ContinueScanning>b__14_11(ISdlXliffStreamContentHandler handler)
   at System.Collections.Generic.List`1.ForEach(Action`1 action)
   at Sdl.FileTypeSupport.Bilingual.SdlXliff.SdlXliffFeeder.ContinueScanning()
   at Sdl.FileTypeSupport.Bilingual.SdlXliff.XliffFileReader.ContinueParsing()
   at Sdl.FileTypeSupport.Bilingual.SdlXliff.XliffFileReader.ParseNext()
   at Sdl.FileTypeSupport.Framework.Integration.FileExtractor.ParseNext()
   at Sdl.FileTypeSupport.Framework.Integration.MultiFileConverter.ParseNext()
   at Sdl.FileTypeSupport.Framework.Integration.MultiFileConverter.Parse()
   at Sdl.ProjectApi.Implementation.TaskExecution.ContentProcessingTaskImplementation.TaskFileExecuter.Parse(String targetFilePath)'. 
Rate translation
×
Suggest better translation
×
  • 0

    Hi  , I wonder if this issue is related to a similar problem reported recently on another thread here: Issue with RunAutomaticTask after upgrading to Trados 2024 

    Patrick Andrew Hartnett | Developer Experience | Team Lead | RWS Group

  • 0 in reply to Patrick Andrew Hartnett

    Hi   unfortunately not it is not linked to this thread. Additional information, this thread is about "update main memories" when our problem is about "populate translations memories". Moreover our issue is about "translation provider" exception when in this thread iit is about "file not found" exception. Finally our problem is about "groupeshare memories" when in this thread it is about "local TM".
  • 0 in reply to Johan Lapasset

    Hi  , thank you for following up.  I see, so you're not attempting to update the GroupShare TM, only the a FileBased TM.  And, when you remove the GroupShare TM's from the project, updating the FileBased TM works as expected.

    I'll followup with the team and attempt to reproduce from your description above.

    In the meantime, can you confirm the following:
    1. Seeing as you are working outside the context of Studio via the API's, you still need to provide the credentials to connect to the TM resources independenly, where required.  Are you also providing credentials to connect to the GS TM, in the scenario where you update the Main TM?  

    2. Can you also confirm that this Uri is correct (e.g. sdltm.">gsweb...)

    Johan Lapasset said:
    <MainTranslationProviderItem Uri="sdltm.">gsweb-prd-09.net1.cec.eu.int/.../NormativeMem_EN-FR" Enabled="true" /> </CascadeEntryItem>

    Patrick Andrew Hartnett | Developer Experience | Team Lead | RWS Group

  • 0
    Thank you for bringing this to our attention. Our development team will review it in the context of our ongoing projects and priorities. Your understanding and patience as we assess this matter is appreciated. We have recorded the issue in our tracking system under the reference number SDLCOM-6707
  • 0 in reply to Patrick Andrew Hartnett

    Hi  , I didn't hear back from you regarding my questions above. It's important to get your input, additional details, so that I can help you further in understanding what the root cause is.  And then determine if this is an actual bug in the product, or something that needs to be configured in your code project.  

    I have taken some time out of my evening, this evening, to followup and try to reproduce the issue that you reported. I confirm the API seems to be working correctly after performing the following automation scenarios working with GS 2020 & Trados Studio 2024 SR1

    Automation Scenario 1 & 2:

    1. Open an existing Trados Project with one FileBased TM and one GS TM 
    2. Add credentials for GS TM
    3. Perform Analysis/Pretranslate/Update FileBased TM - Automation 1
    4. Perform Analysis/Pretranslate/Update GS TM  - Automation 2


    Automation Scenario 3 & 4:

    1. Create a new Trados Project from a project template with one FileBased TM and one GS TM 
    2. Add credentials for GS TM
    3. Add Project Native files to the project (Scan, Convert.. Copy to target languages...)
    4. Perform Analysis/Pretranslate/Update FileBased TM - Automation 3
    5. Perform Analysis/Pretranslate/Update GS TM - Automation 4

    Now, let's take a better look at what you reported:

    From your detail, the error is specifically indicating that it cannot connect to the GS server

    Johan Lapasset said:
    ProjectAutomationException: Unexpected exception when configuring file multiFileConverter for task 'Update Main Translation Memories': Failed to create an instance of translation provider

    1. In all cases, it is required to add the credentials when working with GS TM via Automation.  Remember you are outside the context of Studio app, therefore you'll need to provide these in the Project Automation context.  Can you confirm you are adding the GS credentials correctly?

    Johan Lapasset said:
    <MainTranslationProviderItem Uri="sdltm.">gsweb-prd-09.net1.cec.eu.int/.../NormativeMem_EN-FR" Enabled="true" /> </CascadeEntryItem>

    2. Can you also confirm that this Uri is correct (e.g. sdltm.">gsweb...) that you mentioned above?

    3. What Automation scenario best describes your workflow from my tests above, if any?  Please describe in steps as I have done here if different.

    Johan Lapasset said:
    The server is correctly setup in Studio, using the Windows default user authentication (without password).

    4. Did you also try with the GroupShare password?  Maybe there is something not configured correctly?

    Johan Lapasset said:
    on a specific set of groupshare servers

    5. Can you explain by what you mean by a specific set of GS servers... I'm assuming they are GS 2020, right?

    6. Can you provide me the App.config that you have attached to your Automation Project?  It might be that some or all of the binding redirects are not up todate!

    7. Lastely, I don't typically do this, but sometimes it's faster.  Give me access to your code project so that I can review it for you. If you can share it, great, if not, send it to me phartnett@rws.com with a link where I can download it.  don't include the project zipped in the e-mail.

    Patrick Andrew Hartnett | Developer Experience | Team Lead | RWS Group