ZecHub DAO — Proposal A149: Phase 1 Progress Report

Community Collaborations
1

Summary

Phase 1 of ZecHub Proposal A149 — the repository-controlled translation framework that replaces runtime Google Translate, is implemented and running as a public pilot for the DAO to evaluate:

Both repositories are public for transparency. No Google Translate script,
widget, cookie, or DOM translation is used anywhere in the translated pages.

The three problems §2 addressed

Problem identified in the proposal Outcome
Privacy — Google Translate auto-loads, contacting Google infrastructure by default Eliminated. No Google Translate script/widget/cookie/DOM translation anywhere in the app (verified across the source and public assets).
UX / reliability — async MDX sometimes stays English until the user switches languages Solved. Content is static and repository-controlled, server-rendered from the submodule — no async-vs-translation race.
Terminology — e.g. “Arborist Calls” → “Chiamate dell’arboricoltore” Solved. A protected-terms glossary + CI keeps the 38 proposal terms verbatim; the Italian page keeps “Arborist Calls” unchanged.

Implementation plan — status against the proposal

Phase Deliverable Status
1. Framework next-intl repo-controlled i18n, locale routes, JSON UI dictionaries, translated MDX, English fallback, predictable PR structure, no runtime Google Translate :white_check_mark: Delivered
2. Glossary Protected-terms glossary :white_check_mark: Delivered — all 39 proposal terms (Zcash … Safepal) enforced by CI
3. Pilot (Italian) Italian translation of priority pages :white_check_mark: Delivered + exceeded — all 9 named priority items; 64 pages (~38% of the core wiki); 3 categories at 100%
4. Contributor workflow Docs: locate/edit files, add languages, protected terms, review :white_check_mark: CONTRIBUTING.md + docs/translation-contributor-workflow.md (incl. an “Adding a New Language” guide)
5. Gradual expansion Page-by-page expansion to the full wiki :next_track_button: Future / separate contributor PRs & bounties (per proposal §7)

What the pilot delivers

Architecture (Phase 1). A next-intl layer in the Next.js App Router. English stays canonical at its existing unprefixed URLs (e.g. /wallets, /zcash-organizations/electric-coin-company); Italian is served at /it/...; /en/... redirects to canonical English; any /it/... route without an Italian translation falls back to English automatically. UI text, navigation, and metadata come from JSON dictionaries (dictionaries/en.json, dictionaries/it.json) — the Italian dictionary is now at full parity with English, so the home page, navigation/category labels, and footer all render in Italian.

Content delivery. Wiki Markdown is consumed from a build-time git submodule read from local disk — there is no runtime GitHub API call and no GITHUB_TOKEN. To publish new translations: commit in the content repo → git submodule update --remote content in the app repo → commit the new pin → deploy.

Italian pilot content (64 pages, ~38% of the core wiki). Coverage by category:

  • Start Here: 10/10 · Using Zcash: 22/22 · Zcash Organizations: 9/9 — all complete
  • Zcash Tech: 13/14 · Zcash Community: 8/14
  • Zcash Use Cases: 1/7 · Glossary & FAQs: 1/4
  • Plus the home page and category navigation in Italian via the UI dictionary.
  • Full live per-page status: translations/TRANSLATION_STATUS.md in the content repo.

Terminology quality (Phase 2). A protected-terms manifest plus a CI check (scripts/check-protected-terms.mjs) verifies that the 39 protected Zcash terms present in each English source remain verbatim in the Italian translation. The check runs over all 64 translated pages and passes. This is what prevents regressions like “Arborist Calls → Chiamate dell’arboricoltore.”

Privacy result (precise). The pilot removes the need to send wiki page content to Google Translate at runtime; Italian content is maintained and served from repository-controlled translations. It does not yet claim the pages make zero third-party requests — see deferred follow-ups below.

Route convention (disclosure)

The proposal text showed prefixed routes (/en/, /it/, /es/). The pilot keeps English at its existing canonical URLs to avoid breaking current inbound links and search indexing; non-English locales use prefixed routes (/it/...), and /en/... redirects to the canonical English route. This is an implementation refinement that preserves SEO and existing links.

Prior-art credit: contributor 1337bytes

During development, ZecHub contributor @1337bytes opened draft PR #544 exploring next-intl, locale-prefixed App Router pages, and a git-submodule approach for localized Markdown. That is relevant prior architecture work, and the pilot’s switch to a build-time submodule content source was informed by it. The funded Phase 1 additionally delivers the repository-controlled Italian content, English fallback, protected-term validation, removal of runtime Google Translate, and a documented editorial/publication workflow.

Scope note

Per proposal §7, Phase 1 funds the framework, glossary, contributor docs, and a
pilot migration for one language across selected high-priority pages — it does not include translating the entire wiki into every language. Broader coverage is intended for separate contributor PRs / bounties (Phase 5).

Editorial status & deferred items

  • The Italian text is a strong first pass and benefits from a final native-speaker editorial review before upstream merge. (Terminology fidelity is already machine-enforced.)
  • Deferred privacy follow-ups (separate PRs, not Phase-1 blockers):
    YouTube nocookie/click-to-load embeds; local hosting of external image assets (i.ibb.co, GitHub user-attachments).

Next steps

  1. Community/editorial review of the Italian pilot pages on https://zechub-wiki-i18n.vercel.app.
  2. On approval, prepare the upstream PR(s) to ZecHub/zechub-wiki, crediting
    @1337bytes prior next-intl/submodule direction.
  3. Open Phase 5 expansion (additional pages/locales) as contributor PRs / bounties.

Caveats

  1. Static translation is not “free” just because LLMs and translation APIs can generate drafts quickly. In this pilot I tested several tools (including ChatGPT 5.5, Claude 4.8, DeepSeek V4, DeepL API), but grammar, syntax, tone, and Zcash-specific terminology still required careful review. If ZecHub decides to move fully toward static translations, this should be treated as an ongoing community/editorial effort rather than a one-time automation task.

  2. A possible alternative is LibreTranslate: it can provide machine translation similar in purpose to Google Translate, but can be self-hosted instead of loading Google’s runtime translation widget. That may improve the privacy posture, but it would still produce machine translations at runtime (the pages are translated when users open them) and would not provide the same repository-controlled review workflow, terminology enforcement, or stable translated pages as the static approach.

In my opinion, this static translation is the best option but still requires some effort from the community.

Your opinion and comments welcome!

8 Likes
2

A149 progress update — from the Italian pilot to a fully-private, multilingual rollout

Summary

The Phase 1 framework is proven, so the work since then has been about scale and staying true to the privacy goal end-to-end. The pilot has grown from one language to a multilingual rollout on a shared ~180-page curated set. For the translation job I used both ChatGPT 5.4 and a local model. This is a progress report and the plan ahead.

Language coverage

Locale Status
English, Italian :white_check_mark: Baseline (Phase 1)
French, Spanish, German, Portuguese, Arabic, Chinese :white_check_mark: Full curated set translated + UI dictionaries + wiring
Hindi, Russian, Japanese, Korean, Turkish, Ukrainian :white_check_mark: Full curated set translated + UI dictionaries + wiring
Swahili, Yoruba, Igbo, Twi, Ewe :counterclockwise_arrows_button: Underway now (specialized local model — see below)

That’s all 12 curated languages beyond the English/Italian baseline drafted end-to-end — the full ~180-page set, UI dictionaries, and frontend wiring — now consolidated and staged for review. The five African languages are actively being translated as I write this.

Same principles as the pilot throughout: repository-controlled content, English fallback, protected-terms CI, no runtime Google Translate.

What’s new

A private translation pipeline. Rather than one cloud API, each language is routed to the best-fit engine, chosen partly for privacy:

  • ChatGPT 5.4 for high-resource languages,
  • a local open model running on my own GPU for others,
  • a specialized open translation model (NLLB-200), also fully local, for low-resource languages.

Quality measured against the live baseline. Google Translate is what readers get today, so it’s my yardstick. Every language is scored with an automatic round-trip check against GT before shipping. Result so far: high/medium-resource languages are on par with or better than Google Translate; nothing ships that regresses below the GT baseline users already have.

Terminology at scale. The protected-terms glossary + CI now enforces the Zcash term list across every language, not just Italian — so “Arborist Calls” stays “Arborist Calls” everywhere.

A broader privacy audit. The original scope was Google Translate; I went further and audited the whole site for other third-party touchpoints (fonts, embeds, CDNs, map tiles, the AI assistant, analytics). Findings were cross-checked by an independent second model. Removing Google Translate is by far the biggest win; the rest are queued as small, self-contained follow-ups.

African languages — the honest part

General-purpose LLMs are strong on major languages but unreliable on low-resource ones, in testing they produced confident-looking output that mistranslated core meaning. So these five use a specialized open translation model built for exactly these languages (Meta’s NLLB-200), run entirely on my own GPU. This track is now in progress: the pipeline is markdown- and terminology-aware — code, links and protected terms are shielded during translation, and any line where a link or term can’t be safely preserved falls back to English rather than risk a broken page. Each language is held to a simple bar: ship only where quality is at least as good as the Google Translate already live (a pure privacy win, no regression), measured with the same automatic round-trip check as every other language. Native speakers can then refine pages over time — improvement is welcome, not a blocker.

Status against the plan

Item Status
Framework, glossary, contributor docs, Italian pilot :white_check_mark: Delivered (Phase 1)
Multi-language expansion (12 curated languages) :white_check_mark: Drafted + staged for review
Private, local translation pipeline :white_check_mark: Built
Automatic quality benchmark vs Google Translate :white_check_mark: Built
Low-resource (African) languages :counterclockwise_arrows_button: In progress (specialized local model)
Full-site privacy hardening (beyond GT) :next_track_button: Follow-ups
Community refinement :next_track_button: Ongoing

Next steps

  1. Settle the merge structure for the batch and open the 12 curated languages for community/editorial review; ship each as it clears the quality bar.
  2. Finish the African languages on the specialized-model path, run each through the no-regression benchmark, and ship the ones that pass — with community refinement to follow.
  3. Land the deferred privacy follow-ups as small PRs.

I am also considering implementing a system that will update translated pages semi-automatically when an English update is released.

However, it is important to remember that machine drafts still need people. Automatic scores tell me a translation didn’t regress; they don’t replace a native read. Static translation remains an ongoing community effort, not a one-time automation. Also, round-trip metrics are a screen, not a verdict. They’re biased toward the tool used to measure them, so “within a few points of Google Translate” should be read as “effectively on par,” and native corrections are always welcome.

Your opinion and comments welcome!

5 Likes
3

With the 18 curated languages now in place (and the on-the-fly Google Translate widget on its way out), the problem to solve was keeping those translations current. Curated pages are point-in-time snapshots — when an English page changes, every language’s copy silently goes stale, and once the runtime widget is gone there’s no fallback: a stale translation is simply what the reader sees until someone fixes it.

That’s now built and working end-to-end. A translation-sync system with two halves: a deterministic, secretless check that publishes a “staleness dashboard” (what’s out of date, missing, or orphaned), and a routine that re-translates just what changed (down to the individual paragraphs, for most languages), runs the protected-term and structure gates, and prepares one reviewable update per batch. Deleted English pages have their orphaned translations cleaned up so no one lands on permanently-stale content, and the menus stay localized automatically, I’ve tested it end-to-end: a new English page shows up in every language’s side menu with a translated label, a deleted page drops out, and featured nav/“coin” items get their labels translated too.

For contributors it means basically no change: you create, edit, and delete wiki pages in English exactly as today, and a translation maintainer runs the sync (it can move into CI later). The only new ask is that if you feature a brand-new item in the top nav or the explore (“coin”) menu, you add it in English and it gets translated into every language for you.

Two things would help most now: native-speaker reviewers for any of the 18 languages (the tooling gets structure and terminology right, but it can’t meaning-review 18 languages), and thoughts on who should run this long-term — keep it contributor-run for now, or fund a small org-side automation so the DAO owns the pipeline.

3 Likes