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

  • 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.
  • Hi ,

    I have run some tests in trying to reproduce the issue that you have mentioned here.  To avoid any misinterpretation, can you please confirm the steps that I have mentioned underneath.

    Steps
    1. Create a new project in 2019 SR1
    2. Add a single xlsx file.
    Q 1: Is the *.xlsx file embedded in the SDLXLIFF file?
    3. Complete the project creation.
    4. Created a Studio Package and provided it to the linguist.
    Q 2: Did you provide the linguist with SDL Studio Package, target SDLXLIFF file and or the original source file (*.xlsx), or simply the entire project?
    5. Your understanding is that the Translator opened the studio package, translated the file and provided you with the translated file.
    Q 3: Is there a reason why the linguist did not provide a return package?
    Q 4: Any additional pre-processing done by the linguist?

    Tip: you can configure whether the native file is embedded in the SDLXLIFF file by updating the setting mentioned here


    Given the information you provided, I have deducted that your case is best aligned with the following scenario; if different, please advise.

    Scenario

    PM:
    •    Created a project in Studio 2019 SR1 with a single *.xlsx file
    •    *.xlsx embedded in the SDLXLIFF file
    •    Created a SDL Studio Package
    Linguist:
    •    Opened the package and translated the file
    •    The linguist did not create a return package; instead sent the translated SDLXLIFF file
    PM:
    •    Copied the translated SDLXLIFF file back into target folder of your project, overwriting the existing file.

    Observations
    In this scenario, the only case where I can see it being reproducible is when the translated SDLXLIFF file that you receive from the translator is recreated from the native file.  The original path of the reference file is defined when the file is created and relevant when not working with an embedded native file. 

    From the tests that I carried out, the original path was not updated when simply providing translations in the SDLXLIFF file. However, I was successful in updating this original path information, when creating a new project from the native file, as follows:
    •    Open the studio package
    •    Open the file in the editor and select the option File>Save Target As
    •    Create a new project from the native file.

    Note: In this user-case, it can also be seen that additional complications may occur; including variant segmentation & whether or not the native file is embedded with the creation of the new project, which might lend itself to the issues noted by .

    Tip: You can verify if the base64 encoded string of the embedded file is validate from here: https://www.base64decode.org/. Simply create a separate file with only the base64 encoded string and upload it, under the section: ‘Decode file from Base64 format’.

  • Hi

    1) It would be difficult to know every single click the translator did. I checked with the translator and all what she did was opening the file in SDL Trados Studio and translate it. She didn't even create a project.

    2) What I mean by 'path' is this: When I finished reviewing the file, I tried to save the target file, but for some reason, SDL Trados Studion complained about a path that was actually the path from translator's machine. So, I tried to mimic the same exact path on my C Drive trying to trick Trados Studion that the file is basically opened on the same machine, but this didn't resolve the issue. I hope this answers your question.

    3) That was the error message. It's weird, but what is weirder is actually this Trados Studio error, especially the one regarding the translator's path that still remembers it for some reason.
  • Hi ,

    I checked with the translator. She simply opened the XLSX file in Trados Studio and she didn't create a project for it. I didn't create a project at my end as well because it was a small file.

    I hope this helps answer some of your questions.

    Thanks,
    Mohamed
  • Hi ,

    Thank you for following up with this. I understand, so the steps to reproduce would better resemble the following:

    Scenario

    1. Project Manager:
      • Provide Translator with the source file (*.xlsx)
    2. Translator:
      • Create new project with the *.xlsx source file
      • Provide translations and return translated SDLXLIFF file to PM
    3. Project Manager
      • Open the SDLXLIFF file by creating a new project (or single document project)
      • Create translated native file -> Save Target As

     

    Original file (Embedded/Not Embedded)

    • Not Embedded: Studio will prompt the user with a message box asking them to locate the original file.  This is because the path  referencing the location of the native file is located on the translators computer (because the SDLXLIFF file/project was created on that computer).
    • Embedded: Studio will not prompt the user for the original file because it can recreate the original file from the base64 encoded string of the embedded file.

    Notes:
    In this scenario, you might still encounter problems in cases where the file type information used on the translators computer is different to what is present on the PM's computer. To avoid any unforseen issues as such, try to adopt the more regulated procedure of providing a Studio Package and then importing the Return Package.

  • Thanks Patrick Andrew Hartnett (PatrickHartnett)  for your kind follow-up on this. Your description is right, only one minor change.

    Under Project Manager, I would phrase it as follows:

    • PM opened the translated SDLXLIFF file, i.e. no new project was created. 

    By the way, the Excel file was so simple, 2 columns with a source column and an empty target column. Can you please explain more on how 'embedded vs. not embedded' may play a role in this problem? and how to avoid this in the future?

    Thanks again for your support!

    Mohamed

  • Hi ,

     

    Can you please explain more on how 'embedded vs. not embedded' may play a role in this problem?

    • You can configure whether the native file is embedded in the SDLXLIFF file by updating the setting mentioned here, from the studio options. 
    • In your case, the translator created the SDLXLIFF from the native file that you provided them.  So, the path to xlsx file saved in the SDLXLIFF is referencing a physcial path on their computer.  If the xslx file is not embedded with the SDLXLIFF (given the option here), then Studio will prompt you to locate that file when you attempt to load the translated SDLXLIFF on your computer.  To resolve, simply provide the correct path of where you have that same file (that you provided to the translator), located on your computer.
    • However, there are some gotcha's, especially if the file type or configuration used on the translators computer is different to what you have on your environment that influences structure or segmentation, which can result in Studio not being able to regenerate the target file.

     

    and how to avoid this in the future?

    • try to adopt the more regulated procedure of providing a Studio Package and then importing the Return Package.
    • If that is not possible, then mabye provide the prepared SDLXLIFF file to the translator, so that you are not at the mercy of how the SDLXLIFF file is prepared from their environment.
  • Thanks for taking the time to explain and thanks for your support. I appreciate it.