Extending the TBX-import

A new method is created in the REST API of translate5, with which TBX files can be imported (so far the TBX import in the API is part of the task upload).

• A parameter of the new method determines to which end customer the TermCollection is assigned.(this is solved by design, since in the lek_term_collection there is customerId field)
• Another parameter of the new method determines in which TermCollection the TBX file is imported.
• If the TermEntry ID and the term ID of a term are already contained in the TermCollection, this term is updated in translate5.
  • if the condition match
    • update the term text and the term attributes
    • remove unmatched attributes
• If the TermEntry ID exists in the TermCollection, but the Term ID is not, then translate5 analyzes whether the same term for this termEntry ID already exists under a different term ID in the same language and with the same termEntry ID
  • If so, this term is updated, but its term ID in translate5 is retained (not taken from the TBX).
  • If the term does not exist at the termEntry ID, it is added to the termEntry as a new term entry with the ID from the TBX.
  • remove unmatched attributes
• If the TermEntry ID does not exist in the TermCollection (no matter, what the term ID does), another parameter ("mergeTerms") decides what happens:
  • If the parameter is true, translate5 will search all existing terms to see if the same term already exists in the TermCollection in the same language.
    • If so, the first term that is found is updated by the values ​​in the TBX file. The term-ID and termEntry-ID remain the same as they already existed in translate5.
      • All other terms of this termEntry in the TBX file will be imported/merged to the same termEntry of the TermCollection, that just has been found through the matching 
      • This means, if 2 (or more) terms that belong to the same termEntry-ID in the TBX file can be merged with a term in the database, but in the database those terms do NOT belong to the same termEntry-ID, only the first one will be merged with the one it matches and the second one (or more) will be put into the same termEntry as the first one.
    • If no term of a termEntry can be matched with an existing term in the termCollection, a new termEntry is added with the termEntry ID of the TBX in the TermCollection and all terms of the termEntry of the TBX are added to this termEntry in the TermCollection
    • Summarized this means, that the checks should be done in the following order, in case the termEntry-ID does not exist in the termCollection and mergeTerms is true
      • For each term of a termEntry of the TBX file check, if the term exists in the termCollection within the same language.
        • If yes, merge it 
          • Also put all other terms of the same termEntry of the TBX (independent of their language) file into this termEntry in the termCollection
            • When doing this check, if this term already exists within this termEntry in the DB. 
              • With the same ID? If yes: Merge it
              • Not with the same ID, but they exist: Also merge it.
              • If exists not at all: Add it to the termEntry
            • After adding these other terms to the termEntry, you can therefore stop checking, if they match with something (abort the loop)
        • If the term does not match, check the next
        • if no term of the termEntry of the TBX file can be matched, create a new termEntry with the termEntry-ID of the TBX and add all terms from the TBX to that termEntry in the termCollection with the term-IDs of the TBX.
  • If the parameter is false, a new termEntry is added to the termCollection with the term ID of the TBX file and all terms of this termEntry of the TBX file are added to this new termEntry in the termCollection with the term IDs of the TBX file (same thing as if  no term from this termEntry in the TBX can be matched in the termCollection).

When imported, each term that was "touched" receives an update stamp. It also ensures that all terms older than the current import can be deleted during import.

The TermImport must be changed, so that original IDs from the TBX file are used, not anymore the autocalculated one.

Document all new API calls (the here described TBX API and the creation and listing of customers also)!

Document in Release Notes, that adding TBX Data to existing term collections is working only for collections added after this feature was created. Not for term collections migrated from legacy data.

Supported TBX-tags and attributes of those tags

The tags, that our parser should support for the TBX import are the tags listed inside of

http://www.ttt.org/oscarStandards/tbx/tbx_oscar.pdf

in the sections 8.4 and 8.5. (Please note, that the tags in 8.5 can only occur at tig/ntig-level, while the tags in 8.4 can occur on termEntry and language-level also.

For each tag the specification also lists, which attributes these tags can have.