Proposal: Chinese (zh_CN) localization — fully implemented, happy to submit a PR

Hi @BaskovicP first of all, thanks for Incremento — it's by far the most polished incremental reading implementation I've used in Anki.

>I'm writing to ask whether you'd be open to a **complete Chinese (zh_CN) localization** of the add-on and its companion Chrome extension. I've already implemented and tested it locally, and I'd love to contribute it upstream rather than keep it as a private patch.

### What I built

>

- **Qt / Anki side:** standard `gettext` catalog (`locale/zh_CN/...`), matching Anki's own localization mechanism. A small `backend/i18n.py` module detects the interface language at startup (via `anki.lang`), so the UI follows Anki's language automatically — no user-facing setting needed.
- **Chrome extension side:** standard Chrome i18n API (`_locales/en` + `_locales/zh_CN/messages.json`).
- **Coverage:** ~1,975 strings across the add-on UI, backend messages, and the extension — effectively 100% translated. A few terms (PDF, EPUB, OCR, Markdown, provider URLs) are intentionally kept in English.
- **Build tooling:** `scripts/extract_po.py` and `scripts/compile_po.py` regenerate/compile the catalog, and the compiled `.mo` is included in the packaged add-on.

>

### Zero impact for English users

>When Anki's interface language isn't Chinese, every string falls back to the original English source text — the behavior is byte-for-byte identical to today, including for untranslated entries.

### Quality

>

- The existing pytest suite passes unchanged.
- Added regression tests for language detection, catalog compilation, and fallback behavior (including a guard against blank UI labels from untranslated entries).

>

### Maintenance offer

>I know the real cost of i18n is keeping translations in sync as strings change. **I'm happy to take on ongoing maintenance of the zh_CN catalog** — whenever you update wording, I can follow up with updated translations so nothing drifts.

### Questions for you

>

1. Would you be open to accepting this as a PR?
2. Any preference on structure? I can submit it as one PR, or split it: (a) i18n infrastructure + tests, then (b) string wrapping + zh_CN catalog, whichever is easier for you to review.
3. Any terminology preferences for specific concepts (e.g., "extract", "session", "topic")? My translations currently follow Anki's official zh_CN conventions.

>The diff touches ~56 files (~2.9k insertions / 2.2k deletions), mostly mechanical `_()` wrapping, so I understand if you'd like to review it in parts.
>
>I fully respect that the repo is under an all-rights-reserved license — I'm only interested in contributing upstream and won't distribute a modified version on my own. If you'd prefer a different arrangement, I'm happy to discuss.

Start by reviewing the proposed backend/i18n.py module, locale/zh_CN catalogs, scripts/extract_po.py, scripts/compile_po.py, and the added regression tests. Run the existing pytest suite and inspect the current add-on and extension localization structure before confirming the maintainer's preferred PR split. Done means the agreed localization changes, compiled catalog, fallback behavior, and tests are accepted without changing English behavior.

Written by the indexing model from the issue text.