Bug 305612 - Selection of a string from msgid with a line break in Source of TM search results in a string with two spaces
Summary: Selection of a string from msgid with a line break in Source of TM search res...
Status: RESOLVED FIXED
Alias: None
Product: lokalize
Classification: Applications
Component: translation memory (show other bugs)
Version: 1.4
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Nick Shaforostoff
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-22 15:34 UTC by Freek de Kruijf
Modified: 2019-09-01 21:29 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.