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

I think Evzen has answered this in a more complete manner than I could have done.  The only thing I'd clarify is the msgctxt comment in case it's not clear.  Writing this:

msgctxt ""
"{\"checksum\": 3509901753, \"cxt\": \"question_required\", \"id\": "
"1975836929}"
msgid "This question requires an answer."
msgstr "Cette question nécessite une réponse."

like this:

msgctxt "{\"checksum\": 3509901753, \"cxt\": \"question_required\", \"id\": " "1975836929}"
msgid "This question requires an answer."
msgstr "Cette question nécessite une réponse."

resolves the "problem" as you perceive it in both the SDL and Supertext filetype but as mentioned this is most likely not acceptable.  I'm not clear on how this file should be handled however and can't find a clear example in the specification on the use of multiline msgctxt.

I'd like to log this with development for review but could use some help on how this should be correctly handled.  The preview shows this:

I'm thinking, because of the multiline msgctxt, it should either be this:

msgstr "Cette question nécessite une réponse."
"new translation in here"

or this:

msgstr "new translation in here"
"Cette question nécessite une réponse."

But I'm really not sure.  Any guidance gratefully received along with some clarification of why it should be a particular way according to the PO specfication.

Paul said:

can't find a clear example in the specification on the use of multiline msgctxt

That's actually very simple - the "msgid", "msgstr" and "msgctxt" strings may be wrapped to multiple lines, each starting and ending with quotation mark.
It's up to the writing application whether it wraps the line or not. The wrapping is applied purely for visual convenience.
And the consuming application should unwrap the line.
(And for the sake of completeness, no other strings may be multiline!)

It means that the yellow highlighted construct on your screenshot is totally unneeded and unnecessary, but still okay and perfectly valid.

Your "new translation in here" examples are actually both incorrect because the "msgstr" - the entire string, possibly multiline - is the target... there is no "new translation on first or second line", the entire string is the translation.

So it should simply be written like this as there is no setting to determine when a wrap should be applied and even the suggested limit (column 80 I think) doesn't apply here?

msgstr "Cette question nécessite une réponse."

If having a multiline msgctxt is irrelevant to the lines used in the msgtr Studio should ignore the fact they are wrapped altogether, other than to display them in the preview?

Yes to both ;-),as far as I know.

The wrapping in produced file is purely voluntary (though, as the Pology mentions, majority of applications follow the original wrapping).

Evzen Polenka said:

The wrapping in produced file is purely voluntary (though, as the Pology mentions, majority of applications follow the original wrapping).

So we should have done something like this:

msgstr ""

""

""

"Cette question nécessite une réponse."

I guess we didn't even do it wrong right ;-)

Why the empty lines? They are not necessary (though they are not wrong, since they will be simply ignored after unwrapping the entire line).

The format of "msgctxt" is unrelated to the source (i.e. "msgid") and target (i.e. "msgstr") strings. It's just a context information - something what further explains the meaning of the string.

My understanding of "following the original wrapping" is that

• lines not changed by the application (i.e. "msgid" and "msgctxt") are kept as they were
• lines changed by the application (i.e. "msgstr") are wrapped at the column determined from the wrapping present in the source file

I suppose that following the practice of POEdit would be perfectly okay. It's just a matter of asking the POEdit author, I guess ;-).

I was kidding Evzen... enjoy your Saturday!