fix(i18n): translate the zh-CN strings added since the last sync

[ApplesBear-X]

The Simplified Chinese locale is behind en-US. Everything shipped recently - billing, members, calendar feeds, the GitLab integration, the security page, the notifications inbox, the dashboard, the press kit, the landing pages and this week's sync-scope settings - arrived as English placeholders, so those screens currently fall back to English.

This PR translates them. It only changes values: no key is added, removed or reordered.

• 679 strings, using the wording the file already uses (工作区 / 项目 / 任务 / 看板 / 负责人 / 仓库 / 关联).
• GitLab mirrors the existing GitHub and Gitea blocks, so the three integrations read the same way.
• settings.customFields.optionsPlaceholder now points out that the ASCII comma is required (用英文逗号 (,) 分隔选项), because the editor splits options on , only.
• Brand names and technical identifiers (Webhook, URL, Issue, PR, SVG, OIDC ...), editor language names and example placeholders stay in English on purpose.

Checked with node scripts/i18n/check.mjs zh-CN -> OK, and every {{placeholder}} matches en-US.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Translate newly added Simplified Chinese UI strings

🐞 Bug fix 🕐 20-40 Minutes

AI Description

• Translate 624 English placeholders across the Simplified Chinese product UI and public pages.
• Preserve existing keys, ordering, interpolation placeholders, and Chinese plural forms.
• Keep product names and technical identifiers unchanged for consistency.

Diagram

graph TD
  ZH["zh-CN locale"] --> Loader["Locale loader"] --> I18n["i18next runtime"] --> UI["Chinese UI"]

Loading

High-Level Assessment

Translating the existing values in place is the appropriate approach: it fixes English text without changing locale keys, runtime behavior, or plural handling. Changing fallback logic or introducing a localization service would add scope without addressing this values-only gap more directly.

Files changed (1) +637 / -637

Bug fix (1) +637 / -637

zh-CN.jsonTranslate 624 newly added Simplified Chinese strings +637/-637

Translate 624 newly added Simplified Chinese strings

• Replaces English placeholder values across onboarding, settings, billing, user management, GitLab integration, calendar feeds, tasks, notifications, the dashboard, the press kit, and landing pages. Existing keys and ordering remain intact, as do interpolation placeholders and '_other' plural forms.

i18n/zh-CN.json

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Chinese commas create one dropdown option ✓ Resolved

Description

settings.customFields.optionsPlaceholder tells users to separate options with commas without
specifying that only the ASCII comma works. When a Chinese-speaking user enters options separated by
the Chinese comma ，, the editor's .split(",") treats the entire entry as one option in both its
preview and creation request.

Code

i18n/zh-CN.json[1538]

+			"optionsPlaceholder": "选项之间用逗号分隔",

Evidence

The translated hint is the placeholder of the dropdown-options input, while both paths that parse
that input split exclusively on the ASCII comma.

i18n/zh-CN.json[1538-1538]
apps/web/src/components/project/custom-field-editor.tsx[613-623]
apps/web/src/components/project/custom-field-editor.tsx[141-150]
apps/web/src/components/project/custom-field-editor.tsx[320-334]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Chinese dropdown-options hint does not distinguish `,` from the Chinese comma `，`, but the editor splits options only on `,`.
## Fix Focus Areas
- i18n/zh-CN.json[1538-1538]
- apps/web/src/components/project/custom-field-editor.tsx[141-150]
- apps/web/src/components/project/custom-field-editor.tsx[320-334]
## Recommended Fix
Make the Chinese hint explicitly show the accepted ASCII comma, for example `用英文逗号 (,) 分隔选项`. Alternatively, accept both comma characters in the editor's preview and creation parsing.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can turn on the rule miner and Qodo learns your standards from review history

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[ApplesBear-X]

Follow-up on this PR:

• Rebased onto the current main. The branch had drifted 36 commits behind, which is what produced the merge conflict. The translations are now re-applied on top of main's current file, so the diff stays values-only (one file, values only).
• Covered the strings added since the first revision. While rebasing I also translated the sync-scope block (settings.syncRules.* — the label-based sync filter, the paused-link review and the resume dialog) plus settings.advancedSettingsDescription: 55 more strings, so the locale now matches main's key set exactly.
• Reviewer finding fixed at the value level. settings.customFields.optionsPlaceholder now reads 用英文逗号 (,) 分隔选项, which matches the editor splitting on ,. Making the editor accept the Chinese comma as well would be a source change in custom-field-editor.tsx (handleCreate and dropdownOptions) — glad to open that separately if you'd like it.

All checks are green on the new head.

[ApplesBear-X]

I noticed the new Contribution eligibility check fails here. It wants a linked issue labelled ready-for-contribution, and there isn't one - the label doesn't exist in this repo yet, so nothing can pass it at the moment. This PR was opened just before that policy landed, and I see the same check failing on the other open external PRs.

Happy to open an issue for the zh-CN sync and link it here with Closes #N, or you can vouch for this account - whichever is less work for you. Nothing else changed: the translation is the same, and the rest of CI is green.