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

Bjørnar Magnussen  Identity Verified
Local time: 17:38
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?


Direct link Reply with quote
 

Claudia Alvis  Identity Verified
Peru
Local time: 10:38
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.

Direct link Reply with quote
 

Bjørnar Magnussen  Identity Verified
Local time: 17:38
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?

Direct link Reply with quote
 

Bjørnar Magnussen  Identity Verified
Local time: 17:38
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:)

Direct link Reply with quote
 

Claudia Alvis  Identity Verified
Peru
Local time: 10:38
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.


Direct link Reply with quote
 
BenB
Local time: 17:38
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.

Direct link Reply with quote
 

SDL Community  Identity Verified
United Kingdom
Local time: 17:38
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


Direct link Reply with quote
 

Thomas Groendal  Identity Verified
Local time: 08:38
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!

Direct link Reply with quote
 
FarkasAndras
Local time: 17:38
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.


Direct link Reply with quote
 


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







WordFinder
The words you want Anywhere, Anytime

WordFinder is the market's fastest and easiest way of finding the right word, term, translation or synonym in one or more dictionaries. In our assortment you can choose among more than 120 dictionaries in 15 languages from leading publishers.

More info »
Déjà Vu X3
Try it, Love it

Find out why Déjà Vu is today the most flexible, customizable and user-friendly tool on the market. See the brand new features in action: *Completely redesigned user interface *Live Preview *Inline spell checking *Inline

More info »



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