ru.react.dev is the React documentation in Russian, and it is a fork with a sync problem

A translation fork inherits the upstream site and everything upstream does

ru.react.dev is the Russian version of the React documentation. The repository description says so in two languages, React documentation website in Russian and the official Russian version of the React site, and the README states plainly that the repo contains the source code and documentation powering ru.react.dev.

The interesting structural fact is that this is not a standalone site. The prerequisites list includes Git, Node of any version starting with v16.8.0 or greater, Yarn, a fork of the repository for contributions, and a clone of the react.dev repository on your local machine. That last item is the tell. A translator working here is working with two trees, the English upstream and the Russian copy, and the tooling has to reconcile them.

The dev script makes that reconciliation explicit. Rather than a plain dev server, the package.json defines it as a watch against the content directory:

    "dev": "next-remote-watch ./src/content",
    "build": "next build && node --experimental-modules ./scripts/downloadFonts.mjs",
    "ci-check": "npm-run-all prettier:diff --parallel lint tsc lint-heading-ids rss",
    "tsc": "tsc --noEmit",

So the development server watches the content tree and picks up changes to it. The top level entries show the shape of the site: a src directory, a plugins directory, a scripts directory, a public directory, plus next.config.js, tailwind.config.js, postcss.config.js, tsconfig.json, vercel.json, colors.js and a .husky directory. There is also a TRANSLATION.md file and a LICENSE-DOCS.md file, which tells you the site has a translation workflow and a content licence of its own.

yarn dev, localhost:3000, and the Yarn-first toolchain

The getting started section is short enough to quote without distortion, and it tells you the shape of the whole contributor workflow:

1. `cd react.dev` to go into the project root
3. `yarn` to install the website's npm dependencies
1. `yarn dev` to start the development server (powered by [Next.js](https://nextjs.org/))
1. `open http://localhost:3000` to open the site in your favorite browser

Note the detail that the folder you enter is called react.dev, and that Yarn is the package manager rather than npm, with a yarn.lock at the top level. The project uses Yarn for installs and for scripts, and the postinstall hook installs the husky git hooks, so the local tooling is wired in from the first install.

The stack is modern. The dependencies pin Next.js at 15.4.8 and React at ^19.0.0, with react-dom on the same major line, and the build script runs a Next.js build followed by a font download step. Interactive examples come from @codesandbox/sandpack-react, and search comes from @docsearch/react with its CSS package, so the site embeds runnable examples in the page rather than linking out to CodeSandbox. Radix and Headless UI provide the interactive primitives, and the markdown side is handled by remark-frontmatter and remark-gfm, which is how the MDX-style content in the content directory is parsed.

The Node floor of v16.8.0 in the prerequisites list is well below what the pinned Next.js version needs in practice, so treat that number as a stale line in the README rather than a supported target.

yarn check-all is the single gate a change has to pass

Every contribution in this repository is filtered through one command. The README says to run yarn check-all, and the script definition spells out what that means:

    "check-all": "npm-run-all prettier lint:fix tsc rss",
    "rss": "node scripts/generateRss.js"

The README describes it as running Prettier, ESLint and validating types, and the script agrees. The check-all chain runs the formatter in fix mode, the linter, the TypeScript compiler, and the RSS generator. The ci-check variant is stricter and parallelised, running a Prettier diff instead of a fix, plus lint, tsc, lint-heading-ids and rss.

The heading linter is the interesting one for a translation project. There are dedicated scripts for it, one that lints heading ids and one that fixes them, and the package scripts give them descriptive names. Heading identifiers in a documentation site are anchors that other pages and search engines link to, so a translation that renames a heading without keeping the identifier consistent breaks inbound links. The linter is the mechanism that catches this automatically.

Because the fix scripts exist, formatting is not a review topic. A contributor runs check-all, the tooling normalises the files, and the reviewer looks at prose.

Translations are edited in place and hot reload, with one cache caveat

The make-the-change section describes how editing feels. Changes to React components in src hot reload, and changes to markdown files in content hot reload. The one exception is plugins, where you may need to remove the .cache directory and restart the server. That caveat is the cost of a plugin based content pipeline, and it is the only step in the loop that is not automatic.

The guidelines note that the documentation is divided into several sections with a different tone and purpose, and that if you plan to write more than a few sentences you might find it helpful to read the contributing guidelines for the appropriate sections in the upstream repository. This is the part that surprises people who expect a translation to be a mechanical exercise. The Russian text is not a mirror, and a page in the tutorial section and a page in the reference section are not supposed to sound the same. A translation that ignores the source section's voice will read as wrong to a native editor even when every term is correct.

The upstream link in that sentence is also the answer to where translation policy lives. The README points to the current translation efforts in the reactjs/react.dev repository, issue 4135, which is where the coordination happens. TRANSLATION.md in this repository is the local counterpart.

A fork has no release history, only a push history

The maintenance picture here is short. The repository is not archived, and the last push was on 2026-10-19. There are no GitHub releases, so there is no tag series, no changelog and nothing to pin. What you can point to instead is the last push date and the commit log.

The content licence is the more interesting item. The README states that content submitted to react.dev is CC-BY-4.0 licensed, as found in the LICENSE-DOCS.md file, and the package.json carries a license field of CC. CC-BY-4.0 is a content licence, not a software licence, which is the correct instrument for documentation, and it means the translated prose can be reused, adapted and republished with attribution, including in internal company wikis and in paid courses. Anyone republishing the Russian text should attribute it and keep the licence notice.

The top level entries list LICENSE-DOCS.md but no separate LICENSE file, so the reuse terms of the site components themselves are not stated in this repository. Only the documentation content carries a licence here.

Where a translation fork is the wrong place to work

The honest limitation is the fork itself. Every upstream change to the English documentation has to reach this repository before the Russian site reflects it, and this repository's history cannot show you when that happened. For a reader, that means a Russian page can lag the English page on a specific API detail and there is no version marker on the page telling you which upstream state it was translated from. For a contributor, it means a fix to the English site does not automatically fix the Russian one, and vice versa.

There is a second, smaller trap in the prerequisites. A local clone of the react.dev repository is required, which means the environment has two trees and the tooling has to know which one it is reading. A contributor who starts from the English clone and edits the wrong content tree will see no change on the Russian site, and the failure is quiet rather than loud.

The pragmatic alternative for most people is the upstream English site, and the difference is not quality but scope. Upstream is the source of truth, it is where the API documentation originates, and it is where the maintainers decide what a page says. A translation adds a language layer and nothing else, which is exactly what you want when your working language is Russian, and exactly what you do not want when you need to be certain you are reading the current text.

Why Russian-speaking React developers keep their own fork

Translation of technical documentation is one of the most reliably under-served cases in open source. The English site is where the content is produced, reviewed and updated, and the incentive structure points upstream in one direction only. That leaves a gap that a community fork can fill, and the numbers in the repository reflect a working project rather than an abandoned mirror: the last push was on 2026-10-19, the site is served at ru.react.dev, and the build is a current Next.js 15 and React 19 stack rather than a frozen snapshot of an older generator.

The tooling follows from that ambition. Sandpack for live examples, DocSearch for search, Radix and Headless UI for accessible components, a heading id linter to protect anchor links, an RSS generator so new pages can be followed, and husky hooks installed at postinstall so the checks run before a commit lands. None of that is exotic. It is a documentation site built like a product, which is the correct response to a translation that has to be indistinguishable from a native site to be worth using.

The remaining question is one of coordination rather than engineering. The README routes translation work through upstream issue 4135, and the guidelines route tone questions back to the upstream contributing guide, so the Russian site is a participant in a wider process rather than an island. That is the mechanism that decides whether the fork stays in step with the English documentation over time.

Editorial conclusion

Use ru.react.dev if you write React and read Russian, since the translations are maintained in this repository and the content is licensed for reuse under CC-BY-4.0. Do not use it as your learning source if you need version accurate API detail, because a translation fork can lag the English site between syncs, and upstream changes are not visible in this repository alone. Before contributing, clone reactjs/react.dev locally as the README requires, run yarn check-all to see a clean baseline, and read the contributing guidelines for the section you plan to touch, because the documentation is split by tone and purpose and a page can be rejected for voice rather than for accuracy.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-4.0
3. Project website
4. reactjs/ru.react.dev on GitHub
5. README