Step 1: Prepare Your README and Define the Translation Scope
First, make sure your existing README is complete and well-structured. A standard open source README typically includes:
- Project name and one-line description
- Feature list
- Quick start / installation guide
- Usage examples (with code blocks)
- API docs or configuration reference
- Contributing guide
- License
If your README is missing any of these sections, fill them in before translating. Otherwise you’ll need to add the missing content separately to every language version — doubling your work.
Copy the full README, and also create a terminology list — note any terms that should NOT be translated (project name, technical jargon, CLI commands, config keys, etc.).
Pitfall warning: Code comments and example output are the most commonly overlooked parts. If your code examples contain non-English comments or output strings, decide upfront whether to translate them. The recommended approach: translate all comments to English, but leave commands and variable names untouched.
Step 2: Use Claude to Translate into English
Paste your README into Claude with this prompt:
You are a senior open source technical documentation translator.
Please translate the following README into English with these requirements:
1. Use standard English technical terminology (e.g. "Install Dependencies", "Quick Start", "Configuration")
2. Do NOT translate the following proper nouns: [list your project name, CLI commands, config keys, etc.]
3. Translate inline code comments to English; leave the code itself unchanged
4. Preserve all Markdown formatting exactly (heading levels, lists, links, badges, etc.)
5. Tone: match popular open source projects (React, Vue README style) — professional but not stiff
6. Where the original text uses language-specific idioms, convert them to natural English equivalents rather than translating literally
README:
[paste full README]
After getting the English version, check these specifically:
- Technical accuracy: Are installation commands, API parameters, and config keys correct?
- Link integrity: Are all URLs preserved correctly?
- Formatting consistency: Are tables, code blocks, and lists syntactically intact?
- Natural flow: Does it read like it was written natively, not translated?
If you’re not confident in your English, Grammarly ($12/month) can check grammar, spelling, and natural expression — especially good at polishing “understandable but unnatural” English into something that reads like a native speaker wrote it.
Pitfall warning: Claude is generally excellent at translating technical docs, but there’s one common issue — it sometimes translates things that should stay as-is. For example, it might translate a package name or a CLI command. After translating, do a global search for non-ASCII characters and verify no original command strings were altered.
Step 3: Extend to Japanese or Other Languages
If your target users include Japanese developers, add a Japanese version. Continue in the same Claude conversation:
Great. Now translate the same README into Japanese with these requirements:
1. Use standard terminology from the Japanese tech community (e.g. "インストール" rather than "設置")
2. Use polite form (です/ます style)
3. Apply the same proper noun rules as the English version
4. Follow Japanese typographic conventions: use full-width parentheses and middle dots (・) for lists where appropriate
The same approach extends to Korean, Spanish, or any other language. Each additional language adds about 10 minutes of review time.
File naming convention:
README.md ← English (international default)
README_zh.md ← Chinese
README_ja.md ← Japanese
Note: GitHub displays README.md by default, so make the main README English — that’s what international contributors see first.
Pitfall warning: Japanese translations are more error-prone than English, especially katakana spellings of technical terms. If you don’t read Japanese, at minimum have someone who does give it a quick look. Or paste the translation back into Claude and ask: “Please check this Japanese README for unnatural expressions or incorrect katakana spellings.”
Step 4: Add Language Switcher Badges and Commit
Add language navigation links at the top of each README so readers can jump between versions:
English version (README.md) top:
<p align="center">
<a href="README.md"><strong>English</strong></a> |
<a href="README_zh.md">简体中文</a> |
<a href="README_ja.md">日本語</a>
</p>
Add the same navigation to each other language version, with the current language bolded and not linked.
Use Claude to generate the navigation headers for all files at once:
Please generate the language navigation header for each of these three README files:
- README.md (English, primary)
- README_zh.md (Simplified Chinese)
- README_ja.md (Japanese)
Requirements:
- Centered using Markdown/HTML
- Current language in bold, not linked
- Other languages as hyperlinks
Then commit to GitHub:
git add README.md README_zh.md README_ja.md
git commit -m "docs: add multilingual README (en, zh, ja)"
git push
Optional extras:
- Update your repo description to mention supported languages:
📖 Docs: English | 中文 | 日本語
- Add a note in
CONTRIBUTING.md explaining how to contribute translations (encourages the community to help maintain additional languages)
- If your README changes frequently, consider a GitHub Action that creates a reminder issue when the Chinese version is updated, prompting you to sync the other versions
Pitfall warning: The biggest ongoing cost of multilingual READMEs is keeping them in sync. Every time you update the English version, you need to update the others. A practical approach: use consistent commit message prefixes like docs(en): update installation guide so it’s immediately clear which language version changed and what needs to be mirrored.