GithubDesktopZhTool: a Chinese localization patcher for GitHub Desktop

What problem GithubDesktopZhTool solves, and for whom

GitHub Desktop ships an English interface. For Chinese-speaking developers who use it as their daily Git client, that means every menu item, dialog and error string is in a second language. GithubDesktopZhTool exists to replace those strings with Chinese. The README describes it as a localization tool for GitHub Desktop and points at the official app at https://desktop.github.com.

The audience is narrow and specific. It is not a general Git tool, it does not touch your repositories, and it does not change how commits or pushes work. It is for people who already run GitHub Desktop and want the interface in Chinese. The README also notes the author is based in Qingdao, Shandong, and that a WeChat public account carries more detailed documentation and first release announcements. That matters for adoption: the release notes on the repository are thin, and the README directs readers to the public account for the fuller write-up.

How the localization actually works: file replacement, not a plugin

There is no plugin API here. GitHub Desktop is an Electron application, and its UI logic lives in two JavaScript files, main.js and renderer.js, inside the app's resources directory. GithubDesktopZhTool ships translated copies of those files. You copy them over the originals.

The README gives the Mac target path as /Applications/GitHub Desktop.app/Contents/Resources/app and the Linux path as /usr/lib/github-desktop/resources/app. On Linux the README points at the community build at https://github.com/shiftkey/desktop rather than an official Linux package, which is worth noting: the Linux instructions assume that build's directory layout. Windows takes a different route, an executable named GithubDesktopZhTool.exe that the README says you open and then click the localization button.

The version 3.5.12 release notes list three changes: Copilot generating Chinese commit messages, fully customizable localization content, and more translated strings. The README does not document how the customization works or where the dictionary lives, so that claim cannot be verified from the repository text alone.

Installing GithubDesktopZhTool on Windows and replacing the Mac files

The README's Windows flow is the shortest: run the executable from the repository archive and click the localization button. The top level of the repository contains a single archive, GithubDesktop汉化工具.7z, which is where that executable comes from. The README does not document a command-line interface, a silent install flag, or an uninstall step.

For Mac, the README instructs you to copy main.js and renderer.js from the repository's Mac folder into the app's resources directory. Back up the originals first; the README does not describe a restore path. Copy the two files from the repository's Mac folder into the directory below, then relaunch GitHub Desktop and expect the interface in Chinese.

/Applications/GitHub Desktop.app/Contents/Resources/app

If the interface does not change, the README's own advice is to retry. The Linux instructions follow the same copy pattern but target a different directory, and writing there normally requires elevated permissions because it sits under /usr/lib.

/usr/lib/github-desktop/resources/app

The README links video walkthroughs for all three platforms on Bilibili, which is a reasonable sign that the file paths are the part users get wrong most often.

The version-matching constraint is the whole risk model

The README states plainly that you must keep the GitHub Desktop version matched to the localization tool version, otherwise GitHub Desktop may fail to open after localization. That is not a minor caveat. It means the tool is coupled to a specific upstream release, and GitHub Desktop updates on its own schedule.

When the app updates, the replaced files are either overwritten or left mismatched against new code. Either way you are back to running the tool again, and you can only do that once a matching tool release exists. The release history shows this cadence: 3.5.8 in early May, 3.5.8v2 two weeks later, 3.5.12 in early June. The v2 suffix suggests a fix shipped quickly after the first attempt, which fits the README's own line about retrying when localization fails.

There is no rollback documentation. The README does not tell you how to restore the original files, and on Windows the executable's behavior when it encounters an unexpected app version is not described. If you patch a machine you cannot easily reinstall GitHub Desktop on, that gap is the real cost.

Alternatives: localize upstream, or skip the patch

The most direct alternative is to use GitHub Desktop in English and rely on Git's own tooling for anything language-specific. Git itself does not localize commit messages, but GitHub Desktop's Copilot commit generation is what the 3.5.12 notes claim to translate into Chinese, so the feature overlap is partial.

A second option is the Linux build the README itself names, https://github.com/shiftkey/desktop. That project packages GitHub Desktop for Linux; it is not a localization layer, and its interface is English. If your reason for looking at GithubDesktopZhTool is simply that GitHub Desktop is not available on your distribution, shiftkey/desktop solves that problem and this tool does not.

A third path is contributing translations upstream to GitHub Desktop so they ship in the official app. That removes the version-matching problem entirely, but it depends on the upstream project accepting and shipping the strings, and the README gives no indication that this route is in progress.

Maintenance, licensing and what the repository does not say

The last push to the repository was on 2026-06-02, the same date as the 3.5.12 release. Two releases landed in May 2026 and one in June. Anyone adopting this should expect release activity to follow GitHub Desktop's own update cycle rather than a fixed schedule.

The repository does not declare a license. The top level contains the 7z archive, README.md and a WeChat QR image, and no LICENSE file is listed. That is a real adoption blocker for company use: without a stated license, you have no grant of rights, and the translated files are derived from GitHub Desktop's own JavaScript. Whether that derivation is acceptable depends on GitHub Desktop's license terms, which this repository does not discuss. This is not legal advice; if you need to ship this inside an organization, ask someone qualified.

Upgrade cost is recurring. Every GitHub Desktop update potentially invalidates the patch, and the README's instruction to keep versions matched means you cannot simply let the app auto-update and forget about it.

Editorial conclusion

Adopt GithubDesktopZhTool only if you are pinned to the exact GitHub Desktop version the tool release was built for and you accept that every app update means re-patching. Do not use it on a team machine you cannot restore, because the README warns that a version mismatch can leave GitHub Desktop unable to open. Before installing, check your GitHub Desktop version against the tool release number, confirm the Windows executable's source, and keep a copy of the original main.js and renderer.js so the replacement can be undone.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. robotze/GithubDesktopZhTool on GitHub