It's not very clear at all in the help, but this is the part that's relevant:

4. Do one of the following:

• If you have not yet created an import definition, right-click Import and select Create.
• If you already have one, select it from the list in the right-hand window.

What this really means is that you have to create an import definition first, you can't edit the defaults with the advanced options so they skip from step 3 to step 7.  So you need to do this:

1. duplicate one of the defaults (must be one of the synchronize defaults to get the advanced options)
2. select the new one you just created and then Edit
3. run through the wizard
4. you will get the advanced options

Just one of the reasons people love the Glossary Converter :-)

Paul

Ah, yes. Thank you. My issue with Glossary Convreter is that I rely heavily on field metadata (created on, modified on ...) Glossary Converter does not preserve these values, does it?

MultiTerm is definitely an "old" program, the UI is not like today's. But once you get used to it, it has many, many useful features. Field metadata is one of them. I guess it will be replaced with the current "Live" version at some point? That is quite good and lightning fast, but I could not find field info like "create on", "modified by" etc. yet.

Here's a change suggestion: When importing (non-reversible step), the final button before the import actually takes place is called "Next". I wish it was called "Import" or "Start Import", to make sure the user realizes the NOW is the moment and there are no more import options to hope for.

Daniel

Unknown said:

Here's a change suggestion: When importing (non-reversible step), the final button before the import actually takes place is called "Next". I wish it was called "Import" or "Start Import", to make sure the user realizes the NOW is the moment and there are no more import options to hope for.

That's a good suggestion... perhaps one for the ideas site?  That's the best place to have these things considered by the product managers.

community.sdl.com/.../multiterm-ideas

Unknown said:

MultiTerm is definitely an "old" program, the UI is not like today's. But once you get used to it, it has many, many useful features. Field metadata is one of them. I guess it will be replaced with the current "Live" version at some point?

Maybe... maybe not.  Certainly the "Live" version will continue to improve and there will be more exciting things around terminology available through this medium that we don't have great solutions for at the moment.

Unknown said:

Ah, yes. Thank you. My issue with Glossary Convreter is that I rely heavily on field metadata (created on, modified on ...) Glossary Converter does not preserve these values, does it?

Only if you use the XML/XDT export.  But then you don't have the same flexibility to edit the data as you already know.  So yes, you're correct for your usecase.

Unknown said:

Here's a change suggestion: When importing (non-reversible step), the final button before the import actually takes place is called "Next". I wish it was called "Import" or "Start Import", to make sure the user realizes the NOW is the moment and there are no more import options to hope for.

That's a good suggestion... perhaps one for the ideas site?  That's the best place to have these things considered by the product managers.

community.sdl.com/.../multiterm-ideas

Unknown said:

MultiTerm is definitely an "old" program, the UI is not like today's. But once you get used to it, it has many, many useful features. Field metadata is one of them. I guess it will be replaced with the current "Live" version at some point?

Maybe... maybe not.  Certainly the "Live" version will continue to improve and there will be more exciting things around terminology available through this medium that we don't have great solutions for at the moment.

Unknown said:

Ah, yes. Thank you. My issue with Glossary Convreter is that I rely heavily on field metadata (created on, modified on ...) Glossary Converter does not preserve these values, does it?

Only if you use the XML/XDT export.  But then you don't have the same flexibility to edit the data as you already know.  So yes, you're correct for your usecase.