[LH#3405:FIXED] hunspell language directories, dictionary downloading, and contents creation

First, a bug.

I used Scrivener to download additional dictionaries. Several in a row. When you do this, sometimes (not all the time), Scrivener puts other dictionaries in that directory.

I downloaded Hungarian yesterday. Today I downloaded Icelandic, after restarting Windows and Scrivener. Everything should have been cleared after restarting the OS and the program, right?

The Icelandic directory now contains BOTH Hungarian and Icelandic files.
hu.aff, hu.dic, is.aff, is.dic, and the readme files for both languages.

I downloaded Catalan-roa-es-val and Vietnamese-vi-dau-cu, and while that Catalan directory only has the Catalan files in it, the Vietnamese directory has both the Catalan and the Vietnamese files in it.

Scrivener will not recognize those extra files; the coding is very specific. Catalan-roa-es-val contains roa-es-val.aff and roa-es-val.dic, and those are the only files Scrivener cares about in that directory; it ignores the others. But they do take up space, and downloading them takes bandwidth (I think Scrivener is re-downloading them, but I cannot be positive).

Scrivener is saving some sort of state related to downloading dictionary files.

Second, an observation.

Scrivener is pretty consistent about spelling directory naming and contents. If the directory is named SomeLanguage-sl, the contents will be named sl.aff, sl.dic, and README-sl.txt, with other README files on occasion. But there are two exceptions, and both are Vietnamese.

The Viet directories are named Vietnamese-vi-dau-cu, and Vietnamese-vi-dau-moi. The Viet dictionary files are named vi-daucu.aff, vi-daucu.dic (both for the first), and vi-daumoi.aff, vi-daumoi.dic (both for the second). Note the second hyphen is missing. The README files are README-vi.txt and README-en.txt for both. This is inconsistent; I cannot call it a bug, because it really isn’t; it’s just inconsistent compared to the rest.

Thanks for the report. We’re currently working on the dictionaries, and I’ll make sure the developers are aware. If you find steps to reproduce the bug with the files downloading into the wrong directory, that’d be especially helpful.

Managed to reproduce it, and this time I have 2, 3, and 4 sets of dict files in various directories.

Here’s how to make this happen:
Options > Corrections > Download.

Dictionary menu appears.

Click on a language. Download it. Do not close the menu.
Click on another language, without closing that menu. Download it. You will now have two sets of files in the directory for the second language. As many times as you do that, the last one’s directory will have that many sets of dictionaries in place.

I think a variable isn’t being cleared after the download is finished. It’s being cleared when the menu is closed. It may not even be cleared; the programmer may be relying on menu closure to clear it. As well, the variable is being appended to somehow and not being overwritten. At least, that’s how it acts. Should be a fairly simple fix, but I could be wrong.

It is actually downloading the dictionaries again; the last DL when I got 4 of them in one directory, I saw the progress bar hiccup three times. Shift-click and ctrl-click do not work in that menu, so if you want 5 dictionaries, you have to DL them one at a time. To avoid the repeat download, do not DL repeatedly from the dictionary menu; close the menu and reopen it (not difficult, but when you’re impatient, do you think about it?).

Some of the readme.txt files will be overwritten, too, as sometimes they are not all named by language (I suspect they should be. It may not matter, as long as some readme file is in there, but some of them are in those languages, so it may matter). Greek-el-GR, for example, has a readme file named readme.txt, and not README-gr.txt. And it overwrote Chichewa’s readme.txt file. Scriv doesn’t know about those, but the license requires the readme file to be present, as it contains the copyright and licensing information.

Still happening. NOT fixed yet.

This has been filed and will be fixed in the next release.