Pages in topic:   [1 2] >
Compatibility issues between Studio 2009 and Studio 2011
Thread poster: xxxStrastran
xxxStrastran
France
Local time: 11:13
French to English
+ ...
Feb 29, 2012

Hello all

I've translated a file in Studio 2011, but my customer only has Studio 2009. They are able to open and modify the .sdlxliff file, but cannot create a Target file from it.

They had to send their updated .sdlxliff file back to me along with a TM export, so I could open it in 2009 as if beginning a new project, process all segments and create a Target file.

Is there a way around this? At the moment it seems that, because my customers have 2009, there was no point in my upgrading to 2011 as it will only create extra work for me. So I may have to go back to using 2009.

I find it hard to believe that there are compatibility issues with target files, but I am very new to 2011 and am yet to take training on it so I'm open to suggestions.

Thanks!


Direct link Reply with quote
 

SDL Community  Identity Verified
United Kingdom
Local time: 11:13
English
The way around it.. Feb 29, 2012

... is to create a package for 2009 and then the 2011 user will be able to handle it. Or as you have discovered, ask your customer to prepare the file and then you translate their sdlxliff. Clearly you won't be able to do this unless you have the Professional version.

The problem will be there because the sdlxliff will have been prepared using a different version of the filetype than they have so when 2009 tries to reassemble the target it cannot find the appropriate filetype to do the work.

Maybe another solution is for you to send them the translated sdlxliff for review. They review in Studio and send it back and then you create the final target for them. They will then have the target and can update their TMs from the sdlxliff you sent them.

Regards

Paul


Direct link Reply with quote
 
xxxStrastran
France
Local time: 11:13
French to English
+ ...
TOPIC STARTER
Thanks Feb 29, 2012

SDL Support wrote:

... is to create a package for 2009 and then the 2011 user will be able to handle it. Or as you have discovered, ask your customer to prepare the file and then you translate their sdlxliff. Clearly you won't be able to do this unless you have the Professional version.

The problem will be there because the sdlxliff will have been prepared using a different version of the filetype than they have so when 2009 tries to reassemble the target it cannot find the appropriate filetype to do the work.

Maybe another solution is for you to send them the translated sdlxliff for review. They review in Studio and send it back and then you create the final target for them. They will then have the target and can update their TMs from the sdlxliff you sent them.

Regards

Paul


Many thanks for your quick reply, Paul.

I have to say, that all seems overly complicated when I could simply stick with 2009.


Direct link Reply with quote
 

Marinus Vesseur  Identity Verified
Canada
Local time: 02:13
English to Dutch
+ ...
Well that settles it then... Feb 29, 2012

... I was just contemplating whether I should upgrade after all. Can't have any compatibility issues.

Thanks for the info.


Direct link Reply with quote
 

SDL Community  Identity Verified
United Kingdom
Local time: 11:13
English
Is it a common scenario... Feb 29, 2012

... for your customer to ask you to create the sdlxliff in the first place and then send them the sdlxliff and not the target file? Also outside of a Project Package?

They can still update their Translation Memory from the sdlxliff, so perhaps this is all they need?

If not and this is the workflow you use for the majority of your customers who are on 2009 rather than 2011 then you probably better stay put until they upgrade too.

Regards

Paul


Direct link Reply with quote
 

Alexandre Maricato
Brazil
Local time: 07:13
Member (2009)
English to Portuguese
Problem with a specific file type? Feb 29, 2012

Hi Patrick,

I was wondering if you have such problem with the sdlxliff file from a specific file type (for example, InDesign files) or if it happens with all file types: sdlxliff from Word, Excel, XML, etc files.

Could you please clarify?

Thanks,

Alex


Direct link Reply with quote
 
xxxStrastran
France
Local time: 11:13
French to English
+ ...
TOPIC STARTER
yes Feb 29, 2012

Paul: that's the way I've always worked, yes. I think you're right, I'll go back to 2009 for the time being.

Alex: I've only used 2011 for Word files so far, as this was my first project with it. I'm not sure about other files.


Direct link Reply with quote
 
FarkasAndras
Local time: 11:13
English to Hungarian
+ ...
This should work Mar 1, 2012

SDL Support wrote:

Is it a common scenario for your customer to ask you to create the sdlxliff in the first place and then send them the sdlxliff and not the target file? Also outside of a Project Package?


Of course it is, why do you even ask? That's the most logical workflow there is. They can review the sdxliff, update their TM and generate the target translation. People don't use Project Packages because... what's the point? It's much simpler and more transparent & flexible to just send the necessary files.

This incompatibility is a huge and embarrassing bug in Trados in my opinion. Developers may 'call it a feature' all they want, and cite "File types", but the fact of the matter is is that it's their job to make sure that subsequent versions of their own product are interoperable. If they keep fiddling with their filetype filters all the time, then include a reference to the filetype it was created with in the sdlxliff and send all filetypes to all Trados versions through updates. Store them all in AppData and BAM! problem solved. If an sdlxliff references a filetype that's not available on the computer, just autodownload it from SDL after prompting the user. It's not like this is a hard problem to solve...
If there's an "idea" I can vote for, let me know. I'm not sure that "make basic functionality work" is an idea per se, but what can we do.
I'm thinking about upgrading to 2011 but things like this aren't exactly encouraging me to take the plunge.

On a side note, would it be possible for us to do the programmers' job? I.e. grab the correct filetype file and put it in the right folder. Would trados use it? I guess not, but it's worth a try.

[Edited at 2012-03-01 08:13 GMT]


Direct link Reply with quote
 

SDL Community  Identity Verified
United Kingdom
Local time: 11:13
English
I don't see it this way Mar 1, 2012

FarkasAndras wrote:

Of course it is, why do you even ask? That's the most logical workflow there is. They can review the sdxliff, update their TM and generate the target translation. People don't use Project Packages because... what's the point? It's much simpler and more transparent & flexible to just send the necessary files.



I ask because in my opinion this is really silly. If I wanted the sdlxliff back then this must be because I have Studio in the first place. This being the case i would always create the sdlxliff and not ask someone else to do it because they may not do it as I would like. They also won;t be using my resources for segmentation or leverage. This is why I asked.

It is also backward compatibility we are talking about here and we have covered this with packages. The only problem we are discussing is that someone who opens an sdlxliff that was created with a filetype from a tool that has more features than the one they use may not be able to make full use of it. I really don;t see a problem with this at all. The workarounds to this very specific scenario is easy.

Could I give you an IDML or ICML if you had an old version of InDesign, or MIF files, or xliff created with custom xml that used new features... Loading all filetypes from every version we have ever released and ensuring we still support the code to use them is ridiculous.

I really can't see your point at all in this discussion. Everything you mentioned is supported in the package concept as this is what it is there for. If you are sending work out without the packages and you are not using the same versions, in particular if you ask someone with a newer version than you to create your files for you, then workarounds will be required.

Regards

Paul


Direct link Reply with quote
 
FarkasAndras
Local time: 11:13
English to Hungarian
+ ...
Yes it is Mar 1, 2012

SDL Support wrote:
I ask because in my opinion this is really silly. If I wanted the sdlxliff back then this must be because I have Studio in the first place. This being the case i would always create the sdlxliff and not ask someone else to do it because they may not do it as I would like. They also won;t be using my resources for segmentation or leverage. This is why I asked.

In the overwhelming majority of cases, people don't care how their sdlxliff is created. There is no "way that they would like" their sdlxliff files. They need to 1) be able to enter the translations to a TM and 2) generate the target file. As long as those conditions are met, most people couldn't care less about what shape, size, colour or smell the sdlxliff is. Busy PMs don't necessarily want to spend their time preparing sdlxliffs from the input files, either.
Yes the segmentation might be different depending on who does it. Often there won't be any difference, or not a significant one. And guess what: as a translator, I don't want to get presegmented files from the client at all. I would like to segment my own files. I will be the one who has to fix incorrectly segmented sentences manually, after all. I have edited the abbreviation list to my liking, and I don't want to have to fix segmentation errors that occur because other people left the default list as it is. I know SDL thinks that uniformly presegmented files are the best thing since sliced bread. As a translator, I can tell you they aren't. Good translators split&merge segments to create logical units (otherwise, you'll get really interesting concordance hits down the line), and if they are allowed to use the best segmentation settings they can, then that job becomes easier. The "improved TM leverage" argument doesn't hold water because, again, good translators split&merge segments to create logical units so the TM will contain "correct segments", not "Trados default segments".


SDL Support wrote:

It is also backward compatibility we are talking about here

Yes, yes it is. Are you saying that providing convenient backwards compatibility for as many usage scenarios as possible is not a good goal to pursue? I have never personally met anyone who ever used a Trados project package. Some people use them I'm sure, but they are not the standard workflow at all.
As a software vendor, SDL should not try to guess what the best workflow is and then force its clients to adhere to it. Within reason, its tools should support a wide array of workflows, because its cookie cutter "best practice" workflow won't fit every real life scenario.

[Edited at 2012-03-01 10:10 GMT]


Direct link Reply with quote
 

SDL Community  Identity Verified
United Kingdom
Local time: 11:13
English
Then the answer is... Mar 1, 2012

... send the target file with the sdlxliff and then the client can still update their TM and they have the bilingual (in the event they have professional and use Perfect Match and decide to forgo you the opportunity of segmenting files yourself).

Or they upgrade and work with the same version as their translators. Actually if I've no intention of preparing anything myself and I want to do more than simply update my Translation Memories then I should at least make sure I have the versions my translators use or I'm asking for trouble. In fact seeing as I won't spend time preparing the files in the first place why would I even bother trying to create the target files... surely this is also effort that falls into the same category for your busy PM.

Of course providing for backwards compatibility is important and we do that where we can. You can share the sdlxiff between versions, work on them, review them etc. But being able to create target files from them is something that is dependent on how different the filetypes are in both versions. We do provide for this in the packages where possible, but the changes may be such that we don't hold them in the xliff itself.

Regards

Paul


Direct link Reply with quote
 
FarkasAndras
Local time: 11:13
English to Hungarian
+ ...
Workflows Mar 1, 2012

SDL Support wrote:

... send the target file with the sdlxliff and then the client can still update their TM and they have the bilingual (in the event they have professional and use Perfect Match and decide to forgo you the opportunity of segmenting files yourself).


Agencies ask for an sdlxliff because they like to proofread the bilingual file (as it's obviously more convenient to work with than separate source and target files). If they needed it just to update TMs, they could ask for a TMX and the problem wouldn't arise. Then they need to generate the target translations to send to the client, with the changes made by the proofreader. Sending the proofed sdlxliff back to the translator and getting the target file back from them is generally too slow/inconvenient for both parties.
Working with the same Trados versions would invariably mean that agencies have to work with at least 2 trados versions in parallel and keep track of which translator uses which. Not an appetizing prospect.
Of course packages are a reasonable alternative, but not most people's first choice.

SDL Support wrote:
Actually if I've no intention of preparing anything myself and I want to do more than simply update my Translation Memories then I should at least make sure I have the versions my translators use or I'm asking for trouble.

Judging from the OP's experience, that is the case. It shouldn't be the case though, and you can't expect people to know it is the case. Studio 2009 broke compatibility with the file formats of previous Trados versions, and that was fine considering that it was rewritten from scratch. Everyone's expectation was that subsequent Studio releases would maintain full interoperability and full compatibility with the newly introduced 2009 formats. The fresh start gave SDL the opportunity to come up with well thought-out formats and internal processes that can stand the test of time for at least 2 or 3 releases.

SDL Support wrote:
being able to create target files from them is something that is dependent on how different the filetypes are in both versions.

Do you think that's normal? Do you think it's good software design? I mean, ttx is an age-old format and I believe this problem doesn't happen with ttx, not even when you create the ttx in one brand of CAT and generate the target file with another brand. At least that's been my experience so far. I believe you need the source file to be able to generate target from a ttx and you might not need the source file for the sdlxliff workflow, but you need the same software tool and version... If you ask me, the first requirement is much more convenient and sensible than the second.

[Edited at 2012-03-01 11:36 GMT]


Direct link Reply with quote
 

SDL Community  Identity Verified
United Kingdom
Local time: 11:13
English
Maybe it's just me... Mar 1, 2012

FarkasAndras wrote:

Agencies ask for an sdlxliff because they like to proofread the bilingual file (as it's obviously more convenient to work with than separate source and target files). If they needed it just to update TMs, they could ask for a TMX and the problem wouldn't arise. Then they need to generate the target translations to send to the client, with the changes made by the proofreader. Sending the proofed sdlxliff back to the translator and getting the target file back from them is generally too slow/inconvenient for both parties.



But if this was my workflow I really wouldn't risk the preparation of the files to someone else. I would have no idea what tools they were going to use or what the the eventual sdlxliff would look like. It seems far more logical to make sure that at least I stand a reasonable chance of reducing problems in my workflow by preparing the files first.

FarkasAndras wrote:

I mean, ttx is an age-old format and I believe this problem doesn't happen with ttx, not even when you create the ttx in one brand of CAT and generate the target file with another brand. At least that's been my experience so far.



Interesting... you must be lucky. Which CAT tools do you know (other than SDL flavours) allow you to create a TTX in one and then generate the target file in another?

Regards

Paul


Direct link Reply with quote
 
FarkasAndras
Local time: 11:13
English to Hungarian
+ ...
sdlxliff Mar 1, 2012

SDL Support wrote:

But if this was my workflow I really wouldn't risk the preparation of the files to someone else. I would have no idea what tools they were going to use or what the the eventual sdlxliff would look like. It seems far more logical to make sure that at least I stand a reasonable chance of reducing problems in my workflow by preparing the files first.


To my knowledge, the only two tools that can generate an sdlxliff are Studio 2009 and Studio 2011, so you know they are going to use one of the two. People assume as a matter of course that their sdxliff files are identical or at least fully compatible. Why wouldn't they be? We're talking about two subsequent versions of the same software, the files have the same extension... people expect them to be the same thing. I thought they were until this thread popped up.
Again, mixed T2007/Studio ttx workflows are fully supported, aren't they? Both Studio and the age-old T2007 can generate target files from the same ttx. Then why wouldn't the same apply to the much more recent sdlxliff files and Studio 2009 and 2011?
I don't see why you expect people to assume by default that Studio 2009 and 2011 aren't interoperable and take it as a given that they will have to use workarounds for mixed 2009/2011 workflows.

BTW the CAT-hopping ttx workflow was the following: An agency that uses MemoQ requested the translation in bilingual ttx. I generated a ttx out of the source doc file in T2007, translated it with Studio2009 and sent it to the agency. They processed it with MQ no problem (proofread, update TM, generate target translations). As an aside, both TagEditor and Studio failed to generate the target file from the ttx for me but it wasn't a problem because the agency could generate the target file with MQ.
This agency uses MQ and I much prefer Studio, so we'll be testing the reliability of this workflow extensively, I expect.


Direct link Reply with quote
 

SDL Community  Identity Verified
United Kingdom
Local time: 11:13
English
They must have had Trados 2007 Mar 1, 2012

FarkasAndras wrote:

BTW the CAT-hopping ttx workflow was the following: An agency that uses MemoQ requested the translation in bilingual ttx. I generated a ttx out of the source doc file in T2007, translated it with Studio2009 and sent it to the agency. They processed it with MQ no problem (proofread, update TM, generate target translations). As an aside, both TagEditor and Studio failed to generate the target file from the ttx for me but it wasn't a problem because the agency could generate the target file with MQ.
This agency uses MQ and I much prefer Studio, so we'll be testing the reliability of this workflow extensively, I expect.


To my knowledge I'm not sure this can be correct? As far as I am aware it is not possible for memoQ to generate the target file from a TTX. I even tested it just now to reaffirm my belief... so unless there is an option somewhere I am unaware of (very possible as I'm not that familiar with memoQ) I think this agency must have had a copy of Trados too. Certainly something doesn't see right with this workflow. I think memoQ sees a TTX as another filetype and generates a TTX as the target.

FarkasAndras wrote:

Again, mixed T2007/Studio ttx workflows are fully supported, aren't they? Both Studio and the age-old T2007 can generate target files from the same ttx. Then why wouldn't the same apply to the much more recent sdlxliff files and Studio 2009 and 2011?



To be honest this is a good point. We treat TTX as a a filetype and include the necessary code to allow the generation of TTX or target file (this part I'm pretty sure nobody else can do... but will welcome evidence to the contrary for interest), but we don't treat a 2009 sdlxliff as a specific filetype. The xliff components are basically the same, although the 2011 version obviously holds more information because we introduced tracked changes etc. But the binary at the start is the important thing here because this holds the information about the original file it was created from and the necessary information to reconvert it. So the problem really is that the changes to the filetype has been changed too much for 2009 to be able to handle it in a way that allows the back conversion of the target file.

I'm sure the solution could be implemented, but I'm not sure it's worth it given the easy workaround. There were quite big changes between 2009 and 2011, not least because of the filetypes themselves, but also in how Studio handles these filetypes.... no more filetype folders etc.

I also think that despite this conversation the number of users with 2009 asking users to create sdlxliff in 2011 for them is considerably in the minority.

Regards

Paul


Direct link Reply with quote
 
Pages in topic:   [1 2] >


To report site rules violations or get help, contact a site moderator:


You can also contact site staff by submitting a support request »

Compatibility issues between Studio 2009 and Studio 2011

Advanced search







memoQ translator pro
Kilgray's memoQ is the world's fastest developing integrated localization & translation environment rendering you more productive and efficient.

With our advanced file filters, unlimited language and advanced file support, memoQ translator pro has been designed for translators and reviewers who work on their own, with other translators or in team-based translation projects.

More info »
Across v6.3
Translation Toolkit and Sales Potential under One Roof

Apart from features that enable you to translate more efficiently, the new Across Translator Edition v6.3 comprises your crossMarket membership. The new online network for Across users assists you in exploring new sales potential and generating revenue.

More info »



Forums
  • All of ProZ.com
  • Term search
  • Jobs
  • Forums
  • Multiple search