Jonathan Hopkins Germany Local time: 03:48 German to English + ...
Going with memoQ workaround to save time and complications
Nov 25, 2011
Thanks Grzegorz,
Grzegorz Gryc wrote:
Try other workarounds based on TBX-CSV conversion.
The CSV mapping in Multiterm is easier.
You should rename the column headers in the CSV file, they should match the Multiterm database structure.
You can also save CSV as Excel, it's probably easier to edit complex data.
In the past, I've had difficulties with converting files to CSV, since Excel has always eliminated the Unicode setting upon saving the file. Doesn't that happen for you, when you convert, say, a txt file into CSV? Even though I select the Unicode UTF-8 setting upon opening my document in Excel, once I save it as a CSV file, and re-open the file in Excel, or OpenOffice for that matter, the coding has been switched (probably to ANSI or whatever is first in the list). I've tried this procedure before for Transit IV which exports mtf and txt files, which need to be converted to CSV files. It always created havoc with our Slavic languages, since the special characters were not rendered properly.
In any case, I've really appreciated your very promt and helpful replies, but in the end I'll just wait for the tmx files to import into memoQ, which will then give me a good xml file compatible with MultiTerm.
Cheers,
Jonathan
Subject:
Comment:
The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional)
Grzegorz Gryc Poland Local time: 03:48 French to Polish + ...
TOPIC STARTER
Text Unicode... Multiterm annoyances...
Nov 25, 2011
Jonathan Hopkins wrote:
In the past, I've had difficulties with converting files to CSV, since Excel has always eliminated the Unicode setting upon saving the file. Doesn't that happen for you, when you convert, say, a txt file into CSV?
No
I don't save as CSV, I use the Unicode text option which produces neat tab separated Unicode files.
It works as a charm.
Even though I select the Unicode UTF-8 setting upon opening my document in Excel, once I save it as a CSV file, and re-open the file in Excel, or OpenOffice for that matter, the coding has been switched (probably to ANSI or whatever is first in the list).
By default, your Windows code page.
It always created havoc with our Slavic languages, since the special characters were not rendered properly.
True.
The default CSV damages these chars but the Unicode text option behaves correctly.
Believe me, I'm Polish
In any case, I've really appreciated your very promt and helpful replies, but in the end I'll just wait for the tmx files to import into memoQ, which will then give me a good xml file compatible with MultiTerm.
Yep, probably you'll have less problems with the mappings if you use a default-like Multiterm termbase definition.
BTW, the column naming conventions for complex Excel/CSV files mapping are not documented, AFAIK.
E.g. in order to receive the structure automatically in MT Convert, you should concatenate the field names e.g. English Note if you want to put Note under English.
Extremely annoying.
Practically unusable for complex multilanguage files but it's handy for small imports.
So why I use sometimes Across as converter, it sets unique names for CSV columns.
Cheers
GG
Subject:
Comment:
The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional)
Grzegorz Gryc Poland Local time: 03:48 French to Polish + ...
TOPIC STARTER
Veritable mess...
Nov 25, 2011
FarkasAndras wrote:
Good Lord, that's a veritable mess.
Can't the translation industry produce and implement standards that work? TMX isn't exactly working flawlessly, and TBX looks like it's a lot worse.
Probably the translation industry doesn' t really care about the compatibility and interoperation, so why the TMX files exchange is almost always lossy (e.g. formatting, context etc.).
As the translation offices don't care about the terminology, TBX was never popular, so during several years almost nobody insisted on the compatibility.
In fact, the compatibility between several implementations is very poor and it's safer to use CSV which is transparent.
The drawback is Trados (Multiterm) is simply unable to generate valid CSV files.
Because brand matters
Anyone know for a fact who is at fault here? Is it SDL or is the standard broken?
SDL.
The last time I tested it, they were unable to exchange TBX files between SDL Idiom and SDL Studio.
I suppose SDL Whatever is unable to import correctly TBX files generated by SDL Whatever Else.
Cheers
GG
Subject:
Comment:
The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional)
FarkasAndras Hungary Local time: 03:48 English to Hungarian + ...
SDL hates TBX
Nov 25, 2011
Grzegorz Gryc wrote:
Anyone know for a fact who is at fault here? Is it SDL or is the standard broken?
SDL.
The last time I tested it, they were unable to exchange TBX files between SDL Idiom and SDL Studio.
I suppose SDL Whatever is unable to import correctly TBX files generated by SDL Whatever Else.
Wow, that's... erm... peculiar.
Subject:
Comment:
The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional)
Grzegorz Gryc Poland Local time: 03:48 French to Polish + ...
TOPIC STARTER
Marketing strategy...
Nov 25, 2011
FarkasAndras wrote:
Grzegorz Gryc wrote:
Anyone know for a fact who is at fault here? Is it SDL or is the standard broken?
SDL.
The last time I tested it, they were unable to exchange TBX files between SDL Idiom and SDL Studio.
I suppose SDL Whatever is unable to import correctly TBX files generated by SDL Whatever Else.
Wow, that's... erm... peculiar.
I don't say it's always the same mess, I simply don't have enough force/patience to retest the same non working scenarios.
IMO they have their proprietary Multiterm XML and they'll do everything in order to defend this format 'cause it's very unfriendly for more advanced CAT hopping which is a horror for SDL.
Anyone know for a fact who is at fault here? Is it SDL or is the standard broken?
SDL.
The last time I tested it, they were unable to exchange TBX files between SDL Idiom and SDL Studio.
I suppose SDL Whatever is unable to import correctly TBX files generated by SDL Whatever Else.
I beg to disagree.
I don't think SDL is the only one at fault.
TBX is a complex and flexible standard meant to cover many different types of needs.
For instance, you can have a Definition field at Entry level (one definition for all terms in all languages), at Language level (one definition for all terms in a language) or at term level (one definition for each term).
You can have three different perfect 100% compliant TBX files which just cannot be merged automatically into the same termbase (not from which company) because they have the definition field at different levels.
"Full TBX compliant" does not mean easy and automatic compatibility. Termbases can have different structures.
That's why many software applications can claim to be 100% compliant with TBX and still they lack interoperability.
Users could try to stick to TBX-basic, which is more easily exchangeable, but then again, this might not be suitable for all situations and we are back to square one.
Daniel
Subject:
Comment:
The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional)
Grzegorz Gryc Poland Local time: 03:48 French to Polish + ...
TOPIC STARTER
TBX vs TBX-basic
Nov 25, 2011
Daniel García wrote:
Grzegorz Gryc wrote:
Anyone know for a fact who is at fault here? Is it SDL or is the standard broken?
SDL.
The last time I tested it, they were unable to exchange TBX files between SDL Idiom and SDL Studio.
I suppose SDL Whatever is unable to import correctly TBX files generated by SDL Whatever Else.
I beg to disagree.
I don't think SDL is the only one at fault.
TBX is a complex and flexible standard meant to cover many different types of needs.
(...)
You can have three different perfect 100% compliant TBX files which just cannot be merged automatically into the same termbase (not from which company) because they have the definition field at different levels.
Yes, I'm a aware of it but I was speaking about the very basic default exports.
No definition, only the user, date, maybe something more.
If one company is unable to create and use unified default structures, it's something wrong here...
BTW.
Some time ago, I simply refused to work with Idiom projects, so maybe SDL managed to create one basic default template, I dunno.
(...)
Users could try to stick to TBX-basic, which is more easily exchangeable, but then again, this might not be suitable for all situations and we are back to square one.
Exactly.
Nonetheless, I think 95% (or more) of the users will be happy with the basic compatibility...
Cheers
GG
[Edited at 2011-11-25 17:00 GMT]
Subject:
Comment:
The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional)
FarkasAndras Hungary Local time: 03:48 English to Hungarian + ...
Not an excuse
Nov 25, 2011
Daniel García wrote:
For instance, you can have a Definition field at Entry level (one definition for all terms in all languages), at Language level (one definition for all terms in a language) or at term level (one definition for each term).
You can have three different perfect 100% compliant TBX files which just cannot be merged automatically into the same termbase (not from which company) because they have the definition field at different levels.
I disagree. There is no reason why TBX compliant tools can't offer to create the required new field during the import process. If definitions at the various levels are part of the standard, then compliant tools should know about them. Fields are added to TMs during TMX import, I don't see why it would have to be a problem with TBX.
Daniel García wrote:
"Full TBX compliant" does not mean easy and automatic compatibility.
In that case, TBX is useless as an interchange standard, don't you think? If it can only work with an all-Multiterm (all-DVX, all-MQ etc.) workflow and it can't provide CAT-hopping compatibility, then it's no better than each company sticking to its own proprietary format (MultiTerm XML etc.)
Subject:
Comment:
The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional)
Jonathan Hopkins Germany Local time: 03:48 German to English + ...
I for one would definitely prefer a compatible—even if somewhat simplified—to a very complex standard, if it meant that data exchange would be easier than it presently is.
Grzegorz Gryc wrote:
Nonetheless, I think 95% (or more) of the users will be happy with the basic compatibility...
I don't mind the somewhat simplistic term base from memoQ if it means I get guaranteed compatibility. And besides, the most important fields are all included anyway.
And speaking of compatibility...my import into MultiTerm via memoQ is now complete after just a few clicks.
I really like a lot of features of memoQ, especially the fact that it simply works the way you'd expect it to.
Cheers,
Jonathan
Subject:
Comment:
The contents of this post will automatically be included in the ticket generated. Please add any additional comments or explanation (optional)
SDL Trados Studio 2011 is the latest market-leading translation memory software from SDL. Now with Track Changes, Bilingual Word Files support, new Display Filter, AutoSuggest and more great details.
SDL provides market-leading translation software to over 185,000 users
SDL offers leading translation management solutions to meet LSPs needs throughout the whole translation supply chain.
With over 185,000 licenses being used by translators and organizations worldwide, our products will help you to connect to a supply chain that guarantees compatibility, making it easier to work with your customers and other users.
The translation workplace 
Translation news related to SDL Trados