MultiTerm Import

Former Member
Former Member

Hi

I'd like to know how can I use "SDL MultiTerm > Termbase Management > Import > Synchronize on Term" check item.

I'm in the middle of testing. Code goes..

Entries myEntries = myTB.Entries;
foreach(string myXMLitem in myXMLitems)
{
    Entry myEntry = myEntries.New(myXMLitem);
    //  myEntry.Merge(someTHING);
}

So far so good, I can import successfully for non_duplicated items.

But, I can not figure out how to manage duplicated items properly (entry Merge).

Just a brief hints/sample_codes should be perfect.

Thanks

[Version 2017]

OR

I just found this kind of codes. But, I can not handle it properly.

ImportDefinition myImportDefinition = myImportDefinitions[2];     // Synchronize on Term
myImportDefinition.ProcessImport(MtTaskType.mtScript, "English", "Chinese");

I have a proper XML file and I do not want to use "Wizard"

Thanks

Parents
  • Not sure what you mean by "not handle it properly", but your code looks OK. Here is a snippet from some old test code I had around, it performs an import without the wizard:

                string tbPath = @"C:\_temp\New Termbase.sdltb";
                string definitionName = "sync";

                Sdl.MultiTerm.TMO.Interop.Application mt =
                    new Sdl.MultiTerm.TMO.Interop.Application();
                TermbaseRepository tr = mt.LocalRepository;
                tr.Connect("", "");
                tr.Termbases.Add(tbPath, "Name", "description");
                Termbase tb = tr.Termbases[tbPath];

                tb.ImportDefinitions[definitionName].ProcessImport(MtTaskType.mtScript, "German", "English");

                tb.Close();
                mt.LocalRepository.Disconnect();

    But... you may have found a bug in the MultiTerm API, because it does not merge. If I run the same definition (called "sync" in my setup) in theUI, it properly merges entries. Through the API it does add them as new. You may be out of luck here, I can't see a bugfix for that being high priority.

  • Hi Gerhard - do you remember whether the bug only affects the "Merge" operation via the API, or whether I can't sync at all via the API? As far as I understand / remember it's only via the "Synchronize on Entry Number" option that we can force MultiTerm to make incoming entry numbers survive (instead of MultiTerm renumbering / creating new ones for incoming imported entries) ... I am asking before we start spending quite some time in developing an API driven import script ...

    Our customer demand / story is to automate the following: we export Coreon repository data into mtf format, assign integers for the entries (MultiTerm only allows integers for entry IDs ...), inject  CLinks to link entries to each other, then import via API script into MultiTerm sdltb local file - but for this I need the entry numbers to survive.

    A workaround for us would be to create an index/language, say, "Coreon ID" that holds the Coreon IDs, and we link via TLink, but then another index / language shows up in the sdltb file (a bit ugly from a UX point of view). Therefore, I'd prefer the first option ...

    Best

    Michael

Reply
  • Hi Gerhard - do you remember whether the bug only affects the "Merge" operation via the API, or whether I can't sync at all via the API? As far as I understand / remember it's only via the "Synchronize on Entry Number" option that we can force MultiTerm to make incoming entry numbers survive (instead of MultiTerm renumbering / creating new ones for incoming imported entries) ... I am asking before we start spending quite some time in developing an API driven import script ...

    Our customer demand / story is to automate the following: we export Coreon repository data into mtf format, assign integers for the entries (MultiTerm only allows integers for entry IDs ...), inject  CLinks to link entries to each other, then import via API script into MultiTerm sdltb local file - but for this I need the entry numbers to survive.

    A workaround for us would be to create an index/language, say, "Coreon ID" that holds the Coreon IDs, and we link via TLink, but then another index / language shows up in the sdltb file (a bit ugly from a UX point of view). Therefore, I'd prefer the first option ...

    Best

    Michael

Children
No Data