Version: 0.3 (using KDE 4.2.2) OS: Linux Installed from: Ubuntu Packages 1. If I call Search function from menu "Find... (Ctrl + F)" then I can search in message tree, its OK. 2. But if I call Search function by pressing keyboard shortcut Ctrl+F or F3 (as shown in menus) then I can search only in active field eg. "source" or "target". Search scopes of methods 1 and 2 differs (also differs "Search" dialogs). So I think that "Search" called from menu and with keyboard shortcut must be same and they must search in message tree.
i cannot confirm this. is there any special detail regarding your configuration? can you try reproducing this on another PC?
I have updated my fedora 10 64 bit today. I've got lokalize version 0.3 on kde 4.2.2 I don't have any special configuration, I try to use lokalize with another new user account on my fedora but the problem remain. Seems there are two different function or interface for search text. Exactly like Valdas.
> I have updated my fedora 10 64 bit today. does it mean the bug wasn't there before the update?
wow, I just started lokalize compiled by debian and it shows the bug. i guess the problem is caused by http://websvn.kde.org/?view=rev&revision=933013 commit. i'll fix the problem in few days...
(In reply to comment #3) > > I have updated my fedora 10 64 bit today. > does it mean the bug wasn't there before the update? Yes, the previus version (package kdesdk 4.2.1) don't have this problem.
yeah, the temporary solution for you is to revert _kdelibs_ to 4.2.1
(In reply to comment #6) > yeah, the temporary solution for you is to revert _kdelibs_ to 4.2.1 Thank you, I'm working with new version so I can report other bugs if I'll find them. P.S. sorry for my bad English.
SVN commit 965007 by shaforo: -allow adding scripts by dropping them onto treeview in project settings -remove redundant code -fix ctrl+f issue BUG: 188867 M +3 -6 cataloglistview/cataloglistview.cpp M +1 -2 cataloglistview/cataloglistview.h M +2 -10 cataloglistview/catalogmodel.cpp M +3 -3 cataloglistview/catalogmodel.h M +12 -2 editortab.cpp M +2 -1 editortab.h M +3 -1 lokalizemainwindow.h M +21 -2 prefs/prefs.cpp M +16 -1 prefs/prefs.h M +6 -0 xlifftextedit.cpp M +3 -0 xlifftextedit.h WebSVN link: http://websvn.kde.org/?view=rev&revision=965007
Was this backported to 4.2.x?
no. i will if there is a 4.2.4 release.
*** Bug 196741 has been marked as a duplicate of this bug. ***
This hasn't really been fixed yet in 4.2.4-1, has it? Debian package too. I can press Ctrl-F and search for «Projekt» lokalize doesn't find anything. With the Search button or via the menu it's working fine.
no ;) upgrade to 4.3rc from experimental, it works fine.
Okay, glad to hear that :) I'll wait for 4.3 getting in sid/testing, but thanks for the information!
this bug still exists in 4.3.80 release
are you using the standard shortcuts? (ctrl+f, ctrl+r)
I am using Fedora development version 13. I used to select random word from mouse and press ctrl+f this will pick same word and show in Find dialog box. but when used F3 to again search same word, I see random characters around this word are selected but not the word itself.
does it happen on all files, or some specific one? I couldn't reproduce this behaviour on KDE-4.3 + lokalize-trunk. (I'm waiting for debian 4.4rc packages in experimental)
I have tested 4.3.80 KDE packages and seems still not working global search and replace in lokalize. I observed that in kate and kwrite I can easily search and replace non-English words. But same is not happening in lokalize. Its searching near actual words in text and placing cursor near that word but not highlighting actual words found.
I have created some screenshots and po file I tested which can be downloaded from http://paragn.fedorapeople.org/kde-work/lokalize/
Nick, If above information is not sufficient then please ask for more input for this problem.
Created attachment 39208 [details] mr glitches please try global-searching in European translations (e.g. http://websvn.kde.org/*checkout*/trunk/l10n-kde4/en_GB/messages/kdelibs/kdelibs4.po) i think it is a problem specific for your language (I opened your file and saw glitches - sometimes there is a circle between each letter, and sometimes not). in this case please elaborate on the difference between kate searching behavour and lokalize one (with screenshots).
I see that KDE packages needs some coding where language specific rules are needed to be written. Recently, I helped upstream to understand Indic spell checker problem and they fixed in http://websvn.kde.org/?view=revision&revision=1056377 so which kdelibs version are you using? dotted circle is used for forming a composed character( combination of more than one unicode characters). After using above svn patch we got lokalize working fine without showing dotted circle for Indic scripts. If you are using latest kdelibs then please do tell me and I will investigate further and give you some more screenshots.
no, its kdelibs 4.3.4 from debian. maybe improper found-word selection has something to do with those zero-length characters? see EditorTab::highlightFound in http://websvn.kde.org/trunk/KDE/kdesdk/lokalize/src/editortab_findreplace.cpp?revision=1049744&view=markup
I have updated some more screenshots at http://paragn.fedorapeople.org/kde-work/lokalize, please have a look at kate-4.3.4-press-f3-again-7th-times.png and lokalize-4.3.4-press-f3-again-7th-times.png. This is also one testcase to show how searching is failing for Indic scripts. Also updated screenshots for how to select word that I selected from mr.po file which is second string in it. see kate-4.3.4-initial-selection-of-word-press-ctrl-f3.png and lokalize-4.3.4-initial-selection-of-word-press-ctrl-f3.png
oops sorry initial word selection file names corrected by replacing f3 to f.