Strange behavior of xliff 1.2 filter

[Marc Mittag]

Dear all,

I hope very much, that someone can help me here.

I have the attached file

test-for-okapi-mailing-list.xliff

I parse it with the xliff parser settings in Rainbow, that you see in attached image.

Then I get the resulting also attached file

test-for-okapi-mailing-list.xliff.xlf

What is strange for me, is that every segment is doubled.

Instead of 1 trans-unit I get 2 like the example shows:

In input xliff I have:

<trans-unit id="some-id-of-the-xliff-trans-unit" resname="StructureGroupLang.Name">
                  <source xml:lang="de">Test zu übersetzen</source>  
                  <target xml:lang="fr" maxlength="250">Test à traduire</target>
                </trans-unit>

In output xlf I have:

<group id="some-id-of-the-xliff-trans-unit_ssf1" resname="sub-filter:StructureGroupLang.Name">
<trans-unit id="some-id-of-the-xliff-trans-unit_sf1_tu1" resname="StructureGroupLang.Name_1">
<source xml:lang="de">Test zu übersetzen</source>
<seg-source><mrk mid="0" mtype="seg">Test zu übersetzen</mrk></seg-source>
<target xml:lang="fr"></target>
</trans-unit>
</group>
<group id="some-id-of-the-xliff-trans-unit_ssf2" resname="sub-filter:StructureGroupLang.Name">
<trans-unit id="some-id-of-the-xliff-trans-unit_sf2_tu1" resname="StructureGroupLang.Name_1">
<source xml:lang="de">Test à traduire</source>
<seg-source><mrk mid="0" mtype="seg">Test à traduire</mrk></seg-source>
<target xml:lang="fr"></target>
</trans-unit>
</group>

Yet I would have expected in output xlf something like

<group id="some-id-of-the-xliff-trans-unit_ssf1" resname="sub-filter:StructureGroupLang.Name">
<trans-unit id="some-id-of-the-xliff-trans-unit_sf1_tu1" resname="StructureGroupLang.Name_1">
<source xml:lang="de">Test zu übersetzen</source>
<seg-source><mrk mid="0" mtype="seg">Test zu übersetzen</mrk></seg-source>
<target xml:lang="fr">Test à traduire</target>
</trans-unit>
</group>

Does someone know, what is wrong here? Do I miss some setting or is this a bug?

I'm using Rainbow 1.46

Would be great, if someone could help, thank you very much in advance

best

Marc

   

[Chase Tingley]

This is quite strange, I can't reproduce the problem locally with either Tikal or Rainbow, despite trying to recreate your config from the screenshots.

When you defined the custom XLIFF filter config, it should have created a .fprm file somewhere (possibly your home directory) -- can you attach that to the thread?

Also, when I was testing in Rainbow, my pipeline looked like:

- Raw Document to Filter Events

- Rainbow Translation Kit Creation [default options - Generic XLIFF]

Are you doing anything different?

--
You received this message because you are subscribed to the Google Groups "okapi-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to okapi-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-users/c320f7cb-075e-42fe-a982-a28c93250ac8%40marcmittag.de.

[Marc Mittag]

Hi Chase,

thank you very much for looking into this!!!

Attached you find the 2 created fprm files and my pipline file.

Does that clarify your questions?

I modified some paths in the files to not disclose clients data. But the rest is like it is in Rainbow.

best

Marc

To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-users/CAGRYq4ggNE8BBdRRGg%3DoNh99s3GVUz3on7wRdQSt-R48capvJw%40mail.gmail.com.

[Chase Tingley]

Interesting!  This looks like it may be a bug with the pcdataSubfilter option in the XLIFF filter -- I can reproduce with tikal (ie, without your pipeline) using the provided filter configs, but if I clear the pcdataSubfilter option, the bug goes away.

Can you file an issue?

[Sivaji]

Hi ,

Is it feasible to integrate world server with DeepL ...  does it make sense?

Regards,

Sivaji

[Marc Mittag]

Hi Sivaji,

since you also wrote to me directly, I'll answer here and on the list.

I think, yes sure it makes sense, if you use Worldserver. 

Yet I wonder, why you write this question to this list, since the list is about Okapi?

On how to do that or more questions about this I think you would have to ask RWS.

As for us, we at translate5 have deeply integrated DeepL and are using Okapi as filter conversion framework.

If someone is looking for a modern, open source Worldserver alternative, she/he would be right with us. Would be in good company with others, who already switched from Worldserver to us :-)

best

Marc

--
You received this message because you are subscribed to the Google Groups "okapi-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to okapi-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-users/CAMiqQjfWxicyBjt8q-AYeX__ynrM3SEcYwFJkTQrE%2BKaC%2BGwRQ%40mail.gmail.com.

[Chase Tingley]

It's possible this was directed here because there are some wrappers around various Okapi MT connectors to run them through WorldServer's SDK interface:

  https://github.com/spartansw/okapi-worldserver-components/tree/dev/mt

I think DeepL could probably be adapted in this way.

To view this discussion on the web visit https://groups.google.com/d/msgid/okapi-users/3d40bc09-67c1-4224-9651-89f0152f2ad7%40marcmittag.de.