Details
-
Bug
-
Resolution: Fixed
-
None
-
High
-
FIX: Solve Problems with additional whitespace tags from accepted TM matches not being saved / stripped on saving
-
Empty show more show less
Description
When TM matches are accepted in the TM panel / concordance serach, additional whitespace tags in the match are automatically stripped, when the segment is saved.
The reason for this is a quirky architecture of the HtmlEditor.js class:
the prop "markupImages" is used as a cache for converting the internal-tags to image-tags for the editor (markup and unmarkup API, HtmlEditor::insertMarkup and HtmlEditor::setMarkupImages) and at the same time to validate the tags in the tag-check against when saving. This is preventing a proper seperation of concerns and a better solution is needed:
- The reference to compare in the tag check is generally the segment source (for translation tasks) or the target at import-time for review tasks (-> RowEditorColumnPart::loadRecord). Review tasks are those, where at least a number of segments have a filled target in the imported xliff. See corresponding LEK_task flag.
- If not already present, isPretranslated, isTranslation and isReview shorthands shall be added to the task entity (frontend and backend)
- The tag-cache "markupImages" shall be used for conversion/creation of tags only.
- The tag-check shall work on the serialazied reference to compare, not the tag-cache, it also does only check whitespace-tags or special character tags, when the config property untimeOptions.segments.userCanModifyWhitespaceTags is set to false.
- when accepting TM-matches, the inserted markup should have the internal tags ("<1>, <2> ...) replaced with the ones from the tag-check-reference, internal tags not present in the reference shall be stripped, only whitespace and special characters can be added by accepting the match (and thus have to be added to the "markupImages" cache - what should be achieved automatically with "insertMarkup")
Generally, the Tag-Check shall become an own class and independent from the tag-conversion and the "markupImages" cache must always represent the current state of the shown markup in the editor
The new class should be written in a way, that it can still be used with the existing old segment editor, but also with the upcoming new one.
Attachments
Issue Links
- relates to
-
TRANSLATE-3449 Taking matches with tags ignores the tag numbers
- Done
-
TRANSLATE-3487 Taking over fuzzy matches in the UI may lead to corrupted internal tags
- Done
-
TRANSLATE-3582 Change behavior of reference field in editor
- Done
- mentioned in
-
Page Loading...