I am not aware of an existing naming convention, but this is how Arch Linux handled it:
https://archlinux.org/todo/packaging-qtwebengine-dictionaries/
Specifically, here is how their hunspell-de package names the files:
https://archlinux.org/packages/extra/any/hunspell-de/
Note that Arch Linux places the files in usr/share/qt/qtwebengine_dictionaries/ and a symlink from usr/share/qt6/qtwebengine_dictionaries/. However, on my current Debian testing system the output of qmake -query according to the instructions at <https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker> indicates the correct directory is /usr/share/qt5/qtwebengine_dictionaries (with the symlink for future compatibility).
~$ qmake -query | grep QT_INSTALL_DATA
QT_INSTALL_DATA:/usr/share/qt5
My personal testing confirms that if if a .bdic file is placed in /usr/share/qt5/qtwebengine_dictionaries any program that uses a Qt WebEngine is able to find it (although the program still has to have code that chooses to use it).
The en_US.bdic that I compiled from the current en_US.dic and en_US.aff is 691.2 KiB.
--
Soren Stoutner
I recently posted in the debian-kde list about packaging the Qt WebEngine dictionaries to see if there was any preference about how they should be named or where the files should be located. So far there have not been any comments.
https://lists.debian.org/debian-kde/2022/09/msg00011.html
If you would like I could attempt to create a patch to enable the building of these files. I am new to Debian packaging, but I have been reading over the documentation and have some idea of how to put it together.
As Rene Engelhard <re...@debian.org> objects to the placement of the .bdic files in /usr/share/hunspell, and because it would generally be a good idea to include as many Hunspell maintainers as possible and document the consensus in a central location as to how these dictionaries should be packaged, I have created a bug report against dictionaries-common at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020387 . It would probably be a good idea to hold off on uploading these changes until that consensus is reached.