# sparanoid/chinese-copywriting-guidelines: A Rulebook for Spacing and Punctuation in Chinese Text > The repository is a Markdown style guide, not software. It defines where spaces and punctuation belong when Chinese, Latin script and numbers share a line, and it points readers to a separate family of tools that apply the rules automatically. **sparanoid/chinese-copywriting-guidelines** — Chinese copywriting guidelines for better written communication／中文文案排版指北 - Repository: https://github.com/sparanoid/chinese-copywriting-guidelines - Stars: 15,730 · Forks: 1,837 - Language: Unknown - License: MIT - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/sparanoid-chinese-copywriting-guidelines ## What the Chinese Copywriting Guidelines Actually Are This repository is a document. Its stated purpose is to unify Chinese copy and typography conventions so that team members spend less time on the same formatting arguments and the resulting pages read better. The README is written in Traditional Chinese, with README.en.md and README.zh-Hans.md as translations of the same content. The rules cover four areas. Spacing between Chinese characters and Latin words, between Chinese and digits, and between digits and units. Punctuation, specifically not stacking exclamation or question marks. Full-width versus half-width characters, including the rule that Chinese punctuation is full-width while numbers stay half-width. And capitalisation of proper nouns such as GitHub or Microsoft Corporation. The intended reader is a writer, editor or front-end developer producing Chinese content, not someone looking for a library. The repository lists no runtime dependency for the rules themselves. ## The Spacing Rules and Their Exceptions The core rule is that a space belongs between Chinese characters and Latin text. The README gives a correct example and two incorrect ones, showing that a missing space on either side of a term like `AVObject` breaks the pattern. The same logic applies between Chinese and Arabic numerals, and between a number and its unit: 10 Gbps and 20 TB are correct, 10Gbps and 20TB are not. The exceptions matter more than the rules for anyone applying this by hand. Degrees and percentages take no space: 90° and 15% are correct, 90 ° and 15 % are not. Full-width punctuation takes no space against adjacent characters, so a comma directly after iPhone is right and a floating comma is wrong. Product names that have an official form, such as 豆瓣FM, are written the way the vendor writes them rather than by the general rule. The README also addresses whether CSS can do this for you. It points to the `text-spacing` property in CSS Text Module Level 4 and to Microsoft's `-ms-text-autospace`, then states that neither is widely supported and that user interfaces on macOS, iOS and Windows do not expose the feature. The conclusion drawn is that manual spacing stays necessary. ## Punctuation, Width and Proper Nouns The punctuation section takes a clear position against repeated marks. Mainland Chinese punctuation usage permits stacking, the README says, but stacking damages the appearance of a sentence, so a single exclamation mark or a single question mark is preferred. Where a question and an exclamation are both intended, the guide accepts one of each rather than a run of them. On width, the rule is that Chinese punctuation is full-width and numbers are half-width. The README carves out an exception for design files and posters where a very small amount of text needs to align, in which case full-width digits are acceptable. It also states that a complete English sentence or a special noun keeps half-width punctuation, and that an English book or periodical title inside a Chinese sentence should be italicised rather than wrapped in Chinese title marks. Proper noun capitalisation is treated briefly and explicitly as an English writing concern rather than the guide's own subject. The examples contrast GitHub with github, GITHUB, Github and gitHub. One note is practical for front-end work: when a design calls for all-uppercase or all-lowercase display, the HTML should carry the standard casing and `text-transform: uppercase;` or `text-transform: lowercase;` should handle the presentation. ## Installing the Guideline and Applying It to a File There is nothing to install for the rules themselves; you read the README. What the repository does provide is a package.json whose test script runs remark over the Markdown, with remark-preset-lint-consistent, remark-preset-lint-recommended and a list-item indent rule configured. That tooling checks the document's own Markdown, not your Chinese prose. The README's tools table is where you go for automatic spacing, and it lists pangu.js, autocorrect and their ports in Go, Java, Python, Ruby, PHP, Vim, Vue and several editors. To work on the guideline document locally, clone the repository and install the dev dependencies with pnpm, since the repository carries a pnpm-lock.yaml: ```bash pnpm install pnpm test ``` The test script is `remark .`, so a clean run prints no lint errors for the Markdown files. If remark reports problems, they concern Markdown structure such as list indentation, not whether you put a space before `AVObject`. For the prose rules, the README points at the pangu family. A JavaScript project that renders Chinese text alongside Latin terms can add pangu.js and let it insert the spaces at render time, which is the approach the guide's own examples describe as the manual habit it wants you to keep until CSS support arrives. ## Where the Guideline Stops Being Useful The most important limitation is that this is a convention document with no enforcement mechanism of its own. Nothing in the repository fails a build when a contributor writes 10Gbps instead of 10 Gbps. The remark configuration only governs the Markdown files in the repository, and the README itself does not present a linter for the typographic rules. If your team needs every pull request checked, you are relying on the third-party tools in the tools table, each with its own coverage and its own release cycle. The guide also mixes two categories of rule without labelling them equally. The spacing and width sections read as settled conventions. The section headed 爭議 (controversies) explicitly says that the usages it discusses are grammatically correct either way and carry a personal flavour, covering whether to put a space around hyperlinks and whether Simplified Chinese should use corner brackets. A team that adopts the whole document as policy will end up enforcing preferences that the document itself declines to call rules. Finally, the guide is written from a Traditional Chinese starting point. Simplified Chinese readers are served by a translation file, and the corner bracket question in the controversies section applies specifically to Simplified Chinese, so the translation is not a cosmetic detail. ## How This Differs from pangu and autocorrect The nearest alternatives are the tools the README itself lists. pangu.js and its ports in Go, Java, Python, Ruby, PHP and Vim take a string and insert spaces between CJK characters and half-width alphanumerics. autocorrect, written in Rust and available as a CLI, a WASM build, a VS Code extension and bindings for Node.js, Python, Ruby, Java, Go and PHP, goes further and also normalises punctuation and width. The difference in approach is the direction of the dependency. This repository is the specification; pangu and autocorrect are implementations. A team can adopt the guideline as the shared reference for reviewers and still choose either tool, or neither, without changing the document. The reverse does not hold: neither tool explains why 15% takes no space while 20 TB does, and neither covers capitalisation of proper nouns or the choice between corner brackets and curly quotes. There is also a maintenance difference worth noting. The guideline changes through pull requests to Markdown, with the last push recorded on 2026-07-07 and releases v1.0.0 and v1.0.1 from 2021 and 2022. The tools have their own schedules and their own issue trackers. ## Licence, Translations and Upgrade Cost The repository is MIT licensed, and package.json declares the same. For a document, that means you can copy the rules into an internal style guide, translate them, or quote the examples, provided you keep the licence and copyright notice. It is not legal advice, and the MIT text in the LICENSE file is the authority rather than this summary. Upgrade cost is close to zero for consumers. There is no dependency to bump and no API to break. If you vendor the text, you inherit the cost of tracking changes yourself, and the CHANGELOG.md is the file to watch. The translations are managed through Crowdin, with a crowdin.yml in the repository root, so the English and Simplified Chinese files can lag the Traditional Chinese original between updates. The package.json also configures release-it with signed commits and tags and with npm publishing disabled, which tells you the release process is aimed at GitHub releases rather than a registry package. You cannot install this guideline from npm as a set of rules. ## Conclusion Adopt this guideline if your team writes Chinese product copy, documentation or marketing pages and spends review time arguing about where the spaces go; the correct and incorrect examples settle those arguments with a link. Do not adopt it if you need an enforced formatter, because the repository itself ships no linter for the prose rules, only remark-lint for its own Markdown structure. Before you point anyone at it, check the README.en.md and README.zh-Hans.md translations against the Traditional Chinese original, since the English file is the one most of your readers will open first. ## FAQ ### Is sparanoid/chinese-copywriting-guidelines a program I can install? No. It is a Markdown document that states spacing, punctuation, width and capitalisation conventions, and its package.json only wires up remark linting for the repository's own Markdown files. The README points to separate tools such as pangu.js and autocorrect if you want the spacing applied automatically. ### Does the guideline cover Simplified Chinese as well as Traditional Chinese? Yes. The README is written in Traditional Chinese and the repository also contains README.zh-Hans.md for Simplified Chinese and README.en.md in English. The controversies section discusses corner brackets as a Simplified Chinese question specifically. ### Why does the guide say not to put a space before a percent sign or a degree symbol? The spacing section lists degrees and percentages as exceptions to the number-plus-unit rule, giving 90° and 15% as correct and 90 ° and 15 % as incorrect. Units such as Gbps and TB do take a space after the number. ## Sources - [Issues](https://github.com/sparanoid/chinese-copywriting-guidelines/issues) - [License: MIT](https://github.com/sparanoid/chinese-copywriting-guidelines/blob/master/LICENSE) - [README](https://github.com/sparanoid/chinese-copywriting-guidelines/blob/master/README.md) - [Releases](https://github.com/sparanoid/chinese-copywriting-guidelines/releases) - [sparanoid/chinese-copywriting-guidelines on GitHub](https://github.com/sparanoid/chinese-copywriting-guidelines) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sparanoid-chinese-copywriting-guidelines