Translate into Japanese

config.toml

@@ -52,19 +52,22 @@ anchor = "smart"
 # Language configuration
 
 [languages]
-[languages.en.params]
-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)."
+[languages.en]
 languageName ="English"
+title = "OSPO Glossary"
 # 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.hi]
-# title = "क्लाउड नेटिव शब्दावली"
-# description = "CNCF क्लाउड नेटिव शब्दावली परियोजना का उद्देश्य क्लाउड नेटिव एप्लिकेशन के बारे में बात करते समय प्रयोग किए जाने वाले सामान्य शब्दों के संदर्भ के रूप में उपयोग किया जाना है।"
-# languageName ="हिन्दी (Hindi)"
-# contentDir = "content/hi"
-# weight = 2
+[languages.ja]
+contentDir = "content/ja"
+languageName ="日本語 (Japanese)"
+title = "OSPO 用語集"
+# Weight used for sorting.
+weight = 2
+[languages.ja.params]
+description = "OSPO 用語集プロジェクトは、オープンソースおよびオープンソースプログラムオフィス (OSPO) について話すときに使用される一般的な用語のリファレンスとして使用することを目的としています。"
 
 [markup]
   [markup.goldmark]

content/ja/_index.md

@@ -0,0 +1,19 @@
+---
+title: "OSPO 用語集"
+status: Completed
+---
+
+# OSPO 用語集に<br/>ようこそ！
+
+オープンソースプログラムオフィス (OSPO) の用語集へようこそ。ご存知のとおり、オープンソースの世界は広大かつ複雑で、さまざまな用語や概念があり、理解するのが難しい場合があります。この用語集の目的は、これらの用語の確定的または一般的な定義を提供することではなく、組織向けの 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/ja/contribute/_index.md

@@ -0,0 +1,74 @@
+---
+title: How To Contribute
+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/todogroup/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 within 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. 
+Working 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/ja/contributor-ladder/_index.md

@@ -0,0 +1,109 @@
+---
+title: Contributor Ladder
+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/ja/free-content.md

@@ -0,0 +1,9 @@
+---
+title: フリーコンテンツ
+status: Completed
+tags: ["fundamental", "", ""]
+---
+
+リブレコンテンツ、リブレ情報、またはフリー情報とも呼ばれるものは、自由文化作品の定義を満たす機能的な作品、芸術作品、またはその他の創造的なコンテンツを指します。
+
+*  [Free Content Wikipedia Definition](https://en.wikipedia.org/wiki/Free_content)

content/ja/free-software.md

@@ -0,0 +1,11 @@
+---
+title: フリーソフトウェア
+status: Completed
+tags: ["fundamental", "", ""]
+---
+
+フリーソフトウェアとは、価格ではなく自由を指します。それはユーザーに重要な 4 つの自由 (使用、学習、共有、改善) を保証します。これらの自由のうち少なくとも 1 つが欠如している場合、アプリケーションは独自のものであり、非フリーソフトウェアであることを意味します。 [詳細](https://fsfe.org/freesoftware/freesoftware.en.html)
+
+## 💻 ソース
+
+* [Free Software Foundation](https://fsfe.org/freesoftware/freesoftware.en.html)

content/ja/free_cultural-works.md

@@ -0,0 +1,16 @@
+---
+title: 自由文化作品
+status: Completed
+tags: ["fundamental", "", ""]
+---
+
+自由文化作品の定義は、互換性のあるフリーコンテンツライセンスを評価し推奨します。すなわち、人々の以下の自由に対して重大な法的制限がないライセンスを指します：
+
+* コンテンツを使用し、その使用から利益を得ること
+* コンテンツを研究し、学んだことを応用すること
+* コンテンツのコピーを作成し配布すること
+* コンテンツを変更・改善し、それらの派生作品を配布すること
+
+## 💻 ソース
+
+* [自由文化作品の定義](https://ja.wikipedia.org/wiki/%E8%87%AA%E7%94%B1%E6%96%87%E5%8C%96%E4%BD%9C%E5%93%81%E3%81%AE%E5%AE%9A%E7%BE%A9)

content/ja/innersource-principles.md

@@ -0,0 +1,12 @@
+---
+title: InnerSource Principles
+status: Completed
+tags: ["fundamental", "culture", ""]
+---
+
+InnerSource Principles are a set of guidelines that provide a framework for organizations to tap into the collective knowledge and expertise of their employees, and to create a culture of collaboration and innovation. 
+
+## 💻 Source
+
+* [InnerSource Commons](https://innersourcecommons.org/learn/).
+

content/ja/innersource.md

@@ -0,0 +1,12 @@
+---
+title: InnerSource
+status: Completed
+tags: ["fundamental", "culture", ""]
+---
+
+The use of open source software development best practices and the establishment of an open source-like culture within organizations for the development of its non-open-source and/or proprietary software. [InnerSource](https://innersourcecommons.org/) is a close sibling of open source and often collaborates with or is part of the OSPO. [Learn more](https://innersourcecommons.org/)
+
+# 💻 Source
+
+* [InnerSource Commons Foundation](https://innersourcecommons.org/)
+

content/ja/knowledge-sharing.md

@@ -0,0 +1,7 @@
+---
+title: Knowledge Sharing
+status: Completed
+tags: ["fundamental", "", ""]
+---
+
+Knowledge sharing refers to the exchange of information and expertise between individuals, teams, and organizations. Knowledge sharing is often a key component of open source and innerSource development practices. [Learn more about knowledge sharing](https://en.wikipedia.org/wiki/Knowledge_sharing).

content/ja/open-data-and-content.md

@@ -0,0 +1,12 @@
+---
+title: Open Data and Content
+status: Completed
+tags: ["fundamental", "", ""]
+---
+
+The [Open Definition](http://opendefinition.org/od/2.1/en/) sets out principles that define *openness* in relation to data and content. Open means anyone can freely access, use, modify, and share for any purpose (subject, at most, to requirements that preserve provenance and openness). 
+Open data and content can be freely used, modified, and shared by anyone for any purpose. 
+
+## 💻 Source
+
+* [Open Knowledge Initiative](https://okfn.org/)

content/ja/open-innovation.md

@@ -0,0 +1,14 @@
+---
+title: Open Innovation
+status: Completed
+tags: ["fundamental", "", ""]
+---
+
+Open innovation assumes that useful knowledge is widespread, so that one needs to innovate by developing effective mechanisms to access this useful knowledge, and to share useful knowledge with others. 
+Open Innovation is based on the fundamental idea that useful knowledge is now widespread throughout society. No one organization has a monopoly on great ideas, and every organization, 
+no matter how effective internally, needs to engage deeply and extensively with external knowledge networks and communities. An organization that practices open innovation will utilize external 
+ideas and technologies as a common practice in their own business and will allow unused internal ideas and technologies to go to the outside for others to use in their respective businesses. 
+
+## 💻 Source
+
+* [European Commission Open Innovation Definition](https://digital-strategy.ec.europa.eu/en/news/what-open-innovation)

content/ja/open-source-culture.md

@@ -0,0 +1,11 @@
+---
+title: Open Source Culture
+status: Completed
+tags: ["fundamental", "", ""]
+---
+
+Open source culture refers to a set of values and practices that promote collaboration, transparency, and community-driven development. It is often associated with the open source software movement, but can be applied to other areas as well, such as open science, open hardware, and open education. This Glossary references the four opens philosophy, created by the Open Infra (former OpenStack) community. [Learn more](https://openinfra.dev/four-opens/).
+
+## 💻 Source
+
+* [Open Infrastructure Foundation](https://openinfra.dev/four-opens/)