1. Okapi Framework Avatar Okapi Framework
  2. Okapi and localization
  3. Okapi
  4. Issues

"-ERR:PROP-NOT-FOUND-" added after complaining "WARNING: Property 'mtConfidence' not found."

Issue #547 resolved
Wei JIANG created an issue

Hi Yves,

The attached zip package contains the following files: 1. us_sch_html_space.rnb - rainbow setting file, used to normalize target Chinese strings by a pipeline 2, not_confirmed_zho-CN.mqxliff - memoQ xliff to process 3. not_confirmed_zho-CN.HtmlSapce.mqxliff - file processed. "-ERR:PROP-NOT-FOUND-" added in line 67 4. log.txt - the log file.

Hope the above is helpful for debugging.

Kindest, Wei

Comments (9)

  1. Chase Tingley

    Hi Wei,

    What was the input file that went into MemoQ? If it was an XLIFF file produced by Okapi, please attach it.

  2. Wei JIANG reporter

    Hi Chase,

    I think it was an Excel file, that the client imported into memoQ, and then exported part of it as memoQ xliff and send it to me to translate. I have used two Machine Translation plugins - Microsoft Translator and Slate Desktop - from memoQ. And I am not sure if this is related to the missing " mtConfidence".

    I am sorry that I cannot provide more source files.

    Kindest, Wei

  3. Chase Tingley

    Thanks Wei. I think I understand now. I thought this was a file that was first filtered with Okapi and then imported into MemoQ. But it's actually the opposite: the original XLIFF was created with memoQ and then processed in Okapi with your pipeline.

    It sounds like the XLIFF filter is creating a reference to an empty mtConfidence value (which would be stored as a property or annotation, I'd have to check) and then the referenced object is disappearing during the pipeline. We should handle it better than this, since it was data that was never in the file to begin with...

  4. YvesS

    It seems the issue occurs in memoQ's <mq:historical-unit> elements, where you have <source> and <target> elements, which technically are in the XLIFF namespace but should probably not.

    Using XLIFF elements in your own namespace is really not a good idea. One cannot use XLIFF element as extensions, but here they use them as "the extension of an extension", so it passes validation (because we can't validate the extension without their schema). This type of construct can only get you in trouble at some point with some tool.

  6. YvesS

    Well, 'we' (Okapiers) should try to ensure such source and target elements outside where it is supposed to be are ignored. And it's indeed a good idea to point out to Kilgray that such use of XLIFF elements is bound to cause problems.

  10. Log in to comment
Assignee
Type
bug
Priority
major
Status
resolved
Milestone
–
Version
–
Votes
0
Watchers
3
Jira: the preferred issue tracker for Bitbucket. Join the team!