Save analysis from xliff

Read the match rate passed in the xliff from across.xliff (and for consistency other xliff, Trados, MemoQ) and write it into translate5 as an analysis. This functionality can be enabled or disabled by task import specific config.

If the word count column in the task/project grid is visible or not, is decided by customer specific config. By default the column is visible.

In case we need possibility to switch between different analysis, we must implement this https://jira.translate5.net/browse/TRANSLATE-2174 feature.

Use case: The use case is for review tasks only, so there will not be the need to extract this analysis from a "mixed" import with a) bilingual translated xliff and b) untranslated monolingual other files at the same time. If such a case is detected, no analysis from xliff is provided. If not match rate information can be extracted from the files, this should be mirrored in the analysis or in some output/information to the user.

• Update: After talking with Thomas regarding this, we decided that we will only check if there was matchrate detected for the segment after import no matter the  file type. For segments where no matchrate was detected we will write 0 matchrate in the analysis.

Technical concept

Back-End

• new Task-import specific config: readImportAnalysis
• new client specific config: hideWordCount column
• new worker to generate analysis out of segment matchrate from the imported segments. Important: this worker should run before translate5 resource analysis. We want the analysis generated from the translate5 resources be the last one after the import so it can be visible for the user

Front-end

• Because the config for hiding the wordCount column in customer specific, the state of the column is checked with task is selected in one of the overviews. For PM users we have the customer config store in the UI, but for non pmusers, this information is not available. Which means, we will need to pass the flag as separate value in the tast-get response, and use it from there to manage the column state. This param is UI only and should not go in the regular API response