pyg3t / poproofread

GNU General Public License v3.0
0 stars 0 forks source link

Wish: Search in file #9

Open KennethNielsen opened 9 years ago

KennethNielsen commented 9 years ago

In order to do a good proofreading of a po-file, you cannot look at each translation isolated.

So I am missing a function to search in all msgid fields for a certain term to see both how it is used other places to get a better idea of the context/meaning of the term, and to check that the translation of the term is consistent.


Imported from Launchpad using lp2gh.

KennethNielsen commented 9 years ago

(by k-nielsen81) This sounds like a good idea (but also a slightly more complicated one).

I have been thinking about how to implement it "widget wise". I would really prefer not to have a separate search window, as I think those always get in the way, so I would prefer to go with some sort of search line (that pops up and disappears). It would be neat if it was floating in the right corner, the way it is done e.g. in ff, chrome and gedit, however a little research says the the proper way to do these overlaying widgets is with the GtkOverlay widget of GTK+3, and I'm looking to move it to GTK+3 just yet. For Gtk+2 there is the GtkFixed, but that comes with all sorts of warnings and apparently have been used with varying degrees of success.

From a more function stand point I was thinking of letting the search work (and highlight) in both windows (there could also be a toggle button for whether the search should work in the comment window also). One open question is how to handle moving through search hits. I was thinking, that it would simplify the implementation a lot, if when jumping to the next search hit, you jump to the next diff chunk that has a hit, instead of to the next hit within the current chunk. The downside is that you might not see a hit if it is located at the bottom of a very long string. On the other hand I think those cases are rare enough that it might be ok. And for all the strings that are not to long, it would probably give a more natural experience, since you commonly want to quickly just see all the diff chunks that corresponds to your search.

IMPLEMENTATION NOTE TO MYSELF: The dynamic updating of the searches will require listening for keypresses. This could also be used to implement save functionality in the way that it is usually done i.e. keeping track of whether the current state is saved. This should be thought into the implementation.