-
Improvement
-
Resolution: Unresolved
-
None
-
None
-
Low
-
Emptyshow more show less
- change the export in a way, that
- for repetitions the matchRateType is adjusted accordingly
- all other segment attributes in sdlxliff, Star Transit files and OpenTM2 Xliff are set accordingly. See examples files to evaluate, which attributes are these. For sdlxliff for example conf, origin, origin-system; for Transit for example EDIT_BY, EDIT_FIRST, EDIT_LAST, EDIT_DATE und STATUS
- do that via event-based mechanisms export or in the export/fileparser, so that plug-ins like the matchResources plug-in can optionally hook in.
Current use case:
when using the matchResource plug-in, the content of the segment field matchRateType is changed on using a match as target.
On export the internally used value from matchRateType must be converted to a valid value of the exported data type (sdlxliff etc). This can be done by the above mentioned event hook in.
Please see implementation of T5DEV-40 for example how to solve these issues (in difference to this, the mapped values for the different file types have to come from the matchResource plug-in for good architecture)
- relates to
-
TRANSLATE-421 Generic TM/MT-interface, first connected to openTM2 and Moses-based MT-Systems
- Done
marcmittag The above mentioned concept has one problem: What happens when the match resource plug-in is deactivated before export, then the values won't get translated.
I think better would be some kind of "export segment meta data translation map". This map is reasonable for the converting the matchRateType from the internal value to a valid export file type based value. Other meta data which should be exported in the future can also be handled by this class.
It should be designed that way, that each plugin can add new "map entries" on installation but this values remain in the map until the plugin is deinstalled. When it is deactivated the export will work anyway.