3.2.x Bug Report / Feedback Thread
- Thread starter mikelove
- Start date
No, 11.4.1.
JD
状元
Not that it helps, but it seems to work ok on my iPad Air 1 (very old) running iOS 11.4.1 with latest Pleco.
Attachments
Is it reproducing?
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.
\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:
W.HK: 对号入座[對號入座] 2nd and 3rd sample sentences have some formatting issues - subsequently taking out tts function with them.
@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.
@ACardiganAndAFrown - thanks.
rizen suha
状元
amazing! thx
rizen suha
状元
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.
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.
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.
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.
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
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
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.
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.