Wrong handling of bilingual PO files on creation of an OmegaT Project

[Former user]

Original issue 328 created by [e-mail] on 2013-04-23T16:16:29.000Z:

What steps will reproduce the problem?
1. Add bilingual PO files to rainbow (part wise or fully translated)
2. Translation Kit Creation...
3. Select "package type" = OmegaT Project

What is the expected output? What do you see instead?
xlf files will be created. However msgid is always identical to msgstr (source=target), although there are existing translations in the source po files. I would expected the existing translations to be in the msgstr. This only happens when creating an OmegaT Project. If I create an Generic XLIFF package, it seems to work:

Generic XLIFF (right):
<trans-unit id="1" resname="NF0C38BE2" approved="yes" xml:space="preserve">
<source xml:lang="en-gb">Online Help</source>
<target xml:lang="de-de">Online-Hilfe</target>
</trans-unit>

OmegaT Project (wrong):
<trans-unit id="1" resname="NF0C38BE2" approved="yes" xml:space="preserve">
<source xml:lang="en-gb">Online Help</source>
<target xml:lang="de-de">Online Help</target>
</trans-unit>

What version of the product are you using? On what operating system?
6.0.21, Windows 7

Please provide any additional information below.
PO file content:
msgid "Online Help"
msgstr "Online-Hilfe"

[Former user]

Comment 1. originally posted by @ysavourel on 2013-04-23T16:34:33.000Z:

When creating an OmegaT project, the XLIFF document created has always a copy of the source text in the <target> element. This is because the native OmegaT filter for XLIFF expects the text to be there.
If there is a corresponding translation, it is placed in the project_save.tmx file in the omegat sub-folder.
If you open the project you'll see the translation for the given segment.

[Former user]

Comment 2. originally posted by [e-mail] on 2013-04-23T17:52:50.000Z:

Thanks for your quick reply.

The only strange thing is that OmegaT finds a lot of orphan segments. This causes segments to be identified as not translated, although project_save.tmx has the corresponding translation.

project_save.tmx:
<tuv lang="en-gb">
<seg>Found Version <x0/></seg>
</tuv>
<tuv lang="de-de">
<seg>Gefundene Version <x0/></seg>
</tuv>

Corresponding xlf file created by Rainbow (Package type = OmegaT):
<trans-unit id="2" resname="NC602ACD6" approved="yes" xml:space="preserve">
<source xml:lang="en-gb">Found Version <x id="1" ctype="x-regxph"/></source>
<target xml:lang="de-de">Found Version <x id="1" ctype="x-regxph"/></target>
</trans-unit>

OmegaT says (also see screenshot)
1) Found Version <x0/>
Gefundene Version <x0/>
<100/100/60% Verwaiste Segmente>

Is this a bug by Rainbow, by OmegaT or am I doing something wrong?

[Former user]

Comment 3. originally posted by @ysavourel on 2013-04-24T15:31:39.000Z:

[Former user]

Comment 4. originally posted by @ysavourel on 2013-04-25T21:39:49.000Z:

One possible cause for this is that OmegaT is set to segment by default. So the source entry get segmented, but the translation is not.
Pre-translated PO files should be left un-segmented.

[Former user]

Comment 5. originally posted by [e-mail] on 2013-04-26T06:43:44.000Z:

Segmentation in switched off in OmegaT and is not applied within Rainbow.

file "project_save.tmx":
<tu tuid="1_s0">
<tuv xml:lang="en-gb"><seg>File: <ph x="1"><x0/></ph></seg></tuv>
<tuv xml:lang="de-de"><seg>Datei: <ph x="1"><x0/></ph></seg></tuv>
</tu>

folder "source":
<trans-unit id="1" resname="P660F82FA" approved="yes" xml:space="preserve">
<source xml:lang="en-gb">File: <x id="1" ctype="x-regxph"/></source>
<target xml:lang="de-de">File: <x id="1" ctype="x-regxph"/></target>

folder "original":
msgid "File: {0}"
msgstr "Datei: {0}"

It seems that project_save.tmx includes an additional "<x0/>" which should be "<x0/>" in plain text, while the source does not.

Does this help to carify?

[Former user]

Comment 6. originally posted by @ysavourel on 2013-04-29T13:31:44.000Z: