#918 Search by author/date in translation memories, not in glossaries

[Thomas CORDONNIER]

In the code of the Searcher class we can read the following, in comment:
"Search TM entries, unless we search for date or author.
They are not loaded from external TM, so skip the search in that case."

The phrase "They are not loaded from external TM" was true when it was written (in 2010, accordig to git blame) but now, date and author are stored correctly in the PrepareTMXEntry, so this restriction should not be kept anymore.
On the contrary you did not put the same restriction for glossaries, while in this case dates and authors are not stored, and will probably never be, as most glossary formats do not store them.

Consequences, how to reproduce:

1. do a search in TMs only. Then add a date or author filter and search again ==> result will be empty, even if they are matching results with correct author/date
2. do a search in glossaries. Then add a date or author filter and search again ==> these filters are simply igored
   Expected result : since TMX files correctly store date and author, while glossaries do not, it should be the contrary.

I join the corrections I made for OmegaT 3.6 and 4.1

[Briac Pilpré]

Thanks for the patch Thomas, I'm not sure I agree with the expected result #2 though.
Glossaries will likely never have date/author, so it doesn't make sense to be able to filter these results.
Also, since we currently display the matching glossary results, it would probably be safer to keep it that way to avoid confusing the translator.

(added zipped test project)

[Thomas CORDONNIER]

Short answer:
Yes, I know that you usually like to have a conservative approach. In this case, it is not hard to remove the part about glossaries and apply only the part for translation memories. If you want a new patch like this, please let me know.

[Thomas CORDONNIER]

Long answer: let's try to analyse a little bit the situation.

What we have is a common screen which enables to search in heterogenous set of data sources. Some fields exist in several sources but not in all of them. Then we have two solutions:

1. when an entry does not have a given field, accept the entry. In other terms, ignore the filter in this case
2. when an entry does not have a given field, reject it, as if the filter always answers false.

Actual behavior of the screen is not coherent because you selected solution 1 for glossaries and solution 2 for translation memories.
Of course, now that TM can be filtered by author or date, things can be more coherent. But think about one thing: even if PrepareTMXEntry can store author or date, this is not mandatory - these fields are optional in the TMX specification. So, when an entry does not have author or date, should we keep it or to reject it?

Now you have all the cards in the hand, it is up to you to decide.