T2007: Unable to import a TMX export from T2009
Thread poster: Bjørnar Magnussen

Bjørnar Magnussen  Identity Verified
Local time: 15:13
English to Norwegian
+ ...
Jun 30, 2009

A customer is asking for a Trados 2.x - 6.x format export of a project that I have translated in Trados 2009.

Since Trados 2009 don't let me export to this format, I figured out that I had to export to TMX, import the TMX file in Trados 2007 and then export to Trados 2.x - 6.x from there.

However, no matter what file type (TMX 1.1, 1.4 or 1.4b) I choose in the import dialogue in T2007, I always get "0 added, xxx invalid TUs".

The languages of the T2007 TM and T2009 export are exactly the same.

Have any of you been able to import a T2009 TMX export into T2007?


 

Claudia Alvis  Identity Verified
Peru
Local time: 08:13
Member
Spanish
+ ...
Yes Jun 30, 2009

I have, a few times. Check your filter settings, maybe something is preventing the TUs from being imported. Also, make sure you have full access to the TM in Trados 2007.

 

Bjørnar Magnussen  Identity Verified
Local time: 15:13
English to Norwegian
+ ...
TOPIC STARTER
TMX 1.1, 1.4 or 1.4b? Jun 30, 2009

Thanks a lot for your quick answer, Claudia. I will experiment further. Which format did you choose when importing into Trados 2007 - TMX 1.1, 1.4 or 1.4b?

 

Bjørnar Magnussen  Identity Verified
Local time: 15:13
English to Norwegian
+ ...
TOPIC STARTER
Language codes Jun 30, 2009

I opened the TMX in Notepad++ and changed all the language codes from "NB_NO" to "NO_NO" - then it worked:)

 

Claudia Alvis  Identity Verified
Peru
Local time: 08:13
Member
Spanish
+ ...
Plain TMX Jun 30, 2009

In Studio, there's no option to set the version of the TMX files. Under 'Save as type', there's only TMX Files and TMX Compressed Files. You should select the first one. Then in Trados, I always select 1.4b; for no particular reason really, I figure that it's the newest one. But I just exported a Studio TM and imported into a new Trados TM, I used the three TMX formats, and was able to add all the terms without any problems.

Nevermind, I just read your new post. I guess it's one of those "small" issues that shouldn't been there in the first place.


 

BenB
Local time: 15:13
Norwegian to English
Worked for me too Jul 1, 2009

Thanks for posting the solution you found, Bjørnar - I did the same thing after having the same problem and was able to import the TMX file successfully. I don't know whether this only affects translation memories with Norwegian as one of the languages, or whether it's a more general issue, but either way it appears to be a bug.

 

SDL Community  Identity Verified
United Kingdom
Local time: 15:13
English
Legacy Language Codes Jul 1, 2009

BenB wrote:
........, but either way it appears to be a bug.


Hi all,

This is an interesting one, and I wanted to post because I don't think I would class this as a bug, but it would make an interesting feature request on ideas.sdl.com.

In some cases the language codes used by .Net applications (such as Studio) are incompatible and will not be recognized when the file is imported into older applications. One of these cases is nb-NO (Norwegian Bokmal) where Workbench uses the legacy language code no-NO, as Bjørnar discovered.

We have introduced a mapping from legacy codes to those used by Studio, but not the other way around as it would require corresponding "export modes" which then would apply the legacy (target) application's codes. However the target application may not be known at the time of export.

As a workaround you could attempt to import the bilingual files (ttx or itd) instead, if they were available, or edit the export file as Bjørnar has done. This type of thing is often a problem when looking at backwards migration because legacy applications don't always have the ability to use newer formats, handle custom field values or retain formatting for example).

Regards

Paul
SDL Support


 

Thomas Groendal  Identity Verified
Local time: 06:13
Japanese to English
For me it was unicode Jul 12, 2011

I do Jp-Eng, and my solution to this problem has always been to save the export file as unicode. It is automatically saved as UTF-8. I simply open the export file in notepad and save as... followed by selecting unicode from the pulldown menu. Oila!

 

FarkasAndras
Local time: 15:13
English to Hungarian
+ ...
Language codes Jul 12, 2011

SDL Support wrote:

BenB wrote:
........, but either way it appears to be a bug.


Hi all,

This is an interesting one, and I wanted to post because I don't think I would class this as a bug, but it would make an interesting feature request on ideas.sdl.com.

In some cases the language codes used by .Net applications (such as Studio) are incompatible and will not be recognized when the file is imported into older applications. One of these cases is nb-NO (Norwegian Bokmal) where Workbench uses the legacy language code no-NO, as Bjørnar discovered.

We have introduced a mapping from legacy codes to those used by Studio, but not the other way around as it would require corresponding "export modes" which then would apply the legacy (target) application's codes. However the target application may not be known at the time of export.

As a workaround you could attempt to import the bilingual files (ttx or itd) instead, if they were available, or edit the export file as Bjørnar has done. This type of thing is often a problem when looking at backwards migration because legacy applications don't always have the ability to use newer formats, handle custom field values or retain formatting for example).

Regards

Paul
SDL Support


I would class it as a bug. Two products, made by the same company a couple of years apart and currently sold together as a product suite of sorts, are not fully interoperable. That's hardly commendable.

I'm not sure what it has to do with .NET (surely, any .NET app can generate an XML file with whatever content it pleases), but the issue is very real. IMO the solutions you are mulling over are off the mark, though. As you say, attempting to second guess what language code another application is expecting is a crapshoot. Your own legacy apps are one thing, but there are a gazillion other CAT tools, aligners and other tools out there that need to share TMX files with Studio and there is no way of telling what codes they might generate or expect... Well, there is the TMX standard which should settle this, but as we've repeatedly seen, somehow different vendors manage to interpret the standard completely differently. Was this aspect of the standard revised at some point? Is it ambiguous? I don't know.
The only civilized solution that I can see is the following: on importing, if the language code doesn't match what Studio expects, throw up a popup that says: "Oops, the language codes in your TMX file don't match the languages of your TM. Please pair up the languages. Is nb-NO equivalent to no-NO?" That's a lot more 21st-century than failing with a cryptic error message and leaving the user to try and figure out what's wrong and then hack the TMX, don't you think? Implementing something like this is really a trivial matter.
The same applies to corrupted characters and illegal character entities in TMX files. Rather than fail with an error message that's undecipherable to most users, it'd be much better to just skip the bad TU and notify the user - or even give the user an option to fix the error.


 


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


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

T2007: Unable to import a TMX export from T2009

Advanced search







Wordfast Pro
Translation Memory Software for Any Platform

Exclusive discount for ProZ.com users! Save over 13% when purchasing Wordfast Pro through ProZ.com. Wordfast is the world's #1 provider of platform-independent Translation Memory software. Consistently ranked the most user-friendly and highest value

More info »
Anycount & Translation Office 3000
Translation Office 3000

Translation Office 3000 is an advanced accounting tool for freelance translators and small agencies. TO3000 easily and seamlessly integrates with the business life of professional freelance translators.

More info »



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