ko.react.dev: the Korean React documentation site, and how to run it locally

A Korean documentation site, not a fork of the React library

The first thing to get straight is what this repository is and is not. ko.react.dev holds the source code and the developer documentation for ko.react.dev, the Korean-language React documentation site, and nothing in it alters how React itself behaves. The React library is untouched here. What changes is the language of the prose that teaches it. The repository points the copyright for that prose back to react.dev, and the site is a translation of the same pages you would otherwise read in English on react.dev.

That framing matters for anyone evaluating it. The question is not whether this code improves on the upstream site, because it does not try to. The question is whether you can stand up a local copy, translate or correct a page, and push it through a review path the Korean community already uses. For a team whose engineers read documentation in Korean, that gap is real, because the set of pages available in Korean is narrower than the set available in English, and a page nobody has translated yet is a page that does not exist for them.

yarn dev runs next-remote-watch over the content tree

The development server is a Next.js app, but the dev script is not a bare next dev. The package.json dev entry points at next-remote-watch with the content directory as its argument, which is how the site picks up edits to markdown files without a manual rebuild.

Before any of that runs, the prerequisites are modest: Git, Node v16.8.0 or any later version, Yarn v1 pinned in the guide as [email protected], a forked copy of the repository, and a local clone of it.

The install and start sequence is short:

cd ko.react.dev
yarn
yarn dev
open http://localhost:3000

Running yarn installs the npm dependencies, and the postinstall script additionally installs the local ESLint rules and, outside CI, sets up the husky hooks. After yarn dev starts, open http://localhost:3000 and you should land on the Korean documentation served from port 3000. While the server runs, saving a file under src triggers hot reload for the React components, and saving a markdown file in the content directory triggers hot reload for the prose.

Fork, branch, and push before touching a single Korean sentence

The contribution path is the ordinary fork and pull request path, and the guide is explicit about the order of operations. You work from a fork you created yourself, you sync with the main branch before you branch, and you name your branch something descriptive.

git checkout main
git pull origin main
git checkout -b the-name-of-my-branch

Then you edit, save, and confirm the change in the browser. When you are happy, the commit and push are two commands:

git add -A && git commit -m "My message"
git push my-fork-name the-name-of-my-branch

The placeholder in the commit message is meant to be replaced with something like Fix header logo on Android. Pushing to your fork is what makes the change visible, and the guide notes that a preview build is triggered once the work lands on the repository. It also asks for a screenshot of the visible change where possible, which is a sensible request for a documentation site where a mistranslated label is the whole problem.

yarn check-all is the gate every translation has to pass

Translations are checked mechanically before review, and the entry point is a single command run from the project root:

yarn check-all

The package.json defines that script as a run of prettier, lint:fix, tsc, and rss. In other words the command formats the source, applies ESLint fixes including linting of the markdown files under src/content, runs the TypeScript compiler with no emit to catch type errors, and regenerates the RSS feed. Because lint:fix rewrites files rather than only reporting problems, running it locally is what keeps a pull request free of the failures the review would otherwise flag.

There is a second, stricter command for continuous integration. The ci-check script runs prettier in diff mode, plain lint, tsc, a heading id linter, rss, deadlink checking, and an editorconfig check. The heading id linter and its fix-headings counterpart matter more than they sound, because the English source and the Korean pages share anchor structure that internal links depend on. There are also dedicated textlint scripts and a textlint-test script that runs the rules and utilities under test.

textlint and a shared glossary settle the Korean wording

The hard part of a documentation translation is not the sentence, it is the word. A React term that reads naturally in English can have two plausible Korean renderings, and if two contributors pick different ones the same concept ends up with two names in the same page. The repository addresses this with a wiki directory that holds a universal style guide, a best practices page for translation, and a translate glossary that fixes the shared vocabulary, plus a dedicated textlint guide for the pull request checks that failed.

The linting machinery is visible in the tree. A .textlintrc.js configuration file sits at the top level, a textlint directory holds the custom rules and their tests, and a textlint-lint script runs the rules over the content directory. A separate textlint-docs script regenerates the glossary document from the rules and stages it, so the glossary is partly derived from the rules rather than maintained by hand in two places.

Two more pieces guard the prose. A custom ESLint rule set lives in eslint-local-rules, installed during postinstall, and the guide asks contributors to run a Korean spell checker as a final manual pass. Husky hooks in a .husky directory are installed by the same postinstall script, so formatting and lint rules can run on commit rather than at review time.

CC-BY-4.0 covers the words, a separate notice covers the site code

Licensing here is split in two, and the split is easy to miss. The documentation content is covered by the CC-BY-4.0 license described in LICENSE-DOCS.md, and the guide states that the copyright for that content is held by react.dev, the upstream English site. The package.json separately declares a private package with a license field set to CC, and the repository is marked private, meaning there is nothing here published to a package registry.

Practically, that means the words carry an attribution requirement, while the surrounding site infrastructure, the Next.js configuration, the tailwind setup, the plugins directory, and the custom lint rules are the part a translator is actually editing. This is a documentation project, so the code is small relative to the prose, and the legal weight sits almost entirely on the prose. Anyone reusing translated passages in internal documentation should read LICENSE-DOCS.md directly and keep the attribution, and anyone reusing the site scaffolding should read the repository's own license files rather than assuming the content license covers them. That is a question for your own counsel, not a conclusion to draw from a license identifier alone.

No releases, no package, and a build that reaches the network

The limits of this project are worth stating plainly. The repository publishes no GitHub releases, so there is no tag to pin and no upgrade path in the usual sense. There is also no npm package to install. A consumer who wants the Korean documentation consumes it as a website, and a contributor who wants to change it consumes it as a repository. The last push was on 2026-10-19, so the working tree moves, but nothing is versioned.

Two further constraints shape day to day work. The dev script watches a content path and the guide separately refers to a content directory for markdown files, so the location of a given page is not obvious from the tree alone and the script argument is the more reliable pointer. And when a plugin is involved, the guide requires that the .cache directory be removed and the server restarted, with yarn cache-reset offered as the broader remedy, which clears the Next.js build cache along with the Yarn cache. A full build is heavier still: it resets the cache, builds a React server component worker, runs next build, downloads fonts, and generates Open Graph images, so a production build needs network access rather than only the local checkout.

Editorial conclusion

ko.react.dev is worth adopting if your team reads React documentation in Korean and wants to contribute corrections, and it is the wrong tool if you need a versioned React API reference, since the repository publishes no releases and only mirrors the pages upstream has already translated. Before you rely on it, verify that the specific page you care about has been translated at all, since coverage is tracked separately on translations.react.dev, and run yarn check-all yourself rather than trusting a preview build.

Frequently asked questions

Official sources

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