Patch i18n enable

config.toml

@@ -54,17 +54,22 @@ anchor = "smart"
 [languages]
 [languages.en]
 title = "OSPO Glossary"
-description = "The OSPO Glossary Project is intended to be used as a reference for common terms used when talking about Open Source and Open Source Program Offices (OSPO)."
 languageName ="English"
 # Weight used for sorting.
 weight = 1
+[languages.en.params]
+description = "The OSPO Glossary Project is intended to be used as a reference for common terms used when talking about Open Source and Open Source Program Offices (OSPO)."
+
+
+[languages.zh]
+title = "OSPO 术语表"
+languageName ="中文（Chinese）"
+contentDir = "content/zh"
+weight = 2
+[languages.zh.params]
+description = "OSPO 术语表项目旨在为谈论开源和开源项目办公室 (OSPO) 时使用的常用术语提供参考。"
 
-# [languages.hi]
-# title = "क्लाउड नेटिव शब्दावली"
-# description = "CNCF क्लाउड नेटिव शब्दावली परियोजना का उद्देश्य क्लाउड नेटिव एप्लिकेशन के बारे में बात करते समय प्रयोग किए जाने वाले सामान्य शब्दों के संदर्भ के रूप में उपयोग किया जाना है।"
-# languageName ="हिन्दी (Hindi)"
-# contentDir = "content/hi"
-# weight = 2
+# Add other languages here 
 
 [markup]
   [markup.goldmark]

content/zh/_index.md

@@ -0,0 +1,19 @@
+---
+title: "OSPO 术语表"
+status: Completed
+---
+
+# 欢迎使用 OSPO 术语表
+
+欢迎使用开源项目办公室（OSPOs） 术语表。 众所周知，开源世界广阔而复杂，有许多不同的术语和概念，可能难以理解。 我们编写本术语表的目的并不是为这些术语提供一个明确或通用的定义，而是明确在组织的 OSPO 框架（战略、治理、合规和社区）下的具体含义。
+
+<p><img class="mt-3 mb-3" src="/images/homepage/colorful-shapes.jpg" alt="Colorful shapes with people"></p>
+
+当您探索本术语表中的术语和概念时，我们鼓励您使用所提供的说明和链接。如果您有任何建议，希望我们加入更多的术语或资源，请新建一个问题反馈，或者提交一个包含新术语的 PR ！
+
+## 许可
+
+所有代码贡献使用 Apache 2.0 许可。 
+文档使用 CC BY 4.0 许可分发。
+
+<p><img class="mt-3" src="/images/homepage/writing.jpg" alt="Woman writing on a pad of paper"></p>

content/zh/contribute/_index.md

@@ -0,0 +1,74 @@
+---
+title: 如何参与贡献
+toc_hide: true
+status: Completed
+menu:
+  main:
+    weight: 10
+---
+
+## Welcome 
+
+Welcome to the OSPO Glossary contributing guide, and thank you for your interest. 
+There are a number of ways you can contribute to this project, which we'll cover in detail here: 
+
+1) [Best Practices](#best-practices)
+2) [Style guide](#style-guide)
+3) [Work on an existing issue](#work-on-an-existing-issue)
+4) [Propose new terms](#propose-new-terms)
+
+
+## OSPO glossary overview 
+
+The goal of this glossary is to simplify the Open Source Program Office space and thus make it more accessible to people. 
+
+The OSPO Glossary content is stored in [this GitHub repo](https://github.com/todogorup/glossary) 
+where you'll find a list of [issues](https://github.com/todogroup/glossary/issues) and pull requests ([PRs](https://github.com/todogroup/glossary/pulls)).
+## Who can contribute?
+
+How you can participate in this project depends on your level of Open Source Program Office / Open Source within organizations expertise. 
+Simplifying complex concepts requires a deep knowledge of the topic. 
+Therefore, to contribute new terms, you must be proficient in them. 
+
+That know-how is required because explaining complex concepts in simple words is _really_ hard. And while the digestible, user-friendly outcome may seem easy, achieving the desired simplicity results from hard work and collaboration between cloud native experts. 
+
+If you have never directly engaging with Open Source Program Offices or open source initiatives wihtin organizations yet, but still want to contribute, we recommend teaming up with someone who is. 
+Once the expert is confident that the term accurately describes the concept, you are ready for your first Glossary contribution.
+
+The localization effort is where beginners proficient in another language can make valuable contributions to the Glossary. 
+With solid existing definitions in English, less experienced contributors can localize terms to a target language. You can join an existing localization team or create a new one. Read this guide's [Help Localize the glossary](#help-localize-the-glossary) section to learn how to get started. 
+
+## Before you start
+
+Before beginning your Glossary contributor journey, be sure to complete the following steps:
+
+1. Create a [GitHub account](https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account), if you don't have one already. 
+2. Be familiar with the [DCO signature](https://developercertificate.org/) when making contributions.
+
+## Best practices {#best-practices}
+
+To facilitate the reviewing process, please use [semantic line breaks](https://sembr.org/) (e.g., one line per sentence).
+We recommend checking out this [markdown cheat sheet](https://www.markdownguide.org/cheat-sheet/) 
+to correctly format Markdown text in GitHub (e.g., hyperlink, bold, italic).
+And when naming .md files, please use lowercase letters and hyphens instead of spaces to separate words and avoid parenthesis.
+
+## Style guide {#style-guide}
+
+Read our [Style Guide](/style-guide/) to understand our guidelines for formatting and writing documents and make the contribution process more efficient. 
+
+## Work on an existing issue {#work-on-an-existing-issue}
+
+Go to the [Glossary GitHub repo issues](https://github.com/todogroup/glossary/issues) to find a list of available issues. 
+You can use labels (e.g., English language, help needed, good first issue) to filter out issues.
+
+**Note**: you can start working on an issue after the maintainers assigned it to you. 
+You can only claim one term at a time. 
+Workig on multiple terms is sequential, you must complete a term before claiming the next one.
+
+## Propose new terms {#propose-new-terms}
+
+You can propose a new term for others to work on or create a new definition yourself. 
+Either way, you'll start by [creating an issue](#creating-an-issue). 
+
+
+**We updated this guide based on templates from [The Good Docs Project](https://thegooddocsproject.dev/).**

content/zh/contributor-ladder/_index.md

@@ -0,0 +1,109 @@
+---
+title: 贡献者阶梯
+toc_hide: true
+status: Completed
+menu:
+  main:
+    weight: 10
+---
+
+Hi there! 👋 Thanks for your interest in contributing to the TODO Glossary project. 
+Whether you contribute new terms, help localize the Glossary into your native language, 
+or want to help others get started, there are many ways to become an active member of this community. 
+This doc outlines the different contributor roles within the project and the responsibilities and privileges that come with them.
+
+## 1. Contributors
+
+The Glossary is for everyone. Anyone can become a Glossary contributor simply by contributing to the project. 
+All contributors are expected to follow the [TODO Code of Conduct](https://todogroup.org/code-of-conduct/).
+
+There are a variety of ways you can contribute to the project, including:
+
+- **Content contributors**: everyone who improves existing terms or contributes new ones, 
+- **Localization contributors**: those who help translate the glossary into another language,
+- **Helpers**: anyone who helps others on GitHub, Slack, or wherever community members need support,
+- **Ambassadors**: anyone who helps spread the word, educates the community on how to contribute and why they should do so. 
+
+Contributors can have multiple roles or focus on one area only. 
+**All these contributions are equally important** and help foster a thriving community. 
+Please refer to the [How to Contribute](/contribute/) and [Style Guide](/style-guide/) for content and localization contributions.
+
+## 2. Approvers
+
+Approvers provide feedback on PRs and approve them. Any active contributor can become an approver (see [Becoming an approver](#becoming-an-approver)). 
+The Glossary differentiates between two approvers: (1) approvers for the English Glossary and (2) approvers for localization teams.
+
+Glossary approvers are expected to:
+
+- Review PRs for technical accuracy, 
+- Assign contributors issues and label them appropriately,
+- Provide contributors with feedback and guide them when needed,
+- Proofread and edit submissions.
+
+If an approver is no longer interested in or cannot perform the above duties, they should let the maintainers know and step down.
+
+### English Glossary Approvers
+
+There are three types of approvers:
+
+1) Approvers with a strong technical background,
+2) Approvers with solid writing skills,
+3) Approvers who are proficient in both. 
+
+**Technical Approvers**: Individuals with a strong technical background can be approvers without having solid English writing skills. 
+However, if they approve a PR on technical merit, they must ensure it is reviewed by an (editor) approver.
+
+**Editors**: Editors proofread terms and ensure they are explained in simple language according to the Style Guide. 
+If a term is heavily edited, the editor must request a technical approver to review it again to ensure the meaning wasn't altered.
+
+### Localization Approvers
+
+The Glossary also has localization approvers. These are approvers for one of the localization teams (teams translating the glossary). 
+Localization approvers are only permitted to perform approver duties for their own team and have the ability to merge PRs to their dedicated development branch. 
+Any localization approver can also become an approver for the English Glossary if they meet the requirements. 
+
+### Becoming an Approver
+
+Approver candidates should have a proven track record of submitting high-quality PRs and helping others get their PRs in a mergeable state. 
+
+To become an approver, start by expressing interest to existing maintainers. 
+Existing maintainers will then ask you to demonstrate the qualifications above by contributing PRs, doing reviews, and doing other such tasks under their guidance. 
+After some time of working together, maintainers will decide whether to grant you approver status. 
+This decision will be based on your demonstrated level of proficiency and responsiveness.
+
+## 3. Maintainers
+
+Maintainers are approvers who can also merge PRs. Anyone can become a Glossary maintainer (see [Becoming a maintainer](#becoming-a-maintainer)). 
+There are certain expectations for maintainers, including:
+
+- Be an active and responsive approver (see above),
+- Help maintain the repository, including site configuration, permission, issue-template, GitHub workflow, among others,
+- Monitor the Glossary Slack channels and help out whenever possible,
+- Regularly attend the [Glossary Working Group meetings](https://www.cncf.io/calendar/) (if timezone permits)
+
+If a maintainer is no longer interested in or cannot perform the duties listed above, they should move themselves to emeritus status.
+
+### Becoming a Maintainer
+
+Maintainers should have a proven track record of being successful approvers and submitting high-quality PRs. 
+If their timezone permits, they should also regularly attend the Glossary Working Group meetings.
+
+To become a maintainer, start by expressing interest to existing maintainers. 
+Existing maintainers will then ask you to demonstrate the qualifications above by contributing PRs, doing reviews, and doing other such tasks under their guidance. 
+After some time of working together, maintainers will decide whether to grant maintainer status. 
+This decision will be based on demonstrated level of proficiency and responsiveness.
+
+## Involuntary Removal
+
+Involuntary removal of a contributor happens when responsibilities and requirements aren't met. 
+This may include repeated patterns of inactivity, extended periods of inactivity, and/or a violation of the code of conduct. 
+This process is important because it protects the community and its deliverables while also opening up opportunities for new contributors to step in.
+
+## Stepping Down/Emeritus Process
+
+If and when contributors' commitment levels change, contributors can consider stepping down (moving down the contributor ladder) vs. 
+moving to emeritus status (completely stepping away from the project).
+
+## Stepping Back Into a Role
+
+If and when someone is available to step back into a previous contributor role, project leadership can arrange and consider this.

content/zh/ospo-definition.md

@@ -0,0 +1,49 @@
+---
+title: 开源项目办公室
+status: Completed
+tags: ["fundamental", "", ""]
+---
+
+## 背景
+开源[与现代科技的发展密不可分](https://openforumeurope.org/open-source-impact-study/)，已成为各行各业与技术领域绝大多数代码库的基础，比如 AI 人工智能与机器学习或网络安全。
+
+## OSPO 是什么？
+
+开源项目办公室（OSPO）是组织开源运作体系的能力中心，负责制定和实施战略与政策来指导开源工作。
+具体包括针对代码使用、分发、选择、审计、贡献和其他关键领域设置策略；为参与开源的人员（组织内部和外部）提供教育和培训；
+通过鼓励对现有开源组件的可持续使用，并在适当的情况下，为这些项目回馈贡献增强功能，支持组织在软件开发方面的效率；
+在需要时指导团队开源他们的软件；确保工程有效性；确保法律合规；建立并促进社区参与。 
+[InnerSource内源](https://innersourcecommons.org/) 是开源的近亲，通常与 OSPO 合作或隶属于 OSPO 。
+
+## 为什么需要 OSPO ？
+
+对外，OSPO 作为组织和开源社区的一个重要桥梁，有助于确保组织对开源软件的良好管理，在受益于采用开源软件的同时，最大限度地降低风险。
+对内，OSPO 作为整个组织的开源相关活动的中枢，能够从不同视角汇集所需的专业知识技能，比如法律的、经济的、技术的或社区的视角。
+
+## OSPO 背后的角色
+
+OSPO 由身兼数职的人（开源专家）组成：
+
+* 开源赋能者：OSPO 可以帮助组织应对有效参与开源社区所需的文化、流程和工具变更。这可能涉及教育团队/单位、建立新的流程和工作流程，以及采用新的工具和技术。
+
+* 开源顾问：OSPO 可以就最新的开源趋势、许可趋势以及如何参与开源项目、基金会和社区。这可以帮助组织跟上快速变化的开源环境，并确保他们做出明智的决策。
+
+* 开源布道者：OSPO 可以促进不同组织单位对开源和最佳实践的使用和/或贡献。这可以帮助组织意识到开源的好处，并吸引人们为开源项目做出贡献或开启新的项目。
+
+* 开源生态保护者：OSPO 可以通过解决安全、维护和项目健康等问题，帮助组织长期支持和维护开源项目。这可能涉及制定代码审查、安全漏洞管理以及通过资金和/或捐款进行持续维护和支持的政策和程序。通过这样做，OSPO 可以帮助确保开源项目保持健康，并继续造福于更广泛的社区。
+
+* 开源守卫者：OSPO 可以帮助执行开源政策并加强开源治理。这可以帮助组织确保合规性并减轻开源安全风险。
+
+## OSPO 通常是怎么运行的？
+
+OSPO 背后的人员实现这一目标的方法是，创建和维护一个涵盖以下方面的框架：战略、治理、合规和社区参与。OSPO 战略聚焦于使组织的开源目标与其总体组织目标保持一致，并与组织的所有部门/小组合作。
+
+> 声明：OSPO 可以在不同的部门、地区和组织规模中成立，包括私人和公共组织，如学术界、非政府组织、基金会、政府和公共行政部门，以及小型、中型和大型公司。同样重要的是，组织内的类似 OSPO 的结构有许多不同的名称。命名及具体组织形式将很大程度上取决于每个组织自身的实践。以“专项”或“办公室”的形式来组织，只是实现服务于 OSPO 目的的组织方式之一。
+
+## 💻 源码 - 原始仓库
+
+*  OSPO 定义的原始仓库采用 `CC-BY-SA 4.0` 许可，托管在 [todogroup/ospodefinition.org](https://github.com/todogroup/ospodefinition.org) 。本文是[定义第二版 (v.2.0)](https://github.com/todogroup/ospodefinition.org/releases/tag/v1.2.0) 发布的镜像内容。 
+
+* 如果你希望参与贡献来改进 OSPO 定义，帮助我们定义 v2.1 版本，请[创建一个 issue](https://github.com/todogroup/ospodefinition.org/issues) 或新建一个 [PR](https://github.com/todogroup/ospodefinition.org/pulls) 。
+
+* [了解更多 ospodefinition.org](https://github.com/todogroup/ospodefinition.org)