chore(i18n,docs): processed translations (#44964)

pull/45002/head
camperbot 2022-02-04 03:55:42 +05:30 committed by GitHub
parent 1d76032484
commit a2a1c62953
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
27 changed files with 1213 additions and 1213 deletions

View File

@ -44,7 +44,7 @@ Some examples of good PRs titles would be:
1. Once the edits have been committed, you will be prompted to create a pull request on your fork's GitHub Page.
![Image - Compare pull request prompt on GitHub](https://contribute.freecodecamp.org/images/github/compare-pull-request-prompt.png)
![Image - Compare & pull request prompt on GitHub](https://contribute.freecodecamp.org/images/github/compare-pull-request-prompt.png)
2. By default, all pull requests should be against the freeCodeCamp main repo, `main` branch.

View File

@ -44,7 +44,7 @@ Some examples of good PRs titles would be:
1. Once the edits have been committed, you will be prompted to create a pull request on your fork's GitHub Page.
![Image - Compare pull request prompt on GitHub](https://contribute.freecodecamp.org/images/github/compare-pull-request-prompt.png)
![Image - Compare & pull request prompt on GitHub](https://contribute.freecodecamp.org/images/github/compare-pull-request-prompt.png)
2. By default, all pull requests should be against the freeCodeCamp main repo, `main` branch.

View File

@ -44,7 +44,7 @@ Algunos ejemplos de buenos títulos para PRs serían:
1. Una vez que las ediciones hayan sido confirmadas, se le pedirá que cree un pull request en la página de GitHub de su fork.
![Imagen - Comparar solicitud de pull en GitHub](https://contribute.freecodecamp.org/images/github/compare-pull-request-prompt.png)
![Image - Compare & pull request prompt on GitHub](https://contribute.freecodecamp.org/images/github/compare-pull-request-prompt.png)
2. De manera predeterminada, todas las pull requests deben estar en contra de la rama freeCodeCamp main repo, `main`.

View File

@ -44,7 +44,7 @@ Alcuni esempi di buoni titoli PR sarebbero:
1. Una volta che le modifiche sono state effettuate, ti verrà chiesto di creare una pull request sulla pagina GitHub della tua fork.
![Immagine - Confrontare il prompt delle pull request su GitHub](https://contribute.freecodecamp.org/images/github/compare-pull-request-prompt.png)
![Image - Compare & pull request prompt on GitHub](https://contribute.freecodecamp.org/images/github/compare-pull-request-prompt.png)
2. Di default, tutte le pull request dovrebbero essere sul repository principale di freeCodeCamp, nel ramo `main`.

View File

@ -1,6 +1,6 @@
### GitHub とオープンソースは初めてです。 どこから始めればいいですか?
[「オープンソースガイドに貢献する方法」](https://github.com/freeCodeCamp/how-to-contribute-to-open-source) をご覧ください。 これは、初心者にも優しいプロジェクトのための包括的な参照です。 オープンソースへの貢献に関するヒントを多く含んでいます。
[「オープンソースに貢献する方法ガイド」](https://github.com/freeCodeCamp/how-to-contribute-to-open-source) をご覧ください。 これは、初心者にも優しいプロジェクトのための包括的な参照です。 オープンソースへの貢献に関するヒントを多く含んでいます。
### コードベースに貢献するために知っておくべきことは何ですか?
@ -26,13 +26,13 @@ YouTube チャンネル用の教育ビデオを作成するために、[YouTube
バグを発見した場合は、最初に [「ヘルプ: バグを発見しました」](https://forum.freecodecamp.org/t/how-to-report-a-bug/19543) の記事を読んで、その指示に従ってください。
新しいバグだという確信がある場合は、GitHub に関する問題を作成してください。 バグを再現できるように、できるだけ多くの情報を含めるようにしてください。 これをサポートするために、事前に定義された問題用テンプレートがあります。
新しいバグだという確信がある場合は、GitHub Issue を作成してください。 バグを再現できるように、できるだけ多くの情報を含めるようにしてください。 これをサポートするために、事前に定義された Issue 用テンプレートがあります。
これらの GitHub 問題は、コードベース関連の問題や議論のためのものであり、コードを学習するための助けを得るためのものではありません。 疑わしい場合は GitHub に関する問題を作成する前に、[フォーラム](https://forum.freecodecamp.org) で支援を求めます。
これらの GitHub Issue は、コードベース関連の問題や議論のためのものであり、コードを学習するための助けを得るためのものではありません。 疑わしい場合は GitHub Issue を作成する前に、[フォーラム](https://forum.freecodecamp.org) で支援を求めます。
### セキュリティ問題はどのように報告すればいいですか?
セキュリティ問題のために GitHub に関する問題を作成しないでください。 その代わりに、`security@freecodecamp.org` へメールを送信してください。私たちが直ちに調査します。
セキュリティ問題のために GitHub Issue を作成しないでください。 その代わりに、`security@freecodecamp.org` へメールを送信してください。私たちが直ちに調査します。
### 私は学生です。 単位取得を目的として、機能に関して貢献することはできますか?
@ -40,33 +40,33 @@ YouTube チャンネル用の教育ビデオを作成するために、[YouTube
これを念頭におき、事前にご自身で計画を立てたうえで、コードの貢献に取り組むようお願いいたします。
### 問題にタグ付けされた様々なラベルはどのような意味ですか?
### GitHub Issue にタグ付けされた様々なラベルはどのような意味ですか?
コードメンテナーは、優先度、重大度、およびその他の要因に基づいて、問題とプルリクエストを [トリアージ](https://en.wikipedia.org/wiki/Software_bug#Bug_management) します。 [ラベルの意味の用語集](https://github.com/freecodecamp/freecodecamp/labels) をご覧ください。
コードメンテナーは、優先度、重大度、およびその他の要因に基づいて、Issue とプルリクエストを [トリアージ](https://en.wikipedia.org/wiki/Software_bug#Bug_management) します。 [ラベルの意味の用語集](https://github.com/freecodecamp/freecodecamp/labels) をご覧ください。
### 問題に貢献するには、何から始めたらいいですか?
### Issue の作業に貢献するには、何から始めたらいいですか?
まず、貢献可能な問題の簡単な概要が記載されている [**`help wanted`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) または [**`first timers only`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22first+timers+only%22) を確認します
貢献可能な作業にどのようなものがあるか把握するため、まずは [**`help wanted`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) または [**`first timers only`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22first+timers+only%22) のラベルが付いた Issue を確認してください
> [!TIP] **`help wanted`** の問題は誰でも作業が可能であり、作業前に許可を求める必要はありません。 ただし、**`first timers only`** のラベルに関する問題 は、以前に freeCodeCamp コードベースに貢献したことがない人のために設計された特別な問題です。
> [!TIP] **`help wanted`** の Issue は誰でも作業が可能であり、作業前に許可を求める必要はありません。 ただし、**`first timers only`** ラベルが付けられた Issue は、初めて freeCodeCamp コードベースに貢献する人用の特別な Issue です。
### タイプミスを見つけました。 プルリクエストを行う前に問題を報告すべきですか?
### タイプミスを見つけました。 プルリクエストを行う前に Issue を作成すべきですか?
タイプミスや文言変更の場合、問題を作成せずに、プルリクエストをすぐに開くことができます。 些細な変更であっても、プルリクエストに関する説明を詳細に記載してください。皆様の貢献を理解しレビューする際に役立ちます。
タイプミスや文言変更の場合、Issue を作成せずに、直接プルリクエストをオープンして構いません。 些細な変更であっても、プルリクエストの説明には詳しい情報を記載してください。皆様の貢献を理解しレビューする際に役立ちます。
コードベースやカリキュラムの大きな側面について議論したい場合は、問題を作成してください。
コードベースやカリキュラムの大きな側面について議論したい場合は、Issue を作成してください。
### 自分自身に問題を割り当てるにはどうすればいいですか?
### Issue を割り当て (アサイン) してもらうにはどうすればいいですか?
通常、長期的なコントリビューター以外に問題を割り当てません。 その代わりに、以下の方針に従い、すべての人対して公平であるようにしています。
通常、長期的なコントリビューター以外には Issue を割り当てません。 その代わりに、以下の方針に従い、すべての人対して公平であるようにしています。
1. 問題に対処する最初のプルリクエストをマージする可能性が最も高いです。
2. 複数のコントリビューターが同じ課題に対してプルリクエストを同時に開く場合、 最善の対処をするプルリクエストを優先します。 考慮事項:
1. Issue に対処する最初のプルリクエストをマージする可能性が最も高いです。
2. 複数のコントリビューターが同じ Issue に対してプルリクエストを同時にオープンした場合、 最善の対処をするプルリクエストを優先します。 考慮事項:
- テストを含めましたか?
- ユースケースを全部含めましたか?
- すべてのテストに合格し、すべてがローカルで動作することを確認しましたか?
3. 最後に、推奨ガイドラインに従ったプルリクエストを優先します。
- プルリクエストのチェックリストをフォローしましたか?
- プルリクエストのチェックリストに従って確認しましたか?
- プルリクエストに意味のあるタイトルを付けましたか?
### freeCodeCamp のモデレーターになりたいです。 何から始めればいいですか?
@ -77,9 +77,9 @@ YouTube チャンネル用の教育ビデオを作成するために、[YouTube
いくつかのプラットフォームで推奨されるパスを以下に示します。
- **ディスコード/チャット** のモデレーターになるには、チャットに積極的に参加し、発生する可能性のある潜在的な衝突への対処方法を学ぶとともに実践しながら、他の人と積極的に関わってください。
- **Discordチャット** のモデレーターになるには、チャットに積極的に参加し、発生する可能性のある潜在的な衝突への対処方法を学ぶとともに実践しながら、他の人と積極的に関わってください。
- **フォーラム** のモデレーターになるには、チャットモデレーター同様、積極的に参加します。学びながら他の人を支援し、質問を受けた際にはフィードバックを返して、他のフォーラム投稿者と関わってください。 詳細については、[サブフォーラムリーダーハンドブック](https://forum.freecodecamp.org/t/the-subforum-leader-handbook/326326) をご覧ください。
- **GitHub** モデレーターになるには、提起された GitHub に問題を処理して、それらが有効であるかどうかを確認し、(理想的には) 他の人 (または自分自身)が取り上げる問題に対するソリューションを提案します。
- **GitHub** モデレーターになるには、提起された GitHub Issue の処理を手伝います。それらが有効であるかどうかを確認し、(理想的には) Issue に対するソリューションを提案して、他の人 (または自分自身) が対応できる状態にします。
つまり、他の人に敬意を払ってください。 人々は世界中から集まっています。 これを念頭に置いて、励ましの言葉または応援する言葉を使用し、異文化間のコミュニケーションを意識してください。

View File

@ -1,66 +1,66 @@
# DevOps Handbook
# DevOps ハンドブック
This guide will help you understand our infrastructure stack and how we maintain our platforms. While this guide does not have exhaustive details for all operations, it could be used as a reference for your understanding of the systems.
このガイドは、インフラストラクチャスタックとプラットフォームをどのように維持するかを理解するのに役立ちます。 このガイドで、すべての操作について詳しく説明しているわけではありませんが、システムを理解する上での参考になります。
Let us know, if you have feedback or queries, and we will be happy to clarify.
ご意見やご質問があれば、どうぞご連絡ください。喜んでご説明いたします。
# Flight Manual - Code deployments
# フライトマニュアル - コードデプロイ
This repository is continuously built, tested and deployed to **separate sets of infrastructure (Servers, Databases, CDNs, etc.)**.
このリポジトリは、継続的に構築され、テストされ、**インフラストラクチャの個別のセット (サーバー、データベース、CDNなど)** にデプロイされます。
This involves three steps to be followed in sequence:
これには3つのステップが含まれます。
1. New changes (both fixes and features) are merged into our primary development branch (`main`) via pull requests.
2. These changes are run through a series of automated tests.
3. Once the tests pass we release the changes (or update them if needed) to deployments on our infrastructure.
1. 新規変更 (修正および機能変更の両方を含む) は、プルリクエストによりプライマリ開発ブランチ (`main`) にマージされます。
2. これらの変更は、一連の自動テストで実行されます。
3. テストに合格すると、インフラストラクチャ上でのデプロイメントに対して変更をリリースします(または必要に応じて更新します)。
#### Building the codebase - Mapping Git Branches to Deployments.
#### コードベースのビルド - Git ブランチのデプロイメントへのマッピング
Typically, [`main`](https://github.com/freeCodeCamp/freeCodeCamp/tree/main) (the default development branch) is merged into the [`prod-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/prod-staging) branch once a day and is released into an isolated infrastructure.
通常、[`main`](https://github.com/freeCodeCamp/freeCodeCamp/tree/main) (デフォルトの開発ブランチ) は、[`prod-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/prod-staging) ブランチに 1 日 1 回マージされ、分離されたインフラストラクチャにリリースされます。
This is an intermediate release for our developers and volunteer contributors. It is also known as our "staging" or "beta" release.
これは開発者とボランティアのコントリビューター用の中間リリースです。 「ステージング」または「ベータ」リリースとも呼ばれます。
It is identical to our live production environment at `freeCodeCamp.org`, other than it using a separate set of databases, servers, web-proxies, etc. This isolation lets us test ongoing development and features in a "production" like scenario, without affecting regular users of freeCodeCamp.org's main platforms.
それは `freeCodeCamp.org` のライブプロダクション環境と同じで、データベース、サーバー、Web プロキシなどの別々のセットを使用しています。 この分離により、freeCodeCamp.org の main プラットフォームの正規ユーザーに影響を与えることなく、「本番」のようなシナリオで継続的な開発と機能をテストすることができます。
Once the developer team [`@freeCodeCamp/dev-team`](https://github.com/orgs/freeCodeCamp/teams/dev-team/members) is happy with the changes on the staging platform, these changes are moved every few days to the [`prod-current`](https://github.com/freeCodeCamp/freeCodeCamp/tree/prod-current) branch.
開発者チーム [`@freeCodeCamp/dev-team`](https://github.com/orgs/freeCodeCamp/teams/dev-team/members) が、ステージングプラットフォームでの変更に満足したら、これらの変更は数日ごとに [`prod-current`](https://github.com/freeCodeCamp/freeCodeCamp/tree/prod-current) ブランチに移されます。
This is the final release that moves changes to our production platforms on freeCodeCamp.org.
これが freeCodeCamp.org で本番プラットフォームに変更を加えた最終リリースです。
#### Testing changes - Integration and User Acceptance Testing.
#### 変更のテスト - 統合テストとユーザー承認テスト
We employ various levels of integration and acceptance testing to check on the quality of the code. All our tests are done through software like [GitHub Actions CI](https://github.com/freeCodeCamp/freeCodeCamp/actions) and [Azure Pipelines](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp).
私たちは、コードの品質を確認するために、様々なレベルの統合と受け入れテストを採用しています。 すべてのテストは、[GitHub Actions CI](https://github.com/freeCodeCamp/freeCodeCamp/actions) や [Azure Pipelines](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp) のようなソフトウェアにより実行されます。
We have unit tests for testing our challenge solutions, Server APIs and Client User interfaces. These help us test the integration between different components.
私たちは、チャレンジソリューション、Server API、クライアントユーザーインターフェースをテストするための単体テストを行っています。 これらは、異なるコンポーネント間の統合をテストするのに役立ちます。
> [!NOTE] We are also in the process of writing end user tests which will help in replicating real world scenarios like updating an email or making a call to the API or third-party services.
> [!NOTE] また、メールの更新や API やサードパーティサービスへの呼び出しなど、現実世界のシナリオを再現するのに役立つエンドユーザーテストを作成中です。
Together these tests help in preventing issues from repeating themselves and ensure we do not introduce a bug while working on another bug or a feature.
これらのテストを組み合わせることで、問題が繰り返されるのを防ぎ、別のバグや機能の作業中にバグが発生しないようにします。
#### Deploying Changes - Pushing changes to servers.
#### 変更のデプロイ - 変更をサーバーにプッシュする
We have configured continuous delivery software to push changes to our development and production servers.
開発サーバーと本番サーバーに変更をプッシュする継続的デリバリーソフトウェアを設定しています。
Once the changes are pushed to the protected release branches, a build pipeline is automatically triggered for the branch. The build pipelines are responsible for building artifacts and keeping them in a cold storage for later use.
保護されたリリースブランチに変更がプッシュされると、そのブランチに対してビルドパイプラインが自動的にトリガーされます。 ビルドパイプラインは、アーティファクトを構築し、後で使用するためにコールドストレージに保管する責任があります。
The build pipeline goes on to trigger a corresponding release pipeline if it completes a successful run. The release pipelines are responsible for collecting the build artifacts, moving them to the servers and going live.
実行が正常に完了すると、ビルドパイプラインは対応するリリースパイプラインをトリガーします。 リリースパイプラインは、ビルドアーティファクトを収集し、それらをサーバーに移動し、稼働させる責任があります。
Status of builds and releases are [available here](#build-test-and-deployment-status).
ビルドとリリースのステータスは [こちら](#build-test-and-deployment-status) からご確認いただけます。
## Trigger a build, test and deploy
## ビルドをトリガー・テスト・デプロイする
Currently, only members on the developer team can push to the production branches. The changes to the `production-*` branches can land only via fast-forward merge to the [`upstream`](https://github.com/freeCodeCamp/freeCodeCamp).
現時点では、開発チームのメンバーのみが本番ブランチにプッシュできます。 `production-*` ブランチへの変更は、[`upstream`](https://github.com/freeCodeCamp/freeCodeCamp) への早送りマージによってのみ可能です。
> [!NOTE] In the upcoming days we would improve this flow to be done via pull-requests, for better access management and transparency.
> [!NOTE] 今後、アクセス管理と透明性を向上させるために、プルリクエストを介してこのフローを改善します。
### Pushing changes to Staging Applications.
### ステージングアプリケーションに変更をプッシュする
1. Configure your remotes correctly.
1. リモートを正しく構成します。
```sh
git remote -v
```
**Results:**
**結果:**
```
origin git@github.com:raisedadead/freeCodeCamp.git (fetch)
@ -69,7 +69,7 @@ Currently, only members on the developer team can push to the production branche
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (push)
```
2. Make sure your `main` branch is pristine and in sync with the upstream.
2. `main` ブランチが初期状態であり、アップストリームと同期していることを確認してください。
```sh
git checkout main
@ -77,24 +77,24 @@ Currently, only members on the developer team can push to the production branche
git reset --hard upstream/main
```
3. Check that the GitHub CI is passing on the `main` branch for upstream.
3. GitHub CI がアップストリームの `main` ブランチを渡していることを確認してください。
The [continuous integration](https://github.com/freeCodeCamp/freeCodeCamp/actions) tests should be green and PASSING for the `main` branch. Click the green check mark next to the commit hash when viewing the `main` branch code.
[継続的インテグレーション](https://github.com/freeCodeCamp/freeCodeCamp/actions) テストは、`main` ブランチに関して、緑色であり PASSING でなければなりません。 `main` ブランチコードを表示する際、コミットハッシュの横にある緑色のチェックマークをクリックします。
<details> <summary> Checking status on GitHub Actions (screenshot) </summary>
<details> <summary> GitHub Actionsでステータスを確認する (スクリーンショット) </summary>
<br>
![Check build status on GitHub Actions](https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/main/docs/images/devops/github-actions.png)
</details>
If this is failing you should stop and investigate the errors.
これに失敗した場合は、停止してエラーの確認をします。
4. Confirm that you are able to build the repository locally.
4. リポジトリをローカルにビルドできることを確認します。
```
npm run clean-and-develop
```
5. Move changes from `main` to `prod-staging` via a fast-forward merge
5. 早送りマージにより、変更を `main` から `prod-staging` に移行します。
```
git checkout prod-staging
@ -102,7 +102,7 @@ Currently, only members on the developer team can push to the production branche
git push upstream
```
> [!NOTE] You will not be able to force push and if you have re-written the history in anyway these commands will error out.
> [!NOTE] 強制的にプッシュすることはできません。履歴を書き直した場合、これらのコマンドはエラーになります。
>
> If they do, you may have done something incorrectly and you should just start over.

View File

@ -1,77 +1,77 @@
# How to add Cypress tests
# Cypress テストを追加する方法
When making changes to JavaScript, CSS, or HTML which could change the functionality or layout of a page, it's important to add corresponding [Cypress](https://docs.cypress.io) integration tests.
ページの機能やレイアウトを変更する可能性がある JavaScript、CSS、または HTML を変更する際には、対応する [Cypress](https://docs.cypress.io) 統合テストを追加することが重要です。
To learn how to write Cypress tests, or 'specs', please see Cypress' official [documentation](https://docs.cypress.io/guides/getting-started/writing-your-first-test.html).
Cypress テストもしくは「specs」の書き方については、Cypress の公式 [ドキュメント ](https://docs.cypress.io/guides/getting-started/writing-your-first-test.html) をご覧ください。
## Where to add a test
## テストを追加する場所
- Cypress tests are in the `./cypress` directory.
- Cypress テストは `./cypress` ディレクトリにあります。
- Cypress tests for a curriculum module are in the corresponding curriculum directory, i.e. `cypress/integration/learn/responsive-web-design/basic-css/index.js`.
- カリキュラムモジュールの Cypress テストは、対応するカリキュラムディレクトリ、すなわち `cypress/integration/learn/responsive-web-design/basic-css/index.js` にあります。
## How to run tests
## テストを実行する方法
> [!NOTE] If using GitPod, please see [Cypress-GitPod Setup](/how-to-add-cypress-tests#cypress-gitpod-setup)
> [!NOTE] GitPod を使用している場合は、[Cypress と GitPod の設定](/how-to-add-cypress-tests#cypress-gitpod-setup) を参照してください。
### 1. Ensure that MongoDB and client applications are running
### 1. MongoDB とクライアントアプリケーションが動作していることを確認する
- [Start MongoDB and seed the database](/how-to-setup-freecodecamp-locally#step-3-start-mongodb-and-seed-the-database)
- [MongoDB を起動し、データベースをシードします。](/how-to-setup-freecodecamp-locally#step-3-start-mongodb-and-seed-the-database)
- [Start the freeCodeCamp client application and API server](/how-to-setup-freecodecamp-locally#step-4-start-the-freecodecamp-client-application-and-api-server)
- [freeCodeCamp クライアントアプリケーションと API サーバーを起動します。](/how-to-setup-freecodecamp-locally#step-4-start-the-freecodecamp-client-application-and-api-server)
### 2. Run the cypress tests
### 2. Cypress テストを実行する
To run tests against production builds, replace `dev` with `prd` below.
`dev``prd` に置き換えて本番ビルドに対するテストを実行します。
- To run all tests in the `./cypress` directory:
- `./cypress` ディレクトリで、すべてのテストを実行します。
```console
npm run cypress:dev:run
```
- To run a single test:
- 単一のテストを実行します。
```console
npm run cypress:dev:run -- --spec=cypress/pathToYourSpec/youSpecFileName.js
```
- To create a development build, start the development server, and run all existing cypress end-to-end tests:
- 開発ビルドを作成するには、開発サーバーを起動し、既存の cypress エンドツーエンドテストをすべて実行します。
```console
npm run e2e:dev:run
```
## Cypress-GitPod Setup
## Cypress と GitPod の設定
### 1. Ensure Development Environment is Running
### 1. 開発環境が稼働していることを確認する
If starting the GitPod environment did not automatically develop the environment:
GitPod 環境を起動しても自動的に環境が構築されない場合は、以下を実行します。
- Start the database
- データベースを起動します。
```console
mongod
```
- Seed the database
- データベースをシードします。
```console
npm run seed
```
- Develop the server and client
- サーバーとクライアントを構築します。
```console
npm run develop
```
### 2. Install Cypress Build Tools
### 2. Cypress ビルドツールをインストールする
```console
npm run cypress:install-build-tools
```
- When prompted in the terminal, select your keyboard layout by language/area
- 端末でプロンプトが表示されたら、言語/エリアでキーボードのレイアウトを選択してください。
Now, [Cypress can be run](/how-to-add-cypress-tests#_2-run-the-cypress-tests)
これで、[Cypress を実行することができます ](/how-to-add-cypress-tests#_2-run-the-cypress-tests)

View File

@ -1,16 +1,16 @@
# How to help with video challenges
# ビデオチャレンジを支援する方法
Video challenges are a new type of challenge in the freeCodeCamp curriculum.
ビデオチャレンジは、freeCodeCamp カリキュラムの新しいタイプのチャレンジです。
A video challenge is a small section of a full-length video course on a particular topic. A video challenge page embeds a YouTube video. Each challenge page has a single multiple-choice question related to the video. A user must answer the question correctly before moving on to the next video challenge in the course.
ビデオチャレンジは、特定のトピックに関するノーカットビデオコースの小さなセクションです。 ビデオチャレンジページには、YouTube 動画が埋め込まれています。 各チャレンジページには、動画に関連する多肢選択問題があります。 コース内で次のビデオチャレンジに進む前に、ユーザーは質問に正しく答える必要があります。
The video challenge pages are created by members of the freeCodeCamp team. YouTube videos are also uploaded by members of the freeCodeCamp team. Many of the video challenges do not yet have questions associated with them.
ビデオチャレンジのページは、freeCodeCamp チームのメンバーによって作成されます。 YouTube 動画は、FreeCodeCamp チームのメンバーによってアップロードもされます。 ビデオチャレンジの多くは、関連する質問がありません。
You can help by creating multiple-choice questions related to video sections and adding the questions to the markdown files for the video challenges.
ビデオセクションに関連する多肢選択式の質問を作成し、ビデオチャレンジマークダウンファイルに質問を追加することができます。
## Challenge Template
## チャレンジテンプレート
Below is a template of what the challenge markdown files look like.
以下はチャレンジマークダウンファイルのテンプレートです。
````md
---
@ -23,7 +23,7 @@ forumTopicId: 12345
# --description--
Challenge description text, in markdown
チャレンジの説明 (マークダウンで記入)
```html
<div>example code</div>
@ -31,47 +31,47 @@ Challenge description text, in markdown
# --question--
These fields are currently used for the multiple-choice Python challenges.
現在、このフィールドは多肢選択式 Python チャレンジが使用しています。
## --text--
The question text goes here.
質問のテキストをここに記述します。
## --answers--
Answer 1
回答 1
---
Answer 2
回答 2
---
More answers
その他の回答
## --video-solution--
The number for the correct answer goes here.
正解の番号をここに記述します。
````
## Creating questions for video challenges
## ビデオチャレンジに対する質問を作成する
### Access the video challenge markdown files
### ビデオチャレンジマークダウンファイルにアクセスする
You can find the markdown files for video challenges at the following locations in the curriculum:
カリキュラム内の以下のロケーションにビデオチャレンジマークダウンファイルがあります。
- [Data Analysis with Python Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/08-data-analysis-with-python/data-analysis-with-python-course)
- [TensorFlow 2.0 Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/11-machine-learning-with-python/tensorflow)
- [Numpy Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/08-data-analysis-with-python/numpy)
- [How Neural Networks Work Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/11-machine-learning-with-python/how-neural-networks-work)
- [Data Analysis with Python コース](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/08-data-analysis-with-python/data-analysis-with-python-course)
- [TensorFlow 2.0 コース](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/11-machine-learning-with-python/tensorflow)
- [Numpy コース](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/08-data-analysis-with-python/numpy)
- [How Neural Networks Work コース](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/11-machine-learning-with-python/how-neural-networks-work)
Pick a challenge markdown file from the options above.
上記選択肢からチャレンジマークダウンファイルを選択してください。
### Skim through the video associated with the challenge and create a multiple-choice question
### チャレンジに関連するビデオに目を通し、多肢選択式の質問を作成してください
First, find the videoId.
まず、videoId を見つけてください。
For example, in the following code from the header of a video challenge markdown file, the videoId is "nVAaxZ34khk". On GitHub, the information should be laid out in a table format.
例えば、ビデオチャレンジマークダウンファイルのヘッダーからの以下のコードで、videoIdは「nVAAxZ34khk」です。 GitHub では、情報はテーブル形式で表示されます。
````
---
@ -80,44 +80,44 @@ videoId: nVAaxZ34khk
---
```
Next, access the YouTube video with that `videoId`. The URL for the video will be:
https://www.youtube.com/watch?v=[videoId] (replace `videoId` in the URL with the video's ID - without square brackets)
次に、その `videoId` で YouTube の動画にアクセスします。 ビデオの URL は次のとおりです。
https://www.youtube.com/watch?v=[videoId] (URL 中の `videoId` をビデオの ID に置き換えます。角括弧は不要。)
In the example above, the URL is https://www.youtube.com/watch?v=nVAaxZ34khk
上記例では、URL は https://www.youtube.com/watch?v=nVAaxZ34khk です。
Skim the YouTube video with that videoId and think of a multiple-choice question based on the content of the video.
その videoId でYouTube ビデオに目を通し、ビデオコンテンツに基づいて多肢選択式の質問を考えてください。
### Add the question to the markdown file
### マークダウンファイルに質問を追加してください
You can add the question locally or using the GitHub interface. To add the question locally, you need to [set up freeCodeCamp locally](how-to-setup-freecodecamp-locally.md). You can also find the file on GitHub and click the edit button to add the question right in your browser.
ローカルでまたは GitHub インターフェースを使用して質問を追加することができます。 ローカルで質問を追加するには、「freeCodeCamp をローカルに設定する」(how-to-setup-freecodecamp-locally.md) 必要があります。 GitHub でファイルを見つけて、編集ボタンをクリックして、ブラウザで質問を追加することもできます。
特定のビデオチャレンジに質問がまだ追加されていない場合は、次のデフォルトの質問があります。
If a question has not yet been added to a particular video challenge, it will have the following default question:
```md
# --question--
## --text--
Question text
質問のテキスト
## --answers--
Answer 1
回答 1
---
Answer 2
回答 2
---
More answers
他の回答
## --video-solution--
1
```
Add/Update the question text under the part that shows:
下記項目の下に質問テキストを追加/更新してください。
```
# --question--
@ -125,16 +125,16 @@ Add/Update the question text under the part that shows:
## --text--
```
Add/Update answers (`Answer 1`, `Answer 2`, and so on) under `## --answers--`. Make sure to update the number under `## --video-solution--` with the correct answer number. You can add more possible answers using the same format. The question and answers can be surrounded with quotation marks.
`## --answers--` の下に回答を追加/更新してください (`Answer 1`、`Answer 2` など)。 `## -video-solution--` の下にある番号を正解の番号に更新してください。 同じ形式で、他の回答も追加できます。 質問と回答は引用符で囲むことができます。
### Question examples
### 質問の例
````md
# --question--
## --text--
## -text---
What does this JavaScript code log to the console?
この JavaScript コードは、コンソールに何を記録しますか?
```js
console.log('hello world');
@ -164,7 +164,7 @@ hello world
## --text--
What will print out after running this code:
以下のコードを実行すると何が出力されますか?
```py
width = 15
@ -196,8 +196,8 @@ print(height/3)
3 ````
For more examples, you can look at the markdown files for the following video course. All the challenges already have questions: [Python for Everybody Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/07-scientific-computing-with-python/python-for-everybody)
以下のビデオコースのマークダウンファイルで、その他の例も参照できます。 すべてのチャレンジにはすでに質問があります: [Python for Everybody コース](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/07-scientific-computing-with-python/python-for-everybody)
## Open a pull request
## プルリクエストをオープンする
After creating one or more questions, you can commit the changes to a new branch and [open a pull request](how-to-open-a-pull-request.md).
1 つ以上の質問を作成した後、新しいブランチに変更をコミットすると、[プルリクエストをオープンする](how-to-open-a-pull-request.md) ことができます。

View File

@ -1,103 +1,103 @@
# How to open a Pull Request (PR)
# プルリクエストを開く方法 (PR)
A pull request (PR) enables you to send changes from your fork on GitHub to freeCodeCamp.org's main repository. Once you are done making changes to the code, you can follow these guidelines to open a PR.
プルリクエスト (PR) を使用すると、GitHubのフォークから freeCodeCamp.org のメインリポジトリに変更を送信できます。 コードを変更したら、以下のガイドラインに従ってPRを開くことができます。
> [!NOTE] Your PR should be in English. See [here](index.md#translations) for how to contribute translations.
> [!NOTE] PR は英語で書きます。 翻訳に貢献する方法については、[こちら](index.md#translations) をご覧ください。
## Prepare a good PR title
## 良いPRタイトルを用意する
We recommend using [conventional title and messages](https://www.conventionalcommits.org/) for commits and pull request. The convention has the following format:
コミットやプルリクエストには、 [規約に沿ったタイトルやメッセージ](https://www.conventionalcommits.org/) を使用することをお勧めします。 規約には以下の形式があります。
> `<type>([optional scope(s)]): <description>`
>
> For example:
> 例えば、次のようになります。
>
> `fix(learn): tests for the do...while loop challenge`
When opening a Pull Request(PR), you can use the below to determine the type, scope (optional), and description.
プルリクエスト (PR) をオープンする際、以下を使用して、その種類、スコープ (任意)、説明を決定することができます。
**Type:**
**種類:**
| Type | When to select |
|:----- |:-------------------------------------------------------------------------------- |
| fix | Changed or updated/improved functionality, tests, the verbiage of a lesson, etc. |
| feat | Only if you are adding new functionality, tests, etc. |
| chore | Changes that are not related to code, tests, or verbiage of a lesson. |
| docs | Changes to `/docs` directory or the contributing guidelines, etc. |
| 種類 | 選択するタイミング |
|:----- |:-------------------------------- |
| fix | 機能、テスト、レッスン等の変更または更新/改善時 |
| feat | 新しい機能、テストなどの追加時のみ |
| chore | レッスンのコード、テスト、または検証に関連しない変更時 |
| docs | `/docs` ディレクトリまたは貢献ガイドラインなどへの変更時 |
**Scope:**
**スコープ:**
You can select a scope from [this list of labels](https://github.com/freeCodeCamp/freeCodeCamp/labels?q=scope).
[ラベルリスト](https://github.com/freeCodeCamp/freeCodeCamp/labels?q=scope) からスコープを選択できます。
**Description:**
**説明:**
Keep it short (less than 30 characters) and simple, you can add more information in the PR description box and comments.
簡潔に (30文字未満) 記述します。PR の説明欄やコメントに詳細情報を追加できます。
Some examples of good PRs titles would be:
良い PR のタイトルの例としては、次のようなものがあります。
- `fix(a11y): improved search bar contrast`
- `feat: add more tests to HTML and CSS challenges`
- `fix(api,client): prevent CORS errors on form submission`
- `docs(i18n): Chinese translation of local setup`
## Proposing a Pull Request
## プルリクエストを提案する
1. Once the edits have been committed, you will be prompted to create a pull request on your fork's GitHub Page.
1. 編集がコミットされると、フォークの GitHub ページにプルリクエストを作成するように求められます。
![Image - Compare pull request prompt on GitHub](https://contribute.freecodecamp.org/images/github/compare-pull-request-prompt.png)
![Image - Compare & pull request prompt on GitHub](https://contribute.freecodecamp.org/images/github/compare-pull-request-prompt.png)
2. By default, all pull requests should be against the freeCodeCamp main repo, `main` branch.
2. デフォルトで、プルリクエストはすべて freeCodeCamp メインリポジトリ、`main` ブランチに対して行います。
Make sure that your Base Fork is set to freeCodeCamp/freeCodeCamp when raising a Pull Request.
プルリクエストを上げるときは、Base Fork が freeCodeCamp/freeCodeCamp に設定されていることを確認してください。
![Image - Comparing forks when making a pull request](https://contribute.freecodecamp.org/images/github/comparing-forks-for-pull-request.png)
![画像 - プルリクエストを作成する際にフォークを比較する](https://contribute.freecodecamp.org/images/github/comparing-forks-for-pull-request.png)
3. Submit the pull request from your branch to freeCodeCamp's `main` branch.
3. ブランチから freeCodeCamp の `main` ブランチへ、プルリクエストを送信します。
4. In the body of your PR include a more detailed summary of the changes you made and why.
4. PR の本文には、行った変更とその理由の詳細情報を記述してください。
- You will be presented with a pull request template. This is a checklist that you should have followed before opening the pull request.
- プルリクエストテンプレートが表示されます。 これはプルリクエストを開く前に行うべきチェックリストです。
- Fill in the details as you see fit. This information will be reviewed and the reviewers will decide whether or not your pull request is accepted.
- 必要に応じて詳細を記入します。 この情報はレビューされ、レビュアーがプルリクエストを受け入れるかどうかを決定します。
- If the PR is meant to address an existing GitHub Issue then, at the end of your PR's description body, use the keyword _Closes_ with the issue number to [automatically close that issue if the PR is accepted and merged](https://help.github.com/en/articles/closing-issues-using-keywords).
- PR が既存の GitHub Issue に対処するものである場合、PR 説明本文の最後に、キーワード _Closes_ と Issue 番号を使用して、[ PR が承認されマージされたら、その Issue が自動的にクローズされるようにします](https://help.github.com/en/articles/closing-issues-using-keywords)。
> Example: `Closes #123` will close issue 123
> 例: `Closes #123` と記入すると、Issue 123 がクローズされます。
5. Indicate if you have tested on a local copy of the site or not.
5. サイトのローカルコピーでテスト済みかどうかを表示します。
- This is very important when making changes that are not just edits to text content like documentation or a challenge description. Examples of changes that need local testing include JavaScript, CSS, or HTML which could change the functionality or layout of a page.
- これは、ドキュメントやチャレンジの説明のようなテキストコンテンツを編集するだけでなく、変更を加える場合に、非常に重要です。 ローカルテストを必要とする変更の例としては、ページの機能やレイアウトを変更する可能性のある JavaScript、CSS、または HTML などが挙げられます。
- If your PR affects the behaviour of a page it should be accompanied by corresponding [Cypress integration tests](how-to-add-cypress-tests.md).
- PR がページの動作に影響を与える場合は、対応する [Cypress 統合テスト](how-to-add-cypress-tests.md) も追加する必要があります。
## Feedback on pull requests
## プルリクエストへのフィードバック
> Congratulations! :tada: on making a PR and thanks a lot for taking the time to contribute.
> おつかれさまでした! :tada: PR を作成し、時間をかけて貢献してくださったことに心から感謝します。
Our moderators will now take a look and leave you feedback. Please be patient with the fellow moderators and respect their time. All pull requests are reviewed in due course.
モデレータが内容を見て、フィードバックします。 仲間のモデレータの時間を尊重し、しばらくお待ちください。 すべてのプルリクエストは、いずれレビューされます。
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [the contributors chat room](https://chat.freecodecamp.org/channel/contributors).
[フォーラムの「Contributors」 カテゴリー](https://forum.freecodecamp.org/c/contributors) もしくは [Contributors チャットルーム](https://chat.freecodecamp.org/channel/contributors) へいつでもお気軽にお問合せください。
> [!TIP] If you are to be contributing more pull requests, we recommend you read the [making changes and syncing](how-to-setup-freecodecamp-locally.md#making-changes-locally) guidelines to avoid having to delete your fork.
> [!TIP] 他のプルリクエストも提供する場合は、フォークの削除を避けるため、[変更と同期](how-to-setup-freecodecamp-locally.md#making-changes-locally) ガイドラインをご覧になることを推奨します。
## Conflicts on a pull request
## プルリクエストでの競合
Conflicts can arise because many contributors work on the repository, and changes can break your PR which is pending a review and merge.
リポジトリ上で多くのコントリビューターが作業し、レビューとマージの保留中であるPRを壊す可能性がある変更が発生することで、競合が起こります。
More often than not you may not require a rebase, because we squash all commits, however, if a rebase is requested, here is what you should do.
大半の場合、リベースを必要としないかもしれません。すべてのコミットをスカッシュしているからです。しかしながら、リベースが要求された場合、以下を実行する必要があります。
### For usual bug fixes and features
### 通常のバグ修正と機能について
When you are working on regular bugs and features on our development branch `main`, you are able to do a simple rebase:
開発ブランチ `main` の通常のバグや機能に取り組んでいる場合は、簡単なリベースを行うことができます。
1. Rebase your local copy:
1. ローカルコピーをリベースする
```console
git checkout <pr-branch>
git pull --rebase upstream main
```
2. Resolve any conflicts and add / edit commits
2. 競合を解決し、コミットを追加/編集する
```console
# Either
@ -109,17 +109,17 @@ When you are working on regular bugs and features on our development branch `mai
git commit --amend --no-edit
```
3. Push back your changes to the PR
3. 変更を PR に押し戻す
```console
git push --force origin <pr-branch>
```
### For upcoming curriculum and features
### 今後のカリキュラムと機能について
When you are working on features for our upcoming curriculum `next-*` branches, you have to do a cherry pick:
今後のカリキュラム `next-*` ブランチの機能に取り組んでいる場合は、Cherry Pick を行う必要があります。
1. Make sure your upstream comes in sync with your local:
1. アップストリームがローカルと同期していることを確認する
```console
git checkout main
@ -128,9 +128,9 @@ When you are working on features for our upcoming curriculum `next-*` branches,
git reset --hard upstream/next-python-projects
```
2. Take backup
2. バックアップを取る
a. Either delete your local branch after taking a backup (if you still have it locally):
a. バックアップ後に、ローカルブランチを削除する (ローカルにまだある場合):
```console
git checkout <pr-branch-name>
@ -146,7 +146,7 @@ When you are working on features for our upcoming curriculum `next-*` branches,
git branch -D <pr-branch-name>
```
b. Or just a backup of your pr branch (if you do not have it locally):
b. または、PR ブランチのバックアップのみを行う (ローカルにない場合):
```console
git checkout -b <backup-branch-name> origin/<pr-branch-name>
@ -155,14 +155,14 @@ When you are working on features for our upcoming curriculum `next-*` branches,
# git checkout -b backup-feat/add-numpy-video-question origin/feat/add-numpy-video-question
```
3. Start off with a clean slate:
3. クリーンスレートで始める
```console
git checkout -b <pr-branch-name> next-python-projects
git cherry-pick <commit-hash>
```
4. Resolve any conflicts, and cleanup, install run tests
4. 競合を解決し、クリーンアップし、実行テストをインストールする
```console
npm run clean
@ -176,7 +176,7 @@ When you are working on features for our upcoming curriculum `next-*` branches,
```
5. If everything looks good push back to the PR
5. すべてがうまくいっているようであれば、PRに押し戻す
```console
git push --force origin <pr-branch-name>

View File

@ -1,54 +1,54 @@
# How to Proofread Translations
# 翻訳校正の手順
Our proofreading team is responsible for ensuring that translations accurately reflect the source text. We trust our proofreaders to ensure that we have very high quality translations.
校正チームは、翻訳文が原文を正確に反映するようにする責任があります。 私たちは、非常に高い品質の翻訳文を提供してくれる校正者を信頼しています。
All our translations are done by hand, by real humans. Proofreading ensures that there is a consistent tone across our all our translated resources like the curriculum.
翻訳はすべて実際の人間が作業しています。 校正により、カリキュラムなどの翻訳リソース全体で一貫したトーンが保証されます。
To begin proofreading, visit [our translation platform](https://translate.freecodecamp.org) and login. Select "Go to console" in the top navigation bar to switch from the public view to the workspace view.
校正を始めるには、[翻訳プラットフォーム](https://translate.freecodecamp.org) にアクセスしてログインします。 上部ナビゲーションバーで「コンソールに移動」を選択し、パブリックビューからワークスペースビューに切り替えます。
## Select a File
## ファイルの選択
You should see the list of projects you have been granted access to. Select the project that you would like to proofread, then select the language.
アクセスが許可されたプロジェクトの一覧が表示されます。 校正を行うプロジェクトを選択し、言語を選択します。
![Image - Proofreading File Tree](https://contribute.freecodecamp.org/images/crowdin/proof-file-tree.png)
![画像 - 校正ファイルツリー](https://contribute.freecodecamp.org/images/crowdin/proof-file-tree.png)
You should now see the list of available files. Choose your file by selecting the `Proofread` button on the right of that file, then choosing `Proofreading` from the drop-down menu that appears.
利用可能なファイルのリストが表示されます。 ファイルを選ぶには、ファイルの右側にある `Proofread` ボタンを押し、表示されるドロップダウンメニューから `Proofread` を選択します。
> [!NOTE] If you are in this workspace view, but want to work on [translating a file](how-to-translate-files.md) instead of proofreading, you may select `Crowdsourcing` from the dropdown menu instead.
> [!NOTE] このワークスペースビューで、校正ではなく [ファイルの翻訳](how-to-translate-files.md)を行いたい場合は、ドロップダウンメニューから `Crowdsourcing` を選択します。
## Proofread Translations
## 翻訳文の校正
![Image - Proofreading View](https://contribute.freecodecamp.org/images/crowdin/proofread.png)
![画像 - 校正ビュー](https://contribute.freecodecamp.org/images/crowdin/proofread.png)
<!--Add proofread/crowdsource button to the image-->
Here you will see the list of strings in the selected file, with their related translations. The translation that is displayed here is the translation that has received the highest score (between upvotes and downvotes) from the translation community.
ここでは、選択したファイル内の文字列のリストと関連する翻訳文が表示されます。 ここで表示される翻訳は、翻訳コミュニティから (賛成票と反対票の間で) 最高得点を得た翻訳です。
While you can view _all_ proposed translations for a given string, the community scores (determined by the upvotes and downvotes) should be taken into consideration when choosing which translation to approve. The community can review proposed translations and recommend which one is most accurate and clear.
指定された文字列の _すべての_ 翻訳候補を見ることができます。承認する翻訳文を選択する際に、(賛成票と反対票によって決定される) コミュニティのスコアを考慮します。 コミュニティは翻訳候補をレビューし、最も正確で明確な翻訳を推奨します。
1. This is the original string (in English).
2. This is the matching translated string. The most popular translation proposal, based on upvotes and downvotes, will be displayed here.
3. Clicking this checkmark button will approve that translation.
4. Crowdin will display the status of each string. `Done` means a translation has been approved and will be downloaded on our next Crowdin pull. `Todo` means the string has not been proofread. `Hidden` means the string is locked and _should not be translated_. `Comment` means the string has a related comment.
5. Translations can be selected with the checkboxes and approved here in one bulk action.
6. You can view the community proposed translations, their popularity scores, and Crowdin suggested translations here.
7. This button shows/hides the right-hand side display pane, where you can view translations, comments, translation memory, and glossary terms.
8. Crowdin displays error messages here from the quality assurance checks. In other words, if something does not seem correct in the translation, Crowdin will notify you. These translations should be approved with care.
1. 原文の文字列 (英語) を確認します。
2. 翻訳された文字列を確認します。 賛成票と反対票に基づいて、最も人気のある翻訳案がここに表示されます。
3. このチェックマークボタンをクリックすると、その翻訳が承認されます。
4. Crowdin は各文字列のステータスを表示します。 `Done` は翻訳が承認されたことを意味し、次の Crowdin プルにダウンロードされます。 `Todo` は文字列が校正されていないことを意味します。 `Hidden` は文字列がロックされており、_翻訳すべきではない_ことを意味します。 `Comment` は、その文字列に関連するコメントがあることを意味します。
5. 翻訳文をチェックボックスで選択し、一括して承認することもできます。
6. コミュニティが提案した翻訳、その人気度のスコア、Crowdin が提案した翻訳をここで参照できます。
7. このボタンで、右側の表示ペインの表示/非表示を切り替えます。ここでは、翻訳、コメント、翻訳メモリ、および用語集を見ることができます。
8. 品質保証チェックにエラーがあった際に、ここにメッセージが表示されます。 つまり、翻訳文が正しくないと思われる場合に、Crowdin から通知があります。 これらの翻訳は慎重に承認します。
No additional actions are required once a file has been proofread.
ファイルが校正されると、追加のアクションは必要ありません。
> [!NOTE] Approving a string in the proofreading view will mark it as complete and it will be downloaded in our next pull from Crowdin to GitHub.
> [!NOTE] 校正ビューで文字列を承認すると完成とマークされ、Crowdin から GitHub への次のプルでダウンロードされます。
## Becoming a proofreader
## 校正者になる
If you have any questions, or are interested in becoming a proofreader, feel free to reach out to us in our [contributors chat room](https://chat.freecodecamp.org/channel/contributors). We will typically grant you proofreading access if you have been contributing to freeCodeCamp for a while.
ご質問がある場合、または校正者になることに興味がある場合は、[コントリビューターチャットルーム](https://chat.freecodecamp.org/channel/contributors) でお気軽にお問い合わせください。 一定期間 freeCodeCamp に貢献している場合は、通常、校正へのアクセスを許可します。
Our staff team and community moderators teams are always looking for kind volunteers like you who help us make high quality translations available to the world.
スタッフチームとコミュニティモデレータチームは、世界中で高品質の翻訳を利用できるようにするための親切なボランティアを常に探しています。
> [!NOTE] Crowdin will allow you to approve your translations. In general, it is best to allow another proofreader to review your proposed translations as extra safety to ensure there are no errors.
> [!NOTE] Crowdin では、自身の翻訳を承認することを許可します。 一般的には、エラーがないことを確認するための安全策として、他の校正者が翻訳案を見直すことをお勧めしています。
## Creating a channel on Chat for a world language
## 世界の言語のチャットでチャンネルを作成する
For the most part we encourage you to use the [contributors chat](https://chat.freecodecamp.org/channel/contributors) room for all correspondence. However if the team of volunteer translators grows for a certain language, we can consider creating additional break-out channel for the language.
ほとんどの場合、すべての連絡に [コントリビューターチャット](https://chat.freecodecamp.org/channel/contributors) を使用することをお勧めします。 しかし、ある言語のボランティア翻訳者のチームが成長した場合、その言語のブレイクアウトチャンネルを追加することを検討します。
If you are already a proofreader and are interested in having a dedicated channel on our chat servers for a specific language, [fill out this form](https://forms.gle/XU5CyutrYCgDYaVZA).
すでに校正者であり、特定の言語のためのチャットサーバーに専用チャンネルを持つことに興味がある場合、[このフォーム](https://forms.gle/XU5CyutrYCgDYaVZA) に記入します。

View File

@ -1,138 +1,138 @@
Follow these guidelines for setting up freeCodeCamp locally on your system. This is highly recommended if you want to contribute regularly.
これらのガイドラインに従い、ローカルシステム上に freeCodeCamp を設定してください。 定期的に貢献したい場合に、強くお勧めします。
Some of these contribution workflows like fixing bugs in the codebase or curriculum need you to run freeCodeCamp locally on your computer.
コードベースやカリキュラムのバグを修正するなど、コントリビューションワークフローの中には、ローカルコンピュータ上で freeCodeCamp を実行する必要があるものがあります。
> [!TIP] If you are not interested in setting up freeCodeCamp locally, consider using Gitpod, a free online dev environment.
> [!TIP] freeCodeCamp のローカル設定に興味がない場合は、無料のオンライン開発環境である Gitpod の使用を検討してください。
>
> [![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
> [![Gitpod で開く](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
>
> (Starts a ready-to-code dev environment for freeCodeCamp in your browser.)
> (ブラウザで freeCodeCamp のコーディング開発準備ができている環境を起動します。)
### How to prepare your local machine
### ローカルマシンを準備する方法
Start by installing the prerequisite software for your operating system.
お使いのオペレーティングシステムの必須ソフトウェアをインストールすることから始めます。
We primarily support development on Linux and Unix-based systems. Our staff and community contributors regularly work with the codebase using tools installed on Ubuntu and macOS.
私たちは、Linux または Unix ベースのシステムでの開発を主にサポートしています。 スタッフとコミュニティのコントリビューターは、Ubuntu と macOS にインストールされているツールを使用して、定期的にコードベースの作業をしています。
We also support Windows 10 via WSL2, which you can prepare by [reading this guide](how-to-setup-wsl.md).
また、WSL2 を介した Windows 10 をサポートしており、[ガイド](how-to-setup-wsl.md) を読んで準備することができます。
Some community members also develop on Windows 10 natively with Git for Windows (Git Bash), and other tools installed on Windows. We do not have official support for such a setup at this time, we recommend using WSL2 instead.
コミュニティメンバーの中には、Git for Windows (Git Bash) や Windows にインストールされている他のツールを使用して、Windows 10でネイティブに開発する人もいます。 We do not have official support for such a setup at this time, we recommend using WSL2 instead.
#### Prerequisites:
#### 必要条件:
| Prerequisite | Version | Notes |
| --------------------------------------------------------------------------------------------- | ------- | ------------------------------------------------------------------------------------------- |
| [Node.js](http://nodejs.org) | `16.x` | We use the "Active LTS" version, See [LTS Schedule](https://nodejs.org/en/about/releases/). |
| npm (comes bundled with Node) | `8.x` | We use the version bundled with Node.js Active LTS. |
| [MongoDB Community Server](https://docs.mongodb.com/manual/administration/install-community/) | `4.0.x` | - |
| 必要条件 | バージョン | 注記 |
| --------------------------------------------------------------------------------------- | ------- | ---------------------------------------------------------------------------------------- |
| [Node.js](http://nodejs.org) | `16.x` | 「Active LTS」バージョンを使用しています。[LTS スケジュール](https://nodejs.org/en/about/releases/) を参照してください。 |
| npm (Nodeにバンドル) | `8.x` | Node.js Active LTS にバンドルされたバージョンを使用します。 |
| [MongoDB コミュニティサーバー](https://docs.mongodb.com/manual/administration/install-community/) | `4.0.x` | - |
> [!ATTENTION] If you have a different version, please install the recommended version. We can only support installation issues for recommended versions. See [troubleshooting](#troubleshooting) for details.
> [!ATTENTION] 異なるバージョンの場合は、推奨バージョンをインストールしてください。 推奨バージョンのインストールに関する問題のみサポートできます。 詳細は [troubleshooting](#troubleshooting) を参照してください。
If Node.js is already installed on your machine, run the following commands to validate the versions:
Node.js がすでにマシンにインストールされている場合、以下のコマンドを実行してバージョンを検証します。
```console
node -v
npm -v
```
> [!TIP] We highly recommend updating to the latest stable releases of the software listed above, also known as Long Term Support (LTS) releases.
> [!TIP] 長期サポート (LTS) リリースとも呼ばれる、上記の安定版の最新リリースにアップデートすることを強くお勧めします。
Once you have the prerequisites installed, you need to prepare your development environment. This is common for many development workflows, and you will only need to do this once.
必要条件をインストールしたら、開発環境を準備します。 これは多くの開発ワークフローに共通しており、一度だけこれを行う必要があります。
##### Follow these steps to get your development environment ready:
##### 以下の手順に従って、開発環境を準備してください。
1. Install [Git](https://git-scm.com/) or your favorite Git client, if you haven't already. Update to the latest version; the version that came bundled with your OS may be outdated.
1. インストール済みでない場合は、[Git](https://git-scm.com/) またはお気に入りの Git クライアントをインストールしてください。 最新バージョンにアップデートしてください。お使いの OS にバンドルされているバージョンが古い可能性があります。
2. (Optional but recommended) [Set up an SSH Key](https://help.github.com/articles/generating-an-ssh-key/) for GitHub.
2. (任意ですが推奨) GitHub 用の [SSH キーを設定](https://help.github.com/articles/generating-an-ssh-key/) します。
3. Install a code editor of your choice.
3. 選択したコードエディタをインストールします。
We highly recommend using [Visual Studio Code](https://code.visualstudio.com/) or [Atom](https://atom.io/). These are great, free and open source code editors.
[Visual Studio Code](https://code.visualstudio.com/) または [Atom](https://atom.io/) の使用を強くお勧めします。 これらは優れた、無料のオープンソースコードエディタです。
4. Set up linting for your code editor.
4. コードエディターのリンティングを設定します。
You should have [ESLint running in your editor](http://eslint.org/docs/user-guide/integrations.html), and it will highlight anything that doesn't conform to [freeCodeCamp's JavaScript Style Guide](http://forum.freecodecamp.org/t/free-code-camp-javascript-style-guide/19121).
[エディターでの ESLint 実行](http://eslint.org/docs/user-guide/integrations.html) を入手してください。[freeCodeCamp の JavaScript スタイルガイド](http://forum.freecodecamp.org/t/free-code-camp-javascript-style-guide/19121) に準拠していないものを強調表示できます。
> [!TIP] Please do not ignore any linting errors. They are meant to **help** you and to ensure a clean and simple codebase.
> [!TIP] リンティングエラーを無視しないでください。 これらは **サポート** し、クリーンでシンプルなコードベースを確保するためのものです。
## Fork the repository on GitHub
## GitHub でリポジトリをフォークする
[Forking](https://help.github.com/articles/about-forks/) is a step where you get your own copy of freeCodeCamp's main repository (a.k.a _repo_) on GitHub.
[フォーク](https://help.github.com/articles/about-forks/) とは Github 上に freeCodeCamp メインリポジトリ (別名 _repo_) のコピーを自分用に用意するステップです。
This is essential, as it allows you to work on your own copy of freeCodeCamp on GitHub, or to download (clone) your repository to work on locally. Later, you will be able to request changes to be pulled into the main repository from your fork via a pull request (PR).
これは、GitHub 上の freeCodeCamp のコピーで作業できるようにするために、またリポジトリをダウンロード (クローン) しローカルで作業するために不可欠です。 後で、プルリクエスト (PR) を介して、フォークからメインリポジトリにプルされるように変更をリクエストできます。
> [!TIP] The main repository at `https://github.com/freeCodeCamp/freeCodeCamp` is often referred to as the `upstream` repository.
> [!TIP] `https://github.com/freeCodeCamp/freeCodeCamp` のメインリポジトリは、よく `upstream` リポジトリと呼ばれます。
>
> Your fork at `https://github.com/YOUR_USER_NAME/freeCodeCamp` is often referred to as the `origin` repository. `YOUR_USER_NAME` would be replaced with your GitHub username.
> `https://github.com/YOUR_USER_NAME/freeCodeCamp` のフォークは、しばしば `origin` リポジトリと呼ばれます。 `YOUR_USER_NAME` は、GitHub のユーザーネームに置き換えられます。
**Follow these steps to fork the `https://github.com/freeCodeCamp/freeCodeCamp` repository:**
**以下の手順に従って `https://github.com/freeCodeCamp/freeCodeCamp` リポジトリをフォークします。**
1. Go to the freeCodeCamp repository on GitHub: <https://github.com/freeCodeCamp/freeCodeCamp>
1. GitHub 上の freeCodeCamp リポジトリに移動します。<https://github.com/freeCodeCamp/freeCodeCamp>
2. Click the "Fork" Button in the upper right-hand corner of the interface ([More Details Here](https://help.github.com/articles/fork-a-repo/))
2. インターフェースの右上隅にある「フォーク」ボタンをクリックします ([詳細はこちら](https://help.github.com/articles/fork-a-repo/))。
3. After the repository has been forked, you will be taken to your copy of the freeCodeCamp repository at `https://github.com/YOUR_USER_NAME/freeCodeCamp` (`YOUR_USER_NAME` would be replaced with your GitHub user name.)
3. リポジトリをフォークすると、freeCodeCamp リポジトリのコピーである `https://github.com/YOUR_USER_NAME/freeCodeCamp` に移動することになります (`YOUR_USER_NAME` は GitHub のユーザーネームに置き換えられます)。
<details>
<summary>
How to fork freeCodeCamp on GitHub (screenshot)
GitHub で freeCodeCamp をフォークする方法 (スクリーンショット)
</summary>
<br>
<img src="https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/main/docs/images/github/how-to-fork-freeCodeCamp.gif" alt="How to fork freeCodeCamp on GitHub" />
<img src="https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/main/docs/images/github/how-to-fork-freeCodeCamp.gif" alt="GitHub で freeCodeCamp をフォークする方法" />
</details>
## Clone your fork from GitHub
## GitHub からフォークのクローンを作る
[Cloning](https://help.github.com/articles/cloning-a-repository/) is where you **download** a copy of a repository from a `remote` location that is either owned by you or by someone else. In your case, this remote location is your `fork` of freeCodeCamp's repository that should be available at `https://github.com/YOUR_USER_NAME/freeCodeCamp`. (`YOUR_USER_NAME` would be replaced with your GitHub user name.)
[クローン作成](https://help.github.com/articles/cloning-a-repository/) とは、自分または他の誰かが所有しているリポジトリのコピーを、`remote` の場所から **ダウンロード** することです。 自分の場合は、この remote の場所は freeCodeCamp のリポジトリの `fork`で、`https://github.com/YOUR_USER_NAME/freeCodeCamp` で入手可能です。 `YOUR_USER_NAME` は、GitHub のユーザーネームに置き換えられます。
> [!WARNING] If you are working on a WSL2 Linux Distro, you might get performance and stability issues by running this project in a folder which is shared between Windows and WSL2 (e.g. `/mnt/c/Users/`). Therefore we recommend to clone this repo into a folder which is mainly used by your WSL2 Linux Distro and not directly shared with Windows (e.g. `~/PROJECTS/`).
> [!WARNING] WSL2 Linux Distro上で作業している場合、Windows と WSL2 の間で共有されているフォルダ内でこのプロジェクトを動作させることで、性能と安定性の Issue が発生するかもしれません (例えば `/mnt/c/Users/`)。 したがって、このリポジトリを、Windows と直接共有するフォルダではなく、主に自分の WSL2 Linux Distro で使用するフォルダに、クローンを作成することをお勧めします (例: `~/PROJECTS/`)。
>
> See [this GitHub Issue](https://github.com/freeCodeCamp/freeCodeCamp/issues/40632) for further Information about this problem.
> この問題の詳細については、 [GitHub Issue](https://github.com/freeCodeCamp/freeCodeCamp/issues/40632) を参照してください。
Run these commands on your local machine:
以下のコマンドをローカルマシンで実行します。
1. Open a Terminal / Command Prompt / Shell in your projects directory
1. Terminal / Command Prompt / Shell をプロジェクトディレクトリで開きます。
_i.e.: `/yourprojectsdirectory/`_
_: `/yourprojectsdirectory/`_
2. Clone your fork of freeCodeCamp, replacing `YOUR_USER_NAME` with your GitHub Username
2. `YOUR_USER_NAME` を GitHub のユーザーネームに置き換えて、freeCodeCamp のフォークのクローンを作成します。
```console
git clone --depth=1 https://github.com/YOUR_USER_NAME/freeCodeCamp.git
```
This will download the entire freeCodeCamp repository to your projects directory.
これで、freeCodeCamp リポジトリ全体がプロジェクトディレクトリにダウンロードされます。
Note: `--depth=1` creates a shallow clone of your fork, with only the most recent history/commit.
注: `--depth=1` は、最新の履歴 / コミットのみでフォークのシャロ―クローンを作成します。
## Set up syncing from parent
## 親からの同期を設定する
Now that you have downloaded a copy of your fork, you will need to set up an `upstream` remote to the parent repository.
フォークのコピーをダウンロードしたので、親リポジトリに `upstream` リモートを設定する必要があります。
[As mentioned earlier](#fork-the-repository-on-github), the main repository is referred `upstream` repository. Your fork referred to as the `origin` repository.
[前述](#fork-the-repository-on-github) のように、メインリポジトリは `upstream` リポジトリと呼ばれています。 自身のフォークは `origin` リポジトリと呼ばれています。
You need a reference from your local clone to the `upstream` repository in addition to the `origin` repository. This is so that you can sync changes from the main repository without the requirement of forking and cloning repeatedly.
`origin` リポジトリに加えて、ローカルクローンから `upstream` リポジトリへの参照が必要です。 これは、フォークやクローンを繰り返し行うことなく、メインリポジトリからの変更を同期できるようにするためです。
1. Change directory to the new freeCodeCamp directory:
1. ディレクトリを新しい freeCodeCamp ディレクトリに変更します。
```console
cd freeCodeCamp
```
2. Add a remote reference to the main freeCodeCamp repository:
2. メインの freeCodeCamp リポジトリへのリモート参照を追加します。
```console
git remote add upstream https://github.com/freeCodeCamp/freeCodeCamp.git
```
3. Ensure the configuration looks correct:
3. 設定が正しいことを確認します。
```console
git remote -v
```
The output should look something like below (replacing `YOUR_USER_NAME` with your GitHub username):
出力は以下のようになります (`YOUR_USER_NAME` を GitHub ユーザ名に置き換えます)。
```console
origin https://github.com/YOUR_USER_NAME/freeCodeCamp.git (fetch)
@ -141,33 +141,33 @@ You need a reference from your local clone to the `upstream` repository in addit
upstream https://github.com/freeCodeCamp/freeCodeCamp.git (push)
```
## Running freeCodeCamp locally
## freeCodeCamp をローカルで実行する
Now that you have a local copy of freeCodeCamp, you can follow these instructions to run it locally. This will allow you to:
freeCodeCamp のローカルコピーができたので、これらの指示に従ってローカルで実行することが可能です。 これによって次のことができるようになります。
- Preview edits to pages as they would appear on the learning platform.
- Work on UI related issues and enhancements.
- Debug and fix issues with the application servers and client apps.
- 学習プラットフォーム上に表示されるページへの編集をプレビューする。
- UI関連の Issue と機能強化に取り組む。
- アプリケーションサーバーとクライアントアプリの Issue をデバッグして修正する。
If you do run into issues, first perform a web search for your issue and see if it has already been answered. If you cannot find a solution, please search our [GitHub issues](https://github.com/freeCodeCamp/freeCodeCamp/issues) page for a solution and report the issue if it has not yet been reported.
問題が発生した場合は、まず Web 検索を実行し、すでに解決済みであるかどうかを確認します。 解決策が見つからない場合、[GitHub Issue](https://github.com/freeCodeCamp/freeCodeCamp/issues) ページを検索し、まだ報告されていない Issue を報告してください。
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our chat server](https://chat.freecodecamp.org/home).
そして、[フォーラムの「Contributors」カテゴリ](https://forum.freecodecamp.org/c/contributors) または [チャットサーバー](https://chat.freecodecamp.org/home) へいつでもお気軽にお問い合わせください。
> [!TIP] You may skip running freeCodeCamp locally if you are simply editing files. For instance, performing a `rebase`, or resolving `merge` conflicts.
> [!TIP] ファイルを編集するだけの場合は、freeCodeCamp のローカルでの実行をスキップしてもかまいません。 例えば、`rebase` の実行や、`merge` の競合の解決です。
>
> You can always return to this part of the instructions later. You should **only** skip this step if you do not need to run the apps on your machine.
> 後からいつでもこちらの手順に戻ることができます。 自分のマシンでアプリを実行する必要がない場合は、このステップ **のみ** スキップしてください。
>
> [Skip to making changes](#making-changes-locally).
> [変更を加えるへスキップ](#making-changes-locally) します。
### Configuring dependencies
### 依存関係を設定する
#### Step 1: Set up the environment variable file
#### ステップ 1: 環境変数ファイルを設定する
The default API keys and environment variables are stored in the file `sample.env`. This file needs to be copied to a new file named `.env` that is accessed dynamically during the installation step.
デフォルトの API キーと環境変数は、`sample.env` ファイルの中に格納されています。 このファイルは、インストールの段階で動的にアクセスされる `.env` という名前の新しいファイルにコピーする必要があります。
```console
# Create a copy of the "sample.env" and name it ".env".
# Populate it with the necessary API keys and secrets:
# "sample.env" のコピーを作成し、".env" という名前を付けます。
# 必要な API キーとシークレットを追加します。
```
<!-- tabs:start -->
@ -186,25 +186,25 @@ copy sample.env .env
<!-- tabs:end -->
The keys in the `.env` file are _not_ required to be changed to run the app locally. You can leave the default values copied over from `sample.env` as-is.
`.env` ファイル内のキーは、ローカルでアプリを動作させるのであれば、変更する必要は _ありません_`sample.env` からコピーされたデフォルト値をそのままにしておくことができます。
> [!TIP] Keep in mind if you want to use services like Auth0 or Algolia, you'll have to acquire your own API keys for those services and edit the entries accordingly in the `.env` file.
> [!TIP] Auth0 または Algolia のようなサービスを使用する場合は、これらのサービスのために自分の API キーを取得し、`.env` ファイル内で項目を編集する必要があります。
#### Step 2: Install dependencies
#### ステップ 2: 依存関係をインストールする
This step will install the dependencies required for the application to run:
このステップで、アプリケーションを動作させるために必要な依存関係をインストールします。
```console
npm ci
```
#### Step 3: Start MongoDB and seed the database
#### ステップ 3: MongoDBを起動し、データベースをシードする
Before you can run the application locally, you will need to start the MongoDB service.
ローカルでアプリケーションを実行できるようにする前に、MongoDB サービスを開始する必要があります。
> [!NOTE] Unless you have MongoDB running in a setup different than the default, the URL stored as the `MONGOHQ_URL` value in the `.env` file should work fine. If you are using a custom configuration, modify this value as needed.
> [!NOTE] デフォルトと異なった設定で MongoDB を動作させない限りは、`.env` ファイル内に `MONGOHQ_URL` の値として格納された URL はうまく機能するはずです。 カスタム設定を使用している場合は、必要に応じてこの値を変更します。
Start the MongoDB server in a separate terminal:
別のターミナルで MongoDB サーバーを起動します。
<!-- tabs:start -->
@ -216,7 +216,7 @@ mongod
#### **Windows**
- On Windows, you must specify the full path to the `mongod` binary
- Windows では、`mongod` バイナリへの完全なパスを指定する必要があります。
```console
"C:\Program Files\MongoDB\Server\3.6\bin\mongod"
@ -224,62 +224,62 @@ mongod
<!-- tabs:end -->
Make sure to replace `3.6` with the version you have installed
必ず `3.6` をインストールしたバージョンに置き換えてください。
> [!TIP] You can avoid having to start MongoDB every time by installing it as a background service. You can [learn more about it in their documentation for your OS](https://docs.mongodb.com/manual/administration/install-community/)
> [!TIP] MongoDBをバックグラウンドサービスとしてインストールすることで、毎回起動する必要がなくなります。 [お使いのOSに関するドキュメント](https://docs.mongodb.com/manual/administration/install-community/) で詳細を確認できます。
Next, let's seed the database. In this step, we run the below command that fills the MongoDB server with some initial data sets that are required by services. These include a few schemas, among other things.
次に、データベースをシードします。 このステップでは、サービスに必要な初期データセットを MongoDB サーバーに入れる以下のコマンドを実行します。 これらはいくつかのスキーマを含みます。
```console
npm run seed
```
#### Step 4: Start the freeCodeCamp client application and API server
#### ステップ 4: freeCodeCamp クライアントアプリケーションと API サーバーを起動する
You can now start up the API server and the client applications.
API サーバーとクライアントアプリケーションを起動できるようになりました。
```console
npm run develop
```
This single command will fire up all the services, including the API server and the client applications available for you to work on.
この単一コマンドは、APIサーバーや利用可能なクライアントアプリケーションを含むすべてのサービスを起動します。
> [!NOTE] Once ready, open a web browser and **visit <http://localhost:8000>**. If the app loads, congratulations you're all set! You now have a copy of freeCodeCamp's entire learning platform running on your local machine.
> [!TIP] 準備が整ったら、Web ブラウザを開いて **<http://localhost:8000>** をご覧ください。 アプリがロードされたとしたら、すべての準備ができているということです。おめでとうございます! これで、freeCodeCamp の学習プラットフォーム全体のコピーがローカルマシン上で実行されます。
> [!TIP] The API Server serves APIs at `http://localhost:3000`. The Gatsby app serves the client application at `http://localhost:8000`
> [!TIP] API サーバーは、API を `http://localhost:3000` で提供します。 Gatsby アプリは、クライアントアプリケーションを `http://localhost:8000` で提供します
> If you visit <http://localhost:3000/explorer> you should see the available APIs.
> <http://localhost:3000/explorer> にアクセスすると、利用可能な API が表示されます。
## Sign in with a local user
## ローカルユーザーでサインインする
Your local setup automatically populates a local user in the database. Clicking the `Sign In` button will automatically authenticate you into the local application.
ローカル設定では自動的にデータベース内にローカルユーザーを追加します。 `Sign In` ボタンをクリックすると、ローカルアプリケーションへの認証が自動的に行われます。
However, accessing the user portfolio page is a little tricky. In development, Gatsby takes over serving the client-side pages and hence you will get a `404` page for the user portfolio when working locally.
ただし、ユーザーポートフォリオページにアクセスするのは少し難しいです。 開発中 Gatsby は、クライアント側のページにサービスを引き継ぎ、ローカルで作業する際に、ユーザーポートフォリオの `404` ページを取得します。
Simply clicking the **"Preview Custom 404 Page"** button will forward you to the correct page.
**「Preview Custom 404 Page」** ボタンをクリックするだけで、正しいページに移動します。
<details>
<summary>
How to sign in when working locally (screenshot)
ローカル作業時のサインイン方法 (スクリーンショット)
</summary>
<br>
<img src="https://user-images.githubusercontent.com/29990697/71541249-f63cdf00-2923-11ea-8a85-cefb6f9c9977.gif" alt="How to sign in when working locally" />
<img src="https://user-images.githubusercontent.com/29990697/71541249-f63cdf00-2923-11ea-8a85-cefb6f9c9977.gif" alt="ローカルで作業している時にサインインする方法" />
</details>
## Making changes locally
## ローカルで変更を行う
You can now make changes to files and commit your changes to your local clone of your fork.
ファイルに変更を加え、フォークのローカルクローンに変更を反映できるようになりました。
Follow these steps:
以下の手順に従ってください。
1. Validate that you are on the `main` branch:
1. `main` ブランチにいることを確認します。
```console
git status
```
You should get an output like this:
次のような出力になるはずです。
```console
On branch main
@ -288,59 +288,59 @@ Follow these steps:
nothing to commit, working directory clean
```
If you are not on main or your working directory is not clean, resolve any outstanding files/commits and checkout `main`:
main にいない場合や作業ディレクトリがクリーンでない場合は、未処理のファイル / コミットを処理し、`main`をチェックアウトします。
```console
git checkout main
```
2. Sync the latest changes from the freeCodeCamp upstream `main` branch to your local main branch:
2. freeCodeCamp の upstream `main` ブランチからローカルの main ブランチへと最新の変更を同期させます。
> [!WARNING] If you have any outstanding pull request that you made from the `main` branch of your fork, you will lose them at the end of this step.
> [!WARNING] フォークの `main` ブランチから行った未処理のプルリクエストがある場合は、このステップの最後にそれらを失うことになります。
>
> You should ensure your pull request is merged by a moderator before performing this step. To avoid this scenario, you should **always** work on a branch other than the `main`.
> このステップを実行する前に、プルリクエストがモデレータによってマージされていることを確認します。 このシナリオを回避するには、**常に** `main` 以外のブランチで作業する必要があります。
This step **will sync the latest changes** from the main repository of freeCodeCamp. It is important that you rebase your branch on top of the latest `upstream/main` as often as possible to avoid conflicts later.
このステップで、freeCodeCamp の main リポジトリからの **最新の変更を同期** させます。 競合を回避するために、できるだけ頻繁に最新の `upstream/main` の上に、自分のブランチをリベースすることが重要です。
Update your local copy of the freeCodeCamp upstream repository:
freeCodeCamp upstream リポジトリのローカルコピーを更新します。
```console
git fetch upstream
```
Hard reset your main branch with the freeCodeCamp main:
freeCodeCamp main で main ブランチをハードリセットします。
```console
git reset --hard upstream/main
```
Push your main branch to your origin to have a clean history on your fork on GitHub:
GitHub 上のフォークにクリーンな履歴を表示するには、main ブランチを origin にプッシュします。
```console
git push origin main --force
```
You can validate your current main matches the upstream/main by performing a diff:
diff を実行することにより、現在の main が upstream/main と一致することを確認できます。
```console
git diff upstream/main
```
The resulting output should be empty.
出力結果は空になるはずです。
3. Create a fresh new branch:
3. 新しいブランチを作成します。
Working on a separate branch for each issue helps you keep your local work copy clean. You should never work on the `main`. This will soil your copy of freeCodeCamp and you may have to start over with a fresh clone or fork.
それぞれの Issue に対して別のブランチで作業することは、ローカル作業のコピーをクリーンに保つのに役立ちます。 `main` では作業しないでください。 これは freeCodeCamp の自分のコピーを汚してしまい、新たなクローンやフォークからやり直さなくてはならない可能性があります。
Check that you are on `main` as explained previously, and branch off from there:
前述したように `main` にいることを確認して、そこからブランチに進んでください。
```console
git checkout -b fix/update-guide-for-xyz
```
Your branch name should start with a `fix/`, `feat/`, `docs/`, etc. Avoid using issue numbers in branches. Keep them short, meaningful and unique.
ブランチ名は `fix/``feat/``docs/`などで始まる必要があります。 ブランチ内で Issue 番号の使用は避けてください。 短く、意味のあり、固有な名前にします。
Some examples of good branch names are:
適切なブランチ名の例は、次のとおりです。
```md
fix/update-challenges-for-react
@ -350,19 +350,19 @@ Follow these steps:
translate/add-spanish-basic-html
```
4. Edit pages and work on code in your favorite text editor.
4. ページを編集し、お気に入りのテキストエディタでコードを作成します。
5. Once you are happy with the changes you should optionally run freeCodeCamp locally to preview the changes.
5. 満足のいく変更が完成したら、必要に応じて freeCodeCamp をローカルで実行して変更をプレビューします。
6. Make sure you fix any errors and check the formatting of your changes.
6. エラーを修正し、変更のフォーマットを確認してください。
7. Check and confirm the files you are updating:
7. アップデートするファイルを確認します。
```console
git status
```
This should show a list of `unstaged` files that you have edited.
編集した `unstaged` のファイルリストが表示されます。
```console
On branch feat/documentation
@ -379,27 +379,27 @@ Follow these steps:
...
```
8. Stage the changes and make a commit:
8. 変更をステージし、コミットします。
In this step, you should only mark files that you have edited or added yourself. You can perform a reset and resolve files that you did not intend to change if needed.
このステップでは、自分で編集または追加したファイルのみをマークする必要があります。 必要に応じて、変更するつもりではなかったファイルを、リセットして解決できます。
```console
git add path/to/my/changed/file.ext
```
Or you can add all the `unstaged` files to the staging area:
`unstaged` のファイルをすべて、ステージングエリアに追加することもできます。
```console
git add .
```
Only the files that were moved to the staging area will be added when you make a commit.
ステージングエリアに移されたファイルのみが、コミットを行うときに追加されます。
```console
git status
```
Output:
出力:
```console
On branch feat/documentation
@ -414,24 +414,24 @@ Follow these steps:
modified: docs/how-to-work-on-guide-articles.md
```
Now, you can commit your changes with a short message like so:
これで、次のような短いメッセージで変更をコミットできます。
```console
git commit -m "fix: my short commit message"
```
Some examples:
:
```md
fix: update guide article for Java - for loop
feat: add guide article for alexa skills
```
Optional:
オプション:
We highly recommend making a conventional commit message. This is a good practice that you will see on some of the popular Open Source repositories. As a developer, this encourages you to follow standard practices.
慣習的なコミットメッセージを作ることを強くお勧めします。 これは、人気のあるオープンソースリポジトリで見ることができる良い方法です。 開発者として、この標準的な慣行に従うことをお勧めします。
Some examples of conventional commit messages are:
従来のコミットメッセージの例は次のとおりです。
```md
fix: update HTML guide article
@ -440,67 +440,67 @@ Follow these steps:
docs: update contributing guidelines
```
Keep these short, not more than 50 characters. You can always add additional information in the description of the commit message.
50文字未満の短い文にします。 コミットメッセージの説明にいつでも追加の情報を加えることができます。
This does not take any additional time than an unconventional message like 'update file' or 'add index.md'
こうすることで、「updateファイル」や「add index.md」のような型破りなメッセージよりも時間がかかりません。
You can learn more about why you should use conventional commits [here](https://www.conventionalcommits.org/en/v1.0.0-beta.2/#why-use-conventional-commits).
慣習的なコミットを使用すべき理由については、[こちら](https://www.conventionalcommits.org/en/v1.0.0-beta.2/#why-use-conventional-commits) をご覧ください。
9. If you realize that you need to edit a file or update the commit message after making a commit you can do so after editing the files with:
9. コミットを行った後にファイルを編集したりコミットメッセージを更新する必要があることに気づいた場合は、以下のようにファイルを編集できます。
```console
git commit --amend
```
This will open up a default text editor like `nano` or `vi` where you can edit the commit message title and add/edit the description.
これにより、`nano` や `vi` のようなデフォルトのテキストエディタが開き、コミットメッセージのタイトルを編集したり、説明を追加/編集したりすることができます。
10. Next, you can push your changes to your fork:
10. 次に、フォークに変更をプッシュできます。
```console
git push origin branch/name-here
```
## Proposing a Pull Request (PR)
## プルリクエストを提案する (PR)
After you've committed your changes, check here for [how to open a Pull Request](how-to-open-a-pull-request.md).
変更をコミットし終えた後に、[プルリクエストを開く方法](how-to-open-a-pull-request.md) をここで確認してください。
## Quick commands reference
## クイックコマンドリファレンス
A quick reference to the commands that you will need when working locally.
ローカルで作業する時に必要なコマンドのクイックリファレンスです。
| command | description |
| -------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| `npm ci` | Installs / re-install all dependencies and bootstraps the different services. |
| `npm run seed` | Parses all the challenge markdown files and inserts them into MongoDB. |
| `npm run develop` | Starts the freeCodeCamp API Server and Client Applications. |
| `npm run storybook` | Starts Storybook for component library development. |
| `npm test` | Run all JS tests in the system, including client, server, lint and challenge tests. |
| `npm run test-client` | Run the client test suite. |
| `npm run test:curriculum` | Run the curriculum test suite. |
| `npm run test:curriculum --block='Basic HTML and HTML5'` | Test a specific Block. |
| `npm run test:curriculum --superblock='responsive-web-design'` | Test a specific SuperBlock. |
| `npm run test-curriculum-full-output` | Run the curriculum test suite, without bailing after the first error |
| `npm run test-server` | Run the server test suite. |
| `npm run e2e` | Run the Cypress end to end tests. |
| `npm run clean` | Uninstalls all dependencies and cleans up caches. |
| コマンド | 説明 |
| -------------------------------------------------------------- | ----------------------------------------------------- |
| `npm ci` | すべての依存関係をインストール/再インストールし、異なるサービスをブートストラップします。 |
| `npm run seed` | すべてのチャレンジのマークダウンファイルを解析し、MongoDB に挿入します。 |
| `npm run develop` | freeCodeCamp の API サーバーとクライアントアプリケーションを起動します。 |
| `npm run storybook` | コンポーネントライブラリ開発のためのストーリーブックを起動します。 |
| `npm test` | クライアント、サーバー、lint、チャレンジテストを含むシステム内で、すべての JS テストを実行します。 |
| `npm run test-client` | クライアントテストスイートを実行します。 |
| `npm run test:curriculum` | カリキュラムテストスイートを実行します。 |
| `npm run test:curriculum --block='Basic HTML and HTML5'` | 特定のブロックをテストします。 |
| `npm run test:curriculum --superblock='responsive-web-design'` | 特定のスーパーブロックをテストします。 |
| `npm run test-curriculum-full-output` | 最初のエラーが発生した後、終了せずにカリキュラムテストスイートを実行します。 |
| `npm run test-server` | サーバーテストスイートを実行します。 |
| `npm run e2e` | Cypress エンドツーエンドテストを実行します。 |
| `npm run clean` | すべての依存関係をアンインストールして、キャッシュをクリーンアップします。 |
## Troubleshooting
## トラブルシューティング
### Issues with installing the recommended prerequisites
### 推奨される必要条件をインストールする際の問題
We regularly develop on the latest or most popular operating systems like macOS 10.15 or later, Ubuntu 18.04 or later, and Windows 10 (with WSL2).
通常 macOS 10.15 以降、Ubuntu 18.04 以降、Windows 10 (WSL2) のような、最新または最も一般的なオペレーティングシステムで開発しています。
It is recommended to research your specific issue on resources such as Google, Stack Overflow, and Stack Exchange. There is a good chance that someone has faced the same issue and there is already an answer to your specific query.
Google、Stack Overflow、Stack Exchange などのリソースに関する特定の問題を調べることをお勧めします。 誰かが同じ問題に直面していて、すでに具体的な質問に対する回答が存在する可能性があります。
If you are on a different OS and/or are still running into issues, see [getting help](#getting-help).
別の OS をお使いの場合や問題が解決しない場合は、[ヘルプ](#getting-help) を参照してください。
> [!WARNING]
>
> Please avoid creating GitHub issues for prerequisite issues. They are out of the scope of this project.
> 必要条件の問題のために GitHub issue を作成しないでください。 それらはこのプロジェクトの範囲外です。
### Issues with the UI, Fonts, build errors, etc.
### UI、フォント、ビルドエラーなどに関する問題
If you face issues with the UI, Fonts or see builds errors a cleanup can be useful:
UI やフォントに関する問題またはビルドエラーには、クリーンアップが役立ちます。
```console
npm run clean
@ -509,17 +509,17 @@ npm run seed
npm run develop
```
OR
もしくは
Use the shortcut
ショートカットを使用することもできます。
```
npm run clean-and-develop
```
If you continue to face issues with the build, cleaning up the workspace is recommend.
それでも、ビルドに関する問題が解決しない場合は、ワークスペースのクリーンアップを推奨します。
Use `git clean` in interactive mode:
対話モードで `git clean` を使用してください。
```
git clean -ifdX
@ -527,20 +527,20 @@ git clean -ifdX
<details>
<summary>
How to clean git untracked files (screenshot)
追跡されていない git ファイルをクリーンアップする方法(スクリーンショット)
</summary>
<br>
<img src="https://user-images.githubusercontent.com/1884376/94270515-ca579400-ff5d-11ea-8ff1-152cade31654.gif" alt="How to clean git untracked files" />
<img src="https://user-images.githubusercontent.com/1884376/94270515-ca579400-ff5d-11ea-8ff1-152cade31654.gif" alt="追跡されていない git ファイルをクリーンアップする方法" />
</details>
### Issues with API, login, Challenge Submissions, etc.
### API、ログイン、チャレンジ提出などに関する問題
If you can't sign in, and instead you see a banner with an error message that it will be reported to freeCodeCamp, please double-check that your local port `3000` is not in use by a different program.
サインインできず、「freeCodeCamp に報告されます」というエラーメッセージが表示される場合、ローカルポート `3000` が別のプログラムで使用されていないことを再確認してください。
<!-- tabs:start -->
#### **macOS/Linux/WSL on Windows - From Terminal:**
#### **macOSLinuxWindows 上の WSL - 端末から:**
```console
netstat -a | grep "3000"
@ -548,7 +548,7 @@ netstat -a | grep "3000"
tcp4 0 0 0.0.0.0:3000 DESKTOP LISTEN
```
#### **On Windows - From Elevated PowerShell:**
#### **Windows - 管理者権限で起動したパワーシェルから:**
```powershell
netstat -ab | Select-String "3000"
@ -562,14 +562,14 @@ TCP 0.0.0.0:3000 DESKTOP LISTENING
### Issues installing dependencies
If you get errors while installing the dependencies, please make sure that you are not in a restricted network or your firewall settings do not prevent you from accessing resources.
依存関係のインストール中にエラーが発生した場合、ネットワークが制限されていないこと、またはファイアウォール設定でリソースへのアクセスが妨げられていないことを確認してください。
The first time setup can take a while depending on your network bandwidth. Be patient, and if you are still stuck we recommend using GitPod instead of an offline setup.
最初の設定では、ネットワーク帯域幅に応じて時間がかかることがあります。 それでも設定できない場合は、オフライン設定ではなく GitPod を使用することを推奨します。
> [!NOTE] If you are using Apple Devices with M1 Chip to run the application locally, it is suggested to use Node v14.7 or above. You might run into issues with dependencies like Sharp otherwise.
> [!NOTE] M1 チップのある Apple Devices を使用してアプリケーションをローカルで実行する場合は、Node v14.7 以上を使用することをお勧めします。 さもなければ、Sharp のような依存関係に関連する問題が発生する可能性があります
## Getting Help
## ヘルプ
If you are stuck and need help, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [the contributors chat room](https://chat.freecodecamp.org/channel/contributors).
問題がありサポートが必要な場合は、[フォーラムの「Contributors」カテゴリ](https://forum.freecodecamp.org/c/contributors) または [contributors チャットルーム](https://chat.freecodecamp.org/channel/contributors)でお気軽にお尋ねください。
There might be an error in the console of your browser or in Bash / Terminal / Command Line that will help identify the problem. Provide this error message in your problem description so others can more easily identify the issue and help you find a resolution.
ブラウザのコンソールやBashターミナルコマンドラインで、問題を特定するのに役立つエラーが表示されている可能性があります。 問題の説明にこのエラーメッセージを提供することで、他の人がより簡単に問題を特定し、解決策を見つけることができます。

View File

@ -1,26 +1,26 @@
# Set up freeCodeCamp on Windows Subsystem for Linux (WSL)
# Linux 用の Windows サブシステム (WSL) で freeCodeCamp を設定する
> [!NOTE] Before you follow these instructions make sure your system meets the requirements
> [!NOTE] これらの指示に従う前に、システムが要件を満たしていることを確認してください。
>
> **WSL 2**: Windows 10 64-bit (Version 2004, Build 19041 or higher) - available for all distributions including Windows 10 Home.
> **WSL2** : Windows 10 64-bit (Version 2004, Build 19041以上) - Windows 10 Home を含むすべてのディストリビューションで利用可能です。
>
> **Docker Desktop for Windows**: See respective requirements for [Windows 10 Pro](https://docs.docker.com/docker-for-windows/install/#system-requirements) and [Windows 10 Home](https://docs.docker.com/docker-for-windows/install-windows-home/#system-requirements)
> **Docker Desktop for Windows** : [Windows 10 Pro](https://docs.docker.com/docker-for-windows/install/#system-requirements) および [Windows 10 Home](https://docs.docker.com/docker-for-windows/install-windows-home/#system-requirements) の各要件を参照してください。
This guide covers some common steps with the setup of WSL2. Once some of the common issues with WSL2 are addressed, you should be able to follow [this local setup guide](how-to-setup-freecodecamp-locally.md) to work with freeCodeCamp on Windows running a WSL distro like Ubuntu.
このガイドでは、WSL2 のセットアップに関する一般的な手順について説明します。 WSL2 に関する一般的な問題に対処したら、[ローカルセットアップガイド](how-to-setup-freecodecamp-locally.md) に従い、Ubuntu のように WSL ディストリビューションを実行している Windows 上で freeCodeCamp を起動できるようになります。
## Enable WSL
## WSLを有効化する
Follow the instructions on the [official documentation](https://docs.microsoft.com/en-us/windows/wsl/install-win10) to install WSL1 and followed by upgrading to WSL2.
[公式ドキュメント](https://docs.microsoft.com/en-us/windows/wsl/install-win10) の指示に従って、WSL1 をインストールしてから、WSL2 にアップグレードしてください。
## Install Ubuntu
## Ubuntu をインストールする
1. We recommended using Ubuntu-18.04 or above with WSL2.
1. WSL2 で Ubuntu-18.04 またはそれ以降を使用することをお勧めします。
> [!NOTE]
>
> While you may use other non-debian based distros, they all come with their own gotchas and are beyond the scope of this guide.
> 他の非debianベースのdistrosを使用することができますが、それぞれの問題点があり、このガイドの範囲を超えています。
2. Update the dependencies for the OS
2. OS の依存関係を更新します。
```console
sudo apt update
@ -30,9 +30,9 @@ Follow the instructions on the [official documentation](https://docs.microsoft.c
sudo apt autoremove -y
```
## Set up Git
## Git を設定する
Git comes pre-installed with Ubuntu 18.04, verify your Git version with `git --version`.
Git は Ubuntu 18.04 でプリインストールされています。Git バージョンを `git --version` で確認してください。
```output
~
@ -40,45 +40,45 @@ Git comes pre-installed with Ubuntu 18.04, verify your Git version with `git --v
git version 2.25.1
```
(Optional but recommended) You can now proceed to [setting up your ssh keys](https://help.github.com/articles/generating-an-ssh-key) with GitHub.
(任意ですが推奨) GitHub で [ssh キー設定](https://help.github.com/articles/generating-an-ssh-key) を実行します。
## Installing a Code Editor
## コードエディタをインストールする
We highly recommend installing [Visual Studio Code](https://code.visualstudio.com) on Windows 10. It has great support for WSL and automatically installs all the necessary extensions on your WSL distro.
Windows 10 に [Visual Studio Code](https://code.visualstudio.com) をインストールすることを強くお勧めします。 WSLの素晴らしいサポートがあり、自動的にWSL distro に必要な拡張機能をすべてインストールします。
Essentially, you will edit and store your code on Ubuntu-18.04 with VS Code installed on Windows.
基本的には、Windows にインストールされている VS Code を使用して、Ubuntu-18.04 上でコードを編集して保存します。
If you use [IntelliJ Idea](https://www.jetbrains.com/idea/), you may need to update your Node interpreter and Npm package manager to what is installed on your WSL distro.
[IntelliJ Idea](https://www.jetbrains.com/idea/) を使用する場合、Node インタプリターと Npm パッケージマネジャーを WSL distro にインストールされているものに更新する必要があるかもしれません。
You can check these settings by going to Settings > Languages & Frameworks > Node.js and NPM.
その設定は、設定 > 言語 & フレームワーク > Node.js および NPM で確認できます。
## Installing Docker Desktop
## Docker Desktop をインストールする
**Docker Desktop for Windows** allows you to install and run databases like MongoDB and other services like NGINX and more. This is useful to avoid common pitfalls with installing MongoDB or other services directly on Windows or WSL2.
**Docker Desktop for Windows** を使用すると、MongoDB のようなデータベースや NGINX などのサービスをインストールして実行できます。 MongoDB やその他のサービスを Windows または WSL2 に直接インストールする際の一般的な落とし穴を避けることができます。
Follow the instructuction on the [official documentation](https://docs.docker.com/docker-for-windows/install) and install Docker Desktop for your Windows distribution.
[公式ドキュメント](https://docs.docker.com/docker-for-windows/install) の指示に従って、Docker Desktop for Windows をインストールしてください。
There are some minimum hardware requirements for the best experience.
最高の体験を得るための最低限のハードウェア要件があります。
## Configure Docker Desktop for WSL
## Docker Desktop for WSL を構成する
Once Docker Desktop is installed, [follow these instructions](https://docs.docker.com/docker-for-windows/wsl) and configure it to use the Ubuntu-18.04 installation as a backend.
Docker Desktop がインストールされたら、[この手順に従って](https://docs.docker.com/docker-for-windows/wsl) Ubuntu-18.04 をバックエンドとして使用するように設定します。
This makes it so that the containers run on the WSL side instead of running on Windows. You will be able to access the services over `http://localhost` on both Windows and Ubuntu.
これにより、コンテナは Windows 上ではなく WSL 側で実行されます。 Windows と Ubuntu の両方で `http://localhost` からサービスにアクセスできます。
## Install MongoDB from Docker Hub
## Docker Hub から MongoDB をインストールする
Once you have configured Docker Desktop to work with WSL2, follow these steps to start a MongoDB service:
WSL2 で動作するように Docker Desktop を設定したら、次の手順に従って MongoDB サービスを起動します。
1. Launch a new Ubuntu-18.04 terminal
1. 新しい Ubuntu-18.04 端末を起動します。
2. Pull `MongoDB 4.0.x` from dockerhub
2. dockerhub から `MongoDB 4.0.x` を取得します。
```console
docker pull mongo:4.0
```
3. Start the MongoDB service at port `27017`, and configure it to run automatically on system restarts
3. MongoDB サービスをポート `27017` で起動し、システム再起動時に自動的に実行するように設定します。
```console
docker run -it \
@ -89,13 +89,13 @@ Once you have configured Docker Desktop to work with WSL2, follow these steps to
-d mongo:4.0
```
4. You can now access the service from both Windows or Ubuntu at `mongodb://localhost:27017`.
4. Windows または Ubuntu から `mongodb://localhost:27017` でサービスにアクセスできるようになりました。
## Installing Node.js and npm
## Node.js と npm をインストールする
We recommend you install the LTS release for Node.js with a node version manager - [nvm](https://github.com/nvm-sh/nvm#installing-and-updating).
Node バージョンマネジャー - [nvm](https://github.com/nvm-sh/nvm#installing-and-updating) を使用して、Node.js 用の LTS リリースをインストールすることを推奨します。
Once installed use these commands to install and use the Node.js version as needed
インストールしたら、以下のようなコマンドを使って、Node.js バージョンをインストールして使用します。
```console
nvm install --lts
@ -111,23 +111,23 @@ nvm install 14
nvm use 12
```
Node.js comes bundled with `npm`, you can update to the latest versions of `npm` with:
Node.js には `npm` がバンドルされています。次のコマンドで `npm` の最新バージョンに更新することができます。
```console
npm install -g npm@latest
```
## Set up freeCodeCamp locally
## freeCodeCamp をローカルで設定する
Now that you have installed the pre-requisites, follow [our local setup guide](how-to-setup-freecodecamp-locally.md) to clone, install and setup freeCodeCamp locally on your machine.
前提条件のインストールが完了したら、[ ローカルセットアップガイド](how-to-setup-freecodecamp-locally.md) に従って、マシンに freeCodeCamp をローカルにクローンし、インストールし、セットアップしてください。
> [!WARNING]
>
> Please note, at this time the set up for Cypress tests (and related GUI needs) are a work in progress. You should still be able to work on most of the codebase.
> 現在、Cypress テストのセットアップ (および関連するGUIのニーズ) 作業が進行中です。 それでも、ほとんどのコードベースで作業できるはずです。
## Useful Links
## 有用なリンク
- [A WSL2 Dev Setup with Ubuntu 20.04, Node.js, MongoDB, VS Code and Docker](https://devlog.sh/wsl2-dev-setup-with-ubuntu-nodejs-mongodb-and-docker) - an article by Mrugesh Mohapatra (Staff Developer at freeCodeCamp.org)
- Frequently asked questions on:
- [Ubuntu 20.04, Node.js, MongoDB, VS Code and Docker を使用した WSL2 Dev セットアップ](https://devlog.sh/wsl2-dev-setup-with-ubuntu-nodejs-mongodb-and-docker) - Mrugesh Mohapatra (freeCodeCamp.org のスタッフ開発者)
- よくある質問:
- [Windows Subsystem for Linux](https://docs.microsoft.com/en-us/windows/wsl/faq)
- [Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/faqs)

View File

@ -1,22 +1,22 @@
# How to Test Translations Locally
# 翻訳文をローカルでテストする方法
> [!NOTE] This process is not required, but documented in case you would like to preview what your translations will look like.
> [!NOTE] このプロセスは必須ではありませんが、翻訳文がどのように見えるかをプレビューしたいという場合に備えて文書化されました。
If you would like to test your translations on a local instance of the freeCodeCamp `/learn` site, first ensure you have [set up the codebase](how-to-setup-freecodecamp-locally.md).
翻訳文を freeCodeCamp の `/learn` サイトでテストしたい場合は、まず [コードベースが設定済み](how-to-setup-freecodecamp-locally.md) であることを確認してください。
## Enabling a Language
## 言語を有効にする
There are a few steps to take in order to allow the codebase to build in your desired language.
コードベースをご希望の言語で構築するために、いくつかのステップがあります。
First, visit the `config/i18n/all-langs.ts` file to add the language to the available languages list and configure the values. There are four objects here.
まず、`config/i18n/all-langs.ts` ファイルにアクセスして、利用可能な言語リストに言語を追加し、値を設定します。 ここには 4 つのオブジェクトがあります。
- `availableLangs`: For both the `client` and `curriculum` arrays, add the text name of the language. This is the value that will be used in the `.env` file later.
- `auditedCerts`: Add the text name of the language as the _key_, and add an array of `SuperBlocks.{cert}` variables as the _value_. This tells the client which certifications are fully translated.
- `i18nextCodes`: These are the ISO language codes for each language. You will need to add the appropriate ISO code for the language you are enabling. These do need to be unique for each language.
- `langDisplayNames`: These are the display names for the language selector in the navigation menu.
- `langCodes`: These are the language codes used for formatting dates and numbers. These should be Unicode CLDR codes instead of ISO codes.
- `availableLangs` : `client``curriculum` 両方の配列で、言語のテキスト名を追加します。 これは `.env` ファイルで使用される値です。
- `auditedCerts` : 言語のテキスト名を _key_ として追加し、`SuperBlocks.{cert}` 変数の配列を _value_ として追加します。 これは、クライアントにどの認定講座の翻訳が完了しているのかを伝えます。
- `i18nextCodes` : これらは各言語の ISO の言語コードです。 有効にしようとしている言語に適切な ISO コードを追加する必要があります。 言語コードは、各言語に固有のものである必要があります。
- `langDisplayNames` : これらはナビゲーションメニューの言語セレクターで使用する表示名です。
- `langcodes` : これらは日付と数字の書式設定に使用する言語コードです。 ISO コードではなく、Unicode CLDR コードである必要があります。
As an example, if you wanted to enable Dothraki as a language, your `all-langs.js` objects should look like this:
一例を挙げると、Dothraki という言語を有効にしたい場合、`all-langs.js` の各オブジェクトは次のようになります。
```js
const availableLangs = {
@ -94,13 +94,13 @@ const langCodes = {
};
```
Next, open the `client/src/utils/algolia-locale-setup.ts` file. This data is used for the search bar that loads `/news` articles. While it is unlikely that you are going to test this functionality, missing the data for your language can lead to errors when attempting to build the codebase locally.
次に、`client/src/utils/algolia-locale-setup.ts` ファイルを開きます。 このデータは、`/news` 記事を読み込む検索バーに使用されます。 この機能をテストする可能性は低いですが、 言語のデータがないと、ローカルでコードベースを構築しようとする際にエラーが発生する可能性があります。
Add an object for your language to the `algoliaIndices` object. You should use the values for the `english` object for local testing, replacing the `english` key with your language's `availableLangs` value.
`algoliaIndices` オブジェクトに言語のオブジェクトを追加します。 ローカルテスト用に `english` オブジェクトの値を使用する必要があります。`english` キーを、言語の `availableLangs` 値に置き換えます。
> [!NOTE] If we have already deployed an instance of news in your target language, you can update the values to reflect the live instance. Otherwise, use the English values.
> [!NOTE] すでに対象言語でニュースのインスタンスをデプロイしている場合は、値を更新してライブインスタンスを反映することができます。 それ以外の場合は、英語の値を使用します。
If you were to add Dothraki:
Dothraki を追加する場合は、次のとおりです。
```js
const algoliaIndices = {
@ -127,16 +127,16 @@ const algoliaIndices = {
};
```
Finally, in your `.env` file, set `CLIENT_LOCALE` and `CURRICULUM_LOCALE` to your new language (use the `availableLangs` value.)
最後に、`.env` ファイルの中で、`CLIENT_LOCALE` と `CURRICUUM_LOCALE` を新しい言語 (`availableLangs` 値を使用) に設定します。
```txt
CLIENT_LOCALE="dothraki"
CURRICULUM_LOCALE="dothraki"
```
## Enabling Localized Videos
## ローカライズされた動画を有効にする
For the video challenges, you need to change a few things. First add the new locale to the GraphQL query in the `client/src/templates/Challenges/video/Show.tsx` file. For example, adding Dothraki to the query:
ビデオチャレンジのために、いくつかの変更が必要です。 まず、`client/src/templates/Challenges/video/Show.tsx` ファイルの中の GraphQL クエリに新しいロケールを追加します。 例えば、クエリに Dothraki を追加します。
```tsx
query VideoChallenge($slug: String!) {
@ -151,7 +151,7 @@ For the video challenges, you need to change a few things. First add the new loc
...
```
Then add an id for the new language to any video challenge in an audited block. For example, if `auditedCerts` in `all-langs.ts` includes `scientific-computing-with-python` for `dothraki`, then you must add a `dothraki` entry in `videoLocaleIds`. The frontmatter should then look like this:
次に、監査済みブロック内の任意のビデオチャレンジに新しい言語の id を追加します。 例えば、 `all-langs.ts` 中の `auditedCerts``dothraki``scientific-computing-with-python` が含まれる場合、`videoLocaleIds` に `dothraki` を追加しなければなりません。 フロントマターは次のようになります。
```yml
videoLocaleIds:
@ -163,7 +163,7 @@ dashedName: introduction-why-program
---
```
Update the `VideoLocaleIds` interface in `client/src/redux/prop-types` to include the new language.
`client/src/redux/prop-types``VideoLocaleIds` インターフェースを更新して、新しい言語を入れます。
```ts
export interface VideoLocaleIds {
@ -174,7 +174,7 @@ export interface VideoLocaleIds {
}
```
And finally update the challenge schema in `curriculum/schema/challengeSchema.js`.
そして最後に、`curriculum/schema/challengeSchema.js` のチャレンジスキーマを更新します。
```js
videoLocaleIds: Joi.when('challengeType', {
@ -188,12 +188,12 @@ videoLocaleIds: Joi.when('challengeType', {
}),
```
## Loading Translations
## 翻訳内容を読み込む
Because the language has not been approved for production, our scripts are not automatically downloading the translations yet. Only staff have the access to directly download the translations - you are welcome to reach out to us in our [contributors chat room](https://chat.freecodecamp.org/channel/contributors), or you can translate the English markdown files locally for testing purposes.
言語が本番用に承認されていないため、スクリプトは翻訳を自動的にダウンロードしていません。 スタッフのみ、翻訳を直接ダウンロードすることができます - [contributors チャットルーム](https://chat.freecodecamp.org/channel/contributors) にお問い合わせください。 または、テスト目的で、ローカルで英語のマークダウンファイルを翻訳することもできます。
Once you have the files, you will need to place them in the correct directory. For the curriculum challenges, you should place the certification folders (i.e. `01-responsive-web-design`) within the `curriculum/challenges/{lang}` directory. For our Dothraki translations, this would be `curriculum/challenges/dothraki`. The client translation `.json` files will go in the `client/i18n/locales/{lang}` directory.
ファイルを入手したら、それらを正しいディレクトリに配置する必要があります。 カリキュラムのチャレンジについては、認定講座のフォルダ (すなわち、`01-responsive-web-design`) を `curriculum/challenges/{lang}` ディレクトリ内に配置する必要があります。 Dothraki の翻訳では、これが `curriculum/challenges/dothraki` になります。 クライアント翻訳の `.json` ファイルは、 `client/i18n/locales/{lang}` ディレクトリに移動します。
Once these are in place, you should be able to run `npm run develop` to view your translated version of freeCodeCamp.
以上の準備が整ったら、 `npm run develop` を実行することで freeCodeCamp の翻訳版を表示できるはずです。
> [!ATTENTION] While you may perform translations locally for the purpose of testing, we remind everyone that translations should _not_ be submitted through GitHub and should only be done through Crowdin. Be sure to reset your local codebase after you are done testing.
> [!ATTENTION] テスト目的でローカルで翻訳を実行することもできますが、翻訳は GitHub を介して送信 _するのではなく_、Crowdin を介してのみ送信する必要があることをご承知おきください。 テストが終了したら、必ずローカルコードベースをリセットしてください。

View File

@ -117,84 +117,84 @@ Crowdin はドキュメントを翻訳可能な文字列 (通常は文単位)
> [!NOTE] コントリビューションドキュメントは `docsify` によって提供されており、このようなメッセージボックス用に特別な構文解析機能があります。 `[!NOTE]`、`[!WARNING]` または `[!TIP]` などで始まる文字列を見かけたら、これらの単語は翻訳しないようにしてください。
## Translate the LearnToCode RPG
## LearnToCode RPG の翻訳
The LearnToCode RPG runs on Ren'Py, which uses special syntax for translated strings: (See [Ren'Py Text documentation](https://www.renpy.org/doc/html/text.html))
LearnToCode RPGはRen'Py上で動作します。Ren'Pyでは翻訳の際に独特の構文が使用されます([Ren'Py Text documentation](https://www.renpy.org/doc/html/text.html) を参照してください)。
- The sentences to be translated are always between `""`. These are dialogues or UI strings. The keywords that come before or after the dialogue are game engine control keywords and will be explained in details in subsequent rules. Please note that this first rule governs all subsequent rules listed.
- In case of `new "..."` Do not translate the `new` keyword.
- Prefixes like `player`, `annika`, `layla`, `marco` (or variants like `player happy`, `player @ happy`) should not be translated. These are control keywords to correctly display the character sprite in the game.
- Postfixes like `nointeract` should not be translated.
- Do not translate things between `[]` and `{}`. These are variable interpolations and text tags. These must remain halfwidth parentheses `[]` and `{}` instead of their fullwidth counterparts `【】` and `「」`
- Do not translate the `nointeract` keyword at the end of the sentence.
- If we try to use fullwidth parentheses ``, a QA warning will show. To avoid the QA warning, use halfwidth parentheses `()`
- `" "`で囲まれた文章が翻訳対象です。 ダイアログまたはUIユーザーインターフェース文字列です。 ダイアログの前後に表示されるキーワードは、ゲームエンジンを制御するキーワードです。詳細は後続のルールにて説明します。 このルールは、後続で説明する全ルールの基本であり、最も重要です。
- `new "..."` のように表示される場合、接頭辞 `new` の部分はキーワードなので翻訳しないでください。
- `player`、`annika`、`layla`、`marco` が先頭にて付く用語 (`player happy` や `player @ happy` などの複合形も含む) は、翻訳しないでください。 これらは、ゲーム内のキャラクターのスプライトを正しく表示し制御するためのキーワードです。
- `nointeract` のような接尾辞も翻訳しないでください。
- `[]``{}` で囲まれた部分は翻訳しないでください。 これらは補間機能とテキストタグです。 半角の `[]``{}` は翻訳文章にも残し、全角の `【】``「」`は使用しません。
- 文末の `nointeract` キーワードは翻訳しないでください。
- 全角括弧 `()`を使用しようとすると、品質保証に関する警告が表示されます。 品質保証に関する警告を避けるためには、半角括弧 `()` を使用してください。
### Examples
###
---
#### Before translation
#### 翻訳前
```renpy
# "[player_name]? What a coincidence! Our VIP team member {a=[vip_profile_url]}[player_name]{/a} will be honored to hear that."
"[player_name]? What a coincidence! Our VIP team member {a=[vip_profile_url]}[player_name]{/a} will be honored to hear that." <--- this is the line that needs to be translated. see translation below
"[player_name]? What a coincidence! Our VIP team member {a=[vip_profile_url]}[player_name]{/a} will be honored to hear that." <---
```
#### After translation
#### 翻訳後
```renpy
# "[player_name]? What a coincidence! Our VIP team member {a=[vip_profile_url]}[player_name]{/a} will be honored to hear that."
"[player_name]好巧我们的VIP队友{a=[vip_profile_url]}[player_name]{/a}会很高兴的。"
```
Note: The `[]` and `{}` tags should be left intact.
注: `[]``{}` タグは半角のまま残す必要があります。
---
#### Before translation
#### 翻訳前
```renpy
old "{icon=icon-fast-forward} Skip"
new "{icon=icon-fast-forward} Skip" <-- translate this line, see below
new "{icon=icon-fast-forward} Skip" <--
```
#### After translation
#### 翻訳後
```renpy
old "{icon=icon-fast-forward} Skip"
new "{icon=icon-fast-forward} 跳过"
```
Note: Again, the `new` prefix and the `{icon=icon-fast-forward}` tag should be left intact.
注: 接頭辞 `new``{icon=icon-fast}` タグはそのまま残す必要があります。
---
#### Before translation
#### 翻訳前
```renpy
# layla @ neutral "Hehe, [player_name], you are a fun one. I'm sure you will enjoy your work as a developer."
layla @ neutral "Hehe, [player_name], you are a fun one. I'm sure you will enjoy your work as a developer."
```
#### After translation
#### 翻訳後
```renpy
# layla @ neutral "Hehe, [player_name], you are a fun one. I'm sure you will enjoy your work as a developer."
layla @ neutral "哈哈,[player_name],你真有趣。我相信你一定会喜欢你的开发者工作的。"
```
Note: `layla @ neutral` and `[player_name]` are left unchanged.
注: `layla @ neutral``[player_name]` はそのまま残します。
---
#### Before translation
#### 翻訳前
```renpy
# player "Maybe this is all a dream?" nointeract
player "Maybe this is all a dream?" nointeract
```
#### After translation
#### 翻訳後
```renpy
# player "Maybe this is all a dream?" nointeract
@ -203,71 +203,71 @@ player "也许这都是一场梦?" nointeract
---
### A Note on How Crowdin Segments a Sentence
### Crowdinでは文章をどのように分割するか
Pay attention to how Crowdin segments a line of dialogue wrapped between opening and closing quotes `""`. When we are translating the dialogue, we need to make sure to retain the opening and closing quotes, even if the quotes appear in different segments.
Crowdinでは引用符 (`""`) で囲まれたダイアログ行をどのように分割するのでしょうか。 ダイアログを翻訳する際は、引用符の開始・終了が両方存在することを確認する必要があります。引用符が異なるセグメントに表示されたとしてもです
This is the line to be translated:
以下は翻訳対象の行です。
```renpy
player @ surprised "{b}Full-stack{/b}... What is that? I better take notes so I can learn more about it."
```
Crowdin segments it into three parts like below:
Crowdinは以下のように、3つに分割します。
<img width="836" alt="Screen Shot 2022-01-23 at 10 36 43" src="https://user-images.githubusercontent.com/35674052/150693962-d3b091e5-2432-44d0-9d24-195ea7d7aeda.png" />
<img width="836" alt="スクリーンショット 2022-01-23 (10 36 43)" src="https://user-images.githubusercontent.com/35674052/150693962-d3b091e5-2432-44d0-9d24-195ea7d7aeda.png" />
```renpy
# original
# 原文
player @ surprised "{b}Full-stack{/b}
# translated, keeping the opening quotes `"`
# 訳文。引用符の開始側 `"` は付与したまま
player @ surprised "{b}全栈{/b}
```
<img width="750" alt="Screen Shot 2022-01-23 at 10 36 49" src="https://user-images.githubusercontent.com/35674052/150693965-15411504-791a-4db3-8b14-bc9177be6375.png" />
<img width="750" alt="スクリーンショット 2022-01-23 (10 36 49)" src="https://user-images.githubusercontent.com/35674052/150693965-15411504-791a-4db3-8b14-bc9177be6375.png" />
```renpy
# original
# 原文
What is that?
# translated, no quotes on either side
# 訳文。引用符はなし
这是什么?
```
<img width="857" alt="Screen Shot 2022-01-23 at 10 36 54" src="https://user-images.githubusercontent.com/35674052/150693969-062e3268-580f-4ad2-97db-cab6240b6095.png" />
<img width="857" alt="スクリーンショット 2022-01-23 (10 36 54)" src="https://user-images.githubusercontent.com/35674052/150693969-062e3268-580f-4ad2-97db-cab6240b6095.png" />
```renpy
# original
# 原文
I better take notes so I can learn more about it."
# translated, keeping the closing quotes `"`
# 訳文。引用符の終了側 `"` は付与したまま
我最好做笔记,这样我可以学习更多东西。"
```
## Rate Translations
## 翻訳を評価する
Crowdin allows you to rate the existing proposed translations. If you attempt to save a translation, you may see a message indicating that you cannot save a duplicate translation - this means another contributor has proposed that identical translation. If you agree with that translation, click the `+` button to "upvote" the translation.
Crowdin では既存の翻訳を評価することができます。 翻訳内容を保存しようとした際、同じ内容は保存できないとメッセージが出ることがあります。これは他の投稿者が提案した内容と全く同じであることを意味しています。 既存の翻訳に賛成であれば`+`ボタンを押して賛成票を投じてください。
If you see a translation that is inaccurate or does not provide the same clarity as the original string, click the `-` button to "downvote" the translation.
もし、翻訳が不正確または原文の意味が正しく翻訳されていない既存訳を発見した場合は、`-` ボタンをクリックし反対票を投じて下さい。
Crowdin uses these votes to give a score to each proposed translation for a string, which helps the proofreading team determine which translation is the best fit for each string.
Crowdinはそれらの投票結果を元に各翻訳案の点数を算出し、校正チームがベストの翻訳文を決定する際に参照します。
## Quality Assurance Checks
## 品質保証チェック
We have enabled some quality assurance steps that will verify a translation is as accurate as possible - this helps our proofreaders review proposed translations.
翻訳内容が可能な限り正確であることを確認し、校正チームによる翻訳文レビューに役立てるため、品質保証ステップを設けています。
When you attempt to save a translation, you may see a warning message appear with a notification regarding your proposed translation.
翻訳内容を保存しようとする際、翻訳内容に対する警告文が表示されることがあります。
![Image - QA Warning Message](https://contribute.freecodecamp.org/images/crowdin/qa-message.png)
![画像 - 品質保証に関する警告メッセージ](https://contribute.freecodecamp.org/images/crowdin/qa-message.png)
This message appears when Crowdin's QA system has identified a potential error in the proposed translation. In this example, we have modified the text of a `<code>` tag and Crowdin has caught that.
このメッセージは、Crowdinの品質保証システムが投稿内容に間違いが含まれている可能性があると判断した場合に表示されます。 この例では `<code>` タグ内のテキストが翻訳され、Crowdinがそれを検出しました。
> [!WARNING] エラーが検出されても翻訳内容を保存することは可能です。 「Save Anyway」をクリックして保存できますが、その場合は校正者かプロジェクトマネージャー宛てにコメントし、なぜ品質保証メッセージを無視する必要があったかを説明するようにしてください。
## Translation Best Practices
## 翻訳のベストプラクティス
Follow these guidelines to ensure our translations are as accurate as possible:
翻訳をできる限り正確なものとするため、以下のガイドラインに従って下さい。
- Do not translate the content within `<code>` tags. These tags indicate text that is found in code and should be left in English.
- Do not add additional content. If you feel a challenge requires changes in the text content or additional information, you should propose the changes through a GitHub issue or a pull request that modifies the English file.
- Do not change the order of content.
- `<code>` タグの中身を翻訳しないでください。 これらのタグはコードの一部であり、英語のまま残しておかなければなりません。
- コンテンツを追加しないで下さい。 チャレンジを翻訳する際、テキスト内容の変更や追加の情報が必要だと感じた場合は、GitHub Issue を通して提案するか、提案内容を反映した英語のファイルをプルリクエストして下さい。
- コンテンツの順番を変えないで下さい。
If you have any questions, feel free to reach out to us in our [contributors chat room](https://chat.freecodecamp.org/channel/contributors) and we will be happy to assist you.
質問があれば、[contributors チャットルーム](https://chat.freecodecamp.org/channel/contributors) にてお気軽にお尋ねください。喜んでサポートいたします。

View File

@ -1,15 +1,15 @@
# How to use Docker on Windows Home
# Windows Homeで Docker を使用する方法
There are a few pitfalls to be avoided when setting up Docker on Windows Home. First of all, you have to use [Docker Toolbox](https://docs.docker.com/toolbox/toolbox_install_windows/) as Administrator. Unfortunately Windows Home does not support Docker for Windows Desktop, so Toolbox must be used instead. It has to be run as Administrator as the installation uses symlinks, which cannot be created otherwise.
Windows Home で Docker を設定する際に避けるべき落とし穴がいくつかあります。 まず、[Docker Toolbox](https://docs.docker.com/toolbox/toolbox_install_windows/) を管理者として使用する必要があります。 残念ながら、Windows Home は Docker for Windows Desktop をサポートしていないため、代わりに Toolbox を使用する必要があります。 インストールでシンボリックリンクを使用するため、管理者として実行する必要があります。
Once you've installed the toolbox, run Docker Quickstart Terminal as Administrator. This will create a `default` virtual machine if it does not already exist. Once that has happened, close the terminal and open VirtualBox (again as Administrator). You should be able to see the `default` machine. The site is quite resource-intensive, so stop the virtual machine and raise the settings as much as you can - memory in particular. It has been confirmed to work with 4GB of ram.
Toolbox をインストールしたら、管理者として Docker Quickstart Terminal を実行します。 既存の仮想マシンが存在しない場合は、 `default` 仮想マシンが作成されます その後、ターミナルを閉じて (再び管理者として) VirtualBoxを開きます。 `デフォルト` マシンが表示されます。 サイトはかなりリソースが多いので、仮想マシンを停止し、できるだけメモリの容量を増やしてください。 4GBの RAM で動作することが確認されています。
Once you're happy that Docker is working, clone the freeCodeCamp repository to a directory inside `C:\Users`. These directories are shared giving Docker access to the local directories, which it needs during installation.
Docker が正常に動作していることを確認したら、freeCodeCamp リポジトリを `C:\Users` 内のディレクトリにクローンします。 これらのディレクトリは共有され、インストール中に必要なローカルディレクトリに Docker アクセスを提供します。
If you see messages like
次のようなメッセージが表示される場合
```shell
bash: change_volumes_owner.sh: No such file or directory
```
when you `npm run docker:init` this is likely the culprit.
`npm run docker:init` が原因である可能性があります。

View File

@ -1,52 +1,52 @@
# How to work on coding challenges
# コーディングチャレンジに貢献する方法
Our goal is to develop a fun and clear interactive learning experience.
私たちの目標は、楽しく明確なインタラクティブな学習体験を開発することです。
Designing interactive coding challenges is difficult. It would be much easier to write a lengthy explanation or to create a video tutorial. But for our core curriculum, we're sticking with what works best for most people - a fully interactive, video game-like experience.
インタラクティブなコーディングチャレンジの設計は難しいです。 長い説明を書いたり、ビデオチュートリアルを作成したりする方がはるかに簡単です。 しかし、私たちのコアカリキュラムは、多くの人にとって最適なものに固執しています。完全にインタラクティブでビデオゲームのような体験です。
We want campers to achieve a flow state. We want them to build momentum and blast through our curriculum with as few snags as possible. We want them to go into the projects with confidence and gain a wide exposure to programming concepts.
私たちはキャンパーにフロー状態を体験してほしいのです。 勢いをつけて大きな支障なくカリキュラムを突破してほしいと思っています。 自信を持ってプロジェクトに参加し、プログラミングの概念に広く触れてほしいと考えています。
Note that for Version 7.0 of the freeCodeCamp curriculum, we are moving toward [an entirely project-focused model with a lot more repetition](https://www.freecodecamp.org/news/python-curriculum-is-live/).
freeCodeCamp カリキュラムのバージョン 7.0 では、[多くの繰り返しを伴うプロジェクトに焦点を当てたモデル](https://www.freecodecamp.org/news/python-curriculum-is-live/) に移行していることに注意してください。
Creating these challenges requires immense creativity and attention to detail. There's plenty of help available. You'll have support from a whole team of contributors to whom you can bounce ideas off and demo your challenges.
これらのチャレンジを生み出すには、大きな創造性と細部へのこだわりが必要です。 たくさんの助けを得ることができます。 アイデアを出し合ったりチャレンジを実演したりできる貢献者チーム全体がサポートしてくれます。
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [the contributors chat room](https://chat.freecodecamp.org/channel/contributors).
[フォーラムの「Contributors」カテゴリ](https://forum.freecodecamp.org/c/contributors) または [Contributors チャットルーム](https://chat.freecodecamp.org/channel/contributors) でいつでも気軽に質問してください。
With your help, we can design an interactive coding curriculum that will help millions of people learn to code for years to come.
皆さんのご支援により、今後何百万もの人々がコーディングを学ぶのに役立つインタラクティブなコーディングカリキュラムを設計することができます。
The content for each challenge is stored in its markdown file. This markdown file is later converted to HTML using our tools to create interactive web pages.
各チャレンジのコンテンツは、マークダウンファイルに保存されます。 このマークダウンファイルは、インタラクティブな Web ページを作成するためのツールを使用して、後で HTML に変換されます。
You can find all of freeCodeCamp.org's curricular content in the [`/curriculum/challenges`](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges) directory.
[`/curriculum/challenges`](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges) ディレクトリに、freeCodeCamp.org のカリキュラムコンテンツのすべてがあります。
## Set up the tooling for the curriculum
## カリキュラムのツールを設定する
Before you work on the curriculum, you would need to set up some tooling to help you test your changes. You can use any option from the below:
カリキュラムを作成する前に、変更をテストするためのツールを設定する必要があります。 以下から任意のオプションを使用できます。
- You can [set up freeCodeCamp locally](how-to-setup-freecodecamp-locally.md). This is **highly recommended** for regular/repeat contributions. This setup allows you to work and test your changes.
- Use Gitpod, a free online dev environment. Clicking the button below will start a ready-to-code dev environment for freeCodeCamp in your browser. It only takes a few minutes.
- [freeCodeCampをローカル設定](how-to-setup-freecodecamp-locally.md) することができます。 これは定期的 / 繰り返しの貢献に **強く推奨** します。 このセットアップで、作業と変更テストができます。
- 無料のオンライン開発環境であるGitpodを使用します。 下のボタンをクリックすると、ブラウザで freeCodeCamp のコーディング開発準備ができている環境を起動します。 かかる時間はほんの数分です。
[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
[![Gitpod で開く](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
- Edit the files on GitHub's interface by clicking the pencil icon for the corresponding file. While this is the quickest way, It is **not recommended**, because you are unable to test your changes on GitHub. If our maintainers conclude that the changes you made need to be tested locally, you would need to follow the methods above instead.
- GitHub のインターフェースでファイルを編集するには、該当するファイルの鉛筆アイコンをクリックします。 これが最も速い方法ですが、GitHub 上で変更をテストすることができないため、**お勧めできません**。 もしメンテナーが、行った変更をローカルでテストする必要があると結論づけた場合は、上記の方法で行う必要があります。
### How to work on practice projects
### プラクティスプロジェクトに貢献する方法
The practice projects have some additional tooling to help create new projects and steps. To read more, see [these docs](how-to-work-on-practice-projects.md)
プラクティスプロジェクトには、新しいプロジェクトやステップの作成に役立つ追加ツールがあります。 詳細については、[これらのドキュメント](how-to-work-on-practice-projects.md) をご参照ください。
## Challenge Template
## チャレンジテンプレート
````md
---
id: Unique identifier (alphanumerical, MongoDB_id)
title: 'Challenge Title'
challengeType: Integer, defined in `client/utils/challenge-types.js`
videoUrl: 'url of video explanation'
id: ユニーク ID (アルファベットと数字の MongoDB_id)
title: 'チャレンジのタイトル'
challengeType: `client/utils/challenge-types.js` に定義されている整数
videoUrl: '説明動画のURL'
forumTopicId: 12345
---
# --description--
Challenge description text, in markdown
チャレンジの説明 (マークダウンで記入)
```html
<div>example code</div>
@ -54,17 +54,17 @@ Challenge description text, in markdown
# --instructions--
Challenge instruction text, in markdown
チャレンジの指示内容 (マークダウンで記入)
# --hints--
Tests to run against user code, in pairs of markdown text and code block test code.
ユーザコードに対して実行するテスト。マークダウンテキストと、テストコードのコードブロックをペアにして記入。
```js
Code for test one
```
If you want dynamic output based on the user's code, --fcc-expected-- and --fcc-actual-- will be replaced with the expected and actual values of the test's assertion. Take care if you have multiple assertions since the first failing assertion will determine the values of --fcc-expected-- and --fcc-actual--.
ユーザーのコードに基づいて動的な出力が必要な場合、--fcc-expected-- と --fcc-actual-- は、テストのアサーションの期待値と実際の値に置き換えられます。 最初のアサーションの失敗により --fcc-expected-- と --fcc-actual-- の値が決まるので、複数のアサーションがある場合は注意してください。
```js
assert.equal(
@ -75,25 +75,25 @@ assert.equal(
# --notes--
Extra information for a challenge, in markdown
チャレンジの追加情報 (マークダウンで記入)
# --seed--
## --before-user-code--
```lang
Code evaluated before the users code.
ユーザーコードの前に評価されるコード。
```
## --after-user-code--
```lang
Code evaluated after the users code, and just before the tests
ユーザーコードの後およびテスト直前に評価されるコード。
```
## --seed-contents--
Boilerplate code to render to the editor. This section should only contain code inside backticks, like the following:
エディターにレンダリングするボイラープレートコード。 このセクションには、以下のようなバックティック内のコードのみを含める必要があります。
```html
<body>
@ -118,67 +118,67 @@ console.log('freeCodeCamp is awesome!');
# --solutions--
Solutions are used for the CI tests to ensure that changes to the hints will still pass as intended
ソリューションは、ヒントの変更が意図した通りに合格するようにするために CI テストに使用されます。
```js
// first solution - the language(s) should match the seed.
// 最初のソリューション - 言語はシードに一致する必要があります。
```
---
```js
// second solution - so if the seed is written in HTML...
// 2 番目のソリューション - シードが HTML で書かれている場合...
```
---
```js
// third solution etc. - Your solutions should be in HTML.
// 3番目のソリューション等 - ソリューションは HTML でなければなりません。
```
# --question--
These fields are currently used for the multiple-choice Python challenges.
現在、このフィールドは多肢選択式 Python チャレンジ用に使用されています。
## --text--
The question text goes here.
質問のテキストをここに記述します。
## --answers--
Answer 1
回答 1
---
Answer 2
回答 2
---
More answers
その他回答
## --video-solution--
The number for the correct answer goes here.
正解の番号をここに記述します。
````
> [!NOTE]
>
> 1. In the above sections, examples of `lang` are:
> 1. 上記セクションで、`lang` の例は、次のとおりです。
>
> - `html` - HTML/CSS
> - `js` - JavaScript
> - `jsx` - JSX
## Numbering Challenges
## チャレンジの採番
Every challenge needs an `id`. If you don't specify one, then MongoDB will create a new random one when it saves the data; however, we don't want it to do that, since we want the challenge ids to be consistent across different environments (staging, production, lots of different developers, etc.).
すべてのチャレンジには `id` が必要です。 指定されていない場合、MongoDB はデータを保存する際に新しいランダムな id を作成します。しかしながら、チャレンジ id を異なる環境 (ステージング、本番環境、多くの様々な開発者など) において一貫性のあるものにしたいので、ランダムなものは作成したくありません。
To generate a new one in a shell (assuming MongoDB is running separately):
シェル内で新しい id を生成するには、次のとおり実行します (MongoDB は別途実行されていると仮定)。
1. Run `mongo` command.
2. Run `ObjectId()` command.
1. `mongo` コマンドを実行します。
2. `ObjectId()` コマンドを実行します。
For example:
例:
```bash
$ mongo
@ -190,9 +190,9 @@ $ ObjectId()
ObjectId("5a474d78df58bafeb3535d34")
````
The result is a new id, for example `5a474d78df58bafeb3535d34` above.
その結果、例えば上記の場合 `5a474d78df58bafeb3535d34` という新しい id が得られます。
Once you have your id, put it into the markdown file as the `id` field at the top, e.g.
id を取得したら、上部の `id` フィールドとしてマークダウンファイルに入れてください。例えば、次のようになります。
```yml
---
@ -200,129 +200,129 @@ id: 5a474d78df58bafeb3535d34
title: Challenge Title
```
## Naming challenges
## チャレンジ名の決定
Naming things is hard. We've made it easier by imposing some constraints.
チャレンジ名を決めるのは難しいです。 しかし、いくつかの制約を課すことで簡単になります。
All challenge titles should be explicit and should follow this pattern:
すべてのチャレンジタイトルは明示的でなければなりません。そして、以下のパターンに従う必要があります。
\[verb\]\[object clause\]
\[動詞\]\[目的語 (節)\]
Here are some example challenge names:
チャレンジ名の例を以下に示します。
- Use Clockwise Notation to Specify the Padding of an Element
- Condense arrays with .reduce
- Use Bracket Notation to Find the First Character in a String
## Challenge descriptions/instructions
## チャレンジの説明/指示
Sentences should be clear and concise with minimal jargon. If used, jargon should be immediately defined in plain English.
文章は最小限の専門用語で明確かつ簡潔にする必要があります。 専門用語を使用する場合、平易な英語で定義する必要があります。
Keep paragraphs short (around 1-4 sentences). People are more likely to read several short paragraphs than a wall of text.
段落は短くしてください (1-4 文程度)。 多くの人にとって、長文よりもいくつかの短い段落のほうが読みやすいです。
Challenge text should use the second person ("you") to help to give it a conversational tone. This way the text and instructions seem to speak directly to the camper working through the challenge. Try to avoid using the first person ("I", "we", "let's", and "us").
チャレンジテキストでは、会話調にするために二人称 ("you") を使用する必要があります。 これにより、チャレンジで作業しているキャンパーは、テキストと指示を通して直接話しかけられているように感じます。 一人称 ("I", "we", "let's", and "us") をできるだけ使用しないようにしてください。
Don't use outbound links. These interrupt the flow. Campers should never have to google anything during these challenges. If there are resources you think campers would benefit from, add them to the challenge's Guide-related article.
外部のサイトへのリンクは使用しないでください。 フローの妨げとなります。 チャレンジの間、キャンパーが Google で検索を行う必要がないようにしてください。 キャンパーが利益を得ると思うリソースがある場合は、それらをチャレンジガイド関連記事に追加します。
You can add diagrams if necessary.
必要に応じてダイアグラムを追加できます。
Don't use emojis or emoticons in challenges. freeCodeCamp has a global community, and the cultural meaning of an emoji or emoticon may be different around the world. Also, emojis can render differently on different systems.
チャレンジに絵文字や顔文字を使用しないでください。 freeCodeCamp は、グローバルコミュニティを持っており、絵文字や顔文字の文化的意味は世界中で異なる場合があります。 また、絵文字は異なるシステムでは異なるレンダリングをします。
Proper nouns should use correct capitalization when possible. Below is a list of words as they should appear in the challenges.
固有名詞は、極力正しい大文字表記を使用することが適切です。 以下は、チャレンジで表示される単語のリストです。
- JavaScript (capital letters in "J" and "S" and no abbreviations)
- JavaScript「J」と「S」が大文字、省略形なし
- Node.js
- Although sometimes inaccurate, non-hyphenated forms of 'back end' and 'front end' should be used, as they are more widely used.
- 不正確な場合もありますが、より広く使われているため、ハイフンなしの「back end」と「frond end」を使用します。
### The 2-minute rule
### 2 分ルール
Each challenge should be solvable within 120 seconds by a native English speaker who has completed the challenges leading up to it. This includes the amount of time it takes to read the directions/instructions understand the seeded code, write their code and get all the tests to pass.
各チャレンジは、そこまでのチャレンジを完了した英語のネイティブスピーカーによって 120 秒以内に解決されるべきです。 これには、命令/指示を読み、シードされたコードを理解し、コードを書き、すべてのテストに合格するのにかかる時間が含まれます。
If it takes longer than two minutes to complete the challenge, you have two options:
チャレンジを完了するのに 2 分以上かかる場合は、2 つの選択肢があります。
- Simplify the challenge, or
- Split the challenge into two challenges.
- チャレンジを簡素化する
- チャレンジを 2 つのチャレンジに分ける
The 2-minute rule forces you, the challenge designer, to make your directions concise, your seed code clear, and your tests straight-forward.
2 分ルールにより、命令を簡潔にし、シードコードを明確にし、テストを容易にすることが、チャレンジ設計者に求められます。
We track how long it takes for campers to solve changes and use this information to identify challenges that need to be simplified or split.
キャンパーが変更を解決するまでにかかる時間を追跡し、その情報を使用して簡略化や分割が必要なチャレンジを特定します。
### Modularity
### モジュール化
Each challenge should teach exactly one concept, and that concept should be apparent from the challenge's name.
チャレンジごとに、1 つのコンセプトを教えるべきであり、そのコンセプトはチャレンジ名から明らかであるべきです。
We can reinforce previously covered concepts through repetition and variations - for example, introducing h1 elements in one challenge, then h3 elements a few challenges later.
繰り返しやバリエーションにより、以前学んだコンセプトを強化することができます。例えば、1 つのチャレンジに h1 要素を導入し、いくつかのチャレンジの後に h3 要素を導入します。
Our goal is to have thousands of 2-minute challenges. These can flow together and reiterate previously-covered concepts.
私たちの目標は、数千の 2 分間チャレンジを行うことです。 これらは同じフローであり、以前に網羅されたコンセプトを繰り返すことができます。
### Formatting challenge text
### チャレンジテキストのフォーマット
Here are specific formatting guidelines for challenge text and examples:
チャレンジテキストと例の具体的なフォーマットガイドラインは次のとおりです。
- Language keywords go in `` \` `` backticks. For example, HTML tag names or CSS property names.
- References to code parts (i.e. function, method, or variable names) should be wrapped in `` \` `` backticks. See example below:
- 言語キーワードは `` \` `` のバックティックに入ります。 例えば、HTML タグ名や CSS プロパティ名です。
- コード部品 (すなわち、関数、メソッド、変数名) への参照は、`` \` `` バックティックで囲みます。 下記の例を参照してください。
```md
Use `parseInt` to convert the variable `realNumber` into an integer.
変数 `realNumber` を整数に変換するには、`parseInt` を使用します。
```
- References to file names and path directories (e.g. `package.json`, `src/components`) should be wrapped in `` \` `` backticks.
- Multi-line code blocks **must be preceded by an empty line**. The next line must start with three backticks followed immediately by one of the [supported languages](https://prismjs.com/#supported-languages). To complete the code block, you must start a new line which only has three backticks and **another empty line**. See example below:
- Whitespace matters in Markdown, so we recommend that you make it visible in your editor.
- ファイル名とパスディレクトリへの参照 (例: `package.json`、`src/component`) は `` \` `` バックティックで囲みます。
- 複数行コードブロック **の前に空行** が必要です。 次の行は、3つのバックティックに続いて [対応言語](https://prismjs.com/#supported-languages) の1つで始まります。 コードブロックを完了するには、3 つのバックティックのみの新しい行と **別の空行** が必要です。 下記の例を参照してください。
- 空白はマークダウンでも重要ですので、エディターで表示させることをお勧めします。
**Note:** If you are going to use an example code in YAML, use `yaml` instead of `yml` for the language to the right of the backticks.
**注:** YMAL でコード例を使用する場合、バックティックの右側に言語用の `yml` を使用するのではなく、`yaml` を使用してください。
The following is an example of code:
以下はコードの例です。
````md
```{language}
[YOUR CODE HERE]
[ここに、コードを記述してください]
````
````
- Additional information in the form of a note should be surrounded by blank lines, and formatted: `**Note:** Rest of note text...`
- If multiple notes are needed, then list all of the notes in separate sentences using the format: `**Notes:** First note text. Second note text.`
- Use single-quotes where applicable
- 注意書き形式の追加情報は空白行で囲みます。例: `**注:** 注記のテキスト...`
- 複数の注意書きが必要な場合は、すべての注意書きを別々の文章でリスト化します。例: `**注:** 最初の注記のテキスト。 2 番目の注記のテキスト。`
- 可能であれば、一重引用符を使用します。
**Note:** The equivalent _Markdown_ should be used in place of _HTML_ tags.
**注:** 同等の_マークダウン_は、_HTML_タグの代わりに使用します。
## Writing tests
## テストの記述
Challenges should have the minimum number of tests necessary to verify that a camper understands a concept.
チャレンジには、キャンパーがコンセプトを理解していることを確認するために最小限のテストが必要です。
Our goal is to communicate the single point that the challenge is trying to teach, and test that they have understood that point.
私たちの目標は、チャレンジが教えようとしている単一のポイントを伝え、そのポイントを理解していることをテストすることです。
Challenge tests can make use of the Node.js and Chai.js assertion libraries. Also, if needed, user-generated code can be accessed in the `code` variable. In addition, the `__helpers` object exposes several functions that simplify the process of writing tests. The available functions are defined in _client/src/utils/curriculum-helpers.ts_.
チャレンジテストでは、Node.js と Chai.js アサーションライブラリを使用できます。 また、必要に応じて、`code` 変数からユーザーが生成したコードにアクセスすることもできます。 さらに、 `__helpers` オブジェクトは、テストを記述するプロセスを簡略化するいくつかの関数を公開します。 利用可能な関数は、_client/src/utils/curriculum-helpers.ts_ に定義されています。
## Formatting seed code
## シードコードの書式設定
Here are specific formatting guidelines for the challenge seed code:
チャレンジシードコードの具体的なフォーマットガイドラインは、次のとおりです。
- Use two spaces to indent
- JavaScript statements end with a semicolon
- Use double quotes where applicable
- 2つの空白を使用してインデントする
- JavaScript ステートメントは、セミコロンで終了する
- 適用できる場合は、二重引用符を使用する
### Seed code comments
### シードコードコメント
We have a [comment dictionary](/curriculum/dictionaries/english/comments.js) that contains the only comments that can be used within the seed code. The exact case and spacing of the dictionary comment must be used. The comment dictionary should not be expanded without prior discussion with the dev-team.
[comment dictionary](/curriculum/dictionaries/english/comments.js) は、シードコード内で使用できるコメントのみを含みます。 辞書のコメントに記載されている正確な大文字と小文字の区別および語間を使用します。 コメント辞書は、開発チームとの事前議論なしに増やしてはいけません。
Comments used should have a space between the comment characters and the comment themselves. In general, comments should be used sparingly. Always consider rewriting a challenge's description or instructions if it could avoid using a seed code comment.
使用するコメントは、コメント文字とコメントそのものの間にスペースを入れる必要があります。 一般的に、コメントは控えめに使用します。 シードコードコメントの使用を避けられるのであれば、チャレンジの説明や指示を書き換えることを常に検討してください。
Example of valid single line JavaScript comment:
有効な単一行 JavaScript コメントの例は以下のとおりです。
```js
// Only change code below this line
// この行の下のコードのみ変更する
````
Example of a valid CSS comment:
有効な CSS コメントの例は次のとおりです。
```css
/* Only change code above this line */
```
If a challenge only has a single place where code changes are needed, please use the comments in the following example to instruct the user where changes should be made.
チャレンジに、コード変更が必要な場所が 1 つしかない場合、以下の例のコメントを使用してユーザーに変更を行うべき場所を指示してください。
```js
var a = 3;
@ -335,7 +335,7 @@ b = 9 + b;
c = c + 7;
```
If a challenge has multiple places where the user is expected to change code (i.e. the React challenges)
チャレンジに、ユーザがコード変更を行うべき場所が複数存在する場合 (例: React のチャレンジ) は、次のようになります。
```jsx
class MyComponent extends React.Component {
@ -344,9 +344,9 @@ class MyComponent extends React.Component {
this.state = {
text: 'Hello'
};
// Change code below this line
// この行より下にあるコードを変更してください。
// Change code above this line
// この行より上にあるコードを変更してください。
}
handleClick() {
this.setState({
@ -366,68 +366,68 @@ class MyComponent extends React.Component {
}
```
### Translation of seed code comments
### シードコードコメントの翻訳
There are separate comment dictionaries for each language. The [English version of the comment dictionary](/curriculum/dictionaries/english/comments.js) is the basis for the translations found in the corresponding non-English versions of the files. The non-English version of the Chinese comment dictionary would be located at `/curriculum/dictionaries/chinese/comments.js`. Each dictionary consists of an array of objects with a unique `id` property and a `text` property. Only the `text` should be modified to encompass the translation of the corresponding English comment.
各言語には、個別のコメント辞書があります。 [コメント辞書の英語版](/curriculum/dictionaries/english/comments.js) は、英語以外のバージョンファイルにある翻訳のベースになります。 英語以外のバージョンである中国語のコメント辞書は、`/curriculum/dictionaries/chinese/comments.js`にあります。 それぞれの辞書は一意の `id` プロパティと `text` プロパティを持つオブジェクトの配列で構成されています。 `text` のみ、対応する英語のコメントの翻訳を含むように変更する必要があります。
Some comments may contain a word/phrase that should not be translated. For example, variable names or proper library names like "React" should not be translated. See the comment below as an example. The word `myGlobal` should not be translated.
一部のコメントには、翻訳してはいけない単語 / フレーズが含まれています。 例えば、変数名や「React」のような固有ライブラリ名は翻訳しません。 例として以下のコメントをご覧ください。 `myGlobal` という単語は翻訳しません。
```text
Declare the myGlobal variable below this line
この行の下に myGlobal 変数を宣言してください。
```
> [!NOTE]
>
> We are working on an integration to make it possible to work on i18n for the comment dictionary.
> コメント辞書の i18n で作業できるようにするために統合に取り組んでいます。
## Hints and Solutions
## ヒントとソリューション
Each challenge has a `Get a Hint` button, so a user can access any hints/solutions which have been created for the challenge. Curriculum hints/solutions topics are located on [our forum](https://forum.freecodecamp.org/c/guide) under the `Guide` category.
各チャレンジには `Get a Hing` ボタンがあり、ユーザーはチャレンジ用に作成されたヒント / ソリューションにアクセスできます。 カリキュラムヒント/ソリューショントピックは、`Guide` カテゴリの下の [フォーラム](https://forum.freecodecamp.org/c/guide) にあります。
If you find a problem with an existing challenge's hints/solutions topic, you can make suggestions in the [contributors category](https://forum.freecodecamp.org/c/contributors) on the forum. Moderators and users with trust level 3 will review the comments and decide whether or not to include the changes in the corresponding hint/solutions topic.
既存のチャレンジのヒント/ソリューショントピックに関わる問題がある場合は、フォーラムの [contributors カテゴリ](https://forum.freecodecamp.org/c/contributors) で提案を行うことができます。 信頼レベル 3 のモデレーターとユーザーは、コメントをレビューし、対応するヒント/ソリューションのトピックに変更を含めるかどうかを決定します。
### Adding new Challenge hints/solutions Topics
### 新しいチャレンジのヒント / ソリューションの追加
Take the following steps when adding a new challenge hints/solutions related topic.
新しいチャレンジのヒント/ソリューション関連トピックを追加する場合は、次の手順を実行します。
1. Start by following the same steps for creating a new topic but review the next for creating the title.
2. The title of the topic should start with `freeCodeCamp Challenge Guide:` concatenated with the actual title of the curriculum challenge. For example, if the challenge is named "`Chunky Monkey`", the topic title would be "`freeCodeCamp Challenge Guide: Chunky Monkey`".
3. `camperbot` should be the owner of these topics/posts, so you will need to request an admin to change the ownership of the main post to `camperbot`.
4. Once the new topic is created, a forum topic id is created. It is located at the end of the forum topic URL. This id must be added to the frontmatter of the curriculum challenge file via the normal pull request process for the `Get a Hint` button to link to the topic.
1. 新しいトピックの作成と同じ手順からスタートします。タイトルを作成するために以下を確認します。
2. トピックのタイトルは、`freeCodeCamp チャレンジガイド:` にカリキュラムチャレンジの実際のタイトルを連結します。 例えば、チャレンジに「`Chunky Monkey`」という名前が付けられている場合、トピックのタイトルは、「`freeCodeCamp Challenge Guide: Chunky Monkey`」になります。
3. `camperbot` はトピック / 投稿のオーナーである必要があるので、管理者に、メイン投稿のオーナーを `camperbot` に変更するようにリクエストします。
4. 新しいトピックを作成すると、フォーラムのトピック id が作成されます。 これは、フォーラムのトピック URL の末尾にあります。 この id は、トピックにリンクするために、`ヒントを入手` ボタン用の標準プルリクエストプロセスを介して、カリキュラムチャレンジファイルのフロントマターに追加する必要があります。
### Guidelines for content of hints and solutions topics
### ヒントとソリューショントピックの内容に関するガイドライン
When proposing a solution for a curriculum challenge related Guide topic, the full code must be added. This includes all the original seed code plus any changes needed to pass all the challenge tests. The following template should be used when creating new hints/solutions topics:
カリキュラムチャレンジに関連するガイドトピックのソリューションを提案する場合は、完全なコードを追加する必要があります。 これには、すべての元のシードコードと、すべてのチャレンジテストに合格するために必要な変更が含まれています。 次のテンプレートは、新しいヒント/ソリューションのトピックを作成する際に使用する必要があります。
````md
# Challenge Name Goes Here
# ここにチャレンジ名を記述する
---
## Problem Explanation
## 問題説明
This summarizes what needs to be done without just restating the challenge description and/or instructions. This is an optional section
チャレンジの説明や指示を再記述するのではなく、実行すべきことを要約します。 ここは任意のセクションです。
#### Relevant Links
#### 関連リンク
- [Link Text](link_url_goes_here)
- [Link Text](link_url_goes_here)
- [リンクテキスト](link_url_goes_here)
- [リンクテキスト](link_url_goes_here)
---
## Hints
## ヒント
### Hint 1
### ヒント 1
Hint goes here
ヒントを記述してください
### Hint 2
### ヒント 2
Hint goes here
ヒントを記述してください
---
## Solutions
## ソリューション
<details><summary>Solution 1 (Click to Show/Hide)</summary>
@ -437,30 +437,30 @@ function myFunc() {
}
````
#### Code Explanation
#### コードの説明
- Code explanation goes here
- Code explanation goes here
- コードの説明はこちら
- コードの説明はこちら
#### Relevant Links
#### 関連リンク
- [Link Text](link_url_goes_here)
- [Link Text](link_url_goes_here)
- [リンクテキスト](link_url_goes_here)
- [リンクテキスト](link_url_goes_here)
</details>
````
## Testing Challenges
## チャレンジのテスト
Before you [create a pull request](how-to-open-a-pull-request.md) for your changes, you need to validate that the changes you have made do not inadvertently cause problems with the challenge.
変更のために [プルリクエストを作成する] (how-to-open-a-pull-request.md) 前に、行った変更が誤ってチャレンジに問題を引き起こさないことを確認する必要があります。
1. To test all challenges run the below command from the root directory
1. すべてのチャレンジをテストするには、ルートディレクトリから以下のコマンドを実行してください。
````
npm run test:curriculum
```
2. You can also test a block or a superblock of challenges with these commands
2. 次のコマンドでチャレンジのブロックやスーパーブロックをテストすることもできます。
```
npm run test:curriculum --block='Basic HTML and HTML5'
@ -470,29 +470,29 @@ npm run test:curriculum --block='Basic HTML and HTML5'
npm run test:curriculum --superblock=responsive-web-design
```
You are also able to test one challenge individually by performing the following steps:
次の手順を実行することで、1 つのチャレンジを個別にテストすることもできます。
1. Switch to the `curriculum` directory:
1. `カリキュラム` ディレクトリに切り替えてください。
```
cd curriculum
```
2. Run the following for each challenge file for which you have changed (replacing `challenge-title-goes-here` with the full title of the challenge):
2. 変更したチャレンジファイルごとに以下を実行します ( `challenge-title-goes-here` を正式なチャレンジのタイトルに置き換えてください)。
```
npm run test -- -g challenge-title-goes-here ```
Once you have verified that each challenge you've worked on passes the tests, [please create a pull request](how-to-open-a-pull-request.md).
各チャレンジがテストに合格したことを確認したら、[プルリクエストを作成](how-to-open-a-pull-request.md) してください。
> [!TIP] You can set the environment variable `LOCALE` in the `.env` to the language of the challenge(s) you need to test.
> [!TIP] `.env` にある環境変数 `LOCALE` を、テストするチャレンジ言語に設定できます。
>
> The currently accepted values are `english` and `chinese`, with `english` being set by default.
> 現在受け入れられている値は、`english` と `chinese`で、デフォルトは `english` です。
### Useful Links
### 役立つリンク
Creating and Editing Challenges:
チャレンジの作成および編集
1. [Challenge types](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/client/utils/challenge-types.js#L1-L13) - what the numeric challenge type values mean (enum).
1. [チャレンジタイプ](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/client/utils/challenge-types.js#L1-L13) - 数値チャレンジ型の値が何を意味するのか (列挙)
2. [Contributing to FreeCodeCamp - Writing ES6 Challenge Tests](https://www.youtube.com/watch?v=iOdD84OSfAE#t=2h49m55s) - a video following [Ethan Arrowood](https://twitter.com/ArrowoodTech) as he contributes to the old version of the curriculum.
2. [FreeCodeCampへの貢献 - ES6 Challenge Tests の作成](https://www.youtube.com/watch?v=iOdD84OSfAE#t=2h49m55s) - 古いバージョンのカリキュラムに貢献している [Ethan Arrowood](https://twitter.com/ArrowoodTech) のビデオ

View File

@ -1,20 +1,20 @@
# How to work on localized client webapp
# ローカライズされたクライアント Web アプリに貢献する方法
The react based client web app that powers our learning platform is built using Gatsby. It is translated into various world languages using [react-i18next](https://react.i18next.com/) and [i18next](https://www.i18next.com/).
学習プラットフォームを動かす React ベースのクライアント Web アプリは、Gatsby を使用して構築されています。 [react-i18next](https://react.i18next.com/) と [i18next](https://www.i18next.com/) を使用して、様々な世界の言語に翻訳されています。
You can learn more about setting up the client application locally for development by following [our local setup guide here](how-to-setup-freecodecamp-locally.md). By default the application is available only in English.
開発用クライアントアプリケーションのローカル設定については、こちらの [ローカル設定ガイド](how-to-setup-freecodecamp-locally.md)をご覧ください。 デフォルトでは、アプリケーションは英語でのみ使用できます。
Once you have setup the project locally you should be able to follow this documentation to run the client in the language of your choice from the list of available languages.
ローカルでプロジェクトを設定したら、利用可能な言語リストから選択した言語でクライアントを実行するために、このドキュメントに従ってください。
This could be helpful when you are working on a feature that specifically targets something that involves localization, and requires you to validate for instance a button's label in a different language.
これは、ローカライゼーションを含むものを対象にし、例えば別の言語でボタンラベルを検証する必要がある機能に関して作業している場合に役立ちます。
> [!TIP] You do not need to follow this document for translating freeCodeCamp's curriculum or contributing documentation. Read [this guide here](how-to-translate-files.md) instead.
> [!TIP] freeCodeCamp のカリキュラムを翻訳したりドキュメントに貢献したりするために、このドキュメントに従う必要はありません。 代わりに、[このガイド](how-to-translate-files.md) をお読みください。
Let's understand how the i18n frameworks and tooling work.
i18n フレームワークとツールがどのように機能するかを理解しましょう。
## File Structure
## ファイル構成
Most of files for translating the platform are located in the [`client/i18n`](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/client/i18n) folder. Each language has a directory within that containing JSON files with the translations.
プラットフォームを翻訳するために必要なファイルの多くは、[`client/i18n`](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/client/i18n) フォルダに入っています。 各言語には、翻訳付きの JSON ファイルを含むディレクトリがあります。
```console
config/i18n
@ -59,29 +59,29 @@ Most of files for translating the platform are located in the [`client/i18n`](ht
└── validate-keys.ts
```
Some of these files are translated on our translation platform (Crowdin), some are not.
これらのファイルは翻訳プラットフォーム (Crowdin) で翻訳されていますが、翻訳されていないものもあります。
**Files translated on our translation platform:**
**翻訳プラットフォーム上で翻訳されたファイル:**
- The `translations.json` file contains the majority of the text that appears on the user interface elements. The keys are used in the codebase to get the correct text for whatever language is set. This file needs to have the exact same keys in all languages.
- `translations.json` ファイルは、ユーザーインターフェース要素に表示されるテキストの大部分を含んでいます。 キーは、設定されるすべての言語で正しいテキストが取得できるように、コードベースで使用されます。 このファイルでは、すべての言語で同じキーが必要です。
- The `intro.json` file contains the key-value pairs for the introduction text on the certification pages.
- `intro.json` ファイルには、認定講座ページの紹介テキスト用に、キーと値のペアが含まれています。
If you want to add/update translations for the keys please [read this guide here](how-to-translate-files.md).
キーの翻訳を追加 / 更新したい場合は、[こちらのガイド](how-to-translate-files.md) をご覧ください。
**Files NOT translated on our translations platform:**
**翻訳プラットフォーム上で翻訳されていないファイル:**
- The `motivation.json` files are not required to have the same quotes, compliments, or array length. Just the same JSON structure.
- `motivation.json` ファイルは、同じ引用符、賛辞、配列の長さを含む必要はありません。 JSON 構造だけは同じです。
- The `trending.json` file contains the titles and links for the trending news articles in the website's footer.
- `trending.json` ファイルは、Web サイトのフッターにトレンドニュース記事のタイトルとリンクを含みます。
- The `meta-tags.json` file contains the information for our website's meta tag information.
- `meta-tags.json` ファイルには、Web サイトのメタタグ情報に関する情報が含まれています。
Changes to these files are typically done by the staff team. If you see something out of the ordinary we recommend you reach us in the [contributors chat room](https://chat.freecodecamp.org/channel/contributors).
これらのファイルの変更は通常、スタッフチームによって行われます。 異常が表示された場合は、[contributors チャットルーム](https://chat.freecodecamp.org/channel/contributors) に連絡することをお勧めします。
## Testing the client app in a world language
## 世界の言語でクライアントアプリをテストする
You can test the client app in any language available in the [list of languages here](https://github.com/freeCodeCamp/freeCodeCamp/blob/6b4a6a02568b809fc216ea8566ff5df446d1da4e/config/i18n/all-langs.js#L5).
クライアントアプリは、[言語リスト](https://github.com/freeCodeCamp/freeCodeCamp/blob/6b4a6a02568b809fc216ea8566ff5df446d1da4e/config/i18n/all-langs.js#L5) にある言語でテストできます。
```js
const availableLangs = {
@ -90,19 +90,19 @@ You can test the client app in any language available in the [list of languages
};
```
If you are testing a new language, create a folder with the language name as the title next to the other languages and copy the JSON files from another language into your new folder.
新しい言語をテストするには、言語名をタイトルとしたフォルダを他の言語の隣に作成し、JSON ファイルを別の言語から新しいフォルダにコピーします。
Add the language to the `client` array as seen above in the [`config/i18n/all-langs.js`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/config/i18n/all-langs.js) file.
上記の [`config/i18n/all-langs.js`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/config/i18n/all-langs.js) ファイルにあるように、`client` 配列に言語を追加します。
Next, follow the instructions in the comments in the same file to add/update the rest of the variables as needed.
次に、同じファイルのコメント指示に従って、必要に応じて残りの変数を追加 / 更新します。
Finally, set the `CLIENT_LOCALE` variable in your `.env` file to the locale you want to build and you're ready.
最後に、`.env` ファイルの `CLIENT_LOCALE` 変数を、ビルドするロケールに設定します。これで準備が整います。
## How to Structure Components
## コンポーネントの構築方法
If you are working on a feature or a bug for the client web app, say for example adding new UI items on the settings page, you should follow the guidelines below. They will help you prepare the components for localization into all the supported world languages.
クライアント Web アプリの機能やバグの作業をしていて、例えば、設定ページに新しい UI アイテムを追加する場合は、以下のガイドラインに従ってください。 これらは、サポートされている世界言語へのローカライゼーションで、コンポーネントを準備するのに役立ちます。
### Functional Component
### 関数コンポーネント
```js
import { useTranslation } from 'react-i18next';
@ -114,7 +114,7 @@ const { t } = useTranslation();
<p>{t('key')}</p>; // more details below
```
### Class Component
### クラスコンポーネント
```js
import { withTranslation } from 'react-i18next';
@ -132,9 +132,9 @@ export default withTranslation()(Component);
export default connect(...)(withTranslation()(Component));
```
## Translate Using the "t" Function
## 「t」関数を使って翻訳する
### Basic Translation
### 基本的な翻訳
```js
// in the component:
@ -149,7 +149,7 @@ export default connect(...)(withTranslation()(Component));
<p>My paragraph</p>
```
### With Dynamic Data
### 動的データの使用
```js
// in the component:
@ -166,13 +166,13 @@ const username = 'moT';
<p>Welcome moT</p>
```
The above example passes an object to the `t` function with a `username` variable. The variable will be used in the JSON value where `{{username}}` is.
上の例では、 `username` 変数を使用して `t` 関数にオブジェクトを渡します。 変数は、`{{username}}` の JSON 値で使用されます。
## Translate with the `Trans` Component
## `Trans` コンポーネントを使用した翻訳
The general rule is to use the "t" function when you can. But there's a `Trans` component for when that isn't enough, usually when you have elements embedded in the text. You can use the `Trans` component with any type of react component.
一般的なルールは、「t」関数を使うことです。 しかし、それだけでは不十分な場合のための `Trans` コンポーネントがあります。通常、テキストに要素が埋め込まれている場合に使用されます。 どんな型の React コンポーネントでも `Trans` コンポーネントを使用できます。
### Basic Elements Nested
### ネストされた基本要素
```js
// in the component:
@ -193,11 +193,11 @@ import { Trans } from 'react-i18next'
<p>Welcome to <strong>freeCodeCamp</strong></p>
```
You can place the key inside the component tags like the above example if the text contains "simple" tags with no attributes. `br`, `strong`, `i`, and `p` are the default, but that list can be expanded in the i18n config.
上記の例のように、テキストが属性のない「単純な」タグを含む場合、キーをコンポーネントタグの中に置くことができます。 `br`、`strong`、`i`、および `p` がデフォルトですが、そのリストは、i18n config で拡張できます。
### Complex Elements Nested
### ネストされた複雑な要素
Other times, you will want to have certain text inside another element, an anchor tag is a good example:
別の要素内に特定のテキストを持たせたい場合、アンカータグが良い例です。
```js
// in the component:
@ -216,9 +216,9 @@ Other times, you will want to have certain text inside another element, an ancho
<p>Check out <a href='https://forum.freecodecamp.org/'>our forum</a></p>
```
In the above example, the key is set in the attributes of the `Trans` component. The `<0>` and `</0>` in the JSON represent the first child of the component, in this case, the anchor element. If there were more children, they would just count up from there using the same syntax. You can find the children of a component in the react dev tools by inspecting it. `placeholder` is simply there because the linter complains about empty `<a>` elements.
上記の例では、キーは `Trans` コンポーネントの属性に設定されています。 JSON の `<0>``</0>` はコンポーネントの最初の子を表します。 この場合、アンカー要素です。 もっと多くの子供がいたら、同じ構文を使ってそこから数えるだけです。 検査により、React 開発ツールでコンポーネントの子供を見つけることができます。 `placeholder` は単にそこにあるだけです。なぜなら、リンターが空の `<a>` 要素について不平を言うからです。
### With a Variable
### 変数の使用
```js
// in the component:
@ -243,25 +243,25 @@ const email = 'team@freecodecamp.org';
<p>Send us an email at: <a href='mailto:team@freecodecamp.org'>team@freecodecamp.org</a><p>
```
In the above example, the key and a variable are set in the attributes of the `Trans` component. `{{ email }}` needs to be somewhere in the `Trans` component as well, it doesn't matter where.
上記の例では、キーと変数は `Trans` コンポーネントの属性に設定されています。 `{{ email }}` は、`Trans` コンポーネントのどこかにある必要がありますが、どこであっても問題はありません。
## Changing Text
## テキストの変更
To change text on the client side of things, go to the relevant `.json` file, find the key that is being used in the React component, and change the value to the new text you want. You should search the codebase for that key to make sure it isn't being used elsewhere. Or, if it is, that the changes make sense in all places.
クライアント側でテキストを変更するには、関連する `.json ` ファイルで、React コンポーネントで使用されているキーを見つけて、値を新しいテキストに変更します。 そのキーが他の場所で使用されていないことを確認するために、コードベースを検索する必要があります。 他の場所で使用されていた場合、そのすべての場所で変更が実行されます。
## Adding Text
## テキストの追加
If the text you want to add to the client exists in the relevant `.json` file, use the existing key. Otherwise, create a new key.
クライアントに追加するテキストが、関連する `.json` ファイルに存在する場合は、既存のキーを使用します。 それ以外の場合は、新しいキーを作成します。
The English file is the "source of truth" for all of the `.json` files sharing the same name. If you need to add a new key, add it there. Then, add the key to **all** of the `translations.json` files.
英語ファイルは、同じ名前を共有する `.json` ファイルすべてにとって、「真実を語る資料」です。 新しいキーを追加する必要がある場合は、そこに追加します。 そして、そのキーを **すべて** の `translations.json` ファイルに追加します。
> [!NOTE] Use English text for all languages if the file is translated through Crowdin. The tests will fail if you don't.
> [!NOTE] ファイルが Crowdin で翻訳されている場合は、すべての言語に英語のテキストを使用してください。 そうしないと、テストは失敗します。
It would be nice to keep the keys in the same order across all the files as well. Also, try to put all punctuation, spacing, quotes, etc in the JSON files and not in the components or server files.
すべてのファイルで、キーを同じ順序に保つことをお勧めします。 また、コンポーネントやサーバーファイルではなくJSON ファイルに、すべての句読点、スペース、引用符などを 入れるようにしてください。
> [!NOTE] The underscore (`_`) is a reserved character for keys in the client side files. See [the documentation](https://www.i18next.com/translation-function/plurals) for how they are used.
> [!NOTE] アンダースコア (`_`) は、クライアント側ファイルのキー用予約文字です。 使用方法については、 [ドキュメント](https://www.i18next.com/translation-function/plurals) を参照してください。
## Helpful Documentation
## 参考ドキュメント
- [react-i18next docs](https://react.i18next.com/latest/usetranslation-hook)
- [i18next docs](https://www.i18next.com/translation-function/essentials)

View File

@ -1,78 +1,78 @@
# How to Work on Practice Projects
# プラクティスプロジェクトに貢献する
The `tools/challenge-helper-scripts` folder contains tools to help facilitate the creation and maintenance of the freeCodeCamp project-based curriculum.
`tools/challenge-helper-scripts` フォルダには、freeCodeCamp プロジェクトベースのカリキュラムの作成とメンテナンスを容易にするためのツールが含まれています。
## Create a new project
## 新規プロジェクトを作成する
Run `npm run create-project`. This opens up a command line ui that guides you through the process. Once that has finished, there should be a new challenge in the English curriculum that you can use for the first step of the project. For example, if you created a project called `test-project` in the Responsive Web Design certification, it would be in `curriculum/challenges/english/01-responsive-web-design/test-project`.
`npm run create-project` を実行します。 これにより、プロセスをガイドするコマンドライン UI が開きます。 そうすると、英語のカリキュラムに新しいチャレンジがあるはずですので、プロジェクトの最初のステップに使用できます。 例えば、レスポンシブ Web デザイン認定講座で `test-project` というプロジェクトを作成した場合、`curriculum/challenges/english/01-responsive-web-design/test-project` になります。
If you want to create new steps, the following tools simplify that process.
新しいステップを作成したい場合は、以下のツールでそのプロセスを簡素化できます。
## create-next-step
## 次のステップを作成する
A one-off script that will automatically add the next step based on the last step numbered as `step-xxx.md` where `xxx` represents the 3-digit step number of the last step. The challenge seed code will use the previous step's challenge seed code with the editable region markers (ERMs) removed.
一時スクリプトにより `step-xxx.md` と付番される最後のステップに基づいて、次のステップを自動的に追加します。`xxx` は最後のステップの 3 桁のステップ数を表します。 チャレンジシードコードは、前のステップのチャレンジシードコードを使用します。このシードコードでは編集可能なリージョンマーカー(ERM) が削除されています。
**Note:** This script also runs [reorder-steps](#reorder-steps).
**注: ** このスクリプトは [ステップの並べ替え](#reorder-steps) も実行します。
### How to run script:
### スクリプトを実行する方法
1. Change to the directory of the project.
2. Run the following npm command:
1. プロジェクトのディレクトリに変更します。
2. 以下の npm コマンドを実行します。
```bash
npm run create-next-step
```
## create-empty-steps
## 空のステップを作成する
A one-off script that automatically adds a specified number of steps at a specific starting step number. The challenge seed code for all steps created will be empty.
一時スクリプトにより、特定の開始ステップ番号に指定されたステップ数を自動的に追加します。 作成された全ステップのチャレンジシードコードは空になります。
**Note:** This script also runs [reorder-steps](#reorder-steps).
**注: ** このスクリプトは [ステップの並べ替え](#reorder-steps) も実行します。
### How to run script:
### スクリプトを実行する方法
1. Change to the directory of the project.
2. Run the following npm command:
1. プロジェクトのディレクトリに変更します。
2. 以下の npm コマンドを実行します。
```bash
npm run create-empty-steps start=X num=Y # where X is the starting step number and Y is the number of steps to create.
```
## create-step-between
## 中間ステップを作成する
A one-off script that automatically adds a new step between two existing consecutive steps. The challenge seed code will use the existing starting step's challenge seed code with the editable region markers (ERMs) removed.
一時スクリプトにより、 2 つの既存の連続したステップの間に自動的に新しいステップを追加します。 チャレンジシードコードは、既存の開始ステップのチャレンジシードコードを使用します。このシードコードでは編集可能なリージョンマーカー(ERM) が削除されています。
**Note:** This script also runs [reorder-steps](#reorder-steps).
**注: ** このスクリプトは [ステップの並べ替え](#reorder-steps) も実行します。
### How to run script:
### スクリプトを実行する方法
1. Change to the directory of the project.
2. Run the following npm command:
1. プロジェクトのディレクトリに変更します。
2. 以下の npm コマンドを実行します。
```bash
npm run create-step-between start=X # where X is the starting step number
```
## delete-step
## ステップを削除する
A one-off script that deletes an existing step and then reorders the remaining step files in the project's folder as well as updates the `challengeOrder` property array in the project's `meta.json` with the new order of the steps.
一時スクリプトにより、既存のステップを削除して、プロジェクトフォルダー内の残りのステップファイルを並べ替えるます。また、プロジェクトの `meta.json` 内の `challengeOrder` プロパティ配列を、新しいステップ順序で更新します。
### How to run script
### スクリプトを実行する方法
1. Change to the directory of the project.
2. Run the following npm command:
1. プロジェクトのディレクトリに変更します。
2. 以下の npm コマンドを実行します。
```bash
npm run delete-step num=x # where x is the step number to be deleted.
```
## reorder-steps
## ステップを並べ替える
A one-off script that automatically reorders the step files in a project's markdown files based on the filename. It also updates the `challengeOrder` property array in the project's `meta.json` with the new order of the steps.
一時スクリプトにより、ファイル名に基づいて、プロジェクトのマークダウンファイル内のステップファイルを自動的に並べ替えます。 また、プロジェクトの `meta.json` 内の `challengeOrder` プロパティ配列を、新しいステップ順序で更新します。
### Working Example
### 作業例
Let's say you start with the following project structure:
例えば、次のプロジェクト構造から始めるとします。
```bash
step-001.md
@ -83,9 +83,9 @@ step-005.md
step-006.md
```
At some point you decide you need to delete `step-002.md`, because that step is no longer needed. Also, you decide to break down `step-004.md` into three steps instead of just one.
ある時点で、ステップが不要になったため `step-002.md` を削除する必要があると判断します。 また、`step-004.md` を 1 つではなく 3 つのステップに分解することにします。
To accomplish this restructure, you would need to delete `step-002.md` and then add a `step-004a.md` and a `step-004b.md`. The new folder structure would look like the following:
この構造を再構築するには、`step-002.md` を削除し、 `step-004a.md``step-004b.md` を追加する必要があります。 新しいフォルダ構造は次のようになります。
```bash
step-001.md
@ -97,9 +97,9 @@ step-005.md
step-006.md
```
You now need the file names to be `step-001.md` through `step-007.md`, because you removed one but gained two more for a net difference of one file. Also, the frontmatter of each file below a deleted step or added step will need to be modified by making the `title` key value match the new step number. For example, after renaming `step-3.md` to `step-2.md`, you would need to change `step-2.md`'s title from `Step 03` to `Step 02`.
ここで、ファイル名は `step-001.md` から `step-007.md` である必要があります。これは、1 つ削除して、2つ追加したので、正味差は1ファイルだからです。 また、削除されたステップまたは追加されたステップの各ファイルの Frontmatterは、`title` キー値を新しいステップ数と一致させた上で変更する必要があります。 例えば、`step-3.md` を `step-2.md` に変更した後、 `step-2.md` のタイトルを `Step 03` から `Step 02` へ変更する必要があります。
See below for the actual project folder changes needed:
以下は、実際のプロジェクトフォルダの変更です。
```bash
step-001.md
@ -111,12 +111,12 @@ step-005.md renames to step-006.md and title changes to "Step 6"
step-006.md renames to step-007.md and title changes to "Step 7"
```
Along with the above changes, the `challengeOrder` key in the project's `meta.json` file needs to reflect the new step order. This is needed because each step below a step deletion and/or step addition changes the `title` associated with each of the affected step's challenge `id`.
上記の変更に伴い、プロジェクトの `meta.json` ファイル内の `challengeOrder` キーは、新しいステップの順序を反映する必要があります。 これは、ステップの削除や追加に伴い、その下にある各ステップが、影響を受けるステップのチャレンジ `id` に関連する `title` を変更するためです。
### How to run script
### スクリプトを実行する方法
1. Change to the directory of the project.
2. Run the following npm command:
1. プロジェクトのディレクトリに変更します。
2. 以下の npm コマンドを実行します。
```bash
npm run reorder-steps

View File

@ -1,54 +1,54 @@
# How to work on the docs theme
# ドキュメントテーマでの作業方法
> [!NOTE] A quick reminder that you do not need to setup anything for working on the content for the documentation site.
> [!NOTE] ドキュメントサイトのコンテンツでの作業に必要な設定は何もありません。
>
> To work on the contributing guidelines, you can edit or add files in the `docs` directory [available here](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/docs). When your changes are merged, it will be made available automatically at the documentation site.
> 貢献するガイドラインで作業するには、`docs` [ディレクトリ](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/docs) でファイルを編集または追加します。 変更がマージされると、ドキュメントサイトで自動的に利用可能になります。
## Structure of the docs website
## ドキュメント Web サイトの構造
The site is generated using [`docsify`](https://docsify.js.org), and served using GitHub pages.
サイトは [`docsify`](https://docsify.js.org) を使用して生成され、GitHub ページを使用して提供されます。
Typically you would not need to change any configuration or build the site locally. In case you are interested, here is how it works:
通常、サイトの設定を変更したり、サイトをローカルにビルドしたりする必要はありません。 以下のように動作します。
- The homepage's source for this site is available in [`docs/index.html`](index.html).
- We serve this file as a SPA using `docsify` and GitHub Pages.
- The `docsify` script generates the content of `markdown` files in `docs` directory on demand.
- The homepage is generated from the [`_coverpage.md`](_coverpage.md).
- the sidebar navigation is generated from [`_sidebar.md`](_sidebar.md).
- このサイト向けのホームページのソースは、[`docs/index.html`](index.html) にあります。
- `docsify` と GitHub Pages を使用して、このファイルを SPA として提供します。
- `docsify` スクリプトは、`docs` ディレクトリ内の `markdown` ファイルの内容を必要に応じて生成します。
- ホームページは [`_coverpage.md`](_coverpage.md) から生成されます。
- サイドバーナビゲーションは [`_sidebar.md`](_sidebar.md) から生成されます。
## Serving the documentation site locally
## ローカルでドキュメントサイトを提供する
Clone freeCodeCamp:
freeCodeCamp をクローンする
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
docsify serve docs
```
Install `docsify`:
`docsify` をインストールする
```console
npm install -g docsify
```
and serve the `/docs` directory
`/docs` ディレクトリを開く
```console
docsify serve docs
```
Alternatively, if you have installed freeCodeCamp locally (see the local setup guide), we bundle the CLI with the development tools so you can run any of the below commands as needed from the root of the repo:
freeCodeCampをローカルにインストールした場合は (ローカルセットアップガイド参照)、 CLIを開発ツールに束ねることで、必要に応じてリポジトリのルートから以下のコマンドを実行することもできます。
### Serve and launch the documentation site only
### ドキュメントサイトのみを提供して起動する
```console
npm run docs:serve
```
### Serve the documentation site alongside freeCodeCamp locally:
### freeCodeCamp と一緒にドキュメントサイトをローカルで提供する
```console
npm run develop
```
> The documentation site should be available at <http://localhost:3200>
> ドキュメンテーションサイトは <http://localhost:3200> で利用できます。

View File

@ -1,31 +1,31 @@
# How to work on freeCodeCamp.org's developer news theme
# freeCodeCamp.org の開発者ニュースのテーマに貢献する方法
The developer news also known as [`/news`](https://www.freecodecamp.org/news) site is powered by [Ghost](https://ghost.org/). We use a custom theme for the look and feel of the site. The source code of the theme is available here: <https://github.com/freeCodeCamp/news-theme>.
開発者ニュースは [`/news`](https://www.freecodecamp.org/news) サイトとも呼ばれ、[Ghost](https://ghost.org/) によって提供されます。 サイトのルックアンドフィールにカスタムテーマを使用しています。 テーマのソースコードは <https://github.com/freeCodeCamp/news-theme> です。
## The Theme
## テーマ
Ghost uses a simple templating language called [Handlebars](http://handlebarsjs.com/) for its themes. The theme used on `/news` is based off of the default [casper theme](https://github.com/TryGhost/Casper).
Ghostは、テーマに [Handlebars](http://handlebarsjs.com/) と呼ばれる単純なテンプレート言語を使用します。 `/news` で使用されるテーマは、デフォルトの [casper テーマ](https://github.com/TryGhost/Casper) に基づいています。
The default theme is commented pretty heavily so that it should be fairly easy to work out what's going on just by reading the code and the comments. Once you feel comfortable with how everything works, Ghost also has a full [theme API documentation](https://themes.ghost.org) which explains every possible Handlebars helper and template.
デフォルトのテーマには多くのコメントがあるので、コードやコメントを読むだけで何が起こっているのかを簡単に把握できます。 どのように動作するかを理解したら、 [テーマ API ドキュメント](https://themes.ghost.org) で、Handlebars ヘルパーとテンプレートの詳細をお読みください。
**The main files are:**
**主なファイルは次のとおりです。**
- `default.hbs` - The main template file
- `index.hbs` - Used for the home page
- `post.hbs` - Used for individual posts
- `page.hbs` - Used for individual pages
- `tag.hbs` - Used for tag archives
- `author.hbs` - Used for author archives
- `default.hbs` - メインテンプレートファイル
- `index.hbs` - ホームページに使用
- `post.hbs` - 個々の投稿に使用
- `page.hbs` - 個々のページに使用
- `tag.hbs` - タグアーカイブに使用
- `author.hbs` - 著者アーカイブに使用
One really neat trick is that you can also create custom one-off templates just by adding the slug of a page to a template file. For example:
1つの巧妙なトリックは、テンプレートファイルにページのスラグを追加するだけで、カスタムのワンオフテンプレートを作成することもできることです。 例:
- `page-about.hbs` - Custom template for the `/about/` page
- `tag-news.hbs` - Custom template for `/tag/news/` archive
- `author-ali.hbs` - Custom template for `/author/ali/` archive
- `page-about.hbs` - `/about/` ページのカスタムテンプレート
- `tag-news.hbs` - `/tag/news/` アーカイブのカスタムテンプレート
- `author-ali.hbs` - `/author/ali/` アーカイブのカスタムテンプレート
## Development
## 開発
1. Get Ghost installed locally.
1. ゴーストをローカルにインストールします。
```sh
npm install -g ghost-cli@latest
@ -38,63 +38,63 @@ One really neat trick is that you can also create custom one-off templates just
ghost start
```
> Note: Currently freeCodeCamp uses Ghost version `2.9.0`, so make sure you are using a version higher than that.
> 注: freeCodeCampは現在、バージョン `2.9.0` を使用しているため、それ以降のバージョンであることを確認してください。
Be sure to run `ghost` commands from the `ghost-local-site` directory. Follow additional instructions on [Ghost's official documentation](https://docs.ghost.org) if are not familiar with its interface.
`ghost-local-site` ディレクトリから `ghost` コマンドを実行してください。 インターフェースに慣れていない場合は、[Ghost 公式ドキュメント](https://docs.ghost.org) の追加指示に従ってください。
2. Fork and clone the repository in your theme directory (replacing `YOUR_USERNAME` with your GitHub username):
2. テーマディレクトリにあるリポジトリをフォークしてクローンします ( `YOUR_USERNAME` を GitHub ユーザー名に置き換えてください)。
```sh
cd content/themes/
git clone https://github.com/YOUR_USERNAME/news-theme.git
```
3. Make sure you have all the pre-requisites.
3. 前提条件がすべて揃っていることを確認してください。
The theme styles are compiled using Gulp/PostCSS to polyfill future CSS spec. You'll need [Node.js](https://nodejs.org/). Make sure that your Node.js version is compatible with `ghost`.
テーマのスタイルは Gulp/PostCSS を使用してコンパイルされ、将来の CSS 仕様をポリフィルします。 [Node.js](https://nodejs.org/) が必要です。 Node.js のバージョンが `ghost` と互換性があることを確認してください。
4. Install dependencies and develop the theme
4. 依存関係をインストールしてテーマを開発します。
```sh
npm ci
npm run develop
```
5. Now you can edit `/assets/css/` files, which will be compiled to `/assets/built/` automatically.
5. これで `/assets/css/` ファイルを編集できるようになりました。これは `/assets/built/` に自動的にコンパイルされます。
6. Access the development site.
6. 開発サイトにアクセスします。
a. Enter `http://localhost:2368/ghost/` into your address bar. Continue with the setup prompted on the page (if running ghost for the first time).
a. アドレスバーに `http://localhost:2368/ghost/` を入力します。 ページに表示されたセットアップを続行します (ghost の初回実行時)。
b. _(One-time only, during setup)_ Restart Ghost, on a separate terminal once to ensure the theme is available.
b. _(セットアップ時に一度だけ)_ テーマが利用可能であることを確認するために、別の端末で Ghost を再起動します。
```sh
cd ghost-local-site
ghost restart
```
c. _(One-time only, during setup)_ Once you've done this, go to `http://localhost:2368/ghost/#/settings/design` and scroll to the bottom. Make sure you click activate on the `freecodecamp-news-theme`.
c. _(セットアップ時に一度だけ)_ これが完了したら、 `http://localhost:2368/ghost/#/settings/design` に行き、一番下までスクロールします。 `freecodecamp-news-theme` をクリックしてアクティブ化します。
7. Zip the final code and make a pull-request
7. 最終コードを Zip してプルリクエストを作成します。
The `zip` Gulp task packages the theme files into `dist/<theme-name>.zip`, which we can then upload to the production site.
`zip` Gulp タスクは、テーマファイルを `dist/<theme-name>.zip` にパッケージ化し、本番サイトにアップロードできるようにします。
When you make a PR, please make sure you have run the below script prior to commiting the code and sending a PR.
PR を行う場合は、コードをコミットして PR を送信する前に、以下のスクリプトを実行していることを確認してください。
```sh
npm run zip
```
## Other Reference and resources
## その他の参照とリソース
### PostCSS Features Used
### PostCSS 機能の使用
- Autoprefixer - Don't worry about writing browser prefixes of any kind, it's all done automatically with support for the latest 2 major versions of every browser.
- Variables - Simple pure CSS variables
- [Color Function](https://github.com/postcss/postcss-color-function)
- Autoprefixer - あらゆる種類のブラウザのプレフィックスも書く必要がありません。すべてのブラウザにおいて、最新の2つのメジャーバージョンをサポートして自動的に行われます。
- 変数 - シンプルな純粋な CSS 変数
- [カラー関数](https://github.com/postcss/postcss-color-function)
### SVG Icons
### SVG アイコン
The theme uses inline SVG icons, included via Handlebars partials. You can find all icons inside `/partials/icons`. To use an icon just include the name of the relevant file, eg. To include the SVG icon in `/partials/icons/rss.hbs` - use `{{> "icons/rss"}}`.
このテーマは、Handlebars パーシャルを介して組み込まれたインライン SVG アイコンを使用しています。 すべてのアイコンは `/partials/icons` 内にあります。 アイコンを使用するには、関連ファイルの名前を含めます。例えば、 SVGアイコンを `/partials/icons/rss.hbs` に含めるには、`{{> "icons/rss"}}`を使用します。
You can add your own SVG icons in the same manner.
独自の SVG アイコンを同じ方法で追加できます。

View File

@ -1,130 +1,130 @@
This page describes how to contribute to the freeCodeCamp tutorials and projects that are completed using the CodeRoad VS Code extension.
このページでは、CodeCamp の freeCodeCamp チュートリアルや、CodeRoad VS Code 拡張機能を使用して完了したプロジェクトに貢献する方法を説明します。
## How the tutorials work
## チュートリアルの仕組み
The freeCodeCamp tutorials that use CodeRoad each have their own repo under the freeCodeCamp GitHub organization. They all start with `learn-`. For example, `https://github.com/freeCodeCamp/learn-bash-by-building-a-boilerplate/`.
CodeRoad を使用している freeCodeCamp チュートリアルは、それぞれ freeCodeCamp GitHub 組織 の下に独自のリポジトリを持っています。 それらはすべて `learn-` から始まります。 例えば、`https://github.com/freeCodeCamp/learn-bash-by-building-aboilerplate/` です。
Each tutorial repo has a `main` branch and a "version" branch, e.g. `v1.0.0`.
各チュートリアルリポジトリには、`main` ブランチと「バージョン」ブランチがあります。例えば、 `v1.0.0` です。
The two main files on the `main` branch are `TUTORIAL.md` and `coderoad.yaml`. `TUTORIAL.md` contains all the instructions, hints, titles, and so on, for the tutorial. `coderoad.yaml` contains instructions for CodeRoad, such as what commands to run and when, what files to watch for changes, and what version branch to use for the steps.
`main` ブランチには、`TUTORIAL.md` と `coderad.yaml` 2 つのメインファイルがあります。 `TUTORIAL.md` には、チュートリアルのすべての手順、ヒント、タイトルなどが含まれています。 `coderoad.yaml` には、どのコマンドを実行するか、どのファイルの変更を監視するか、どのブランチバージョンをステップに使用するかなど CodeRoad に対する指示が含まれています。
The "version" branch contains the commits that will be loaded on each step of a tutorial. The commit messages on this branch have to be specific. The first commit needs `INIT` for its message and contains all the files to load before the first lesson.
「バージョン」ブランチには、チュートリアルの各ステップにロードされるコミットが含まれています。 このブランチのコミットメッセージは特定のものでなければなりません。 最初のコミットには、メッセージに `INIT` が必要であり、初回レッスン前にロードするファイルがすべて含まれています。
Subsequent commit messages have to match the step number in `TUTORIAL.md` from the `main` branch. For example, the commit with the message `10.1` will be loaded when a user goes to step `10.1`.
後続のコミットメッセージは、`main` ブランチの `TUTORIAL.md` のステップ数と一致する必要があります。 例えば、ユーザーがステップ `10.1` に行くと、メッセージ `10.1` を含むコミットがロードされます。
In order to make changes to commits on a version branch, you would need to rebase and edit the commits you want to change. This will rewrite the Git history, so we cannot accept PRs to these types of branches. Once a version branch is on the freeCodeCamp repo, it should never change.
バージョンブランチでコミットに変更を加えるには、変更したいコミットをリベースして編集する必要があります。 これにより Git の履歴が書き換えられるので、これらの種類のブランチには PR を受け入れられません。 バージョンブランチが freeCodeCamp リポジトリ上にある場合は、変更しないでください。
> [!WARNING]
>
> Never make or push changes to a version branch that is on one of the freeCodeCamp repos. Always create a new one
> freeCodeCamp リポジトリにあるバージョンブランチに、変更を加えたりプッシュしたりしないでください。 常に新しいものを作成してください。
## How to contribute
## 貢献する方法
### Prerequisites
### 必要条件
Install the [CodeRoad CLI tools](https://www.npmjs.com/package/@coderoad/cli) with `npm install -g @coderoad/cli`.
[CodeRoad CLI ツール](https://www.npmjs.com/package/@coderoad/cli) を `npm install -g @coderoad/cli` でインストールします。
There have been some issues with the latest version. If `coderoad --version` doesn't work after installing, downgrade to `0.7.0` with `npm install -g @coderoad/cli@0.7.0`.
最新バージョンにはいくつかの問題があります。 `coderoad --version` がインストール後に動作しない場合は、`npm install -g @coderoad/cli@0.7.0` を使用して `0.7.0` にダウングレードしてください。
### Working on `main`
### `main` に貢献する
This set of instructions is for PRs that only make minor changes on `main` to **existing lessons**. That mainly consists of typo, grammar, hint, and instructional changes or fixes in the `TUTORIAL.md` file.
この一連の手順は、`main` で **既存のレッスン** に軽微な変更を加える PR のためのものです。 これは主に `TUTORIAL.md` ファイルのタイプミス、文法、ヒント、指示の変更または修正で構成されています。
For everything else, including adding or deleting lessons, follow the [working on a version branch instructions](#working-on-version-branch). You will not need to create a new version branch for this - you can create a PR following the instructions below.
レッスンの追加や削除を含むその他すべてについては、[バージョンブランチの手順](#working-on-version-branch) に従ってください。 このために新しいバージョンブランチを作成する必要はありません。以下の手順に従って PR を作成できます。
> [!NOTE]
>
> These changes will use the existing version branch. If they are substantial, feel free to add them to `CHANGELOG.md`. Most of the time, a good commit message should work
> これらの変更には既存のバージョンブランチを使用します。 相当量のものであれば、自由に `CHANGELOG.md` に追加してください。 ほとんどの場合、良いコミットメッセージで動作するはずです。
You never need to modify the `tutorial.json` file directly. That will be created with the CLI tools.
`tutorial.json` ファイルを直接変更する必要はありません。 これは、CLI ツールで作成されます。
If you are only making minor changes like fixing a typo or grammatical error, you don't have to test your changes.
タイプミスや文法上のエラー修正等の軽微な変更の場合は、その変更をテストする必要はありません。
Follow these instructions to make a PR, keeping in mind that instructions usually use the lessons around them for context:
以下の手順に従って PR を作成します。この手順は、通常、周りのレッスンをコンテキストに使用していることを覚えておいてください。
- Create a copy of the latest version branch with `git branch vX.X.X upstream/vX.X.X` - you do not need to check this branch out, it just needs to exist.
- Create and checkout a new branch off of `main`
- Make **and commit** your changes. Reminder: You don't need to change anything in the `tutorial.json` file. You likely only need to make changes to `TUTORIAL.md`
- Run `coderoad build` to recreate the `tutorial.json` file
- Commit the changes with `update json` as the message
- Make a PR
- `git branch vX.X.X upstream/vX.X.X` を使用して、最新バージョンのブランチのコピーを作成します。このブランチをチェックする必要はありませんが、存在している必要があります。
- `main` の新しいブランチを作成してチェックアウトします。
- 変更を行い **コミット** します。 注意: `tutorial.json` ファイルを変更する必要はありません。 `TUTORIAL.md` に変更を加える必要があります。
- `coderoad build` を実行して、`tutorial.json` ファイルを再作成します。
- `update json` でメッセージとして変更をコミットします。
- PR を作成します。
### Testing changes on `main`
### `main` の変更をテストする
If you want to test your changes to `main` after using the above instructions, follow these instructions:
上記手順の後、`main` の変更をテストしたい場合は、次の手順に従います。
- Follow the instructions on the [rdb-alpha repo](https://github.com/freeCodeCamp/rdb-alpha) to run a container
- Start the tutorial using the `tutorial.json` file on the new branch
- [rdb-alpha repo](https://github.com/freeCodeCamp/rdb-alpha) の手順に従ってコンテナを実行します。
- 新しいブランチの `tutorial.json` ファイルを使用してチュートリアルを開始します。
### Reviewing PR's to `main`
### `main` の PR をレビューする
If reviewing a PR that only changes `main` with instructional or grammar issues as described above, the changes in `TUTORIAL.md` should match the changes in `tutorial.json`.
上述のように、指示もしくは文法問題に関わる `main` のみを変更する PR をレビューする場合、`TUTORIAL.md` の変更は、`tutorial.json` の変更と一致する必要があります。
The `tutorial.json` file should not have changes to commit hashes, or step/level ids. Startup or level commands or file watchers likely should not be changed either. There are exceptions if there's an issue with a step, but they should be treated with more caution.
`tutorial.json` ファイルには、コミットハッシュやステップ / レベル ID の変更を含めないでください。 起動コマンドや、レベルコマンド、ファイルウォッチャーも変更すべきではありません。 例外はありますが、ステップに問題があれば、注意深く処理する必要があります。
Also, keep in mind that instructions usually use the lessons around them for context, so make sure they make sense.
通常、周りのレッスンをコンテキストに使用していることを覚えておいてください。指示が理にかなっていることを確認してください。
### Working on version branch
### バージョンブランチで作業する
> [!WARNING]
>
> Reminder: Never make or push changes to a version branch that is on one of the freeCodeCamp repos. Always create a new one
> 注: freeCodeCamp リポジトリにあるバージョンブランチに、変更を加えたりプッシュしたりしないでください。 常に新しいものを作成してください。
There's no easy way to see exactly what changed between version branches since the Git history will be rewritten. Accepting new version branches to use will need to be done with careful consideration and testing.
Git の履歴が書き換えられるため、バージョンブランチ間で何が変更されたかを簡単に確認する方法はありません。 新しいバージョンブランチの使用を承諾するには、慎重な検討とテストが必要です。
These instructions are for changing anything on a "version" branch, such as tests, test text, reset files, adding and deleting steps, among other things.
これらの手順は、テスト、テストテキスト、ファイルのリセット、ステップの追加や削除など、「バージョン」ブランチを変更するためのものです。
Follow these instructions to create a new version:
新しいバージョンを作成するには、次の手順に従います。
- Checkout the **latest** version branch with `git checkout -b vX.X.X upstream/vX.X.X`
- Create a new branch off of that, incrementing the version, with `git checkout -b vX.X.Y`
- Make your changes to the version branch. See more info in the [CodeRoad Documentation](https://coderoad.github.io/docs/edit-tutorial) for how to work with tutorials
- Push the new branch to your fork with `git push -u origin vX.X.Y`
- Checkout the `main` branch
- Create a new branch off `main`. e.g. `feat/version-X.X.Y`
- Change the `uri` in `coderoad.yaml` to your fork of the repo. This is so you and reviewers can test it before pushing it to the freeCodeCamp repo. Change the version to the new branch in the two spots of that file. Add your changes for the new version to `CHANGELOG.md`. Make any other changes you need.
- Commit your changes with the message `feat: release version X.X.Y - <optional description>`
- Run `coderoad build` to create a new `tutorial.json` file
- Add and commit the file
- Push the changes to your fork
- Test your changes following the [testing instructions below](#testing-changes-to-a-version-branch). Make any additional changes and commit them as you just did, or, if you are satisfied, follow the rest of the instructions
- Make a PR to `main` using your new `feat/version-X.X.Y` branch. Give it a title of `version X.X.Y ready for review`. This will not be merged, it is just to let reviewers know that there is a new version ready
- Leave it here for reviewers
- **最新の** バージョンブランチを `git checkout -b vX.X.X upstream/vX.X.X` でチェックアウトします。
- そこから新しいブランチを作成し、`git checkout -b vX.X.Y` でバージョンをインクリメントします。
- バージョンブランチを変更します。 チュートリアルの使い方については、[CodeRoad ドキュメント](https://coderoad.github.io/docs/edit-tutorial) を参照します。
- `git push -u origin vX.X.Y` で、新しいブランチをフォークにプッシュします。
- `main` ブランチをチェックアウトします。
- `main` から新しいブランチを作成します。 例: `feat/version-X.X.Y`
- `coderoad.yaml``uri` をリポジトリのフォークに変更します。 これにより、あなたとレビュアーが freeCodeCamp リポジトリにプッシュする前に、テストできるようになります。 バージョンを、そのファイルの 2 つのスポットにある新しいブランチに変更します。 新しいバージョンの変更を `CHANGELOG.md` に追加します。 その他必要な変更を行います。
- メッセージ `feat: release version X.X.Y - <optional description>` で、変更をコミットします。
- `coderoad build` を実行して、新しい `tutorial.json` ファイルを作成します。
- ファイルを追加してコミットします。
- フォークに変更をプッシュします。
- 以下の [テスト手順](#testing-changes-to-a-version-branch) に従って変更をテストします。 追加の変更を行い、先ほどと同様にコミットします。追加の変更がなければ、残りの手順に進みます。
- 新しい `feat/version-X.X.Y` ブランチを使用して `main` に PR を作成します。 `version X.X.Y ready for review` のタイトルを付けます。 これはマージされません。新しいバージョンが準備ができていることをレビューアーに知らせるためのものです。
- レビュアーのためにそこに残してください。
### Testing changes to a version branch
### バージョンブランチの変更をテストする
- Follow the instructions on the [rdb-alpha repo](https://github.com/freeCodeCamp/rdb-alpha) to run a container
- Start the tutorial using the `tutorial.json` file on whatever fork the changes are on. Make sure to use the file on the `feat: version-X.X.Y` branch and not the `main` branch
- [rdb-alpha repo](https://github.com/freeCodeCamp/rdb-alpha) の手順に従ってコンテナを実行します。
- 変更があるフォークの `tutorial.json` ファイルを使用してチュートリアルを開始します。 `main` ブランチ ではなく、`feat: version-X.X.Y` ブランチのファイルを使用します。
### Pushing a new version
### 新しいバージョンをプッシュする
Before pushing a new version, view the new `feat/version-vX.X.Y` (will be merged to `main`) branch on the user's fork. Make sure there are additions to the `CHANGELOG.md` file that include the new changes, and the version in the two spots of `coderoad.yaml` matches the new version branch.
新しいバージョンをプッシュする前に、ユーザーのフォークで新しい `feat/version-vX.X.Y` (`main` にマージされる) ブランチを表示してください。 新規変更を含む `CHANGELOG.md` ファイルに追加があり、`coderoad.yaml` の 2 つのスポットのバージョンが新しいバージョンブランチと一致していることを確認してください。
If you have write access to the freeCodeCamp repo, have verified the `CHANGELOG` and `coderoad.yaml` files, have tested the changes using the instructions above, and want to push a new version of a tutorial:
freeCodeCamp リポジトリへの書き込みアクセス権を有しており、`CHANGELOG` と `coderoad.yaml` ファイルが検証済で、上記手順を使用して変更もテスト済みであり、チュートリアルの新しいバージョンをブッシュしたい場合は、下記を実行してください。
> [!WARNING]
>
> Reminder: Never make or push changes to a version branch that is on one of the freeCodeCamp repos. Always create a new one
> 留意点: freeCodeCamp リポジトリにあるバージョンブランチに変更を加えたりプッシュしたりしないでください。 常に新しいものを作成してください。
- If you don't have a remote to where the new changes exist, create a remote to the user's fork with `git remote add <users_fork>`
- Delete any **local** branches that share a name with the new branches. Likely named either `vX.X.Y` or `feat/version-X.X.Y`
- Checkout the new version branch with `git checkout -b vX.X.Y <remote>/vX.X.Y`
- Push the new version branch to the freeCodeCamp repo with `git push -u upstream/vX.X.Y`. You need to push the new branch before you update `main` with the new `tutorial.json` file
- Checkout the users branch that will be merged into `main` with `git checkout -b feat/version-X.X.Y <remote>/feat/version-X.X.Y`
- Change the `uri` in `coderoad.yaml` back to the freeCodeCamp repo
- Add and commit the changes
- Run `coderoad build` to create the new `tutorial.json` file
- Add and commit the file
- Push the changes to your fork with `git push -u origin/feat/version-X.X.Y`
- Make a PR to `main` on the freeCodeCamp repo
- If you are satisfied, merge it or leave it and ask for a review from someone
- After the PR is merged, open the tutorial by following the instructions on the [rdb-alpha repo](https://github.com/freeCodeCamp/rdb-alpha) to make sure it's loading properly, and that you can get through a few steps
- Finally, if any PRs for this version exists, close them
- 新しい変更が存在する場所へのリモートがない場合、`git remote add <users_fork>` を使用してユーザーのフォークへのリモートを作成します。
- 新しいブランチと同じ **local** ブランチ名を削除します。 おそらく、 `vX.X.Y` または `feat/version-X.X.Y` いずれかの名前です。
- 新しいバージョンブランチを `git checkout -b vX.X.Y <remote>/vX.X.Y` でチェックアウトします。
- `git push -u upstream/vX.X.Y` で freeCodeCamp リポジトリに新しいバージョンのブランチをプッシュします。 新しい `tutorial.json` ファイルで `main` を更新する前に、新しいブランチをプッシュする必要があります。
- `git checkout -b feat/version-X.X.Y <remote>/feat/version-X.X.Y` で、`main` にマージされるユーザーブランチをチェックアウトします。
- `coderoad.yaml``uri` を freeCodeCamp リポジトリに戻します。
- 変更を追加してコミットします。
- `coderoad build` を実行して、新しい `tutorial.json` ファイルを作成します。
- ファイルを追加してコミットします。
- `git push -u origin/feat/version-X.X.Y` でフォークに変更をプッシュします。
- freeCodeCamp リポジトリで `main` にPRを作成します。
- 問題がない場合は、それをマージするか残して、レビューを依頼します。
- PR がマージされた後、[rdb-alpha repo](https://github.com/freeCodeCamp/rdb-alpha) の指示に従ってチュートリアルを開き、正しく読み込まれていることと、いくつかのステップが実行できることを確認します。
- 最後に、このバージョンの PR が存在する場合は、それらをクローズします。
### How to revert to a previous version
### 以前のバージョンに戻す方法
- Create a new branch off the latest `main` with `git checkout -b revert/to-version-X.X.X`
- Revert all commits on this branch up to and including the commit of the version after the one you want to revert to. For example, you may have commits that look like this:
- `git checkout -b revert/to-version-X.X.X` を使用して、最新の `main` から新しいブランチを作成します。
- このブランチにおいて、元に戻したいバージョン以降のコミットをすべて元に戻します。 例えば、次のようなコミットです。
```
fix: typo
@ -133,6 +133,6 @@ fix: typo
release: version 1.0.0
```
If you want to revert to v1.0.0, revert all the commits from `release: version 1.0.1` and after
v1.0.0 に戻したい場合は、 `release: version 1.0.1` 以降からすべてのコミットを元に戻します。
- Create a PR. Give it a title of `revert: to version X.X.X`
- PR を作成します。 `revert: to version X.X.X` のタイトルを付けます。

View File

@ -1,43 +1,43 @@
The [freeCodeCamp.org](https://freecodecamp.org) community is possible thanks to thousands of kind volunteers like you. If you want to contribute your time and expertise, we would be excited to welcome you aboard.
[freeCodeCamp.org](https://freecodecamp.org) コミュニティは、皆さんような親切な何千人ものボランティアのおかげで成り立っています。 もし貴重な時間や専門知識を提供したいと思っていただけるならば、喜んで歓迎いたします。
> [!NOTE] Before you proceed, please take a quick 2 minutes to read our [Code of Conduct](https://www.freecodecamp.org/code-of-conduct). We strictly enforce it across our community so that contributing to freeCodeCamp.org is a safe, inclusive experience for everyone.
> [!NOTE] 続行される前に、いったん 2 分ほどお時間をいただいて私たちの [行動規範](https://www.freecodecamp.org/code-of-conduct) をお読みください。 freeCodeCamp.org に貢献することが誰にとっても安全で包括的な体験になるよう、コミュニティ全体でこの規範を徹底的に実施します。
You are welcome to create, update and fix bugs in our [curriculum](#curriculum), help us fix bugs in freeCodeCamp.org's [learning platform](#learning-platform), or [help us translate](#translations) freeCodeCamp.org to world languages.
私たちの [curriculum](#curriculum) の作成、更新、バグの解消を行ったり、freeCodeCamp.org の [学習プラットフォーム](#learning-platform) 内でバグの解消を支援したり、freeCodeCamp.org の世界言語への [翻訳を支援](#translations) したりすることを歓迎します。
We answer the most common questions about contributing [in our contributor FAQ](FAQ.md).
貢献に関する一般的なご質問には、[コントリビューターのよくある質問](FAQ.md) でお答えします。
Happy contributing.
貢献をお楽しみください。
---
## Curriculum
## カリキュラム
Our curriculum is curated by the global freeCodeCamp community. This way, we are able to incorporate expert knowledge from volunteers like you.
私たちのカリキュラムは、世界中の freeCodeCamp コミュニティによってキュレーションされています。 こうすることで、皆さんのようなボランティアから専門的な知識を取り入れることができます。
You can help expand and improve the curriculum. You can also update project user stories to better-explain concepts. And you can improve our automated tests so that we can more accurately test people's code.
皆さんは、カリキュラムを拡張したり改善したりする支援ができます。 プロジェクトのユーザーストーリーをより良い概念の説明に更新することもできます。 また、より正確にコードをテストするために、テスト自動化を改善することができます。
**If you're interested in improving our curriculum, here's [how to contribute to the curriculum](how-to-work-on-coding-challenges.md).**
**カリキュラムの改善にご興味があれば、[カリキュラムに貢献する方法](how-to-work-on-coding-challenges.md) をご覧ください。**
## Translations
## 翻訳
We are localizing freeCodeCamp.org to major world languages.
私たちは freeCodeCamp.org を世界中の主要言語へローカライズしています。
Certifications are already live in some major world languages like [Chinese (中文)](https://chinese.freecodecamp.org/learn), [Spanish (Español)](https://www.freecodecamp.org/espanol/learn/), [Italian (Italiano)](https://www.freecodecamp.org/espanol/learn/), [Portuguese (Português)](https://www.freecodecamp.org/espanol/learn/). We encourage you to read the [announcement here](https://www.freecodecamp.org/news/world-language-translation-effort) and share it with your friends to get them excited about this.
認定講座は、[中国語 (中文)](https://chinese.freecodecamp.org/learn)、[スペイン語 (Español)](https://www.freecodecamp.org/espanol/learn/)、[イタリア語 (Italiano)](https://www.freecodecamp.org/espanol/learn/)、[ポルトガル語 (Português)](https://www.freecodecamp.org/espanol/learn/) のような世界の主要言語で、すでに動作しています。 [お知らせ](https://www.freecodecamp.org/news/world-language-translation-effort) を読んで、仲間と共に楽しんでください。
**If you're interested in translating, here's [how to translate freeCodeCamp's resources](how-to-translate-files.md).**
**翻訳にご興味があれば、[freeCodeCamp リソースを翻訳する方法](how-to-translate-files.md) をご覧ください。**
## Learning Platform
## 学習プラットフォーム
Our learning platform runs on a modern JavaScript stack. It has various components, tools, and libraries. These include Node.js, MongoDB, OAuth 2.0, React, Gatsby, Webpack, and more.
学習プラットフォームは、最新の JavaScript スタックで動作しています。 様々なコンポーネント、ツール、ライブラリがあります。 Node.js、MongoDB、OAuth 2.0、React、Gatsby、Webpackなどが含まれています。
Broadly, we have a Node.js based API server, a set of React-based client applications, testing scripts to evaluate camper-submitted curriculum projects, and more. If you want to productively contribute to the learning platform, we recommend some familiarity with these tools.
Node.js ベースの API サーバー、React ベースのクライアントアプリケーションのセット、キャンパーが提出したカリキュラムプロジェクトを評価するためのスクリプトテストなどがあります。 学習プラットフォームに生産的に貢献したい場合は、これらのツールを熟知している方が良いでしょう。
If you want to help us improve our codebase...
コードベースの改善にご協力いただけますか?
**you can either use Gitpod, a free online dev environment that starts a ready-to-code dev environment for freeCodeCamp in your browser.**
**無料のオンライン開発環境である Gitpod を使用して、ブラウザで freeCodeCamp 用のコード対応開発環境を開始することができます。**
[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
[![Gitpod で開く](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
Or you can...
あるいは
**[set up freeCodeCamp locally](how-to-setup-freecodecamp-locally.md) on your machine.**
**コンピュータ上で [freeCodeCamp をローカル設定](how-to-setup-freecodecamp-locally.md) することができます。**

View File

@ -1,224 +1,224 @@
# The Official freeCodeCamp Moderator Handbook
# 公式 freeCodeCamp モデレーターハンドブック
This handbook will help you moderate different places in our community. This covers conversations and interactions in issues & pull request threads on GitHub, the community forum, the chat rooms and other official communities that we foster.
このハンドブックは、私たちのコミュニティの様々な場所をモデレートするのに役立ちます。 GitHub、コミュニティフォーラム、チャットルーム、およびその他の公式コミュニティにおける Issue とプルリクエストスレッドに関する、会話とインタラクションを説明します。
> [!NOTE] All freeCodeCamp moderators are community-wide moderators. That is we trust you to oversee any of these places.
> [!NOTE] すべての freeCodeCamp モデレーターは、コミュニティ全体のモデレーターです。 上記いずれかの場所を監督していただきます。
You can serve as a moderator on any of the platforms that are of the most interest to you. Some moderators just help out on GitHub, while others just help out on the forum. Some moderators are active everywhere.
最も興味のあるプラットフォームのモデレーターなることができます。 GitHub を支援するモデレーターもいれば、フォーラムを支援するモデレーターもいます。 すべての場所においてご活躍いただくモデレーターもいます。
The bottom line is that we want you to enjoy being a moderator, and invest your scarce time in places that are of interest to you.
モデレーターであることを楽しんでください。 興味のある場所に皆さんの時間を投資してください。
> "With great power comes great responsibility." - Uncle Ben
> 「大いなる力には大いなる責任が伴う」 - ベンおじさん
As a moderator, temperament is more important than technical skill.
モデレーターにとって、気質は技術的スキルよりも重要です。
Listen. Be Helpful. Don't abuse your power.
聞きましょう。 役に立ちましょう。 権力を乱用してはいけません。
freeCodeCamp is an inclusive community, and we need to keep it that way.
freeCodeCamp は包括的なコミュニティであり、それを維持する必要があります。
We have a single code of conduct that governs our entire community. The fewer the rules, the easier they are to remember. You can read those rules and commit them to memory [here](https://code-of-conduct.freecodecamp.org).
私たちにはコミュニティ全体を支配する単一の行動規範があります。 ルールは少ないほど、覚えやすいものです。 [こちら](https://code-of-conduct.freecodecamp.org) にあるルールを読み、記憶に留めておいてください。
> [!NOTE] As a moderator we would add you to one or more teams on GitHub, our community forum(s) & chat servers. If you are missing access on a platform that you would like to moderate please [reach out to a staff member](FAQ.md#additional-assistance).
> [!NOTE] GitHub、コミュニティフォーラム 、チャットサーバーのチームに、皆さんをモデレーターとして追加します。 モデレートしたいプラットフォームにアクセスできない場合は、[スタッフまでご連絡ください](FAQ.md#additional-assistance)。
## Moderating GitHub
## GitHub をモデレートする
Moderators have two primary responsibilities on GitHub:
モデレーターは、GitHub 上で 2 つの主要な責任を負います。
1. Triaging and responding to issues
2. Reviewing and merging pull requests (a.k.a QA).
1. Issue のトリアージと対応
2. プルリクエストのレビューとマージ (すなわち、QA)
### Moderating GitHub Issues
### GitHub Issue をモデレートする
We use our main [`freeCodeCamp/freeCodeCamp`](https://github.com/freeCodeCamp/freeCodeCamp/issues) repo as a common issue tracker for all of our repositories. We get new issues every day, all of which need to be triaged, labeled and addressed. This is also a great place to start helping with open-source codebase contributions.
main [`freeCodeCamp/freeCodeCamp`](https://github.com/freeCodeCamp/freeCodeCamp/issues) リポジトリを、すべてのリポジトリのための共通 Issue トラッカーとして使用しています。 毎日新しい問題が起きており、そのすべてをトリアージし、ラベル付けし、対処する必要があります。 オープンソースコードベースの貢献を始めるのに最適な場所です。
#### Issue Triage
#### Issue のトリアージ
[Triaging](https://en.wikipedia.org/wiki/Triage) is a process of prioritizing attention to each new issue report. We have an extensive list of labels that we use to mark each issue's priority, category, status, and scope.
[トリアージ](https://en.wikipedia.org/wiki/Triage) は、新しい Issue の各報告に対して優先順位を付けるプロセスです。 それぞれの Issue の優先順位、カテゴリ、ステータス、スコープにマークを付けるために使用する広範なラベルリストがあります。
You can help us organize and triage the issue reports by applying labels from [this list](https://github.com/freeCodeCamp/freeCodeCamp/labels). Usually, a description is available alongside the label explaining its meaning.
[このリスト](https://github.com/freeCodeCamp/freeCodeCamp/labels) のラベルを使用して、Issue 報告を整理しトリアージすることができます。 通常、ラベルにはその説明書きがあります。
Please pay special attention to the labels `"help wanted"` and `"first timers only"`. These are to be added to threads that you think can be opened up to potential contributors for making a pull request.
`"help wanted"``"first timers only"` のラベルに特に注意してください。 これらは、プルリクエストを行う潜在的なコントリビューターが入る可能性があるスレッドに追加されます。
A `"first timer only"` label should be applied to a trivial issue (ex. a typo fix) and should include additional information. You can use this [reply template](moderator-handbook.md#first-timer-only-issues) for triage.
`"first timer only"` ラベルは些細な問題 (例: タイプミスの修正) に適用され、追加情報が必要となります。 この [返信テンプレート](moderator-handbook.md#first-timer-only-issues) をトリアージに使用できます。
#### Closing Stale, Outdated, Inactive Issues and Pull Requests
#### 古く、期限切れで、不活発な Issue とプルリクエストをクローズする
- Stale issues or PRs are those that have not seen any activity from the author for 21 days (3 weeks from the last activity), but only after a moderator has requested more information/changes.
- 古い Issue または 古い PR とは、作成者が過去21 日間 (最後の活動から 3 週間) アクティビティを行っていないものを指しますが、具体的にはモデレーターが作成者に対して追加情報 / 変更を要求してから上記既定の日数を経過したものを指します。
- Activity is defined as: Comments requesting an update on the PR and triages like `status: update needed` label etc.
- アクティビティは、`status: update needed` ラベルなどの PR とトリアージの更新をリクエストするコメントと定義されます。
- If the contributor asks for additional assistance or even time, the above can be relaxed and revisited after a response is given. In any case, the mods should use their best judgment to resolve the outstanding PR's status.
- コントリビューターから支援もしくは時間の追加要求があった場合、それに対する回答を返し、該当する Issue または PR を後日改めて確認することができます。 いずれの場合でも、モデレーターは、未解決の PR を解決するために最善の判断を下す必要があります。
> [!TIP] We recommend you use this list of standard [reply templates](moderator-handbook.md#reply-templates) while triaging issues.
> [!TIP] Issue をトリアージする際には、この標準の [返信テンプレート](moderator-handbook.md#reply-templates) リストを使用することをお勧めします。
### Moderating Pull Requests
### プルリクエストをモデレートする
Pull Requests (PRs) are how contributors submit changes to freeCodeCamp's repository. We must perform Quality Assurance (QA) on pull requests before we decide whether to merge them, request changes, or close them.
プルリクエスト (PR) とは、コントリビューターが freeCodeCamp のリポジトリに変更を送信する方法です。 プルリクエストをマージするか、変更をリクエストするか、もしくはクローズするかを決定する前に、Quality Assurance (QA) を実行しなければなりません。
#### Types of Pull Requests
#### プルリクエストの種類
1. **Challenge Instruction Edits**
1. **チャレンジ指示の編集**
These are changes to the text of challenges - the Description, Instructions, or Test Text.
これは、チャレンジテキスト (説明、指示、またはテストテキスト) の変更です。
You can also review these right on GitHub and decide whether to merge them. We need to be a bit more careful about these because millions of people will encounter this text as they work through the freeCodeCamp curriculum. Does the pull request make the text more clear without making it much longer? Are the edits relevant and not overly pedantic? Remember that our goal is for challenges to be as clear and as short as possible. They aren't the place for obscure details. Contributors may try to add links to resources to the challenges.
GitHub で確認し、マージするかどうかを決定することもできます。 しかし、これについては少し注意する必要があります。 なぜなら、freeCodeCamp カリキュラムを通して何百万人もの方がこのテキストを見るからです。 テキストは、プルリクエストにより、冗長になることなく明確になっていますか? 編集内容は、過度に知識をひけらかすものではなく、関連性の高いものになっていますか? 可能な限り明確かつ短文のチャレンジにすることが目標であることを忘れないでください。 曖昧であってはなりません。 コントリビューターが、チャレンジにリソースへのリンクを追加しようとする場合もあります。
You can close invalid pull requests and reply to them with these [reply templates](moderator-handbook.md#closing-invalid-pull-requests).
無効なプルリクエストをクローズして、この [返信テンプレート](moderator-handbook.md#closing-invalid-pull-requests) で送信します。
If the change looks good, please ensure to leave an approval with a "LGTM" comment. Once a pull request gets at least two approvals (including yours) from the moderators or the dev-team, you can go ahead and merge it.
正しく変更されたら、必ず「LGTM」コメントで承認を残してください。 プルリクエストがモデレーターまたは開発チームから少なくとも 2 つの承認 (あなたを含む) を得たら、マージすることができます。
2. **Challenge Code Edits**
2. **チャレンジコードの編集**
These are changes to the code in a challenge - the Challenge Seed, Challenge Solution, and Test Strings.
これは、チャレンジシード、チャレンジソリューション、テスト文字列などのチャレンジのコードの変更です。
These pull requests need to be pulled down from GitHub and tested on your local computer or Gitpod to make sure the challenge tests can still be passed with the current solution, and the new code doesn't introduce any errors.
現在のソリューションでチャレンジテストに合格できるかどうか、また新しいコードでエラーが発生しないかどうか確認するために、プルリクエストを GitHub からプルダウンしローカルコンピュータまたは Gitpod でテストする必要があります。
Some contributors may try to add additional tests to cover pedantic corner-cases. We need to be careful to not make the challenge too complicated. These challenges and their tests should be as simple and intuitive as possible. Aside from the algorithm challenges and interview prep section, learners should be able to solve each challenge within about 2 minutes.
コントリビューターの中には、衒学的で厄介なケースも網羅するために、追加テストを含めようとする人もいるかもしれません。 チャレンジがあまり複雑にならないように注意しなければなりません。 チャレンジとそのテストは可能な限りシンプルで直感的なものにします。 アルゴリズムチャレンジとインタビューの準備セクションは別として、学習者は約 2 分以内に各チャレンジを解決する必要があります。
You can close invalid pull requests and reply to them with these [reply templates](moderator-handbook.md#closing-invalid-pull-requests).
無効なプルリクエストをクローズして、この [返信テンプレート](moderator-handbook.md#closing-invalid-pull-requests) で送信します。
If the change looks good, please ensure to leave an approval with a "LGTM" comment. Once a pull request gets at least two approvals (including yours) from the moderators or the dev-team, you can go ahead and merge it.
正しく変更されたら、必ず「LGTM」コメントで承認を残してください。 プルリクエストがモデレーターまたは開発チームから少なくとも 2 つの承認 (あなたを含む) を得たら、マージすることができます。
3. **Platform Changes**
3. **プラットフォームの変更**
These code edits change the functionality of the freeCodeCamp platform itself.
このコード編集により、freeCodeCamp プラットフォーム自体の機能を変更します。
Sometimes contributors try to make changes without much explanation, but for code changes, we need to make sure there's a genuine need for the change. These pull requests should reference an existing GitHub issue where the reasons for the change are discussed. Then you can open the pull request on your computer and test them out locally.
コントリビューターは、説明せずに変更しようとすることがありますが、コードの変更については、その変更が間違いなく必要であることを確認する必要があります。 説明の無いプルリクエストについては、変更理由が説明されている既存の GitHub の問題を参照する必要があります。 その後、コンピュータでプルリクエストをオープンし、ローカルでテストすることができます。
After you've done so, if the changes look good, don't merge them quite yet. You can comment on the pull request saying "LGTM", then mention **"@freeCodeCamp/dev-team"** so they can take a final look.
上記完了後、正しく変更されていても、まだマージしないでください。 「LGTM」とプルリクエストにコメントを残し、**"@freeCodeCamp/dev-team"** と記述することで、開発チームが最終的な確認を行います。
4. **Automated PRs (Dependabot)**
4. **自動 PR (Dependabot)**
Some PRs are automated dependency updates made via an integration. You should not merge or approve these PRs. One of the dev-team members will take care of reviewing and merging such automated PRs.
一部の PR は、インテグレーションにより自動的に依存関係を更新します。 これらの PR をマージまたは承認してはなりません。 開発チームメンバーの 1 人が、このような自動化された PR のレビューとマージを行います。
#### How to review, merge or close pull requests
#### プルリクエストをレビュー、マージ、またはクローズする方法
##### Assign yourself to a pull request:
##### プルリクエストをアサインする
First of all, when you choose a pull request to review, you should assign yourself to it. You can do this by clicking the "assign yourself" link below the "assignees" part on the right-hand column of GitHub's interface.
まず最初に、レビューするプルリクエストを選択するときには、それを自分自身にアサインする必要があります。 GitHub インターフェースの右側の列にある「assignees」の下にある「assign yourself」リンクをクリックします。
Depending on the type of pull request it is, follow the corresponding rules listed previously.
プルリクエストの種類に応じて、対応する上述のルールに従ってください。
##### Ensure the CI checks are passing:
##### CI チェックに合格していることを確認する
Before merging any pull request, make sure that GitHub is reporting all checks to be passing (green check marks) on the pull requests. If you see any of the checks failing, please investigate and clarify the root cause. Is the change being made breaking our tests? Will the site build correctly if the PR is merged? These checks are critical for the stability of the platform.
プルリクエストをマージする前に、GitHubが、プルリクエストですべてのチェックに合格 (緑色のチェックマーク) していることを報告しているかどうかを確認してください。 チェックが不合格の場合は、原因を調べて明確にしてください。 テストに不合格となるような変更ですか? PR がマージされる場合、サイトは正しく構築されますか? これらのチェックはプラットフォームの安定性に不可欠です。
> [!WARNING] Merging a PR that fails CI/CD checks can cause difficulties for all stakeholders, including the dev-team and contributors.
> [!WARNING] CI/CD チェックが不合格の PR をマージすると、開発チームやコントリビューターを含むすべてのステークホルダーに問題を引き起こす可能性があります。
##### Handling merge conflicts:
##### マージの競合を処理する
Sometimes there will be a Merge Conflict.
マージの競合が発生することがあります。
This means that another pull request has made a change to that same part of that same file. GitHub has a tool for addressing these merge conflicts right on GitHub. You can try to address these conflicts. Just use your best judgment.
これは、別のプルリクエストがその同じファイルの同じ部分に変更を加えたことを意味します。 GitHub には、GitHub 上でこれらのマージ競合に対処するためのツールがあります。 皆さんはこれらの競合に対処することができます。 最善の判断をしてください。
The pull request's changes will be on top, and the main branch's changes will be on the bottom. Sometimes there will be redundant information in there that can be deleted. Before you finish, be sure to delete the `<<<<<<`, `======`, and `>>>>>>` that Git adds to indicate areas of conflict.
プルリクエストの変更は一番上にあり、main ブランチの変更は一番下にあります。 次のような、削除可能な冗長な情報がある場合もあります。 終了する前に、Git が競合エリアを表すために追加する `<<<<<<`、`======` および `>>>>>>` を削除してください。
If you are uncertain, please ask one of the fellow moderators or the dev-team for assistance.
ご不明な点がある場合は、モデレーターまたは開発チームにお問い合わせください。
##### Merging a valid pull request:
##### 有効なプルリクエストをマージする
If the pull request looks ready to merge (and doesn't require additional approvals - remember we require at least two), you can go ahead and merge it. Be sure to use the default **"Squash and Merge"** option. This will squash all the pull requests commits down into a single commit, making the Git history much easier to read.
プルリクエストにマージの準備ができている (そして、少なくとも 2 人が承認済みで追加承認が必要ない) 場合、マージすることができます。 デフォルトの **"Squash and Merge"** オプションを使用してください。 これにより、すべてのプルリクエストがコミットされて単一のコミットにスカッシュされ、Git の履歴がより読みやすくなります。
> You should then comment on the pull request, thanking the contributor in your own personal way.
> そして、コントリビューターに感謝の意を示すため、それぞれの書き方でプルリクエストにコメントする必要があります。
If the pull request author is a "first-time contributor" you should also congratulate them on their first merged pull request to the repository. You can look at the upper right-hand corner of the PR's body to determine a first-time contributor. It will show `First-time contributor` as shown below:
プルリクエストの作成者が、「新規コントリビューター」である場合、リポジトリに初めてマージされたプルリクエストに対しても祝意を伝える必要があります。 PR ボディの右上隅を見ると、新規コントリビューターであるかどうかを判断することができます。 以下のように、`First-time contributor` が表示されています。
<details>
<summary>
First time contributor badge on pull requests (screenshot)
プルリクエストの新規コントリビューターバッジ (スクリーンショット)
</summary>
<br>
<img src="https://i.imgur.com/dTQMjGM.png" alt="First time contributor badge on pull requests" />
<img src="https://i.imgur.com/dTQMjGM.png" alt="プルリクエストの新規コントリビューターバッジ" />
</details>
If the pull request doesn't look ready to merge, you can politely reply telling the author what they should do to get it ready. Hopefully, they will reply and get their pull request closer to ready.
プルリクエストにマージの準備ができていない場合は、準備するために何をすべきかを作成者に伝えるために丁寧に返信します。 上手くいけば、作成者から返信があり、プルリクエストの準備に近づけるでしょう。
If you need a second opinion on a pull request, go ahead and leave your comments on the pull request, then add the "discussing" label to the pull request.
プルリクエストにセカンドオピニオンが必要な場合は、プルリクエストにコメントを残してください。そして、プルリクエストに 「discussing」ラベルを追加します。
##### Closing an invalid pull request:
##### 無効なプルリクエストをクローズする
Often, a pull request will be low effort. You can usually tell this immediately when the contributor didn't bother checking the checkboxes in the Pull Request Template or used a generic pull request title like "made changes" or "Update index.md".
大抵の場合、プルリクエストには手間がかかりません。 コントリビューターがプルリクエストテンプレートのチェックボックスにチェックを付けなかったり、「made changes」や「Update index.md」のように特徴のないプルリクエストのタイトルを使用したりした場合は、通常これをすぐに確認できます。
There are also situations where the contributor is trying to add a link to their website, include a library they created, or have a frivolous edit that doesn't help anyone but themselves.
コントリビューターが Web サイトへのリンクを追加しようとしたり、彼らが作成したライブラリを含めようとしたり、彼ら以外の誰にも役に立たない自由な編集をしようとする状況もあります。
You can close invalid pull requests and reply to them with these [reply templates](moderator-handbook.md#closing-invalid-pull-requests).
無効なプルリクエストをクローズして、これらの [返信テンプレート](moderator-handbook.md#closing-invalid-pull-requests) で送信します。
#### Other guidelines for Moderators on GitHub
#### GitHub モデレーターに関するその他のガイドライン
Though you will have write access to freeCodeCamp's repository, **you should never push code directly to freeCodeCamp repositories**. All code should enter freeCodeCamp's codebase in the form of a pull request from a fork of the repository.
freeCodeCamp のリポジトリへの書き込み権限はありますが、**freeCodeCamp リポジトリに直接コードをプッシュしてはいけません**。 すべてのコードは、リポジトリのフォークからのプルリクエストへという形で、freeCodeCamp のコードベースに入る必要があります。
Also, you should never accept your own PRs. They must be reviewed by another moderator, just like any other PR.
また、自分の PR を承認するべきではありません。 他の PR と同様に、別のモデレーターがレビューする必要があります。
If you notice anyone breaking the [code of conduct](https://code-of-conduct.freecodecamp.org) on GitHub issues, or opening pull requests with malicious content or code, email `support[at]freecodecamp.org` with a link to the offending pull request, and we can consider banning them from freeCodeCamp's GitHub organization entirely.
誰かが GitHub Issue に関する [行動規範](https://code-of-conduct.freecodecamp.org) に違反していることに気づいた場合、または悪意あるコンテンツやコードでプルリクエストをオープンしている場合は、問題のあるプルリクエストへのリンクを添付して `support[at]freecodecamp.org` までメールしてください。該当者を freeCodeCamp の GitHub 組織 にアクセスできないようにすることを検討します。
## Moderating the Forum
## フォーラムをモデレートする
As a Moderator, you help keep our community an enjoyable place for anyone to learn and get help. You will deal with flagged posts and handle spam, off-topic, and other inappropriate conversations.
モデレーターとして、コミュニティを、誰もが助けを得ながら学ぶことができる楽しい場所に保つ支援をします。 フラグ付きの投稿やスパム、トピック外の内容、不適切な会話に対処します。
Note that once you are a moderator on the forum, you will start to see blue moderator hints about forum members, like "this is the first time [person] has posted - let's welcome them to the community!" or "[person] hasn't posted in a long time - let's welcome them back."
フォーラムのモデレーターになると、「 [person] さんの初めての投稿です。ようこそコミュニティへ!」または「 [person] さんは長い間投稿していません。投稿があったら歓迎しましょう!」など、フォーラムメンバーに関する青色のモデレーターヒントが表示されるようになります。
![A blue text message saying "this is the first time [person] has posted - let's welcome them to the community!](https://i.imgur.com/mPmVgzK.png)
![「 [person] さんが投稿するのはこれが初めてです。コミュニティに歓迎しましょう!」という青色のテキストメッセージ](https://i.imgur.com/mPmVgzK.png)
These are opportunities for you to welcome them and make them feel extra special. You never know which person who's marginally involved may become our next super-helper, helping many other people in their coding journey. Even the slightest kindness may trigger a cascade of good deeds.
これは、あなたが彼らを歓迎するとともに彼らを特別な気分にさせる機会です。 わずかにしか関与していない人が、次のスーパーヘルパーになり、コーディングの学習で多くの人を助けることになる可能性があります。 ほんの少しの思いやりが、善行の連鎖を引き起こすかもしれません。
### Deleting forum posts
### フォーラムの投稿を削除する
Forum moderators can delete user's posts. You should only do this for the following instances:
フォーラムモデレーターは、ユーザーの投稿を削除できます。 以下の場合にのみ、投稿を削除する必要があります。
1. Someone has posted a pornographic or graphically violent image.
2. Someone has posted a link or code that is malicious in nature and could harm other campers who click on it.
3. Someone has flooded a thread with lots of spam messages.
1. ポルノやグラフィカルに暴力的な画像を投稿している
2. 本質的に悪意のあるリンクやコードを投稿し、それをクリックする他のキャンパーに害を与える可能性がある
3. たくさんのスパムメッセージでスレッドを氾濫させている
### Dealing with spam
### スパムに対処する
For the first spam post of a user, send them a message explaining the problem, and remove the link or post as appropriate. Leave a note on the user's profile explaining the action you have taken. If the problem persists, then quietly block the user from posting (using the silence option on the User Admin panel). Send the user a warning with the Code of Conduct. Check the box in the private message indicating that your message is a "formal warning."
最初のスパム投稿については、問題を説明するメッセージを送信し、必要に応じてリンクや投稿を削除します。 ユーザーのプロフィール欄に、あなたが行ったアクションを説明するメモを残してください。 問題が解決しない場合は、(ユーザー管理パネルのサイレンスオプションを使用して) ユーザーの投稿をブロックします。 行動規範を使用してユーザーに警告を送信します。 プライベートメッセージのボックスにチェックを入れ、メッセージが「正式な警告」であることを示します。
As a moderator, you can ask questions and report incidents in the [staff forum section](https://forum.freecodecamp.org/c/mod-team/4).
モデレーターとして、[スタッフフォーラムセクション](https://forum.freecodecamp.org/c/mod-team/4) でインシデントについて質問したり報告したりできます。
### Dealing with off-topic conversations
### トピック外の会話に対処する
Posts or topics that seem to be in the wrong place can be re-categorized or renamed to whatever would be appropriate.
間違った場所にあるように思われる投稿やトピックは、適切な場所へ再分類したり、名前を変更したりできます。
In exceptional circumstances, it may be appropriate for a moderator to fork a discussion into multiple threads.
例外的な状況として、モデレーターがディスカッションを複数のスレッドにフォークすることが適切である場合があります。
Again, if you have any problems or questions, make a post with your actions in the Staff category, and tag another moderator if you want them to review your moderating actions.
問題や質問がある場合は、スタッフカテゴリでアクションを投稿し、モデレーターとしてのアクションを確認してもらいたい場合は、別のモデレータにタグ付けします。
### Underage Users
### 未成年のユーザー
Our [Terms of Service](https://www.freecodecamp.org/terms) require that freeCodeCamp users be at least 13 years of age. If a user reveals that they are under the age of 13, send them the below message and delete their forum account (if deletion is not available, suspending the account is sufficient).
私たちの [利用規約](https://www.freecodecamp.org/terms) では、freeCodeCamp ユーザーは少なくとも 13 歳である必要があります。 ユーザーが 13 歳未満であることを明らかにした場合、以下のメッセージをユーザーに送信し、そのフォーラムアカウントを削除します (削除できない場合は、アカウントを停止するだけで十分です)。
**Email `support[at]freecodecamp.org` to delete the user's freeCodeCamp account as well.**
**ユーザーの freeCodeCamp アカウントも削除するには、`support[at]freecodecamp.org` にメールしてください。**
```markdown
SUBJECT: Users under 13 are not allowed to use the forum per Terms of Service
件名: 13 歳未満のユーザーは、利用規約によりフォーラムを利用できません
It has come to our attention that you are under 13 years of age. Per the [freeCodeCamp terms of service](https://www.freecodecamp.org/news/terms-of-service), you must be at least 13 years old to use the site or the forum. We will be deleting both your freeCodeCamp account and your forum account. This restriction keeps us in compliance with United States laws.
あなたが 13 歳未満のユーザーの方であるということが判明しました。 [freeCodeCamp 利用規約] (https://www.freecodecamp.org/news/terms-of-service) では、サイトまたはフォーラムを利用するには 13 歳以上である必要があります。 そのため、あなたの freeCodeCamp アカウントとフォーラムアカウントの両方を削除させていただきます。 この制限は米国の法律に準拠したものです。
Please rejoin once you have reached at least 13 years of age.
13 歳以上になってからご参加いただけるのをお待ちしています。
Thank you for understanding.
ご理解のほどよろしくお願いいたします。
```
## Moderating Facebook
## Facebook をモデレートする
If you see anything that seems to break our [Code of Conduct](https://code-of-conduct.freecodecamp.org/), you should delete it immediately.
私たちの [行動規範](https://code-of-conduct.freecodecamp.org/) に違反するようなものがあれば、すぐに削除してください。
Sometimes people will post things that they think are funny. They don't realize that what they said or what they shared could be interpreted as offensive. You should delete such posts, but not necessarily ban the person. Hopefully, the user will come to understand that what they posted was inappropriate because the post was deleted.
自分が面白いと思うことを投稿する人が時々います。 彼らは、自分たちが言ったこと、シェアしたことが攻撃的だと解釈され得ることに気づいていません。 そのような投稿は削除する必要がありますが、必ずしもその人のアクセスを禁じるわけではありません。 投稿が削除されることにより、ユーザーは投稿内容が不適切だったと気づくことになるでしょう。
But if it is an egregious offense that can't reasonably be attributed to a cultural difference or a misunderstanding of the English language. In that case, you should strongly consider blocking the member from the Facebook group.
しかし、それが文化的な違いや英語での誤解では説明できない酷い犯罪である場合もあります。 その場合、Facebook グループからメンバーをブロックすることを検討するべきです。
## Moderating Chat
## チャットをモデレートする
Here's how moderators deal with violations of our [Code of Conduct](https://code-of-conduct.freecodecamp.org/) on our chat server:
モデレーターは、以下のように、チャットサーバー上の [行動規範](https://code-of-conduct.freecodecamp.org/) の違反に対処します。
1. **Make sure the user intended to violate the Code of Conduct.**
1. **ユーザーが、意図して行動規範に違反していることを確認します。**
Not all violations of the CoC were intended as such. A new camper might post a large amount of code for help, unaware that this can be considered spamming. In these cases, you can just ask them to paste their code with services like CodePen or Pastebin.
CoC のすべての違反がそのように意図されているわけではありません。 新しいキャンパーは、スパムであると気づかずに、支援のために大量のコードを投稿する場合もあります。 この場合、CodePen や Pastebin のようなサービスを使用してコードを貼り付けるようにキャンパーに依頼することができます。
2. **If the camper clearly and intentionally violates the Code of Conduct, the moderator will proceed as follows:**
2. **キャンパーが、明確かつ意図的に行動規範に違反した場合、モデレーターは以下を実行します。**
Kick or mute the offending person from the chat room. To kick or mute someone, left-click on their profile picture, select the three dots, and select "Remove from room" to kick or "Mute user" to prevent them from sending messages. Then report a short summary of the event in the #mod-log channel. Here's an example of what such a summary might look like:
チャットルームから問題のある人を退出させたり、ミュートしたりします。 誰かを退出させるまたはミュートするには、彼らのプロフィール画像上で左クリックして、3 つの点を選択します。 そして、「ルームから削除」を選択して退出させるか、「ユーザーをミュート」を選択してメッセージを送信できないようにします。 その後、#mod-log チャネルでその概要を報告します。 以下は、そのような概要の例です。
```
Kicked: _@username_
@ -226,182 +226,182 @@ Here's how moderators deal with violations of our [Code of Conduct](https://code
Evidence: _One or more links to the offending message(s)_
```
3. **Creating a Private Discussion**
3. **プライベートディスカッションを作成します。**
There may be situations where you need to address a concern with a camper privately. This should not be done through DMs, which can lead to situations where you claim one thing and the camper claims another. Instead, use the bot's functionality to create a private discussion:
キャンパーに関わる懸念事項に対して個人的に対処する必要のある場合があるかもしれません。 これは、DM を通じて行うべきではありません。あなたがあることを主張し、キャンパーがそれとは別のことを主張する状況につながる可能性があります。 代わりに、bot の機能を使用してプライベートディスカッションを作成してください。
- Call the `!fCC private username` command, where `username` is the camper's chat username.
- The bot will create a new channel, and add the mentioned camper and all moderators with the `Your Friendly Moderator` role. While all moderators are added to the channel for transparency, the moderator who calls this command should be the only one to interact with the camper unless they request assistance.
- When the conversation is complete, call the `!fCC close` command _in the private channel_ to have the bot close and delete that channel.
- `!fCC private username` コマンドを呼び出します。ここでは、`username` が、キャンパーのチャットユーザー名です。
- bot は新しいチャンネルを作成し、上述のキャンパーと `Your Friendly Moderator` の役割を持つすべてのモデレーターをディスカッションに追加します。 透明性を保つため、すべてのモデレーターをチャンネルに追加しますが、支援を求めない限り、このコマンドを呼び出すモデレーターがキャンパーと接触する唯一の人であるべきです。
- ディスカッションが完了したら、_プライベートチャンネル_ にある `!fCC close` コマンドを呼び出し、bot をクローズしてそのチャンネルを削除します。
4. **Deleting Messages**
4. **メッセージを削除します。**
Moderators can delete messages on our chat server. They should only exercise this ability in four very specific situations:
モデレーターは、チャットサーバー上のメッセージを削除できます。 モデレーターは、以下 4 つの非常に特定の状況でのみこの機能を行使します。
- Someone has posted a pornographic or graphically violent image.
- ポルノやグラフィカルに暴力的な画像を投稿している
- Someone has posted a link or code that is malicious in nature and could harm other campers who click on it.
- 本質的に悪意のあるリンクやコードを投稿し、それをクリックする他のキャンパーに害を与える可能性がある
- Someone has flooded the chat with lots of spam messages to such an extreme extent (usually involving bots) to render chat completely unusable.
- 非常に多くのスパムメッセージ (通常 bot も含む) を送ることでチャットを溢れさせ、チャットを完全に使用不能にしている
- Someone has posted an advertisement and/or a self-promoting message/image (social media).
- 広告や自己宣伝メッセージ / イメージ (ソーシャルメディア) を投稿している
In all other situations - even situations where the code of conduct is violated - moderators should not delete the messages as they are important historic records. When you do delete a message, make sure you take a screenshot of it first! The screenshot can be logged in the #mod-log channel.
他のすべての状況において (たとえ行動規範に違反している場合でも)、モデレーターは、メッセージを削除してはなりません。なぜなら、それらは重要な記録だからです。 メッセージを削除する場合は、まずスクリーンショットを撮ってください! スクリーンショットは #mod-log チャンネルに記録することができます。
> [!NOTE] If the message contains material that would be illegal to take a screenshot of, copy the message link instead - provide that message link to @raisedadead to forward to Discord's Trust and Safety team.
> [!NOTE] スクリーンショットを撮ることが違法となる素材がメッセージに含まれている場合、代わりにメッセージリンクをコピーしてください。そのメッセージリンクを @raisedadead へ提供して、Discord の Trust & Safety チームへ転送します。
5. **Dont use @all or @here**
5. **@all または @here は使用しません。**
Dont use @all or @here under any circumstances! Every single person in that chat room will get a notification. In some cases, tens of thousands of people.
どんな状況下でも、@all または @here を使用しないでください! チャットルームにいるすべての人に通知が届いてしまいます。 場合によっては、何万人もの人々に通知が届きます。
Instead, if you want people to see an announcement, you can pin it to the channel to allow everyone to read it.
多くの人にアナウンスメントを見て欲しい場合は、誰もが読むことができるようにチャンネルに固定することができます。
6. **Dont threaten to take action**
6. **アクションを起こすと脅してはなりません。**
If a camper breaks the code of conduct, dont threaten to take moderator action, and never warn them in public. Instead, talk to them privately using the bot's `private` command. No one else in that channel needs to know that you banned/suspended the person. If a violation was clearly unintended and doesn't warrant a suspension or private conversation, make the offending camper aware of his / her actions without making it come across as a warning. For example:
キャンパーが行動規範に違反した場合、モデレーターとしてアクションを起こすと言って脅してはなりません。また、公の場でキャンパーに対し警告を与えてはなりません。 代わりに、bot の `private` コマンドを使用して彼らと非公開で話をします。 あなたがその人を利用禁止 / 一時利用停止したという事実は、そのチャンネルで誰も知る必要はありません。 明らかに意図された違反ではなく、一時利用停止や個人的な会話を行うことが当然であるとは言えない場合には、警告としての印象を与えずに、違反しているキャンパーにその行動が問題であることを認識させます。 例を示します。
- Camper posts a wall of code to request help:
- キャンパーが大量のコードを投稿して支援を要求する場合
Moderator: @username Please use CodePen or Pastebin when posting large amounts of code.
モデレーター: @username 大量のコードを投稿する場合は CodePen または Pastebin を使用してください。
- Or if you really have to explain why:
- 上記対応の理由も説明する必要がある場合
Moderator: @username Please use CodePen or Pastebin when posting large amounts of code, because it disrupts the chat for everyone and could be considered spamming according to our Code of Conduct.
モデレーター: @username 大量のコードを投稿する場合は CodePen または Pastebin を使用してください。なぜなら、チャットを混乱させ、私たちの行動規範によりスパムとみなされる可能性があるからです。
- For mild and unintentional violations of the code of conduct:
- 行動規範に対する軽微および意図しない違反
Moderator: This is a friendly reminder for everyone to follow the code of conduct: https://code-of-conduct.freecodecamp.org/
モデレーター: 皆さんに遵守いただきたい行動規範を念のためお知らせいたします。https://code-of-conduct.freecodecamp.org/ をご覧ください。
7. **Dont brag about being a moderator**
7. **モデレーターであることを自慢してはなりません。**
Do not see yourself as above the community. You are the community. And the community has trusted you to help protect something rare that we all share - a _welcoming_ place for new developers.
自分がコミュニティの上にいるとは思わないでください。 皆さんはコミュニティの中にいます。 コミュニティは、共有する素晴らしいもの、つまり、新しい開発者を _歓迎する_ 場所、を皆さんが保護してくれると信じています。
If you brag about being a moderator, people may feel uneasy around you, in the same way that people may feel uneasy around a police officer, even if theyre doing nothing wrong. This is just human nature.
モデレーターであることを自慢すれば、周囲の人は不安を感じるかもしれません。何も悪いことをしていなくても、警察官の周りにいると不安を感じるのと同じです。 それが人間の本質なのです。
8. **Dont contradict other moderators**
8. **他のモデレーターを批判してはなりません。**
If you disagree with a moderator's action, talk with them in private or bring it up in the #mod-chat channel. Never override a moderator's action, and never contradict the other moderator(s) publicly. Instead, have a cool-headed discussion in `#mod-chat` and convince the moderator that they themselves should reverse their ban or change their point of view.
モデレーターのアクションに同意できない場合は、プライベートまたは #mod-chat チャンネルで相談してください。 モデレーターのアクションを無効にしないでください。他のモデレーターを公に批判してはいけません。 代わりに、`#mod-chat` で冷静なディスカッションを行い、利用禁止を取り消したり、視点を変えたりするように、そのモデレーターを説得します。
Remember: were all on the same team. We want to dignify the role of moderators and present a unified front.
私たちは皆同じチームに所属していることを忘れないでください。 モデレーターの役割を尊重し、統一戦線の形を取りたいと考えています。
9. **Talk with other moderators**
9. **他のモデレーターと話をします。**
We have a room for moderators only. Use it! If you feel uncomfortable with handling a certain situation, ask other moderators for help. If you think something should be discussed, do it. You're part of the team, and we value every team member's input! Even if you totally disagree with anything in these guidelines or the Code of Conduct!
モデレータ専用のルームがあります。 それを使ってみましょう! 特定の状況を処理することを不快に感じる場合は、他のモデレーターに支援を求めてください。 議論されるべきことがあると思ったら、議論してください。 皆さんはチームの一員であり、私たちはすべてのチームメンバーからのインプットを大切にしています! 皆さんが、ガイドラインや行動規範に完全に同意していないとしても、皆さんからの意見を大切にします!
10. **Temporarily inactive**
10. **一時的に非アクティブにします。**
If you're not going to be active as a Moderator for a while due to vacation, illness, or any other reason, make sure to let the others know in the `#mod-chat` channel. This is so we know if we can count on you to be regularly active on the server or not.
休暇、病気、または他の理由により、しばらくモデレーターとして活動できない場合は、`#mod-chat` チャンネルで他の人に知らせるようにしてください。 そうすることで、皆さんがサーバー上で通常どおり活動しているかどうかを認識することができます。
## How to become a moderator
## モデレーターになる方法
Suppose you are helping people in the community consistently over time. In that case, our Moderator Team will eventually take notice, and one of them will mention you as a possible moderator to [our staff](https://forum.freecodecamp.org/g/Team). There are no shortcuts to becoming a moderator.
皆さんが、長い期間一貫してコミュニティの人を支援しているとします。 その場合、やがてモデレーターチームが気づき、チームの誰かが、あなたのことをモデレーター候補として [私たちスタッフ](https://forum.freecodecamp.org/g/Team) に知らせることになります。 モデレーターになるための近道はありません。
If you are approved, we will add you to our Moderator Teams on [GitHub](https://github.com/orgs/freeCodeCamp/teams/moderators), [forum](https://forum.freecodecamp.org/g/moderators), and chat etc.
承認されると、皆さんは、[GitHub](https://github.com/orgs/freeCodeCamp/teams/moderators)、[フォーラム](https://forum.freecodecamp.org/g/moderators)、チャットなどのモデレーターチームに追加されます。
> [!NOTE] For GitHub: After you've been accepted as a moderator, you will receive a Github repository invitation. You'll need to head over towards [freeCodeCamp GitHub Organisation Invitation](https://github.com/orgs/freeCodeCamp/invitation) to be able to accept the invitation.
> [!NOTE] GitHub の場合: モデレータとして承認されると、Github リポジトリへの招待が届きます。 招待を承認するには、[freeCodeCamp GitHub Organization Invitation](https://github.com/orgs/freeCodeCamp/invitation) に進む必要があります。
>
> This is required for us to be able to give you write access to some of our repositories.
> これは、一部のリポジトリへの書き込みアクセスを提供するために必要となります。
## How we retire inactive moderators
## 非アクティブモデレーターの削除方法
Please note that we will frequently remove mods whom we think are inactive. When we do this, we will send the following message:
非アクティブと思われるモデレーターは頻繁に削除します。 削除すると、次のようなメッセージが送信されます。
```markdown
This is a standard message notifying you that, since you don't seem to have been an active moderator recently, we're removing you from our Moderator team. We deeply appreciate your help in the past.
最近アクティブではないモデレーターの方にお送りしている通知メッセージです。最近の活動が少なくなっているようですので、モデレーターチームから削除させていだきます。 これまでのご支援に深く感謝いたします。
If you think we did this in error, or once you're ready to come back and contribute more, just reply to this message letting me know.
私たちの理解が誤っている場合、再度貢献できる状況になった場合には、このメッセージに返信する形でどうぞお知らせください。
```
## How our Contributors room works
## Contributors ルームの仕組み
Anyone is welcome in the [Contributors room on our chat server](https://chat.freecodecamp.org/channel/contributors). It is the designated chat room for moderators and other campers who contribute to our community in any number of ways, including through study groups.
[チャットサーバーの contributors ルーム](https://chat.freecodecamp.org/channel/contributors) は、どなたでも歓迎します。 学習グループなど、様々な方法でコミュニティに貢献しているモデレーターやキャンパーのための専用のチャットルームです。
We assume contributors will read anything in this room that directly mentions them with an `@username`. Everything else is optional, but feel free to read anything anyone posts in there and interact.
`@username` で直接言及しているものを、コントリビューターがこのルームで読むことを想定しています。 他はすべて任意ですが、自由に誰かの投稿を読んだり交流したりしてください。
## Dealing with solicitors
## 勧誘者への対応
You may be approached by organizations who want to partner or co-brand with freeCodeCamp somehow. Once you realize that this is what they're after, **please stop talking to them** and tell them to email `team[at]freecodecamp.org`.
freeCodeCamp と連携またはブランド提携したい団体から、アプローチを受ける場合があります。 そのようなことを求めていると気が付いたら、**その団体と話しをすることを止めて**、`team[at]freecodecamp.org` にメールを書くように伝えてください。
We get proposals like this all the time, and the staff are in the best position to judge whether such a relationship will be worth it for our community (and it rarely is).
私たちは、いつもこのような提案を受けています。スタッフは、そのような関係が私たちのコミュニティにとって価値があるのかどうか (ほとんどの場合そうではありません) を判断するのに最適な立場にあります。
## Dealing with (mental) health inquiries
## (メンタル) ヘルスに関する問い合わせへの対応
You may come across situations where users seek medical advice or are dealing with mental health issues and are looking for support.
ユーザーが医療アドバイスを求めたり、メンタルヘルスの問題でサポートを求めたりする状況に遭遇することがあります。
As a matter of policy, you should avoid talking privately about these matters. Should the situation reflect back to freeCodeCamp, we want to have the conversation(s) on record. Make it clear that we are not medical professionals and that you encourage the user to find professional help.
ポリシー上、これらの問題について個人的に話すことは避けるべきです。 もしその状況が freeCodeCamp に反映された場合、私たちはその会話を記録します。 私たちは医療の専門家ではないこと、そしてユーザー自身が専門的な支援を見つけることを推奨していることを明確にしてください。
As difficult as it sometimes can be, avoid giving any tips or advice other than pointing the user in the direction of professional help!
難しい場合もありますが、ユーザーを専門家の支援の方向に向けてください。ヒントやアドバイスを与えることを避けてください!
If this happens on our chat server: Create a private channel for the user and the mod team. This can be done with the bot's `private` command.
これが、チャットサーバーで発生した場合は、ユーザーとモデレーターチームのプライベートチャンネルを作成してください。 bot の `private` コマンドで作成することができます。
- The user is guaranteed some privacy
- Public chat is no longer disrupted
- Other team members can pitch in, should you be uncomfortable dealing with the situation yourself
- ユーザーはプライバシーを保証されています。
- パブリックチャットはもう中断されません
- 対応に気まずさを感じる場合は、他のチームメンバーが支援することができます。
Helpful URLs:
参考URL:
http://www.suicide.org/international-suicide-hotlines.html
## A note on free speech
## 言論の自由に関する注意点
Sometimes people will defend something offensive or incendiary that they said as "free speech."
人々は、「言論の自由」として述べた攻撃的または扇情的な何かを擁護しようとする場合があります。
This XKCD comic summarizes perfectly most communities' thoughts on free speech. So if someone defends something in the name of "free speech", feel free to send it to them.
この XKCD 漫画は、言論の自由に対するコミュニティでの考えを要約しています。 誰かが「言論の自由」という名目で何かを擁護する場合、これをその人たちに送ってください。
<div align="center"><img src='https://aws1.discourse-cdn.com/freecodecamp/original/3X/4/3/43a8b2eafe4c8622e02838f66f1dc6227de32c70.png' width="400" height="400" /></div>
Thanks for reading this, and thanks for helping the developer community!
お読みいただきありがとうございます。また開発者コミュニティを支援してくださってありがとうございます!
## Reply Templates
## 返信テンプレート
These are some of the standard reply templates that you may use while reviewing pull requests and triaging issues and pull requests.
以下は、プルリクエストをレビューしたり、問題やプルリクエストをトリアージしたりする際に使用できる標準的な返信テンプレートです。
> You can make your own with GitHub's built-in [**Saved replies**](https://github.com/settings/replies/) feature or use the ones below.
> GitHub のビルトインの [**Saved replies**](https://github.com/settings/replies/) 機能を使用して自分で作成するか、以下の機能を使用することができます。
### Thank you
### お礼
```markdown
Thank you for your contribution to the page! 👍
We are happy to accept these changes and look forward to future contributions. 🎉
このページに貢献していただきありがとうございます! 👍
喜んでこれらの変更を承認いたします。今後の貢献に期待しています。 🎉
```
### Thank you and congrats
### お礼と祝福
> For thanking and encouraging first-time contributors.
> 新規コントリビューターへの感謝と励まし
```markdown
Hi @username. Congrats on your first pull request (PR)! 🎉
@usernameさん、こんにちは。 最初のプルリクエスト (PR) おめでとうございます! 🎉
Thank you for your contribution to the page! 👍
We are happy to accept these changes and look forward to future contributions. 📝
このページに貢献していただきありがとうございます! 👍
喜んでこれらの変更を承認いたします。今後の貢献に期待しています。 📝
```
### Build Error
### ビルドエラー
```markdown
Hey @username
@username さん、こんにちは。
We would love to be able to merge your changes but it looks like there is an error with the CI build. ⚠️
変更をマージしたいのですが、CI ビルドでエラーが発生しています。 ⚠️
Once you resolve these issues, we will be able to review your PR and merge it. 😊
この問題が解決すれば、PR を確認してマージすることができます。 😊
---
Feel free to reference the [contributing guidelines](how-to-work-on-coding-challenges.md#testing-challenges) for instructions on running the CI build locally.
CI ビルドをローカルで実行する手順については、[貢献ガイドライン] (how-to-work-on-coding-challenges.md#testing-challenges) を参照してください。
```
### Syncing Fork
### フォークの同期
> When PR is not up to date with the `main` branch.
> PR が、最新の `main` ブランチで更新されていない場合
````markdown
Hey @username
@username さん、こんにちは。
We would love to be able to merge your changes, but it looks like the branch is not up to date. ⚠️
変更をマージしたいのですが、ブランチが最新ではないようです。 ⚠️
To resolve this error, you will have to sync the latest changes from the `main` branch of the `freeCodeCamp/freeCodeCamp` repo.
このエラーを解決するには、 `freeCodeCamp/freeCodeCamp` リポジトリの `main` ブランチから最新の変更を同期する必要があります。
Using the command line, you can do this in three easy steps:
コマンドラインを使用すると、次の 3 つの簡単な手順でこれを実行できます。
```bash
git remote add upstream git://github.com/freeCodeCamp/freeCodeCamp.git
@ -411,129 +411,129 @@ git fetch upstream
git pull upstream main
````
If you're using a GUI, you can simply `Add a new remote...` and use the link `git://github.com/freeCodeCamp/freeCodeCamp.git` from above.
GUI を使用している場合は、単純に `Add a new remote...` を使用するとともに、上記の `git://github.com/freeCodeCamp/freeCodeCamp.git` のリンクを使用してください。
Once you sync your fork and pass the build, we will be able to review your PR and merge it. 😊
フォークを同期してビルドに合格すると、PR をレビューしてマージすることができます。 😊
---
Feel free to reference the [Syncing a Fork](https://help.github.com/articles/syncing-a-fork/) article on GitHub for more insight on how to keep your fork up-to-date with the upstream repository. 🔄
アップストリームリポジトリでフォークを最新状態に保つ方法については、GitHub 上の [フォークの同期](https://help.github.com/articles/syncing-a-fork/) 記事を参照してください。 🔄
````
### Merge Conflicts
### マージ競合
> When PR has merge conflicts that need to be resolved.¹
> PR に解決すべきマージ競合がある場合
```markdown
Hey @username
@username さん、こんにちは。
We would love to be able to merge your changes, but it looks like you have some merge conflicts. ⚠️
変更をマージしたいのですが、マージが競合しているようです。 ⚠️
Once you resolve these conflicts, we will be able to review your PR and merge it. 😊
この問題が解決すれば、PR を確認してマージすることができます。 😊
---
--
If you're not familiar with the merge conflict process, feel free to look over GitHub's guide on ["Resolving a merge conflict"](https://help.github.com/articles/resolving-a-merge-conflict-on-github/). 🔍️
マージ競合プロセスに慣れていない場合は、GitHub のガイド の [「マージ競合の解決」] をご覧ください (https://help.github.com/articles/resolving-a-merge-conflict-on-github/)。 🔍
Also, it's good practice on GitHub to write a brief description of your changes when creating a PR. 📝
また、GitHub で PR を作成する際に、変更に関する簡単な説明を記述することをお勧めします。 📝
````
¹ If a first-time-contributor has a merge conflict, maintainers will resolve the conflict for them.
¹ 新規コントリビューターにマージ競合が発生した場合、メンテナーがその競合を解決します。
### Duplicate
### 重複
> When PR is repetitive or a duplicate.
> PR が反復または重複している場合
```markdown
Hey @username
@username さん
This PR seems to make similar changes as the existing PR <#number>. As such, we are going to close this as duplicate.
この PR は、既存の PR <#number> と同様の変更を行っているようです。 そのため、重複としてこの PR をクローズします。
If you feel you have additional changes to expand upon this PR, please feel free to push your commits and request this PR be reopened.
この PR を拡張するために追加変更したい場合は、自由にコミットをプッシュし、この PR を再オープンするようリクエストしてください。
Thanks again! 😊
よろしくお願いいたします! 😊
---
If you have any questions, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [the contributors chat room](https://chat.freecodecamp.org/channel/contributors).
質問がございましたら、[フォーラムの 「Contributors」カテゴリ](https://forum.freecodecamp.org/c/contributors) もしくは、[contributors チャットルーム] (https://chat.freecodecamp.org/channel/contributors) までお気軽にお問合せください。
```
### Closing invalid pull requests
### 無効なプルリクエストをクローズする
> When PR is invalid.
> PR が無効な場合
```markdown
Hey @username
@username さん、こんにちは。
Thank you for opening this pull request.
プルリクエストをオープンしていただきありがとうございました。
This is a standard message notifying you that we've reviewed your pull request and have decided not to merge it. We would welcome future pull requests from you.
プルリクエストをレビューしました結果、マージしないことを決定しましたのでお知らせいたします。 今後、またプルリクエストを作成していただけることを期待しております。
Thank you and happy coding.
ご理解のほどよろしくお願いいたします。
```
> When PR adds links to external resources.
> PR が外部リソースへのリンクを追加している場合
```markdown
Thank you for your pull request.
プルリクエストを作成していただきありがとうございました。
We are closing this pull request. Please suggest links and other details to add the challenge's corresponding guide post through [a forum topic](https://forum.freecodecamp.org/new-topic?category=Contributors&title=&body=**What%20is%20your%20hint%20or%20solution%20suggestion%3F**%0A%0A%0A%0A%0A**Challenge%3A**%0A%0A%0A**Link%20to%20the%20challenge%3A**) instead.
しかしながら、このプルリクエストをクローズさせていただきます。 [フォーラムトピック] (https://forum.freecodecamp.org/new-topic?category=Contributors&title=&body=**What%20is%20your%20hint%20or%20solution%20suggestion%3F**%0A%0A%0A%0A%0A**Challenge%3A**%0A%0A%0A**Link%20to%20the%20challenge%3A**) に投稿されているチャレンジの該当ガイドを追加するためのリンクおよびその他詳細を提案してください。
If you think we're wrong in closing this issue, please request for it to be reopened and add further clarification. Thank you, and happy coding.
この Issue をクローズすることが誤りであると思われる場合は、再オープンをリクエストして説明を追加してください。 ご理解のほどよろしくお願いいたします。
```
### Closing Invalid Issues
### 無効な Issue をクローズする
> When an issue relates to the camper's code.
> Issue がキャンパーのコードに関連する場合
```markdown
Thank you for reporting this issue.
この問題を報告していただきありがとうございます。
This is a standard message notifying you that this issue seems to be a request for help. Instead of asking for help here, please click the **"Get Help"** button on the challenge on freeCodeCamp and choose the **"Ask for help"** option, which will help you create a question in the right part of the forum. Volunteers on the forum usually respond to questions within a few hours and can help determine if there is an issue with your code or the challenge's tests.
しかしながら、これは支援リクエストであるように思われますのでお知らせいたします。 ここで支援を求めるのではなく、freeCodeCamp のチャレンジにある **"Get Help"** ボタンをクリックして **"Ask for help"** オプションを選択してください。フォーラムの右側に質問を作成することができます。 フォーラムのボランティアが通常数時間以内に質問に対して回答し、コードもしくはチャレンジテストに問題があるかどうかを判断します。
If the forum members determine there is nothing wrong with your code, you can request this issue to be reopened.
フォーラムメンバーによりコードに問題がないと判断された場合は、この問題を再オープンするようにリクエストすることができます。
Thank you and happy coding.
ご理解のほどよろしくお願いいたします。
```
> When an issue is duplicate of an earlier issue
> Issue が以前の Issue と重複している場合
```markdown
Thank you for reporting this issue.
この問題を報告していただきありがとうございます。
This is a standard message notifying you that this issue appears to be very similar to issue #XXXXX, so we are closing it as a duplicate.
この問題は、#XXXXX と非常によく似ているので、重複としてクローズすることをお知らせいたします。
If you think we're wrong in closing this issue, please request for it to be reopened and add further clarification. Thank you and happy coding.
この問題をクローズすることが誤りであると思われる場合は、再オープンをリクエストし説明を追加してください。 ご理解のほどよろしくお願いいたします。
```
> When an issue is fixed in staging.
> Issue がステージングで修正された場合
```markdown
Thank you for reporting this issue.
この問題を報告していただきありがとうございます。
This is a standard message notifying you that the problem you mentioned here is present in production, but that it has already been fixed in staging. This means that the next time we push our staging branch to production, this problem should be fixed. Because of this, we're closing this issue.
言及された問題は本番環境に存在していますが、ステージングで既に修正されていますのでお知らせいいたします。 これは、次回ステージングブランチを本番環境にプッシュする際に、この問題を修正する必要があることを意味します。 そのため、この問題はクローズいたします。
If you think we're wrong in closing this issue, please request for it to be reopened and add further clarification. Thank you and happy coding.
この問題をクローズすることが誤りであると思われる場合は、再オープンをリクエストし説明を追加してください。 ご理解のほどよろしくお願いいたします。
```
### First Timer Only Issues
### 初回者用の Issue
> When an issue is deemed to be eligible for first time code contributors.
> Issue が新規コードコントリビューターの対象となる場合
```markdown
Thanks for opening this issue.
この問題をオープンしていただきありがとうございます。
This looks like something that can be fixed by "first time" code contributors to this repository. Here are the files that you should be looking at to work on a fix:
これは、このリポジトリへの「新規」コードコントリビューターによって修正できるようです。 修正するために調べるべきファイルは次のとおりです:
List of files:
ファイルのリスト:
1. ...
2. ...
3. ...
Please make sure you read [our guidelines for contributing](https://contribute.freecodecamp.org/#/), we prioritize contributors following the instructions in our guides. Join us in [our chat room](https://chat.freecodecamp.org/channel/contributors) or [the forum](https://forum.freecodecamp.org/c/contributors/3) if you need help contributing, our moderators will guide you through this.
[貢献に関するガイドライン] (https://contribute.freecodecamp.org/#/) を必ずお読みください。私たちは、ガイドの指示に従ってコントリビューターに優先順位を付けます。 [チャットルーム] (https://chat.freecodecamp.org/channel/contributors) もしくは [フォーラム] (https://forum.freecodecamp.org/c/contributors/3) に参加してください。貢献するのに支援が必要な場合、モデレーターがガイドいたします。
Sometimes we may get more than one pull request. We typically accept the most quality contribution followed by the one that is made first.
複数のプルリクエストを受け取ることもあります。 私たちは通常、最も質の高い貢献を受け入れ、その後に最初の貢献を受け入れます。
Happy contributing.
貢献をお楽しみください。
```

View File

@ -1,10 +1,10 @@
# Responsible Disclosure - Hall of Fame
# 責任ある開示 - 殿堂入り
We appreciate any responsible disclosure of vulnerabilities that might impact the integrity of our platforms and users. If you are interested in contributing to the security of our platform, please read our [security policy outlined here](https://contribute.freecodecamp.org/#/security).
私たちのプラットフォームおよびユーザーの整合性に影響を与える可能性のある脆弱性について、責任ある開示をお願いします。 私たちのプラットフォームのセキュリティに貢献したい方は、[セキュリティポリシー](https://contribute.freecodecamp.org/#/security) をお読みください。
While we do not offer any bounties or swags at the moment, we are grateful to these awesome people for helping us keep the platform safe for everyone:
現時点ではいかなる報奨金も報酬も提供していませんが、プラットフォームの安全性を守ってくださる皆さんに心から感謝しています。
- Mehul Mohan from [codedamn](https://codedamn.com) ([@mehulmpt](https://twitter.com/mehulmpt)) - [Vulnerability Fix](https://github.com/freeCodeCamp/freeCodeCamp/blob/bb5a9e815313f1f7c91338e171bfe5acb8f3e346/client/src/components/Flash/index.js)
- Peter Samir https://www.linkedin.com/in/peter-samir/
- Mehul Mohan ([codedamn](https://codedamn.com) 所属) ([@mehulmpt](https://twitter.com/mehulmpt)) - [脆弱性修正](https://github.com/freeCodeCamp/freeCodeCamp/blob/bb5a9e815313f1f7c91338e171bfe5acb8f3e346/client/src/components/Flash/index.js)
- Peter Samir (https://www.linkedin.com/in/peter-samir/)
> ### Thank you for your contributions :pray:
> ### ご尽力いただきありがとうございます :pray:

View File

@ -1,46 +1,46 @@
# Security Policy
# セキュリティポリシー
This document outlines our security policy for the codebases, platforms that we operate, and how to report vulnerabilities.
このドキュメントでは、コードベース、運用プラットフォーム、および脆弱性の報告方法に関するセキュリティポリシーについて概説します。
## Reporting a Vulnerability
## 脆弱性の報告
If you think you have found a vulnerability, _please report responsibly_. Don't create GitHub issues for security issues. Instead, please send an email to `security@freecodecamp.org` and we'll look into it immediately.
脆弱性を発見したと思われる場合は、_責任を持って報告してください_。 セキュリティ問題のために GitHub Issue を作成しないでください。 その代わりに、`security@freecodecamp.org` にメールを送信してください。私たちが直ちに調査します。
Ensure that you are using the **latest**, **stable** and **updated** version of the Operating System and Web Browser available to you on your machine.
お使いのマシンで使用できるオペレーティングシステムとウェブブラウザの **最新**、**安定**、および **更新** バージョンを使用していることを確認してください。
We appreciate any responsible disclosure of vulnerabilities that might impact the integrity of our platforms and users.
私たちのプラットフォームおよびユーザーの整合性に影響を与える可能性のある脆弱性について、責任ある開示をお願いします。
Once you report a vulnerability, we will look into it and make sure that it is not a false positive. We will get back to you if we need to clarify any details. You can submit separate reports for each issue you find.
脆弱性が報告されたら、それを調査し誤検知ではないことを確認します。 詳細を明確にする必要がある場合は、ご連絡いたします。 発見した各問題について個別にレポートを提出することができます。
While we do not offer any bounties or swags at the moment, we'll be happy to list your name in our [Hall of Fame](https://contribute.freecodecamp.org/#/security-hall-of-fame) list, provided the reports are not low-effort.
現時点ではいかなる報奨金も報酬も提供していませんが、その報告に多大なご尽力をいただいた場合、[殿堂入り](https://contribute.freecodecamp.org/#/security-hall-of-fame) リストにお名前を掲示します。
We consider using tools & online utilities to report issues with SPF & DKIM configs, or SSL Server tests, etc. in the category of ["beg bounties"](https://www.troyhunt.com/beg-bounties/) and are unable to respond to these reports.
私たちは、[「beg bounties」](https://www.troyhunt.com/beg-bounties/) カテゴリの SPF & DKIM 構成、または SSL サーバーテスト等に関する問題を報告するため、ツール & オンラインユーティリティを使用することを検討します。それらの報告に対して対応することはできません。
## Platforms & Codebases
## プラットフォーム & コードベース
Here is a list of the platforms and codebases we are accepting reports for:
報告を受け付けるプラットフォームとコードベースのリストは以下のとおりです。
### Learn Platform
### 学習プラットフォーム
| Version | Branch | Supported | Website active |
| ----------- | -------------- | --------- | ------------------------ |
| production | `prod-current` | Yes | `freecodecamp.org/learn` |
| staging | `prod-staging` | Yes | `freecodecamp.dev/learn` |
| development | `main` | No | |
| バージョン | ブランチ | サポート | 有効な Web サイト |
| ------ | -------------- | ---- | ------------------------ |
| 生産 | `prod-current` | 有 | `freecodecamp.org/learn` |
| ステージング | `prod-staging` | 有 | `freecodecamp.dev/learn` |
| 開発 | `main` | 無 | |
### Publication Platform
### 公開プラットフォーム
| Version | Supported | Website active |
| ---------- | --------- | ---------------------------------------- |
| production | Yes | `freecodecamp.org/news` |
| localized | Yes | `freecodecamp.org/<language>/news` |
| バージョン | サポート | 有効な Web サイト |
| ------ | ---- | ---------------------------------------- |
| 生産 | 有 | `freecodecamp.org/news` |
| ローカライズ | 有 | `freecodecamp.org/<language>/news` |
### Mobile app
### モバイルアプリ
| Version | Supported | Website active |
| ---------- | --------- | ---------------------------------------------------------------- |
| production | Yes | `https://play.google.com/store/apps/details?id=org.freecodecamp` |
| バージョン | サポート | 有効な Web サイト |
| ----- | ---- | ---------------------------------------------------------------- |
| 生産 | 有 | `https://play.google.com/store/apps/details?id=org.freecodecamp` |
Apart from the above, we are also accepting reports for repositories hosted on GitHub, under the freeCodeCamp organization.
上記とは別に、freeCodeCamp 組織で、GitHub にホストされているリポジトリの報告も受け付けています。
We self-host some of our platforms using open-source software like Ghost & Discourse. If you are reporting a vulnerability please ensure that it is not a bug in the upstream software.
Ghost & Discourse のようなオープンソースソフトウェアを使用して、いくつかのプラットフォームをセルフホストします。 脆弱性を報告する場合は、アップストリームソフトウェアのバグではないことを確認してください。

View File

@ -44,7 +44,7 @@ Alguns exemplos de bons títulos de PRs seriam:
1. Uma vez que as edições tenham sido realizadas, será solicitado que você crie um pull request na página do GitHub do seu fork.
![Imagem - Comparar o prompt de pull request no GitHub](https://contribute.freecodecamp.org/images/github/compare-pull-request-prompt.png)
![Image - Compare & pull request prompt on GitHub](https://contribute.freecodecamp.org/images/github/compare-pull-request-prompt.png)
2. Por padrão, todos os pull requests devem ser feitos no repositório principal do freeCodeCamp, branch `main`.

View File

@ -44,7 +44,7 @@ Some examples of good PRs titles would be:
1. Once the edits have been committed, you will be prompted to create a pull request on your fork's GitHub Page.
![Image - Compare pull request prompt on GitHub](https://contribute.freecodecamp.org/images/github/compare-pull-request-prompt.png)
![Image - Compare & pull request prompt on GitHub](https://contribute.freecodecamp.org/images/github/compare-pull-request-prompt.png)
2. By default, all pull requests should be against the freeCodeCamp main repo, `main` branch.