Summary: | Translation Memory searches don't trigger when they should | ||
---|---|---|---|
Product: | [Retired] Zanata | Reporter: | croe <croe> |
Component: | Component-UI | Assignee: | David Mason <damason> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Ding-Yi Chen <dchen> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | jni, sflaniga, zanata-bugs |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | 1.4 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-10-28 07:05:41 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Bug Depends On: | |||
Bug Blocks: | 729533 |
Description
croe@redhat.com
2011-05-09 23:40:03 UTC
Sorry, I don't understand the problem description. I will have to see the problem in action. Please let me know when you see it again, so I can take a look. Corina showed me two different but related problems. 1. When using the Save button to advance (from message A) to the next message B, Zanata does not perform a TM search for the new message B. 2. If user attempts to force a TM search by clicking on the previous message A, then on B, the search is not triggered. Only by clicking a lower message, say C, or a message *above A*, can the TM search be triggered. Clicking on A or B does not trigger a TM search. Note: this bug isn't really about TM, it's about not updating the selected row when we use the Save button. Thus we don't trigger the TM search. Now that we put a border around the selected row, it's easier to see what's going on. This is more serious than I thought, because if the translator doesn't realise what's happening, he or she might click Copy on a "100% match" which isn't really a match at all, because it's a match for a different string. Please ensure that: (a) The selected row updates whenever navigation occurs, whether using Next/Previous, Next/Previous Fuzzy or Untranslated, Save as Approved buttons, or the keyboard equivalents. (b) Whenever the selected row changes by any means, the translation memory updates to show matches for that row. In commit c52e14, i have added a method of selectRow in gotoRow function of TableEditorView.java. I test with Save as approved button and alt+J/K keyboard short-cuts, both working fine and highlight is moved to next row. And I think Translation Memory is refreshed since row selection event will trigger the Translation memory search, but i only test it in WebTrans-Dev mode and test data is limited. Please help to make sure that my implementation is correct, thanks Will test with Keyboard shortcut: 1. Move up/down 2. Move previous fuzzy/ next fuzzy 3. Save as Approved Mouse click. 1. Click 1 then 2 2. Click 4 then 3 3. Use previous/next buttons 4. Use previous fuzzy/ next fuzzy 5. Save as Approved VERIFIED with 1.4-SNAPSHOT (20110824-1328). I tested it again today on two very similar docs: Newsletters TAM & INSIDER translations, where a lot of text is 100% in these two newsletters. The same problem occurs: the Translation Memory does not trigger when it should, exactely with the same problems described earlier. You need to go down in the document and make your way upwards for the TM to trigger which is counter productif to the way a translator operates. I do not believe this bug has been fixed yet. Corina, which zanata version is shown at the bottom of the zanata page? It will be something like "Zanata version 1.X" VERIFIED means that Dean has validated the fix in our test environment. Zanata 1.4 hasn't been released or put into production yet. |