Description of problem: Down Under Translation Memory
After I translated the Insider Newsletter doc on Zanata/Engineering (internal), I noticed that some strings I just translated on the previous doc (TAM Newsetter), and that were according to'MY (human) memory' 100% matching, did not come up as suggestions in the TM (Translation Memory).
So I intuitively clicked on strings below and came back on my current upper string I was working on, then I noticed 'the suggestion' coming up in the TM. So I clicked on copy, and it worked!
This was quite 'boring' process after a while, so I tried to translate starting from the END of the document = starting with last string to be translated, and then there was no problems at all, all suggestions came up as they should, except it was DOWN UNDER (the other way round).
Could we please fix this bug so that we can have suggestions in TM coming from the top from now on, because so far, translators have missed out on the benefits of the TM capabilities.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Expected results: Fonctional TM
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
Fixed in https://github.com/zanata/zanata/commit/9612a3ba2ee67f9864c41b4df14a48c69bb39df4
Will test with
1. Move up/down
2. Move previous fuzzy/ next fuzzy
3. Save as Approved
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.