[ja] Clarify the localization process for kubernetes-specific terminologies (especially for boundary cases)

[youmeim]

This is a Feature Request

What would you like to be added

Modify the localization guide for kubernetes terminology .

Why is this needed

Our translation guideline is well-working and also enough simple and well-covered for our translation workflow itself and the localization guide for kubernetes terminology successfully works for separating alphabetical results (or カタカナ語) and other words translated into Japanese.

However there are uncovered cases for several term categories, especially for newer functionalities or non-API resource terms, such as:

• Validating Admission Controller (or Validating Admission Webhook)
• Guaranteed QoS
• Pod Security Standard

These terms (or other future terms on k8s) are not perfectly covered by our translation guideline, because these terms are not composed of purely k8s-specific concepts and also they are not resources.

Additionally, these terms are originated and derived from domain specific knowledge in neighbor technologies of k8s (such as network engineering, service management, access control or auditing, etc.), some contributors may assume that there is a Japanese counterpart for a word composing the term. Such decisions by a contributor (and reviewers) seem to be performed per-contribution, and the ambiguity of the localization workflow for several boundary terms possibly results different translations for the same term by different contributors (on different pages spread on the website). Audiences of the localized website can be confused by the variety of a translated k8s term.

In present (and in past), boundary terms categorized above were translated and reviewed per-PR, translated AS-IS, and seems not to be referred from the new contribution for other pages in every time.

We, contributors, have various backgrounds, different knowledge and different levels of comprehension and experience on k8s and its related technologies. So we should clarify or redefine the translation workflow even for these boundary cases, to empower localization contributors and to reduce the workload of reviewers.

---

Comments

Proposal

Here, I have two proposal to improve the localization guide for kubernetes terminology, to reduce the ambiguity of localization process on k8s-specific terms.

Proposal 1 Add a flow chart for the eye-catch of the section

Provide a flow chart to support contributors and reviewers for boundary cases, to detect whether a term should be translated into Japanese or not.
For example:

This kind of flow chart can be used as the initial check or the final check for a contribution, and it will improve the performance of the contributor (possibly a newcomer or a reviewer) to reduce the time consumption to choose or find certain solution for boundary cases of the translation of k8s terminology.

Proposal 2 Add notes for new contributors (and also for reviewers and maintainers) to describe that:

• The list of API resources, the glossary page and the localization guide should be checked to reduce boundary cases for your translation.
• Any boundary cases are processed within the table その他の表記.
• If you make a consensus for the translation of the boundary case with reviewers, you (contributor) should add a translation result to the table その他の表記.

Finally, any boundary cases can be caught with the table その他の表記 and the history of translations for boundary cases will be tracked on the table.
(This proposal requires the change of the current localization workflow to check the table その他の表記 when a translator wonders whether the term should be translated into Japanese or not.)

Attention: The update of the table その他の表記 should only be made for boundary cases, not for common cases of the translation. (So the future workload for the table maintenance will be small enough for us). It will not be an inclusive list of k8s terminologies such as zh-cn team's one.

Note: 日本語のローカリゼーションと日本語記事の改善に特化した提案内容であるため、ここでは日本語でのやり取りを希望します。

Robot

/area localization
/language ja

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.