You are viewing a condensed mobile version of this NASPA webpage.
Switch to full version.
Until version 3.5.0, NASPA Zyzzyva (NZ) and NASPA Zyzzyva Mobile (NZM) only supported lexicons that use the A-to-Z letter set and its frequencies and values. We built licensed lexicons (NWL, NSWL, and CSW) into each version, and users could add one custom lexicon.
We’ve completely reworked Zyzzyva so that users can create multiple custom lexicons by plugging them in. As part of that effort, we updated Zyzzyva to accommodate other letter sets and their differences, and created a way for international organizations to make their lexicons “pluggable” with the assurance of authenticity that Zyzzyva users have come to expect.
A lot of countries use different letter sets, some with more or less letters, some with multigraph letters like the Spanish {CH}. Users sometimes managed to squeeze them into Zyzzyva as a custom lexicon, with varying degrees of success.
Zyzzyva now uses a system of Web-linked catalogs to understand these letter sets and their particular values, counts, and sort orders. When properly configured, an international user can now expect Zyzzyva to work correctly in their own language, recognizing all of their letters and refusing all others.
In particular, we have worked extensively with the Spanish federation (FILE) to accommodate the international Spanish letter set and to translate the user interface. We hope that this will spread the love of Zyzzyva to the many countries that participate in FILE’s clubs and competitions.
Probably not, though you may appreciate being able to load multiple custom lexicons that use the English letter set. You can do this by importing text files in Preferences -> General -> Lexicon -> Manage (NZ) or Settings -> Lexicon -> All Lexicons (NZM) and telling it to model them on your usual English word list.
For our many English-only users, the only other change is that we redesigned those dialogs to support “pluggable” lexicons. That means that you won’t have to update the desktop application to use the next version of your favorite lexicon, just watch for a notification that an update to that lexicon’s catalog is available, accept that update, then import the new lexicon source file so that the catalog can recognize it as authentic; from then on, it’ll be as if it was built into the application. (Or, you can wait for those new lexicons to be built into a new version of NASPA Zyzzyva, as before.)
First thing first: Not every international lexicon is publicly distributed, or at least, not with detailed definitions and other stuff attached. It’s up to the publisher to manage how its users get access to the lexicon source files, so, contact your organization to see if they have a compatible lexicon source text file or ZIP archive that you can download. (If all you have is some text file, you can try importing it as a custom lexicon, but you may run into trouble if it uses a special letter set.)
As of mid-2026, we have made such arrangements with the FILE (Spanish), SD (German), and DS (Danish) organizations. If you dive into the Advanced section in NZ’s Manage Lexicons dialog, you can explore the tree of Zyzzyva catalogs that are set up to define international letter sets and recognize approved lexicon source files. With the benefit of some basic cryptography, we’ve made it so that these international lexicons can be authenticated just like the ones that we build into Zyzzyva.
The process requires that you work your way through this catalog tree, fetching them from the Internet and loading them, to make Zyzzyva aware of the lexicons you’re interested in. Then, when you import the lexicon source that you downloaded, it’ll be recognized cryptographically, and you’ll be all ready to go. Remember: fetch and load the catalog first, then import and load the downloaded lexicon source.
In NZ, there’s a new section in the online help named Lexicons that explains everything about the new catalog system, how lexicons are imported and recognized, and how to use the Manage Lexicons dialog to load and unload them as desired. There’s a lot of detail there, so, if you’re using NZM, you may want to install NZ and read that section, because the online help in NZM is very brief.
Only at the beginning, to fetch catalogs and download lexicon source files. Everything you’ll need to use any lexicon winds up in your Zyzzyva data directory, which lives on your computer or mobile device, and is eligible for data synchronization between devices. Unless you uninstall the mobile app and delete its data, these files (catalogs and lexicon source) are there for good.
Sure thing. Let’s take FISE2A (the current international Spanish lexicon, abridged, containing all 2- to 9-letter words). These instructions work for either NZ or NZM.
Your newly imported lexicon should now show the same green “seal and checkmark” icon as the built-in lexicons, meaning that it’s been authenticated and is correct for judging. If your lexicon source archive file included optional features such as definitions and playability data, you may want to take a few minutes to build a lexicon database as described in the online help.
The rest of this document is for you! There are a number of steps you need to take to make your lexicon and its letter set fully compatible with Zyzzyva. For more information, or to ask a specific question about international support in NZ and NZM, please send a message to the NASPA Zyzzyva Committee.
You should check with the publisher of the word list itself, plus any definitions, to be sure that you’re in compliance with their terms of license for distribution to users. That may depend on whether your lexicon will be made available to anyone or just to approved users. Our standard format for lexicon source puts basic symmetric encryption on text files, so that the word list isn’t easily accessible outside Zyzzyva itself, but it’s not unbreakable.
It’s important to know that catalogs only describe lexicons; they don’t contain them. Users never have to handle catalogs as files, because Zyzzyva knows where to find them on the Internet and where to store them in the user’s data directory. However, they will have to follow your instructions to download and import the lexicon source files that your catalog describes and recognizes.
Each Zyzzyva catalog belongs to one organization, and you’ll be responsible for hosting and updating it, so you’ll need a Web server in an established domain and the capacity to serve the catalog file to your users when they’re online. Your catalog, actually a small SQLite database, will contain basic information about your organization and the lexicons you support, including copyright, publishing date, and so on. It will also contain the specifics of the letter set your lexicons use, plus the unique cryptographic hashes of all lexicon source files you intend for your users to import. (All of this database structure is described below.)
Your users’ ability to import and load your lexicon with a mark of authenticity depends on Zyzzyva recognizing its source files by those cryptographic hashes. In turn, Zyzzyva needs to be able to validate the catalog itself, which requires that it be digitally signed and that its signer’s public key be listed in its parent catalog, likely Zyzzyva’s International Lexicons Catalog.
Getting listed in that parent catalog is a one-time task, between your organization and the parent catalog’s publisher (usually NASPA), based on a signed agreement about responsibilities and practices. Essentially, in return for Zyzzyva’s validation of your catalog, you will be agreeing to operate it in a way that’s consistent with NASPA’s interests, to show due regard for the legal rights of word list publishers, and to enforce the same agreement on any entity whose child catalog is validated by yours.
Once your organization’s catalog is listed in that way, you are free to amend your catalog as required without involving us, to revise, replace, add, or remove lexicons, as long as your digital signing key remains the same. When the catalog’s content changes, users who have your catalog loaded will see a notification directing them to the dialog that lists catalogs, where they can click a button to do the update.
It’s critical to be sure that you have the exact complete word list, because your users will see the lexicon presented as authenticated by your organization. Formatting is also important — one word per line, with optional definitions, parts of speech, and inflections in the format described in the Lexicons section in NZ’s online help, saved in a plain text file (.txt) in UTF-8 encoding with a byte-order mark (BOM), hexadecimal EF BB BF, at the start. (A professional text editor should be able to do this for you.)
Each individual lexicon source file is separately recognized by its cryptographic hash. To see that hash value, hold down the SHIFT key in NZ as you import the source file in the Manage Lexicons dialog. You can then enter it in the catalog database record that you create for that file.
Unless a lexicon source file has already been cataloged (which will be normal for your users, though not for you at this point), the only kind you can import is one that you agree to register in your custom catalog as an unrecognized lexicon source text file. That’s the first step to take for each new lexicon you will add to your catalog. The file will be copied to your data directory under words/imported, and it will be available to load for use in NZ only as long as it is (currently) registered in your custom catalog or (later) recognized by your (future, loaded) catalog.
If you want to protect your word list by encrypting a lexicon source file (word list or playability data), ask your desktop OS to open the .txt file using an application picker, then navigate to the NZ application and hold down the SHIFT key as NZ opens the file; it will write the encrypted file to the same location with the extension .enc.txt. (This optional encryption step does not change the file’s recognized cryptographic hash value.)
We encourage catalog owners to recognize forward and reverse word-graph (DAWG) files as lexicon source files by adding catalog database records for them. The purpose of these DAWGs is to make word searches faster by mapping the letter sequences in all of the listed words; including those records in the catalog, and making the DAWG files part of the lexicon source archive file, makes everything go smoothly for the user. Zyzzyva will automatically generate DAWG files when a lexicon is loaded if they’re absent from the data directory, but with a delay that’s visible to the user. To catalog them, you’ll need their cryptographic hash values; if you hold down the SHIFT key in NZ while the lexicon source text file is loading, Zyzzyva will report the hash value for each DAWG, so you can enter those values in their catalog database records. Once those DAWG hashes are recognized by a loaded catalog, you’ll see that the generated files are also stored in your data directory under words/imported.
If you are interested, we can help you configure optional lexicon source files for playability data and bingo stems, which have their own standard formats. Each fully configured lexicon can have a lexicon source text file, a playability data file, two bingo-stems files (for six- and seven-letter stems), and two word-graph files; they can be imported separately, but most users will prefer to import them as part of a lexicon source archive (.zip) file, which is usually smaller than the lexicon source text file alone.
Once you have the cryptographic hash values for all of your lexicon source files (including DAWGs, if you took note of those when Zyzzyva generated them), you can go about building your organization’s catalog. You can describe multiple word lists in one catalog; for example, the Spanish catalog recognizes both the public (FISE2A) and restricted (FISE2) word lists.
The following sections describe the data format for a Zyzzyva catalog database. We strongly suggest that you follow along using a database browser such as DB Browser for SQLite, using any catalog database that you find in your Zyzzyva data directory under catalogs as a working example. When building a new catalog from scratch or from an existing one, you should work through the tables in the order below, as the schema uses SQLite foreign keys to manage dependencies between records. (All such dependencies are resolved within your catalog, not between catalogs.)
All key fields in these tables are by convention in lower case, to distinguish them from non-key fields (name and description) whose content is intended to appear in the user interface.
The interpretation table contains records that describe all of the file formats that your catalog may recognize. There’s no reason to change these records at this time, so you should leave this table as is.
Currently defined interpretation keys include:
The publisher table contains one record for each publishing authority mentioned in the database. That includes your organization as the publisher of the catalog, as well as any other organization that publishes a word list that your catalog recognizes.
The tile_set table contains one record for each letter set mentioned in the database. Without such a record, your word lists are assumed to use the standard English set and its letter counts and values, so you very likely will need to create one.
The tile table contains one record for each letter in each letter set. It has a composite (two-part) key, comprising the tile_set foreign key and a serial index.
The word_list_family table contains records that describe each “family” that your word lists belong to. Families in Zyzzyva are distinguished by color when used in judging, as a visual aid to users, to distinguish between stations intended for different divisions. You should probably invent a new family for your international lexicons, with its own distinctive color, but if you don’t, you must reproduce the family record from any other catalog where it’s defined, because all dependencies between database records must be resolved within one catalog.
The word_list table contains one record for each word list that your recognized lexicon source files use. It may contain multiple records for the same word list if there have been revisions since it was originally published, using a composite (two-part) key that includes the revision number. It may also contain superseding records for word lists that are new versions of another list in the same family. (For example, NWL2023 supersedes NWL2020, but they are both in the NWL family.)
The lexicon table contains one record for each lexicon source file that your catalog recognizes. It has a composite (two-part) key, comprising its cryptographic hash value and the algorithm used to generate it. (Note that ZIP archives used to package multiple lexicon source files are not listed here, though each individual file inside them must be individually recognizable.)
The catalog table contains one self-description record to describe itself, and optionally more records to describe child catalogs that are validated by your catalog. It’s unlikely that you’ll be birthing child catalogs, but if you do, your users will have to fetch and load your catalog before they can fetch those.
Once you’ve created your catalog, it’s time to test it to see if it properly recognizes and describes your lexicon source files. Since your catalog isn’t validated by any existing catalog, it won’t be possible to operate your catalog in the way that your users will once everything is configured, so you should follow these steps to test it.
When you are satisfied that your catalog is ready to test with its first Zyzzyva users, it’s time to put a digital signature on it. This (along with a record in a parent catalog that describes it) is what enables users to load your catalog so that it can recognize your lexicons as authentic.
Follow these steps using any current version of the OpenSSL program, which is available in source form for all desktop operating systems, or any software with equivalent functionality. In these steps, use a suitable unique name for your catalog, something reflective of your organization, in place of our.
openssl genrsa -aes256 -out our.prv 4096
openssl rsa -in our.prv -pubout -out our.pub
openssl dgst -sign our.prv -keyform PEM -sha256 -out our.db.sig.binary -binary our.db
openssl enc -base64 -in our.db.sig.binary -out our.db.sig
The result is that your catalog (our.db) is unchanged, but you also have the accompanying signature file (our.db.sig) that Zyzzyva expects to be in the same location on the Internet when users fetch your catalog, for validation.
Because of the way this catalog validation works, it’s not critical that you host your catalog with SSL (https:) security, but that’s always good server-management practice.
When all this is done, you must send us three files: the catalog, its signature file, and the public key in PEM format (our.pub). We will run a validation check on these files. When your hosting location is finalized, send us the URL to the catalog file, and we will add the necessary description record to the appropriate parent catalog. Your last task is to test the link between catalogs in NZ and/or NZM by updating the parent catalog and then fetching and loading your catalog, as described above.
When it’s time to make changes to your catalog, you can repeat the above steps to test, sign, and host the updated catalog. As long as you use the same private key to do the signing, you are free to do these updates without notifying us. We may intervene if we see evidence that you aren’t following the signed agreement regarding respect for publishing rights or other issues.
At some point in the future, your catalog files may have to move to a different Internet domain or a different location on your existing Web server. This affects the parent catalog, which tells Zyzzyva where to look when a user asks to fetch or update your catalog.
The catalog tree design allows for this through a practice known in software engineering as “tombstoning”. Your catalog must contain a “self-description” record that matches the record in the parent catalog, including its own Internet URL. No catalog can load properly unless it contains a self-description record that matches its description in its parent catalog.
When you first know that you will be moving your catalog files, you should advise us, to make us aware of the coming change. When you place your catalog in its new location, and before it’s no longer available in its existing location, you must change the self-description record in the catalog at its old location to point to the new URL (and re-sign the catalog, so that it can still be validated). Zyzzyva will notify users that your catalog has changed, and when they update it, Zyzzyva will skip over your obsoleted catalog and fetch the one in the new location. In this way, you can relocate your catalog without involving us during your cutover.
Later, once everything is tested, you must advise us that your change is complete. We will update the parent catalog so that its description of your catalog contains the new URL, at which point you can take down the existing copy.
If you need clarification or assistance with any information in this document, please send a message to us with your specific request.
This page was last edited on 9 September 2026, at 21:27. Privacy policy
Copyright © 2026 NASPA All rights reserved. SCRABBLE is a trademark of Hasbro, Inc. in the USA and Canada, and of Mattel, Inc. elsewhere. NASPA and its activities are neither endorsed by nor affiliated with Hasbro or Mattel. For more information about NASPA or for comments or issues with this page, please email us.