Currently I’m planning to make word groups contain every word meaning for a single item, so it won’t be possible to add the same word multiple times to a single word group, nor to only pick some meanings. The idea behind separate items for meanings was that it’s easier to learn only one or two meanings at a time, and it makes printing vocabulary lists easier too, as they fit in a smaller place. The downside is that it’s both harder to implement and didn’t even work too well in my opinion.
So in the future word groups will only contain a word once, and those will have every meaning of the word. To make studying them and printing a vocabulary list useful, the user will be able to enter a custom meaning for the word. (Or to be more precise, words will share their word group and long-term study definition.)
As usual, if you don’t like this idea and have a better one, write a comment.
As I have to rewrite everything, I’m not only trying to achieve the same functionality of zkanji, but add some stuff I always wanted to. I never got to it because there were so many things to change for every small thing. Now that I have to rewrite zkanji anyway, it doesn’t matter anymore so I can do it as well.
For example in the new version, you can look up words with the kana in the middle of a word. There’s also a button to look for the exact kana characters. Before, if you had the button ?+ pressed and then typed あ, the results contained words ending in か or さ etc. Now if you check the “exact kana” button, only words ending in the kana あ will be found.
Another long awaited functionality was to enter kanji or kana directly with the system’s IME. This is finally possible. (But romaji is still converted as usual.)
As the title says, I’m currently working on word groups. In the past zkanji versions, single meanings are added to word groups. If you want to add several meanings of a word to a group, each of them are added as separate items. The change here is that I want the user to be able to select several meanings, and add them as a single item to a group. I still haven’t decided how to handle the case when you try to add a meaning to a group that contains the word already with different meanings. Should it merge the meaning with the existing item or add it as a separate item? I have to think about the reasons why someone would want to do one or the other. Or rather, if there’s a reason to add a separate item. Writing zkanji is a huge task and not adding unnecessary functionality (even if it sounds cool at first) will make it happen faster.
What is your opinion?
As usual, if I get no opinions I’ll just decide one thing and if someone complains later, it’ll be already too late.
Creating a usable and safe backup system is my last aim for the next release, before I go over the user reported bugs and complaints. Just like most other things that seem simple at first glance, this is also not as easy as it looks like.
In past releases, zkanji created a copy of successfully loaded files in the user data folder with the TEMP extension, after loading them. (Thinking about it, isn’t the TEMP extension a bit misleading?) The user had a single safe(?) copy of data files that loaded correctly, or at least which didn’t generate an immediate error. Past backups were overwritten. This solution worked fine in the utopian world in my mind, that is, if errors occurred on load (which is not very likely). Unfortunately there has been a case at least once, when a user only noticed a few days late, that something is not right with his/her data. This situation is obviously not solved with our simple backup.
The obvious solution would be to keep a backup of all user data files for the past few days, or even weeks. I started working on this solution, but there have been a few things that bugged me about it all along. In the new data handling system, users will be able to change their main English dictionary, so a safe copy must be made. The dictionary file is nearly 25 megabytes, and even without the few additional kilobytes of user data, making several backups of this size is not an acceptable solution. As I’m working on a dictionary in a different language, the total size for me would be nearly 35 megabytes. In my experience, at least 2 weeks of backup is necessary to be on the safe side, which equals to 350 megabytes normally, and in my case nearly half a gigabyte! We can probably do better than that.
If someone never changes his or her main dictionary, and the only files to save are groups or study data, not saving unchanged files can keep the size of backups to the minimum. This is seemingly a good solution to the problem, unfortunately this brings the complications to a whole new level. How can we know that the main data file has not been changed? We could read it and compare it to the unchanged dictionary data (there is a data file which is not touched, but is required for the update system to work). Comparing files is slow, and nobody would want to wait the additional seconds every time zkanji creates new backups. I also thought of comparing file times, but if a user unintentionally changed the main dictionary, and reverted the changes later, the file times would be different while the data is the same. Not to mention the case when the user data is on some central server and files have to be read and written several times over a network. (I know of at least one such case.)
As I have decided not to do any kind of complicated magic that can be slow as well, a compromise is forming in my head. (This is just the current idea which can be rejected in the next second.) Keeping 2-3 backups of each file doesn’t seem to be that much of a burden. If the files are backed up at some longer intervals, for example every 4-5 days, and are not kept for too long, the user can enjoy a relative safety which is relatively cheap. Data loss happens, but this way only a few days worth of data would be lost. If the user only notices some problem a week later, this is still better than losing everything. (In case you have terabytes of space for backups, you will be able to tweak the interval of days and number of backups in the settings.) Safe copies of data would be created once on startup, or if you are the kind of person who doesn’t power off their computers for months, I’m considering checking the running time of the program as well, and creating a copy when the time comes.
You will be able to hide the kanji list, the group list, the dictionary or any combination of two areas by dragging the splitter near the window border, starting from the next version. Just thought I would post about it.
I have decided to create a separate import for groups and dictionaries, because in some edge cases with a shared import, users would have to deal with 3 separate dialog windows with complicated selections one after the other.
The dictionary import will offer the option to completely replace a dictionary with the imported data (for full dictionary exports or when a free dictionary was converted to the export file format), and another option to expand an existing dictionary with the words in the export file. Making the former case requires no additional work as it is the same as normal dictionary updates. The latter is rather for a community working on a single dictionary, so they can share the few words they changed in the past month or some other short time. It is a more complicated problem but will be very similar to how groups are imported when there are differences in word definitions in the exported file and the current dictionary. Users will be able to select which differing words to import from the export file, adding new entries or changing old ones. This can affect already added words in existing groups. Dictionary expansion can’t deal with the case when words get deleted, so people working on dictionaries will have to do full export/imports from time to time, but it is easier if they don’t have to do it all the time.
Writing the group import is more complicated, because it is usually not the intention of users to change the dictionary, but I still want to allow it. First the same dialog will be shown that is used for expanding the dictionary (only when needed), but in this case I can’t avoid showing a similar dialog again. Once the dictionary is updated (or kept unchanged – it is important to be able to do this easily as well), a dialog will be shown for words that cannot be imported directly because of some conflict with existing groups or because their definition was not added in the first step. Users will be able to either select a replacement word in problem cases or choose to skip importing that word.
This much complexity can’t be avoided when the data is in such a complex relation. Hopefully in general cases, users won’t see any dialogs. There is no need for them if the dictionaries match and the groups don’t already contain conflicting definitions. Unfortunately, we are always dealing with the same kind of data, so the dialogs must be very similar, even identical at times, which can confuse users. I don’t know how to help with this, but if users complain I will come up with a solution.
The release of the next version of zkanji has been delayed a good 10 months already for the single reason that huge changes took place in its data format, and for that reason the export and import feature became unusable. (Translation: reason of delay = laziness.) You can ask “So what? Why not just release it and add export and import later, like other features?” I could do that of course, but there is a difference. I usually only remove features if I don’t intend to support them in the future, and some users couldn’t use the program without export and import. I think both are reasonable.
Now that this is out of the way, I’ll write a bit about the previous concept image of the data export dialog. You can see that I have thought of four sections. Dictionary, word groups, kanji groups and long-term study list export. After a bit of thought I realized that the dictionary and word group export both has the same kind of data. Not just the words’ kanji form and reading must be exported, but the meanings as well. This is obvious for the dictionary. The word groups contain words, but only specific meanings are added. In the near future I plan to change this a bit to be able to include several or all meanings for each word entry in a word group, but it will still be possible to only add some meanings. The biggest problem here (like with everything) is that the dictionary can change between releases, sometimes splitting meanings or changing them altogether. If the export file didn’t contain the word meanings, it would be impossible to check this at the time of import. The only additional data that must be exported with the dictionary is the word usage types and word frequency so the two are very similar.
It’s a simple case if the dictionary has the same words and definitions when importing (though there still can be conflicting word groups which require user interaction), but when the dictionaries at the time of export and import differ, the program should probably allow users to update the target dictionary not just for dictionary imports, but word group imports as well. When I took a break from developing zkanji 10 months ago I had this same problem, and it is still difficult. Thus I think that I’ll first make the export/import with a bit crude interface, and if users can propose something better I’m going to change it. Because this doesn’t usually happen you will probably have to put up with that interface for life. 🙂
I can’t think of such difficulty with kanji group and long-term study list export/import. The kanji group might have to handle words that are selected as examples for kanji, but the meaning is not important there. The long-term study list holds meanings for the words but those either depend on the current dictionary, or can be independent, in which case there is no need to do anything with the dictionary.
This is a concept image for a new dialog window, where the user can select data for export to be imported later or on a different computer. This might still not be final, but I’ll try to finish this and only change it if something comes up. There will be a few pages of this export window, but even from the main panel you can see all the features it will offer. Maybe this dialog is a bit wordy compared to previous ones, but at least nobody can say that I’m not trying to make it user friendly. :p