Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 1077439 - RFE: Use lucene indexes to do Copy Trans.
RFE: Use lucene indexes to do Copy Trans.
Status: CLOSED CURRENTRELEASE
Product: Zanata
Classification: Retired
Component: Component-CopyTrans (Show other bugs)
3.3
Unspecified Unspecified
unspecified Severity medium
: ---
: 3.4
Assigned To: Alex Eng
Zanata-QA Mailling List
:
Depends On:
Blocks: 1088122
  Show dependency treegraph
 
Reported: 2014-03-17 22:47 EDT by Carlos Munoz
Modified: 2014-07-17 02:39 EDT (History)
7 users (show)

See Also:
Fixed In Version: 3.4.0-SNAPSHOT (git-server-3.3.1-244-gcebf76a)
Doc Type: Bug Fix
Doc Text:
Story Points: 8
Clone Of:
Environment:
Last Closed: 2014-07-17 02:39:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Carlos Munoz 2014-03-17 22:47:25 EDT
Since TM merge is already using the underlying indexing to find translation matches, copy trans should use the same to have a single place where this is happening. At the moment, having two implementations for what is essentially the same feature is giving us issues, specially when users expect their TM matches to be the same was what copy trans has copied.
Comment 1 David Mason 2014-03-18 21:32:02 EDT
This is combining the backend for CopyTrans and TM Merge.

Concerns about how obsolete documents will be handled - CopyTrans doesn't ignore them at the moment, TM Merge does.

Hash column could still be used for 100% matches (currently only used by copytrans.

# Testing

Will need to make sure test data is indexed before tests are run.

Could test different aspects separately:

 - test that indexes can be generated properly
 - test that indexes are used properly during searches
 - test that indexes are updated when new data is added
Comment 2 Carlos Munoz 2014-03-19 01:02:28 EDT
Secondary: camunoz@redhat.com
Comment 3 Ding-Yi Chen 2014-03-28 01:40:46 EDT
The test should also cover CJK languages, both Han character and punctuation, as we did have bugs on lucence search with CJK before.
Comment 4 Sean Flanigan 2014-03-30 21:16:44 EDT
(In reply to Ding-Yi Chen from comment #3)
> The test should also cover CJK languages, both Han character and
> punctuation, as we did have bugs on lucence search with CJK before.

Thanks.  Do you know the bug numbers?  We should make sure we have tests.
Comment 5 Sean Flanigan 2014-04-07 22:17:49 EDT
Development branch is here: https://github.com/zanata/zanata-server/commits/rhbz1077439
Comment 6 Ding-Yi Chen 2014-04-15 22:16:12 EDT
I don't think it is recorded in Bugzilla, it was discovered in Translate Editor search and fixed straight away when it was discovered. 

Yet I can come up with some test cases like:
"性": U+6027 CJK UNIFIED IDEOGRAPH-6027, -ity, nature, character
"。": U+3002 IDEOGRAPHIC FULL STOP
"、": U+3001 IDEOGRAPHIC COMMA (Used to separate items in list)
Comment 7 Sean Flanigan 2014-04-15 22:34:55 EDT
Pull request is here: https://github.com/zanata/zanata-server/pull/418

Although Hibernate Search/Lucene is indexing the translated contents, we won't be using those fields in the CopyTrans query.  So those CJK characters shouldn't give us any trouble unless they appear in source contents.  (And right now we are querying by contentHash, which doesn't care about CJK-compatible Lucene Analyzers.)
Comment 8 Alex Eng 2014-04-30 20:36:25 EDT
Pull request:
https://github.com/zanata/zanata-server/pull/418

We've implemented lucene search for Copy Trans (same as TM Merge) but disabled at the moment due to performance. This pull request now is mainly for refactoring of unit test.
Comment 9 Damian Jansen 2014-05-05 00:32:24 EDT
Verified

Note You need to log in before you can comment on or make changes to this bug.