This latest GrampsAIO should fix the spell checker issues.
The new GrampsAIO no longer throws a console error for missing dictionaries.
But the format of Dictionary files that are installed from the AIO are evidently not compatible with the spellcheck library … or maybe just the format it expects in a folder labeled hunspell. With spellcheck enabled, every word in every note is marked as misspelled.
But replacing the dictionary files with downloaded hunspell dictionaries let the spellcheck and suggestions work. It did NOT allow adding words to the custom dictionary. “Add” behaved like an “ignore” while that particular Note was open.
It is probably just a character encoding issue. We can always look for an alternative site from which we can download hunspell dictionaries.
I’m pretty sure they’re not, but in the 5.1.6 AIO, there are still 4 for en_GB, and 3 more for nl, next to our own gramps.mo.
And this suggests that the old AIO installer (or its auhor) was aware of the dependencies, in some way. And technically, the situation is that some DLL’s that we include have dependencies, that must be included, and this new AIO is a bit too radical, in the sense that it doesn’t include any, or all, with your latest change, and neither is good.
I had quite a busy week, but I may have more time this weekend, so I may be able to help, by looking at the code of the old AIO, if I can find that. And I hope that this can also tell me why the new 5.2 doesn’t detect the UI language in Windows, 10 or 11, and works well in Wine.
There is another approach, and that’s a program that was once distributed by Microsoft, with the Windows SDK that I used in the early nineties, and that’s called dependency walker. It’s still available, and it may help if we can’t find more clues in the old AIO.
It’s been a while since I used it, and I have no idea whether it actually lists dependencies on MO files, but it might be worth a try.
Gramps loaded with this new build.
Symbol error is resolved with this build.
GitHub Pull Request 1508 and MantisBT Bug Report 12965
1 Like
Follow-up: I checked both dependancy walkers, and they did not reveal which MO files are needed.
This is a circular reference. The link comes back to itself.
Where is the original note about it being fixed so we can close it (and bug report 12965) with link to a specific PR# or commit?
(Since the AIO builds have not been numbered, we cannot trace a change back to a “this build”. The problem still occurs on the AIO build posted on 13 Aug. Everyone seems to be on different builds and the hexadecimal ID is too difficult to decode and determine which is newer.)
@DaveSch
Nope. That links to the message 44 in this Discourse thread 3968,jumping to just above message 45. Message 45 links back message 20 with now links to message 45! I need a link to the conversation on GitHub
(And to break the loop to the future in the thread at message20!)
The fix for genealogical symbols was in PR #1508.
1 Like
@Nick-Hall @prculley jralls
Glad to report that my PR to restore bsddb3 v6.2.29 including a fix to resolve the clang compiler failure, which initially led to the package’s removal, has been merged into MSYS. At some point bsddb3 will once again be available to download directly from the MSYS package repo 
2 Likes
Is there a patch to fix Mac builds for bsddb3? When I run gramps beta and try to load a BSDDB tree, I get:
./Gramps
2023-08-16 11:18:09.199: WARNING: _manager.py: line 333: Plugin error (from ‘bsddb’): No module named ‘bsddb3’
2023-08-16 11:18:19.870: ERROR: dbloader.py: line 107: can’t load database backend: ‘bsddb’
I applied the patch for Arabic instead of English and that is resolved.
Did you try the Convert?
The conversion is a one-way option and precludes future testing on the file if BSDDB support changes. So you should duplicate the BSDBD database folder before trying it.
It cannot convert a BSDDB. The error I get is:
An attempt to convert the database failed. Perhaps it needs updating.