Am Monday 25 June 2007 15:11 schrieb Jean-Christophe Helary:
> > A Search and Replace function would be nice - I think there is already a
> > corresonding RFE.
> But this is possible only as far as the translated segment exists, am I
Well, at the moment, it's not possible at all, unless I've missed something.
> > It might also be practical to add two features from the Match window to
the Search window: Ctrl-<number> to select a particular hit, and
Ctrl-I/Ctrl-R to insert it.
> That would be nice indeed.
Lots of things would be nice. :-) The reason I mention this is that I presume
some code could be re-used. But that's only part of the problem. The match
window, like the tag window and the search window, are only viewers. Making
them editable makes them editors in their own right, with the potential for
conflicts with the main editor.
> In fact I like the search window a lot myself (I put a number of RFE already
to add search "flags" that could be used for QA). The only thing I regret is
that it is not editable like the editor window is.
I think we need to think about this more fundamentally. Search functions in
similar text-oriented applications like word processors or viewers are
normally dialogs. What we have a "concordance" function, which is quite
common in CAT tools. This is more like a list of "hits" such as you get in a
search engine. (In fact, the function in OmegaT resembles a search engine in
many ways.) We agree that a Search (and also a Search & Replace) function
would be useful. But I think we should be careful about making the existing
Text Search function more similar to the Search function of a typical word
processor. We could lose benefits in the process.
> What I think would be a really nice feature of OmegaT is to have an
homogenous GUI as far as segment display/editing is concerned in which the
edit window would be the most general "view" of the project contents.
> - the match window would be a "specialized" edit window restricted to
> displaying segments matching contents (with the possibility to edit
> them directly too).
> - the tag validation window would be a "specialized" edit window
> restricted to displaying segments with unmatching tags ...
> - the search window would be a "searchable" edit window with the same
> flags/fields as today (at least) _plus_ the behavior of the edit
> window of which it would only be a different instance.
It would be nice to edit segments in the match and/or search window. But this
effectively means having more than one "active" segment at a time. I am not
sure whether that is easy to implement technically, and even if it is, I am
not sure whether it is good GUI design. I think a lot more thought needs to
be given to this.
> Basically, what I suggested originally here was to add the search functions
of the search window to the current edit window, so that we can promptly edit
repeated mistakes, or similar segments etc.
But there are no "search functions of the search window" (or have I missed
something). The search window, as I see it, *is* the search function. Think
about browsing in Google: you have quite different functions for searching
*within* a document and searching (with Google) *for* documents. I'm not
saying that it has to be that way; just that it's a fairly fundamental design
feature and probably not easy to change.
> Curently is takes time and mousing to use OmegaT for systematic editing:
search on a criteria, click the instance, shift to the editor, edit, return
to the search window, click on the second instance etc... If the edit window
display could be filtered with search criteria we'd only have to edit, enter,
edit, enter: a huge productivity improvement.
Again, this would effectively mean having multiple segments open, OR having an
automated segment closing and opening mechanism.
> _Especially_ since Search/Replace is hard to implement.
I suspect your solution isn't any easier. But I'd be interested to hear what
the developers say.