stephanhodges - I'm not quite clear on this import bug; so 乱 mapped to Guifan instead of ABC? Were there traditional characters / Pinyin on the input line? Are you sure the remapping worked (i.e., checked back on the card and it actually reflected the ABC definition)? And you definitely should be able to export custom flashcard definitions - was the checkbox for that enabled in the Export screen?
With the keyboard tab switch, was that the first time you shifted the keyboard during that session? Good point on bounce-checking for hardware buttons, no reason we can't apply the same check to them that we do for onscreen ones.
gandq - it looks like the audio/stroke order features are included in your keyfile, so it probably is something on the installation end. Make sure you installed both sets of audio files (basic along with extended), the extended audio won't work by itself.
Ajo - both of those errors are actually present in the original Oxford dictionary too; it doesn't include a traditional translation for the 們 in 我們 nor does it include one for the 險 in 風險, both appear in simplified-only in the printed dictionary. Since the Oxford unlike our other dictionaries actually does include traditional characters in example sentences / definitions, we wanted to stick as accurately as possible to their traditional character conversions rather than re-converting the entries ourselves. I'll make a note that we should re-check them (no reason we should refuse to change something when it's clearly wrong), but it probably won't happen until after 2.0 is released since the current database is at least faithful to the printed version.
The Duelist - thanks, but we're still having no luck at reproducing this. I'm starting to think it might be a hardware issue - if you use PlecoMover to move your flashcard database to an SD card (and set the version in internal memory to Backup), does that help any? What if you move your other Pleco database files to an SD card as well? (so there's as little as possible left in your Palm's internal memory)
gaokang - well I guess this is better than not starting up at least
But we haven't seen this problem on other devices - are you using Input Field Compatibility Mode? Any other preferences changes?
goog1e - interesting; nothing particularly unusual about that character code (unicode 0x801C), so I'm not sure what could be causing this.
With the keyboard tab switch, was that the first time you shifted the keyboard during that session? Good point on bounce-checking for hardware buttons, no reason we can't apply the same check to them that we do for onscreen ones.
gandq - it looks like the audio/stroke order features are included in your keyfile, so it probably is something on the installation end. Make sure you installed both sets of audio files (basic along with extended), the extended audio won't work by itself.
Ajo - both of those errors are actually present in the original Oxford dictionary too; it doesn't include a traditional translation for the 們 in 我們 nor does it include one for the 險 in 風險, both appear in simplified-only in the printed dictionary. Since the Oxford unlike our other dictionaries actually does include traditional characters in example sentences / definitions, we wanted to stick as accurately as possible to their traditional character conversions rather than re-converting the entries ourselves. I'll make a note that we should re-check them (no reason we should refuse to change something when it's clearly wrong), but it probably won't happen until after 2.0 is released since the current database is at least faithful to the printed version.
The Duelist - thanks, but we're still having no luck at reproducing this. I'm starting to think it might be a hardware issue - if you use PlecoMover to move your flashcard database to an SD card (and set the version in internal memory to Backup), does that help any? What if you move your other Pleco database files to an SD card as well? (so there's as little as possible left in your Palm's internal memory)
gaokang - well I guess this is better than not starting up at least
But we haven't seen this problem on other devices - are you using Input Field Compatibility Mode? Any other preferences changes?goog1e - interesting; nothing particularly unusual about that character code (unicode 0x801C), so I'm not sure what could be causing this.
