Skip to content

Commit

Permalink
Merge pull request #874 from Jacob953/dev-zh
Browse files Browse the repository at this point in the history
[zh] Localize contributor-ladder
  • Loading branch information
Rocksnake authored May 11, 2022
2 parents 295bad5 + bbc78ed commit 5892124
Show file tree
Hide file tree
Showing 17 changed files with 123 additions and 31 deletions.
4 changes: 2 additions & 2 deletions content/zh-cn/cloud_native_apps.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ category: 概念
## Problem it addresses

传统上,本地环境以相当定制的方式提供计算资源。
每个数据中心都有与特定环境 [紧密耦合](/zh-cn/tightly_coupled_architectures/) 应用程序的服务,通常严重依赖于基础设施的手动配置,例如 [虚拟机](/zh-cn/virtual_machine/) 和服务。
每个数据中心都有与特定环境 [紧密耦合](/tightly_coupled_architectures/) 应用程序的服务,通常严重依赖于基础设施的手动配置,例如 [虚拟机](/zh-cn/virtual_machine/) 和服务。
这反过来又将开发人员及其应用程序限制在该特定数据中心。
不是为云设计的应用程序无法利用云环境的弹性和扩展能力。
例如,需要手动干预才能正确启动的应用程序无法自动扩展,也无法在发生故障时自动重启。
Expand All @@ -23,5 +23,5 @@ category: 概念

虽然云原生应用程序没有“一刀切”的路径,但它们确实有一些共性。
云原生应用程序具有弹性、可管理性,并由配套的云服务套件提供帮助。
各种云服务实现了高度的 [可观察性](/zh-cn/observability/),使用户能够在问题升级之前检测和解决问题。
各种云服务实现了高度的 [可观察性](/observability/),使用户能够在问题升级之前检测和解决问题。
结合强大的自动化,它们使工程师能够以最少的工作频繁且可预测地进行高影响力的更改。
2 changes: 1 addition & 1 deletion content/zh-cn/cloud_native_security.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ category: 概念
云原生安全是一种将安全性构建到 [云原生应用程序](/zh-cn/cloud_native_apps/) 中的方法。
它确保安全是从开发到生产的整个应用程序生命周期的一部分。
云原生安全旨在确保与传统安全模型相同的标准,同时适应云原生环境的特殊性,即快速的代码更改和高度短暂的基础设施。
云原生安全与称为 [测试左移](/zh-cn/devsecops/) 的实践高度相关。
云原生安全与称为 [测试左移](/devsecops/) 的实践高度相关。

## 强调的问题

Expand Down
4 changes: 2 additions & 2 deletions content/zh-cn/containerization.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,9 +12,9 @@ category: 技术

## 解决的问题

在容器盛行之前,企业依靠虚拟机 (VMs) 在一台 [裸机](/zh-cn/bare_metal_machine/) 上协调多个应用程序。
在容器盛行之前,企业依靠虚拟机 (VMs) 在一台 [裸机](/bare_metal_machine/) 上协调多个应用程序。
虚拟机比容器大得多,需要一个管理程序来运行。由于这些较大的虚拟机模板的存储、备份和传输,创建虚拟机模板也很慢。
此外,虚拟机可能会出现配置漂移,这违反了 [不变性](/zh-cn/immutable_infrastructure/) 的原则。
此外,虚拟机可能会出现配置漂移,这违反了 [不变性](/immutable_infrastructure/) 的原则。

## 如何帮助

Expand Down
6 changes: 3 additions & 3 deletions content/zh-cn/containers_as_a_service.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,11 +6,11 @@ category: 技术

## 是什么

容器即服务(CaaS)是一种云服务,有助于使用基于 [容器](/zh-cn/container/)[抽象](/zh-cn/abstraction/) 管理和部署应用程序。
容器即服务(CaaS)是一种云服务,有助于使用基于 [容器](/zh-cn/container/)[抽象](/abstraction/) 管理和部署应用程序。
这项服务可以部署在企业内部或云中。

CaaS 供应商提供了一个框架或协调平台,使容器部署和管理的关键 IT 功能自动化。
它帮助开发者建立安全和 [可扩展](/zh-cn/scalibility/) 的容器化应用。
它帮助开发者建立安全和 [可扩展](/zh-cn/scalability/) 的容器化应用。
因为用户只购买他们需要的资源(调度能力、负载平衡等),他们可以节省资金并提高效率。
容器创造了一致的环境,以快速开发和交付可以在任何地方运行的 [云原生应用](/zh-cn/cloud_native_apps/)

Expand All @@ -21,6 +21,6 @@ CaaS 供应商提供了一个框架或协调平台,使容器部署和管理的
## 如何帮助

当把容器化应用部署到 CaaS 平台时,用户可以通过日志聚合和监控工具获得对系统性能的可见性。
CaaS 还包括 [自动扩展](/zh-cn/auto_scaling/) 和协调管理的内置功能。
CaaS 还包括 [自动扩展](/auto_scaling/) 和协调管理的内置功能。
它使团队能够建立高可见性和高可用性的 [分布式系统](/zh-cn/distributed_systems/)
此外,通过允许快速部署,CaaS 提高了团队的开发速度。在容器确保一致的部署目标的同时,CaaS 通过减少管理部署所需的 [DevOps](/zh-cn/devops/) 资源,降低了工程运营成本。
9 changes: 2 additions & 7 deletions content/zh-cn/contribute/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,6 @@ toc_hide: true
menu:
main:
weight: 10
pre: <i class='fas fa-pen-square'></i>
---

Cloud Native Glossary 内容存储在 [this GitHub repo](https://github.com/cncf/glossary) 中, 您可以在其中找到关于 glossary 的 [issues](https://github.com/cncf/glossary/issues), [PRs](https://github.com/cncf/glossary/pulls), 和 [discussions](https://github.com/cncf/glossary/discussions).
Expand Down Expand Up @@ -103,9 +102,5 @@ Cloud Native Glossary 内容存储在 [this GitHub repo](https://github.com/cncf

这将打开术语的 GitHub 页面. 进行更改并提交 PR. 有关详细说明, 请参阅上面的“提交新术语”(跳转到有关降价的部分).

## Help translate the glossary
为了帮助将词汇表翻译成您的母语, 请加入 CNCF Slack 上的#glossary-localizations 频道并告诉我们. 您可以加入现有团队或创建新团队(要查看需要什么, 请查看 [Localization Guide](https://github.com/cncf/glossary/blob/main/LOCALIZATION.md)). 也请参加我们每月的词汇表工作组会议. 你可以在 [CNCF calendar](https://www.cncf.io/calendar/) 中找到会议详情. 我们期待在那里与您见面!




## 云原生词汇表翻译帮助
为了帮助将云原生词汇表翻译成您的母语, 请加入 CNCF Slack 上的 #glossary-localizations 频道并告诉我们. 您可以加入现有团队或创建新团队(要查看需要什么, 请查看 [Localization Guide](https://github.com/cncf/glossary/blob/main/LOCALIZATION.md)). 也请参加我们每月的词汇表工作组会议. 你可以在 [CNCF calendar](https://www.cncf.io/calendar/) 中找到会议详情. 我们期待在那里与您见面!
98 changes: 98 additions & 0 deletions content/zh-cn/contributor-ladder/_index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,98 @@
---
title: 贡献者阶梯
toc_hide: true
menu:
main:
weight: 10
---

大家好! 👋 感谢你对 CNCF 云原生词汇项目的贡献。无论你是贡献新的术语,帮助将词汇表本地化为你的母语,还是想帮助其他人开始工作,都有很多方法可以成为这个社区的积极成员。本文档概述了项目中不同的贡献者角色以及随之而来的责任和特权。

## 1. 贡献者

云原生词汇表是为所有人准备的。任何人都可以通过对项目的贡献而成为词汇表的贡献者。所有贡献者都应遵守 [CNCF 行为准则](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)

你可以通过多种方式为该项目做出贡献,包括:

- **内容贡献者**:每个改进现有条款或贡献新条款的人。
- **本地化贡献者**:帮助将词汇表翻译成其他语言的人。
- **帮助者**:任何在 GitHub、Slack 或社区成员需要支持的地方帮助他人的人。
- **大使**:帮助传播信息的人,教育社区成员如何做出贡献以及为什么要这样做。

贡献者可以有多种角色,也可以只专注于一个领域。**所有这些贡献都是同样重要的**,这有助于促进社区的繁荣。关于内容和本地化的贡献,请参考 [如何贡献](/zh-cn/contribute/)[风格指南](/zh-cn/style-guide/)

## 2. 审批者

审批者对 PR 提供反馈并批准它们。任何活跃的贡献者都可以成为审批者(见 "成为审批者")。词汇表区分了两种审批者:(1) 英语词汇表的审批者和(2) 本地化团队的审批者。

词汇审批者应做到:

- 审查 PR 的技术准确性。
- 为贡献者分配问题并为其贴上适当的标签。
- 向贡献者提供反馈,并在需要时为他们提供指导。
- 校对和编辑提交的内容。

如果审批者不再有兴趣或不能履行上述职责,他们应该让维护者知道并退出。

### 英语词汇表审批者

有三种类型的审批者:

1) 具有强大技术背景的审批者。
2) 具有扎实的写作技巧的审批者。
3) 两者都精通的审批者。

**技术审批者**:具有强大技术背景的人可以成为审批者,而不需要具备坚实的英语写作技能。然而,如果他们根据技术价值批准一项公关,他们必须确保由(编辑)批准者进行审查。

**编辑**:编辑对术语进行校对,并确保根据《风格指南》用简单的语言对其进行解释。如果一个术语被大量编辑,编辑必须要求技术审批者再次审查,以确保其含义没有被改变。

### 本地化审批者

词汇表也有本地化审批者。他们是本地化团队(翻译云原生词汇表的团队)的审批者。本地化审批者只允许为他们自己的团队履行审批者职责,并有能力将 PR 合并到他们专用的开发分支。如果符合要求,任何本地化审批者也可以成为英语词汇表的审批者。

### 成为审批者

审批员候选人应该有提交高质量 PR 的记录,并帮助他人将他们的PR合并到可合并的状态。如果他们的时区允许,他们也应该定期参加 [云原生词汇工作组会议](https://www.cncf.io/calendar/)

要成为审批者,首先要向现有的维护者表达兴趣。现有的维护者会要求你在他们的指导下,通过贡献PR、做审查和其他类似的任务来证明上述资格。经过一段时间的合作,维护者们将决定是否授予你审批者的身份。这个决定将基于你的熟练程度和反应能力。

## 3. 维护者

维护者是审批者,也可以合并PR。任何人都可以成为词汇表维护者(见 "成为维护者")。对维护者有一些期望,包括:

- 成为一个积极响应的审批者(见上文)。
- 帮助维护存储库,包括网站配置、权限、问题模板、GitHub 工作流程等。
- 监控云原生词汇表的 Slack 频道,并尽可能地提供帮助。
- 定期参加 [云原生词汇工作组会议](https://www.cncf.io/calendar/) (如果时区允许)

如果维护者不再有兴趣或不能履行上述职责,他们应该将自己转为荣誉会员。

### 成为维护者

维护者应该有成功批准和提交高质量 PR 的良好记录。如果他们的时区允许,他们也应该定期参加词汇工作组的会议。

要成为一名维护者,首先要向现有的维护者表达兴趣。现有的维护者会要求你在他们的指导下,通过提交PR、做审核和其他类似的任务来证明上述资格。经过一段时间的合作,现有维护者们将决定是否授予维护者资格。这个决定将基于你的熟练程度和反应能力。

## 4. 社区管理者

社区管理者帮助培养一个受欢迎和有吸引力的社区。任何社区成员都可以成为社区管理者。他们要做的是:

- 欢迎新成员,确保他们获得所需的信息。
- 帮助回答来自社区的问题或找到可以帮助的人。
- 调节 Slack上 的对话。

### 成为社区管理者

任何人都可以成为词汇表社区管理者。社区管理者必须对贡献和本地化过程有扎实的了解,并且喜欢与人交流和帮助他人。要成为社区管理者,首先要向现有的维护者表达兴趣。在入职/试用期过后,维护者会根据表现来决定是否授予社区管理者资格。

## 非自愿删除

当责任和要求没有得到满足时,就会发生非自愿删除贡献者的情况。这可能包括反复的不活动模式,长时间的不活动,和/或违反行为准则的行为。这个过程很重要,因为它保护了社区和它的成果,同时也为新的贡献者提供了机会。

## 退役/退休程序

如果贡献者的承诺水平发生了变化,贡献者可以考虑退出(在贡献者的阶梯上往下走)和转为名誉会员(完全离开项目)。

## 重新进入一个角色

如果有人可以重新担任以前的贡献者角色,项目领导层可以安排并考虑这样做。
2 changes: 1 addition & 1 deletion content/zh-cn/data_center.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,4 +14,4 @@ category: 技术

## 如何帮助

对于云计算,数据中心至关重要。 由于可以根据 [需求规模](/zh-cn/scalability/) 配置资源和基础设施,因此企业可以在数据中心租用云计算资源,而无需多虑预测的资源过多过少带来的问题。 由于数据中心遍布世界各地,这允许在地理上接近需求的地方提供资源,而无需实际运送和设置设备。
对于云计算,数据中心至关重要。 由于可以根据 [可扩展性](/zh-cn/scalability/) 配置资源和基础设施,因此企业可以在数据中心租用云计算资源,而无需多虑预测的资源过多过少带来的问题。 由于数据中心遍布世界各地,这允许在地理上接近需求的地方提供资源,而无需实际运送和设置设备。
2 changes: 1 addition & 1 deletion content/zh-cn/devops.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ category: 概念
开发运维是一种方法论,其中团队拥有从应用程序开发到生产操作的整个过程,因此 DevOps,它不仅仅是实施一套技术,还需要文化和流程的彻底转变。 DevOps 需要一组工程师来处理小组件(相对于整个功能),从而减少交接——一个常见的错误来源。

## 强调的问题
传统上,在具有 [紧密耦合](/zh-cn/tightly_coupled_architectures/) [单体应用程序](/zh-cn/monolithic_apps/) 的复杂组织中,工作通常分散在多个组之间。 这导致了多次交接和较长的交货时间。 每次组件或更新准备就绪时,都会将其放入队列中以供下一个团队使用。 因为个人只参与了项目的一小部分,这种方法导致缺乏所有权。 他们的目标是将工作交给下一个小组,而不是为客户提供正确的功能——明显的优先级错位。
传统上,在具有 [紧密耦合](/tightly_coupled_architectures/) [单体应用程序](/zh-cn/monolithic_apps/) 的复杂组织中,工作通常分散在多个组之间。 这导致了多次交接和较长的交货时间。 每次组件或更新准备就绪时,都会将其放入队列中以供下一个团队使用。 因为个人只参与了项目的一小部分,这种方法导致缺乏所有权。 他们的目标是将工作交给下一个小组,而不是为客户提供正确的功能——明显的优先级错位。

到代码最终投入生产时,它经过了这么多开发人员,排了这么多队列,如果代码不起作用,很难追查问题的根源。 DevOps 颠覆了这种方法。

Expand Down
2 changes: 1 addition & 1 deletion content/zh-cn/distributed_apps.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,5 +19,5 @@ category: 概念
## 如何帮助

当把一个应用程序拆分成不同的部分并在许多地方运行时,整个系统可以容忍更多的故障。
它还允许应用程序利用单个应用程序实例所不具备的扩展功能,即 [水平扩展](/zh-cn/horizontal_scaling/)的能力。
它还允许应用程序利用单个应用程序实例所不具备的扩展功能,即 [水平扩展](/horizontal_scaling/)的能力。
然而,这也是有代价的:增加了复杂性和操作开销--你现在正在运行很多应用组件,而不是一个应用。
4 changes: 2 additions & 2 deletions content/zh-cn/distributed_systems.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ category: 概念
## 是什么

分布式系统是通过网络连接的自主计算元素的集合,在用户看来是一个单一的连贯系统。
一般被称为 [节点](/zh-cn/nodes/),这些组件可以是硬件设备(如电脑、手机)或软件进程。
一般被称为 [节点](/nodes/),这些组件可以是硬件设备(如电脑、手机)或软件进程。
节点被编程以实现一个共同的目标,为了协作,它们通过网络交换信息。

## 解决的问题
Expand All @@ -21,6 +21,6 @@ category: 概念

## 如何帮助

分布式系统允许 [水平扩展](/zh-cn/horizontal_scaling/)(例如,在需要时向系统添加更多节点)。这可以是自动化的,允许系统处理工作负荷或资源消耗的突然增加。
分布式系统允许 [水平扩展](/horizontal_scaling/)(例如,在需要时向系统添加更多节点)。这可以是自动化的,允许系统处理工作负荷或资源消耗的突然增加。

非分布式系统面临着故障的风险,因为如果一台机器发生故障,整个系统都会故障。分布式系统可以设计成这样,即使一些机器发生故障,整个系统仍然可以继续工作,产生相同的结果。
4 changes: 2 additions & 2 deletions content/zh-cn/kubernetes.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,11 +9,11 @@ category: 技术
Kubernetes,通常缩写为K8s,是一种流行的现代基础设施自动化的开源工具。
它就像一个数据中心的操作系统,管理在 [分布式系统](/zh-cn/distributed_systems/) 上运行的应用程序(就像你笔记本上的操作系统,管理你的应用程序)。

Kubernetes在 [集群](/zh-cn/cluster/)[节点](/zh-cn/nodes/) 上调度 [容器](/zh-cn/container/)
Kubernetes在 [集群](/zh-cn/cluster/)[节点](/nodes/) 上调度 [容器](/zh-cn/container/)
它捆绑了几个基础设施结构,有时被称为 "基元",如应用程序的实例、负载平衡器、持久性存储等,以一种可以被组成应用程序的方式。

Kubernetes 实现了自动化和可扩展性,使用户能够以可重复的方式声明性地部署应用程序。
Kubernetes 生态系统中的软件产品和项目利用这种自动化和可扩展性来扩展 Kubernetes [API](/zh-cn/application_programming_interface/)
Kubernetes 生态系统中的软件产品和项目利用这种自动化和可扩展性来扩展 Kubernetes [API](/application_programming_interface/)
这使他们能够利用 Kubernetes 的自动化,并使他们的工具更容易被有经验的 Kubernetes 从业者所接受。

## 解决的问题
Expand Down
2 changes: 1 addition & 1 deletion content/zh-cn/microservices.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ category: 概念
微服务是对单体应用所带来的挑战的一种回应。一般来说,一个应用程序的不同部分需要分别进行 [扩展](/zh-cn/scalability/)
例如,一个在线商店将有更多的产品视图而不是结账。这意味着你需要更多的产品视图功能的运行,而不是结账。
在一个单一的应用程序中,这些逻辑位不能被单独部署。如果你不能单独扩展产品功能,你将不得不复制整个应用程序和所有其他你不需要的组件--这是一种低效的资源利用。
单机式应用程序也使开发人员容易屈服于设计陷阱。因为所有的代码都在一个地方,所以更容易使这些代码 [高耦合](/zh-cn/tightly_coupled_architectures/),更难执行关注点分离的原则。
单机式应用程序也使开发人员容易屈服于设计陷阱。因为所有的代码都在一个地方,所以更容易使这些代码 [高耦合](/tightly_coupled_architectures/),更难执行关注点分离的原则。
单机通常要求开发人员了解整个代码库,然后才能有成效。

## 如何帮助
Expand Down
Loading

0 comments on commit 5892124

Please sign in to comment.