Feature Suggestions

[llammamama]

When reviewing how to draw the characters using free response, I keep accidentally hitting the "answer" button after drawing the character and getting it marked wrong.

This made me think that maybe it would be a good idea to have the "answer" button automatically recognize what you had drawn in the input box, and if the first match is correct then score the card as being answered successfully. This would be a time saver when you know for sure that you wrote the character well enough for it to be recognized correctly, and it would give that "answer" button some meaning besides "mark card as wrong".

 

[ipsi]

Alexis: It works fine now, but for full-text search, the language you've got selected is the language you're searching in. e.g. If you want to do a full-text search of the NWP dictionary for ni3hao3 (Can't write Chinese here), then you'd switch to Chinese -> English and do a full-text search there. Then tap-hold the dictionary button, and you should see all the dictionaries listed. Confused me as well the first time I tried it

EDIT: To search all the dictionaries for, say, 'Grape', switch to English -> Chinese and do a full-text search (e.g. #grape), and that will search all the dictionaries (ABC, Oxford, NWP, etc) for that word.

 

[radioman]

From what I can tell, the full text search is probably the least promoted, yet highly useful feature. I use it all the time.

Alexis: It works fine now, but for full-text search, the language you've got selected is the language you're searching in. e.g. If you want to do a full-text search of the NWP dictionary for ni3hao3 (Can't write Chinese here), then you'd switch to Chinese -> English and do a full-text search there. Then tap-hold the dictionary button, and you should see all the dictionaries listed. Confused me as well the first time I tried it

EDIT: To search all the dictionaries for, say, 'Grape', switch to English -> Chinese and do a full-text search (e.g. #grape), and that will search all the dictionaries (ABC, Oxford, NWP, etc) for that word.

 

[F_Kal]

Maybe somebody has suggested it before, but there is one thing that I find very very useful in wenlin and there is not in pleco: It gives you a way to judge if the that a word or the character you are reviewing is "useful" or not: Gives you a number saying how often this word appears in a typical text. In that way you know which words you should focus on studying and what to ignore!(I think it would really make a difference, displaying this information and sorting the results by this!)

 

[Alexis]

Alexis: It works fine now, but for full-text search, the language you've got selected is the language you're searching in. e.g. If you want to do a full-text search of the NWP dictionary for ni3hao3 (Can't write Chinese here), then you'd switch to Chinese -> English and do a full-text search there. Then tap-hold the dictionary button, and you should see all the dictionaries listed. Confused me as well the first time I tried it

EDIT: To search all the dictionaries for, say, 'Grape', switch to English -> Chinese and do a full-text search (e.g. #grape), and that will search all the dictionaries (ABC, Oxford, NWP, etc) for that word.

Thanks ipsi! It never occurred to me to switch the dictionaries around for some reason. This full-text search indeed seems to be the most powerful new dictionary feature in 2.0!

I used the example of Grape, and noticed that the default behavior of the list box is different for Chinese/English and English/Chinese. English/Chinese lists only the entries that match, whereas the Chinese/English dictionaries list all entries in the dictionary. This may have contributed to the reason I thought that only the E-C was working before (with an english full-text search) Of course, one can manually toggle the listing every time one does a full-text search, but would be useful if the C-E defaulted to list only the matched entries as well.

 

[mikelove]

llammamama - I guess that would help with single-character cards, but I'm worried about potential confusion with multi-character ones - having to use two different interfaces to recognize the character depending on how many characters are in the card could be somewhat problematic. It might make sense to put Recognize in a bigger / easier-to-access place, though, or consider finally adding recognize-after-every-stroke support. (if we really wanted to be sadistic we could have you draw each of the characters on the card in a separate box, then recognize them all at once once you hit Answer, but that seems likely to cause a lot of incorrectly-marked answers)

radioman - yeah, we do need to do a better job of making people aware of it - the interface still needs to be made clearer, though, and we don't handle really common words very well yet, so just as with the comparatively little-used flashcard system in Oxford Dict 2.0 I think as we put more time into improving it we'll feel more confident about promoting it. (same goes for the document reader, which also isn't getting much attention yet)

F_Kal - we actually haven't found a good set of word frequency data yet; the ABC dictionary has some rough info on that embedded in its database (not numbers but letter grades for how common words are) and I guess we could make that visible to users but we'd really like to find / license / generate a good detailed list of word frequencies that we can use for sorting search results and such.

Alexis - the reason that C-E search is listing all of the entries in the dictionary is because it's only finding one match; whenever you do a search in Pleco with only result, it jumps you right to that result in the dictionary ('dian' instead of 'guo' List Mode icon), since there's not really much point in displaying a list with only one entry in it.

 

[mfcb]

dont know if i missed something and what i want is possible, but i could not find it.

basically i am recategorizing my flashcards, and i would have liked to do a search for all cards in a certain main category but not in another category.
i can select the categories for the search result that the cards should have (with AND/OR) but i miss the NOT option for categories.

example: categories "200809" OR "200810" but <NOT> category "chengyu"

 

[llammamama]

Hmm... you're definitely right that my idea would be confusing for multi-character cards.

At any rate, it is a bit annoying to draw in the character on the right of the screen, then have to click recognize all the way on the left of the screen, then click the character I drew (also on the very left). Being right handed my little stylus doesn't reach over to the far left edge of the screen very well (although I am glad that the input was switched to the right side).

A simple fix would be to swap the positions of the recognize and erase buttons, then arrange the results window in reverse (best match to the right hand side). Maybe you could order the results window top-to-bottom right-to-left (like traditional Chinese script) so that it doesn't seem like the list is backwards.

 

[ldolse]

Unicode Code Point & Radical

Adding Unicode code point to the Character Info screen would be very useful - this was discussed early on during the beta process but never made it in, just re-noting it here.

Also, radical is on the Stroke Order tab, but I'd really prefer it on the details tab as well. It's only sort of there with RSUnicode. The problem with RSUnicode is it's just a number, I don't think many people have the radicals memorized by Kangxi number, I certainly don't. What's useful about RSUnicode though is it includes the radical plus number of additional strokes after the decimal point. What would be best is the primary radical plus the number of strokes.

For example:
仁 has the RSUnicode value of 9.2, So:

9.2
would then be replaced by:
人 ＋ 2
or
亻 ＋ 2

 

[stephanhodges]

Has anyone produced a flashcard set of just the radicals with their pronunciations, and perhaps a little "story" to help remember them?

 

[ldolse]

Regarding the radicals, I've been waiting for the MakePleco equivalent for 2.0 to make a 2.0 compatible radical dictionary. I suppose I could try to do it just using a flashcard import file, but I was hoping to be able to use line breaks and bold formatting....

 

[ipsi]

Line Breaks and bold formatting work fine with flashcards in 2.0. The Classical Function word list I posted has them, and it works for me. Admittedly, I'm not sure how they appear when editing...

I'd also like the Unicode code point in the details tab. Have been getting by with looking it up based on the RSUnicode field.

 

[ldolse]

You're saying that you have the line breaks and formatting in your actual word list file? If so point me to the link and I'll figure out how to do it. I know that flashcards support it in general, just wasn't sure how to specify that myself in an import file.

Never mind - found the file....

 

[ipsi]

Yeah, you need to enter private-use Unicode code points. Can't remember them off the top of my head, but a good text editor should give them to you from the file.

 

[ldolse]

If it's the same ones as Pleco 1.0 then I'm good to go. Now I just need to figure out which text editor to use on a mac... Switched over recently and haven't found one that's as good for handling custom code points as the PC editors....

 

[Alexis]

Alexis - the reason that C-E search is listing all of the entries in the dictionary is because it's only finding one match; whenever you do a search in Pleco with only result, it jumps you right to that result in the dictionary ('dian' instead of 'guo' List Mode icon), since there's not really much point in displaying a list with only one entry in it.[/quote]

I would suggest that there is value in displaying the list with only one entry:

1) The user does not have to check the guo/dian button to see if the list displayed is a list of search results or is a list of dictionary entries
2) The user does not accidentally click on the next entry and then wonder why it's not relevant.

Basically, makes the results more consistent and intuitive (IMHO).

 

[mikelove]

mfcb - there's no "NOT" option for categories yet, unfortunately - it would be both really tricky to implement and very slow, though it's another one of the things we might consider adding once we drop Palm OS support (taking away the "slow" argument at least).

Your earlier issue with 萝卜 incidentally turned out to be a different sort of font bug that we actually could fix, so the soon-to-be-available b8c should clear that up.

llammamama - flipping the results might help, though it introduces another sort of confusion in that people would be used to a different orientation in other handwriting input screens (like the regular Input dialog) - however, since there's no change in functionality (you're still looking at all of the characters in the box to identify the right one) I guess it wouldn't be too problematic. Putting recognize closer certainly makes sense.

ldolse - the tricky thing about displaying radical characters instead of numbers is that we have to pick the correct version of a given radical for a given character; we don't do that in the stroke order radical display, resulting in the as-yet uncorrected bug that traditional characters are still shown with simplified radicals. Certainly not impossible, but it would be a lot more work than just pulling characters from a table, particularly since UniHan doesn't really have any fields that we could get that information from.

The code points for newlines / boldface / etc are different than in 1.0, but you don't even need to worry about them anymore (and in fact probably shouldn't, since they're unofficial and could change again in a future version) if you just do the import with XML instead of text - regular newlines embedded in XML import definitions should come through fine in Pleco.

Alexis - that's tricky because of how regular E-C searches work; in those, since the headwords are in alphabetical order, rather than searching for all entries that start with the search query we simply jump you to the one that appears first in the dictionary, so there's never a list of search results. And that seems like a much more useful behavior in those cases. I don't really think checking guo versus dian is much of an imposition - you don't even have to do that, actually, you can just check the scrollbar / scroll arrows to see if you're at the top of the list or not.

 

[ldolse]

I'm fine with the same bug existing on both the character detail and stroke order tabs, it would still be more useful to show a canonical simplified radical vs. the specific variant.

Regarding the formatting, how would I do bold in the new format? Is it just html bold tags?

 

[mikelove]

There's no official way to do bold yet, unfortunately - it's a bit of a tricky issue because we're not sure whether to use HTML-type tags in the database, use our own tags, or use private-use characters like we do now. A lot of these sorts of schema issues probably won't be resolved until there's an official desktop version.

Unofficially, the current private-use tags are EAB1 for newlines, EAB2/3 for bold and EAB8/BB for copy-whatever's-in-this-to-the-Input-Field hyperlinks, but those tags are NOT guaranteed to remain the same in future versions, we wouldn't be likely to release a converter utility if we did change them, and in addition to losing formatting they might potentially be mapped to some other undesirable behavior (like "hide all of this text" or "don't render any more of this entry" or "make an annoying beeping noise whenever this entry is viewed"), so keep that in mind if you use them in your database.

Oh, and while I'm spilling the beans, colored text can be done with private-use tags too: EAC1 followed by two characters with the highest-order bit 1 and the lowest-order 12 bits representing the first/second halves of a 24-bit RGB color value to start the range, EAC2 to end. So to render a character in green, for example, you'd want EAC1 800F 8F00, then the character, then EAC2. But again, if you use that you should not expect it to keep working in future versions, and since (unlike the bold / link tags) it's not even embedded in any of the database files but is only created by our own entry-formatting code, it could change again in even a minor bug-fix release.

 

[stephanhodges]

I'd suggest basically using your own tags, so that you can "remap" them when and if you need for different underlying technology.

Also, perhaps a good subset to use would be BBS markup, although that's just off the top of my head.