XLIFF filter (for OmegaT) hides files with DOCTYPE including URL

[Manuel Souto Pico]

Preconditions

OmegaT project containing a translated/bilingual XLIFF for review with has a generic DOCTYPE declaration including the URL to the xliff DTD.

<?xml version="1.0"?> 
<!DOCTYPE xliff PUBLIC "-//XLIFF//DTD XLIFF//EN" "http://www.oasis-open.org/committees/xliff/documents/xliff.dtd">
<xliff version="1.0">
etc...

Expected results

OmegaT’s editor displays the segments in the XLIFF (both source and target). The file appears in the Project Files window (Ctrl+L).

Actual results

No segments are displayed from that file, as if the file was empty, or as if the file had been removed from the project. The file appears listed in the Project Files window.

Additional info

The expected results are achieved when the DOCTYPE declaration (second line above) is removed, i.e.

<?xml version="1.0"?> 
<xliff version="1.0">
etc...

or if the URL is replaced with a local path to the DTD stored locally, e.g.

<?xml version="1.0"?> 
<!DOCTYPE xliff PUBLIC "-//XLIFF//DTD XLIFF//EN" "xliff.dtd">
<xliff version="1.0">
etc...

Reproduced with Okapi XLIFF filter for OmegaT version 1.6-m40 in OmegaT 4.3.0.

‌

[Manuel Souto Pico]

A bit of further input: This issue was reproduced by different users (at least 3 different people testing it independently, in different projects). However, I am unable to reproduce this issue one day later, with the same OmegaT installation and with the same OmegaT project (I don’t think anything has changed in my installation or in the project).

[Manuel Souto Pico]

It seems other users who have reported this problem are not able to reproduce the problem anymore either. I guess it’s now gone until next year…

[Chase Tingley]

Thanks for the investigation. I will close this for now, please re-open if you come up with steps to reproduce.

[Manuel Souto Pico]

Transferred to Okapi-plugin issue #39