Details
-
New Feature
-
Resolution: Unresolved
-
None
-
None
-
Medium
-
Empty show more show less
Description
fprm-files
It should be possible to up- and download single fprm files through the UI.
Proposal where to integrate this: Up- and download buttons analogous to those, we have on bconf level in the bconf grid, yet on file format level when editing the filters of a single bconf.
This should only be possible for a cloned filter, because we should not allow to edit the default filters.
This again implies, that it is possible to clone also filters, that are not editable in translate5 so far (which is not the case so far). And then for cloned filters distinguish between those, that are editable in translate5 (the edit icon should be active there) and those, that are not (here only the icon should be editable to assign file formats).
Handling of xliff
For xliff and xlf and mqxliff and mxliff so far in our settings the okapi xliff / xliff2 filter seems to be configured. What is acutally misleading, because it is actually not used and translate5 parses them without Okapi.
This needs to be changed: The file extensions should not be listed there by default anymore, because translate5 parses them without Okapi. Yet if someone enters .xliff as file extension in the filter set for a file format, actually it should be implemented, that in this case an xliff file should be send to Okapi for pre-parsing with this file format filter.
Also so far if we detect, that an xliff file contains cdata, we are throwing an error and stopping the import. This should be changed: If no xliff extension is defined in the file filters and our native xliff parsers normally would be used, but if cdata in them is detected, a specific okapi xliff filter should be used that parses the cdata with the okapi html subfilter (only if this does not require a lot of refactoring. Else: Adjust the error message to point the user to set a specifc xliff subfilter designed by us for these files).
This should be true for all the following extensions: xliff and xlf and mqxliff and mxliff.
Also it should be possible to clone and customize all xliff and xliff2-related Okapi-filters in our UI.
xlf2 and xliff2 file extension should stay configured as they are at the moment in translate5: with the xliff2 parser of Okapi. Because translate5 can not parse xliff2 natively anyway.
=> This part of the Ticket may be implemented by Axel apart of "The file extensions should not be listed there by default anymore, because translate5 parses them without Okapi." At least it should be implemented on the End of the framing "1.4.7 compatibility" Issue
Pipeline
- Up- and download of pipeline files (.pln): Analogous to srx files on bconf level in the bconf grid.
- Be Aware: The edited BCONF is the IMPORT BCONF. It must be made sure, that the uploaded Pipeline has a Extraction and Segmentation Step (see T5-default bconf for reference)
- We may should define the steps, that MUST be in the Pipeline (order!) and that additionally CAN BE.
- Therefore, the Pipeline-validation Part of https://jira.translate5.net/browse/TRANSLATE-4093 must be implemented before
Attachments
Issue Links
- blocks
-
TRANSLATE-3202 Adopt File Format Settings for OpenXML to Okapi version 1.4.7
- Selected for dev
- is blocked by
-
TRANSLATE-4093 OKAPI integration: Compatibility with 1.4.7, editable Pipelines
- Selected for dev
1.
|
BCONF: Add XSLT step to pipeline | Selected for dev | Volodymyr Kyianenko | |
2.
|
Generate Export BCONF from Import BCONF to solve Subfilter-Problem | Selected for dev | Unassigned |