The zero-width non-joiner (Unicode U+200C) is an important character in Persian. It prevents two parts of a compound word (or word with certain prefixes and suffixes) from being joined together, and occurs in almost every Persian sentence.
LingQ is able to display this character, but for some reason cannot import it. That is, when I import text (whether it’s from a file like an ebook, or by copy-pasting text myself), the ZWNJ gets deleted, and the words in the lesson are joined incorrectly. (It is possible to reinsert the ZWNJ by editing the lesson afterwards, but I have not found a way to import without losing the ZWNJ in the first place.)
A secondary issue: when the ZWNJ is displayed, LingQ highlights the disjoined parts of the word separately, as if the ZWNJ were a space. It also allows me to save the whole word as if it were a phrase; however, it does not display this “phrase”! This is much less of a problem, however, than the outright deletion of the ZWNJ in imported lessons.
Thank you fabbol for bringing this up. I just assumed this was an issue unique to the stuff I had imported but now that you mention it, yeah, every text I’ve brought into LingQ has had this problem.
I’ve realized that there is a difference between the app and browser version with regard to the ZWNJ, once it has been re-inserted into the lesson text (the secondary issue I described above). As I said, LingQ allows you to highlight and save a word that includes a ZWNJ as if it were a phrase.
On the browser, this actually works as intended. The “phrase” is saved with the ZWNJ, and the “phrase” is correctly highlighted in the text.
The (secondary) problem I described happens in the app. What seems to happen is that the app ignores the ZWNJ in phrase creation. For instance, the conjugated verb میرفت is saved as میرفت. Since the displayed “phrase” (with the ZWNJ) doesn’t match the saved word (without the ZWNJ), the word/phrase is not highlighted yellow.
In short: the app wrongly deletes the ZWNJ during LingQ creation, the browser does not (which is the desired behavior).
The primary issue (deletion of the ZWNJ when importing text) still remains, of course. Thanks for looking into it!
Update: I don’t know when this was added (maybe in the maintenance just now, or maybe weeks ago - I haven’t imported anything lately before tonight), but this seems to be fixed now!
A secondary issue remains: the (iOS) app still does not highlight a word that includes a ZWNJ. Only the separate parts of the word appear, even if the complete word has been LingQed. But again, that’s very much secondary.
Here I am LingQing a compound word, خیرهکننده, consisting of the components خیره (amazed, staring at X) and کننده (-doing, -making), thus literally “amazed-making” or stunning. As you can see, the lesson text displays the word correctly, but the LingQ that gets saved incorrectly connects the two components, making it *خیرهکننده. This on its own is already vexing, but the real problem is that as a result, as soon as I click away, the color-coding goes away, both on iOS:
I assume that this is because the saved LingQ with the incorrect connection does not match the correct lesson text.
The browser, thankfully, does not remove the ZWNJ from saved LingQs. The result is: when I save a compound word on the browser, it is saved and color-coded correctly both on the browser and on iOS. When I save a compound word on iOS, it is saved incorrectly and displayed without color-coding both on the browser and on iOS.
I really appreciate that you fixed the primary issue I reported first, as it was much more disruptive! I wanted to report and illustrate this secondary issue again to see if it could be fixed in time as well. Thanks!
(To illustrate the extent of the potential problem, I count 16 unique instances of ZWNJ (and several more repeated ones) on my iOS screenshot. It’s less of an issue for me now, as I’ve turned most of these words white by now, but if someone were to begin fresh using iOS, that would be 16 LingQs not correctly displayed in a mere half screen!)
