While gtkspell expects libenchant.dll, copy libenchant-1.dll to the
alternate name (setup.py expects both while this is the case)

Remove the .dll files of dependencies shipped with pyenchant (iconv, glib,
gmodule, intl) – they conflict with the ones coming from GTK but are
picked up by setup.py for some reason

iso-codes – if you want translated language names

libproxy and its Python binding, which might be called something like
python-libproxy on your system – improved support for proxies on Linux
(since Virtaal 1.0)

The optional fts3 module for sqlite3 will be used if it is available -
provides speedups with TM retrieval (it is safe to just overwrite a better
sqlite library over the one available in Python for Windows)

libtranslate – used by Machine Translation plugin

psycopg2 – for TinyTM plugin

python-Levenshtein – speeds up Levenshtein distance measures, if not present
we’ll use a pure Python version.

For users running from a tarball, we do some dependency checking when starting
Virtaal to be able to give accurate error messages in case of missing
dependencies. However, if you have all of these sorted out in your package
dependencies, there is no need for Virtaal to do this any more. In the file
bin/virtaal, uncomment the line

#packaged = True

by removing the hash sign. This way Virtaal can start a bit quicker with no
loss of functionality.

For the translate-toolkit, be sure to get the Python library – the
one marked win32.exe – and not the stand-alone Windows installer, which
is labelled setup.exe. You might need to create this yourself with

This is just some notes – it is incomplete and might be entirely off the mark.
Virtaal and all dependencies run on OSX, but we still need help to document the
simplest process, and to build installable packages.