# cfug/flutter.cn: the Chinese translation track for the Flutter docs > cfug/flutter.cn is the repository behind the Chinese Flutter documentation effort, a Dart site build with Jaspr and hosted on Firebase that mirrors the structure of the upstream Flutter website. It suits contributors who want to translate and maintain Flutter's docs for Chinese readers, and it comes with the full weight of upstream's style rules, review process and API reference ownership. **cfug/flutter.cn** — Flutter CN docs translation plan, get started from the wiki: https://github.com/cfug/flutter.cn/wiki - Repository: https://github.com/cfug/flutter.cn - Website: https://docs.flutter.cn - Stars: 568 · Forks: 359 - Language: Dart - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/cfug-flutter-cn ## What the repository is for, and where the work is coordinated The repository description is short and specific: a Flutter CN docs translation plan, with the wiki at the GitHub wiki of the same repository as the place to get started. That is the entry point, and it tells you the important thing about the project. This is not a general purpose website repository that happens to be mirrored in China. It is a translation effort for the Flutter framework documentation, and the wiki is where the plan, the division of work and the conventions live. The homepage is docs.flutter.cn, the Chinese documentation site. The default branch is `main`, the repository is not archived, and the last push to the tree was on 2026-09-09. There are no GitHub releases, which is what you would expect from a repository whose output is a website rather than a package: there is no artefact to version, the deployment is the deliverable. The primary language is Dart, and the repository carries topics for China, localization, documents and the Flutter websites, which is consistent with a site that is itself built from Dart and whose content is translated. The contributors file, the `CODEOWNERS` file and a `CONTRIBUTING.md` are all present, and there are `.agents/` and `.gemini/` directories alongside an `AGENTS.md` at the root, which tells you the project expects automated tooling to take part in the work. For a reader deciding whether to spend an afternoon here, the honest summary is that contributing is a translation task with engineering process attached, not a code feature you can adopt. ## The site infrastructure behind the translation: Jaspr, Firebase, dash_site The README in the repository describes the site infrastructure the translation runs on, and it is the same shape as the upstream Flutter website. There are two sites. The documentation site at `docs.flutter.dev` and the marketing website at `flutter.dev`, which includes the blog. Both are built with Jaspr, a Dart web framework, and hosted on Firebase. The build is driven by a single tool, `dash_site`, invoked with `dart run` from the repository root. The tool is site aware, which matters for a translation project: the documentation site and the marketing site are separate targets selected by a flag, and the README shows the flag form as `--site=www` for the marketing site and blog, with the default target being the documentation site. The repository layout matches that structure. A `sites/` directory holds the site definitions, `tool/` holds the tooling, `examples/` holds the code samples that appear in the docs, `packages/` holds shared Dart packages, and `cloud_build/` holds the build configuration. There is also a `pubspec.yaml` at the root for the Dart dependencies of the site itself. That last part deserves a note for a translation project. The `examples/` directory contains runnable Flutter sample applications, and the README states that changes in `/examples`, `/sites` or `/tool` need to be built and tested before submitting, with a dedicated validation command for exactly that. A translator editing prose may not need to touch any of it, but a translator updating a code sample does, and the tool enforces the distinction. ## Building the site locally before you open a pull request The README is explicit that small text fixes can go straight through the GitHub UI without a local build, and that code samples, added or removed pages, or navigation changes require you to build and test first. The local workflow is short and fully scripted. The prerequisite is the latest stable release of Flutter, which includes Dart. You verify it is on your path with a single command, and the README also links the install and upgrade instructions for people who need them. ```bash flutter --version ``` After that you clone the repository, create a branch, fetch the Dart dependencies, and ask the tool what it can do. The clone command in the README points at the upstream `flutter/website` repository, and the same README explains the fork workflow: if you are not a member of the Flutter organization you are asked to fork the repository under your own account and submit the pull request from that fork. ```bash git clone https://github.com/flutter/website.git ``` ```bash git checkout -b ``` ```bash dart pub get ``` ```bash dart run dash_site --help ``` Serving the site is one more command, and the port it uses is printed to your terminal so you can open it in a browser. The site rebuilds automatically on most changes; if something does not update, the instruction is to exit the process and rerun the command. ```bash dart run dash_site serve ``` ```bash dart run dash_site --site=www serve ``` For content that could break the docs, there is a validation pass. If you changed the examples, sites or tool directories, you commit and run `check-all`, then address any errors or warnings it reports. ```bash dart run dash_site check-all ``` ## A translation inherits upstream style rules and a review culture The contribution rules are the part that surprises people who arrive expecting to just translate sentences. The project asks that changes not be run through Grammarly or a similar tool and submitted as a pull request, and it requires the Google Developer Documentation Style Guidelines to be followed, with examples given: avoid `i.e.` or `e.g.`, avoid writing in the first person, and avoid the future tense. Those rules are a poor fit for a naive translation pass. Machine translated English documentation often carries the first person and the future tense forward, and it tends to keep Latin abbreviations that the Chinese style expects to be spelled out or dropped. The rules therefore function as a translation checklist as much as an English writing guide, and the links given for the style guide highlights and the word list are the concrete reference. The review culture is visible in the issue process too. The README notes that when triaging issues the project sometimes applies a `PRs welcome` label, and that pull requests on other issues are equally welcome, so the label is not a gate. Small changes are explicitly easiest through the GitHub UI, and for larger changes the project says it can stage the changes automatically in the pull request. Contributors are pointed to the `hackers-devrel` channel on the Flutter contributors Discord, and to a `CONTRIBUTING.md` in the repository root. For a translation team this is the real cost model of the work. Every translated page inherits a review standard written for the upstream English docs, and the review happens in the upstream project, not locally. ## Where content ownership sits, and why API reference pages are out of scope The README draws a boundary that a translation project has to respect. If you have an issue with the API docs on `api.flutter.dev`, the instruction is to file it in the `flutter/flutter` repository, not in the website repository, because the API docs are embedded in Flutter's source code and the engineering team handles them. That division has direct consequences. The reference pages generated from the framework's own doc comments are owned by the framework maintainers and are, in practical terms, not part of what a documentation translator edits. The prose pages, the guides and the tutorials are the part that a translation effort can actually take on. The same boundary shapes the site split. The documentation site holds the technical guides, and the marketing site with the blog is a separate target with a different owner and a different audience. Selecting the site is part of every `dash_site` invocation, which means a change to the blog and a change to the guide are reviewed in different places. The `examples/` directory adds a third layer of coupling. The code samples in the docs are real Flutter applications that get built and validated, so a translated snippet that changes behaviour has to survive the same check as the English original. Translating prose and translating code samples are not the same job, and the tooling treats them differently. ## Licence, releases, and what the repository does not promise The licence is where this repository is unlike a typical open source project. The licence field for the repository is recorded as a custom licence that GitHub cannot classify, and the LICENSE file at the root is the authoritative text. Any team planning to reuse code from it, or to fork the site for a purpose other than the documented translation plan, needs to read that file directly. The MIT and Apache terms that many Dart projects use should not be assumed here, and this is a licensing question for whoever owns the code in your organisation rather than something to settle from a summary. There are no GitHub releases, so there is no version history to point at and no artefact to pin. The deliverable is a deployed site, and the deployment is the upstream project's business. For the translation, the equivalent of a release is a merged pull request and a site update, and the README says a change can be staged automatically in the pull request, which suggests a fairly tight loop between review and publish. Two things the repository does not document are worth naming before anyone commits effort. First, the translation conventions themselves live in the wiki rather than in the README, so a contributor has to find the wiki to learn how terms are handled, which pages are in scope, and how the effort is prioritised. Second, the README does not set out a release or stabilisation plan for the Chinese site, so how quickly an upstream English change reaches the Chinese pages is a question for the wiki and the maintainers. The last push to the tree was on 2026-09-09, so the work is live rather than frozen, and the repository is not archived. ## Conclusion Adopt cfug/flutter.cn if you are a Chinese-speaking Flutter contributor who wants to translate and maintain the framework's documentation, and if you can follow the Google Developer Documentation Style Guidelines the project inherits. Do not treat it as a drop-in clone for building an unrelated Dart site, because the tooling, the site variants and the review expectations are all tied to the Flutter documentation. Before your first pull request, read the wiki linked from the repository description, install the latest stable Flutter, run `dart run dash_site --help` to see the available commands, and confirm which of the two sites your change touches, the documentation site or the marketing site and blog. ## FAQ ### What is cfug/flutter.cn and how do I get started? It is the repository for the Flutter CN docs translation plan, and the project description points contributors to the repository wiki as the place to start. The Chinese documentation site it serves is at docs.flutter.cn. ### How do I build the Flutter documentation site locally? Install the latest stable Flutter release, which includes Dart, then run `dart pub get` and `dart run dash_site serve` from the repository root. The port is printed to your terminal, and `dart run dash_site --site=www serve` serves the marketing site and blog instead. ### Do translated pages have to follow the same style rules as the English docs? Yes. The project requires the Google Developer Documentation Style Guidelines, including avoiding the first person and the future tense, and asks that changes not be run through Grammarly before being submitted as a pull request. ### Where should I report a problem with the Flutter API reference pages? In the `flutter/flutter` repository rather than the website repository, because the API docs are embedded in Flutter's source code and are handled by the engineering team. ### Do I need to build the site before submitting a translation change? For simple text fixes the README says you probably do not need to, and the GitHub UI is often the easiest route. If the change touches code samples in the examples directory, adds or removes pages, or affects navigation, you should build and test, and `dart run dash_site check-all` validates the examples, sites and tool directories. ## Sources - [cfug/flutter.cn on GitHub](https://github.com/cfug/flutter.cn) - [Issues](https://github.com/cfug/flutter.cn/issues) - [Project website](https://docs.flutter.cn) - [README](https://github.com/cfug/flutter.cn/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cfug-flutter-cn