[HsuehYi]

Add the missing Traditional Chinese translations for the Dag version diff path tooltip. This is a follow-up to #75433, which introduced these tooltip strings. The tooltip appears when multiple changes share the same JSON-Pointer-style path, including when the diff is truncated.

Validation:

• breeze ui check-translation-completeness --language zh-TW: 100% coverage, 0 missing, 0 TODO, 0 unused
• prek run --from-ref upstream/main --stage pre-commit: passed

---

Was generative AI tooling used to co-author this PR?

• Yes — OpenCode (DeepSeek V4.1 Flash Free)

Generated-by: OpenCode (DeepSeek V4.1 Flash Free) following the guidelines

[jason810496]

Thanks.

[Lee-W]

Let's change it this way for simplicity.

[HsuehYi]

Applied both suggestions in 3ea2b5d.

[HsuehYi]

I noticed some pre-existing _one entries still use {{count, number}}:

"count_one": "{{count, number}} 個期限",
"missedCount_one": "{{count, number}} 個已逾期的期限",
"upcomingCount_one": "{{count, number}} 個即將到期的期限",
"mappedTaskInstances_one": "任務實例 [{{count, number}}]",
"summaryAtLeast_one": "至少 {{count, number}} 項變更",

I left them unchanged to keep this PR scoped to the missing translations.

I also noticed that Breeze lists only _other as the locale-specific plural suffix for zh-TW:

dev/breeze/src/airflow_breeze/commands/ui_commands.py:

PLURAL_SUFFIXES = {
    ...
    "zh-TW": ["_other"],
}

At Javascript runtime, i18next also resolves zh-TW to the other category only:

new Intl.PluralRules("zh-TW").resolvedOptions().pluralCategories
// ["other"]

However, the completeness check starts from the English key set, so the _one keys remain required for key parity even though i18next does not select them for zh-TW. That is also why deleting a _one key still makes the completeness check report it as missing.

Given that, do you think it's worth opening a separate PR to normalize the existing _one entries, or should we leave them as-is?

[Lee-W]

Given that, do you think it's worth opening a separate PR to normalize the existing _one entries, or should we leave them as-is?

make a separate one makes sense to me. thanks!

[github-actions]

Hi maintainer, this PR was merged without a milestone set.
We've automatically set the milestone to Airflow 3.4.1 based on: backport label targeting v3-4-test
If this milestone is not correct, please update it to the appropriate milestone.

This comment was generated by Milestone Tag Assistant.

[github-actions]

Backport successfully created: v3-4-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-4-test