DEV Community

Fernando Paladini
Fernando Paladini

Posted on

I Shipped the Harness Guide in Hindi and Simplified Chinese — Here's Why That Matters More Than Another CLI Flag

Your team runs Cursor and Claude Code in production. The scanner says you are at L2. The failed checks link to remediation recipes.

Your senior engineer in Bangalore reads the guide in English at midnight before a release. Your teammate in Shanghai opens the same page and hits the same wall. The harness is multilingual-ready — the documentation was not.

That gap is not cosmetic. Harness engineering is the practice of wrapping a coding agent with context, rules, tests, and guardrails so output is reliable, not lucky. When the maturity model lives only in English, half your team inherits the harness without inheriting the playbook.

harness-score 1.2.0 does not add a new CLI flag or check. It ships the full VitePress guide in Simplified Chinese (zh-CN) and Hindi (hi-IN) — bringing the project to five locales total.

This article explains why that release train mattered, what actually shipped, and how to verify it on your machine in under a minute.

Prerequisites

No code changes required in your repository — this is a documentation release.

The tension: global tools, English-only playbooks

India and China are two of the largest pools of professional software developers on the planet. Both markets adopt AI coding assistants aggressively — Cursor, Claude Code, Windsurf, Cline, Continue, Copilot.

The tools read config in any repo. The maturity guide — the document that explains what L3 Sensing means, why HKS-05 matters, and how to wire hooks that block destructive commands — was English-only until 1.1 added pt-BR and es.

That helped LatAm and Brazil. It did not help a team in Pune debugging why their repo stuck at L1, or a team in Shenzhen trying to understand dimension thresholds before gating CI.

1.2.0 closes that gap for two more audiences:

Locale Language URL
English (default) English paladini.github.io/harness-score
pt-BR Português (Brasil) /pt-BR/
es Español (LatAm) /es/
zh-CN 简体中文 /zh-CN/
hi-IN हिन्दी /hi-IN/

Each locale ships 10 guide pages: landing, maturity model, check catalog, multi-harness chapter, sensors, guardrails, and more. The language switcher in the header lands you on the equivalent page — not the homepage.

Source: v1.2.0 release and CHANGELOG.

Why documentation i18n is infrastructure, not marketing

A common objection: "Developers read English anyway."

Some do. Many read English for code and their native language for concepts they need to explain to teammates, managers, and new hires. Harness maturity is a team conversation — standups, PR reviews, CI gate decisions. If only one language can carry that conversation, the harness becomes a solo sport.

The harness-score project treats translations as first-class infrastructure:

  1. Check catalog anchors stay identical — #ctx-01, #hks-05, etc. — so CI log links work in every locale.
  2. English remains the contract — translations track the English source; CI enforces anchor parity across all five locales.
  3. hreflang SEO — search engines surface the right locale instead of dumping everyone on the English homepage.

That is the same discipline as keeping check IDs stable in the CLI: public API, not prose decoration.

What 1.2.0 actually ships (and what it does not)

Shipped

  • Full VitePress guide in zh-CN (Simplified Chinese)
  • Full VitePress guide in hi-IN (Hindi, Devanagari script)
  • Language switcher wiring for both locales on home and guide pages
  • Same maturity model, same 36 checks, same 108-point ladder as 1.1.0

Not shipped (honest limits)

  • No scanner changes — scores, check IDs, point totals, and thresholds are identical to 1.1.0
  • CLI output strings remain English — only the web guide is translated
  • Not a new maturity level — this is a docs-only minor

If you were on 1.1.0, upgrading to 1.2.0 changes nothing about your score. It changes who can read the remediation recipes.

Verify in 60 seconds

Install and scan (unchanged from prior versions):

npx harness-score@1.2.0

Open the guide in your locale:

Switch languages from the header on any guide page — confirm you land on the equivalent chapter, not /.

Track progress over time (still works the same):

harness-score --json > baseline.json
# ... improve the harness ...
harness-score@1.2.0 --diff baseline.json

Gate CI at L3:

- uses: paladini/harness-score/action@main
  with:
    min-level: '3'

How this fits the release series

Version Headline Type
1.0.0 Stable API, multi-harness OR semantics Major (stability)
1.1.0 EN / pt-BR / es guide + HKS-05 hook-path fix Minor
1.2.0 zh-CN / hi-IN guide Minor (docs only)

Each minor expands who can use the playbook without moving the maturity goalposts. That is deliberate: teams gating CI on L3 should not wake up to a new ladder because someone translated a chapter.

What I would do differently if starting today

I would have shipped i18n earlier — before 1.0 — if the anchor-sync CI gate existed on day one. Translating five locales without drift requires mechanical enforcement (docs.test.ts keeps check-catalog anchors aligned). Building that first made 1.1 and 1.2 possible without breaking links in existing CI logs.

If you maintain developer docs for a global audience: invest in anchor-stable translations before you invest in a sixth locale. One broken #hks-05 link in Hindi is worse than no Hindi page at all.

Try it 

npx harness-score@1.2.0

Links:

Takeaway

Another CLI flag gets a tweet. A translated maturity guide gets adopted by teams who were never going to read English remediation recipes at midnight.

1.2.0 is docs-only — and that is the point. The scanner was already deterministic, multi-harness, and CI-gateable. What was missing was a playbook in the languages your team actually thinks in.

Which locale would you want next — and what is your repo's current level? Drop both in the comments.

Top comments (0)