CryptoZombies lessons, the translation repository behind the browser game

A content repository, not a game repository

The repository is described as lesson content for cryptozombies.io, and its README title says it plainly: CryptoZombies, Content Localization. This repository is used to translate CryptoZombies to other languages. Everything in it is text.

The top level listing makes the shape obvious. There is an en/ directory, which the README states is the source content that should be used for all translations, and then a flat set of locale directories beside it: de/, es/, fa/, fr/, it/, jp/, ko/, no/, pl/, pt/, ru/, sk/, th/, tr/ and zh/. The names are the locale codes the README suggests for a new language, with jp for Japanese and zh for Chinese given as examples. Alongside the locale directories sit an index.ts at the root, a crowdin.yml, a funding.json, a license file and a .github/ directory.

The primary language field says TypeScript, which points at the index.ts files rather than at the lesson text, since the lessons themselves are JSON and Markdown rather than code. index.ts at the root is the registry, and step five of the localisation procedure is to update the index.ts in the root folder, so adding a locale is a two file change: a new index.ts in the locale directory and a line in the root one.

The crowdin.yml at the root is the one entry that hints at how translation actually gets done at scale. It is a Crowdin configuration file, and Crowdin is a translation management service, so the project appears to run a managed translation flow with this repository as the source of truth and the language directories as the output.

One lesson per directory, and two JSON files with different rules

Inside the en/ directory the content is organised by lesson number, with one directory per lesson, and two JSON files carrying the interface strings. The README lays out the structure directly:

en/
  1/ - content of Lesson 1
  ...
  N/ - content of Lesson N
  index.json - strings used in the UI
  share-template-msgs.json - strings used on the share page

So the lesson directories hold prose and code samples, and the two JSON files hold everything the interface shows the user, plus the text used on the share page.

The parameter handling is where a translator can easily introduce a bug, and the README gives it a dedicated note. Strings in index.json and share-template-msgs.json can contain parameters, and these will be injected before the strings are displayed to the user. The important detail is that parameters present in the source string may appear in any position in the translated string, or be omitted entirely if that makes sense.

Then there is the syntax trap. The syntax used to represent parameters differs between the two .json files. In index.json parameters are written with curly braces around the name, {parameterName}, while in share-template-msgs.json they use the Handlebars style {{ .ParameterName }}. A translator copying a pattern from one file to the other will produce a string that renders the placeholder literally instead of the value.

The freedom to move or drop parameters is a design decision rather than an oversight. It lets a language whose word order differs from English put the injected value where it belongs grammatically, and it lets a translator leave a parameter out when the English phrasing depends on it.

Adding a locale is a six step process with a pull request

The procedure for localising into a new language is short enough to follow exactly. You create a new branch off master. You create a new folder named after the locale code, for example jp or zh. You translate the content. You add index.ts to the new folder. You update index.ts in the root folder. And you submit a pull request against master.

The default branch of the repository is master, and both the new locale procedure and the content fix procedure target master with pull requests, so the review flow is a pull request against the default branch in both cases.

The fixing procedure is even more compressed, and reads as a joke in the original: create a branch off master, fix fix fix, submit a pull request against master. Underneath the joke is the same three step shape, and it applies to source content as well as localized content. That distinction matters, because the English source is the input to every other locale, so a fix to the source has to be made in en/ and then carried into the translated directories, which is a mechanical but real chore across fifteen of them.

The workflow assumes a contributor can read the structure of a lesson directory and translate it. There is no tooling described for extracting strings, no script to check for missing keys, and no test suite in the repository layout, so consistency across locales is maintained by review rather than by automation. The.github/ directory is the natural place for whatever checks exist, and funding.json suggests the project accepts sponsorship.

The licence hands copyright back to Loom Network

The licence section of the README is the part a contributor has to read before writing anything, and it is not a standard open source grant. The wording is that contributors must assign copyright back to Loom Network for any contributions they make, and that Loom Network retains ownership of any derivative work created from original content.

That is a contributor licensing agreement in substance, and it is the reason the repository metadata does not classify the licence as one of the standard open source licences. Contributors are not granting a permissive licence; they are assigning their rights to the company, and the company keeps ownership of what results. A translator who signs up without reading that is making a decision about their own work that is different from the one most open source repositories ask for.

The practical consequences are straightforward. A translator cannot take the lesson content and publish it under their own name or licence, and cannot treat a translated lesson as their own text. The existing translations remain usable by the project and by its users, and the same terms have to apply to every future locale, which is why the assignment is stated in the general case rather than per contributor.

For a project whose goal is to make a coding course available in as many languages as possible, this is a coherent choice. The course teaches a specific curriculum about smart contracts and web3 development, and keeping the content under one owner keeps that curriculum consistent and attributable. It does mean the repository is not a source of freely reusable lesson material, and the difference is worth understanding before spending a weekend translating Lesson 1.

What is missing, and where the real project lives

The repository is honest about its scope, and a reader should know what they will not find here.

There is no application code. The client that renders the lessons, the browser environment the exercises run in, the code that executes the learner's contracts, and the web3 tooling the courses mention are all outside this repository. What is here is the text, the code samples inside the lessons, and the interface strings. The description says lesson content for cryptozombies.io, and the repository title says content localization, and both are accurate.

There is also no documented build or test step. The top level listing contains no package.json, no Makefile, no lockfile and no test directory. The only entry points described are procedural: a branch, a directory, a file, a pull request. That is consistent with a repository whose output is consumed by another system rather than built here, but it also means a contributor has no local way to check that a translation is complete or correctly parameterised.

On maintenance, the repository is not archived and the last push was on 2026-09-08. There are no GitHub releases, which fits a repository where the version of the content is the commit history rather than a tag. The lesson numbering in the structure, with 1/ through N/, suggests the course grows by adding directories, and since the en/ directory is the reference for every other locale, a new lesson is a translation backlog before it is anything else.

Editorial conclusion

CryptoZombies lessons suits translators who want to bring the cryptozombies.io course into another language and are comfortable working inside a JSON and TypeScript layout rather than a wiki, and it suits anyone maintaining the English source, since fixes to the original propagate to the translated directories. It is the wrong repository for anyone looking for the game itself, because the client code, the web3 environment and the lesson runtime are not here, and it is the wrong place to ship a new lesson, because the branching model is described only as creating a branch, copying the English directory and translating the content. Before contributing, read the license file, since contributors must assign copyright back to Loom Network and Loom Network retains ownership of derivative works, and check the parameter syntax for the file you are editing, because index.json uses {parameterName} while share-template-msgs.json uses {{ .ParameterName }}.

Frequently asked questions

Official sources

1. CryptozombiesHQ/cryptozombie-lessons on GitHub
2. Issues
3. README