Re: Volunteering for the zh_CN message translation - Mailing list pgsql-translators

Hi all,

The zh_CN catalogs are done. One issue per branch on the patch tracker,
PostgreSQL 14 through 19:

master (PG19) https://redmine.postgresql.org/issues/8123
REL_18_STABLE https://redmine.postgresql.org/issues/8118
REL_17_STABLE https://redmine.postgresql.org/issues/8119
REL_16_STABLE https://redmine.postgresql.org/issues/8120
REL_15_STABLE https://redmine.postgresql.org/issues/8121
REL_14_STABLE https://redmine.postgresql.org/issues/8122

162 files, 67,487 messages: 100% translated, no fuzzy, no empty entries,
msgfmt --check --check-format clean. Only msgstr changed -- references,
extracted comments, msgctxt, flags, entry order and obsolete entries are
byte-for-byte from the templates, so msgmerge against a newer POT should
be a no-op for the entries in common. These supersede #8117.

Method, briefly: a glossary and style guide were fixed first, then every
message went through eight to ten rounds of translation and cross-review
between models, each round gated on msgfmt, placeholder, plural and
column-alignment checks. A full human review pass came last, message by
message against the English. So: machine-assisted, human-verified, which
is what I said in my first note here.

The baseline it was held to -- style guide, phrasebook, glossaries,
decision log, errata -- is published:

https://github.com/pgsty/pgnls/tree/main/ref

If the attachments are awkward, the same catalogs are in that repo, with
a tarball per branch on the release page:

https://github.com/pgsty/pgnls/releases/tag/20260917

Each unpacks to zh_CN/<branch>/<catalog>.po. The first commit is the
current upstream state, and one commit per catalog follows, so a single
component's diff reads on its own.

Messages are also browsable at https://pgsql.cc/nls -- English, existing
translation and the new one side by side.

I am not dropping this after one submission. I will keep zh_CN current
as the POT moves, post corrections on these issues, and help with
whatever else is useful on the zh_CN side.

Corrections and disagreements welcome. If a different shape is easier to
review -- fewer issues, one branch first, a git branch to pull from --
say so and I will redo it.

Thanks,
Ruohang Feng
rh@vonng.com
VONNG @ PGSTY


> 2026年9月13日 上午9:46，rh@vonng.com 写道：
>
> Hi all,
>
> Following up on my earlier note, I'm submitting all 28 zh_CN message
> catalogs for PostgreSQL 19 in one batch:
>
> https://redmine.postgresql.org/issues/8117
>
> The set covers 12,702 active messages and incorporates the upstream
> changes in the Babel 19-branch snapshot retrieved on September 13.
>
> All 28 files pass msgfmt --check --check-format, with no empty or
> fuzzy entries. Source-key comparisons and GNU gettext lookup tests
> also pass, including plural forms.
>
> The work includes some fable/astra assisted translation, as noted earlier.
> Human review and calibration is ongoing on https://pgsql.cc
>
> I'll keep checking accuracy, wording and terminology,
> track upstream changes, and post corrections promptly. Follow-up
> revisions will go on the same issue with a short change summary.
>
> Complete PO files included:
>
>  ecpg-zh_CN.po
>  ecpglib-zh_CN.po
>  initdb-zh_CN.po
>  libpq-zh_CN.po
>  pg_amcheck-zh_CN.po
>  pg_archivecleanup-zh_CN.po
>  pg_basebackup-zh_CN.po
>  pg_checksums-zh_CN.po
>  pg_combinebackup-zh_CN.po
>  pg_config-zh_CN.po
>  pg_controldata-zh_CN.po
>  pg_ctl-zh_CN.po
>  pg_dump-zh_CN.po
>  pg_resetwal-zh_CN.po
>  pg_rewind-zh_CN.po
>  pg_test_fsync-zh_CN.po
>  pg_test_timing-zh_CN.po
>  pg_upgrade-zh_CN.po
>  pg_verifybackup-zh_CN.po
>  pg_waldump-zh_CN.po
>  pg_walsummary-zh_CN.po
>  pgscripts-zh_CN.po
>  plperl-zh_CN.po
>  plpgsql-zh_CN.po
>  plpython-zh_CN.po
>  pltcl-zh_CN.po
>  postgres-zh_CN.po
>  psql-zh_CN.po
>
> Feedback on translation quality and terminology is welcome, especially
> from the existing zh_CN maintainers.
>
> Thanks,
> Ruohang Feng (Vonng)
> rh@vonng.com
>
>> 2026年9月11日 下午4:58，rh@vonng.com 写道：
>>
>> Hi all,
>>
>> I'd like to volunteer for the Simplified Chinese (zh_CN) message
>> catalogs, if the project is open to a new translator taking them on.
>>
>> Briefly: I'm Ruohang Feng (Vonng), a native Chinese speaker, more than
>> ten years with PostgreSQL. I maintain pgsql.cc, a full Chinese translation
>> of the PostgreSQL documentation for v10 through v20, held together by
>> a single glossary so the same English sentence reads the same way
>> across versions. I've translated several technical books into Chinese,
>> including Designing Data-Intensive Applications and PostgreSQL
>> Internals, and I maintain Pigsty, an OSS PostgreSQL distribution.
>>
>> I've been following the translation tooling discussion Peter started
>> around PGConf.dev 2026, and Thom's July note that several catalogs,
>> zh_CN among them, are at risk of being dropped from 19. On today's
>> 19-branch status table zh_CN is at 66% overall, with nine of
>> twenty-eight catalogs above the threshold; postgres is at 61%, psql at
>> 75%, libpq at 12%.
>>
>> Coverage isn't the whole problem. The current zh_CN catalogs appear to
>> have been translated against a much older baseline, and they carry a
>> fair number of outright errors, several of them reported on this list
>> this year, plus terminology that varies between files and sometimes
>> within a single file.
>>
>> I've set up a translation and proofreading workflow for the message at
>>
>> https://pgsql.cc/nls,
>>
>> and a first-pass base version of the 19 catalogs is already in place.
>>
>> To be explicit about what that is: it is LLM-translated by fable & astra,
>> generated against the same glossary that backs the pg cn doc site.
>> It is working material, and I would not submit it as it stands.
>>
>> Once I have a go-ahead, that base goes through a full human review --
>> every message checked by hand against the English original and the
>> current translation -- and only the reviewed, msgfmt-clean result is
>> sent to this list. That review is the bulk of the work, which is why
>> I'm asking before starting it rather than afterwards.
>>
>> Two ways I could go from here:
>>
>> 1. Full overhaul. I take the whole of zh_CN through that review, keep
>> what's good in the existing translations, and submit complete PO
>> files in time for 19. This is what I'd prefer: most of the
>> inconsistency is cross-file, and one pass against a fixed glossary
>> fixes it in a way incremental patches won't.
>>
>> 2. Minimal fixes. I fill in the untranslated messages and correct the
>> clear errors, and leave everything else as it stands.
>>
>> Either is fine by me -- I'd rather follow whatever the project prefers
>> to review. If this sounds workable, a few things I'd need to know:
>>
>> - Is anyone already working on zh_CN that I should coordinate with?
>> - Should corrections be back-patched to the supported branches
>> (18 and earlier), or is it better to keep everything on 19?
>> - What's the cutoff for getting updates into 19?
>>
>> If it's easier to judge from a sample, I can send one reviewed catalog first.
>>
>> Thanks,
>> Ruohang Feng (Vonng)
>> rh@vonng.com
>>
>>
>>
>