Bug 305612

Summary: Selection of a string from msgid with a line break in Source of TM search results in a string with two spaces
Product: [Applications] lokalize Reporter: Freek de Kruijf <freekdekruijf>
Component: translation memoryAssignee: Nick Shaforostoff <shafff>
Status: RESOLVED FIXED    
Severity: normal CC: adrian
Priority: NOR    
Version First Reported In: 1.4   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Freek de Kruijf 2012-08-22 15:34:36 UTC
I am translating from branch docmessages kdenetwork kopete_jabber.po. msgid #51 reads:
Finally, there are some privacy configurations in the tab <guilabel>Privacy</
guilabel>, they are mostly self-explanatory. The option <guilabel>Use old 
inline PGP format for signed and encrypted messages</guilabel> (read here 
what <ulink url="http://en.wikipedia.org/wiki/Pretty_Good_Privacy">PGP</
ulink> means) is not recommended, because there exists a method to do this 
with the built-in OTR, which will be explained <link linkend="useful-
configuration-hints">later in this tutorial</link>.
I select from "Use old" till " messages" and open TM via F7 and insert in the text field Source, by clicking with the middle mouse button, this selected text. After that I activate Wildcard and click on Search. Nothings appears. It turns out that there are two spaces between "old" and "inline".
Removing, what looks like a space, in front of "inline" and pressing Search produces the expected result. However removing, what looks like a space, after old" and pressing Search does not give any result.

Reproducible: Always

Steps to Reproduce:
1. probably one needs to have that specific string translated in messages kdenetwork kopete.po and in TM


Expected Results:  
The search should succeed the first time without the removal of what looks like a space in front of the word "inline". 

This may be related to what is shown in the subwindow Alternate Translations, where line breaks which differ from a previous translation are shown as lightblue (inserted) or pink (removed) spaces. In fact there is no difference at that point. These spaces are not in the po file, only msgstr has been broken up at different positions. This is also present in 1.2. I never bothered to report it.

BTW. Searching for Alternate Translations, shows also the use of the term Alternative Translations. I have the feeling that the same term should be used. I am not sure both terms are the proper terms. Maybe Previous Translation is a better term.
Comment 1 Adrián Chaves (Gallaecio) 2019-09-01 20:04:52 UTC
I can search for two spaces with the latest Lokalize. In fact I can search for “*  *” (asterisk, space, space, asterisk) to find all strings with at least two spaces in a row.

I’m not sure if that means that this issue has been fixed, I’m not sure I fully understood the steps to reproduce. Could anyone confirm whether or not we can consider this fixed?
Comment 2 Freek de Kruijf 2019-09-01 21:29:28 UTC
Checked the .po file and things appear to be fixed. Resolved.