WinUtil_CN: a Chinese localization of the Chris Titus Tech Windows utility

What WinUtil is, and what the fork adds

WinUtil is a script by Chris Titus Tech that does the things people ask Windows to do badly: install a batch of applications, apply registry tweaks, configure Windows Update policy and assemble a Windows 11 installation image. It runs as a single PowerShell script that a user executes on their own machine.

WinUtil_CN is the Chinese localization of it, and the README describes the scope in three parts: a Chinese interface, Chinese explanations, and Chinese support for the Win11ISO workflow. The point of the fork is stated plainly. It is for Chinese-speaking users, providing a Chinese interface, Chinese descriptions, Chinese explanations of the Tweaks, and Chinese notes on Win11ISO, so that a user can understand what each optimisation item, repair option, update policy item and image-building option actually does.

The localisation approach is the interesting part, and it is a deliberate engineering decision rather than a translation pass. The repository keeps the upstream WinUtil logic intact as much as possible, translating user-facing text and adding Chinese explanations for the tweaks, repair options, update policies and the Win11ISO workflow.

There is also an explicit statement of position. The project is a Chinese maintenance branch of WinUtil, not an official version, and the upstream project is Chris Titus Tech's WinUtil. The two things it does are preserve the upstream functional logic and add a Chinese UI and Chinese explanations.

The disclaimer section is more careful than most, and it is worth reading in full. It says the project is a personally maintained unofficial Chinese localisation with no affiliation with upstream. It says the author tries only to translate and explain user-visible text, but that WinUtil involves system optimisation, registry operations, services and update policies, so you should back up before using it. And it says that if you trust the original author's version more, you should go with the upstream repository.

That last sentence is a project making a clear statement about what it is and is not, and it is the sort of honesty that makes a fork easier to evaluate.

Running it, and the encoding problem

The recommended way to run the script is directly, with administrator PowerShell:

irm "https://raw.githubusercontent.com/constansino/WinUtil_CN/refs/heads/main/winutil.zh_CN.ps1" | iex

If the raw.githubusercontent.com host is unreliable, the jsDelivr mirror is offered as a fallback:

irm "https://cdn.jsdelivr.net/gh/constansino/WinUtil_CN@main/winutil.zh_CN.ps1" | iex

And there is a third option, the GitHub Release asset:

irm "https://github.com/constansino/WinUtil_CN/releases/latest/download/winutil.zh_CN.ps1" | iex

Three URLs for the same script, and the README explains why all three exist. Windows PowerShell 5.1 sometimes decodes a piped remote script from a GitHub Release or a CDN asset as something other than UTF-8, which produces garbled Chinese characters. The raw link is preferred because it returns the script as text/plain with a UTF-8 charset.

The workaround for the other two is worth understanding, because the shape of it explains the design of the files. The current Release asset named winutil.zh_CN.ps1 is a pure ASCII launcher, which reads the full Chinese script again as UTF-8. If you run one of the other Release or CDN scripts and still hit garbled text, there is a longer command that fetches the file with Invoke-WebRequest, rewinds the raw content stream and decodes it explicitly as UTF-8 before piping it to the interpreter.

That ASCII launcher trick is the elegant part of the arrangement. A launcher that contains no non-ASCII bytes cannot be mis-decoded, and it can then read the real script with the encoding it knows is right.

The alternative is to download the file and run it locally, which the README recommends as more auditable:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force
.\winutil.zh_CN.ps1

The `Unblock-File` step removes the Mark of the Web from the downloaded file, which is what stops PowerShell's execution restrictions or a crash. The `Set-ExecutionPolicy` line is scoped to the process rather than the machine, so the policy change disappears when the shell closes. Running locally is the better option because it is easier to audit the script's contents before executing it, and the README says so plainly.

The three files, and the upstream sync strategy

The repository holds three artefacts, and the file naming is what you need to understand to use the project correctly.

`winutil.zh_CN.ps1` is the stable filename, always pointing at the currently recommended version to run. `winutil.zh_CN.commented.20260804.ps1` is the current Chinese-commented and Chinese-interface maintenance version. And `winutil.zh_CN.full.patch.20260804.diff` is the complete patch generated against upstream 26.08.04, with the note that the official script's line endings must be normalised to LF before applying it.

So the first is what you run, the second is what you read, and the third is what you diff. That third file is the most interesting artefact in the repository, and keeping it is the mechanism behind the whole approach. A complete patch against a named upstream release is a reviewable record of every change the localisation makes, and it can be reused or audited later.

The upstream sync strategy is described as four rules, and they are all about minimising merge conflicts.

Do not change functional logic, only user-facing text. Prefer maintaining the configuration layer, with fields such as Title, Description, Content and category. When upstream updates, sync the official script first, then migrate the Chinese fields, then fill in translations for the newly added items. And keep the complete patch at the same time, so it can be reused and reviewed later.

The second rule is the load-bearing one. If the Chinese text lives in configuration fields rather than being scattered through the logic, then a new upstream release brings new logic and new field values, and the merge is a question of which field values to replace rather than a question of which lines to keep. That is a much smaller merge surface.

The version tracking is visible in the release names. The two listed releases are 26.08.04-cn.20260804, which pairs the upstream WinUtil release 26.08.04 with the Chinese maintenance date of 2026-08-04, and 26.04.21-cn.20260510, which pairs upstream 26.04.21 with the Chinese date of 2026-05-10. Each release therefore records both what upstream it tracks and when the Chinese side was last updated, which tells you the age of the translation without having to check anything else.

The README also names the current synced upstream version as 26.08.04 and links the upstream repository and its releases page, so the chain back to Chris Titus Tech's project is one click away.

What has been translated

The localisation coverage is described in four groups, and the details say more about the work than the word count does.

The top navigation and common buttons come first. The tabs for Install, Tweaks, Config, Updates and Win11ISO have Chinese labels and common tooltips, and the new software category filters on the install page, the advanced options in Tweaks and the AppX removal page have been translated.

The Tweaks page is where most of the effort went. Item titles are in Chinese, item descriptions are in Chinese, and for many items an explanation better suited to Chinese-speaking users has been added, to help someone judge what the switch actually changes and what the risk is. That last point is the one that distinguishes this from a plain translation. A tweak's English description is often terse and assumes knowledge of the underlying registry or service behaviour, and the added explanation is the part that makes the item comprehensible rather than merely readable.

The other pages follow. The Install, Config, Updates and Win11ISO pages have Chinese explanations in their common areas, and the three Windows Update policy cards in the new version, the AppX operation status and the Win11ISO running notices have been filled in.

One deliberate non-translation is worth noting, because it shows the fork thinking about the reader rather than just the language. Software names such as 7-Zip, VS Code and PowerShell 7 are usually kept as the original product names, to avoid making comparison difficult. Translating a product name that the user will search for by its English name is a translation that makes the tool harder to use.

The repository also carries a file whose name is a Chinese-language promotional text, and the README's own keywords section lists the search terms the project is aiming to be found by, including the repository name and several Chinese phrasings of WinUtil Chinese edition. That is a small reminder that a localisation project has an audience and a search presence to think about, not only a codebase.

Contributions are invited in three forms: a pull request adding a Chinese translation or a more accurate explanation for an entry, an issue pointing out a translation that is inaccurate or an explanation that is unclear, or a pull request syncing a new upstream release.

Who this fork is for, and what it is not

The scope of the fork is easy to misread from the outside, so it is worth setting out who it serves and who it is not for.

It is for the Windows user who wants the WinUtil workflow without having to read English descriptions of registry modifications. The point is that the operator is not comfortable with the surrounding tooling and the descriptions of what each switch does are terse in the original.

It is not for the person who wants the newest upstream features immediately. The sync model is explicitly two-stage, upstream first and the Chinese fields second, so a new upstream release lands in this fork after the maintainer has done the translation pass. A gap of a few weeks between an upstream release and the matching Chinese release is inherent to the approach rather than a defect.

It is also not an official product, and the README does not pretend otherwise. The disclaimer repeats that this is a personally maintained unofficial Chinese localisation with no relationship to upstream, and it names the upstream repository and its releases page directly so a reader can go there.

The upstream link is not a formality. The WinUtil project is by Chris Titus Tech, and this repository is a Chinese maintenance branch of it rather than an independent implementation, which means the two share a release cadence and a feature set. Every change here is a change to that project in a different language.

For a reader deciding between the fork and the original, the honest answer is that the fork's value is comprehension. If you read English comfortably enough to understand what a registry tweak does, the upstream version gives you the same functionality and a fresher sync. If you do not, the fork saves you from guessing, and the added explanations are the part that makes it worth running.

The contribution model is the same shape as the sync model. Translations and explanations arrive as pull requests against the current upstream release, and a pull request that syncs a new upstream release is also welcome, so the work of keeping the fork current is shared rather than resting on one person.

Editorial conclusion

Adopt WinUtil_CN if you are comfortable with PowerShell and want a Chinese interface and plain explanations of what each Windows tweak does, since that is the whole contribution it makes. Do not adopt it if you would rather follow the upstream project, since this is a personal unofficial fork and the README itself points you to the original if you trust it more, and check first which of the three files you run, because the stable launcher, the commented build and the full patch differ in what they contain.

Frequently asked questions

Official sources

1. constansino/WinUtil_CN on GitHub
2. Issues
3. README
4. Releases