Having a dictionary database fulfilling the requirements for inclusion into FreeDict, here you find the background and the steps to get your dictionary into FreeDict.

Overview of the FreeDict Build System The data flow from the point of view of the FreeDict Build System originates in the FreeDict CVS repository. From there checkouts are made to buildhosts, where the data is converted to the formats of the supported platforms and where the FreeDict website is generated. The most interesting metadata is collected in an XML file. That is used to build the download and details pages on the FreeDict website. Other projects may use that XML file to find out about new releases of the FreeDict databases.

A strength of FreeDict is its support for different dictionary platforms. Once a dictionary is available in TEI format, it can be converted to many other formats, to be used with dictionary applications, spell checkers (for this only the headwords or translation equivalents are taken), for printing a book using XSL-FO etc. Support for aspell and XSL-FO is still a wish. This is enabled by two factors. First, XML is purposely very flexible. Second, the tools for converting the TEI files are kept in one place (the tools module) and are shared between the dictionary modules. The backbone of the FreeDict build system is the file Makefile.common in the tools module. It is designed to be included by the Makefile of each dictionary module. Every Makefile of a dictionary module should start with these lines: FREEDICTDIR ?= .. # Adjust per dictionary variables like DISTFILES, TEI2DICTFLAGS, DICTFMTFLAGS etc. DISTFILES = la1-la2.tei README Makefile NEWS include $(FREEDICTDIR)/tools/Makefile.common # Optional, space separated list of platform identifiers: # Default: all supported # UNSUPPORTED_PLATFORMS = evolutionary bedic # Add targets specific for this dictionary module, # eg. instructions how to create the TEI file from # another source format. In the first line, FREEDICTDIR is per default set to the parent directory. If you have set FREEDICTDIR to something else, that value will be used. In the next lines you can optionally adjust some variables. After that, the Makefile.common is included from the tools subdirectory of the FreeDict directory. Makefile.common provides the support for the following targets (as well as some more internally used targets): validation validates the TEI file of the dictionary module. find-homographs Looks for "double-entries" in the TEI file of the dictionary module, ie. entries with headwords that follow the same orthography. test test-reverse tests whether all words can be looked up from the dictionary in dictd by extracting a list of headwords, starting a dictd server and looking up each headword in turn release-dict-tgz release-dict-tgz-reverse release-dict-tbz2 release-dict-tbz2-reverse release-dict-tbz2-c5 release-dict-tbz2-c5-reverse release-evolutionary release-rpm release-bedic release-zaurus puts a release file for the specified platform into the corresponding directory of $(FREEDICTDIR)/release. query-PLATFORM Make will exit with an error message and an exit status of 1 if the PLATFORM in question is not supported by this dictionary module. Which platforms are supported is determined by the UNSUPPORTED_PLATFORMS variable. This target is used by the release-PLATFORM targets as a guard to prevent builds for unsupported platforms. The support status information is also saved in freedict-database.xml dist puts a release file of the dictionary module source into $(FREEDICTDIR)/release/src. commit shortcut for cvs -z3 commit. The -z3 is forgotten too often. version sourceURL status extracts these pieces from the TEI header and prints them on STDOUT. Used during dbupdate. dbupdate extracts interesting information from the dictionary module and writes it into freedict-database.xml. all default target. It currently converts to dictd database format without packaging the result as a release. In the future it would make sense to generate the files for all supported platforms when this target is invoked. clean removes the non-source files generated during the build of anything from the dictionary module. The FreeDict CVS Repository is provided by SourceForge. The repository name as specified to the cvs command is freedict.cvs.sourceforge.net:/cvsroot/freedict. SourceForge provides two different access methods, ext (using SSH) for developers and pserver for anonymous read-only access. The modules in the repository fall into two groups: dictionary modules and "special modules". Special modules are presently only the tools and howto module. The former contains conversion scripts, XSLT stylesheets, test scripts etc. used by most dictionary modules. The latter contains the XML source of this HOWTO. The following modules are unused: website, htdocs, spa-spa, eng-ger, ger-eng. One of the first two should be reactivated, though.

For naming the dictionary modules and their TEI files we use the format la1-la2.tei, where la1 and la2 are ISO 639-2/T 3-letter language codes (ISO 639-1 defines the two letter codes; the "T" stands for "Terminology"). See also the ISO 639-2 Registration Authority, where this standard is made.

If you are a developer of FreeDict and have write access to the repository, you can import this way: cd la1-la2 This step assumed you keep all files related to your new dictionary in a directory la1-la2, obviously. Importing has to be done from the directory itself, otherwise CVS will create an ugly subdirectory like la1-la2/la1-la2 that will not be removable from CVS again (it contents can be removed, but not the directory itself) - so please be careful! cvs -z3 -d:ext:developername@freedict.cvs.sourceforge.net:/cvsroot/freedict import la1-la2 vendortag releasetag If your dictionary doesn't come from another place, you can invent dummy values for vendortag and releasetag. Otherwise, use them as intended by CVS: If you import files from some upstream project, use that project's name as vendortag and that project's release version as releasetag. If you do not have CVS write access, ask a developer to import your TEI file (or eventual code to create the TEI file from a different format) into the FreeDict CVS repository. At present it is still undefined whether to import a TEI file as well, when it can be made from other sources. The cleanest solution in such case would be not to import it, but to import the sources and create a file release of the TEI file.

If you have a directory containing the tools module as well as one or more dictionary modules, you already have a FreeDict build tree. If you sometimes work on dictionary modules outside the FreeDict build tree (hey, it is a synonym of FREEDICTDIR!), you can set up the environment variable FREEDICTDIR to point to that directory. Afterwards the Makefile will be able to find the tools directory. There also is a special kind of build tree, the release build tree. This tree does not contain the latest CVS revisions of all files, but it is intended to contain only the revisions that the maintainers of the dictionary modules have marked as stable. For more information, please refer to the manage-buildtree.pl script in the tools directory.