ah, you are right.
i found it.
thanks.

-minor inconvenient thing.. I have to click more than "200" times. that's a quite labor.

sounds like that is the real dark side of it.

if it still has Fields problem, forget about it. Period.

it says its latest version is "2009 April 29"
oh, that's enough

it says its latest version is "2009 April 29"
oh, that's enough

i have tested that "2009" Olifant
it recognizes all fields of SDL Trados Studio correctly.
that is good enough.

but, if you want to use them (my sdltm has lots, lots of fields) again,
you have to make all and every of them "Again" when you import it into SDL Trados Studio.
that is pure nonsense.
so, i guess, field problem lies at SDL's "2017" side.
i do not think it's a bug, it's just another difficulties.

i could be wrong, because i have used Olifant less than 5 minutes.
if you know better idea about it tell me, i'll check it out, for sure. 

And, Do not mention others age like this, that is dirty attitude. 

In short
I am not going to use the old "Olifant"
In itself it works well. But, it's not good at with SDL Traods Studio 2017.

Martin Jornan said:

but, if you want to use them (my sdltm has lots, lots of fields) again,
you have to make all and every of them "Again" when you import it into SDL Trados Studio.
that is pure nonsense.

This is not really nonsense.  The problem with using TMX is that it lists all the fields you used for that TMX but it carries no information about what should actually be in the TM.  For example, your TM could be set up for 5 different types of fields and 10 different possible picklist values in each field.  The TMX export may not actually contain all the fields or all the values so when you share that TMX with someone else they will not get the same TM as the one you have.

Maybe make use of a Language Resource Template and then you will be able to recreate your TMs quickly and reliably?

Martin Jornan said:

And, Do not mention others age like this, that is dirty attitude. 

I don't agree with this.  TMX is a really old exchange filetype that has been used for decades and it hasn't changed for around a decade.  So why wouldn't you use a piece of software that was designed to handle old formats like this if you see fit?  I've played a round with Heartsome and it has some good qualities, but I still find Olifant to be more stable than that despite its age.  It's still used as part of the Okapi framework by many localization engineers today.

Martin Jornan said:

or if you like tmx so much, makes it as "Default".

TMX is an exchange file.  I didn't say I liked it at all.

Martin Jornan said:

i really hate to converting something.
if you can handle it using sdltm directly do it so.

This is not always possible without corrupting the SDLTM.  I know you like to work directly with SQL and it is really fast, but it's not always possible to do this safely.  It just depends on what you are trying to achieve.

if you restrict under this topic, it is ALWAYS possible using sdltm "directly" without corrupting the SDLTM
you do not have to use "sdltm>tmx>sdltm" detour (and it revealed itself useless if you have fields within it.  -at least very dangerous and tedious)

Martin Jornan said:

it is ALWAYS possible using sdltm "directly" without corrupting the SDLTM

I don't think this is correct.  If you are making changes to system and custom fields then yes, it's perfectly fine and we have developed a solution for something we will release shortly that uses SQL to do this as it is very fast.  But if you are changing content in the source and/or target segments then it is not always possible.  For this we had to use the Language Platform API to prevent corruption of the SDLTM.  So we created a mix and match and used SQL where it was safe and the APIs where we needed more surety.

I would add a caveat here that this is only a problem for TMs that support the new SDLTM structure to accommodate fragment matching.  Legacy TMs are not affected by this, but since we are now on the second version to support fragment matching I think it's safe to say it's risky to use only SQL.  The APIs are designed to ensure developers can work on assets safely without damaging them in any way.

If you are finding working with SQL is fine for the things you are doing then that's great, but please don't suggest this as always being possible as this may lead some developers down a path to problems.