User-Created Dictionaries - Modifications kill flashcards?
- Thread starter ipsi
- Start date
Well, you could try importing the new dictionary as a flashcard file if it's not too big; any entry in a flashcard file with a definition automatically has a user dictionary entry created to hold that definition, and once they were in there you could then edit/delete/add to them while preserving the flashcard links. But aside from that the best bet is probably to wait for 2.0.
Unfortunately, I have a fair few entries, and I don't really want to clutter my user dictionary with them... I guess I'll wait for 2.0.
Will it be possible to modify free / user created dictionaries directly from the interface in 2.0? Or will I have to recompile any I've created with MakePlecodict?
Will it be possible to modify free / user created dictionaries directly from the interface in 2.0? Or will I have to recompile any I've created with MakePlecodict?
We're still going back and forth on that one, actually, in fact we may even make it the subject of a survey question. Basically, Pleco 2.0 supports two different dictionary database formats; one of them is faster, smaller, and non-editable, and that's the one we're using for all Pleco-released databases, and the other one (based on SQLite, just like the new flashard database) is slower, larger, but does allow entries to be edited, and that's the one we're using for dictionaries created by users on their PDAs.
The question is which of these formats to use for dictionaries created by users on desktops - smaller and faster but non-editable, or slower and larger but editable. We're leaning towards the latter, since these databases can be stored on memory cards (eliminating the size problem) and the speed should be more than acceptable on most systems. Plus, since it wouldn't be sharing the same format as our paid databases (like the current user dictionaries do), we could make the source code for MakePlecoDict 2.0 publicly available, allowing anyone else to create their own dictionary creator/manager utility.
The question is which of these formats to use for dictionaries created by users on desktops - smaller and faster but non-editable, or slower and larger but editable. We're leaning towards the latter, since these databases can be stored on memory cards (eliminating the size problem) and the speed should be more than acceptable on most systems. Plus, since it wouldn't be sharing the same format as our paid databases (like the current user dictionaries do), we could make the source code for MakePlecoDict 2.0 publicly available, allowing anyone else to create their own dictionary creator/manager utility.
I fully support the idea to go with the SQLite format for user-created and free dictionaries. Which are really the same, I guess. I'd also be quite happy if the source code for MakePlecoDict was released as open-source. As would a number of Linux Users, I imagine 
It would also allow other people to make a GUI front end for it, if you decide that you can't afford that much time for a free app.
Yeah, I'd say definitely go for the editable format. The number of possibilities it opens up definitely outweighs the loss in speed and size. At least, to me it does.
It would also allow other people to make a GUI front end for it, if you decide that you can't afford that much time for a free app.
Yeah, I'd say definitely go for the editable format. The number of possibilities it opens up definitely outweighs the loss in speed and size. At least, to me it does.
Not quite the same, actually, free dictionaries would still be non-SQLite since they don't really need to be editable and the speed/size advantages become more important when 10,000 people are downloading and installing a file.
But yeah, as sfrrr correctly surmised I'm leaning towards editable and it definitely seems like the case for it is stronger - technological advances will pretty much kill any performance concerns in a few years anyway.
But yeah, as sfrrr correctly surmised I'm leaning towards editable and it definitely seems like the case for it is stronger - technological advances will pretty much kill any performance concerns in a few years anyway.
Fair enough on the free dictionaries. Does the number of entries impact performance? I'd be surprised if it didn't. Given that, I imagine most user-created dictionaries will be quite small, thus giving you another reason to make them in the SQLite format. Although I would need to see how it performed before I could give a really accurate answer, I don't imagine I'd be seeing much difference. I also don't use my user-created dictionary as an actual dictionary for the most part, but rather as a way to keep my flashcard data seperate from any User Dictionary entries.
I'm hoping, as this thread's title suggests, that you can actually create more than one user defined dictionary? Perhaps one to hold copies of uploaded flashcard (user defined) definitions, and another one (at least one other) to hold manually entered items.
I personally don't like seeing several hundred entries in a user dictionary when i didn't actually enter them there. I want to see the items I've entered (usually things that aren't in the current dictionary but are in my text book). This makes it easy for me to submit new definitions to various dictionary sources (CeDict, Wenlin, etc). I've submitted quite a few to the Wenlin people, and they always review and add/change items as appropriate, for example.
I personally don't like seeing several hundred entries in a user dictionary when i didn't actually enter them there. I want to see the items I've entered (usually things that aren't in the current dictionary but are in my text book). This makes it easy for me to submit new definitions to various dictionary sources (CeDict, Wenlin, etc). I've submitted quite a few to the Wenlin people, and they always review and add/change items as appropriate, for example.
It's currently possible to have multiple ones, but they have to be compiled on a desktop and then copied across to your PDA, which is what we're talking about here. And hopefully making them user-editable from within Pleco, in 2.0.
You can create them using MakePlecoDict, which can be found somewhere on the website.
You can create them using MakePlecoDict, which can be found somewhere on the website.
ipsi - the number of entries does impact performance a little, but actually SQLite scales up very well and the difference between 100 and 10,000 entries should be barely noticeable on most systems.
stephanhodges - actually, custom flashcard definitions in 2.0 are independent of user dictionary entries; we're making this change mainly because people often want to have a shorter or textbook-approved definition for a word that's already covered by our built-in dictionaries. There's a nice little Edit Card screen where you can look at a dictionary-based card, tap a control to convert it to a custom card (the word and Pinyin fields are automatically filled in for you based on the original dictionary-based one), and then fill in your own definition which becomes the main definition for the card. If you want to switch back to a dictionary definition later, you can use the same screen to find a matching dictionary entry and re-map the card to that entry. Nobody seems to like automatically linking flashcards to user dictionary entries, so we've been planning for a while to get rid of that in 2.0.
stephanhodges - actually, custom flashcard definitions in 2.0 are independent of user dictionary entries; we're making this change mainly because people often want to have a shorter or textbook-approved definition for a word that's already covered by our built-in dictionaries. There's a nice little Edit Card screen where you can look at a dictionary-based card, tap a control to convert it to a custom card (the word and Pinyin fields are automatically filled in for you based on the original dictionary-based one), and then fill in your own definition which becomes the main definition for the card. If you want to switch back to a dictionary definition later, you can use the same screen to find a matching dictionary entry and re-map the card to that entry. Nobody seems to like automatically linking flashcards to user dictionary entries, so we've been planning for a while to get rid of that in 2.0.
Sounds good Mike. I can't wait to see the new version of Pleco .
While I'm at it, MakePlecoDict seems to crash if it encounters a space anywhere in the names the user enters. I'm not sure if this is a bug or not? I've actually got a few other bugs, but I'll send you those (they're not MPD ones) when I'm not on a Treo.
.While I'm at it, MakePlecoDict seems to crash if it encounters a space anywhere in the names the user enters. I'm not sure if this is a bug or not? I've actually got a few other bugs, but I'll send you those (they're not MPD ones) when I'm not on a Treo.