Mark Lewis

It is unhelpful... but if you share the stack trace and not just the headline which is very generic, then there might be something in there to help find the problem:

Alternatively if you can share one of the files where this is reproducible then that might also help?

Thanks Paul, thanks for coming back so speedily

I solved the preparation problem, some files were FR > NL
All the FR > EN files now 'prepare' but cannot be opened for translation, same message.

My project is FR to EN(GB)

Here is the stack trace for opening.

If it helps, WPML exports XLIFF v1.2

<SDLErrorDetails time="26/08/2020 10:27:26">
<ErrorMessage>The detected target language does not match that expected by the project.</ErrorMessage>
<Exception>
<Type>Sdl.TranslationStudio.Api.TranslationStudioException, Sdl.TranslationStudio.Api, Version=15.0.0.0, Culture=neutral, PublicKeyToken=c28cdb26c445c888</Type>
<HelpLink />
<Source>Sdl.TranslationStudio.Editor</Source>
<HResult>-2146233088</HResult>
<StackTrace><![CDATA[ at Sdl.TranslationStudio.Editor.TranslationEditor.TranslatableDocument.ResolveLanguages(IMultiFileConverter converter)
at Sdl.TranslationStudio.Editor.TranslationEditor.TranslatableDocument.Load(IJobExecutionContext context)
at Sdl.Desktop.Platform.Services.JobRequest.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.2.7.2849</EntryAssemblyFileVersion>
<OperatingSystem>Microsoft Windows 10 Pro</OperatingSystem>
<ServicePack>NULL</ServicePack>
<OperatingSystemLanguage>1033</OperatingSystemLanguage>
<CodePage>1252</CodePage>
<LoggedOnUser>SCAN\markl</LoggedOnUser>
<DotNetFrameWork>4.0.30319.42000</DotNetFrameWork>
<ComputerName>SCAN</ComputerName>
<ConnectedToNetwork>True</ConnectedToNetwork>
<PhysicalMemory>16673756 MB</PhysicalMemory>
</Environment>
</SDLErrorDetails>

OK so problem solved.

I recreated a project FR to EN-US and it all works.

This despite WPML considering the EN to be EN-GB.

Thanks for the karma, clearly something helped

Mark Lewis

Can you share a file with me to test with?  You can email to pfilkin@sdl.com if this is ok.

Have done, thanks

Mark Lewis

Ah... ok.  I think this is a known issue.  If you use the single document translation for a partially defined language code, like EN, then Studio will handle it by assuming it's en-US as you found out.  But if you createa proper project and define the language as en-GB then Studio doesn't like it because it wants to use en-US.

I can't find the bug in our database at the moment but I'm pretty sure this is a known issue

The workarounds for this are these:

1. do what you have done and create the project as en-US, OR
2. change the language code from just EN to en-GB and then Studio will handle it correctly

In general we prefer fully qualified language codes, but we should handle this better.

Mark Lewis

Ah... ok.  I think this is a known issue.  If you use the single document translation for a partially defined language code, like EN, then Studio will handle it by assuming it's en-US as you found out.  But if you createa proper project and define the language as en-GB then Studio doesn't like it because it wants to use en-US.

I can't find the bug in our database at the moment but I'm pretty sure this is a known issue

The workarounds for this are these:

1. do what you have done and create the project as en-US, OR
2. change the language code from just EN to en-GB and then Studio will handle it correctly

In general we prefer fully qualified language codes, but we should handle this better.

Well, there is no such thing as "fully qualified language code" since RFC 5646 says that everything except the primary language subtag (i.e. the first group of characters) is fully optional.
And on the other hand, a "full" language tag would contain many more subtags than only the first and second, which you probably had in mind ;-)

See https://tools.ietf.org/html/rfc5646#section-2.1

 langtag       = language
                 ["-" script]
                 ["-" region]
                 *("-" variant)
                 *("-" extension)
                 ["-" privateuse]

Thanks Evzen Polenka

:-)