Bug 274235

i think i will implement it through project overview + translation memory.

this way the search will be faster, at cost of having to keep translation memory up-to-date.

Is the search functionality going to be brought on level with those of kbabel at all? I have 1.1 packaged with the kde 4.5.5.

Kbable's search wasn't overmuch, but it was there and worked. Now, the Lokalize is touted as "more rich in features than kbabel" but managing the real project (like firefox or libreoffice) actually got harder, if at all possible. There's no search over the complete project and no search discrimination by msgid/msgstr/comment (see #233426).

There are other ill-considered changes, like: marking the files is removed, "rough translation" is removed, Lokalize can't import the Kbabel translation database, POTs are included in the Project overview, for whatever reason. But the regression in search functionality is the worst. More so now, as the 3 series support is being phased out from distros, so one can't even use the kdesdk with kbabel.

you can already search the whole project, nailing the search to msgid or msgstr. For this add your project files to translation memory and fire the search in translation memory tab (F7)

marking files can make sense. can you tell me how do you use it usually?

rough translation is there (on a per file basis), based on translation memory (in Tools menu). did you try it?

'POTs are included in the Project overview' what do you mean by that?
as far as i remember kbabel's catalogmanager did include pot files in the (combined) file tree

and to be more specific, what you want is searching in specific files that you've selected (or labeled), right?

As some worthy person told me in #289658 to forget about reviving the Kbabel, I'll put my remarks/wishes here.

W/r to marking (flagging), there were 'set all markings', 'remove all markings', and 'toggle markings' functionalities. Toggling of markings was branch-wise applicable. Markings were retained in project config file.

The markings were possible to use as discriminators in search (e.g., 'marked files only') or in rough translation.

W/r to the POT files inclusion, the Kbabel (catalogmanager app) discriminated between the POT and PO files subtrees, and the UI showed only the PO content. It was convenient to keep POT and PO subdirs together. Now, Lokalize recognises only the root folder of the project, and so automatically picks POT subtree, if it resides there. There is a 'templates folder' concept which is auto-guessed to reside one level up.

The search now doesn't dicriminate by msgid, msgstr, comment, or by their combinations. There now are no options for case sensivity and regexes (and for marked files). There were useful switches for auto-saving the changed file.

The search over the complete (or partial) fileset was accessible instantly, in the obvious place in UI. It worked instantly, without 'adding files to TM' or (re)scanning, background or otherwise.

Rough translation was accessible instantly on branch or on marked subset of a branch.

Kbabel TM (considered together with the historical translations, which might have a value) doesn't seem to be importable. 

I'm using (not using) 1.2 from 4.5.5 set, and also just now compiled and tried lokalize from 4.7.4 sources.

thank you for detailed description of the lacking features.

i still don't get your point regarding PO and POT trees. if you don't want POT files to be shown, just remove path to templates directory in project settings.

everything else i understood, and will implement in the near time (maybe a month).

With regard to the above comment "you can already search the whole project, nailing the search to msgid or msgstr. For this add your project files to translation memory and fire the search in translation memory tab (F7)", I tested to do the specified method, but result is not quite the same as fine/replace using the KBabel catalog manager.
The memory lists the strings and option to open the file, but when you open it, it does not go directly to the string which contains the word searched, therefore you have to do find/replace within the file again.
With KBabel manager, you are able to go directly to the string then allows you to replace, and once that's done, jump to the next string, across different files.

@Nick: Good to hear that. Thank you in advance. I've played with an idea of 'porting' the kbabel to 4 series, but this is too demanding a task for me right now. I'll have to settle for a emulator meanwhile.

@Nick: W/r to your question: I have `templates directory' in project config auto-set by Lokalize to a 'templates' subdir one level up of what my project path is (e.g., /home/yury/templates is made for /home/yury/project), after I set the project path. At the same time,  Lokalize creates and fills 'scripts' subdir in a project path, and this subdir is *not* shown in `project overview'.

If I set `templates files folder' parameter to 'pot' subdir, I do not get my 'pot' subdir to NOT be shown and counted in the overview. What actually happens is that *some* of the subdirs of pot are added to the overview; po and pot subdirs stay where they were.

@Yuko: Thank you for that clarification. I might add that having a search within TM is okay, as is any additional amount of control over TM, only I don't see why the search is accompanied with so much manual operations: 1) adding the file(s); 2) rescanning the TM. The way Kbabel did it (from the translator's perspective), *anything* with fuzzy or untranslated flag removed went into TM, with newest entry getting some small plus priority in suggestions -- and what was wanted *in Kbabel* was sort of quick auto-rescan of TM, for the suggestions for similar text units to pop out in the 'newest' form. How it might look in Lokalize, I can't say, yet.

@Yuri, regarding .pot files in project overview: so try to do exactly opposite: clear the 'templates dir' setting, so that Lokalize won't know where .pot files are.

anyways i don't know why you don't want .pot files to be shown in project overview. it is very convenient because you can see which .pot files have no corresponding .po file.

@Nick: Thanks, I'll try that, later. As to how I would know what POT doesn't have its PO counterpart -- Kbabel would show a red cross instead of checkmark next to a filename. I wouldn't even need to look at POT, anyway.

Have you ever worked with Kbabel?

of course. and the aim of writing Lokalize was to overcome several points that I didn't like in KBabel.

but different people have different usage scenario. for example, translating to Russian i'd rarely want to do global 'unattended' search+replace because same english word can have different translation in Russian (always the same root, but different ending for example)

@Yury: BTW, judging by your name you must be slavic.

if you happen to live in Kiev or in Lviv, or maybe St.Petersburg or Moscow,
we can meet in person.

'Lokalize can't import the Kbabel translation database'
as far as i remember kbabel can save it's database in TMX format. then it can be imported into Lokalize. (Tools->Manage translation memories -> import tmx)

@Nick: 
On TMX: that's right, Kbabel doesn't produce one. But it still has a TM, in a Berkeley DB format (Oracle's now). That was what I'd expect Lokalize to import, it replacing Kbabel and all.

On search+replace: that function I use(d) less often than just a search. However, s+r wasn't unattended in Kbabel, not if you wanted it not to; the decision was left to operator by default. With some understanding of a target language grammar, you could quite speedily traverse a large set, making corrections by a button push (using several passes, case sensivity option, and incomplete words forms as a targets/replacements). Context was visible, so it might be done quite handily.

On what I would like to see in Lokalize, besides the reinstitution of a features we discussed:

Maintaining some sort of meta-information. E.g., there may be, as you correctly point out, different variants of translation for the same original word; sometimes, on technicalities, there *need* to be different variants. All such cases have to be identified somehow, and for this task PO format doesn't offer much facilities. One might maintain external "database" of special cases or put info in PO comments, but that's rather ineffective. 

What would be helpful, now, would be either 1) additional TM, associated with the project, or 2) an enhancement of the search in the "regular" TM (which would anyway need some sort of additional storage). Either way there'll be need to account for (I'm groping in the dark here): "project series" (product translated) and "context". So that encountering the right "context" (e.g., combination of 1) product translated, 2) regex in comment), operator would get an additional suggestion ("translate word A as C, not B, in this context" or "translate as an option name" etc.). Of course, a manual input to such a meta-info storage, and search etc. in it, would be required, too.

Finally, on my place of residence: nope, I live in none of those worthy cities, and in none between those. So personal meeting is rather impossible. :)

*** Bug 274237 has been marked as a duplicate of this bug. ***

FYI: i started coding find-replace-in-files feature, and labeling of files in project overview.

i will be CC'ing here for all commits related.

Oh, thank you.
Any chance of early previews?

SVN commit 1270890 by shaforo:

first round of work on inter-file search (and replace -- in future) feature.
basic searching and navigating found occurences in KBabel style is working (use Win+F3 for this)



 M  +7 -0      CMakeLists.txt  
 M  +1 -5      catalog/catalog.cpp  
 M  +1 -0      catalog/pos.h  
 U             editortab.cpp  
 A             filesearch (directory)  
 A             filesearch/filesearchoptions.ui  
 A             filesearch/filesearchtab.cpp   [License: GPL (v2/3)]
 A             filesearch/filesearchtab.h   [License: GPL (v2/3)]
 A             filesearch/filesearchtabui.rc  
 A             filesearch/org.kde.lokalize.FileSearch.xml  
 M  +51 -7     lokalizemainwindow.cpp  
 M  +7 -1      lokalizemainwindow.h  
 M  +3 -0      lokalizemainwindowui.rc  
 M  +3 -2      main.cpp  
 M  +3 -5      project/project.cpp  
 M  +4 -1      project/project.h  
 M  +28 -0     project/projecttab.cpp  
 M  +3 -0      project/projecttab.h  
 M  +2 -3      project/projectwidget.cpp  
 M  +14 -13    tm/jobs.cpp  
 U             tm/qaview.h  
 M  +13 -1     tm/tmscanapi.cpp  
 M  +4 -2      tm/tmscanapi.h  
 M  +2 -9      tm/tmtab.cpp  
 M  +1 -1      version.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1270890

SVN commit 1270930 by shaforo:


filesearch:
mark matched parts with bold, and fuzzy messages with italics
other small changes and fixes

small string optimizations to avoid redundant mem reallocations



 M  +2 -0      CMakeLists.txt  
 M  +6 -0      catalog/catalog.cpp  
 M  +1 -0      catalog/catalog.h  
 M  +2 -2      catalog/gettext/gettextstorage.cpp  
 M  +11 -0     catalog/phase.h  
 A             common/fastsizehintitemdelegate.cpp   [License: GPL (v2/3)]
 A             common/fastsizehintitemdelegate.h   [License: GPL (v2/3)]
 M  +1 -1      common/languagelistmodel.cpp  
 M  +3 -3      completionstorage.cpp  
 M  +1 -1      completionstorage.h  
 M  +90 -9     filesearch/filesearchtab.cpp  
 M  +12 -1     filesearch/filesearchtab.h  
 M  +14 -95    tm/tmtab.cpp  
 M  +1 -36     tm/tmtab.h  
 M  +14 -11    tm/tmview.cpp  
 M  +3 -2      xlifftextedit.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1270930

Thank you for your effort! 
Now, how to checkout this modified lokalize only, without having to pull the complete kde sources?

http://userbase.kde.org/Lokalize#Compiling_Lokalize_from_KDE_trunk

if instructions are not clear for you don't hesitate to ask

SVN commit 1295550 by shaforo:

implement actual replace in files, no visual feedback yet



 M  +6 -0      catalog/catalog.cpp  
 M  +2 -0      catalog/catalog.h  
 M  +110 -8    filesearch/filesearchtab.cpp  
 M  +9 -4      filesearch/filesearchtab.h  
 M  +1 -0      filesearch/filesearchtabui.rc  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1295550

SVN commit 1295973 by shaforo:

add some ui feedback about replacing, fix small mistake

please test




 M  +14 -4     filesearchtab.cpp  
 M  +4 -0      filesearchtab.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1295973