3.2.x Bug Report / Feedback Thread

Hi Mike,

in the Dictionary’s WORDS tab, I found that one Spanish and one French dictionary got separated out of the combined dictionary display, even though the headword and pinyin were identical in both groups. Just the the larger group had a stored Cantonese pronunciation (not visible in the screenshots), the smaller group didn't. Shouldn‘t they be grouped together when the Display Cantonese pronunciation option is disabled and apart when it is enabled, or would that be messy? It's more of a cosmetic issue, of course.

Here is the overview list with two 侵略s in the middle, followed by the two definition screens:

ECF52C1F-C495-4A50-8C1B-70EF6D2DC828.png DA5922E0-40D0-4DA6-8ED6-ABE91693A4E7.png 1B60D1E8-3CCD-4673-BC47-093BE6B2E602.png

Thanks!
 
Last edited:

mikelove

皇帝
Staff member
Looks like it's actually not related to Cantonese but rather to the way the umlauts are encoded in those two dictionaries - will fix it the next time we update them.
 
For whoever‘s interested, here‘s what StackOverflow said about it: „These are two different forms to express the same letter in Unicode; one is the combination of an „u“ with combining diereses, the other is the letter „ü“. Unicode allows either variant to express „ü“.“

If I may, I have this follow-up question: Instead of fixing the umlaut encoding in these and any future dictionary files, wouldn‘t it be more fail-safe if Pleco just recognized both variants as the same character? That way, this error could never happen. Or would that be bad design? Thanks!
 

mikelove

皇帝
Staff member
Unicode normalization (which is what you're describing) is on our to-do list - the problem is that we want to do it with cross-platform code instead of platform-specific code (so we can use the exact same engine for it in our database encoder and on both iOS and Android) and the mapping tables involved take up space we can't currently afford in our Android app; once 4.0 is out with its massive data file shrink it'll be a lot easier.
 
That's interesting, I've found that wherever the pinyin syllable "xǐng" should be read in the third tone together with other syllables, it is read as "xiǎng". Other examples are: 醒神、省事、省视学、省风.

Zhuyin looks great, it might even improve one's pronunciation. ;)
 
That's interesting, I've found that wherever the pinyin syllable "xǐng" should be read in the third tone together with other syllables, it is read as "xiǎng". Other examples are: 醒神、省事、省视学、省风.

Zhuyin looks great, it might even improve one's pronunciation. ;)
thxs shun for the additional examples.
as for zhuyin vs pinyin, zhuyin takes some months getting used to. at first, the more alien script encourages a greater effort to memorize the pronunciation since you are much less prone to automatically cognize the phonetic transcription (or even, unwillingly have "your eyes" being attracted to it and "distracting" attention from the characters - which you really _should_ be focusing on). and in the long run, using a phonetic system free of false associations may very well prove worth your while. i at least feel that this has been the case for me. zhuyin in pleco, though, does look a little clunky as it is. looking forward to the promised ruby script. but that will have to be accompanied by (even) larger chinese characters (option to enlarge chinese characters, even more, yes please, this is not a nice to have, it is really necessary).
 
Last edited:
pleco 3.2.31. reader, epub, iphone x. navigation arrows at the bottom: did their tappable area change? anyhow, i would like for the positioning of these crucial arrows to be configurable for smaller and bigger hands, facilitating one-hand-operation. another thing: in add ons, the "available" section is empty.
 

mikelove

皇帝
Staff member
No, didn't change anything about reader tap areas.

Available section empty: does it help if you reload it now? (swipe down) If not, could you PM me your current Pleco "Registration ID" along with which country you're connecting from?
 
Top