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

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!

Hello

We'll have a look at this as soon as possible, but since this plugin is provided for free, it's not on top of our priority list.

But you just got lucky:

https://github.com/Supertext/Supertext.Sdl.Trados.FileTypes

With a little effort you can fix it yourself.

I don't have C# environment to try it, but I believe this simple fix should be it:

Line 33 in Supertext.Sdl.Trados.FileType.PoFile/Parsing/LineParser.cs

msgctxt
    .CanBeFollowedBy(msgid);

msgctxt
    .CanBeFollowedBy(text)
    .CanBeFollowedBy(msgid);

I'll forward it to the developer. Maybe he has a minute

You can download VS for free:

https://visualstudio.microsoft.com/vs/express/?rr=https%3A%2F%2Fwww.google.com%2F

Hi Evzen

thanks for having a look at the code.

Here is a version of the plugin with that fix.

https://blog.supertext.ch/wp-content/uploads/sdltradosplugins/po/1.6/unsigned/Supertext.Sdl.Trados.FileType.PoFile.sdlplugin

Could you please confirm that it is working for you?

Hi Evzen

thanks for having a look at the code.

Here is a version of the plugin with that fix.

https://blog.supertext.ch/wp-content/uploads/sdltradosplugins/po/1.6/unsigned/Supertext.Sdl.Trados.FileType.PoFile.sdlplugin

Could you please confirm that it is working for you?

Heinrich Muralt said:

Could you please confirm that it is working for you?

Partially... ;-)

It now successfully parses the file from this thread and does not freak out anymore... so that's a progress.

But the multiline "msgctxt" strings are not added to the Document Structure Info - only strings with single-line "msgctxt" have the "Context information" added (these are marked as F+ in the DSI column).
See the screenshot below.

EDIT:
Perhaps some addirtional changes in the LineParser.cs are needed... like in the "text" section - something like

                .After(msgctxt)
                .CanBeFollowedBySameAs(msgctxt)

It's really hard to say for someone who is not author of the code, since the philosophy of the code is hard to understand... there are no comments, nothing...

And BTW, I also noticed another issue - the generated target file does not honor the linebreaks type of the source file.
For example, this source file has Unix linebreaks (LF), but the target file is generated with DOS/Windows linebreaks (CRLF).

Hi Evzen

thanks for you feedback. 

Those changes you mention are needed as well but and actually already included in that test version. What's missing is the text collection for a message context entry in the EntryBuilder. I'll add that.

As for the comments: I agree that some documentation about the architecture and concept should be added to the project/ in the Github repo. That is actually on my todo list.

Evzen Polenka said:

the generated target file does not honor the linebreaks type of the source file.

ok, we can add that.