3.2.x Bug Report / Feedback Thread
- Thread starter mikelove
- Start date
rizen suha
状元
possible bug: for many hanzi (with a specific pronunciation and tone) the def (chosen dict and/or chosen entry) offered depends on wherefrom it is looked up (marked and "clicked" on), fx from main dict overview or from flashcards or from secondary views (fx char componentes) etc. is this a bug or "feature" (which i have been trying to understand with no luck). i believe that accessed from anywhere, a hanzi (or word for that matter) (with a given pronunciation and tone) should have with it associated a deterministic list of entries.
There are more than just those two inputs - in a search result list for example you might also have multiple versions with different traditional (or, if you default to traditional, simplified) characters associated with them and so we might be isolating the results to each of those to make them match up with that particular search result.
We also prioritize whichever dictionary the definition screen was 'spawned' from, so if you're viewing it with a particular dictionary in the popup reader, that dictionary comes up first even if it might not be the first dictionary in Manage Dictionaries or the one that comes up as the default in the main search box. To do otherwise would be highly disorienting in cases where two dictionaries disagreed - you might see an entirely different definition when you brought up that screen and not know where it came from.
We also prioritize whichever dictionary the definition screen was 'spawned' from, so if you're viewing it with a particular dictionary in the popup reader, that dictionary comes up first even if it might not be the first dictionary in Manage Dictionaries or the one that comes up as the default in the main search box. To do otherwise would be highly disorienting in cases where two dictionaries disagreed - you might see an entirely different definition when you brought up that screen and not know where it came from.
rizen suha
状元
same hanzi, same pron, (= x)
defs a b c are available somewhere in pleco
expect to see a b c from whereever i access x
dont mind a contextual ordering c b a, but often fx only b is available, a and c are not
that is highly frustrating
defs a b c are available somewhere in pleco
expect to see a b c from whereever i access x
dont mind a contextual ordering c b a, but often fx only b is available, a and c are not
that is highly frustrating
Any difference between a, b, and c? This shouldn't be happening if they're all completely identical but often they're not. Are any of them coming from user dictionaries?
Can you give me a specific example (from Pleco-supplied dictionaries) + specific steps to reproduce this? We can try to figure out from that whether or not this is supposed to be happening.
Can you give me a specific example (from Pleco-supplied dictionaries) + specific steps to reproduce this? We can try to figure out from that whether or not this is supposed to be happening.
rizen suha
状元
one hanzi x (one pronun)
=> existing various defs a b c... (all distinct)
(a b c... is sum total of existing defs within different pleco dicts)
problem: in some contexts only a subset, say a c, is available
will note down examples in future
busy days
thx for your answer
=> existing various defs a b c... (all distinct)
(a b c... is sum total of existing defs within different pleco dicts)
problem: in some contexts only a subset, say a c, is available
will note down examples in future
busy days
thx for your answer
rizen suha
状元
thanks
re reading my original post #283 i realise that i waa not being clear about the problem
sorry
re reading my original post #283 i realise that i waa not being clear about the problem
sorry
rizen suha
状元
example for post #287
1) 肖像 in flashcards (for hsk 1-6, 5000 cards)
2) select/click to go to def of 像 (my top dict in pleco is KEY) (i have ALL dicts minus one italian and one subordinate chinese)
3) from def of 像 select component 象 (observe def hereof)
4) def of 象 shows only one dict (GR) and entry, even the linked-from-def (3) has disappeared
i observe this ko thing on around 10% of all chars (or so i feel)
it is by no means "isolated cases"
ie not "deterministic"/complete list of desf available for each char => depends on context
(edit: pictures inserted in any order because xenforo sees it fit to do so)
1) 肖像 in flashcards (for hsk 1-6, 5000 cards)
2) select/click to go to def of 像 (my top dict in pleco is KEY) (i have ALL dicts minus one italian and one subordinate chinese)
3) from def of 像 select component 象 (observe def hereof)
4) def of 象 shows only one dict (GR) and entry, even the linked-from-def (3) has disappeared
i observe this ko thing on around 10% of all chars (or so i feel)
it is by no means "isolated cases"
ie not "deterministic"/complete list of desf available for each char => depends on context
(edit: pictures inserted in any order because xenforo sees it fit to do so)
Attachments
OK, found the problem here - it appears non-deterministic because you've hidden simplified characters, but actually it's a case of GR listing this as being 象 simplified / 像 traditional and everybody else listing 象 as a secondary variant of 像. So it's behaving in a consistent fashion based on the data it has - picking the only dictionary that purports to be giving a definition of 象 on its own - but the reasons for that aren't obvious with simplified hidden.
Anyway, we'll file this as a bug on GR and look for other similar cases of it disagreeing with other dictionaries. As far as the more general problem, though, I'm a little wary of changing the way we handle that because going too far in the direction of not filtering could give you lots of useless results (e.g. for something that appears of a variant of a bunch of other characters), but perhaps we could tweak the logic a bit to prevent a single dictionary from 'taking over' a character by being the only dictionary to call it something other than a variant.
Anyway, we'll file this as a bug on GR and look for other similar cases of it disagreeing with other dictionaries. As far as the more general problem, though, I'm a little wary of changing the way we handle that because going too far in the direction of not filtering could give you lots of useless results (e.g. for something that appears of a variant of a bunch of other characters), but perhaps we could tweak the logic a bit to prevent a single dictionary from 'taking over' a character by being the only dictionary to call it something other than a variant.
rizen suha
状元
thx, appreciate your answer
could you not just treat components as first class citizens in the chars tab, so that all imposed (hard wired) context is stripped and the def list for "component" x would be the same as if x was searched from main dict tab?
i think this relates to another post on components i made a week or so ago
could you not just treat components as first class citizens in the chars tab, so that all imposed (hard wired) context is stripped and the def list for "component" x would be the same as if x was searched from main dict tab?
i think this relates to another post on components i made a week or so ago
The problem there would be searching for components that would give you lots of results in the main dictionary tab. Characters with multiple pronunciations, e.g.; you could end up with such a long list of definitions as to be nearly useless / impossible to navigate. The main point of component breakdowns is to give you the essential / basic meaning of a component, in fact we weren't originally sure whether to link them to separate definition screens at all.
That being said, as it happens this is another area we're working on right at this moment, and the current plan for definition screen tabs in general is that every list of results in there will be a customizable search, so that in theory you could customize it to behave the same way your main screen search does. (we've wanted to add flexibility to the definition screen for a long time, for lots of reasons - people might for example want a separate tab for all of their Classical dictionaries, or might want all of their component definitions from a user dictionary they'd made with Heisig mnemonics) So while I can't make any promises yet, I expect that if you want to have the character component search screen give you a giant messy dump of every conceivable definition from any dictionary for a character you'll probably be able to do that.
That being said, as it happens this is another area we're working on right at this moment, and the current plan for definition screen tabs in general is that every list of results in there will be a customizable search, so that in theory you could customize it to behave the same way your main screen search does. (we've wanted to add flexibility to the definition screen for a long time, for lots of reasons - people might for example want a separate tab for all of their Classical dictionaries, or might want all of their component definitions from a user dictionary they'd made with Heisig mnemonics) So while I can't make any promises yet, I expect that if you want to have the character component search screen give you a giant messy dump of every conceivable definition from any dictionary for a character you'll probably be able to do that.
rizen suha
状元
many thanks
not sure if im understanding you entirely here
but very satisfied that you are aware/thinking about possible issues/solutions
not sure if im understanding you entirely here
but very satisfied that you are aware/thinking about possible issues/solutions
rizen suha
状元
feature request: keyboard use/config
my global primary keyboard on ios is zhuyin
when calling up the kb pane on pleco, the last used kb (anywhere on ios) is ...called up by pleco
i would like an option so that the ios primary kb (*) will always be called up, regardless of lastly used kb (**)
* or better: a pleco-default-kb-config with kb use shielded from kb use elsewhere on ios
** also: _i _ even prefer NOT to remember last used kb WITHIN pleco (but that would be an option within *)
my global primary keyboard on ios is zhuyin
when calling up the kb pane on pleco, the last used kb (anywhere on ios) is ...called up by pleco
i would like an option so that the ios primary kb (*) will always be called up, regardless of lastly used kb (**)
* or better: a pleco-default-kb-config with kb use shielded from kb use elsewhere on ios
** also: _i _ even prefer NOT to remember last used kb WITHIN pleco (but that would be an option within *)
This is unfortunately not an area where Apple gives us much to work with - we can request a basic keyboard type (number, text, etc) with some variations (@ for email, what goes in the return key label, etc), and we can replace the keyboard entirely or stick other things on top of it, but there’s not really a way to coerce it into showing a specific system keyboard.
(If you’ve seen any other apps that do that, let us know and we can investigate how, but it may be that they’re using some sort of hack that’s not available to us because we’re bigger / more terrified of App Review than they are)
(If you’ve seen any other apps that do that, let us know and we can investigate how, but it may be that they’re using some sort of hack that’s not available to us because we’re bigger / more terrified of App Review than they are)
rizen suha
状元
hmm
understood
maybe an innocent hack that should be "legitimate" since it only affects pleco and could be enabled with a user-conscious fig: when activating the search field, pleco itself opens/selects the user-default kb (and if necessary, but shouldnt be, writes something and immediately deletes it). with that, the last used kb will be the user-default
understood
maybe an innocent hack that should be "legitimate" since it only affects pleco and could be enabled with a user-conscious fig: when activating the search field, pleco itself opens/selects the user-default kb (and if necessary, but shouldnt be, writes something and immediately deletes it). with that, the last used kb will be the user-default
The problem is that from Apple's view there are no innocent hacks. Plus, even if it slipped by initially, it might get caught on a later review and then we'd have to take it out and deal with a bunch of pissed-off users over that. So I'm afraid it's just not worth the risk.
rizen suha
状元
nah
it wouldnt be a hack
it would be a user defined behaviour
i dont buy that apple would censor that, cause it would not interrupt other apps behaviour nor user expectation; user will know that anytime pleco was used last (a search/kb invoked) app, keyboard will be zhuyin or whatever
and the user would have no reason to be surprised, since he would have "seen" the search/kb come up in pleco...
he would have been there to see it ;-)))
so absolutely freakin impossible that apple could censor that
lets not trip over our own feet in trying to be choir boys
many thanks for your considerations though
;-)
it wouldnt be a hack
it would be a user defined behaviour
i dont buy that apple would censor that, cause it would not interrupt other apps behaviour nor user expectation; user will know that anytime pleco was used last (a search/kb invoked) app, keyboard will be zhuyin or whatever
and the user would have no reason to be surprised, since he would have "seen" the search/kb come up in pleco...
he would have been there to see it ;-)))
so absolutely freakin impossible that apple could censor that
lets not trip over our own feet in trying to be choir boys
many thanks for your considerations though
;-)
Sorry, I should be clear: there's no technical way to do what you're describing without literally hacking iOS, making it do a thing which it's not designed to do. This isn't about us simply not wanting to violate the rules, it's about iOS not letting us do this thing + us having to use a hack / workaround to get it to do that.