This is a very strange bug, best explained with an example. See the attached .po file. Part of the translation string is ‘spel og animasjonar’. But when you resize the editor pane so that the word ‘animasjonar’ is the *first* word in any line, it is displayed as ‘nimasjonar’; the ‘a’ is missing. Editing the word doesn’t fix the rendering. This only happens with this word in the example file; other words work fine. And if you resize the pane so that the word ‘animasjonar’ is not the first word on a line, it it correctly displayed (and the word that *is* the first one word a line is *also* displayed correctly). As I said, a very strange bug. Reproducible: Always Steps to Reproduce: 1. Open the attached translation file 2. Resize the editor pane so that the words ‘animasjonar’ is the first word on a line. Actual Results: The word is rendered as ‘nimasjonar’. Expected Results: The word should be rendered as ‘animasjonar’. This also happens on a newly created user profile, with different font settings.
Created attachment 98008 [details] Example translation file triggering the bug
Created attachment 98009 [details] Screenshot showing the incorrect rendering
Created attachment 98010 [details] Screenshot showing the correct rendering (after resizing the edit pane)
Seems like this is related to the non-breaking space after the word. When one adds a non-breaking space after the first word on the line, the first letter in the word is not rendered. When one continues adding non-breaking spaces, the other letters disappear one after another, until the word is completely invisible (adding additional non-breaking spaces then have no effect on the word or on other words).
yep... the workaround is to disable 'highlightSpaces' option...
looks to me as a qt bug -- i do simple setFormat call in syntaxhighlighter for qtextedit if the char matches 0x00a0U code. changing it to match simple spaces does't trigger a similar issue. https://quickgit.kde.org/?p=lokalize.git&a=blob&h=87a765d61ad24ea45133407622b26a7425dc7066&hb=bc3ca63d835aa6f0ecae3e5a451826dc661890b8&f=src%2Fsyntaxhighlighter.cpp
I confirm that this bug is resolved in my Lokalize running Qt 5.11. Please check and close.
Yes, looks like it was a Qt bug which is now fixed.