Simon what do you think about this?

In D10009#303703, @aacid wrote:

Simon what do you think about this?

I've just "rebased" the patch because I fixed an issue with the wordwrap already in the same file.
I need more context to understand what exactly is the issue with the current behavior to begin with. Do you have specific examples ?

With this patch this is the behavior that I see (it removes all line breaks in source and target), which seems rather unwanted in that situation.

-msgid ""
-"<center>This investment account does not contain the \"%1\" security.</center>"
-"<center>Transactions involving this security will be ignored.</center>"
-msgstr ""
-"<center>Ce compte de placement ne contient pas le titre « %1 ».</center>"
-"<center>Les opérations impliquant ce titre seront ignorées.</center>"
+msgid "<center>This investment account does not contain the \"%1\" security.</center><center>Transactions involving this security will be ignored.</center>"
+msgstr "<center>Ce compte de placement ne contient pas le titre « %1 ».</center> <center>Les opérations impliquant ce titre seront ignorées.</center>"

It has been more than a year. Should we close this and https://bugs.kde.org/show_bug.cgi?id=380007?

We never got a proper explanation of what this does or how it works.

The person that submitted it never answered any question.

I'd say abandon this.

May be the original author is not following Phabricator. You can try and ping him in the bugs.kde.org report or by email.

Can you share a .po file where this makes a difference?

And also can you provide a better description of what it does as a commit message? Because "Improvements for Gettext entries wordwrapping" is as generic as it gets.

In D10009#611209, @aacid wrote:

Can you share a .po file where this makes a difference?

And also can you provide a better description of what it does as a commit message? Because "Improvements for Gettext entries wordwrapping" is as generic as it gets.

Here example from one of my translation projects. I have properly formatted by msguniq dable.dlg.po - o dable.dlg.po file
First commit with unpatched lokalize:
https://github.com/winterheart/planescape/commit/72ae2d06b479e3e5ed8ea5e36ab5458806d094e2

Notice that I didn't made any meaningful changes to message, I only pressed Ctrl-i on active translation (remove newlines from translation) and saved file. Expected result is no changes on entry, but lokalize wrapping message incorrectly. Notice that how word wrapping adds leading spaces on each newline in message.

Second commit with patched lokalize right after unpatched commit:
https://github.com/winterheart/planescape/commit/47003b033239a260f4a286f6406594f2d5ae8477

Now lokalize wraps message correctly.

Why this is big deal? When translation being updated, usually there msgmerge command are involved that by default word wrap messages with gettext's wrap() function (https://github.com/autotools-mirror/gettext/blob/master/gettext-tools/src/write-po.c#L616). If PO-file is not word-wrapped correctly, updated file will have lots noisy and pointless changes related to wrapping, and worse - this goes to git history. This make difficult to developer and translator to see real difference. Other scenario - when two translators uses different tools to translate - say lokalize and poedit. poedit uses wrap directly from msguniq (calls it on save), and again - lots of noise and pointless changes.

gettext's wrap() function is bit complicated and has lots of legacy code and portable inlines, but key of algorithm is using libunistring's tokenizing by finding possible line breakers. Since in Qt 5 this can be done a lots easier, so I implemented tokenizer based on QTextBoundaryFinder with QTextBoundaryFinder::Line boundary detector.

When you say "incorrectly" you mean "not like i like it" or "not like gettext creates", right?

The file is just as valid, isn't it?

It may be valid, but the "standard version" produced for example by msgfmt is the one where the spaces are at the end of the line, not at the beginning.
It is worth noting that KBabel first and Lokalize later, up to a certain version which I don't remember, did produce the "properly" formatted version.

IIRC scripty reformats the messages too (as it uses msgfmt), so IMHO using the same format would be useful.

Sure, i agree producing similar formatting to those of other tools is good.

I just want to clarify if we're actually speaking of "incorrect" or just of "different"

I moved this patch to GitLab: https://invent.kde.org/sdk/lokalize/-/merge_requests/60

I will try to check it according to the comments made here.
Feel free to also comment on GitLab.