Closed ghost closed 3 years ago
Hi, I'm the developer who is working in the TBX export/import scripts right now, as it happens.
Yes, I'm aware of the two patterns for encoding terms in TBX, either as tig
or as ntig
. I will take it into consideration as I am developing the tbx-to-entry.js
script further in the next few days, and I will make sure that both patterns are accepted and understood.
So much for importing from TBX into Terminologue. In the opposite direction, exporting from Terminologue into TBX, we always do it the ntig
way, even when that would strictly speaking not be necessary and a tig
would suffice. I hope that's OK for you. If you see a problem with that, let me know (open another issue, I guess).
Thank you for the quick response!
I will take it into consideration as I am developing the tbx-to-entry.js script further in the next few days, and I will make sure that both patterns are accepted and understood.
That sounds good! I guess we got a bit antsy trying to test the functionality. :)
(We also noticed that metadata like <description type=descrip/>
is currently missing in the imported file but I figured that is no doubt already on your agenda, so I did not create another report for that.)
In the opposite direction, exporting from Terminologue into TBX, we always do it the ntig way, even when that would strictly speaking not be necessary and a tig would suffice.
I heavily suspect that will be fine, but do in fact not know all that much about translation. The main audience for exports here will be translators. I.e., as long as Trados is happy, we should be golden.
I tried to test the unfinished (I know) TBX importer script locally with a TBX file exported from iTerm.
The iTerm database exports appear to use a slightly different XML format than the Terminologue database exports, notably, there is this difference in tagging:
On my local install, I got it to work by adding this but I am not sure that is the right solution: