Version: (using KDE 4.4.1) OS: Linux Installed from: Archlinux Packages It would nice and smart if lokalize could support a better translation memory in case tags, like <p></p>, <br>, <i></i>, etc. If I've got an expression like 'Helloworld' in the translation, and if I try to use ctrl+1 (this translation from the translation memory) for a <b>Helloworld</b> like tag, it won't do completely well the target string, just check it, thanks in advance!
Created attachment 73917 [details] Testcase 1. I could reproduce the steps: 1. Download the test.po file attached. It contains to source translation units: “<p>Helloworld</p>” and “Helloworld”. 2. Make sure Lokalize is configured to use the translation memory upon opening files. Mark all the options in “Settings → Configure Lokalize… → Translation Memory”, and click “OK”. 3. Open the file from your file browser with Lokalize. 4. Translate the first translation unit. In my case: “<p>Helloworld</p>” → “<p>Ola, mundo!</p>”. 5. For the second translation unit, “Helloworld”, the Translation Memory widget should show a match, generated from the translation we performed during the previous step. So, press Ctrl+1 to use that translation. Expected results: “Helloworld” → “Ola, mundo!”. Actual results: “Helloworld” → “p>Ola, mundo!”. I will look into it, but I can’t promise anything (little programming experience, none whatsoever with Lokalize’s source code).
Created attachment 73919 [details] (Dirty) temporal workaround. I’ve created a temporal workaround, but I still could not figure out what the root cause is. The deepest I have got was to “tm/tmview.cpp:701”, where “entry.target.tags.size()” should be “true”, but it turns to be “false”. As a result, “tryMarkup” is also set to false, and everything gets screwed. By the way, in the steps above, the actual result is actually “p>Ola, mundo</p”. I had translated “<p>Helloworld</p>” as “<p>Ola, mundo!” by mistake.
I failed to find the code where the “entry.target.tags” variable is meant to be set. Unless Nick succeeds in that search, I guess the best fix would be to convert this line: bool tryMarkup=entry.target.tags.size() && sameMarkup; Into this one: bool tryMarkup = sameMarkup; If we can never know whether there are tags or not, better to always check for tags than never. I guess that code needs a deep cleanup, and I am not as crazy as to even try :)
Git commit ef9ee25a72ef864be2da97e8001fe7947f9ed85b by Nick Shaforostoff. Committed on 25/04/2016 at 20:52. Pushed by shaforo into branch 'Applications/16.04'. fix html markup detection, and a recently introduced crash on exit M +3 -0 src/editortab.cpp M +1 -1 src/tm/tmview.cpp http://commits.kde.org/lokalize/ef9ee25a72ef864be2da97e8001fe7947f9ed85b