# GitHubDesktop2Chinese: rewriting GitHub Desktop's interface from a JSON map

> GitHubDesktop2Chinese is a small C++ loader that replaces the English strings inside GitHub Desktop's bundled JavaScript with Chinese text, using a regex driven JSON mapping file. It is aimed at Windows users who need a Chinese interface and accept running a tool again after every GitHub Desktop release.

**cngege/GitHubDesktop2Chinese** — GithubDesktop语言本地化(汉化)工具 【GitHub桌面客户端中文汉化】

- Repository: https://github.com/cngege/GitHubDesktop2Chinese
- Stars: 1,039 · Forks: 140
- Language: C++
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/cngege-githubdesktop2chinese

## GitHubDesktop2Chinese edits main.js and renderer.js instead of shipping a patched app

GitHub Desktop is a desktop client that most people install from a packaged installer, and the interface that ships with it is English. GitHubDesktop2Chinese takes a different route than shipping a fork or a patched installer. It is a standalone C++ program that opens the installed application and rewrites the English text it finds in the two JavaScript bundles the client relies on, main.js and renderer.js, replacing it with Chinese text drawn from a mapping file. The project describes itself as a program that automatically replaces GitHub Desktop's text with target language text, and it highlights compatibility with frequent GitHub Desktop releases as its main advantage. The reason is the substitution method: because the text is located by matching rather than by relying on fixed byte offsets or on the structure of the surrounding code, a GitHub Desktop update that changes unrelated parts of the bundle does not automatically break the mapping. The project also argues that its own upkeep stays low, since when an update leaves only one or two strings untranslated a maintainer can add those entries by hand. You are not adopting a new client. You are adopting a translator that runs once over files the client reads at launch.

## The localization.json map is regex based, with a third parameter for variable text

Everything the loader knows lives in one file, json/localization.json, which stores the mapping between the English text inside GitHub Desktop and the Chinese replacement. The matching is done with regular expressions, so a mapping entry can match a string that contains English text rather than requiring an exact literal. The file has a version integer, a minversion string holding the minimum loader version required to read it, and a tip array whose strings the loader shows as notifications. There is also a select object used for partial localization: each entry has a replaceFile naming the file to patch, a tooltip shown in the prompt, an enable flag, and a replace array holding the chosen replacement items. The bulk of the mappings live in four arrays. main and renderer hold entries for main.js and renderer.js, while main_dev and renderer_dev hold the same kinds of entries but are used for quick replacement during development. A third parameter per mapping entry acts as a find pattern: the loader runs a global regex search for it, and the matched text is substituted into the second parameter with the special characters replaced using the marker #{number}. That is how a string that changes at runtime, such as one carrying a count or a filename, can still be translated. The loader also compares the file's minversion against its own version, and if the requirement is not met it either exits with a notice when --nopause is defined or asks whether to force the replacement.

```javascript
	const nn = !1;
	function rn() {
		return !nn && "1" === process.env.GITHUB_DESKTOP_PREVIEW_FEATURES
	}
```

That block is the preview flag check from the client's own script, and it is why the environment variable section further down works at all.

## Two ways to run the loader, and a re-run after every GitHub Desktop update

The usage instructions give two paths and they differ in one practical way: whether the mapping file comes from the network. In the first method you download or build GitHubDesktop2Chinese.exe, double click it, and it goes online to fetch the latest localization.json before doing its work. In the second method you put the executable and a localization.json file in the same folder and run it, so the translation is applied from the copy sitting next to it. The second method matters when the machine has no direct internet access or when you want to pin a specific mapping revision while testing your own entries. Both methods have the same cost, and the project states it plainly: each time GitHub Desktop updates to a new version, the program has to be run once more for the Chinese interface to be applied again. That is the central trade-off of the approach. There is no daemon watching for client updates, no patched installer and no build of the client with the translation compiled in. The localization also does not survive a client reinstall, since the reinstall restores the original JavaScript bundles. If you use GitHub Desktop heavily and update it often, that repeated cycle is the price of having the interface in Chinese.

## Building the loader with VS2022 and CMake, and what the repository contains

The project can be built from source, and the instructions are aimed at Windows developers: clone the repository, then open the project folder with VS2022 using CMake support, which builds it directly from the editor. The top level of the repository gives the shape of the code. CMakeLists.txt and CMakePresets.json drive the build, GitHubDesktop2Chinese.cpp and GitHubDesktop2Chinese.h hold the program itself, and the Utils and include directories carry the supporting code. The json directory holds the mapping file and the notes that contributors are asked to read, while the openssl-proj directory carries the TLS dependency. The third party libraries are named in the README: CLI11 for command line parsing, cpp-httplib for the HTTP calls that fetch updates, nlohmann/json for parsing the mapping, spdlog for logging and WinReg for reading the Windows registry. The registry access matters for network behaviour, because the completed feature list says the loader supports a system HTTP proxy taken both from environment variables and from the system proxy registry entry. The CLI library is what provides the --nopause flag and the minimum version check described earlier. Anyone who wants to change the download or replacement behaviour has a conventional CMake C++ project to work in, not a script to edit.

## The shift key test loop behind main_dev and renderer_dev

The translation workflow explains how contributors avoid replacing hundreds of entries every time they test a single string. A translator clones the repository, reads the notes file in the json directory, and adds new entries to json/localization.json following the format of the entries already there. The file is then placed in the program directory so the loader can read it, and a pull request is opened. For work that is only partly finished, the new entries are placed in the main_dev or renderer_dev arrays instead of the production ones, and the software is launched while holding shift, which turns on a mode that replaces only the specified mapping entries and cuts the time spent replacing the whole interface. Once the entries are confirmed, they are moved to the end of the main or renderer array and the pull request is submitted. The loader side of this loop is visible in the feature list as well: it detects its own updates and offers a one click update, it can show a notice after the replacement is done listing everyone involved in the project, and it restores the files to their pre localization state if the run fails. That last item matters in practice, since a partial or failed replacement would otherwise leave the client with a broken JavaScript bundle.

## Windows runtime and OpenSSL failures are the common way the loader dies

The failure modes listed in the README are all Windows runtime problems rather than translation mistakes. If the loader reports that it cannot find an OpenSSL DLL, the stated fix is to update to the latest release. If double clicking GitHubDesktop2Chinese.exe does nothing or the window flashes and closes, the loader may be missing MSVCP140_ATOMIC_WAIT.dll, and the fix is to install the Microsoft Visual C++ Redistributable 14.42.34433.0, choosing vc_redist.x64.exe on a 64 bit machine or vc_redist.x86.exe on a 32 bit one. If the redistributable is already present and the program still will not start, the instructions ask you to check the program directory for leftover MSVCP140.dll and VCRUNTIME140.dll files and delete them, since a stale copy next to the executable can shadow the installed runtime. Two more constraints follow from the design. The replacement is a text substitution inside the installed client, so a partially applied run or a mismatched client version can leave untranslated or wrongly translated strings, which is why the loader restores the previous files when a run fails. And the automatic mode needs network access, so a machine behind a proxy that the registry and environment variables do not describe will not be able to fetch a fresh mapping file.

## Preview builds are reached through an environment variable or a loader prompt

GitHub Desktop hides some options behind a preview flag, and the project documents the internal check that decides whether those options appear. A constant is set to false, and a small function returns true only when that constant is false and the environment variable GITHUB_DESKTOP_PREVIEW_FEATURES holds the string 1. When the function returns true, the preview mechanism is switched on. The loader exposes the same switch in two ways, one through the environment and one through the application itself.

```cmd
  > set GITHUB_DESKTOP_PREVIEW_FEATURES=1
  > "GitHub Desktop.lnk"
```

The set command in that block assigns the variable for the current command prompt session, and the second line is the shortcut for GitHub Desktop. The same result can be obtained through the loader, which offers to turn the preview option on when prompted. The mapping file carries a matching capability, since the feature list includes adding a preview conversion to the mapping file, so the preview state can be handled as part of the localization pass rather than as a separate manual step.

## What the release history and the Apache-2.0 licence imply for adoption

The repository is not archived, and the last push was on 2026-09-27. The three most recent tagged releases are v1.2.2 on 2026-03-16, v1.2.3 on 2026-03-18 and v1.2.4 on 2026-03-29, which shows that loader updates and mapping updates arrive as separate versioned artifacts. The licence is Apache-2.0, with the licence text in LICENSE.txt at the repository root. That licence permits modification and redistribution of the loader and the mapping file, and the pull request workflow described above places contributed translation entries under the same terms, so a company that needs to carry its own wording can fork the mapping file and keep doing so without asking permission. This is a licensing note rather than legal advice, and anyone with a specific compliance requirement should read LICENSE.txt and confirm it with their own counsel. The practical conclusion is narrower than the licence permits: the tool gives you a maintained Chinese interface only as long as somebody keeps mapping the strings that a newly released GitHub Desktop introduces, and the project accepts that the newest release may initially be missing a few entries.

## Conclusion

Adopt GitHubDesktop2Chinese if you need a Chinese GitHub Desktop on Windows and are willing to re-run the loader after each upstream release. Skip it if you need a permanent translation, work on macOS or Linux, or cannot accept a tool that edits the application's JavaScript files. Before trusting it, check that json/localization.json covers the strings your GitHub Desktop build actually shows, confirm your VC++ runtime is present, and run the loader once to see the result in your own account interface.

## FAQ

### Do I need to run GitHubDesktop2Chinese again after a GitHub Desktop update?

Yes. The project states that each time GitHub Desktop updates to a new version, the program must be run once more before the Chinese interface is applied again, because the client restores its original JavaScript bundles.

### How do I add my own translations to GitHubDesktop2Chinese?

Add entries to json/localization.json in the format of the existing ones, place the file in the program directory so the loader can read it, and open a pull request. Partly finished work is kept in the main_dev or renderer_dev arrays and moved into main or renderer after testing.

### What should I do if GitHubDesktop2Chinese.exe flashes and closes on Windows?

The loader may be missing MSVCP140_ATOMIC_WAIT.dll, so install the Microsoft Visual C++ Redistributable 14.42.34433.0, choosing vc_redist.x64.exe or vc_redist.x86.exe to match your machine. If it still fails, delete leftover MSVCP140.dll and VCRUNTIME140.dll files in the program directory, and treat an OpenSSL DLL error as a reason to update to the latest release.

### Does GitHubDesktop2Chinese need an internet connection?

Only one of the two documented methods does. Running the executable on its own makes it fetch the latest localization.json automatically, while placing the executable and a localization.json file in the same folder and running it applies the translation from that local copy.

## Sources

- [cngege/GitHubDesktop2Chinese on GitHub](https://github.com/cngege/GitHubDesktop2Chinese)
- [Issues](https://github.com/cngege/GitHubDesktop2Chinese/issues)
- [License: Apache-2.0](https://github.com/cngege/GitHubDesktop2Chinese/blob/main/LICENSE)
- [README](https://github.com/cngege/GitHubDesktop2Chinese/blob/main/README.md)
- [Releases](https://github.com/cngege/GitHubDesktop2Chinese/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cngege-githubdesktop2chinese