# es.javascript.info: the Spanish translation of the JavaScript tutorial > The es.javascript.info repository holds the Spanish translation of the javascript.info tutorial, structured as one folder per chapter, article or task, with a contribution workflow built around claiming an article, forking, and opening a pull request. **javascript-tutorial/es.javascript.info** — Spanish translation of javascript.info site. - Repository: https://github.com/javascript-tutorial/es.javascript.info - Website: https://javascript.info - Stars: 628 · Forks: 226 - Language: HTML - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/javascript-tutorial-es-javascript-info ## A translation, not a fork of the tutorial The repository hosts the translation of the javascript.info site in Spanish, and the English section at the end of the README states it plainly. The site itself is the modern JavaScript tutorial, and this repository is one language's version of it. The primary language of the repository is recorded as HTML, which reflects that the content is a tree of Markdown files with a build layer around it rather than an application. The top level shows the shape of the tutorial rather than the shape of the project, with numbered part directories such as `1-js/`, `2-ui/`, `3-frames-and-windows/`, `4-binary/`, `5-network/`, `6-data-storage/`, `7-animation/`, `8-web-components/` and `9-regular-expressions/`, plus `script/` for tooling, `images.yml` for the image manifest, `css.md`, a `todo.txt`, a `BACKERS.md` and a `CONTRIBUTING.md`. There is also an `AUTHORING.md`, and a `changes.sketch` alongside `svgs.zip` for the figures, which is a small detail that says a lot about how the work is done. ## Every article is a folder with a known filename The structure section of the README defines the layout, and it is the part every contributor has to follow. Every chapter, article or task has its folder, named like `N-url`, where N is a number for sorting purposes and URL is the URL part with the title of the material. The folder holds one of three files, and the three filenames are the whole convention: ```text - `index.md` stands for a chapter - `article.md` stands for an article - `task.md` stands for a task (solution must be provided in `solution.md` file as well) ``` A file starts with the `# Title Header` and then the text in Markdown-like format, editable in a simple text editor, and additional resources and examples for the article or the task are also in the same folder. This is a sensible convention for a translation project, because the folder name and the file name together identify the upstream piece being translated, and the three filenames encode whether the unit is a chapter, prose or an exercise. ## Claiming an article, forking, then opening a pull request The contribution workflow is documented in five numbered steps, and the first one is where most people get stuck. You go to the Spanish translate progress issue, look for an article that is not already assigned to a user, and if none is free you pick from the English repository. The second step is to request the article by leaving a comment with the exact title, and the recommendation is to copy and paste the title so the bot can recognise it and assign it to your user. Once the bot has assigned it, with your username shown against it, you fork the javascript-tutorial/es.javascript.info repository. The fourth step is to translate the article, starting by clicking the Edit button on the file. The fifth is to open the pull request, with the title matching the article title so the bot writes the number into the issue. The README asks contributors to allow maintainers time to review and merge, and to write to the main repository if maintainers do not respond. ## One article per branch, and a master that stays clean There is a rule in the Spanish instructions that is easy to miss and expensive to break. For each translation you must create a new branch in your fork, because the master branch must always be clean, and the rule is stated as one article equals a new branch. That sounds like a small administrative detail, and it is the thing that keeps a repository with dozens of in-flight translations mergeable. The English instructions in the same README put it the same way, asking for a fork and a pull request, with the pull request title matching the article title. The wider rule is that the repository is not always up to date with the newest version of the English original, and the Spanish instructions say to use the article in the original repository as a guide. The summary is that the Spanish repository must end up identical to the English one, and if folders or files are missing you have to create them. ## A glossary is what makes a translation usable The terminology conventions are the part of a translation project that determines whether the result is worth reading. The README says a glossary has been agreed for consistency and asks you to review it, with the glossary held as an issue in the repository. The English translation tips spell out the rules that apply to every language. Some specification terms are not to be translated at all, with Function Declaration given as the example of a term that can be left as is. For other terms, such as `resolved promise`, `slash` and `regexp`, you should look for a good glossary, and if there is no dictionary for your language, look for translations in manuals such as MDN. The Spanish instructions point at the Spanish MDN for the same reason, saying it is a valuable resource because it lets the project coordinate the terms used across all the articles. The text in code blocks has its own rules, which apply equally to any translation. ## Line breaks are a merge format, not a style choice The single most technical instruction in the translation tips is about line breaks and paragraphs. You are asked to keep them as is, not adding newlines and not removing existing ones, and the stated reason is that it makes it easy to merge future changes from the English version into the translation. That single rule converts an unstructured translation task into a mechanical one, because a translated line still corresponds to exactly one upstream line, so an upstream edit becomes a one line conflict instead of a paragraph rewrite. It also explains why the English instructions ask contributors to send a pull request to the English repository when they spot that the English version can be improved, since a fix upstream has to land before it can be pulled into the translation. The Spanish instructions add a related point, that when selecting an article you have to translate all of its content including the tasks and their solutions, and that you should not open a pull request until everything is done, because partial translations make the reviews slower. ## Where this repository is not the place to start The limits are about scope and about how the workflow is designed. First, the content belongs to the English original. The English instructions ask people who want to improve the tutorial to send a pull request to the English repository, and the Spanish instructions say the Spanish repository should end up identical to the English one, using the original as a guide. So this is a translation surface, and a change to the underlying tutorial is a change to a different repository. Second, the workflow assumes a translation ecosystem. The progress issue, the bot that assigns articles, the agreed glossary, the Discord server, the per-language translate page at javascript.info/translate and the mention of more than fifty sibling repositories all assume a shared infrastructure that a language without one would have to build. Third, the metadata and the language. The repository records no standard licence and no releases, so there is no version to pin and no stated permission text to point at, and the README is bilingual with the Spanish instructions first and the English ones after, so an English reader has to dig past the Spanish half to find the process. Fourth, the figures are a design file. A `changes.sketch` and an `svgs.zip` at the top level mean the illustrations are edited in a specific tool, which is a barrier for a translator who wants to adjust a diagram. ## Conclusion es.javascript.info fits a Spanish speaking developer who wants the javascript.info material in their own language, and it is a well-organised example of how a large translation project is run in the open, with a glossary, a term convention and a bot that keeps the progress issue honest. It is the wrong repository for people who want to extend the tutorial itself, since the README sends English improvements to the upstream repository, and the wrong choice for a language with no existing translation infrastructure, because the whole workflow assumes a shared glossary and a per-language progress issue. Before you start, read the translation tips about keeping line breaks intact, since that is what makes merging upstream changes possible, and check the term list so your first article does not introduce a third spelling of a concept. The last push was on 2026-08-02, the repository publishes no GitHub releases, and the licence is recorded as one GitHub cannot classify. ## FAQ ### How do I contribute a translation to es.javascript.info? Find an unassigned article in the Spanish translate progress issue, comment with the exact article title so the bot can assign it to you, fork the repository, translate the whole article including tasks and solutions, and open a pull request whose title matches the article title so the bot records the number in the issue. ### What is the folder and file structure of es.javascript.info? Every chapter, article or task has its own folder, named like `N-url` with a number for sorting and the URL part of the title. The folder holds `index.md` for a chapter, `article.md` for an article, or `task.md` for a task with its solution in `solution.md`. Each file starts with the `# Title Header` and continues in Markdown-like format, and extra resources for the piece live in the same folder. ### What are the translation rules for es.javascript.info? Keep line breaks and paragraphs as they are, so future changes from the English version merge cleanly. Do not translate some specification terms, with Function Declaration as the example, and for others such as `resolved promise`, `slash` and `regexp` follow the agreed glossary, consulting MDN if no dictionary exists. In code blocks, translate comments and user-facing strings but not variables, classes or identifiers. ## Sources - [Issues](https://github.com/javascript-tutorial/es.javascript.info/issues) - [javascript-tutorial/es.javascript.info on GitHub](https://github.com/javascript-tutorial/es.javascript.info) - [Project website](https://javascript.info) - [README](https://github.com/javascript-tutorial/es.javascript.info/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/javascript-tutorial-es-javascript-info