3.2.x Bug Report / Feedback Thread

JD

状元

Attachments

  • 9B07BA7F-440E-415A-BC46-4CA286A8D614.png
    9B07BA7F-440E-415A-BC46-4CA286A8D614.png
    851.2 KB · Views: 516

rizen suha

状元
flashcards: hide pinyin pronunciations in definitions. annoying to have the pronunciation revealed before "answering". especially when testing for that same thing. please eliminate / hide.
\delimiter{pinyin for character X}\delimiter with {pinyin for character X} actually being english (not pinyin) is negligible and any errors (~0) will be perfectly acceptable.
 
Last edited:

mikelove

皇帝
Staff member
@rizen suha - actually working on that area the last few weeks, we're finally putting an actual regex engine into our cross-platform code so we can do a much much better job of complicated search-and-replace than we used to.

@ACardiganAndAFrown - thanks.
 

rizen suha

状元
@rizen suha - actually working on that area the last few weeks, we're finally putting an actual regex engine into our cross-platform code so we can do a much much better job of complicated search-and-replace than we used to.

@ACardiganAndAFrown - thanks.
upon revealing the answer:
if the pinyin for character X could be substituted with its zhuyin (with tonemarks) that would be an awesome option (switch).
i really prefer not to see pinyin anywhere.
also, in the main text of definitions, the pinyin is usually w/o tonemarks, ugh.
i realize that the dict authors do so out of literary considerations (eg wrt names).
but still, ugh for a slow language learner like myself.
 

rizen suha

状元
possible bug: on iphone x, in dict search mode, suddenly zhuyin keyboard will not punch out tone marks, tone numbers ok, but not theˋˊ˙ˇ marks:they do not show up as text in the search field. in reader mode (search), zhuyin keyboard tone marks ARE produced. this is on lastest pleco. tried closing everything and restarting iphone. no use. w pleco on ipad pro, all is ok.
 

rizen suha

状元
above error: as one can see in this scrshot, in the zhuyin keyboard (std ios) the completion/suggestions bar does not contain any suggested characters/words corresponding to an input "beginning" (here ㄙ as an example). so not being able to choose any of the tone marks, is a consequence of this prior error.
398B037C-2F09-41BB-980D-01DD8D1DBEB1.jpeg
 

mikelove

皇帝
Staff member
The Pinyin/Zhuyin here is on the data file level - if pinyin is encoded with our 'meta-pinyin' system it can be + is rendered as Zhuyin if that's your preference, otherwise it's not. So there isn't something we could really do in code to fix that, we'd just have to tediously go through every dictionary and find / hand-check all of the embedded pinyin in every entry, which is a hard thing to justify doing without a lot more demand for it.

Zhuyin: turn off the 'system keyboard Zhuyin input' option in Settings / Search Engine and that should stop it from interfering with your entering characters with Zhuyin.
 

rizen suha

状元
@mikelove
keyboard: many thanks, that worked!
substitution: but you said previously that you are improving your regex. then the probability of erroneously (ie it really is "english") matching with Xs pinyin (delimited by space or whatever, and you already know that the hanzi is X) must be zilch. so i dont quite understand why you cannot substitute w the zhuyin for X.
 

mikelove

皇帝
Staff member
Not zilch, there are some pinyin strings that are indistinguishable from English. If you're so bothered by pinyin that you're willing to lose random English words to get rid of it then you will probably be able to add a regex to do that, but it's not reliable enough for us to ship as an official option.
 

rizen suha

状元
not looking to hide or subst any pinyin, only the one that is manifest from an entrys hanzi definition. that should bring the false positives down to max 1/1000. add to that, that most pinyin will be "specially delimited" (by ^ : parentheses etc much more frequently than "english") we should end up with an error frq of max 1/10000
 

mikelove

皇帝
Staff member
Sorry, not quite sure what you mean here - if it's pinyin in a dictionary definition and it's not already rendering as zhuyin then it's not tagged as pinyin and it's something we'd have to manually tag. And doing that reliably for every dictionary would take a LOT of work, and doing it poorly would produce some fairly big/obvious bugs (random English words being replaced by Zhuyin for people who've selected Zhuyin, or hidden altogether for people who've set Mandarin pronunciation to 'none' because they only want characters and/or Cantonese).
 

rizen suha

状元
i understand what you mean. if the err frq is ~1/10K, yeah, that is too high for general substitution in dicts, i agree. but in flashcards, and w the user being aware of having selected an option "hide pinyin in flashcars before answ" or "convert pinyin to zhuyin in flashcards / answers" maybe its ok. also it is w flashcards, in "mental imprinting mode", where pinyin may disturb most (either before an answ or in an answ where some prefer studying pronunciation w zhuyin). thanks for your replies, for taking it into consideration
 

mikelove

皇帝
Staff member
Possibly, but adding checkboxes for things like this is how we got into our current mess :) So keeping it an 'expert mode' thing where you have to go into your presentation settings and manually add this as a regex to be applied to a field would let anyone who cares about this feature have it, but avoid cluttering up the UI for non-expert-mode users.
 
Top