Bug in the OpenXML filter for OmegaT (temporary MSO files)

[Jean-Christophe Helary]

There is a bug in the handling of MSO files. It is related to the fact the MSO creates a temporary file when opening an OpenXML file, with a ~$ prefix and a standard "..x" extension, that OmegaT tries to unzip, and fails.

For some reason, even though the file should be handled my the OmegaT MSO filter, it is eventually passed to the Okapi filter that chokes on it, and OmegaT refuses to (re)open the project.

13459: Erreur: net.sf.okapi.common.exceptions.OkapiIOException: Error opening zipped input

The OmegaT filter has fixed that by adding **/~$* to the excluded files list:

https://sourceforge.net/p/omegat/code/ci/c6425108ca4144bb4235eeb97aa1961664dd516f/

Would it be possible to have something similar on the Okapi side ?

--
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

[Chase Tingley]

It sounds like the best place for this fix is in the plugin itself, rather than in the filter.  Once the filter has been told to extract the file, it doesn't really have a way to turn down the operation.

--
You received this message because you are subscribed to the Google Groups "okapi-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to okapi-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-devel/49E406F6-FC9E-4F1F-B58C-D0D2932C7D05%40traduction-libre.org.

[Jean-Christophe Helary]

> On Nov 16, 2021, at 0:31, Jean-Christophe HELARY <jean.christ...@traduction-libre.org> wrote:
>
> There is a bug in the handling of MSO files. It is related to the fact the MSO creates a temporary file when opening an OpenXML file, with a ~$ prefix and a standard "..x" extension, that OmegaT tries to unzip, and fails.

To be more specific, those ~$....(doc)x files are just temporary files that MSO creates when a file is open. The bug happens like this:

- OmegaT has both the native filters and the Okapi filters installed
- OpenXML files are handled by the native filter
- The translator notices something in the source file in the OmegaT interface
- she opens the file in the dedicated MS application
(- the application creates that temporary file)
- the translator modifies and saves the file, but does not close it
- she goes back to OmegaT and reloads
- OmegaT refuses to reload because the Okapi filter cannot handle/ignore the temporary file
- the translator has to close the file, manually reselect the project and reload it

> For some reason, even though the file should be handled my the OmegaT MSO filter, it is eventually passed to the Okapi filter that chokes on it, and OmegaT refuses to (re)open the project.
>
> 13459: Erreur: net.sf.okapi.common.exceptions.OkapiIOException: Error opening zipped input
>
> The OmegaT filter has fixed that by adding **/~$* to the excluded files list:
>
> https://sourceforge.net/p/omegat/code/ci/c6425108ca4144bb4235eeb97aa1961664dd516f/
>
> Would it be possible to have something similar on the Okapi side ?

I've tried to find how to fix that in the Okapi code but it seems beyond what I can do.

I can imagine 3 ways of doing that:

1. excluding OpenXML temporary files (basically those that start with ~$), but Okapi does not seem to have the ignore list that OmegaT does (it looks like it works based on mime type mapping: /okapi/core/src/main/java/net/sf/okapi/common/MimeTypeMapper.java and I have no idea how to tweak that)

2. having the OmegaT plugin filter just *log* the error so as not to keep OmegaT from reloading. That won't fix the issue but it will make OmegaT useable when the 2 filters are used.

3. on OmegaT's side, keep OmegaT from having a file be handled by an Okapi filter if it is already handled by an OmegaT native filter, but that won't fix the issue either.