Bug 402838 - Strange placing of spaces while saving multiline strings
Summary: Strange placing of spaces while saving multiline strings
Status: REPORTED
Alias: None
Product: lokalize
Classification: Applications
Component: editor (show other bugs)
Version: unspecified
Platform: Compiled Sources All
: NOR wishlist
Target Milestone: ---
Assignee: Simon Depiets
URL:
Keywords:
Depends on: 380007
Blocks:
  Show dependency treegraph
 
Reported: 2019-01-03 20:17 UTC by Mario Blättermann
Modified: 2023-10-03 06:59 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mario Blättermann 2019-01-03 20:17:57 UTC
SUMMARY

While saving a file, Lokalize behaves some odd in comparison with other translations editors. For all multiline strings (which are dynamically wrapped at 80 characters as usual) a whitespace character gets not placed at the end of a wrapped line, but at teh beginning of the next one.

STEPS TO REPRODUCE

1. Open a po file which has some already translated multiline strings. 
2. Change one of that strings.
3. Save the file.

OBSERVED RESULT

All strings changed by Localize get the whitespaces at the beginning of the line, like in the following string:

#. type: Plain text
msgid ""
"When writing scripts that need to decompress files, it is recommended to "
"always use the name B<xz> with appropriate arguments (B<xz -d> or B<xz -"
"dc>)  instead of the names B<unxz> and B<xzcat>."
msgstr ""
"Beim Schreiben von Skripten, die Dateien dekomprimieren müssen, wird es"
" empfohlen, immer den Namen B<xz> mit den entsprechenden Argumenten B<xz -d>"
" oder B<xz -dc>) anstelle der Namen B<unxz> und B<xzcat> zu verwenden."

EXPECTED RESULT

The whitespaces should be at the end of the lines. The same string as above after launching "msgcat -w 80":

#. type: Plain text
msgid ""
"When writing scripts that need to decompress files, it is recommended to "
"always use the name B<xz> with appropriate arguments (B<xz -d> or B<xz -dc>)  "
"instead of the names B<unxz> and B<xzcat>."
msgstr ""
"Beim Schreiben von Skripten, die Dateien dekomprimieren müssen, wird es "
"empfohlen, immer den Namen B<xz> mit den entsprechenden Argumenten B<xz -d> "
"oder B<xz -dc>) anstelle der Namen B<unxz> und B<xzcat> zu verwenden."

I don't know if it's essential for the compatibility that the files are not fully canonical (in comparison with Poedit or Gnome Translation Editor), but the effect of a basic command line tool like msgcat shows me that it's at least a bit strange. Maybe it could lead to undesired behavior in other environments which parse *.po files.

SOFTWARE/OS VERSIONS 
Linux/KDE Plasma: Kernel 4.20.0 (Archlinux)
KDE Plasma Version: 5.14.4
KDE Frameworks Version: 5.53.0
Qt Version: 5.12.0
Lokalize Version: 18.12.0

ADDITIONAL INFORMATION
Comment 1 Luigi Toscano 2019-01-06 13:46:53 UTC
It's worth nothing that Lokalize showed the other behavior (space at the end of the line) until some version ago, but I'm not sure which version changed the behavior. As translator, I agree that the "space at the end of the line" is closer to whatever could be called a standard version of po files.
Comment 2 needhelp0x 2023-06-25 14:29:18 UTC
*** Removed for violation of KDE Community standards ***