Cannot export target file from Excel

Not sure why this is happening in the first place. It seems somehow SDL Trados Studio remembers the original path of the file at the translator's end. I got a translated SDLXLIFF file from a translator. I made some changes to translation. Now, I am trying to save the file, but I initially got this message:

 

"file xxx doesn't exist" and it gives me the path from translator's machine which is "C:\ZZ\WORK\Work from home\2018\December\30-12".

So, I tried to go along with Trados and I created the same exact path on my machine. Now, when I try to export target or save it as target, I get this error message:

 

"Failed to save target content: The paragraph unit supplied should always have Contexts properties defined!"

Not sure what does this mean? Any idea? 

How I can resolve this issue? Also, is there any logical explanation of such issue in the first place?

I am using SDL Trados Studio 2019 by the way.

Thanks,

Mohamed

Parents
  • Mohamed Zeid said:
    Also, is there any logical explanation of such issue in the first place?

    +1
    I would like to know the root cause of this as well. I've seen this problem many many times, but was never able to get to the root cause of it (mainly due to lack of knowledge on the translator's side - they were never able to precisely describe what exactly they did on their side... usually they "did nothing", of course...).
    And all the posts here in forum were always focused on getting the result, never on understanding (and preventing) the cause :(

    To resolve your issue, you can e.g. create a TM from the translated file, the creating new project using the untranslated source file and pre-translate it from the TM you created. Eventually, if you have Professional license, you can use PerfectMatch instead of Pre-translation.

  • Evzen Polenka said:
    I would like to know the root cause of this as well. I've seen this problem many many times, but was never able to get to the root cause of it (mainly due to lack of knowledge on the translator's side - they were never able to precisely describe what exactly they did on their side... usually they "did nothing", of course...).

    I wonder if it's related to the original source being embedded in the sdlxliff or not?  Obviously you can't save the target if it's not embedded but perhaps the problem itself of the path relates to thi somehow.  It would be good to have the exact steps that the file went through since it's initial production so we could replicate it.

  • Paul said:
    I wonder if it's related to the original source being embedded in the sdlxliff or not?

    In my case the source was ALWAYS embedded into the SDLXLIFF. Though, sometimes I got back file(s) with this temporary file path inside the SDLXLIFF instead of the embedded source.
    And even, for example, one or two out of ten files were "corrupted" this way and the rest was okay... all files returned from a single translator.

    Paul said:
    Obviously you can't save the target if it's not embedded but perhaps the problem itself of the path relates to thi somehow.  It would be good to have the exact steps that the file went through since it's initial production so we could replicate it.

    Yeah, but since the only information I could ever get from translators was that they "did nothing special" (of course, user never does anything... everything always happens just by itself... :-\ ), this is a no-go.
    I would rather expect some clear explanation from the SDL side, since only SDL knows exactly what is Studio doing internally (I mean, when exactly can the embedded information get lost and be replaced with a path to temporary file, for example).

  • Fair enough Evzen... I’ll see what I can get and share that with you. Happens quite often so got to be worth some time.
  • Thanks for your follow-up on this and thanks for taking the time to look into this. I also believe this issue shouldn't have happened in the first place. Here is what happened at my end:

    1) The original file was xlsx file.
    2) It was translated by a translator using SDl Trados Studio 2015
    3) Translator sent a single sdlxliff file, so no return package.
    4) I opened the file in SDL Trados Studio 2019, made some changes to translation.
    5) Tried to save the file using "Save Target as...", but it complained about the path of the original file at the translator's end.
    6) I created the same path on my machine trying to trick SDL Trados Studio, but I got a totally different error now.
    "Failed to save target content: The paragraph unit supplied should always have Contexts properties defined!"
    7) What I did eventually is that I opened the file on my machine, and translated it again. I also found out that the segmentation was different this time. Some of the bigger paragraphs were segmented in sub-segments, so Perfect Match or CM match was not auto-populated from the TM. Not sure if the translator used a different segmentation, but I really doubt it.

    Here is also the stack trace, it could help.

    I hope SDL can do something about this issue because if this happens with multiple files, it would be a huge problem.

    "<SDLErrorDetails time="12/31/2018 7:41:34 PM">
    <ErrorMessage>Failed to save target content: The paragraph unit supplied should always have Contexts properties defined!</ErrorMessage>
    <Exception>
    <Type>System.InvalidOperationException, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b7???????????</Type>
    <HelpLink />
    <Source>Sdl.FileTypeSupport.Filters.BilingualExcel</Source>
    <HResult>-2146233079</HResult>
    <StackTrace><![CDATA[ at Sdl.FileTypeSupport.Filters.BilingualExcel.Infrastructure.Extensions.ParagraphUnitDefaultContextExtensions.DefaultContext(IParagraphUnit paragraphUnit)
    at Sdl.FileTypeSupport.Filters.BilingualExcel.Writer.ExcelWriter.Process(IParagraphUnit paragraphUnit)
    at Sdl.FileTypeSupport.Filters.BilingualExcel.Writer.BilingualExcelWriter.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
    at Sdl.FileTypeSupport.Framework.BilingualApi.AbstractBilingualContentProcessor.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
    at Sdl.FileTypeSupport.Filters.Processors.EmbeddedContent.RegexEmbeddedBilingualGenerator.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
    at Sdl.FileTypeSupport.Framework.BilingualApi.AbstractBilingualContentProcessor.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
    at Sdl.FileTypeSupport.Filters.Processors.EmbeddedContent.AutoCloneEmbeddedContentGenerator.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
    at Sdl.FileTypeSupport.Framework.Bilingual.WhitespaceBetweenSegmentsBilingualProcessor.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
    at Sdl.FileTypeSupport.Framework.BilingualApi.AbstractBilingualContentProcessor.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
    at Sdl.FileTypeSupport.Framework.Integration.GenerationBilingualContentLocator.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
    at Sdl.FileTypeSupport.Framework.Integration.AbstractBilingualProcessorContainer.ProcessParagraphUnit(IParagraphUnit paragraphUnit)
    at Sdl.FileTypeSupport.Framework.Integration.FileGenerator.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.Bilingual.Tmfc.TmfcReaderImpl.vv_Visit(TmfcReaderImpl* , FrameworkParagraphContainerField* field)
    at FrameworkParagraphContainerField.vv_AcceptFrameworkVisitor(FrameworkParagraphContainerField* , FrameworkFieldVisitor* visitor)
    at Sdl.FileTypeSupport.Bilingual.Tmfc.TmfcReaderImpl.vv_VisitStartEndField(TmfcReaderImpl* , StartEndField* startEnd)
    at Sdl.FileTypeSupport.Bilingual.Tmfc.TmfcReaderImpl.b_VisitNext(TmfcReaderImpl* )
    at Sdl.FileTypeSupport.Bilingual.Tmfc.TmfcReader.ParseNext()
    at Sdl.FileTypeSupport.Framework.Integration.FileExtractor.ParseNext()
    at Sdl.FileTypeSupport.Framework.Integration.MultiFileConverter.ParseNext()
    at Sdl.FileTypeSupport.Framework.Integration.MultiFileConverter.Parse()
    at Sdl.TranslationStudio.Editor.TranslationEditor.TranslatableDocument.SaveMonolingualAsJobRequest.Execute(IJobExecutionContext context)
    at Sdl.Desktop.Platform.Implementation.Services.Job.<_worker_DoWork>b__47_0()
    at Sdl.Desktop.Logger.Log.Resources(Object message, Action action)
    at Sdl.Desktop.Platform.Implementation.Services.Job._worker_DoWork(Object sender, DoWorkEventArgs e)
    at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
    at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)]]></StackTrace>
    </Exception>
    <Environment>
    <ProductName>SDL Trados Studio</ProductName>
    <ProductVersion>15.0.0.0</ProductVersion>
    <EntryAssemblyFileVersion>15.1.0.44109</EntryAssemblyFileVersion>
    <OperatingSystem>Microsoft Windows 10 Pro</OperatingSystem>
    <ServicePack>NULL</ServicePack>
    <OperatingSystemLanguage>1033</OperatingSystemLanguage>
    <CodePage>1256</CodePage>
    <LoggedOnUser>DESKTOP-E59BTC6\mzeid</LoggedOnUser>
    <DotNetFrameWork>4.0.30319.42000</DotNetFrameWork>
    <ComputerName>DESKTOP-E</ComputerName>
    <ConnectedToNetwork>True</ConnectedToNetwork>
    <PhysicalMemory>50288236 MB</PhysicalMemory>
    </Environment>
    </SDLErrorDetails>"
  • Mohamed Zeid said:
    2) It was translated by a translator using SDl Trados Studio 2015

    The point is to know every little details of this step - every little click and operation the translator did here.

    Mohamed Zeid said:
    6) I created the same path on my machine trying to trick SDL Trados Studio

    When you say "path", do you mean only the path (i.e. folder), or did you also put any file in there (with exactly the same filename which Studio complains that it's missing)?
    It's necessary to put the original untranslated source file there, but with exactly the same filename which Studio wants to be there.

    Mohamed Zeid said:
    I also found out that the segmentation was different this time. Some of the bigger paragraphs were segmented in sub-segments, so Perfect Match or CM match was not auto-populated from the TM. Not sure if the translator used a different segmentation, but I really doubt it.

    And I truly believe the opposite - that the translator DID use god-knows-which weird process (i.e. also segmentation)...
    That would not be suprising when the resulting SDLXLIFF file was so "corrupted"...

    Mohamed Zeid said:
    Here is also the stack trace, it could help.

    The error message is weird. It would suggest that you have put some incorrect file in the created path.

  • I'm wondering if this could be the scenario:
    - translator opens the SDLXLIFF in editor
    - this makes Studio to extract the embedded source file to temporary external file and replace the embedded content with reference to external file
    - translator does not properly save the file (or close the editor) and copies the "draft" SDLXLIFF from the project structure and sends it out
    This is IMO a theoretical way to get the SDLXLIFF with reference to external temp file instead of file properly embedded inside the SDLXLIFF. Still, it depends if my assumption about Studio creating the temp file and referring to the temp file (the second step) is correct - this should be confirmed/denied by SDL staff.
Reply
  • I'm wondering if this could be the scenario:
    - translator opens the SDLXLIFF in editor
    - this makes Studio to extract the embedded source file to temporary external file and replace the embedded content with reference to external file
    - translator does not properly save the file (or close the editor) and copies the "draft" SDLXLIFF from the project structure and sends it out
    This is IMO a theoretical way to get the SDLXLIFF with reference to external temp file instead of file properly embedded inside the SDLXLIFF. Still, it depends if my assumption about Studio creating the temp file and referring to the temp file (the second step) is correct - this should be confirmed/denied by SDL staff.
Children
No Data