(Updated for the 2019 Edition)
Numbers may be a universal language, yet if you don’t read English you’ll still miss out on a lot of insights from the latest State of JS survey. For that reason we’ve decided to start translating our results in as many languages as possible!
We’re doing this as a crowdsourced, community effort, and in fact we’ve already heard from many volunteers interested in helping us translate!
If you’d like to help, here’s some more information about the workflow we’ve implemented. Let’s say Alicia wants to translate our results to Spanish.
Starting a New Language
- Alicia forks the State of JS 2019 repo to her own GitHub account.
- She makes an initial commit modifying the languages files (see below for information on where to find them).
- She then opens a PR back to the root repo.
- In the PR description, she pastes in this list of to-do items to help others see how far the translation has progressed.
Contributing to an Existing Language
Now let’s say Javier comes along, and he wants to help with the Spanish translation effort. He would:
- Search the list of open PRs for any pending Spanish translations.
- Leave a comment on the PR asking for write access to Alicia’s fork (which can be given in the repo’s
Settings > Collaborators & teamsscreen).
- Once Javier has write permissions, he can now add commits directly to the PR.
Finalizing a Language
- Once a language is complete, Alicia can ask me (SachaG) to review and merge the PR.
This means that the first person to start a new translation PR will become the “manager” for that language and be responsible with adding collaborators and notifying us once all collaborators are happy with the result.
Translation files are located in
/src/translations. Each language has the following files:
- A root
locale.ymlfile (for exampe
en-US.yml) containing all user interface translations.
localedirectory (for example
/en-US/) containing all markdown files for introductions, conclusions, etc.
When contributing new translations, please make sure you follow the same directory and file structure!
To enable a translation you also have to add your locale to
Other i18n Work
Internationalization is not just about translation, but also involves making other changes like loading new fonts, or adding right-to-left language support.
For these changes, please open separate PRs to make the reviewing process easier.
Running the Site Locally
You might want to see what your translations look like in the actual site. To do so you can run it locally with
Note though that this will require access to our internal GraphQL API. While it’s not officially public yet (we don’t really have a good caching layer or any documentation in place) here are some instructions on how to connect to it:
- In the root of the State of JS 2019 Gatsby repo, create a new
- Add the following line to it:
If you have any questions about using the API you can check out this GitHub issue (the API has its own separate repo).
Note that since this is a fairly large Gatsby site with a lot of API queries, 30s-1min build times are not out of the ordinary.
Also, if you’d like to trigger a clean rebuild with a clear cache you can use:
npm run dev:clean
Previous Years Translations
You can find the translation files for the 2018 edition here. A lot has changed since last year so it might not be that straightforward to reuse the same translation strings. In the future we might explore a more sustainable translation workflow that doesn’t require starting from scratch again every time.
For any other question, please open an issue on GitHub!