denmitch
探花
Oh boy oh boy. This sound exciting!
3.0.0 Bug Report / Feedback Thread
- Thread starter mikelove
- Start date
Alexis
状元
I switched over to "Embed definition" off after seeing your post. I really like having the larger listing "preview" and full-screen definition.
Would it be feasible to have the Search Results Layout -> #defn lines act as a maximum? ie. If set max-lines to three, but an entry only had one lines worth, then the box for that word would only be one one line high? I'd like to increase the number of defn lines (for a clearer 'preview', but it creates a lot of wasted space for entries that fit on one line.
When editing text in the reader, if I have selected some text while in keyboard mode and then accidentally press the handwriting icon, sometimes it does not fully redraw the screen where the keyboard used to be. I cannot always reproduce this but it has happened on several different occasions now.
Not sure if it makes any difference, but the text came from OCR Image capture and it seems when this happens it is usually under that scenario. (A quick tap or scroll seems to force a redraw and fixes the issue.)
Not sure if it makes any difference, but the text came from OCR Image capture and it seems when this happens it is usually under that scenario. (A quick tap or scroll seems to force a redraw and fixes the issue.)
Thanks - text editing is going to remain a little wonky until we debut our own Apple-text-edit-control replacement in an update next year - the system UITextView is just too darn finicky - but if this turns out to be an issue with our code instead of theirs then we should certainly be able to fix it.
I never did find that "full-text search" option -- but the # works...is the inability to get full-text working on tap+hold+select a bug?
ALSO! Can we get the 21c ipa pronunciation back for English words?!
(it was always helpful every now and then)
Yeah, I, too, like this look better for the iPhone portrait mode because the side bar on the left and search result window on the right take too much space away from the dictionary entries. Further, the "+" for adding flashcard only shows up when you turn off "embed definition" in the portrait mode.
Last edited:
ACardiganAndAFrown - looks like a bug, yes; also noticed it while doing some walkthrough testing for the instruction manual update.
21C IPA was removed because we don't have a good way to handle IPA in merged dictionary entries at the moment and we don't consider it an urgent priority to come up with one. If we manage to do so eventually we certainly might bring it back, but for now, you could either turn on the English option in Settings / Audio (which wouldn't bring back IPA but would give you a handy speaker icon to hear the English pronunciation for a word), or you could delete your currently installed copy of 21C, download the old version of it from here and follow the instructions here to install it on your device. But the latter approach would give you a considerably uglier 21C with no example sentence support, the occasional buggy merged search and the possibility of not working at all in the future (in which case you'd have to update to the newer version anyway), so to be honest, if IPA pronunciation for English words is really important to you I'd suggest getting that from a dedicated English dictionary app instead.
gato - the + button certainly should show up on landscape iPhones with "embed definition" on - is this a 4/4S or a 5/5S? Is it running iOS 6.1 or 7?
afritzse - if you turn on "show file extensions" in Settings / Reader, that will let you edit file suffixes.
21C IPA was removed because we don't have a good way to handle IPA in merged dictionary entries at the moment and we don't consider it an urgent priority to come up with one. If we manage to do so eventually we certainly might bring it back, but for now, you could either turn on the English option in Settings / Audio (which wouldn't bring back IPA but would give you a handy speaker icon to hear the English pronunciation for a word), or you could delete your currently installed copy of 21C, download the old version of it from here and follow the instructions here to install it on your device. But the latter approach would give you a considerably uglier 21C with no example sentence support, the occasional buggy merged search and the possibility of not working at all in the future (in which case you'd have to update to the newer version anyway), so to be honest, if IPA pronunciation for English words is really important to you I'd suggest getting that from a dedicated English dictionary app instead.
gato - the + button certainly should show up on landscape iPhones with "embed definition" on - is this a 4/4S or a 5/5S? Is it running iOS 6.1 or 7?
afritzse - if you turn on "show file extensions" in Settings / Reader, that will let you edit file suffixes.
Sorry, had a brain freeze. I meant portrait mode on the iPhone.
AdrianLondon
Member
Finally got the history to sync across my iPad (iOS7) and iPhone (iOS6).
Not sure exactly what did it, but probably a combination of everything:
1. Remove jailbreak from iPhone
2. Turn off history sync within Pleco on both devices
3. Turn off iCloud "documents & data" sync in settings on both devices and hard reboot (both buttons for 10 seconds)
4. Turn on documents & data sync on both, and hard reboot again
5. Enable history sync in Pleco on both
Not sure exactly what did it, but probably a combination of everything:
1. Remove jailbreak from iPhone
2. Turn off history sync within Pleco on both devices
3. Turn off iCloud "documents & data" sync in settings on both devices and hard reboot (both buttons for 10 seconds)
4. Turn on documents & data sync on both, and hard reboot again
5. Enable history sync in Pleco on both
alanmd
探花
This bug probably isn't too high profile, as it's probably only me with my converted dictionaries that notices problems with English user dictionaries, but I figured I would describe it completely here as it seems like something small is going wrong, rather than something impossible to fix.
I have two English user dictionaries, WEB and NET, both of which have a definition for the term 'colloquial'. WEB and NET are first and second respectively in my dictionary priority order. (Update: I've been asked how I got these dictionaries into Pleco, you can add them too at this page: http://hskhsk.com/dictionaries )
When I search for 'colloquial', I see two exact match results:
Clicking on the first result takes me to an entry page that shows the entries in my two user dictionaries only. The WORDS and SENTS tabs are empty:
Clicking on the second result takes me to a merged entry containing the entry from all offical Pleco dictionaries, but with the entry from my WEB dictionary (but not NET) included second! The WORDS tab looks fine and contains results from both WEB and NET. The SENTS tab however includes the full text of many entries from both WEB and NET!
If this is something difficult to fix, is there any simple way (e.g. special character codes) that I can indicate to Pleco that my user dictionary entries are not sentances?
I have two English user dictionaries, WEB and NET, both of which have a definition for the term 'colloquial'. WEB and NET are first and second respectively in my dictionary priority order. (Update: I've been asked how I got these dictionaries into Pleco, you can add them too at this page: http://hskhsk.com/dictionaries )
When I search for 'colloquial', I see two exact match results:
Clicking on the first result takes me to an entry page that shows the entries in my two user dictionaries only. The WORDS and SENTS tabs are empty:
Clicking on the second result takes me to a merged entry containing the entry from all offical Pleco dictionaries, but with the entry from my WEB dictionary (but not NET) included second! The WORDS tab looks fine and contains results from both WEB and NET. The SENTS tab however includes the full text of many entries from both WEB and NET!
If this is something difficult to fix, is there any simple way (e.g. special character codes) that I can indicate to Pleco that my user dictionary entries are not sentances?
Last edited:
alanmd
探花
Some more small bugs.
1) When unpacking .zip files in the File Manager on an iPad, the percentage complete status shows on the file/folder above the .zip file (off by one error?) - file unzips OK though.
2) When editing English user dictionaries I sometimes lose the copyright text when I leave the dictionary and come back; not sure if this only happens for very long (~200 characters or so) copyright strings.
3) The iPhone uses the dictionary 'Short Name' for English User Dictionaries in the 'Manage Dictionaries' menu and elsewhere, while the iPad uses the 'Menu Name' (this might be by design, but isn't obvious).
Some suggestions for the distant future (when you have nothing to do some day
):
4) In many cases for offical Pleco dictionaries the 'Short Name' is longer and more descriptive than the 'Menu Name' - I'd much prefer to see the 'Short Name' or some variation on it in the menus (there is plenty of room); some of the names used in the menus are fine, but some like DGNCYCD, GZHFYCD, HYDCD and GHYDCD are a bit cryptic.
5) The 'Abbreviations' for dictionaries could be made longer (and perhaps allow Hanzi); almost everywhere that displays them has room to display a lot more than the increasingly cryptic TLA.
6) User Dictionary import is very slow, something like 15 or 20 entries per second on an iPhone 5S / iPad 3. Building full text indexes is incredibly fast in comparison, surely something is wrong with the performance of the import code?
1) When unpacking .zip files in the File Manager on an iPad, the percentage complete status shows on the file/folder above the .zip file (off by one error?) - file unzips OK though.
2) When editing English user dictionaries I sometimes lose the copyright text when I leave the dictionary and come back; not sure if this only happens for very long (~200 characters or so) copyright strings.
3) The iPhone uses the dictionary 'Short Name' for English User Dictionaries in the 'Manage Dictionaries' menu and elsewhere, while the iPad uses the 'Menu Name' (this might be by design, but isn't obvious).
Some suggestions for the distant future (when you have nothing to do some day
):4) In many cases for offical Pleco dictionaries the 'Short Name' is longer and more descriptive than the 'Menu Name' - I'd much prefer to see the 'Short Name' or some variation on it in the menus (there is plenty of room); some of the names used in the menus are fine, but some like DGNCYCD, GZHFYCD, HYDCD and GHYDCD are a bit cryptic.
5) The 'Abbreviations' for dictionaries could be made longer (and perhaps allow Hanzi); almost everywhere that displays them has room to display a lot more than the increasingly cryptic TLA.
6) User Dictionary import is very slow, something like 15 or 20 entries per second on an iPhone 5S / iPad 3. Building full text indexes is incredibly fast in comparison, surely something is wrong with the performance of the import code?
Not sure how much we can do about the merging problem - we'll investigate that one - but the SENTS thing is definitely a bug, it should be skipping user dictionaries altogether for that type of search at the moment.
Reasonable point on Short Name, though abbreviations I'd rather keep short for now - we couldn't fit anything longer than 3 letters in the space next to the search bar or the button at the top right corner of the popup definition screen, for example. And keeping them English-only enforces some helpful design consistency - if you see three small-caps letters somewhere you can be pretty sure this is indicating a specific dictionary, important in the relatively context-poor iOS 7.
User dictionary import isn't something we've ever really tried to make fast; frankly, we don't want to be another StarDict - don't want to do anything to encourage people to build up vast libraries of often-not-rigorously-copyright-cleared user dictionaries. It's a tricky balance - it's a nice and relatively unique feature and we're happy to have people explore its potential, but if somebody for example starts sharing an illegally pirated copy of the ABC dictionary as a user dictionary database, then not only do we get the ABC people mad at us, we also potentially lose out on a lot of legitimate sales of the ABC dictionary. (yes, they'd need a legitimate copy of the flashcard add-on, but plenty of people would decide they'd given us enough money at that point and feel that they were now entitled to a bunch of free dictionaries for their trouble) So a non-draconian way to discourage that is to make user dictionaries just slow / awkward enough compared to official ones that people are encouraged to use those instead.
Reasonable point on Short Name, though abbreviations I'd rather keep short for now - we couldn't fit anything longer than 3 letters in the space next to the search bar or the button at the top right corner of the popup definition screen, for example. And keeping them English-only enforces some helpful design consistency - if you see three small-caps letters somewhere you can be pretty sure this is indicating a specific dictionary, important in the relatively context-poor iOS 7.
User dictionary import isn't something we've ever really tried to make fast; frankly, we don't want to be another StarDict - don't want to do anything to encourage people to build up vast libraries of often-not-rigorously-copyright-cleared user dictionaries. It's a tricky balance - it's a nice and relatively unique feature and we're happy to have people explore its potential, but if somebody for example starts sharing an illegally pirated copy of the ABC dictionary as a user dictionary database, then not only do we get the ABC people mad at us, we also potentially lose out on a lot of legitimate sales of the ABC dictionary. (yes, they'd need a legitimate copy of the flashcard add-on, but plenty of people would decide they'd given us enough money at that point and feel that they were now entitled to a bunch of free dictionaries for their trouble) So a non-draconian way to discourage that is to make user dictionaries just slow / awkward enough compared to official ones that people are encouraged to use those instead.
alanmd
探花
I understand you wouldn't want to make pirating easier, but if people are pirating they will import PQB files (which are lightning fast), only people building dictionaries get to use the strangely slow text file import. If you ever have serious problems with pirated dicts, you could block those dictionaries in future versions by looking for some sort of signature of the file, DRM-style.
For me the right justified text in capitals is enough to tell that it's a dictionary name, and there is always plenty of whitespace next to it. I can't see a dict name next to the search bar in 3.0 (is that an option?). There isn't much room there on the OCR screen, that would have to change to allow longer names (up/down buttons and dict name might be better off on the right anyway). I tried changing some of the TLAs to make them easier to remember in the beta, then they all changed back when I bought the dicts in 3.0, and now I can't remember which is which at all for some of the less common dicts- and if I long-press on the TLA to bring up its' full name I see something helpful like GHYDCD. Could be just me that worries about that though with my poor memory...
For me the right justified text in capitals is enough to tell that it's a dictionary name, and there is always plenty of whitespace next to it. I can't see a dict name next to the search bar in 3.0 (is that an option?). There isn't much room there on the OCR screen, that would have to change to allow longer names (up/down buttons and dict name might be better off on the right anyway). I tried changing some of the TLAs to make them easier to remember in the beta, then they all changed back when I bought the dicts in 3.0, and now I can't remember which is which at all for some of the less common dicts- and if I long-press on the TLA to bring up its' full name I see something helpful like GHYDCD. Could be just me that worries about that though with my poor memory...
Sure, but PQB files are much easier to block than text files. And just in general the number of large, legal user dictionaries out there that a) significant numbers of people might find useful but b) we can't / won't turn into official Pleco add-ons is quite small, so it's hard to justify putting much effort into optimizing their creation when there are so many other things we could work on instead.
You can select an individual dictionary in the search bar (for now) with a tap-hold. The popup definition has the same problem that OCR does, it's just a bit less visible since it's on the right instead of the left side - would still be a problem with a long headword that overlapped it.
You can select an individual dictionary in the search bar (for now) with a tap-hold. The popup definition has the same problem that OCR does, it's just a bit less visible since it's on the right instead of the left side - would still be a problem with a long headword that overlapped it.
alanmd
探花
With English TTS switched on, Sometimes "superscript one" and similar gets read out for words with multiple definitions.
Only just noticed this great feature thanks to a post somewhere else- literally the day after a native Chinese speaker was saying they wished Pleco could speak E as well as C.
Only just noticed this great feature thanks to a post somewhere else- literally the day after a native Chinese speaker was saying they wished Pleco could speak E as well as C.
Last edited:
Shun
状元
Thanks. On an iPhone, I downloaded a PDF file from a webpage in Safari, then opened it in Pleco. So far, no problems. Then I sent it to an E-mail address from within Pleco, the recipient received it as a file without any suffix, so he can't double-click to open it. For computer-savvy users, this isn't a big issue, but in any case one would still have to remember to add a PDF suffix manually before sending it. For a beginning user, this can be an unresolvable problem. Couldn't Pleco be a bit more fail-safe in this case?