Bruce Officer 

Use the Glossary Converter, it has these options for TBX:

If you have Trados Studio  2021 or 2022 you can download this tool via the (Missing Wiki Page) . 

If you don't then you can also find it here: https://cerebus.de/glossaryconverter/index.html

Thank you for replying, Paul, but (as I said) I've already tried the Glossary Converter. The TBX it generates is rejected by Lingo's import function with the error message "Not a TBX Basic file. Lingo currently only supports TBX Basic." It doesn't seem to make any difference which of the three TBX dialects I choose in in the Glossary Converter's Formats > TBX window - the TBX file output by Glossary Converter is identical in all three cases. I've verified this by opening them in Notepad++ and doing file compares. I've even been in contact with the developer of Glossary Converter. It seems that the TBX dialect radio buttons alter the available mappings when you are converting TBX back into other formats, but they DON'T change much when you're converting in the SDLTB -> TBX direction. The 'type' attribute in the root <martif> element, for example, remains <martif type="TBX" xml:lang="en"> in the TBX files output by Glossary Converter regardless of the TBX dialect you think you've selected. The developer's suggestion was to try manually changing this to <martif type="TBX-Basic" xml:lang="en"> in my text editor prior to importing it into Lingo. I'm going to try that, but it would be disappointing to have to settle for this manual process. I'm sure there must be other people who've had to transfer termbases between MultiTerm and Lingo and I'm hoping one of them has found a slicker solution.

Bruce Officer 

Bruce Officer said:

The TBX it generates is rejected by Lingo's import function with the error message "Not a TBX Basic file. Lingo currently only supports TBX Basic.

I think it would be interesting to learn more from the Lingo side what they believe a TBX basic is and why these files fail?  I know that the developer of the Glossary Converter worked directly with the TBX committee at their request to be able to handle these formats as expected. Do you have any information on this, or even a link to something they refer to in their documentation?

I'll make the developer aware of this thread though as he might be interested to comment.

I'll ask MadCap what criteria Lingo uses to determine if a file is valid TBX-Basic or not. I'm not sure how much useful info I'll get from them, though. I get the impression that MadCap consider Lingo a minor adjunct to their flagship Flare authoring environment and don't assign much resource to supporting or updating it. Lingo hasn't had a major update since 2016 if I understand correctly, whereas Flare is updated at least once a year.

This isn't the first issue I've encountered passing translation files between Lingo and RWS products. When I used Lingo to bundle up a Flare project into XLIFF for export to a Trados-using LSP, Lingo wouldn't reimport the return bundle. Peeking inside the files with Notepad++ I saw that Trados had overwritten the segmentation tags with ones using a different syntax. Not that I'd blame Trados - the xml structure and segmentation tagging in the original Lingo XLIFF export was frankly a mess. Unfortunately Lingo didn't seem to like those changes. I only mention this example because it reinforces my assessment of Lingo as being OK if used in isolation but poor when it comes to compatibility with standard translation file types.

I'll ask MadCap what criteria Lingo uses to determine if a file is valid TBX-Basic or not. I'm not sure how much useful info I'll get from them, though. I get the impression that MadCap consider Lingo a minor adjunct to their flagship Flare authoring environment and don't assign much resource to supporting or updating it. Lingo hasn't had a major update since 2016 if I understand correctly, whereas Flare is updated at least once a year.

This isn't the first issue I've encountered passing translation files between Lingo and RWS products. When I used Lingo to bundle up a Flare project into XLIFF for export to a Trados-using LSP, Lingo wouldn't reimport the return bundle. Peeking inside the files with Notepad++ I saw that Trados had overwritten the segmentation tags with ones using a different syntax. Not that I'd blame Trados - the xml structure and segmentation tagging in the original Lingo XLIFF export was frankly a mess. Unfortunately Lingo didn't seem to like those changes. I only mention this example because it reinforces my assessment of Lingo as being OK if used in isolation but poor when it comes to compatibility with standard translation file types.