TBO

Hi Franco,

Just noting that the second PO you used is actually a completely separate filetype for PO and it's not an extended version of the out of the box one.

Can you provide a small sample of the orignal source file?  Just edit the one you have and remove eveything apart from a couple of lines, then you anonymise it as needed.  Zip it and attach to your post.

Hi Paul,

That is weird, since I downloaded the PO filetype from the AppStore (https://appstore.sdl.com/language/app/file-type-definition-for-po-extended/868/). From the title, I understood it was the extended version of the already existing PO definition.

Attached you will find a sample of the original source file. I removed everything apart from a couple of lines as advised, since this is a rather large file.

translation_fr (2)_Original - Copy.zip

Please let me know your thoughts regarding its configuration.

Best regards,

Franco Albrecht

TBO said:

From the title, I understood it was the extended version of the already existing PO definition.

That's right - it has more functionality than the original one from SDL.
The most important feature not present in the SDL's file type is loading translations already existing in the PO file... Using the SDL's file type you end up re-translating strings which were already translated... and what's worse, possibly using a (completely) different wording, which won't make the client happy at all.

Right underneath the title you can see that the author is different, it's not SDL.
(I wrote this in my original reply, but it was for unknown reason flagged as spam and nuked :( )

However, it looks like the Supertext's PO file type has a nasty bug - it freaks out on the multiline "msgctxt" strings.
It works fine if the "msgctxt" strings are manually made single-line.
But such editing is hardly acceptable, of course...

So, your only chance right now is the original SDL's PO file type.

The "problem" you mention in your original post - that the translated text "is not correctly placed between the inverted commas" (which is quite amusing term, since these are just a normal quotation marks) - is actually not a problem at all and the file perfectly conforms the PO format specification.

It's actually your client who should implement a fix... since there is nothing wrong with the output - it's just a wrapped multiline string, which is perfectly fine according to the PO format specification.
See http://pology.nedohodnik.net/doc/user/en_US/ch-poformat.html#sec-powrap

TBO said:

From the title, I understood it was the extended version of the already existing PO definition.

That's right - it has more functionality than the original one from SDL.
The most important feature not present in the SDL's file type is loading translations already existing in the PO file... Using the SDL's file type you end up re-translating strings which were already translated... and what's worse, possibly using a (completely) different wording, which won't make the client happy at all.

Right underneath the title you can see that the author is different, it's not SDL.
(I wrote this in my original reply, but it was for unknown reason flagged as spam and nuked :( )

However, it looks like the Supertext's PO file type has a nasty bug - it freaks out on the multiline "msgctxt" strings.
It works fine if the "msgctxt" strings are manually made single-line.
But such editing is hardly acceptable, of course...

So, your only chance right now is the original SDL's PO file type.

The "problem" you mention in your original post - that the translated text "is not correctly placed between the inverted commas" (which is quite amusing term, since these are just a normal quotation marks) - is actually not a problem at all and the file perfectly conforms the PO format specification.

It's actually your client who should implement a fix... since there is nothing wrong with the output - it's just a wrapped multiline string, which is perfectly fine according to the PO format specification.
See http://pology.nedohodnik.net/doc/user/en_US/ch-poformat.html#sec-powrap

Evzen Polenka said:

The most important feature not present in the SDL's file type is loading translations already existing in the PO file... Using the SDL's file type you end up re-translating strings which were already translated... and what's worse, possibly using a (completely) different wording, which won't make the client happy at all.

Hi Evzen,

Can you please detail more about what is the issue in the Studio file type?

From what I can see content that is translated in the PO file is included in the target segment.

I'm not by a machine with Studio now, so can't check at the moment, but...

I'd bet that the original SDL plugin was not able to load the translations already existing in the source PO file... (and I'd bet that this is how at least the Preview function behaves)...
...and that was one of the benefits of the Supertext's PO plugin.

Am I wrong? :-\

Okay, I checked it now and you're right... and I was terribly wrong :(... so I owe you guys a BIG and public apology!

The SDL PO file type does load the existing translations from the source PO file when creating the SDLXLIFF, indeed.

And the preview feature in the File Type settings page behaves the same incorrect way for both SDL and Supertext PO file type - the preview does NOT load the existing translations.

Yes, that was one of the reasons we built the plugin in the first place. But also the possibility to use the PO target as source (it simplified the process for some project we had). And since we built a plugin that could be useful to other Trados users, we put it in the SDL store.

Thank you for the details, I've sent this issue forward to development with ID CRQ-16296.