gaspersic/freeCodeCamp
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

chore(docs,i8n): processed translations from crowdin (#39769)

Browse Source 
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
This commit is contained in:
github-actions[bot]
2020-10-02 00:28:40 +05:30
committed by GitHub
parent 5bf84ae475
commit 84c5c641c3
448 changed files with 86763 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

101
docs/i18n/Afrikaans/FAQ.md Normal file
View File

@ -0,0 +1,101 @@
### I am new to GitHub and Open Source, where should I start?
Read our ["How to Contribute to Open Source Guide"](https://github.com/freeCodeCamp/how-to-contribute-to-open-source). It's a compresensive resource of first timer friendly projects and guidelines.
### Can I translate freeCodeCamp's curriculum?
We will be kicking-off the localization efforts on freeCodeCamp starting with the **Chinese** first.
We intend to make the curriculum available in more languages, but can't commit to any deadlines yet. Several operational limits like staff, active contributors and server costs play a role in driving the internationalisation (i18n) efforts.
We intend to start i18n efforts in these languages: Arabic, Portuguese, Russian and Spanish (in no particular order) after we have released the curriculum in Chinese.
**Why are you focusing on Chinese curriculum first?**
China is the largest demographic regions, in our non-native English speaking audience. Currently, we have hundreds of thousands of users using an old version of the platform. Focusing on the Chinese curriculum will give us an estimate of logistics involved in the i18n.
We will focus on Latin America as the demographic region for Portuguese and Spanish.
We do not have any plans for i18n to any other languages other than the above for the foreseeable future.
We do not encourage you to work on i18n on the above languages. We may accept pull requests, without any expectation of any timelines on deployments.
### How can I report a new bug?
If you think you've found a bug, first read the ["Help I've Found a Bug"](https://forum.freecodecamp.org/t/how-to-report-a-bug/19543) article and follow its instructions.
If you're confident it's a new bug, go ahead and create a new GitHub issue. Be sure to include as much information as possible so that we can reproduce the bug. We have a pre-defined issue template to help you through this.
Please note that any issues that seek coding help on a challenge will be closed. The issue tracker is strictly for codebase related issues and discussions. Whenever in doubt, you should [seek assistance on the forum](https://forum.freecodecamp.org) before making a report.
### How can I report a security issue?
Please don't create GitHub issues for security issues. Instead, please send an email to `security@freecodecamp.org` and we'll look into it immediately.
### I am a student, can I or our team work on a feature for academic credits?
Yes, sure.
While, we are open to all contributions, please note we are unable to commit to any timelines that may be a requirement at your college or university. We receive many pull-requests and code contributions by volunteer developers, and we respect their time and efforts. We will not be able to give any PR any special attention to be fair to all.
We request you to plan ahead and work on a feature with this in mind.
### What do these different labels that are tagged on issues mean?
The code maintainers [triage](https://en.wikipedia.org/wiki/Software_bug#Bug_management) issues and pull requests based on their priority, severity, and other factors. You can [find a complete glossary of their meanings here](https://github.com/freecodecamp/freecodecamp/labels).
### Where do I start if I want to work on an issue?
You should go through [**`help wanted`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) or [**`first timers only`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22first+timers+only%22) issues for a quick overview of what is available for you to work on.
> [!TIP] **`help wanted`** issues are up for grabs, and you do not need to seek permission before working on them. However, issues with the **`first timers only`** label are reserved for people that have not contributed to the freeCodeCamp codebase before. If these issues lack clarity on what needs to be done, feel free to ask questions in the comments.
### I found a typo, should I report an issue before I can make a pull request?
For typos and other wording changes, you can directly open pull requests without creating an issue first. Issues are more for discussing larger problems associated with code or structural aspects of the curriculum.
However, please mention details, context etc. in the pull request's description area to help us understand and review your contribution even for minor changes.
### How do I get an issue assigned to me?
We typically do not assign issues to anyone other than long-time contributors to avoid ambiguous no-shows. Instead, we follow the below policy to be fair to everyone:
1. The first pull request for any issue is preferred to be merged.
2. In the case of multiple pull requests for the same issue, we give priority to the quality of the code in the pull requests.
- Did you include tests?
- Did you catch all usecases?
- Did you ensure all tests pass, and you confirmed everything works locally?
3. Finally, we favor pull requests which follow our recommended guidelines.
- Did you follow the pull request checklist?
- Did you name your pull request title meaningfully?
You do not need any permission for issues that are marked `help wanted` or `first timers only` as explained earlier.
Follow the guidelines carefully and open a pull request.
### I am stuck on something that is not included in this documentation.
**Feel free to ask for help in:**
- The `Contributors` category of [our community forum](https://forum.freecodecamp.org/c/contributors).
- The public `Contributors` [chat room on Gitter](https://gitter.im/FreeCodeCamp/Contributors).
- The `#Contributors` channel on [our Discord community server](https://discord.gg/pFspAhS).
We are excited to help you contribute to any of the topics that you would like to work on. Feel free to ask us questions on the related issue threads, and we will be glad to clarify. Make sure you search for your query before posting a new one.
Be polite and patient. Our community of volunteers and moderators are always around to guide you through your queries.
**Additional Assistance:**
If you have queries about the stack, architecture of the codebase, feel free to reach out to our staff dev team:
| Staff | Send message on Forum |
|:--------------------- |:---------------------------------------------------------------------------- |
| Mrugesh Mohapatra | [@raisedadead](https://forum.freecodecamp.org/u/raisedadead) |
| Ahmad Abdolsaheb | [@abdolsa](https://forum.freecodecamp.org/u/abdolsa) |
| Kristofer Koishigawa | [@scissorsneedfoodtoo](https://forum.freecodecamp.org/u/scissorsneedfoodtoo) |
| Tom Mondloc | [@moT01](https://forum.freecodecamp.org/u/moT01) |
| Oliver Eyton-Williams | [@ojeytonwilliams](https://forum.freecodecamp.org/u/ojeytonwilliams) |
| Randell Dawson | [@RandellDawson](https://forum.freecodecamp.org/u/randelldawson) |
**You can email our developer staff at: `dev[at]freecodecamp.org`**

36
docs/i18n/Afrikaans/_sidebar.md Normal file
View File

@ -0,0 +1,36 @@
- **Getting Started**
- [Introduction](/index.md "Contribute to the freeCodeCamp.org Community")
- [Frequently Asked Questions](/FAQ.md)
- **Code Contribution**
- - [Set up freeCodeCamp locally](/how-to-setup-freecodecamp-locally.md)
- [Open a pull request](/how-to-open-a-pull-request.md)
- [Work on coding challenges](/how-to-work-on-coding-challenges.md)
- [Work on video challenges](/how-to-help-with-video-challenges.md)
- [Work on the news theme](/how-to-work-on-the-news-theme.md)
- [Work on the docs theme](/how-to-work-on-the-docs-theme.md)
- **Optional Guides**
- [Catch outgoing emails locally](/how-to-catch-outgoing-emails-locally.md)
- [Set up freeCodeCamp on WSL](/how-to-setup-wsl.md)
---
- **中文社区贡献指南**
- [成为专栏作者](/i18n/chinese/news-author-application.md)
- [文章翻译计划](/i18n/chinese/news-translations.md)
- [视频翻译计划](/i18n/chinese/video-translations.md)
---
- **Flight Manuals** (for Staff & Mods)
- [Moderator Handbook](/flight-manuals/moderator-handbook.md)
- [Reply Templates](/flight-manuals/using-reply-templates.md)
- [DevOps Overview](/devops.md)
- [Working on Servers](/flight-manuals/working-on-virtual-machines.md)
---
- **Our Community**
- [**GitHub**](https://github.com/freecodecamp/freecodecamp)
- [**Discourse Forum**](https://freecodecamp.org/forum/c/contributors)
- [**Gitter Chat**](https://gitter.im/FreeCodeCamp/Contributors)
- [**Discord Server**](https://discord.gg/pFspAhS)

227
docs/i18n/Afrikaans/devops.md Normal file
View File

@ -0,0 +1,227 @@
# Developer Operations at freeCodeCamp.org
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.
## How do we build, test and deploy the codebase?
This repository is continuously built, tested and deployed to **separate sets of infrastructure (Servers, Databases, CDNs, etc.)**.
This involves three steps to be followed in sequence:
1. New changes (both fixes and features) are merged into our primary development branch (`master`) 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.
#### Building the codebase - Mapping Git Branches to Deployments.
Typically, [`master`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master) (the default development branch) is merged into the [`production-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) branch once a day and is released into an isolated infrastructure.
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.
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 [`production-current`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-current) branch.
This is the final release that moves changes to our production platforms on 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 [Travis CI](https://travis-ci.org/freeCodeCamp/freeCodeCamp) and [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.
> [!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.
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).
## Triggering a build, test and deployment.
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).
> [!NOTE] In the upcoming days we would improve this flow to be done via pull-requests, for better access management and transparency.
### Pushing changes to Staging Applications.
1. Configure your remotes correctly.
```sh
git remote -v
```
**Results:**
```
origin git@github.com:raisedadead/freeCodeCamp.git (fetch)
origin git@github.com:raisedadead/freeCodeCamp.git (push)
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (fetch)
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (push)
```
2. Make sure your `master` branch is pristine and in sync with the upstream.
```sh
git checkout master
git fetch --all --prune
git reset --hard upstream/master
```
3. Check that the Travis CI is passing on the `master` branch for upstream.
The [continuous integration](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) tests should be green and PASSING for the `master` branch.
<details> <summary> Checking status on Travis CI (screenshot) </summary>
<br>
![Check build status on Travis CI](https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/master/docs/images/devops/travis-build.png)
</details>
If this is failing you should stop and investigate the errors.
4. Confirm that you are able to build the repository locally.
```
npm run clean-and-develop
```
5. Move changes from `master` to `production-staging` via a fast-forward merge
```
git checkout production-staging
git merge master
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.
>
> If they do, you may have done something incorrectly and you should just start over.
The above steps will automatically trigger a run on the build pipeline for the `production-staging` branch. Once the build is complete, the artifacts are saved as `.zip` files in a cold storage to be retrieved and used later.
The release pipeline is triggered automatically when a fresh artifact is available from the connected build pipeline. For staging platforms, this process does not involve manual approval and the artifacts are pushed to the Client CDN and API servers.
> [!TIP|label:Estimates] Typically the build run takes ~20-25 minutes to complete followed by the release run which takes ~15-20 mins for the client, and ~5-10 mins for the API to be available live. From code push to being live on the staging platforms the whole process takes **~35-45 mins** in total.
### Pushing changes to Production Applications.
The process is mostly the same as the staging platforms, with a few extra checks in place. This is just to make sure, we do not break anything on freeCodeCamp.org which can see hundreds of users using it at any moment.
| Do NOT execute these commands unless you have verified that everything is working on the staging platform. You should not bypass or skip any testing on staging before proceeding further. |
|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| |
1. Make sure your `production-staging` branch is pristine and in sync with the upstream.
```sh
git checkout production-staging
git fetch --all --prune
git reset --hard upstream/production-staging
```
2. Move changes from `production-staging` to `production-current` via a fast-forward merge
```
git checkout production-current
git merge production-staging
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.
>
> If they do, you may have done something incorrectly and you should just start over.
The above steps will automatically trigger a run on the build pipeline for the `production-current` branch. Once a build artifact is ready, it will trigger a run on the release pipeline.
> [!TIP|label:Estimates] Typically the build run takes ~20-25 minutes to complete.
**Additional Steps for Staff Action**
One a release run is triggered, members of the developer staff team will receive an automated manual intervention email. They can either _approve_ or _reject_ the release run.
If the changes are working nicely and have been tested on the staging platform, then it can be approved. The approval must be given within 4 hours of the release being triggered before getting rejected automatically. A staff can re-trigger the release run manually for rejected runs, or wait for the next cycle of release.
For staff use:
| Check your email for a direct link or [go to the release dashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) after the build run is complete. |
|:------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| |
Once one of the staff members approves a release, the pipeline will push the changes live to freeCodeCamp.org's production CDN and API servers. They typically take ~15-20 mins for the client, and ~5 mins for the API servers to be available live.
> [!TIP|label:Estimates] The release run typically takes ~15-20 mins for each client instance, and ~5-10 mins for each API instance to be available live. From code push to being live on the production platforms the whole process takes **~90-120 mins** in total (not counting the wait time for the staff approval).
## Build, Test and Deployment Status
Here is the current test, build and deployment status of the codebase.
| Type | Branch | Status | Dashboard |
|:---------------- |:-------------------------------------------------------------------------------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |:----------------------------------------------------------------------------------------- |
| CI Tests | [`master`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master) | ![Travis CI Build Status](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=master) | [Go to status dashboard](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| CI Tests | [`production-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | ![Travis CI Build Status](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=production-staging) | [Go to status dashboard](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| Build Pipeline | [`production-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | [![Build Status](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_apis/build/status/dot-dev-ci?branchName=production-staging)](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build/latest?definitionId=15&branchName=production-staging) | [Go to status dashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build) |
| Release Pipeline | [`production-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | | [Go to status dashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) |
| CI Tests | [`production-current`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-current) | ![Travis CI Build Status](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=production-current) | [Go to status dashboard](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| Build Pipeline | [`production-current`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | [![Build Status](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_apis/build/status/dot-org-ci?branchName=production-current)](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build/latest?definitionId=17&branchName=production-current) | [Go to status dashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build) |
| Release Pipeline | [`production-current`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | | [Go to status dashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) |
## Early access and beta testing
We welcome you to test these releases in a **"public beta testing"** mode and get early access to upcoming features to the platforms. Sometimes these features/changes are referred to as **next, beta, staging,** etc. interchangeably.
Your contributions via feedback and issue reports will help us in making the production platforms at `freeCodeCamp.org` more **resilient**, **consistent** and **stable** for everyone.
We thank you for reporting bugs that you encounter and help in making freeCodeCamp.org better. You rock!
### Identifying the upcoming version of the platforms
Currently a public beta testing version is available at:
<h1 align="center"><a href='https://www.freecodecamp.dev' _target='blank'>freecodecamp.dev</a></h1>
> [!NOTE] The domain name is different than **`freeCodeCamp.org`**. This is intentional to prevent search engine indexing and avoid confusion for regular users of the platform.
### Identifying the current version of the platforms
**The current version of the platform is always available at [`freeCodeCamp.org`](https://www.freecodecamp.org).**
The dev-team merges changes from the `production-staging` branch to `production-current` when they release changes. The top commit should be what you see live on the site.
You can identify the exact version deployed by visiting the build and deployment logs available in the status section. Alternatively you can also ping us in the [contributors chat room](https://gitter.im/FreeCodeCamp/Contributors) for a confirmation.
### Known Limitations
There are some known limitations and tradeoffs when using the beta version of the platform.
- #### All data / personal progress on these beta platforms `will NOT be saved or carried over` to production.
**Users on the beta version will have a separate account from the production.** The beta version uses a physically separate database from production. This gives us the ability to prevent any accidental loss of data or modifications. The dev team may purge the database on this beta version as needed.
- #### There are no guarantees on the uptime and reliability of the beta platforms.
Deployment is expected to be frequent and in rapid iterations, sometimes multiple times a day. As a result there will be unexpected downtime at times or broken functionality on the beta version.
- #### Do not send regular users to this site as a measure of confirming a fix
The beta site is and always has been to augment local development and testing, nothing else. It's not a promise of what’s coming, but a glimpse of what is being worked upon.
- #### Sign page may look different than production
We use a test tenant for freecodecamp.dev on Auth0, and hence do not have the ability to set a custom domain. This makes it so that all the redirect callbacks and the login page appear at a default domain like: `https://freecodecamp-dev.auth0.com/`. This does not affect the functionality is as close to production as we can get.
## Reporting issues and leaving feedback
Please open fresh issues for discussions and reporting bugs. You can label them as **[`release: next/beta`](https://github.com/freeCodeCamp/freeCodeCamp/labels/release%3A%20next%2Fbeta)** for triage.
You may send an email to `dev[at]freecodecamp.org` if you have any queries. As always all security vulnerabilities should be reported to `security[at]freecodecamp.org` instead of the public tracker and forum.

326
docs/i18n/Afrikaans/flight-manuals/moderator-handbook.md Normal file
View File

@ -0,0 +1,326 @@
# The official freeCodeCamp Moderator Handbook.
This will help you moderate different places in our community, including:
- GitHub issues & pull requests
- The forum, chat rooms, Facebook groups, and other online meeting places
- In-person events like study groups, hackathons, and conferences
**All freeCodeCamp Moderators are community-wide moderators. That means that we trust you to oversee any of these places.**
This said, you can serve as a moderator in whichever places are of the most interest to you. Some moderators just help out on GitHub. Others just help out on the forum. Some moderators are active everywhere.
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.
> [!NOTE] "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.
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).
# Moderating GitHub
Moderators have the ability to close issues and accept or close pull requests.
Moderators have two primary responsibilities regarding GitHub:
1. QA'ing and merging pull requests
2. Evaluating and responding to issues
## Moderating Pull Requests
Pull Requests (PRs) are how contributors submit changes to freeCodeCamp's repository. It's important that we perform Quality Assurance (QA) on pull requests before we decide whether to merge them or close them.
### Types of Pull Requests
1. **Challenge Instruction Edits** 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. Also, contributors may try to add links to resources to the challenges. You can close these pull requests and reply to them with this:
> Thank you for your pull request.
>
> I am closing this pull request. Please add links and other details to the challenge's corresponding guide article instead.
>
> If you think I'm wrong in closing this issue, please reopen it and add further clarification. Thank you, and happy coding.
2. **Challenge Code Edits** 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 to make sure the challenge tests can still be passed with the current solution, and the new code doesn't introduce any errors. 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.
3. **Codebase Changes** These code edits change the functionality of the freeCodeCamp platform itself. 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. So 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. 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 @raisedadead so he can take a final look.
### How to merge or close pull requests
First of all, when you choose a pull request to QA, 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.
Depending on the type of pull request it is, follow the corresponding rules listed above.
Before merging any pull request, make sure that GitHub has green checkmarks for everything. If there are any X's, investigate them first and figure out how to get them turned into green checkmarks first.
Sometimes there will be a Merge Conflict. This means that another pull request has made a change to that exact 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 judgement. The pull request's changes will be on top, and the Master branch's changes will be on 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.
If the pull request looks ready to merge (and doesn't require approval from @raisedadead), you can go ahead and merge it. Be sure to use the default "Squash and Merge" functionality on GitHub. This will squash all the pull requests commits down into a single commit, which makes the Git history much easier to read.
You should then comment on the pull request, thanking the contributor in your own personal way.
If the author of the pull request 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:
![Copy_edits_for_Java_arrays_article_by_karentobo_%C2%B7_Pull_Request__20615_%C2%B7_freeCodeCamp_freeCodeCamp|690x281](https://i.imgur.com/dTQMjGM.png)
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.
Often, a pull request will be obviously low effort. You can often 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".
There are also situations where the contributor is trying to add a link to their own website, or include a library they themselves created, or has a frivolous edit that doesn't serve to help anyone but themselves.
In both of these situations, you should go ahead and close their pull request and reply with this standard message:
> 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.
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.
## Moderating GitHub Issues
freeCodeCamp is an active open source project. We get new issues every day, all of which need to be triaged and labeled.
### Types of GitHub Issues
1. **Code Help Requests**, which people have mistakenly created GitHub issues for. If someone is asking for help, paste the following message, then close the issue.
> 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 \*\*"Help"\*\* button on the challenge on freeCodeCamp, 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.
>
> 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.
2. **Bug or Clarification issues** Try to reproduce the bug yourself if you can. If not, ask them for the steps to reproduce the bug, and whether they have any screenshots, videos, or additional details that can help you reproduce the issue. Once you can reproduce the issue - or at least confirm it's a legit issue - label it `confirmed`. Then:
- If it's a simple change to an existing challenge, label as `first timers only`, otherwise label as `help wanted`. Use other labels as appropriate.
- If the issue is more significant, flag as `bug`. &nbsp; If there is any ambiguity as to the proper course of action on an issue, feel free to tag @raisedadead on the issue get his opinion on it, then add the `Discussing` label.
3. **Duplicate Issues** If an issue is the same as another reported issue, the prior reported issue should take precedence. Flag as `Duplicate`, paste the following message replacing `#XXXXX` with the issue number, then close the issue.
> 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 I am closing it as a duplicate.
>
> If you think I'm wrong in closing this issue, please reopen it and add further clarification. Thank you and happy coding.
4. **Fixed in staging** Some problems may have already been fixed in staging, but don't have a GitHub issue associated with them. If this is the case, you can paste the following message, close the issue, and add a `status: resolved/shipping` label:
> 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, I'm closing this issue.
>
> If you think I'm wrong in closing this issue, please reopen it and add further clarification. Thank you and happy coding.
### Closing Stale, Outdated, Inactive Issues and Pull Requests
- Stale Issues or PRs are those that have not seen any activity from the OP for 21 days (3 weeks from the last activity), but only after a moderator has requested more information/changes. These can be closed in an automated/bot script or by the moderators themselves.
- Activity is defined as: Comments requesting an update on the PR and triages like `status: update needed` label etc.
- If the OP 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 judgement to resolve the outstanding PR's status.
### Other guidelines for Moderators on 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.
Also, you should never accept your own PRs. They must be QA'd by another moderator, just like with any other 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 dev@freecodecamp.org with a link to the offending pull request and we can consider banning them from freeCodeCamp's GitHub organization entirely.
# 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."
![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)
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 smallest kindness may trigger a cascade of good deeds.
### Deleting forum posts
Forum moderators have the ability to 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.
### 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 follow the process above. Quietly block the user from posting (using the silence option on the User Admin panel), then send a warning with the Code of Conduct. Check the box in the private message indicating that your message is a "formal warning."
You can ask questions and report incidents in the in the [staff forum section](https://forum.freecodecamp.com/c/staff).
### Dealing with off-topic conversations
Posts or topics that seems 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 require that freeCodeCamp users be at least 13 years of age. In the event that 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). Then email [Quincy](https://forum.freecodecamp.org/u/QuincyLarson) (quincy@freecodecamp.org) or [Mrugesh](https://forum.freecodecamp.org/u/raisedadead) (mrugesh@freecodecamp.org) to delete the user's freeCodeCamp account as well.
```markdown
SUBJECT: Users under 13 are not allowed to use the forum per Terms of Service
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.
Please rejoin once you have reached at least 13 years of age.
Thank you for understanding.
```
# Moderating Facebook
If you see anything that seems to break our [Code of Conduct](https://code-of-conduct.freecodecamp.org/), you should delete it immediately.
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. In these cases, their post should be deleted, but the person who posted it doesn't necessarily need to be banned. By getting their post deleted, they will hopefully come to understand that what they posted was inappropriate.
But if it is an egregious offense that can't reasonably be attributed to a cultural difference or a misunderstanding of the English language, then you should strongly consider blocking the member from the Facebook group.
# Moderating Discord
Here's how moderators deal with violations of our [Code of Conduct](https://code-of-conduct.freecodecamp.org/) on Discord:
1. **Make sure it was intended to violate the Code of Conduct.** 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.
2. **If the camper clearly violates the Code of Conduct, the moderator will proceed as follows:**
- Suspend the offending camper, but don't warn or threaten them. Instead, quietly give them the Suspended role on Discord, then send them the following message:
```
This is a standard message notifying you that I had to temporarily suspend you from talking on the freeCodeCamp Discord server.
I am a moderator acting on behalf of our open source community. I can consider removing your suspension, but I need you to take the following 3 steps first:
1. Read our Code of Conduct: https://code-of-conduct.freecodecamp.org/
2. Message me back confirming that you have finished reading it.
3. Explain to me why you think I suspended you, and why I should remove your suspension.
```
- Report a short summary of the event and how they responded to it in the #admin channel. Here's an example of what such a summary might look like:
```
Suspended: _@username_
Reason(s): _Spamming, trolling_
Evidence: _One or more links to the offending message(s)_
CoC: _Sent_
```
- A report for removing a suspension should look like:
```
I’ve removed the suspension from ` @username `. I sent them the Code of Conduct. They just today realized they were suspended and apologized for what they did.
```
- Based on the offenders reply, the moderator will decide whether to remove the suspension from the offending camper. If they seem respectful and apologetic, the moderator can remove the suspension. As a matter of policy, moderators will be polite during this process, no matter how poorly the offending camper has behaved. If they aren't respectful or unwilling to accept the CoC, the suspension should be followed with a ban from the Discord server. Use the same summary as above, but replace "Suspended:" with "Banned:".
3. **How to ban and/or unban**
- In order to ban someone, right click on their username/profile picture and select "Ban <username>". You will be given the option to delete their previous messages - select "Don't delete any", as the messages should remain present as a historic record.
- If you decide to ban someone, it means they're unwilling to abide to our Code of Conduct. Therefore unbanning a Camper should rarely occur. However, if the need arises, you can do so by clicking on the server name, choosing "Server Settings", choosing "Bans", selecting the user you wish to unban, and clicking "Revoke Ban".
Discord Bans are global - you cannot ban a user from a specific channel, only from the entire server.
4. **Deleting messages** Moderators have the ability to delete messages on Discord. They should only exercise this ability in four very specific situations:
- 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) as to render chat completely unusable.
- Someone has posted 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 message as these are an important historic record. 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, but for the #activity-log it is sufficient to say the evidence was "removed due to sensitive content". 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.
5. **Don’t use @everyone or @here** Don’t use @everyone or @here under any circumstances! Every single person in that chat room will get a notification. In some cases, tens of thousands of people. Instead, if you want people to see an announcement, you can pin it to the channel to allow everyone to read it.
6. **Don’t threaten to ban or suspend** If a camper is breaking the code of conduct, don’t threaten to ban or suspend them, and never warn them in public. Instead, talk to them privately, or send them a DM and issue a suspension (per the above protocol). No one else in that channel needs to know that you banned / suspended the person - campers can view the summary in the #activity-log channel if they want to keep up on that information. 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:
- Camper posts a wall of code to request help
Moderator: @username Please use Codepen or Pastebin when posting large amounts of code.
- 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.
- 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/
7. **Don’t brag about being a moderator** 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 they’re doing nothing wrong. This is just human nature.
8. **Don’t contradict other moderators** If you disagree with the action of a moderator, talk with them in private or bring it up in the #mod-chat channel. Never override a ban, 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. Remember: we’re all on the same team. We want to dignify the role of moderators and present a unified front.
9. **Talk with other moderators** We have a room for moderators only. Use it! If you feel uncomfortable with how to handle 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 the input of every team member! Even if you totally disagree with anything in these guidelines or the Code of Conduct!
10. **Temporarily inactive** 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 in the server or not.
# How to become a moderator
If you are helping people in the community consistently over time, 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.
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), etc.
> [!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. This is required for us to be able to give you write access on 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:
> 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
Anyone is welcome in the [Contributors room on our Discord](https://discord.gg/KVUmVXA). It is the designated chat room for moderators and other campers who are contributing to our community in any number of ways, including through study groups.
Our assumption is that 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.
# Dealing with solicitors
You may be approached by organizations who want to partner or co-brand with freeCodeCamp in some way. Once you realize that this is what they're after, please stop talking to them and tell them to email quincy@freecodecamp.org. He gets proposals like this all the time and is 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 are seeking 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 at some point reflect back to fCC, 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. 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 Discord: Suspend the user. This is not to punish them! Suspending a user will create a private channel that's only accessible by the user and the team. This will benefit both the user and fCC in several ways:
- 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
> [!NOTE] Suspending a user automatically gives them a message about reading our Code of Conduct. Make sure you inform the user that you Suspended them to give them some privacy and that they're not being punished. This is very important! We absolutely want to avoid giving users the idea that they're being punished for reaching out to get help!
If you believe the user is capable of rejoining the community, right click on the private channel and copy the ID. Put the following message in #mod-log:
> Reference medical advice: <channel ID> <username>
After that, you can remove the Suspension from the user as you normally do.
Helpful URLs:
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 perfectly summarizes most communities' thoughts on free speech. So if someone defends something they're saying as "free speech" feel free to send it to them.
<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!

126
docs/i18n/Afrikaans/flight-manuals/using-reply-templates.md Normal file
View File

@ -0,0 +1,126 @@
# Using Reply Templates
These are some of the standard reply templates that you may use while reviewing pull requests and triaging issues.
> You can make your own with GitHub's built-in [**Saved replies**](https://github.com/settings/replies/) feature or use the ones below.
### 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)! 🎉
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
We would love to be able to merge your changes but it looks like there is an error with the Travis CI build. ⚠️
Once you resolve these issues, We will be able to review your PR and merge it. 😊
---
> Feel free to reference the [Style guide for writing articles](https://github.com/freeCodeCamp/freeCodeCamp#article-title) for this repo on formatting an article correctly so your Travis CI build passes. ✅
>
> Also, it's good practice on GitHub to write a brief description of your changes when creating a PR. 📝
```
### Syncing Fork
> When PR is not up to date with the `master` branch.
``````markdown
Hey @username
We would love to be able to merge your changes but it looks like there is an error with the Travis CI build. ⚠️
```bash
Error: ENOTDIR: not a directory, open 'src/pages/java/data-abstraction/index.md'
``````
This particular error was not caused by your file but was an old error caused by merging faulty code to the `master` branch. It has since been resolved.
To pass the build, you will have to sync the latest changes from the `master` branch of the `freeCodeCamp/freeCodeCamp` repo.
Using the command line, you can do this in three easy steps:
```bash
git remote add upstream git://github.com/freeCodeCamp/freeCodeCamp.git
git fetch upstream
git pull upstream master
```
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.
Once you sync your fork and pass the build, We will be able to review your PR and merge it. 😊
---
> 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. 🔄
>
> Also, it's good practice on GitHub to write a brief description of your changes when creating a PR. 📝
``````
### Merge Conflicts
> When PR has merge conflicts that need to be resolved.¹
```markdown
Hey @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. 😊
---
> 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/). 🔍️
>
> Also, it's good practice on GitHub to write a brief description of your changes when creating a 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.
```markdown
Hey @username
It seems that similar changes have already been accepted earlier for this article you are editing, sorry about that. 😓
If you feel you have more to add, please feel free to open up a new PR.
Thanks again! 😊
---
> If you have any questions, feel free to reach out through [Gitter](https://gitter.im/FreeCodeCamp/Contributors) or by commenting below. 💬
```
### Closing invalid pull requests
> When PR is invalid.
```markdown
Hey @username
You have not added any content, We will be closing this PR and marking it as `invalid`. 😓️
Feel free to open another PR though! 👍
```

475
docs/i18n/Afrikaans/flight-manuals/working-on-virtual-machines.md Normal file
View File

@ -0,0 +1,475 @@
# Flight Manual for working on Virtual Machines
As a member of the staff or the dev-team, you may have been given access to our cloud service providers like Azure, Digital Ocean, etc.
Here are some handy commands that you can use to work on the Virtual Machines (VM), for instance performing maintenance updates or doing general houeskeeping.
# Get a list of the VMs
> [!NOTE] While you may already have SSH access to the VMs, that alone will not let you list VMs unless you been granted access to the cloud portals as well.
## Azure
Install Azure CLI `az`: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli
> **(One-time) Install on macOS with [`homebrew`](https://brew.sh):**
```
brew install azure-cli
```
> **(One-time) Login:**
```
az login
```
> **Get the list of VM names and P addresses:**
```
az vm list-ip-addresses --output table
```
## Digital Ocean
Install Digital Ocean CLI `doctl`: https://github.com/digitalocean/doctl#installing-doctl
> **(One-time) Install on macOS with [`homebrew`](https://brew.sh):**
```
brew install doctl
```
> **(One-time) Login:**
Authentication and context switching: https://github.com/digitalocean/doctl#authenticating-with-digitalocean
```
doctl auth init
```
> **Get the list of VM names and IP addresses:**
```
doctl compute droplet list --format "ID,Name,PublicIPv4"
```
# Spin a VM (or VM Scale Set)
> Todo: Add instructions for spinning VM(s)
<!--
The below instructions are stale.
### 0. Prerequisites (workspace Setup) for Staff
Get a login session on `azure cli`, and clone the
[`infra`](https://github.com/freeCodeCamp/infra) for setting up template
workspace.
```console
az login
git clone https://github.com/freeCodeCamp/infra
cd infra
```
Use the Scratchpad subdirectory for temporary files, and making one-off edits.
The contents in this subdirectory are intentionally ignored from source control.
### 1. Provision VMs on Azure.
List all Resource Groups
```console
az group list --output table
```
```console
Name Location Status
--------------------------------- ------------- ---------
tools-rg eastus Succeeded
```
Create a Resource Group
```
az group create --location eastus --name stg-rg
```
```console
az group list --output table
```
```console
Name Location Status
--------------------------------- ------------- ---------
tools-rg eastus Succeeded
stg-rg eastus Succeeded
```
Next per the need, provision a single VM or a scaleset.
#### A. provision single instances
```console
az vm create \
--resource-group stg-rg-eastus \
--name <VIRTUAL_MACHINE_NAME> \
--image UbuntuLTS \
--size <VIRTUAL_MACHINE_SKU>
--custom-data cloud-init/nginx-cloud-init.yaml \
--admin-username <USERNAME> \
--ssh-key-values <SSH_KEYS>.pub
```
#### B. provision scaleset instance
```console
az vmss create \
--resource-group stg-rg-eastus \
--name <VIRTUAL_MACHINE_SCALESET_NAME> \
--image UbuntuLTS \
--size <VIRTUAL_MACHINE_SKU>
--upgrade-policy-mode automatic \
--custom-data cloud-init/nginx-cloud-init.yaml \
--admin-username <USERNAME> \
--ssh-key-values <SSH_KEYS>.pub
```
> [!NOTE]
>
> - The custom-data config should allow you to configure and add SSH keys,
> install packages etc. via the `cloud-init` templates in your local
> workspace. Tweak the files in your local workspace as needed. The cloud-init
> config is optional and you can omit it completely to do setups manually as
> well.
>
> - The virtual machine SKU is something like: **Standard_B2s** which can be
> retrived by executing something like
> `az vm list-sizes -l eastus --output table` or checking the Azure portal
> pricing.
-->
# Keep VMs updated
You should keep the VMs up to date by performing updates and upgrades. This will ensure that the virtual machine is patched with latest security fixes.
> [!WARNING] Before you run these commands:
>
> - Make sure that the VM has been provisioned completely and there is no post-install steps running.
> - If you are updating packages on a VM that is already serving an application, make sure the app has been stopped / saved. Package updates will cause network bandwidth, memory and/or CPU usage spikes leading to outages on running applications.
Update package information
```console
sudo apt update
```
Upgrade installed packages
```console
sudo apt upgrade -y
```
Cleanup unused packages
```console
sudo apt autoremove -y
```
# Work on Web Servers (Proxy)
We are running load balanced (Azure Load Balancer) instances for our web servers. These servers are running NGINX which reverse proxy all of the traffic to freeCodeCamp.org from various applications running on their own infrastructures.
The NGINX config is available on [this repository](https://github.com/freeCodeCamp/nginx-config).
## First Install
Provisioning VMs with the Code
### 1. (Optional) Install NGINX and configure from repository.
The basic setup should be ready OOTB, via the cloud-init configuration. SSH and make changes as necessary for the particular instance(s).
If you did not use the cloud-init config previously use the below for manual setup of NGINX and error pages:
```console
sudo su
cd /var/www/html
git clone https://github.com/freeCodeCamp/error-pages
cd /etc/
rm -rf nginx
git clone https://github.com/freeCodeCamp/nginx-config nginx
cd /etc/nginx
```
### 2. Install Cloudflare origin certificates and upstream application config.
Get the Cloudflare origin certificates from the secure storage and install at required locations.
**OR**
Move over existing certificates:
```console
# Local
scp -r username@source-server-public-ip:/etc/nginx/ssl ./
scp -pr ./ssl username@target-server-public-ip:/tmp/
# Remote
rm -rf ./ssl
mv /tmp/ssl ./
```
Update Upstream Configurations:
```console
vi configs/upstreams.conf
```
Add/update the source/origin application IP addresses.
### 3. Setup networking and firewalls.
Configure Azure firewalls and `ufw` as needed for ingress origin addresses.
### 4. Add the VM to the load balancer backend pool.
Configure and add rules to load balancer if needed. You may also need to add the VMs to load balancer backend pool if needed.
## Logging and Monitoring
1. Check status for NGINX service using the below command:
```console
sudo systemctl status nginx
```
2. Logging and monitoring for the servers are available at:
> <h3 align="center"><a href='https://amplify.nginx.com' _target='blank'>https://amplify.nginx.com</a></h3>
## Updating Instances (Maintenance)
Config changes to our NGINX instances are maintained on GitHub, these should be deployed on each instance like so:
1. SSH into the instance and enter sudo
```console
sudo su
```
2. Get the latest config code.
```console
cd /etc/nginx
git fetch --all --prune
git reset --hard origin/master
```
3. Test and reload the config [with Signals](https://docs.nginx.com/nginx/admin-guide/basic-functionality/runtime-control/#controlling-nginx).
```console
nginx -t
nginx -s reload
```
# Work on API Instances
1. Install build tools for node binaries (`node-gyp`) etc.
```console
sudo apt install build-essential
```
## First Install
Provisioning VMs with the Code
1. Install Node LTS.
2. Update `npm` and install PM2 and setup logrotate and startup on boot
```console
npm i -g npm
npm i -g pm2
pm2 install pm2-logrotate
pm2 startup
```
3. Clone freeCodeCamp, setup env and keys.
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
cd freeCodeCamp
git checkout production-current # or any other branch to be deployed
```
4. Create the `.env` from the secure credentials storage.
5. Create the `google-credentials.json` from the secure credentials storage.
6. Install dependencies
```console
npm ci
```
7. Build the server
```console
npm run ensure-env && npm run build:server
```
8. Start Instances
```console
cd api-server
pm2 start production-start.js -i max --max-memory-restart 600M --name org
```
## Logging and Monitoring
```console
pm2 logs
```
```console
pm2 monit
```
## Updating Instances (Maintenance)
Code changes need to be deployed to the API instances from time to time. It can be a rolling update or a manual update. The later is essential when changing dependencies or adding enviroment variables.
> [!DANGER] The automated pipelines are not handling dependencies updates at the minute. We need to do a manual update before any deployment pipeline runs.
### 1. Manual Updates - Used for updating dependencies, env variables.
1. Stop all instances
```console
pm2 stop all
```
2. Install dependencies
```console
npm ci
```
3. Build the server
```console
npm run ensure-env && npm run build:server
```
4. Start Instances
```console
pm2 start all --update-env && pm2 logs
```
### 2. Rolling updates - Used for logical changes to code.
```console
pm2 reload all --update-env && pm2 logs
```
> [!NOTE] We are handling rolling updates to code, logic, via pipelines. You should not need to run these commands. These are here for documentation.
# Work on Client Instances
1. Install build tools for node binaries (`node-gyp`) etc.
```console
sudo apt install build-essential
```
## First Install
Provisioning VMs with the Code
1. Install Node LTS.
2. Update `npm` and install PM2 and setup logrotate and startup on boot
```console
npm i -g npm
npm i -g pm2
npm install -g serve
pm2 install pm2-logrotate
pm2 startup
```
3. Clone client config, setup env and keys.
```console
git clone https://github.com/freeCodeCamp/client-config.git client
cd client
```
```console
git clone https://github.com/freeCodeCamp/client-config.git client
cd client
```
Start placeholder instances for the web client, these will be updated with artifacts from the Azure pipline.
> Todo: This setup needs to move to S3 or Azure Blob storage
>
> ```console
echo "serve -c ../../serve.json www -p 50505" >> client-start-primary.sh
chmod +x client-start-primary.sh
pm2 delete client-primary
pm2 start ./client-start-primary.sh --name client-primary
echo "serve -c ../../serve.json www -p 52525" >> client-start-secondary.sh
chmod +x client-start-secondary.sh
pm2 delete client-secondary
pm2 start ./client-start-secondary.sh --name client-secondary
```
## Logging and Monitoring
```console
pm2 logs
```
```console
pm2 monit
```
## Updating Instances (Maintenance)
Code changes need to be deployed to the API instances from time to time. It can be a rolling update or a manual update. The later is essential when changing dependencies or adding enviroment variables.
> [!DANGER] The automated pipelines are not handling dependencies updates at the minute. We need to do a manual update before any deployment pipeline runs.
### 1. Manual Updates - Used for updating dependencies, env variables.
1. Stop all instances
```console
pm2 stop all
```
2. Install or update dependencies
3. Start Instances
```console
pm2 start all --update-env && pm2 logs
```
### 2. Rolling updates - Used for logical changes to code.
```console
pm2 reload all --update-env && pm2 logs
```
> [!NOTE] We are handling rolling updates to code, logic, via pipelines. You should not need to run these commands. These are here for documentation.

100
docs/i18n/Afrikaans/how-to-catch-outgoing-emails-locally.md Normal file
View File

@ -0,0 +1,100 @@
> **Note:** This is an **optional** step and is required only when working with email workflows
## Introduction
Some email workflows, like updating a user's email, requires the back-end api-server to send outgoing emails. An alternative to using an email service provider to send actual email messages, Mailhog is a developer tool for email testing that will catch the email messages sent by your freeCodeCamp instance.
## Installing MailHog
MailHog can be installed on macOS, Windows and Linux.
- [Introduction](#introduction)
- [Installing MailHog](#installing-mailhog)
- [Installing MailHog on macOS](#installing-mailhog-on-macos)
- [Installing MailHog on Windows](#installing-mailhog-on-windows)
- [Installing MailHog on Linux](#installing-mailhog-on-linux)
- [Using MailHog](#using-mailhog)
- [Useful Links](#useful-links)
### Installing MailHog on macOS
Install MailHog on macOS with [Homebrew](https://brew.sh/):
```bash
brew install mailhog
brew services start mailhog
```
The above commands will start a mailhog service in the background.
When the installation completes, you can start [using MailHog](#using-mailhog).
### Installing MailHog on Windows
Download the latest version of MailHog from [MailHog's official repository](https://github.com/mailhog/MailHog/releases). Locate and click on the link for your Windows version (32 or 64 bit) and a .exe file will be downloaded to your computer.
When the download completes, click to open the file. A Windows firewall notification may appear, requesting access permission for MailHog. A standard Windows command line prompt will open where MailHog will be running once firewall access is granted.
Close MailHog by closing the command prompt window. To start MailHog again, click on the MailHog executable (.exe) file that was downloaded initially - it is not necessary to download a new MailHog installation file.
Start [using MailHog](#using-mailhog).
### Installing MailHog on Linux
First, install [Go](https://golang.org).
Run the following commands to install GO on Debian-based systems like Ubuntu and Linux Mint.
```bash
sudo apt-get install golang
```
Run the following commands to install GO on RPM-based systems like CentOS, Fedora, Red Hat Linux, etc.
```bash
sudo dnf install golang
```
Alternatively, run the following commands to install GO.
```bash
sudo yum install golang
```
Now set the path for Go with the following commands.
```bash
echo "export GOPATH=$HOME/go" >> ~/.profile
echo 'export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin' >> ~/.profile
source ~/.profile
```
Finally, enter the commands below to install and run MailHog.
```bash
go get github.com/mailhog/MailHog
sudo cp /home/$(whoami)/go/bin/MailHog /usr/local/bin/mailhog
mailhog
```
Start [using MailHog](#using-mailhog).
## Using MailHog
Open a new browser tab or window and navigate to [http://localhost:8025](http://localhost:8025) to open your MailHog inbox when the MailHog installation has completed and MailHog is running. The inbox will appear similar to the screen shot below.
![MailHog Screenshot 1](images/mailhog/1.jpg)
Emails sent by your freeCodeCamp installation will appear as below
![MailHog Screenshot 2](images/mailhog/2.jpg)
Two tabs that allow you to view either plain text or source content will be available when you open a given email. Ensure that the plain text tab is selected as below.
![MailHog Screenshot 3](images/mailhog/3.jpg)
All links in the email should be clickable and resolve to their URL.
## Useful Links
- Check out the [MailHog](https://github.com/mailhog/MailHog) repository for further information related to MailHog. Additional information is also available regarding custom MailHog configurations.

199
docs/i18n/Afrikaans/how-to-help-with-video-challenges.md Normal file
View File

@ -0,0 +1,199 @@
# How to help with video challenges
Video challenges are a new type of challenge in the freeCodeCamp curriculum.
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 the the next video challenge in the course.
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.
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
---
id: Unique identifier (alphanumerical, MongoDB_id)
title: Challenge Title
challengeType: 11
videoId: 'YouTube videoId for video challenge'
---
## Description
<section id='description'>
An optional description with helpful information related to the video.
</section>
## Tests
<section id='tests'>
```yml
question:
text: 'Question'
answers:
- 'Answer One'
- 'Answer Two'
- 'Answer Three'
solution: 3
````
</section>
````
## 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/master/curriculum/challenges/english/08-data-analysis-with-python/data-analysis-with-python-course)
- [TensorFlow 2.0 Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/11-machine-learning-with-python/tensorflow)
- [Numpy Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/08-data-analysis-with-python/numpy)
- [How Neural Networks Work Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/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 mutiple choice question
First, find the 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 layed out in a table format.
````
---
id: 5e9a093a74c4063ca6f7c14d title: Data Analysis Example A challengeType: 11
videoId: nVAaxZ34khk
---
```
Next, access the YouTube video with that videoId. The url for the video will be:
https://www.youtube.com/watch?v=[videoId] (add videoId to the URL without square brackets)
In the example above, the url is 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.
### Add the question to the markdown file
You can add the question locally or directly throught 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.
If a question has not yet been added to a particular video challenge, it will have the following default question:
```yml
question:
text: |
Question
answers:
- |
one
- |
two
- |
three
solution: 3
```
Update the word “Question” with your question. Update the “one”, “two”, and “three” with the possible answers. Make sure to update the solution number with which answer is correct. You can add more possible answers using the same format. The question and answers can be surrounded with quotation marks.
#### Use markdown to format your question
The text in the question is parsed as markdown. The simplest way to ensure that it is formatted correctly is to start the question with `text: |`, like this:
```yml
question:
text: |
Question
```
Then you need to make sure that your question is on a new line and indented one level more than `text: |`.
The same approach can be used for the answers, so the entire question becomes
```yml
question:
text: |
Question
answers:
- |
First answer
- |
Second
- |
Third
solution: 2
```
Make sure each answer is plausible but there is only one correct answer.
#### Use of HTML
Questions and answers can contain certain HTML tags like `<br>` for a new line. HTML tags should be used sparingly, when questions cannot be expressed without them.
### Question examples
#### Examples without HTML
````yml
question:
text: |
What does this JavaScript code log to the console?
```js
console.log('hello world');
````
Select an answer!
answers:
- | hello *world*
- | **hello** world
- | hello world solution: 3
````
````yml
question:
text: |
What will print out after running this code:
```py
width = 15
height = 12.0
print(height/3)
````
answers:
- | 39
- | 4
- | 4.0
- | 5.0
- | 5 solution: 3
````
#### Example with HTML
```yml
question:
text: |
What will print out after running this code:
<pre><code>width = 15<br>height = 12.0<br>print(height/3)<code></pre>
answers:
- |
39
- |
4
- |
4.0
- |
5.0
- |
5
solution: 3
````
The final example demonstrates that HTML can be used, but that it is not as readable as the version without it.
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/master/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).

179
docs/i18n/Afrikaans/how-to-open-a-pull-request.md Normal file
View File

@ -0,0 +1,179 @@
# How to open a Pull Request (PR)
A pull request 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, or coding challenges you should follow these guidelines to send a PR.
## Prepare a good PR title
We recommend using [conventional title and messages](https://www.conventionalcommits.org/) for commits and pull request. The convention has the following format:
> `<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.
**Type:**
| Type | When to select |
|:----- |:---------------------------------------------------------------------------- |
| fix | Changed or updated/improved functionality, tests, 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. |
**Scope:**
You can select a scope from [this list of labels](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.
Some examples of good PRs titles would be:
- `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.
![Image - Compare pull request prompt on GitHub](./images/github/compare-pull-request-prompt.png)
2. By default, all pull requests should be against the freeCodeCamp main repo, `master` branch.
Make sure that your Base Fork is set to freeCodeCamp/freeCodeCamp when raising a Pull Request.
![Image - Comparing forks when making a pull request](./images/github/comparing-forks-for-pull-request.png)
3. Submit the pull request from your branch to freeCodeCamp's `master` branch.
4. In the body of your PR include a more detailed summary of the changes you made and why.
- 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).
> Example: `Closes #123` will close issue 123
5. Indicate if you have tested on a local copy of the site or not.
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.
## Feedback on pull requests
> Congratulations! :tada: on making a PR and thanks a lot for taking the time to contribute.
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.
If you need any assistance please discuss in the [contributors chat room](https://gitter.im/FreeCodeCamp/Contributors), we are more than happy to help you.
> [!TIP] If you are to be contributing more pull requests, we recommend you read the [making changes and syncing](https://contribute.freecodecamp.org/#/how-to-setup-freecodecamp-locally?id=making-changes-locally) guidelines to avoid having to delete your fork.
## 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.
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 `master`, you are able to do a simple rebase:
1. Rebase your local copy:
```console
git checkout <pr-branch>
git pull --rebase upstream master
```
2. Resolve any conflicts and add / edit commits
```console
# Either
git add .
git commit -m "chore: resolve conflicts"
# Or
git add .
git commit --amend --no-edit
```
3. Push back your changes to the 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 do a cherry pick:
1. Make sure your upstream comes in sync with your local:
```console
git checkout master
git fetch --all --prune
git checkout next-python-projects
git reset --hard upstream/next-python-projects
```
2. Take backup
a. Either delete your local branch after taking a backup (if you still have it locally):
```console
git checkout <pr-branch-name>
# example:
# git checkout feat/add-numpy-video-question
git checkout -b <backup-branch-name>
# example:
# git checkout -b backup-feat/add-numpy-video-question
git branch -D <pr-branch-name>
```
b. Or just a backup of your pr branch (if you do not have it locally):
```console
git checkout -b <backup-branch-name> origin/<pr-branch-name>
# example:
# git checkout -b backup-feat/add-numpy-video-question origin/feat/add-numpy-video-question
```
4. Start off with a clean slate:
```console
git checkout -b <pr-branch-name> next-python-projects
git cherry-pick <commit-hash>
```
5. Resolve any conflicts, and cleanup, install run tests
```console
npm run clean
npm ci
npm run test:curriculum --superblock=<superblock-name>
# example:
# npm run test:curriculum --superblock=python-for-everybody
```
6. If everything looks good push back to the PR
```console
git push --force origin <pr-branch-name>
```

546
docs/i18n/Afrikaans/how-to-setup-freecodecamp-locally.md Normal file
View File

@ -0,0 +1,546 @@
Follow these guidelines for setting up freeCodeCamp locally on your system. This is highly recommended if you want to contribute regularly.
For some of the contribution workflows, you need to have freeCodeCamp running locally. For example, previewing coding challenges or debugging and fixing bugs in the codebase.
> [!TIP] If you are not interested in setting up freeCodeCamp locally consider using Gitpod, a free online dev environment.
>
> [![Open in 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.)
## Prepare your local machine
Start by installing the prerequisite software for your operating system.
We primarily support development on **\*nix** systems. Our staff and community contributors regularly work with the codebase using tools installed on Ubuntu and macOS.
We also support Windows 10 via WSL2, which you can prepare by [reading this guide](/how-to-setup-wsl).
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.
**Prerequisites:**
| Prerequisite | Version | Notes |
| --------------------------------------------------------------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Node.js](http://nodejs.org) | `12.x` | [LTS Schedule](https://github.com/nodejs/Release#release-schedule) |
| npm (comes bundled with Node) | `6.x` | Does not have LTS releases, we use the version bundled with Node LTS |
| [MongoDB Community Server](https://docs.mongodb.com/manual/administration/install-community/) | `3.6` | [Release Notes](https://docs.mongodb.com/manual/release-notes/), Note: We are currently on `3.6`, an [upgrade is planned](https://github.com/freeCodeCamp/freeCodeCamp/issues/18275). |
> [!DANGER] 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.
If Node.js is already installed on your machine, run the following commands to validate the versions:
```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.
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.
2. (Optional but recommended) [Set up an SSH Key](https://help.github.com/articles/generating-an-ssh-key/) for GitHub.
3. Install a code editor of your choice.
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.
4. Set up linting for your code editor.
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).
> [!TIP] Please do not ignore any linting errors. They are meant to **help** you and to ensure a clean and simple codebase.
## Fork the repository on 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.
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).
> [!TIP] The main repository at `https://github.com/freeCodeCamp/freeCodeCamp` is often referred to as the `upstream` repository.
>
> Your fork at `https://github.com/YOUR_USER_NAME/freeCodeCamp` is often referred to as the `origin` repository.
**Follow these steps to fork the `https://github.com/freeCodeCamp/freeCodeCamp` repository:**
1. Go to the freeCodeCamp repository on GitHub: <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/))
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`
<details>
<summary>
How to fork freeCodeCamp on GitHub (screenshot)
</summary>
<br>
<img src="https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/master/docs/images/github/how-to-fork-freeCodeCamp.gif" alt="How to fork freeCodeCamp on GitHub" />
</details>
## Clone your fork from 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`.
Run these commands on your local machine:
1. Open a Terminal / Command Prompt / Shell in your projects directory
_i.e.: `/yourprojectsdirectory/`_
2. Clone your fork of freeCodeCamp, replacing `YOUR_USER_NAME` with your GitHub Username
```console
git clone --depth=1 https://github.com/YOUR_USER_NAME/freeCodeCamp.git
```
This will download the entire freeCodeCamp repository to your projects directory.
Note: `--depth=1` creates a shallow clone of your fork, with only the most recent history/commit.
## 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.
[As mentioned earlier](#fork-the-repository-on-github), the main repository is referred `upstream` repository. Your fork referred to as the `origin` repository.
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.
1. Change directory to the new freeCodeCamp directory:
```console
cd freeCodeCamp
```
2. Add a remote reference to the main freeCodeCamp repository:
```console
git remote add upstream https://github.com/freeCodeCamp/freeCodeCamp.git
```
3. Ensure the configuration looks correct:
```console
git remote -v
```
The output should look something like below:
```console
origin https://github.com/YOUR_USER_NAME/freeCodeCamp.git (fetch)
origin https://github.com/YOUR_USER_NAME/freeCodeCamp.git (push)
upstream https://github.com/freeCodeCamp/freeCodeCamp.git (fetch)
upstream https://github.com/freeCodeCamp/freeCodeCamp.git (push)
```
## Running freeCodeCamp locally
Now that you have a local copy of freeCodeCamp, you can follow these instructions to run it locally. This will allow you to:
- 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.
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.
And as always, feel free to hop on to our [Contributors Chat room on Gitter](https://gitter.im/FreeCodeCamp/Contributors) or [our Discord server](https://discord.gg/6vJYm9V), for quick queries.
> [!TIP] You may skip running freeCodeCamp locally if you are simply editing files. For instance, performing a `rebase`, or resolving `merge` conflicts.
>
> 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).
### Configuring dependencies
#### Step 1: Set up the environment variable file
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.
```console
# Create a copy of the "sample.env" and name it ".env".
# Populate it with the necessary API keys and secrets:
# macOS / Linux
cp sample.env .env
# Windows
copy sample.env .env
```
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.
> [!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.
#### Step 2: Install dependencies
This step will install the dependencies required for the application to run:
```console
npm ci
```
#### Step 3: Start MongoDB and seed the database
Before you can run the application locally, you will need to start the MongoDB service.
> [!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.
Start the MongoDB server in a separate terminal:
- On macOS & Ubuntu:
```console
mongod
```
- On Windows, you must specify the full path to the `mongod` binary
```console
"C:\Program Files\MongoDB\Server\3.6\bin\mongod"
```
Make sure to replace `3.6` with the version you have installed
> [!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/)
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.
```console
npm run seed
```
#### Step 4: Start the freeCodeCamp client application and API server
You can now start up the API server and the client applications.
```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.
> [!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] The API Server serves APIs at `http://localhost:3000`. The Gatsby app serves the client application at `http://localhost:8000`
> If you visit <http://localhost:3000/explorer> you should see the available APIs.
## 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.
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.
Simply clicking the **"Preview Custom 404 Page"** button will forward you to the correct 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" />
</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 `master` branch:
```console
git status
```
You should get an output like this:
```console
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
```
If you are not on master or your working directory is not clean, resolve any outstanding files/commits and checkout `master`:
```console
git checkout master
```
2. Sync the latest changes from the freeCodeCamp upstream `master` branch to your local master branch:
> [!WARNING] If you have any outstanding pull request that you made from the `master` branch of your fork, you will lose them at the end of this step.
>
> 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 `master`.
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/master` as often as possible to avoid conflicts later.
Update your local copy of the freeCodeCamp upstream repository:
```console
git fetch upstream
```
Hard reset your master branch with the freeCodeCamp master:
```console
git reset --hard upstream/master
```
Push your master branch to your origin to have a clean history on your fork on GitHub:
```console
git push origin master --force
```
You can validate your current master matches the upstream/master by performing a diff:
```console
git diff upstream/master
```
The resulting output should be empty.
3. Create a fresh new branch:
Working on a separate branch for each issue helps you keep your local work copy clean. You should never work on the `master`. This will soil your copy of freeCodeCamp and you may have to start over with a fresh clone or fork.
Check that you are on `master` as explained previously, and branch off from there:
```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.
Some examples of good branch names are:
```md
fix/update-challenges-for-react
fix/update-guide-for-html-css
fix/platform-bug-sign-in-issues
feat/add-guide-article-for-javascript
translate/add-spanish-basic-html
```
4. Edit pages and work on code in your favorite text editor.
5. Once you are happy with the changes you should optionally run freeCodeCamp locally to preview the changes.
6. Make sure you fix any errors and check the formatting of your changes.
7. Check and confirm the files you are updating:
```console
git status
```
This should show a list of `unstaged` files that you have edited.
```console
On branch feat/documentation
Your branch is up to date with 'upstream/feat/documentation'.
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
modified: docs/README.md
modified: docs/how-to-setup-freecodecamp-locally.md
modified: docs/how-to-work-on-guide-articles.md
...
```
8. Stage the changes and make a commit:
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:
```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
Your branch is up to date with 'upstream/feat/documentation'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: CONTRIBUTING.md
modified: docs/README.md
modified: docs/how-to-setup-freecodecamp-locally.md
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
fix: update build scripts for Travis-CI
feat: add article for JavaScript hoisting
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.
This does not take any additional time than an unconventional message like 'update file' or '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).
9. If you realise 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:
```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.
10. Next, you can push your changes to your fork:
```console
git push origin branch/name-here
```
## Proposing a Pull Request (PR)
After you've committed your changes, check here for [how to open a Pull Request](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 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. |
## 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).
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.
If you are on a different OS and/or are still running into issues, see [getting help](#getting-help).
> [!WARNING]
>
> Please avoid creating GitHub issues for prerequisite issues. They are out of the scope of this project.
### Issues with the UI, Fonts, build errors etc.
If you face issues with the UI, Fonts or see builds errors a cleanup can be useful:
```console
npm run clean
npm ci
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 interative mode:
```
git clean -ifdX
```
<details>
<summary>
How to clean git untracked files (screenshot)
</summary>
<br>
<img src="https://user-images.githubusercontent.com/1884376/94270515-ca579400-ff5d-11ea-8ff1-152cade31654.gif" alt="How to clean git untracked files" />
</details>
### Issues with API, Login, Challenge Submissions, etc.
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.
**On Linux / macOS / WSL on Windows - From Terminal:**
```console
netstat -ab | grep "3000"
tcp4 0 0 0.0.0.0:3000 DESKTOP LISTEN
```
**On Windows - From Elevated PowerShell:**
```powershell
netstat -ab | Select-String "3000"
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 recommed using GitPod instead of an offline setup.
## Getting Help
If you are stuck and need help, let us know by asking in the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or the [Contributors chat room](https://gitter.im/FreeCodeCamp/Contributors) on Gitter.
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.

129
docs/i18n/Afrikaans/how-to-setup-wsl.md Normal file
View File

@ -0,0 +1,129 @@
# Set up freeCodeCamp on Windows Subsystem for Linux (WSL)
> [!NOTE] Before you follow these instructions make sure your system meets the requirements
>
> **WSL 2**: Windows 10 64-bit (Version 2004, Build 19041 or higher) - available for all distributions including 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)
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 the our local setup guide to work with freeCodeCamp on Windows running a WSL distro like Ubuntu.
## Enable 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.
## Install Ubuntu
1. We recommended using Ubuntu-18.04 or above with WSL2.
> [!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.
2. Update the dependencies for the OS
```console
sudo apt update
sudo apt upgrade -y
# cleanup
sudo apt autoremove -y
```
## Set up Git
Git comes pre-installed with Ubuntu 18.04, verify that your Git version with `git --version`.
```output
~
❯ git --version
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.
## 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.
Essentially, you will edit and store your code on Ubuntu-18.04 with VS Code installed on Windows.
## Installing Docker Desktop
**Docker Desktop for Windows** allows you to install and run database and services like MongoDB, NGINX, etc. This is useful to avoid common pitfalls with installing MongoDB or other services directly on Windows or WSL2.
Follow the instructuction on the [official documentation](https://docs.docker.com/docker-for-windows/install) and install Docker Desktop for your Windows distribution.
There are some minimum hardware requirements for the best experience.
## Configure 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.
This makes it so that the containers run on WSL side instead of running on Windows. You will be able to access the services over `http://localhost` on both Windows and Ubuntu.
## Install MongoDB from Docker Hub
Once you have configured Docker Desktop to work with WSL2, follow these steps to start a MongoDB service:
1. Launch a new Ubuntu-18.04 terminal
2. Pull `MongoDB 3.6` from dockerhub
```console
docker pull mongo:3
```
3. Start the MongoDB service at port `27017`, and configure it to run automatically on system restarts
```console
docker run -it \
-v mongodata:/data/db \
-p 27017:27017 \
--name mongodb \
--restart unless-stopped \
-d mongo:3
```
4. You can now access the service from both Windows or Ubuntu at `mongodb://localhost:27017`.
## Installing Node.js and 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).
Once installed use these commands to install and use the Node.js version as needed
```console
nvm install --lts
# OR
# nvm install <version>
nvm install 14
# Usage
# nvm use <version>
nvm use 12
```
Node.js comes bundled with `npm`, you can update to the latest versions of `npm` with:
```console
npm install -g npm@latest
```
## Set up freeCodeCamp locally
Now that you have installed the pre-requisites, follow [our local setup guide](https://contribute.freecodecamp.org/#/how-to-setup-freecodecamp-locally) to clone, install and setup freeCodeCamp locally on your machine.
> [!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.
## 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:
- [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)

15
docs/i18n/Afrikaans/how-to-use-docker-on-windows-home.md Normal file
View File

@ -0,0 +1,15 @@
# How to use Docker on Windows Home
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.
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.
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.
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.

541
docs/i18n/Afrikaans/how-to-work-on-coding-challenges.md Normal file
View File

@ -0,0 +1,541 @@
# 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, and there's a place for those on Medium and YouTube. However, 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.
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. Stay active in the [contributors room](https://gitter.im/freecodecamp/contributors) and ask lots of questions.
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 own markdown file. This markdown file is later converted to HTML using our tools to create interactive web pages.
You can find all of freeCodeCamp.org's curricular content in the [`/curriculum/challenges`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges) directory.
## 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.
[![Open in 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 again.
## Challenge Template
Below is a template of what the challenge markdown files look like currently. To see the streamlined template we will be adopting see [below](#upcoming-challenge-template).
````md
---
id: Unique identifier (alphanumerical, MongoDB_id)
title: Challenge Title
challengeType: 0
videoUrl: 'url of video explanation'
---
## Description
<section id='description'>
A Description of the challenge and what is required to pass
</section>
## Instructions
<section id='instructions'>
Instructions about what exactly needs to be done.
</section>
## Tests
<section id='tests'>
```yml
tests:
- text: Should return "foo"
testString: 'A stringified function possibly using Chai asserts'
````
</section>
## Challenge Seed
<section id='challengeSeed'>
<div id='{ext}-seed'>
```{ext}
Code displayed in the editor by default.
This is a required section for the challenge.
```
</div>
### Before Test
<div id='{ext}-setup'>
```{ext}
Optional Test setup code.
```
</div>
### After Test
<div id='{ext}-teardown'>
```{ext}
Optional Test tear down code.
```
</div>
</section>
## Solution
<section id='solution'>
```{ext}
// solution required
```
</section>
````
> [!NOTE]
>
> 1. In the above sections, examples of `{ext}` are:
>
> - `html` - HTML/CSS
> - `js` - JavaScript
> - `jsx` - JSX
>
> 2. For the `Tests` section above, `text` and `testString` should be valid YAML strings. `testString` can be a stringified function or expression using which could use Chai asserts.
## 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.).
To generate a new one in a shell (assuming MongoDB is running separately):
1. Run `mongo` command.
2. Run `ObjectId()` command.
For example:
```bash
$ mongo
MongoDB shell version v3.6.1
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.4.10
...
$ ObjectId()
ObjectId("5a474d78df58bafeb3535d34")
````
The result is a new id, for example `5a474d78df58bafeb3535d34` above.
Once you have your id, put it into the markdown file as the `id` field at the top, e.g.
```yml
---
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.
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").
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.
You can add diagrams if absolutely 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.
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)
- Node.js
- Front-end development (adjective form with a dash) is when you're working on the front end (noun form with no dash). The same goes with "back end", "full stack", and many other compound terms.
### The 2-minute rule
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 own code and get all the tests to pass.
If it takes longer than two minutes to complete the challenge, you have two options:
- Simplify the challenge, or
- Split the challenge into two challenges.
The 2-minute rule forces you, the challenge designer, to make your directions concise, your seed code clear, and your tests straight-forward.
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.
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.
Our goal is to have thousands of 2-minute challenges. These can flow together and reiterate previously-covered concepts.
### Formatting challenge text
Here are specific formatting guidelines for challenge text and examples:
- Language keywords go in `<code>` tags. For example, HTML tag names or CSS property names
- The first instance of a keyword when it's being defined, or general keywords (i.e. "object" or "immutable") go in `<dfn>` tags
- References to code parts (i.e. function, method or variable names) should be wrapped in `<code>` tags. See example below:
- Use <code>parseInt</code> to convert the variable <code>realNumber</code> into an integer.
- 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 newline which only has three backticks and **another empty line**. **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.
See example below:
````md
The following is an example of code:
```{language}
[YOUR CODE HERE]
````
````
- Additional information in the form of a note should be formatted `<strong>Note:</strong> Rest of note text...`
- If multiple notes are needed, then list all of the notes in separate sentences using the format `<strong>Notes:</strong> First note text. Second note text.`.
- Use double quotes where applicable
## 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.
## 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
- Comments made should have a space between the comment characters and the comment themselves
`// Fix this line`
## 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.
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.
### 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.
### 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 need 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)
---
## Hints
### Hint 1
Hint goes here
### Hint 2
Hint goes here
---
## Solutions
<details><summary>Solution 1 (Click to Show/Hide)</summary>
```js
function myFunc() {
console.log('Hello World!');
}
````
#### Code Explanation
- Code explanation goes here
- Code explanation goes here
#### Relevant Links
- [Link Text](link_url_goes_here)
- [Link Text](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.
1. To test all challenges run the below command from the root directory
````
npm run test:curriculum
```
2. You can also test a block or a superblock of challenges with these commands
```
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. Switch to the `curriculum` directory:
```
cd curriculum
```
2. Run the following for each challenge file for which you have changed:
```
npm run test -- -g 'the full English title of the challenge'
```
Once you have verified that each challenge you've worked on passes the tests, [please create a pull request](https://github.com/freeCodeCamp/freeCodeCamp/blob/master/docs/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.
>
> The currently accepted values are `english` and `chinese`, with `english` being set by default.
## Upcoming Challenge Template
The challenge template in the process of being updated to a cleaner, less nested structure. This has not been completely finalized, but the following should close to the final structure:
````mdx
---
id: Unique identifier (alphanumerical, MongoDB_id)
title: 'Challenge Title'
challengeType: Integer, defined in `client/utils/challengeTypes.js`
videoUrl: 'url of video explanation'
forumTopicId: 12345
---
import Script from './script.mdx';
## --step-description--
Description text, in markdown
```html
<div>
example code
</div>
```
## --step-hints--
![test-id-1]
There will be an arbitrary number of triples of ids, instructions (in markdown) and code blocks.
```js
Code for test one
```
![test-id-2]
More instructions in markdown syntax
```js
More code
```
## --step-seed--
### --before-user-code--
```lang
Code evaluated before the user’s
```
### --after-user-code--
```lang
Code evaluated after the user’s, and just before the tests
```
### --seed-content--
![index-html]
```html
Some html
```
```css
Some css
```
```js
Some js
```
![index-js]
<Script ></p>
<h1 spaces-before="0">
--solution-marker--
</h1>
<p spaces-before="0">
Exactly the same as the seeds section
</p>
<h2 spaces-before="0">
--next-solution-marker
</h2>
<p spaces-before="0">
Same again
</p>
<h1 spaces-before="0">
--question-marker--
</h1>
<h2 spaces-before="0">
--text-marker--
</h2>
<p spaces-before="0">
The question would go here (only used for video challenges)
</p>
<h2 spaces-before="0">
--answers-marker--
</h2>
<p spaces-before="0">
Answer 1
</p>
<hr />
<p spaces-before="0">
Answer 2
</p>
<hr />
<p spaces-before="0">
More answers
</p>
<h2 spaces-before="0">
--solution-marker--
</h2>
<p spaces-before="0">
\<number of correct answer\>
</p>
<p spaces-before="0">
````
</p>
<h3 spaces-before="0">
Useful Links
</h3>
<p spaces-before="0">
Creating and Editing Challenges:
</p>
<ol start="1">
<li>
<p spaces-before="0">
<a href="https://github.com/freeCodeCamp/freeCodeCamp/blob/master/client/utils/challengeTypes.js#L1-L13">Challenge types</a> - what the numeric challenge type values mean (enum).
</p>
</li>
<li>
<p spaces-before="0">
<a href="https://www.youtube.com/watch?v=iOdD84OSfAE#t=2h49m55s">Contributing to FreeCodeCamp - Writing ES6 Challenge Tests</a> - a video following <a href="https://twitter.com/ArrowoodTech">Ethan Arrowood</a> as he contributes to the old version of the curriculum.
</p>
</li>
</ol>

40
docs/i18n/Afrikaans/how-to-work-on-the-docs-theme.md Normal file
View File

@ -0,0 +1,40 @@
# 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.
>
> To work on the contributing guidelines, you can edit or add files in the `docs` directory [available here](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/docs). When your changes are merged, it will be made available automatically at the documentation site.
## Structure of the docs website
The site is generated using [`docsify`](https://docsify.js.org), and served using GitHub pages.
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).
## Serving the documentation site locally
Clone freeCodeCamp:
```sh
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
docsify serve docs
```
Install `docsify`:
```sh
npm install -g docsify
```
and serve the `/docs` directory
```sh
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 `npm run docs:serve` from the root of the repo.

10
docs/i18n/Afrikaans/how-to-work-on-the-news-theme.md Normal file
View File

@ -0,0 +1,10 @@
<!--
The source for this document is available at:
https://github.com/freeCodeCamp/news-theme/blob/master/CONTRIBUTING.md
Please edit that file instead.
-->
[remote-markdown-url](https://raw.githubusercontent.com/freeCodeCamp/news-theme/master/CONTRIBUTING.md)

45
docs/i18n/Afrikaans/index.md Normal file
View File

@ -0,0 +1,45 @@
Die [freeCodeCamp.org](https://freecodecamp.org) gemeenskap is moontlik vanweë duisende vriendelike vrywilligers soos jy. Ons welkom enige en al gemeenskapsbydraes, en ons is opgewonde om jou aan boord te verwelkom.
> [!NOTE] Before you proceed, please take a quick 2 minutes to read our [Code of Conduct](https://www.freecodecamp.org/code-of-conduct). We enforce it strictly across our community. We want contributing to freeCodeCamp.org to be a safe and inclusive experience for everyone.
Happy contributing.
You are welcome to:
- Create, update and fix bugs in our [coding challenges](#coding-challenges).
- Help us fix bugs in freeCodeCamp.org's [learning platform](#learning-platform).
- _(Coming Soon)_ Help us translate freeCodeCamp.org to world languages.
Have questions? Head over to [these FAQs](/FAQ.md) where we answer some common queries about contributing.
## Coding Challenges
All our coding challenges are curated by the community, bringing in expert knowledge from volunteers like you.
You can help expand them and make their wording better. You can also update the user stories to explain the concept better or remove redundant ones and improve the challenge tests to make them more accurately test people's code.
**If you're interested in improving these coding challenges, here's [how to work on coding challenges](how-to-work-on-coding-challenges.md).**
## Learning Platform
Our learning platform runs on a modern JavaScript stack. It has various components, tools, and libraries, including but not limited to, Node.js, MongoDB, LoopBack, OAuth 2.0, React, Gatsby, Webpack, and more.
Broadly,
- We have a Node.js based API server.
- A set of React-based client applications.
- A script that we use to evaluate our front-end projects.
Contributing to this requires some understanding of APIs, ES6 Syntax, and a lot of curiosity.
Essentially, we expect basic familiarity with some of the aforementioned technologies, tools, and libraries. With that being said, you are not required to be an expert on them to contribute.
**If you want to help us improve our codebase, you can either use Gitpod, a free online dev environment**
[![Open in 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.)
OR
**you can [set up freeCodeCamp locally](how-to-setup-freecodecamp-locally.md) on your machine.**

101
docs/i18n/Arabic/FAQ.md Normal file
View File

@ -0,0 +1,101 @@
### أنا جديد على GitHub و Open Source، أين يجب أن أبدأ؟
اقرأ ["كيفية المساهمة في دليل المصدر المفتوح"](https://github.com/freeCodeCamp/how-to-contribute-to-open-source). إنه مورد جامع من أول مشاريع ومبادئ توجيهية ملائمة للتوقيت
### هل يمكنني ترجمة المنهج التعليمي لـ FreCodeCamp؟
سنقوم بإطلاق جهود التوطين على FreCodeCamp بدءاً ب **الصينية** أولاً.
ونحن نعتزم جعل المنهاج الدراسي متاحا بمزيد من اللغات، ولكن لا يمكننا الالتزام بأي مواعيد نهائية حتى الآن. وتؤدي عدة قيود تشغيلية مثل الموظفين والمساهمين النشطين وتكاليف حواسيب الخدمة دورا في دفع جهود التدويل (18 سنة).
ونحن نعتزم البدء في بذل جهود في إطار برنامج العمل 18n بهذه اللغات: العربية والبرتغالية. الروسية والإسبانية (دون ترتيب محدد) بعد أن أصدرنا المنهج الدراسي باللغة الصينية.
**لماذا تركز على المناهج الصينية أولاً؟**
الصين هي أكبر المناطق الديمغرافية، في جمهورنا غير الناطقين بالإنجليزية الأصلية. حاليا، لدينا مئات الآلاف من المستخدمين باستخدام نسخة قديمة من المنصة. والتركيز على المنهج الدراسي الصيني سيعطينا تقديرا للسوقيات المشاركة في الـ i18n.
وسوف نركز على أمريكا اللاتينية بوصفها المنطقة الديمغرافية للبرتغالية والإسبانية.
وليس لدينا أي خطط لـ i18n في المستقبل المنظور لأي لغة أخرى غير ما ورد أعلاه.
ونحن لا نشجعكم على العمل بشأن الـ i18 باللغات المذكورة أعلاه. ويمكننا أن نقبل طلبات السحب دون أن نتوقع أي مواعيد زمنية لنشر القوات.
### كيف يمكنني الإبلاغ عن خطأ جديد؟
إذا كنت تعتقد أنك وجدت خطأ، اقرأ أولاً مقالة ["ساعدني في العثور على بوج"](https://forum.freecodecamp.org/t/how-to-report-a-bug/19543) واتبع تعليماتها.
إذا كنت واثقا من أنه خطأ جديد، قم بالمضي قدما و أنشئ مشكلة GitHub جديدة. تأكد من تضمين أكبر قدر ممكن من المعلومات حتى نتمكن من تكرار الخطأ. لدينا نموذج مشكلة محدد مسبقاً لمساعدتك من خلال هذا.
يرجى ملاحظة أنه سيتم إغلاق أي مشاكل تبحث عن مساعدة في الترميز في التحدي. أما تعقب القضايا فيتعلق حصراً بالقضايا والمناقشات ذات الصلة بالترادف. كلما كان هناك شك، يجب عليك [طلب المساعدة في المنتدى](https://forum.freecodecamp.org) قبل إعداد التقرير.
### كيف يمكنني الإبلاغ عن مسألة أمنية؟
الرجاء عدم إنشاء مشاكل GitHub للمشاكل الأمنية. بدلاً من ذلك، يرجى إرسال بريد إلكتروني إلى `security@freecodecamp.org` وسوف ننظر فيه فوراً.
### أنا طالب، هل يمكنني أو فريقنا العمل على ميزة للائتمانات الأكاديمية؟
نعم، بالتأكيد.
وفي حين أننا منفتحون على جميع المساهمات، يرجى ملاحظة أننا غير قادرين على الالتزام بأي جداول زمنية قد تكون مطلوبة في الكلية أو الجامعة الخاصة بك. ونحن نتلقى العديد من طلبات السحب وإسهامات الرموز من مطوري المتطوعين، ونحن نحترم وقتهم وجهودهم. ولن يكون بوسعنا أن نولي أي رأي رسمي أي اهتمام خاص ليكون منصفا للجميع.
ونطلب منكم أن تخطططوا مسبقا وأن تعملوا على وضع هذه الميزة نصب أعيننا.
### ماذا تعني هذه التسميات المختلفة الموسومة على المشكلات؟
مشرفو التعليمات البرمجية [مقارنة](https://en.wikipedia.org/wiki/Software_bug#Bug_management) يصدرون الطلبات ويسحبون الطلبات بناء على أولويتهم وشدتهم وعوامل أخرى. يمكنك [العثور على مسرد كامل لمعانيهم هنا](https://github.com/freecodecamp/freecodecamp/labels).
### أين أبدأ إذا أردت أن أعمل بشأن إحدى القضايا؟
يجب أن تمر عبر [**`المساعدة المطلوبة`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) أو [**`المؤقت الأول فقط`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22first+timers+only%22) من أجل نظرة عامة سريعة لما هو متاح لك للعمل عليه.
> [!تلميح] **`ساعد`** المشكلات المطلوبة ، ولا تحتاج إلى البحث عن إذن قبل العمل عليها. ومع ذلك، فإن المشكلات مع **`التسمية الأولى فقط`** محفوظة للأشخاص الذين لم يساهموا في رمز FreCodeCamp من قبل. وإذا كانت هذه المسائل تفتقر إلى الوضوح بشأن ما ينبغي عمله، فلا تتردد في طرح الأسئلة في التعليقات.
### وجدت طابعاً، هل يجب أن أبلغ عن مشكلة قبل أن أتمكن من تقديم طلب سحب؟
بالنسبة للطباعيات وغيرها من التغييرات في الصياغة، يمكنك فتح طلبات السحب مباشرة دون إنشاء مشكلة أولاً. أما القضايا فتتعلق بقدر أكبر بمناقشة المشاكل الأكبر المرتبطة بالجوانب البرمجية أو الهيكلية للمناهج الدراسية.
ومع ذلك، يرجى ذكر التفاصيل، والسياق، وما إلى ذلك في مجال وصف طلب السحب لمساعدتنا على فهم واستعراض مساهمتك حتى من أجل إجراء تغييرات طفيفة.
### كيف أحصل على مشكلة تم تعيينها لي؟
وعادة ما لا نحيل المسائل إلى أي شخص آخر غير المساهمين منذ وقت طويل لتجنب العروض الغامضة التي لا تظهر على الإطلاق. وبدلا من ذلك، نتبع السياسة التالية لتكون عادلة للجميع:
1. يفضل دمج طلب السحب الأول لأي مشكلة.
2. في حالة طلبات السحب المتعددة لنفس المشكلة، نعطي الأولوية لجودة الرمز في طلبات السحب .
- هل قمت بإدراج اختبارات؟
- هل حصلت على جميع الاستخدامات؟
- هل تأكد من مرور جميع الاختبارات، وأكدت أن كل شيء يعمل محليا؟
3. وأخيرا، نحن نؤيد طلبات السحب التي تتبع مبادئنا التوجيهية الموصى بها.
- هل اتبعت قائمة طلب السحب؟
- هل قمت بتسمية عنوان طلب السحب الخاص بك؟
أنت لست بحاجة إلى أي إذن للمشكلات التي تم وضع علامة عليها `المساعدة المطلوبة` أو `المؤقت الأول فقط` كما هو موضح سابقاً.
اتبع المبادئ التوجيهية بعناية وفتح طلب الجذب.
### وأنا عالقة بشأن شيء غير مدرج في هذه الوثائق.
**لا تتردد في طلب المساعدة في:**
- The `Contributors` category of [our community forum](https://forum.freecodecamp.org/c/contributors).
- The public `Contributors` [chat room on Gitter](https://gitter.im/FreeCodeCamp/Contributors).
- The `#Contributors` channel on [our Discord community server](https://discord.gg/pFspAhS).
ونحن متحمسون لمساعدتك في المساهمة في أي من المواضيع التي تودون العمل بشأنها. لا تتردد في طرح أسئلة علينا بشأن المواضيع ذات الصلة، وسوف يسعدنا أن نوضح ذلك. تأكد من البحث عن استفسارك قبل نشر استعلام جديد.
كن مهذباً وصبراً. مجتمعنا من المتطوعين والمديرين دائمًا ما يدور لإرشادك من خلال الاستفسارات الخاصة بك.
**المساعدة الإضافية**
إذا كان لديك استفسارات حول المكدس ، هندسة الكود ، لا تتردد في التواصل مع فريق موظفينا:
| الموظفون | إرسال رسالة في المنتدى |
|:-------------------- |:---------------------------------------------------------------------------- |
| مروجيش محباترا | [@raisedadead](https://forum.freecodecamp.org/u/raisedadead) |
| أحمد عبد الشاب | [@abdolsa](https://forum.freecodecamp.org/u/abdolsa) |
| Kristofer Koishigawa | [@scissorsneedfoodtoo](https://forum.freecodecamp.org/u/scissorsneedfoodtoo) |
| توم موندلوك | [@moT01](https://forum.freecodecamp.org/u/moT01) |
| أوليفر إيتون ويليامز | [@ojeytonwilliams](https://forum.freecodecamp.org/u/ojeytonwilliams) |
| رانديل داوسون | [@RandellDawson](https://forum.freecodecamp.org/u/randelldawson) |
**يمكنك إرسال بريد إلكتروني لموظفي المطور في: `dev[at]freecodecamp.org`**

36
docs/i18n/Arabic/_sidebar.md Normal file
View File

@ -0,0 +1,36 @@
- **بدء العمل**
- [مقدمة](/index.md "المساهمة في مجتمع FreCodeCamp.org")
- [الأسئلة المتكررة](/FAQ.md)
- **مساهمة الرمز**
- - [إعداد FreCodeCamp محليا](/how-to-setup-freecodecamp-locally.md)
- [فتح طلب سحب](/how-to-open-a-pull-request.md)
- [العمل على تحديات البرمجة](/how-to-work-on-coding-challenges.md)
- [العمل المتعلق بتحديات الفيديو](/how-to-help-with-video-challenges.md)
- [العمل المتعلق بموضوع الأخبار](/how-to-work-on-the-news-theme.md)
- [العمل في موضوع المستندات](/how-to-work-on-the-docs-theme.md)
- **أدلة اختيارية**
- [التقط رسائل البريد الإلكتروني الصادرة محليا](/how-to-catch-outgoing-emails-locally.md)
- [إعداد freeCodeCamp على WSL](/how-to-setup-wsl.md)
---
- **中文社区贡献指南**
- [成为专栏作者](/i18n/chinese/news-author-application.md)
- [文章翻译计划](/i18n/chinese/news-translations.md)
- [视频翻译计划](/i18n/chinese/video-translations.md)
---
- **دليل الرحلات الجوية** (للموظفين & موحد)
- [دليل المشرف](/flight-manuals/moderator-handbook.md)
- [قوالب الرد](/flight-manuals/using-reply-templates.md)
- [استعراض DevOps](/devops.md)
- [العمل على الخوادم](/flight-manuals/working-on-virtual-machines.md)
---
- **مجتمعنا**
- [**GitHub**](https://github.com/freecodecamp/freecodecamp)
- [**منتدى الخطاب**](https://freecodecamp.org/forum/c/contributors)
- [**دردشة Gitter**](https://gitter.im/FreeCodeCamp/Contributors)
- [**Discord Server**](https://discord.gg/pFspAhS)

227
docs/i18n/Arabic/devops.md Normal file
View File

@ -0,0 +1,227 @@
# عمليات المطور في freeCodeCamp.org
هذا الدليل سيساعدك على فهم مكدس البنية التحتية الخاص بنا وكيف نحافظ على المنصات الخاصة بنا. ورغم أن هذا الدليل لا يتضمن تفاصيل شاملة عن جميع العمليات، فإنه يمكن استخدامه كمرجع لفهمكم للنظم.
دعونا نعلم، إذا كان لديكم تغذية مرتدة أو استفسارات، وسيكون من دواعي سرورنا أن نوضح ذلك.
## كيف يمكننا أن نبني ونختبر وننشر الكود البرمجي؟
يتم بناء هذا المستودع بشكل مستمر واختباره ونشره في **مجموعات منفصلة من البنية التحتية (سيرفرات وقواعد البيانات وCDN، وما إلى ذلك)**.
وينطوي ذلك على ثلاث خطوات يتعين اتباعها بالتسلسل:
1. يتم دمج التغييرات الجديدة (الإصلاحات والميزات) في فرع التطوير الأساسي الخاص بنا (`الرئيسية`) عن طريق طلبات السحب.
2. وتجري هذه التغييرات من خلال سلسلة من الاختبارات المؤتمتة.
3. وبمجرد اجتياز الاختبارات نعلن عن التغييرات (أو تحديثها إذا اقتضى الأمر) لنشرها على بنيتنا التحتية.
#### بناء الشريط البرمجي - رسم خرائط فروع Git للنشر.
عادةً، [`سيد`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master) (فرع التطوير الافتراضي) يدمج في [`تجهيز الإنتاج`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) فرع مرة واحدة في اليوم ويطلق في بنية تحتية معزولة.
هذا هو الإصدار الوسيط للمطورين والمساهمين المتطوعين. كما أنه يعرف باسم "الإنتظار" أو "بيتا".
إنه مطابق لبيئتنا الإنتاجية الحية في `freeCodeCamp.org`، بخلاف ذلك باستخدام مجموعة منفصلة من قواعد البيانات، الخوادم، وكلاء الويب، إلخ. تتيح لنا هذه العزلة اختبار التطوير المستمر والميزات في "الإنتاج" مثل السيناريو، دون التأثير على المستخدمين المنتظمين للمنصات الرئيسية لـ freeCodeCamp.org.
مرة واحدة فريق المطور [`@freeCodeCamp/dev-team`](https://github.com/orgs/freeCodeCamp/teams/dev-team/members) سعيد بالتغييرات على منصة التجهيز ، يتم نقل هذه التغييرات كل بضعة أيام إلى فرع [`الإنتاج الحالي`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-current)
هذا هو الإصدار النهائي الذي ينقل التغييرات إلى منصات الإنتاج لدينا على freeCodeCamp.org.
#### اختبار التغييرات - اختبار التكامل وقبول المستخدم.
نحن نستخدم مختلف مستويات اختبار التكامل والقبول للتحقق من جودة الشفرة. تتم جميع اختباراتنا من خلال برمجيات مثل [Travis CI](https://travis-ci.org/freeCodeCamp/freeCodeCamp) و [Azure Pipelines](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp).
لدينا اختبارات وحدة لاختبار حلول التحدي الخاصة بنا، واجهات برمجة تطبيقات الخادم وواجهة مستخدم العميل. هذه تساعدنا على اختبار التكامل بين المكونات المختلفة.
> [!ملحوظة] نحن أيضا في عملية كتابة اختبارات المستخدم النهائي التي ستساعد في تكرار سيناريوهات العالم الحقيقي مثل تحديث البريد الإلكتروني أو إجراء مكالمة إلى خدمات API أو طرف ثالث.
وتساعد هذه الاختبارات معا في منع المشاكل من تكرار نفسها والتأكد من أننا لا ندخل خلل أثناء العمل على خلل آخر أو ميزة أخرى.
#### نشر التغييرات - دفع التغييرات إلى الخوادم.
لقد قمنا بتكوين برنامج التوصيل المستمر لدفع التغييرات إلى خوادم التطوير والإنتاج لدينا.
وبمجرد دفع التغييرات إلى فروع الإفراج المحمية، يبدأ تشغيل خط أنابيب البناء تلقائياً للفرع. وخطوط أنابيب البناء مسؤولة عن بناء الأعمال الفنية وإبقائها في مخزن بارد لاستخدامها في وقت لاحق.
ويمضي خط أنابيب البناء لتفعيل خط أنابيب الإفراج المقابل إذا أنجز عملية تشغيل ناجحة. وخطوط أنابيب الإصدار مسؤولة عن جمع فنون البناء، ونقلها إلى الخوادم، والسير على قيد الحياة.
حالة الإنشاءات والإصدارات [متاحة هنا](#build-test-and-deployment-status).
## تنشيط البناء والاختبار والنشر.
وفي الوقت الراهن، لا يستطيع سوى الأعضاء في فريق المطور الدفع إلى فروع الإنتاج. التغييرات في فروع `الإنتاج *` يمكن أن تهبط فقط عن طريق الدمج السريع للأمام إلى [`أعلى`](https://github.com/freeCodeCamp/freeCodeCamp).
> [!ملحوظة] في الأيام القادمة سنقوم بتحسين هذا التدفق ليتم عن طريق طلبات الجذب، لتحسين إدارة الوصول والشفافية.
### دفع التغييرات إلى التطبيقات المرحلية.
1. تكوين أجهزة التحكم الخاصة بك بشكل صحيح.
```sh
git البعيد -v
```
**النتائج:**
```
الأصل git@github.com:raisedadead/freeCodeCamp.git (fetch)
الأصل git@github.com:raisedadead/freeCodeCamp.git (push)
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (fetch)
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (push)
```
2. تأكد من أن فرع `الرئيسي` الخاص بك نقي وفي تزامن مع البث.
```sh
git قم بالدفع الرئيسي
git يجلب --كل --prune
git reset --hard upstream/master
```
3. تحقق من أن ترافيس سي يقوم بتمرير فرع `الرئيسي` للتبسيط.
يجب أن تكون اختبارات [الدمج المستمر](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) خضراء و باسينغ `لفرع`.
<details> <summary> التحقق من الحالة على Travis CI (لقطة الشاشة) </summary>
<br>
![تحقق من حالة البناء على Travis CI](https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/master/docs/images/devops/travis-build.png)
</details>
إذا فشل هذا يجب عليك التوقف والتحقيق في الأخطاء.
4. تأكد من أنك قادر على بناء المستودع محلياً.
```
npm تشغيل نظيف وتطوير
```
5. نقل التغييرات من `الرئيسي` إلى `تجهيز الإنتاج` عبر دمج سريع للأمام
```
git الدفع بالإنتاج - مرحلة التجهيز
git master دمج
git push upstream
```
> [!ملاحظة] لن تكون قادراً على فرض الدفع وإذا قمت بإعادة كتابة السجل على أي حال فإن هذه الأوامر ستخطأ.
>
> إذا فعلوا ذلك، ربما تكون قد فعلت شيئا خاطئا وينبغي أن تبدأ من جديد.
الخطوات المذكورة أعلاه ستفعل تلقائياً تشغيل على خط أنابيب البناء لفرع `الإنتاج الحالي`. بمجرد أن تصبح أداة البناء جاهزة، فإنها ستؤدي إلى تشغيل على خط أنابيب الإطلاق.
يتم تشغيل خط أنابيب الإطلاق تلقائياً عند توفر أداة جديدة من خط أنابيب البناء المتصل. بالنسبة لمنصات التجهيز، هذه العملية لا تنطوي على موافقة يدوية ويتم دفع التحف إلى خوادم العميل CDN و API.
> [!تلميح: تقديرات] عادة ما يستغرق تشغيل البناء 20-25 دقيقة لإكمال عملية الإصدار التي تستغرق 15-20 دقيقة للعميل، و ~5-10 دقائق لـ API لتكون متاحة على قيد الحياة. من دفع التعليمات البرمجية إلى الحياة على منصات التجهيز تستغرق العملية بأكملها **~35-45 دقيقة** في المجموع.
### دفع التغييرات إلى تطبيقات الإنتاج.
وهذه العملية هي في معظمها نفس منصات التجهيز، مع إجراء عدد قليل من عمليات التحقق الإضافية. هذا فقط لتأكيد، نحن لا نكسر أي شيء على FreCodeCamp.org الذي يمكنه رؤية مئات المستخدمين يستخدمونه في أي لحظة.
| لا تقم بتنفيذ هذه الأوامر إلا إذا تحققت من أن كل شيء يعمل على منصة التجهيز. لا يجب عليك تجاوز أو تخطي أي اختبار عند التجهيز قبل المضي قدماً. |
|:-------------------------------------------------------------------------------------------------------------------------------------------- |
| |
1. تأكد من أن فرع `تجهيز الإنتاج` الخاص بك هو فرع نقدي ومتزامن مع الجزء العلوي.
```sh
git الخروج من الإنتاج وتجهيز
git جلب --كل --prune
git إعادة تعيين --upstream/production-packging
```
2. نقل التغييرات من `الإنتاج التجهيز` إلى `الإنتاج الحالي` عبر دمج سريع للأمام
```
git دفع الانتاج-الحالي
git دمج الانتاج - التجهيز
git push upstream
```
> [!ملاحظة] لن تكون قادراً على فرض الدفع وإذا قمت بإعادة كتابة السجل على أي حال فإن هذه الأوامر ستخطأ.
>
> إذا فعلوا ذلك، ربما تكون قد فعلت شيئا خاطئا وينبغي أن تبدأ من جديد.
الخطوات المذكورة أعلاه ستفعل تلقائياً تشغيل على خط أنابيب البناء لفرع `انتاج - تجهيز` بمجرد اكتمال البناء، يتم حفظ التحف كملفات `.zip` في وحدة تخزين باردة لاسترجاعها واستخدامها لاحقاً. بمجرد أن تصبح أداة البناء جاهزة، فإنها ستؤدي إلى تشغيل على خط أنابيب الإطلاق.
> [!تلميح: تقديرات] عادة ما يستغرق تشغيل البناء 20-25 دقيقة لإكماله.
**خطوات إضافية لعمل الموظفين**
يتم تشغيل إحدى عمليات الإصدار، سيتلقى أعضاء فريق الموظفين المطورين رسالة إلكترونية يدوية للتدخل. يمكنهم إما _الموافقة على_ أو _رفض_ تشغيل الإصدار.
إذا كانت التغييرات تعمل بشكل جيد وتم اختبارها على منصة التجهيز، فيمكن الموافقة عليها. ويجب منح الموافقة في غضون 4 ساعات من تاريخ إطلاق الإصدار قبل أن يتم رفضها تلقائياً. ويمكن للموظفين أن يعيدوا تحريك عملية الإفراج يدويا لطلبات الترحيل المرفوضة، أو أن ينتظروا الدورة التالية من عملية الترحيل.
لاستعمال الموظفين:
| تحقق من بريدك الإلكتروني للحصول على رابط مباشر أو [انتقل إلى لوحة تحكم الإصدار](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) بعد اكتمال تشغيل البناء. |
|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
وبمجرد موافقة أحد الموظفين على الإصدار، فإن خط الأنابيب سيدفع التغييرات مباشرة إلى خوادم CDN و API الخاصة بإنتاج freeCodeCamp.org. عادة ما يستغرق ~15-20 دقيقة للعملاء، و ~5 دقائق لخوادم API لتكون متاحة على قيد الحياة.
> [!تلميح: تقديرات] عملية الإصدار تستغرق عادة 15-20 دقيقة لكل نموذج من نماذج العميل، و ~5-10 دقائق لكل نموذج API لتكون متاحة للحياة. من دفع التعليمات البرمجية إلى أن تكون حية على منصات الإنتاج تستغرق العملية بأكملها **~90-120 دقيقة** في المجموع (بدون حساب وقت الانتظار للحصول على موافقة الموظفين).
## بناء واختبار ونشر حالة
وفيما يلي الاختبار الحالي وحالة البناء والنشر لهذا الدماغ.
| نوع | فرع | الحالة | لوحة التحكم |
|:--------------- |:---------------------------------------------------------------------------------------- |:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |:------------------------------------------------------------------------------------------------ |
| اختبار CI | [`سيد`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master) | ![حالة بناء CI](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=master) | [الذهاب إلى لوحة التحكم الحالة](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| اختبار CI | [`انتاج التجهيز`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | ![حالة بناء CI](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=production-staging) | [الذهاب إلى لوحة التحكم الحالة](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| بناء خط أنابيب | [`انتاج التجهيز`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | [![حالة البناء](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_apis/build/status/dot-dev-ci?branchName=production-staging)](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build/latest?definitionId=15&branchName=production-staging) | [الذهاب إلى لوحة التحكم الحالة](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build) |
| إصدار خط أنابيب | [`انتاج التجهيز`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | | [الذهاب إلى لوحة التحكم الحالة](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) |
| اختبار CI | [`الانتاج-الحالي`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-current) | ![حالة بناء CI](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=production-current) | [الذهاب إلى لوحة التحكم الحالة](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| بناء خط أنابيب | [`الانتاج-الحالي`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | [![حالة البناء](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_apis/build/status/dot-org-ci?branchName=production-current)](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build/latest?definitionId=17&branchName=production-current) | [الذهاب إلى لوحة التحكم الحالة](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build) |
| إصدار خط أنابيب | [`الانتاج-الحالي`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | | [الذهاب إلى لوحة التحكم الحالة](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) |
## الوصول المبكر واختبار بيتا
نحن نرحب بك لاختبار هذه الإصدارات في وضع **"اختبار تجريبي عام"** والحصول على الوصول المبكر إلى الميزات القادمة إلى المنصات. أحياناً يشار إلى هذه الميزات/التغييرات باسم **التالي، بيتا، الإنتخاب،** إلخ.
إسهاماتك عن طريق الإفادة المرتدة وتقارير الإصدار سوف تساعدنا في إنشاء منصات الإنتاج في `freeCodeCamp. rg` أكثر **مرونة**و **ثابت** و **مستقر** للجميع.
نشكرك على الإبلاغ عن الأخطاء التي تواجهك ومساعدتك في جعل CodeCamp.org أفضل. أنت صخر!
### تحديد النسخة القادمة من المنصات
يتوفر حاليا إصدار اختبار تجريبي عام في:
<h1 align="center"><a href='https://www.freecodecamp.dev' _target='blank'>freecodecamp.dev</a></h1>
> NoTE] اسم النطاق مختلف عن **`freeCodeCamp.org`**. وهذا متعمد لمنع فهرسة محرك البحث وتجنب اللبس للمستخدمين المنتظمين للمنصة.
### تحديد النسخة الحالية من المنصات
**النسخة الحالية من المنصة متوفرة دائما في [`freeCodeCamp.org`](https://www.freecodecamp.org).**
يدمج فريق إدارة الإنتاج التغييرات من فرع `التجهيز الإنتاجي` إلى `التيار الإنتاجي` عند تحرير التغييرات. يجب أن يكون الالتزام الأعلى ما ترونه مباشرة على الموقع.
يمكنك تحديد النسخة الدقيقة المنشورة عن طريق زيارة سجلات البناء والنشر المتاحة في قسم الحالة. بدلاً من ذلك، يمكنك أيضاً ربطنا في [غرفة الدردشة المساهمين](https://gitter.im/FreeCodeCamp/Contributors) لتأكيدها.
### القيود المعروفة
هناك بعض القيود المعروفة والمقايضات عند استخدام الإصدار التجريبي من المنصة.
- #### جميع البيانات / التقدم الشخصي على هذه المنصات التجريبية `لن يتم حفظها أو نقلها` إلى الإنتاج.
**المستخدمين على إصدار بيتا سيكون لديهم حساب منفصل عن الإنتاج.** النسخة التجريبية تستخدم قاعدة بيانات منفصلة ماديا عن الإنتاج. وهذا يعطينا القدرة على منع أي خسارة عرضية للبيانات أو التعديلات. قد يقوم فريق ديف بتطهير قاعدة البيانات على نسخة بيتا هذه حسب الحاجة.
- #### لا توجد ضمانات بشأن الوقت الإضافي للمنصات التجريبية وموثوقيتها.
ومن المتوقع أن يكون الانتشار متكررا ومتكررا بسرعة، وأحيانا عدة مرات في اليوم. ونتيجة لذلك، سيكون هناك توقف غير متوقع في بعض الأحيان أو وظائف معطلة على النسخة التجريبية.
- #### لا ترسل المستخدمين المنتظمين إلى هذا الموقع كتدبير لتأكيد إصلاح
وموقع بيتا كان ولا يزال دائما يتمثل في زيادة التنمية والاختبار المحليين، لا شيء آخر. إنه ليس بوعد بما هو قادم، ولكن لمحة عما يجري العمل عليه.
- #### قد تبدو صفحة تسجيل الدخول مختلفة عن الإنتاج
نحن نستخدم مستأجر اختبار لـ freecodecamp.dev على Auth0، وبالتالي ليس لدينا القدرة على تعيين نطاق مخصص. هذا يجعل من الممكن أن تظهر جميع إعادة توجيه المكالمات وصفحة تسجيل الدخول في نطاق افتراضي مثل: `https://freecodecamp-dev.auth0.com/`. وهذا لا يؤثر على هذه الوظيفة التي تقترب من الإنتاج بقدر ما يمكننا الحصول عليه.
## المسائل المتعلقة بالإبلاغ وترك التعليقات
الرجاء فتح مشكلات جديدة للمناقشات والإبلاغ عن الأخطاء. يمكنك تسميتهم كـ **[`الإصدار: التالي/التجريبي`](https://github.com/freeCodeCamp/freeCodeCamp/labels/release%3A%20next%2Fbeta)** للتجربة.
يمكنك إرسال بريد إلكتروني إلى `dev[at]freecodecamp.org` إذا كان لديك أي استفسار. كما هو الحال دائمًا يجب إبلاغ جميع نقاط الضعف الأمنية إلى `الأمن[at]freecodecamp.org` بدلاً من تعقب الجمهور والمنتدى العام.

327
docs/i18n/Arabic/flight-manuals/moderator-handbook.md Normal file
View File

@ -0,0 +1,327 @@
# دليل مشرف FreCodeCamp الرسمي.
هذا سيساعدك على ضبط أماكن مختلفة في مجتمعنا، بما في ذلك:
- مشاكل GitHub & طلبات السحب
- المنتدى وغرف الدردشة ومجموعات الفيسبوك وغيرها من أماكن الاجتماعات على الإنترنت
- المناسبات الشخصية مثل المجموعات الدراسية، والهاكاثون, والمؤتمرات
**جميع مشرفي FreCodeCamp هم مشرفون على نطاق المجتمع. وهذا يعني أننا نثق بأنكم ستشرفون على أي من هذه الأماكن.**
هذا، يمكنك أن تعمل كمشرف في أي مكان من الأماكن التي تهمك. بعض المشرفين يساعدون فقط على GitHub. ويساعد آخرون فقط في المنتدى. بعض المشرفين ناشطون في كل مكان.
وخلاصة القول أننا نريدك أن تستمتع بأن تكون مشرفا، واستثمر وقتك الشحيح في الأماكن التي تهمك.
> [!ملحوظة] "مع القوة العظيمة تأتي مسؤولية عظيمة." - العم بن
وبوصف درجة الحرارة مشرفة، فإن درجة الحرارة أهم من المهارة التقنية.
اسمع. كن مساعداً. لا تسيء استخدام قوتك.
FreCodeCamp هو مجتمع شامل، ونحن بحاجة إلى الحفاظ عليه بهذه الطريقة.
ولدينا مدونة سلوك واحدة تحكم مجتمعنا بأسره. وكلما قلّت القواعد سهولة تذكرها. يمكنك قراءة هذه القواعد وإلزامها بالذاكرة [هنا](https://code-of-conduct.freecodecamp.org).
# Moderating GitHub
المشرفين لديهم القدرة على إغلاق المشكلات وقبول طلبات السحب أو إغلاقها.
ويضطلع المشرفون بمسؤوليتين رئيسيتين فيما يتعلق بـ GitHub:
1. QA'ing و دمج طلبات السحب
2. تقييم المسائل والاستجابة لها
## اعداد طلبات السحب
طلبات السحب هي كيف يقوم المساهمون بإرسال تغييرات إلى مستودع رمز مجاني. من المهم أن ننفذ ضمان الجودة (QA) عند طلبات السحب قبل أن نقرر ما إذا كنا سندمجها أو نغلقها.
### أنواع طلبات السحب
1. **تعديلات تعليمات التحدي** هذه تغييرات على نص التحديات - الوصف أو التعليمات أو نص الاختبار. يمكنك أيضًا مراجعة هذه الحقوق على GitHub والبت فيما إذا كان سيتم دمجها. نحن بحاجة إلى أن نكون أكثر حذرا بشأن هذه المسائل، لأن ملايين الناس سيواجهون هذا النص وهم يعملون من خلال منهج FreCodeCamp الدراسي. هل طلب السحب يجعل النص أكثر وضوحا دون جعله أطول بكثير؟ هل التعديلات ذات صلة وليست مفرطة في الدردشة؟ تذكر أن هدفنا هو أن تكون التحديات واضحة وقصيرة قدر الإمكان. إنهم ليسوا المكان للحصول على تفاصيل غامضة. وقد يحاول المساهمون أيضا إضافة روابط إلى الموارد إلى التحديات. يمكنك إغلاق طلبات السحب هذه والرد عليها بهذا:
> شكرا لك على طلب السحب الخاص بك.
>
> وأغلق طلب السحب هذا. الرجاء إضافة روابط وتفاصيل أخرى لمقالة الدليل المقابلة للطعن بدلاً من ذلك.
>
> إذا كنت تعتقد أنني مخطئ في إغلاق هذه المشكلة، يرجى إعادة فتحها وإضافة المزيد من الإيضاحات. شكرا لك و البرمجة السعيدة.
2. **تعديل كود التحدي** هذه تغييرات على التعليمات البرمجية في تحد - بذور التحدي، حل التحدي، سلاسل الاختبار. يجب سحب طلبات السحب هذه من GitHub واختبارها على جهاز الكمبيوتر المحلي الخاص بك للتأكد من أنه لا يزال من الممكن اجتياز اختبارات التحدي مع الحل الحالي، والشفرة الجديدة لا تقدم أي أخطاء. وقد يحاول بعض المساهمين إضافة اختبارات إضافية لتغطية حالات الزاوية الأطلسية. ونحن بحاجة إلى توخي الحذر لكي لا نجعل التحدي أكثر تعقيدا. وينبغي أن تكون هذه التحديات واختباراتها بسيطة وبديهية قدر الإمكان. بغض النظر عن تحديات الخوارزمية وقسم إعداد المقابلات، يجب أن يكون المتعلمون قادرين على حل كل تحد في غضون دقيقتين تقريبا.
3. **تغييرات Codebase** هذه التعليمات البرمجية تغير وظيفة منصة FreCodeCamp نفسها. في بعض الأحيان يحاول المساهمون إجراء تغييرات بدون الكثير من التفسير، ولكن بالنسبة للتغييرات البرمجية نحتاج إلى التأكد من وجود حاجة حقيقية للتغيير. لذا يجب أن تشير طلبات السحب هذه إلى مشكلة GitHub الحالية حيث تناقش أسباب التغيير. ثم يمكنك فتح طلب السحب على جهاز الكمبيوتر الخاص بك واختباره محلياً. بعد أن فعلت ذلك، إذا كانت التغييرات تبدو جيدة، لا تدمجها بعد. يمكنك التعليق على طلب السحب الذي يقول "LGTM"، ثم ذكر @raisedadead حتى يتمكن من إلقاء نظرة نهائية.
### كيفية دمج أو إغلاق طلبات السحب
بادئ ذي بدء، عندما تختار طلب سحب إلى الجودة، يجب عليك تعيين نفسك لها. يمكنك القيام بذلك بالنقر على رابط "تعيين نفسك" أسفل الجزء "المحال إليه" في العمود الأيمن من واجهة GitHub.
وتبعا لنوع طلب السحب، يتبع القواعد المقابلة المذكورة أعلاه.
قبل دمج أي طلب سحب، تأكد من أن GitHub لديه علامات فحص خضراء لكل شيء. إذا كان هناك أي X'، فحصها أولاً واكتشف كيفية تحويلها إلى علامات فحص خضراء أولاً.
في بعض الأحيان سيكون هناك صراع للدمج. وهذا يعني أن طلب سحب آخر قد أدخل تغييرا على نفس الجزء من نفس الملف بالضبط. GitHub لديه أداة لمعالجة تناقضات الدمج هذه مباشرة على GitHub. يمكنك محاولة معالجة هذه الصراعات. فقط استخدم أفضل حكمك. التغييرات في طلب السحب ستكون في الأعلى، وستصبح التغييرات في الفرع الرئيسي في الأسفل. في بعض الأحيان ستكون هناك معلومات زائدة عن الحاجة يمكن حذفها. قبل أن تنتهي، تأكد من حذف `<<<<<<`، `=====`، و `>>>>>>` الذي يضيفه Git للإشارة إلى مناطق الصراع.
إذا بدا طلب السحب جاهزا للدمج (ولا يتطلب الموافقة من @raisedadead)، يمكنك المضي قدما ودمجه. تأكد من استخدام وظيفة "سكواش ودمج" الافتراضية على GitHub. هذا سوف يهدم جميع طلبات السحب التي تلتزم في التزام واحد، مما يجعل تاريخ Git أسهل بكثير للقراءة.
يجب عليك التعليق على طلب السحب، وشكر المساهم بطريقتك الشخصية.
إذا كان مؤلف طلب السحب "أول مساهم" فيجب عليك أيضاً تهنئتهم على أول طلب سحب مدمج إلى المستودع. يمكنك النظر إلى الزاوية اليمنى العليا في هيئة PR's لتحديد المساهم لأول مرة. سوف تظهر `مساهم لأول مرة` كما هو موضح أدناه:
![copy_edits_for_Java_arrays_article_by_karentobo_%C2%B7_Pull_request__20615_%C%B7_freeCodeCamp_freeCodeCamp<unk> 690x281](https://i.imgur.com/dTQMjGM.png)
إذا كان طلب السحب لا يبدو جاهزاً للدمج، يمكنك الرد بأدب على إخبار مقدم البلاغ بما ينبغي أن يفعله للحصول على الجهاز. ويؤمل أن يجيبوا وأن يجعلوا طلب السحب أقرب إلى الجاهزة.
ومن الواضح أن أي طلب للسحب سيكون في كثير من الأحيان منخفضا للجهد. يمكنك في كثير من الأحيان إخبار هذا على الفور عندما لم يقم المساهم بالتحقق من خانات الاختيار في قالب طلب السحب، أو استخدم عنوان طلب سحب عام مثل "إجراء تغييرات" أو "تحديث فهرس. د".
وهناك أيضا حالات يحاول فيها المساهم إضافة رابط إلى موقع الويب الخاص به، أو تضمين مكتبة أنشأوها بأنفسهم، أو لديها تحرير تافهة لا يساعد أي شخص إلا بأنفسهم.
وفي كلتا الحالتين، ينبغي أن تمضي قدما وأن تغلق طلب السحب والرد بهذه الرسالة القياسية:
> شكرا لك على فتح طلب السحب هذا.
>
> هذه رسالة قياسية تخبرك أننا راجعنا طلب السحب الخاص بك وقررنا عدم دمجه. ونحن نرحب بطلبات السحب في المستقبل منكم.
>
> شكرا لك و البرمجة السعيدة.
إذا كنت بحاجة إلى رأي ثان بشأن طلب الجذب، فأمضي قدماً وتترك تعليقاتك على طلب الجذب، ثم أضف تسمية "مناقشة" إلى طلب السحب.
## إدارة مشكلات GitHub
FreCodeCamp مشروع نشط مفتوح المصدر. إننا نحصل على قضايا جديدة كل يوم، وكلها تحتاج إلى تجربتها ووضع علامات عليها.
### أنواع مشاكل GitHub
1. **طلبات مساعدة التعليمات البرمجية**، والتي قام الناس بالخطأ بإنشاء مشاكل GitHub لها. إذا كان شخص ما يطلب المساعدة، قم بلصق الرسالة التالية، ثم أغلق المشكلة.
> شكرا لك على الإبلاغ عن هذه المشكلة.
>
> هذه رسالة قياسية تخبرك أن هذه المشكلة تبدو وكأنها طلب للمساعدة. بدلاً من طلب المساعدة هنا، يرجى النقر على زر \*\*"مساعدة"\*\* على التحدي في معسكر البرمجيات الحرة، والذي سيساعدك على إنشاء سؤال في الجزء الصحيح من المنتدى. عادة ما يقوم المتطوعون في المنتدى بالرد على الأسئلة في غضون ساعات قليلة ويمكنهم المساعدة في تحديد ما إذا كانت هناك مشكلة في التعليمات البرمجية الخاصة بك أو اختبارات التحدي.
>
> إذا قرر أعضاء المنتدى أنه لا يوجد خطأ في التعليمات البرمجية، يمكنك طلب إعادة فتح هذه المشكلة.
>
> شكرا لك و البرمجة السعيدة.
2. **مشكلات الخطأ أو التوضيح** حاول تكرار الخطأ بنفسك إذا استطعت. إذا لم يكن الأمر كذلك، اسألهم عن الخطوات التي تمكنهم من إعادة إنتاج الخطأ، وما إذا كان لديهم أي لقطات شاشة، مقاطع الفيديو، أو التفاصيل الإضافية التي يمكن أن تساعدك على إعادة نشر المشكلة. بمجرد أن تتمكن من تكرار المشكلة - أو على الأقل تأكيدها مشكلة قانونية - قم بتسميتها `مؤكدة`. ثم:
- إذا كان الأمر بسيطاً إلى تحدي قائم، قم بتسمية `الموقت الأول فقط`، وإلا تم تسميته ب `المساعدة المطلوبة`. استخدام تسميات أخرى حسب الاقتضاء.
- إذا كانت المشكلة أكثر أهمية، علم كخطأ ``. &nbsp; إذا كان هناك أي غموض فيما يتعلق بالمسار الصحيح للعمل بشأن مسألة ما. لا تتردد في وسم @raisedadead حول المسألة والحصول على رأيه بشأنها، ثم أضف `تسمية المناقشة`
3. **تكرار المشكلات** إذا كانت المشكلة هي نفس مشكلة أخرى تم الإبلاغ عنها، يجب أن تكون الأولوية للمشكلة السابقة المبلغ عنها. علم باسم `تكرار`، قم بلصق الرسالة التالية استبدال `#XXX` برقم المشكلة، ثم أغلق المشكلة.
> شكرا لك على الإبلاغ عن هذه المشكلة.
>
> هذه رسالة قياسية تنبيهك أن هذه المشكلة تبدو مشابهة جدا للمشكلة #XXXXX, ولذلك فإنني أختتم هذه المناقشة بوصفها تكرارا لها.
>
> إذا كنت تعتقد أنني مخطئ في إغلاق هذه المشكلة، يرجى إعادة فتحها وإضافة المزيد من الإيضاحات. شكرا لك و البرمجة السعيدة.
4. **أصلحت في التجهيز** بعض المشاكل ربما تم إصلاحها بالفعل في التجهيز، ولكن ليس لديها مشكلة في GitHub مرتبطة بها. إذا كان هذا هو الحال، يمكنك لصق الرسالة التالية، وإغلاق المشكلة، وإضافة `حالة: تم حله/شحن` التسمية:
> شكرا لك على الإبلاغ عن هذه المشكلة.
>
> هذه رسالة قياسية تخبرك أن المشكلة التي ذكرتها هنا موجودة في الإنتاج، ولكن تم بالفعل إصلاحها في مرحلة التدرج. وهذا يعني أنه في المرة القادمة التي ندفع فيها فرع التجهيز إلى الإنتاج، ينبغي حل هذه المشكلة. بسبب هذا، أنا أغلق هذه المشكلة.
>
> إذا كنت تعتقد أنني مخطئ في إغلاق هذه المشكلة، يرجى إعادة فتحها وإضافة المزيد من الإيضاحات. شكرا لك، و البرمجة السعيدة.
### إغلاق الجمود، المشكلات غير النشطة و طلبات السحب
- القضايا العادية أو حقوق الملكية الخاصة هي القضايا التي لم تشهد أي نشاط من البروتوكول الاختياري لمدة 21 يوماً (3 أسابيع من آخر النشاط)، ولكن فقط بعد أن يطلب المشرف المزيد من المعلومات/التغييرات. يمكن إغلاق هذه البرامج في نص تلقائي/روت أو بواسطة المشرفين أنفسهم.
- النشاط معرَّف كما يلي: التعليقات التي تطلب تحديثاً على PR والمحاولات مثل `حالة: التحديث المطلوب` التسمية الخ.
- وإذا طلب البرنامج مساعدة إضافية أو حتى وقت، يمكن تخفيف ما سبق ذكره وإعادة النظر فيه بعد تقديم الرد. وعلى أية حال، ينبغي أن تستعمل النماذج أفضل ما لديها من حكم لتسوية الوضع المعلق للحزب التقدمي الموحد.
### مبادئ توجيهية أخرى لمشرفي نظام GitHub
على الرغم من أنه سيكون لديك الوصول للكتابة إلى مستودع FreCodeCamp، **يجب ألا تدفع التعليمات البرمجية مباشرة إلى مستودعات freeCodeCamp**. جميع التعليمات البرمجية يجب أن تدخل رمز معسكر FreCodep في شكل طلب سحب من شوكة المستودع.
وأيضا، يجب ألا تقبل أبداً براءات الاختراع الخاصة بك. يجب أن يكونوا QAd من قبل مشرف آخر، تماما مثل أي رئيس سابق آخر.
إذا لاحظت أن أي شخص يخالف مدونة السلوك [](https://code-of-conduct.freecodecamp.org) على مشكلات GitHub ، أو فتح طلبات سحب مع محتوى أو كود خبيث، البريد الإلكتروني dev@freecodecamp. rg مع رابط لطلب السحب المذهل ويمكننا النظر في حظرهم من منظمة FreCodeCamp GitHub بشكل كامل.
# إدارة المنتدى
كمشرف ، يمكنك المساعدة في إبقاء مجتمعنا مكانا ممتعا لأي شخص للتعلم والحصول على المساعدة. سوف تتعامل مع المشاركات المعلمة والتعامل مع الرسائل غير المرغوب فيها، خارج الموضوع، وغيرها من المحادثات غير الملائمة.
لاحظ أنه بمجرد أن تكون مشرفا على المنتدى، ستبدأ في مشاهدة تلميحات المشرف الأزرق حول أعضاء المنتدى، مثل "هذه هي المرة الأولى التي ينشر فيها [person] - دعونا نرحب بهم في المجتمع! أو "[person] لم تنشر في وقت طويل - دعونا نرحب بها مرة أخرى."
![رسالة نصية زرقاء تقول "هذه هي المرة الأولى التي تنشر فيها [person] - دعونا نرحب بهم في المجتمع!](https://i.imgur.com/mPmVgzK.png)
هذه فرص لك للترحيب بهم وجعلهم يشعرون بميزة إضافية. أنت لا تعرف أبدا أي شخص يشارك بشكل هامشي قد يصبح المساعد الأعلى التالي لنا، ويساعد العديد من الناس الآخرين في رحلتهم البرمجية. وحتى أصغر لطف قد يؤدي إلى سلسلة من الأفعال الجيدة.
### حذف مشاركات المنتدى
مشرفو المنتدى لديهم القدرة على حذف مشاركات المستخدم. يجب عليك القيام بذلك فقط في الحالات التالية:
1. وقد نشر شخص ما صورة إباحية أو صورية عنيفة.
2. قام شخص ما بنشر رابط أو كود ضارة في طبيعته، ويمكن أن يضر بكاميرات أخرى تنقر عليها.
3. شخص ما غمر خيطا مع الكثير من رسائل البريد المزعج.
### التعامل مع البريد المزعج
في أول مشاركة غير مرغوب فيها للمستخدم، أرسل لهم رسالة تشرح المشكلة، وإزالة الرابط أو المنشور حسب الاقتضاء. اترك ملاحظة على الملف الشخصي للمستخدم تشرح الإجراء الذي اتخذته. وإذا استمرت المشكلة، تتبع العملية أعلاه. منع المستخدم بهدوء من النشر (باستخدام خيار الصمت على لوحة إدارة المستخدم)، ثم إرسال تحذير مع رمز السلوك. حدد المربع في الرسالة الخاصة التي تشير إلى أن رسالتك هي "تحذير رسمي".
يمكنك طرح الأسئلة والإبلاغ عن الحوادث في [قسم منتدى الموظفين](https://forum.freecodecamp.com/c/staff).
### التعامل مع المحادثات خارج الموضوع
ويمكن إعادة تصنيف الوظائف أو المواضيع التي يبدو أنها في المكان الخاطئ أو إعادة تسميتها إلى ما هو مناسب.
وفي ظروف استثنائية، قد يكون من المناسب أن يطرح منسق المناقشة في خيوط متعددة.
مرة أخرى، إذا كان لديك أي مشاكل أو أسئلة، قم بتأدية وظيفة في إطار إجراءاتك في فئة الموظفين، ووسم مشرف آخر إذا كنت تريد منهم مراجعة إجراءاتك المعتدلة.
### المستخدمين القاصرين
شروط الخدمة لدينا تتطلب أن يكون عمر مستخدمي CodeCamp 13 سنة على الأقل. وفي حالة ما إذا كشف المستخدم عن أنه يقل عمره عن 13 سنة، أرسل لهم الرسالة التالية وحذف حساب المنتدى الخاص بهم (إذا كان الحذف غير متوفر، تعليق الحساب). ثم البريد الإلكتروني [Quincy](https://forum.freecodecamp.org/u/QuincyLarson) (quincy@freecodecamp.org) أو [Mrugesh](https://forum.freecodecamp.org/u/raisedadead) (mrugesh@freecodecamp.org) لحذف حساب المستخدم freeCodeCamp أيضا.
```markdown
الثانوية: لا يسمح للمستخدمين الذين تقل أعمارهم عن 13 سنة باستخدام المنتدى لكل شروط الخدمة
لقد تبين لنا أن عمرك أقل من 13 سنة. لكل [Free CodeCamp شروط الخدمة] (https://www.freecodecamp.org/news/terms-of-service) يجب أن يكون عمرك 13 سنة على الأقل لاستخدام الموقع أو المنتدى. سنقوم بحذف حساب FreCodeCamp الخاص بك وحساب المنتدى الخاص بك. وهذا التقييد يجعلنا ممتثلين لقوانين الولايات المتحدة.
يرجى الانضمام مرة أخرى بمجرد بلوغك سن 13 سنة على الأقل.
نشكركم على تفهمكم.
```
# إدارة الفيسبوك
إذا رأيت أي شيء يبدو وكأنه يخالف مدونة قواعد السلوك الخاصة بنا [](https://code-of-conduct.freecodecamp.org/)، يجب عليك حذفها فورا.
في بعض الأحيان يقوم الناس بنشر الأشياء التي يعتقدون أنها مضحكة. إنهم لا يدركون أن ما قالوا أو ما تقاسموه يمكن تفسيره على أنه هجوم. وفي هذه الحالات، ينبغي حذف وظيفتهم، ولكن لا يلزم بالضرورة حظر الشخص الذي قام بنشرها. ومن خلال حذف مشاركتهم، نأمل أن يفهموا أن ما نشروه كان غير مناسب.
ولكن إذا كانت جريمة فظيعة لا يمكن عزوها بشكل معقول إلى اختلاف ثقافي أو سوء فهم للغة الإنجليزية. ثم يجب عليك أن تفكر بقوة في حظر العضو من مجموعة فيسبوك.
# ديسكورد مشرف
إليك كيف يتعامل المشرفون مع انتهاكات [مدونة قواعد السلوك](https://code-of-conduct.freecodecamp.org/) على ديسكورد:
1. **تأكد من أن القصد منه هو انتهاك مدونة قواعد السلوك.** لم تكن جميع انتهاكات مدونة قواعد السلوك مقصودة بهذه الصفة. كاميرا جديدة قد تنشر كمية كبيرة من التعليمات البرمجية للمساعدة، غير مدركة أن هذا يمكن اعتباره غير مرغوب فيه. في هذه الحالات، يمكنك فقط أن تطلب منهم لصق تعليماتهم البرمجية مع خدمات مثل Codepen أو Pastebin.
2. **وفي حالة انتهاك كاميرا مدونة قواعد السلوك بشكل واضح، يتصرف منسق المناقشة على النحو التالي:**
- تعليق الكاميرا المسيئة، ولكن لا تحذر منها أو تهددها. بدلاً من ذلك، أعطيتهم بهدوء الدور المعلق في ديسكورد، ثم أرسل إليهم الرسالة التالية:
```
هذه رسالة قياسية تخبرك بأنني اضطررت إلى تعليقك مؤقتاً من التحدث على خادم FreCodeCamp Discord
وأنا مديرة المناقشة بالنيابة عن جماعتنا المفتوحة المصدر.
وأنا مديرة المناقشة بالنيابة عن جماعتنا المفتوحة المصدر. يمكنني النظر في إزالة تعليقك، لكنني أريدك أن تتخذوا الخطوات الثلاث التالية أولاً:
1. اقرأ كود السلوك الخاص بنا: https://code-of-conduct.freecodecamp.org/
2. رسالة إليّ تؤكد أنك قد أنهيت قراءتها. 3. اشرح لي لماذا تعتقدون أنني علقتك، ولماذا يجب أن أزيل تعليقك.
```
- أبلغ عن ملخص قصير للحدث وكيفية استجابتهم له في قناة #admin . وفيما يلي مثال على ما قد يبدو عليه مثل هذا الموجز:
```
معلقة: _@username_
السبب: _Spamming, trolling_
دليل: _واحدة أو أكثر من الروابط إلى الرسالة (الرسائل) المسيئة_
CoC: _Sent_
```
- وينبغي أن يكون التقرير المتعلق بحذف التعليق على النحو التالي:
```
لقد قمت بإزالة التعليق من '@username `. لقد أرسلت إليهم مدونة قواعد السلوك. واليوم فقط أدركوا أنهم علقوا و اعتذروا عما فعلوه.
```
- واستنادا إلى رد المجرمين، سيقرر مدير المناقشة ما إذا كان سيسحب التعليق من كاميل المخالف. إذا كانت تبدو محترمة ومذهلة، يمكن للمشرف أن يزيل التعليق. وكمسألة تتعلق بالسياسات، سيكون المشرفون مهذبين خلال هذه العملية، مهما كان سوء تصرف الكاميرا المسيئة. إذا لم يكونوا محترمين أو غير راغبين في قبول مدونة قواعد السلوك، يجب أن يتبع التعليق بحظر من خادم ديسكورد. استخدم نفس الموجز كما ورد أعلاه، ولكن استعيض عن "معلقة:" ب "محظورة:".
3. **كيفية حظر و/أو فك الحظر**
- من أجل حظر شخص ما، انقر بزر الماوس الأيمن على اسم المستخدم/الصورة الشخصية الخاصة بهم وحدد "حظر <username>". سيتم منحك الخيار لحذف رسائلها السابقة - حدد "لا تقم بحذف أي من"، لأن الرسائل ينبغي أن تظل حاضرة بوصفها سجلا تاريخيا.
- إذا قررت حظر شخص ما، فهذا يعني أنهم غير مستعدين للالتزام بمدونة قواعد السلوك الخاصة بنا. ولذلك، نادرا ما ينبغي أن يحدث رفع الحظر عن كامير. ومع ذلك، إذا نشأت الحاجة، يمكنك فعل ذلك بالنقر على اسم الخادم، واختيار "إعدادات الخادم"، اختيار "الحظر"، اختيار المستخدم الذي ترغب في فك حظره، والنقر فوق "إلغاء الحظر".
حظر ديسكورد عام - لا يمكنك حظر مستخدم من قناة معينة، فقط من الخادم بأكمله.
4. **حذف الرسائل** للمشرفين القدرة على حذف الرسائل على ديسكورد. ولا ينبغي أن يمارسوا هذه القدرة إلا في أربع حالات محددة جداً:
- وقد نشر شخص ما صورة إباحية أو صورية عنيفة.
- قام شخص ما بنشر رابط أو كود ضارة في طبيعته، ويمكن أن يضر بكاميرات أخرى تنقر عليها.
- وقد غمر شخص ما الدردشة بالكثير من الرسائل غير المرغوب فيها إلى حد كبير (عادة ما تشمل البوتات) بحيث تجعل الدردشة غير قابلة للاستخدام على الإطلاق.
- قام شخص ما بنشر إعلان و/أو رسالة / صورة للترويج الذاتي (وسائل الإعلام الاجتماعية).
وفي جميع الحالات الأخرى - وحتى الحالات التي تنتهك فيها مدونة قواعد السلوك - ينبغي ألا يحذف المنسقون الرسالة لأنها سجل تاريخي هام. عندما تقوم بحذف رسالة، تأكد من أخذ لقطة للشاشة أولاً! يمكن تسجيل لقطة الشاشة في قناة #mod-log، ولكن بالنسبة لسجل #activs-log يكفي القول بأن الأدلة قد "حذفت بسبب المحتوى الحساس". ملاحظة: إذا كانت الرسالة تحتوي على مواد تكون غير قانونية لأخذ لقطة شاشة، انسخ رابط الرسالة بدلاً من ذلك - قدم رابط الرسالة إلى @raisedadead للإرسال إلى فريق ديسكورد الاستئماني والسلامة.
5. **لا تستخدم @everyone أو @here** لا تستخدم @all أو @هنا تحت أي ظروف! كل شخص في غرفة الدردشة هذه سيحصل على إشعار. وفي بعض الحالات، عشرات الآلاف من الناس. بدلاً من ذلك، إذا كنت تريد من الناس رؤية إعلان، يمكنك تثبيته على القناة للسماح للجميع بقراءته.
6. **لا تهدد بحظر أو تعليق** إذا كان كاميرا يخالف مدونة السلوك، لا تهدد بحظرها أو تعليقها، ولا تحذيرها علنا أبدا. وبدلاً من ذلك، التحدث إليهم على انفراد، أو إرسال رسالة رسمية إليهم وإصدار تعليق (حسب البروتوكول أعلاه). لا أحد في تلك القناة يحتاج إلى معرفة أنك حظرت/علقت الشخص - يمكن للكاميرات عرض الملخص في قناة #activt-log إن كانوا يريدون الاستمرار في تلك المعلومات. إذا كان الانتهاك غير مقصود بوضوح ولا يبرر تعليقه أو محادثة خاصة، اجعل الكاميرا المسيئة على علم بأفعاله دون جعلها تخرج كتحذير. وعلى سبيل المثال:
- الكاميرا تنشر جدارا من التعليمات البرمجية لطلب المساعدة
المشرف: @username الرجاء استخدام Codepen أو Pastebin عند نشر كميات كبيرة من التعليمات البرمجية.
- أو إذا كان عليك أن تشرح لماذا:
المشرف: @username الرجاء استخدام Codepen أو Pastebin عند نشر كميات كبيرة من التعليمات البرمجية، لأنه يعطل الدردشة للجميع ويمكن أن يعتبر الرسائل غير المرغوب فيها وفقا لمدونة قواعد السلوك الخاصة بنا.
- الانتهاكات المعتدلة وغير المقصودة لمدونة قواعد السلوك
مدير المناقشة: هذا تذكير ودي للجميع باتباع مدونة قواعد السلوك: https://code-of-conduct.freecodecamp.org//
7. **لا تتقاعس عن أن تكون مشرفا** لا ترى نفسك كما فوق المجتمع. أنت مجتمعك. وقد ثق المجتمع بك للمساعدة في حماية شيء نادر نتقاسمه جميعا - مكان _للترحيب_ للمطورين الجدد. إذا كنت تتغاضى عن أن تكون مشرفا، قد يشعر الناس بالقلق حولك، بنفس الطريقة التي قد يشعر بها الناس بعدم الرضا حول ضابط شرطة، حتى لو لم يفعلوا شيئا خاطئا. هذه مجرد طبيعة إنسانية.
8. **لا تتعارض مع مشرفين آخرين** إذا اختلفت مع إجراء المشرف ، التحدث معهم على انفراد أو إحضارهم في قناة #mod-Chat. لا تتخطى الحظر أبدا، ولا تتناقض أبدا مع المدير الآخر (المنسقون) علنا. وبدلا من ذلك، تجري مناقشة رائعة في المحادثة المفرطة وتقنع مدير المناقشة بأنه ينبغي لهم أنفسهم أن يعكسوا عن حظرهم أو أن يغيروا وجهة نظرهم. تذكر: نحن جميعا في نفس الفريق. ونريد أن نكرم دور المنسقين وأن نقدم جبهة موحدة.
9. **تحدث مع مشرفين آخرين** لدينا غرفة للمشرفين فقط. استخدمه ! إذا كنت تشعر بعدم الارتياح لكيفية التعامل مع حالة معينة، فاطلب المساعدة من المشرفين الآخرين. إذا كنت تعتقد أنه يجب مناقشة شيء ما، قم بذلك. أنت جزء من الفريق ونحن نقدر مدخلات كل عضو في الفريق! حتى لو اختلفت تماما مع أي شيء في هذه المبادئ التوجيهية أو مدونة السلوك!
10. **غير نشط مؤقتا** إذا كنت لن تكون نشطا كمشرف لفترة من الوقت بسبب العطلة، المرض أو أي سبب آخر، تأكد من إخبار الآخرين في قناة الدردشة #mod-Chat. هذا هو ما نعرفه إذا كان بإمكاننا التعويل عليك لتكون نشطا بشكل منتظم في الخادم أم لا.
# كيف تصبح مشرفا
إذا كنت تساعد الناس في المجتمع باستمرار بمرور الوقت، فإن فريق إدارة شؤون الإعلام الخاص بنا سيأخذ في نهاية المطاف الإشعار، وسوف يذكرك أحدهم كمشرف محتمل لـ [موظفينا](https://forum.freecodecamp.org/g/Team). ولا توجد اختصارات يمكن أن تكون مشرفة.
إذا تمت الموافقة عليك، سوف نضيفك إلى أفرقة المشرفين لدينا على [GitHub](https://github.com/orgs/freeCodeCamp/teams/moderators)، [المنتدى](https://forum.freecodecamp.org/g/moderators)، إلخ.
> [!ملاحظة] > **لـ GitHub:** بعد قبولك كمشرف، سوف تتلقى دعوة مستودع Github. ستحتاج إلى التوجه نحو [FreCodeCamp GitHub دعوة](https://github.com/orgs/freeCodeCamp/invitation) لتتمكن من قبول الدعوة. هذا مطلوب لنكون قادرين على إعطائك حق الدخول للكتابة على بعض مستودعاتنا.
# كيف نتقاعد المشرفين الخاملين
يرجى ملاحظة أننا سنقوم في كثير من الأحيان بإزالة المودات التي نعتقد أنها غير نشطة. وعندما نفعل ذلك، سنرسل الرسالة التالية:
> هذه رسالة قياسية تخبرك أن: بما أنك لم تكن مشرفاً نشطاً مؤخراً، فإننا نزيلك من فريق المشرفين لدينا. ونحن نقدر تقديرا عميقا مساعدتكم في الماضي.
> إذا كنت تعتقد أننا فعلنا ذلك بخطأ، أو بمجرد أن تكون على استعداد للعودة والإسهام بالمزيد، فقط الرد على هذه الرسالة التي تسمح لي بالمعرفة.
# كيف تعمل غرفتنا المساهمين
أي شخص مرحب به في غرفة المساهمين [على ديسكورد](https://discord.gg/KVUmVXA). إنها غرفة الدردشة المخصصة لمنسقي الشؤون وآلات التصوير الأخرى الذين يسهمون في مجتمعنا بأي شكل من الأشكال، بما في ذلك من خلال الأفرقة الدراسية.
افتراضنا هو أن المساهمين سيقرأون أي شيء في هذه الغرفة يشير إليهم مباشرة باستخدام `@username`. كل شيء آخر اختياري. ولكن لا تتردد في قراءة أي شيء ينشره أي شخص هناك والتفاعل.
# التعامل مع المحامين
قد يتم الاتصال بك من قبل المنظمات التي ترغب في الشراكة أو الاشتراك مع FreCodeCamp بطريقة ما. بمجرد أن تدرك أن هذا هو ما يفعلونه، يرجى التوقف عن التحدث إليهم وإخبارهم بالبريد الإلكتروني quincy@freecodecamp.org. وهو يحصل على مقترحات من هذا القبيل طوال الوقت وهو في أفضل وضع للحكم على ما إذا كانت هذه العلاقة تستحق بالنسبة لمجتمعنا المحلي (ونادراً ما تكون عليها).
# التعامل مع الاستفسارات الصحية (العقلية)
قد تجد الحالات التي يلتمس فيها المستعملون المشورة الطبية أو الذين يعالجون مشاكل الصحة النفسية ويبحثون عن الدعم. وكمسألة تتعلق بالسياسات، ينبغي أن تتجنب التحدث على انفراد عن هذه المسائل. وإذا ما انعكست الحالة في مرحلة ما على لجنة التنسيق الإدارية، فإننا نريد تسجيل المحادثة (المحادثات). اجعل من الواضح أننا لسنا مهنيين طبيين وأنك تشجع المستخدم على العثور على مساعدة مهنية. على الرغم من صعوبة ذلك في بعض الأحيان، تجنب تقديم أي نصائح أو نصائح غير توجيه المستخدم نحو المساعدة المهنية!
إذا حدث هذا على ديسكورد: علق المستخدم. وهذا لا يعني معاقبتهم! تعليق المستخدم سوف ينشئ قناة خاصة يمكن الوصول إليها فقط من قبل المستخدم والفريق. وهذا سيعود بالفائدة على كل من المستخدم و FCC بعدة طرق:
- المستخدم مكفول بعض الخصوصية
- المحادثة العامة لم تعد متوقفة
- أعضاء الفريق الآخرون يمكنهم الدخول ، إذا كنت غير مريح في التعامل مع الوضع بنفسك
> [!NOTE] تعليق المستخدم يعطي لهم تلقائياً رسالة عن قراءة كود السلوك الخاص بنا. تأكد من إعلام المستخدم بأنك أوقفتها لإعطائهم بعض الخصوصية وأنهم لا يعاقبون. هذا مهم جداً! نحن نريد تماما تجنب إعطاء المستخدمين فكرة أنهم يعاقبون على التواصل للحصول على المساعدة!
إذا كنت تعتقد أن المستخدم قادر على العودة إلى المجتمع، انقر بزر الماوس الأيمن على القناة الخاصة ونسخ المعرف. ضع الرسالة التالية في #mod-log:
> المشورة الطبية المرجعية: <channel ID> <username>
بعد ذلك، يمكنك إزالة التعليق من المستخدم كما تفعل عادة.
عناوين URL المساعدة:
http://www.suicide.org/international-suicide-hotlines.html
# مذكرة بشأن حرية الكلام
في بعض الأحيان يدافع الناس عن شيء هجومي أو حارق قالوا بأنه "حرية التعبير".
يلخص هذا البرنامج الهزلي XKCD تماماً أفكار معظم المجتمعات المحلية بشأن حرية التعبير. لذا إذا دافع شخص ما عن شيء ما يقوله "حرية التعبير" لا تتردد في إرساله إليهم.
<div align="center"><img src='https://aws1.discourse-cdn.com/freecodecamp/original/3X/4/3/43a8b2eafe4c8622e02838f66f1dc6227de32c70.png' width="400" height="400" /></div>
شكرا لقراءة هذا، وشكرا لمساعدة مجتمع المطور!

128
docs/i18n/Arabic/flight-manuals/using-reply-templates.md Normal file
View File

@ -0,0 +1,128 @@
# استخدام قوالب الرد
هذه بعض قوالب الرد القياسية التي قد تستخدمها أثناء استعراض طلبات السحب ومشاكل التجليد.
> يمكنك إنشاء الخاص بك باستخدام خاصية GitHub [**الردود المحفوظة**](https://github.com/settings/replies/) أو استخدام تلك أدناه.
### شكرا لك
```markdown
شكرا لك على مساهمتك في الصفحة! 👍
نحن سعداء لقبول هذه التغييرات ونتطلع إلى المساهمات المستقبلية. 🎉
```
### شكرا لك و مبروك
> لشكر المساهمين لأول مرة وتشجيعهم.
```markdown
مرحبا @username. تهانينا على أول طلب سحب (PR)! 🎉
شكرا لك على مساهمتك في الصفحة! 👍
نحن سعداء لقبول هذه التغييرات ونتطلع إلى المساهمات المستقبلية. 📝
```
### خطأ في البناء
```markdown
مرحبًا @username
نحب أن نكون قادرين على دمج التغييرات الخاصة بك ولكن يبدو أن هناك خطأ في بناء Travis CI. ⚠️
بمجرد حل هذه المشكلات، سنكون قادرين على مراجعة حسابك الخاص ودمجه. 😊
---
> لا تتردد في الرجوع إلى [دليل نمط كتابة المقالات](https://github. om/freeCodeCamp/freeCodeCamp#article-title) لهذا المستودع عند تنسيق المقالة بشكل صحيح بحيث يمر بناء Travis CI الخاص بك. ✅
>
> أيضا، من الممارسات الجيدة على GitHub كتابة وصف موجز للتغييرات الخاصة بك عند إنشاء PR. 📝
```
### مزامنة Fork
> عندما لا يكون PR محدثاً مع فرع `الرئيسي`
``````markdown
مرحبًا @username
نحب أن نكون قادرين على دمج التغييرات الخاصة بك ولكن يبدو أن هناك خطأ في بناء Travis CI. ⚠️
```bash
خطأ: ENOTDIR: ليس دليلا، افتح 'src/pages/java/data-abstraction/index.md'
``````
هذا الخطأ بالذات لم يكن بسبب الملف الخاص بك ولكن خطأ قديم بسبب دمج الرمز الخاطئ في فرع `الرئيسي`. وقد تم حسمها منذ ذلك الحين.
لتمرير البناء، يجب عليك مزامنة أحدث التغييرات من فرع `الرئيسي` في `freeCodeCamp/freeCodeCamp` repo.
باستخدام سطر الأوامر، يمكنك القيام بذلك في ثلاث خطوات سهلة:
```bash
git عن بعد إضافة git://github.com/freeCodeCamp/freeCodeCamp.git
git يجلب أعلى مسار
git يجلب سيد أعلى مسار
```
إذا كنت تستخدم واجهة المستخدم ، يمكنك ببساطة `إضافة جهاز التحكم الجديد ...` واستخدام الرابط `git://github.com/freeCodeCamp/freeCodeCamp.git` من الأعلى.
بمجرد مزامنة الشوكة الخاصة بك وتمرير البناء، سنكون قادرين على مراجعة حسابك الشخصي ودمجه. 😊
---
> لا تتردد في الرجوع إلى مقالة [مزامنة Fork](https://help.github.com/articles/syncing-a-fork/) على GitHub للحصول على مزيد من التبصر حول كيفية إبقاء الشوك الخاص بك محدثة مع المستودع العلوي. 🔄
>
> كما أنه ممارسة جيدة على GitHub لكتابة وصف موجز للتغييرات الخاصة بك عند إنشاء PR. 📝
``````
### دمج التناقضات
> عندما يكون للرقم الرئاسي تضارب يحتاج إلى حله.1
```markdown
Hey @username
نحب أن نكون قادرين على دمج التغييرات الخاصة بك ولكن يبدو أن لديك بعض التضارب في الدمج.
⚠️
بمجرد حل هذه التعارضات، سنكون قادرين على مراجعة حسابك الخاص ودمجه. 😊
---
> إذا لم تكن على دراية بعملية الدمج، لا تتردد في النظر إلى دليل GitHub's على ["حل دمج تنازع"](https://help. ithub.com/articles/resolving-a-merge-conflict-on-github/). 🔍
>
> أيضا، من الممارسات الجيدة على GitHub كتابة وصف موجز للتغييرات الخاصة بك عند إنشاء PR. 📝
``````
(1) إذا كان أحد المساهمين لأول مرة لديه صراع على الاندماج، يقوم القائمون على ذلك بحل الصراع بالنسبة لهم.
### Duplicate
> عندما يكون اللمس متكرراً أو متكرراً.
```markdown
مرحبًا @username
يبدو أنه قد تم قبول تغييرات مماثلة في وقت سابق لهذه المقالة التي تقوم بتحريرها، آسفة لذلك. 😓
إذا كنت تشعر بأن لديك المزيد لإضافته، لا تتردد في فتح PR.
شكرا مرة أخرى! 😊
---
> إذا كان لديك أي أسئلة، لا تتردد في التواصل من خلال [Gitter](https://gitter.im/FreeCodeCamp/Contributors) أو من خلال التعليق أدناه. 💬
```
### إغلاق طلبات السحب غير صالحة
> عندما يكون R PR غير صالح.
```markdown
مرحبًا@username
لم تقم بإضافة أي محتوى، سنقوم بإغلاق هذا اللقب و وضع علامة على أنه 'غير صالح`. 😓
لا تتردد في فتح بطاقة شخصية أخرى! 👍
```

478
docs/i18n/Arabic/flight-manuals/working-on-virtual-machines.md Normal file
View File

@ -0,0 +1,478 @@
# Flight Manual for working on Virtual Machines
وبصفتها عضوا في الموظف أو في فريق التفويض، قد يكون تم منحك حق الوصول إلى موفري خدمات السحابة مثل أزور، ديغيرونس، إلخ.
إليك بعض الأوامر المفيدة التي يمكنك استخدامها للعمل على الآلات الظاهرية (VM)، على سبيل المثال القيام بتحديثات الصيانة أو القيام بحفظ المنازل بشكل عام.
# Get a list of the VMs
> [!ملاحظة] بينما قد يكون لديك بالفعل وصول SSH إلى VM، ذلك وحده لن يسمح لك بقائمة الرسائل الشخصية ما لم يتم منحك حق الوصول إلى بوابات السحابة كذلك.
## Azure
تثبيت Azure CLI `az`: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli
> **(One-time) Install on macOS with [`homebrew`](https://brew.sh):**
```
brew install azure-cli
```
> **(One-time) Login:**
```
az login
```
> **Get the list of VM names and P addresses:**
```
az vm list-ip-addresses --output table
```
## Digital Ocean
تثبيت Digital Ocean CLI `doctl`: https://github.com/digitalocean/doctl#installing-doctl
> **(One-time) Install on macOS with [`homebrew`](https://brew.sh):**
```
brew install doctl
```
> **(One-time) Login:**
تبديل المصادقة والسياق: https://github.com/digitalocean/doctl#authenticating-with-digitalocean
```
doctl auth init
```
> **Get the list of VM names and IP addresses:**
```
doctl compute droplet list --format "ID,Name,PublicIPv4"
```
# Spin a VM (or VM Scale Set)
> Todo: Add instructions for spinning VM(s)
<!--
The below instructions are stale.
### 0. Prerequisites (workspace Setup) for Staff
Get a login session on `azure cli`, and clone the
[`infra`](https://github.com/freeCodeCamp/infra) for setting up template
workspace.
```console
az login
git clone https://github.com/freeCodeCamp/infra
cd infra
```
Use the Scratchpad subdirectory for temporary files, and making one-off edits.
The contents in this subdirectory are intentionally ignored from source control.
### 1. Provision VMs on Azure.
List all Resource Groups
```console
az group list --output table
```
```console
Name Location Status
--------------------------------- ------------- ---------
tools-rg eastus Succeeded
```
Create a Resource Group
```
az group create --location eastus --name stg-rg
```
```console
az group list --output table
```
```console
Name Location Status
--------------------------------- ------------- ---------
tools-rg eastus Succeeded
stg-rg eastus Succeeded
```
Next per the need, provision a single VM or a scaleset.
#### A. provision single instances
```console
az vm create \
--resource-group stg-rg-eastus \
--name <VIRTUAL_MACHINE_NAME> \
--image UbuntuLTS \
--size <VIRTUAL_MACHINE_SKU>
--custom-data cloud-init/nginx-cloud-init.yaml \
--admin-username <USERNAME> \
--ssh-key-values <SSH_KEYS>.pub
```
#### B. provision scaleset instance
```console
az vmss create \
--resource-group stg-rg-eastus \
--name <VIRTUAL_MACHINE_SCALESET_NAME> \
--image UbuntuLTS \
--size <VIRTUAL_MACHINE_SKU>
--upgrade-policy-mode automatic \
--custom-data cloud-init/nginx-cloud-init.yaml \
--admin-username <USERNAME> \
--ssh-key-values <SSH_KEYS>.pub
```
> [!NOTE]
>
> - The custom-data config should allow you to configure and add SSH keys,
> install packages etc. via the `cloud-init` templates in your local
> workspace. Tweak the files in your local workspace as needed. The cloud-init
> config is optional and you can omit it completely to do setups manually as
> well.
>
> - The virtual machine SKU is something like: **Standard_B2s** which can be
> retrived by executing something like
> `az vm list-sizes -l eastus --output table` or checking the Azure portal
> pricing.
-->
# Keep VMs updated
You should keep the VMs up to date by performing updates and upgrades. سيؤدي هذا إلى التأكد من أن الآلة الافتراضية قد تم تصويبها مع أحدث إصلاحات الأمان.
> [!WARNING] Before you run these commands:
>
> - تأكد من أنه تم توفير VM بالكامل ولا يوجد خطوات ما بعد التثبيت قيد التشغيل.
> - إذا كنت تقوم بتحديث الحزم على VM التي تقدم بالفعل تطبيقا، تأكد من إيقاف التطبيق / حفظه. ستسبب تحديثات الحزمة عرض النطاق الترددي للشبكة، الذاكرة و/أو استخدام المعالج مما يؤدي إلى حالات انقطاع في تشغيل التطبيقات.
Update package information
```console
sudo apt update
```
Upgrade installed packages
```console
sudo apt upgrade -y
```
Cleanup unused packages
```console
sudo apt autoremove -y
```
# Work on Web Servers (Proxy)
نقوم بتشغيل مثيلات التحميل المتوازنة (Azure Load Balancer) لخوادمنا على الويب. تقوم هذه الخوادم بتشغيل NGINX التي تعكس مسار كل حركة المرور إلى freeCodeCamp.org من تطبيقات مختلفة تعمل على بنيات تحتية خاصة بها.
إعدادات NGINX متاحة على [هذا المستودع](https://github.com/freeCodeCamp/nginx-config).
## First Install
Provisioning VMs with the Code
### 1. (Optional) Install NGINX and configure from repository.
The basic setup should be ready OOTB, via the cloud-init configuration. يقوم SSH و بالتغييرات حسب الاقتضاء للحالة (الحالات) الخاصة.
إذا لم تستخدم إعدادات Cloud init سابقا استخدم أدناه للإعداد اليدوي ل NGINX وصفحات الخطأ:
```console
sudo su
cd /var/www/html
git clone https://github.com/freeCodeCamp/error-pages
cd /etc/
rm -rf nginx
git clone https://github.com/freeCodeCamp/nginx-config nginx
cd /etc/nginx
```
### 2. Install Cloudflare origin certificates and upstream application config.
احصل على شهادات منشأ Cloudflare من التخزين الآمن والتثبيت في المواقع المطلوبة.
**OR**
Move over existing certificates:
```console
# Local
scp -r username@source-server-public-ip:/etc/nginx/ssl ./
scp -pr ./ssl username@target-server-public-ip:/tmp/
# Remote
rm -rf ./ssl
mv /tmp/ssl ./
```
Update Upstream Configurations:
```console
vi configs/upstreams.conf
```
Add/update the source/origin application IP addresses.
### 3. Setup networking and firewalls.
Configure Azure firewalls and `ufw` as needed for ingress origin addresses.
### 4. Add the VM to the load balancer backend pool.
Configure and add rules to load balancer if needed. قد تحتاج أيضًا إلى إضافة VMs لتحميل مخزن خلفية الموازنة إذا لزم الأمر.
## تحديث الأمثلة (النفوذ)
1. Check status for NGINX service using the below command:
```console
sudo systemctl status nginx
```
2. Logging and monitoring for the servers are available at:
> <h3 align="center"><a href='https://amplify.nginx.com' _target='blank'>https://amplify.nginx.com</a></h3>
## Updating Instances (Maintenance)
يتم الحفاظ على تغييرات التكوين إلى مثيلاتنا NGINX على GitHub، يجب أن يكون نشر في كل حالة مثل هذا:
1. SSH into the instance and enter sudo
```console
sudo su
```
2. Get the latest config code.
```console
cd /etc/nginx
git fetch --all --prune
git reset --hard origin/master
```
3. اختبار وإعادة تحميل الإعدادات [مع الإشارات](https://docs.nginx.com/nginx/admin-guide/basic-functionality/runtime-control/#controlling-nginx).
```console
nginx -t
nginx -s reload
```
# Work on API Instances
1. Install build tools for node binaries (`node-gyp`) etc.
```console
sudo apt install build-essential
```
## First Install
Provisioning VMs with the Code
1. Install Node LTS.
2. Update `npm` and install PM2 and setup logrotate and startup on boot
```console
npm i -g npm
npm i -g pm2
pm2 install pm2-logrotate
pm2 startup
```
3. Clone freeCodeCamp, setup env and keys.
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
cd freeCodeCamp
git checkout production-current # or any other branch to be deployed
```
4. Create the `.env` from the secure credentials storage.
5. Create the `google-credentials.json` from the secure credentials storage.
6. Install dependencies
```console
npm ci
```
7. Build the server
```console
npm run ensure-env && npm run build:server
```
8. Start Instances
```console
cd api-server
pm2 start production-start.js -i max --max-memory-restart 600M --name org
```
## تحديث الأمثلة (النفوذ)
```console
## 1 - قطع الأشجار والرصد
```console
سجلات pm2
```
```console
pm2 monit
```
## Updating Instances (Maintenance)
Code changes need to be deployed to the API instances from time to time. يمكن أن يكون تحديث متجدد أو تحديث يدوي. الأخير ضروري عند تغيير الإعتمادات أو إضافة متغيرات الإنفيرون.
> [!DANGER] خطوط الأنابيب الآلية لا تتعامل مع تحديثات الإعتمادات في دقيقة. We need to do a manual update before any deployment pipeline runs.
### 1. Manual Updates - Used for updating dependencies, env variables.
1. Stop all instances
```console
pm2 stop all
```
2. Install dependencies
```console
npm ci
```
3. Build the server
```console
npm run ensure-env && npm run build:server
```
4. Start Instances
```console
pm2 start all --update-env && pm2 logs
```
### 2. Rolling updates - Used for logical changes to code.
```console
pm2 reload all --update-env && pm2 logs
```
> [!NOTE] We are handling rolling updates to code, logic, via pipelines. يجب ألا تحتاج إلى تشغيل هذه الأوامر وهذه الوثائق هنا للوثائق. These are here for documentation.
# Work on Client Instances
1. Install build tools for node binaries (`node-gyp`) etc.
```console
sudo apt install build-essential
```
## First Install
Provisioning VMs with the Code
1. Install Node LTS.
2. Update `npm` and install PM2 and setup logrotate and startup on boot
```console
npm i -g npm
npm i -g pm2
npm install -g serve
pm2 install pm2-logrotate
pm2 startup
```
3. Clone client config, setup env and keys.
```console
git clone https://github.com/freeCodeCamp/client-config.git client
cd client
```
```console
git clone https://github.com/freeCodeCamp/client-config.git client
cd client
```
ابدأ مثيلات العنصر النائب لعميل الويب، سيتم تحديثها مع مصنوعات من أنبوب ازور.
> Todo: This setup needs to move to S3 or Azure Blob storage
>
> ```console
عملاء-start-Preary.sh --name client-primary
صدى "serve -c . /../serve.json www -p 52525" &#062;&#062; client-start-secondary.sh
chmod +x client-start-secondary. (ح)
pm2 حذف العميل الثانوي
pm2 بدء./client-start-secondary.sh --name client-secondary
```
## تحديث الأمثلة (النفوذ)
```console
## 1 - قطع الأشجار والرصد
```console
سجلات pm2
```
```console
pm2 monit
```
## Updating Instances (Maintenance)
Code changes need to be deployed to the API instances from time to time. يمكن أن يكون تحديث متجدد أو تحديث يدوي. الأخير ضروري عند تغيير الإعتمادات أو إضافة متغيرات الإنفيرون.
> [!DANGER] خطوط الأنابيب الآلية لا تتعامل مع تحديثات الإعتمادات في دقيقة. We need to do a manual update before any deployment pipeline runs.
### 1. Manual Updates - Used for updating dependencies, env variables.
1. Stop all instances
```console
pm2 stop all
```
2. Install or update dependencies
3. Start Instances
```console
pm2 start all --update-env && pm2 logs
```
### 2. Rolling updates - Used for logical changes to code.
```console
pm2 reload all --update-env && pm2 logs
```
> [!NOTE] We are handling rolling updates to code, logic, via pipelines. يجب ألا تحتاج إلى تشغيل هذه الأوامر وهذه الوثائق هنا للوثائق. These are here for documentation.

100
docs/i18n/Arabic/how-to-catch-outgoing-emails-locally.md Normal file
View File

@ -0,0 +1,100 @@
> **ملاحظة:** هذه خطوة **اختيارية** وهي مطلوبة فقط عند العمل مع مسار عمل البريد الإلكتروني
## مقدمة
بعض تدفقات عمل البريد الإلكتروني، مثل تحديث البريد الإلكتروني للمستخدم، يتطلب خادم api-end لإرسال رسائل البريد الإلكتروني الصادرة. بديل لاستخدام موفر خدمة البريد الإلكتروني لإرسال رسائل البريد الإلكتروني الفعلية، Mailhog هو أداة المطور لاختبار البريد الإلكتروني التي ستحصل على رسائل البريد الإلكتروني المرسلة من مثيل freeCodeCamp الخاص بك.
## تثبيت MailHog
يمكن تثبيت MailHog على macOS و Windows و Linux.
- [مقدمة](#introduction)
- [تثبيت MailHog](#installing-mailhog)
- [تثبيت MailHog على macOS](#installing-mailhog-on-macos)
- [تثبيت MailHog على Windows](#installing-mailhog-on-windows)
- [تثبيت MailHog على Linux](#installing-mailhog-on-linux)
- [استخدام MailHog](#using-mailhog)
- [روابط مفيدة](#useful-links)
### تثبيت MailHog على macOS
تثبيت MailHog على macOS مع [Homebrew](https://brew.sh/):
```bash
قرع تثبيت mailhog
خدمات الخبز تبدأ في mailhog
```
الأوامر المذكورة أعلاه ستبدأ خدمة mailhog في الخلفية.
عند اكتمال التثبيت، يمكنك بدء [باستخدام MailHog](#using-mailhog).
### تثبيت MailHog على Windows
تحميل أحدث إصدار من MailHog من [المستودع الرسمي لـ MailHog](https://github.com/mailhog/MailHog/releases). حدد موقع وانقر على رابط إصدار Windows (32 أو 64 bit) و ملف .exe سيتم تنزيله إلى جهاز الكمبيوتر الخاص بك.
عند اكتمال التنزيل، انقر لفتح الملف. قد يظهر إشعار بجدار الحماية Windows ، لطلب إذن الوصول إلى MailHog. سيفتح موجه سطر الأوامر القياسي لنظام Windows حيث سيتم تشغيل MailHog بمجرد منح الوصول إلى جدار الحماية.
أغلق MailHog عن طريق إغلاق نافذة طلب الأوامر. لبدء تشغيل MailHog مرة أخرى، انقر على MailHog القابل للتنفيذ (. x) الملف الذي تم تنزيله في البداية - ليس من الضروري تنزيل ملف تثبيت MailHog جديد.
ابدأ [باستخدام MailHog](#using-mailhog).
### تثبيت MailHog على Linux
أولاً، قم بتثبيت [اذهب](https://golang.org).
تشغيل الأوامر التالية لتثبيت GO على الأنظمة القائمة على دبيان مثل أوبونتو و لينكس مينتنت.
```bash
sudo apt-get install golang
```
تشغيل الأوامر التالية لتثبيت GO على الأنظمة القائمة على RPM، مثل CentOS، فيدورا، Red Hat Linux، إلخ.
```bash
sudo dnf install golang
```
بدلاً من ذلك، قم بتشغيل الأوامر التالية لتثبيت GO.
```bash
sudo yum install golang
```
الآن قم بتعيين مسار الذهاب مع الأوامر التالية.
```bash
صدى "تصدير GOPATH=$HOME/go" >> ~/.prof
صدى 'تصدير PATH=$PATH:/usr/local/go/bin:$GOPATH/bin' >> ~/.prof
مصدر ~/.profile
```
أخيرا، أدخل الأوامر أدناه لتثبيت وتشغيل MailHog.
```bash
go get github.com/mailhog/MailHog
sudo cp /home/$(whoami)/go/bin/MailHog /usr/local/bin/mailhog
mailhog
```
ابدأ [باستخدام MailHog](#using-mailhog).
## استخدام MailHog
افتح علامة تبويب أو نافذة جديدة للمتصفح وانتقل إلى [http://localhost:8025](http://localhost:8025) لفتح صندوق الوارد الخاص بك MailHog عند اكتمال تثبيت MailHog وتشغيل MailHog. سيظهر صندوق الوارد مشابه للشاشة التي تلصق أدناه.
![لقطة شاشة MailHog 1](images/mailhog/1.jpg)
رسائل البريد الإلكتروني المرسلة بواسطة تثبيت freeCodeCamp الخاص بك ستظهر كما يلي
![لقطة شاشة MailHog 2](images/mailhog/2.jpg)
ستتوفر علامة تبويب تسمح لك بعرض إما نص عادي أو مصدر المحتوى عند فتح بريد إلكتروني معين. تأكد من اختيار علامة التبويب للنص العادي على النحو التالي.
![لقطة شاشة MailHog 3](images/mailhog/3.jpg)
يجب أن تكون جميع الروابط في البريد الإلكتروني قابلة للنقر والعزم على عنوان URL الخاص بها.
## روابط مفيدة
- تحقق من [MailHog](https://github.com/mailhog/MailHog) مستودع لمزيد من المعلومات المتعلقة بـ MailHog. تتوفر أيضا معلومات إضافية عن تكوينات MailHog المخصصة.

195
docs/i18n/Arabic/how-to-help-with-video-challenges.md Normal file
View File

@ -0,0 +1,195 @@
# كيفية المساعدة في مواجهة تحديات الفيديو
تحديات الفيديو هي نوع جديد من التحديات في منهج FreCodeCamp.
تحدي الفيديو هو جزء صغير من دورة فيديو كاملة عن موضوع معين. صفحة تحدي الفيديو تتضمن فيديو يوتيوب. ولكل صفحة تحدٍ سؤال واحد متعدد الخيارات يتصل بالفيديو. يجب على المستخدم أن يجيب على السؤال بشكل صحيح قبل الانتقال إلى تحدي الفيديو التالي في الدورة.
يتم إنشاء صفحات تحدي الفيديو من قبل أعضاء فريق FreCodeCamp. يتم تحميل مقاطع فيديو اليوتيوب أيضًا من قبل أعضاء فريق FreCodeCamp. والعديد من التحديات التي تواجه الفيديو ليست لها حتى الآن أسئلة مرتبطة بها.
يمكنك المساعدة عن طريق إنشاء أسئلة متعددة الخيارات ذات الصلة بأقسام الفيديو وإضافة الأسئلة إلى ملفات markdown لتحديات الفيديو.
## قالب التحدي
فيما يلي نموذج لما تبدو عليه ملفات الـ markdown للتحدي.
````md
---
المعرف: معرف فريد (أبجدي رقمي, MongoDB_id)
العنوان: عنوان التحدي
نوع التحدي: 11
معرف الفيديو: 'YouTube videoID لتحدي الفيديو'
---
## # وصف
<section id='description'>
وصف اختياري مع معلومات مفيدة ذات صلة بالفيديو.
</section>
## الإختبارات
<section id='tests'>
'سؤال 'ml
:
نص: 'سؤال'
إجابات:
- 'الإجابة واحدة'
- 'الإجابة الثانية'
- 'الإجابة ثلاثية'
الحلول: 3
````
</section>
````
## 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/master/curriculum/challenges/english/08-data-analysis-with-python/data-analysis-with-python-course)
- [TensorFlow 2.0 Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/11-machine-learning-with-python/tensorflow)
- [Numpy Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/08-data-analysis-with-python/numpy)
- [How Neural Networks Work Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/11-machine-learning-with-python/how-neural-networks-work)
Pick a challenge markdown file from the options above.
### السحابة عبر الفيديو المقترن بالتحدي وإنشاء سؤال اختياري مميز
أولا، ابحث عن معرف الفيديو.
على سبيل المثال، في التعليمة البرمجية التالية من رأس ملف تحدي الفيديو markdown، الفيديو هو "nVAaxZ34k". وينبغي عرض المعلومات في شكل جدول على موقع GitHub.
````
---
معرف: 5e9a093a74c4063ca6f7c14d title: Data Analysis example A ChallengeTpe: 11
videoId: nVAaxZ34khk
---
```
بعد ذلك، الوصول إلى فيديو اليوتيوب باستخدام ذلك المعرف الفيديو. عنوان URL للفيديو سيكون هو:
https://www.youtube. om/watch?v=[videoId] (إضافة الفيديو إلى عنوان URL بدون أقواس معقوفة)
في المثال أعلاه، عنوان URL هو https://www. outube.com/watch?v=nVAaxZ34khk
سمع فيديو يوتيوب مع معرف الفيديو هذا وفكر في سؤال متعدد الخيارات يستند إلى محتوى الفيديو.
### اضافة السؤال الى ملف markdown
يمكنك اضافة السؤال محليا او مباشرة الى واجهة GitHub ### اضافة السؤال الى ملف markdown
يمكنك اضافة السؤال محليا او مباشرة الى واجهة GitHub لإضافة السؤال محلياً، تحتاج إلى [إعداد freeCodeCamp محلياً](howto-setup-freecodecamp-locally.md). يمكنك أيضًا العثور على الملف على GitHub والنقر على زر التحرير لإضافة السؤال في المتصفح الخاص بك.
إذا لم يكن السؤال قد أضيف بعد إلى تحدي فيديو معين، سيكون لديه السؤال الافتراضي التالي:
```ml
سؤال:
نص: <unk>
سؤال
إجابات:
- <unk>
واحد
- <unk>
إثنان
- <unk>
ثلاثة
حلول: 3
```
قم بتحديث كلمة ”سؤال“ بسؤالك. • تحديث "واحد" و"اثنين" و"ثلاثة" مع الإجابات الممكنة. تأكد من تحديث رقم الحل الذي يكون إجابته صحيحاً. يمكنك إضافة المزيد من الإجابات الممكنة باستخدام نفس التنسيق. ويمكن أن تكون علامات الاقتباس محاطة بالسؤال والإجابات.
#### استخدم markdown لتنسيق سؤالك
أما النص الوارد في السؤال فيتم الرجوع إليه كعلامة مأخوذة من الأسفل. أبسط طريقة لضمان تنسيقه بشكل صحيح هي بدء السؤال بنص `: <unk>`، مثل هذا:
```yml
سؤال:
نص: <unk>
سؤال
```
ثم تحتاج إلى التأكد من أن سؤالك موجود على سطر جديد وذو مستوى واحد أكثر من `نص: <unk>`.
ويمكن استخدام نفس النهج للإجابات، بحيث يصبح السؤال بأكمله
```yml
سؤال:
نص: <unk>
سؤال
إجابات:
- <unk>
الإجابة الأولى
- <unk>
ثانية
- <unk>
الحل الثالث
: 2
```
تأكد من أن كل إجابة معقولة ولكن هناك إجابة صحيحة واحدة فقط.
#### استخدام HTML
يمكن أن تحتوي الأسئلة والإجابات على بعض علامات HTML مثل `<br>` لسطر جديد. وينبغي استخدام وسوم HTML بشكل ضئيل، عندما لا يمكن التعبير عن الأسئلة بدونها.
### أمثلة على الأسئلة
#### أمثلة بدون HTML
````yml
سؤال:
نص: <unk>
ماذا يسجل رمز جافا سكريبت هذا إلى وحدة التحكم؟
```js
console.log('hello world')؛
````
اختر إجابة!
الإجابات:
- مرحبا *العالم*
- **مرحبا** العالم
- مرحبا بالعالم حل: 3
````
````yml
سؤال:
نص: <unk>
ما الذي سيطبع بعد تشغيل هذا الكود:
```py
العرض = 15
ارتفاع = 12. الطباعة (ارتفاع/3)
````
الإجابات:
- | 39
- | 4
- 4.0
- 5.0
- 5 حل: 3
````
#### مثال مع HTML
```ml
سؤال:
نص: <unk>
ما الذي سيطبع بعد تشغيل هذا الرمز:
<pre><code>عرض = 15<br>ارتفاع = 12.<br>الطباعة (ارتفاع/3)<code></pre>
إجابات:
- <unk>
39
- <unk>
4
- <unk>
4.
````
ويدل المثال الأخير على أنه يمكن استخدام HTML، ولكنه ليس مقروءاً كالإصدار بدونه.
لمزيد من الأمثلة، يمكنك النظر إلى ملفات markdown للدورة التالية للفيديو. جميع التحديات لديها بالفعل أسئلة: [بايثون لكل شخص دورة](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/07-scientific-computing-with-python/python-for-everybody)
## فتح طلب سحب
بعد إنشاء سؤال واحد أو أكثر، يمكنك إدخال تغييرات على فرع جديد و [فتح طلب سحب](how-to-open-a-pull-request.md).

179
docs/i18n/Arabic/how-to-open-a-pull-request.md Normal file
View File

@ -0,0 +1,179 @@
# كيفية فتح طلب سحب (PR)
يتيح لك طلب سحب إرسال تغييرات من الشوك الخاص بك على GitHub إلى المستودع الرئيسي لـ freeCodeCamp.org. بمجرد الانتهاء من إجراء تغييرات على التعليمة البرمجية، أو تحديات البرمجة، يجب عليك اتباع هذه المبادئ التوجيهية لإرسال PR.
## إعداد عنوان جيد لـ PR
نوصي باستخدام [عنوان ورسائل تقليدية](https://www.conventionalcommits.org/) للإلتزامات وسحب الطلب. وتتخذ الاتفاقية الشكل التالي:
> `<type>([النطاق/النطاقات الاختيارية]): <description>`
>
> وعلى سبيل المثال:
>
> `إصلاح (تعلم): اختبارات الدو...بينما تحدي الحلقة`
عند فتح طلب سحب (PR)، يمكنك استخدام أدناه لتحديد النوع والنطاق (اختياري) والوصف.
**النوع:**
| نوع | متى يتم تحديد |
|:--------- |:------------------------------------------------------------ |
| إصلاح | تغيير أو تحديث/تحسين وظائف واختبارات ودروس وما إلى ذلك. |
| الأجرام | فقط إذا كنت تضيف وظائف جديدة، اختبارات، إلخ. |
| عصى | التغييرات التي لا تتصل بالكود أو الاختبارات أو الدرس الواحد. |
| المستندات | تغييرات على دليل `/docs` أو المبادئ التوجيهية المساهمة، إلخ. |
**النطاق:**
يمكنك تحديد نطاق من [قائمة التسميات](https://github.com/freeCodeCamp/freeCodeCamp/labels?q=scope).
**وصف:**
ابقائها قصيرة (أقل من 30 حرفاً) وبسيطة، يمكنك إضافة المزيد من المعلومات في مربع وصف العلاقات العامة والتعليقات.
وفيما يلي بعض الأمثلة على عناوين حقوق الملكية الفكرية الجيدة:
- `إصلاح (أ11y): تحسين تباين شريط البحث`
- `الميزة: إضافة المزيد من الاختبارات إلى تحديات html و css`
- `إصلاح (api,العميل): منع أخطاء CORS عند تقديم النموذج`
- `docs(i18n): الترجمة الصينية للإعداد المحلي`
## اقتراح طلب سحب
1. بمجرد أن يتم الالتزام بالتعديلات، سيتم مطالبتك بإنشاء طلب سحب على صفحة GitHub الخاصة بك.
![الصورة - مقارنة طلب السحب على GitHub](./images/github/compare-pull-request-prompt.png)
2. بشكل افتراضي، يجب أن تكون جميع طلبات السحب ضد مخزن FreCodeCamp الرئيسي، `رئيسي` فرع.
تأكد من أن القاعدة الخاصة بك تم تعيينها على رمز كامب/FreCodeCamp عند رفع طلب سحب.
![الصورة - مقارنة الشوكات عند تقديم طلب سحب](./images/github/comparing-forks-for-pull-request.png)
3. قم بتقديم طلب السحب من فرعك إلى فرع `الكود كامب الرئيسي`
4. في متن حسابك الشخصي يتضمن ملخصاً أكثر تفصيلاً للتغييرات التي قمت بها ولماذا.
- سيتم تقديمك مع قالب طلب الجذب. هذه قائمة مرجعية كان يجب عليك متابعتها قبل فتح طلب السحب.
- قم بتعبئة التفاصيل كما تراها مناسبة. وسيتم استعراض هذه المعلومات وسيقرر المراجعون ما إذا كان طلب السحب الخاص بك قد قُبل أم لا.
- إذا كان الغرض من اللعبة هو معالجة مشكلة GitHub موجودة عندئذ، في نهاية جسم وصف PR، استخدم الكلمة المفتاحية _يغلق_ مع رقم المشكلة [أغلق هذه المشكلة تلقائيًا إذا تم قبول ودمج الـ PR](https://help.github.com/en/articles/closing-issues-using-keywords).
> على سبيل المثال: `إغلاق #123` سيغلق المشكلة 123
5. حدد ما إذا كنت قد اختبرت على نسخة محلية من الموقع أم لا.
هذا مهم جداً عند إجراء تغييرات لا تقتصر على تعديل محتوى النص مثل التوثيق أو وصف التحدي. وتشمل أمثلة التغييرات التي تحتاج إلى اختبار محلي جافا سكريبت أو CSS أو HTML التي يمكن أن تغير وظيفة أو تخطيط الصفحة.
## تعليقات على طلبات السحب
> تهانينا! :tada: حول إجراء كلمة مرور وشكرا جزيلا على تخصيص الوقت للإسهام.
سوف يلقي المشرفون الآن نظرة ويتركون لك ردود الفعل. يرجى التحلي بالصبر مع زملائهم المشرفين واحترام وقتهم. ويتم استعراض جميع طلبات السحب في الوقت المناسب.
إذا كنت بحاجة إلى أي مساعدة يرجى المناقشة في [غرفة الدردشة المساهمين](https://gitter.im/FreeCodeCamp/Contributors)، نحن سعداء للغاية لمساعدتك.
> [!تلميح] إذا كنت ترغب في المساهمة بمزيد من طلبات السحب، ننصحك بقراءة [إجراء التغييرات ومزامنة](https://contribute.freecodecamp.org/#/how-to-setup-freecodecamp-locally?id=making-changes-locally) المبادئ التوجيهية لتجنب الاضطرار إلى حذف الشوك.
## تضارب حول طلب السحب
يمكن أن تنشأ تناقضات لأن العديد من المساهمين يعملون على المستودع، والتغييرات يمكن أن تحطم حسابك الشخصي الذي هو في انتظار المراجعة والدمج.
وفي كثير من الأحيان قد لا تحتاج إلى قاعدة جديدة، لأننا نهدم جميع الالتزامات، ولكن إذا كان طلب إعادة قاعدة هنا هو ما ينبغي أن تفعله.
### لإصلاح الأخطاء والميزات المعتادة
عندما تعمل على الأخطاء والميزات العادية في فرع التطوير `الرئيسي`، يمكنك القيام بإعادة قاعدة بسيطة:
1. استند إلى نسختك المحلية:
```console
git دفع <pr-branch>
git سحب --rebase الرئيسي في أعلى المجرى
```
2. حل أي تعارضات وإضافة / تحرير الالتزامات
```console
# إما
git يضيف.
git الالتزام -m "chore: حل التعارضات"
# أو
git إضافة.
git الالتزام --تعديل --عدم تحرير
```
3. قم بالعودة إلى التغييرات الخاصة بك في بطاقة PR
```console
git push --أصل القوة <pr-branch>
```
### للمناهج الدراسية والمميزات القادمة
عندما تعمل على الميزات الخاصة بفروع المناهج الدراسية `التالية*` ، لديك اختيار الكرز:
1. تأكد من أن أعلى البث يأتي في تزامن مع اللغة المحلية الخاصة بك:
```console
git الخروج الرئيسي
git يجلب --كل --prune
git الخروج التالي لمشاريع python-
git إعادة تعيين --مشاريع Python التالية - Python
```
2. أخذ نسخة احتياطية
(أ) (أ) إما حذف الفرع المحلي الخاص بك بعد أخذ نسخة احتياطية (إذا كنت لا تزال لديك محلياً):
```console
git الخروج <pr-branch-name>
# مثال:
# git Checout feat/add-numpy-video-question
git Checout -b <backup-branch-name>
# مثال:
# git Checout -b backup-feat/add-numpy-video-question
git branch -D <pr-branch-name>
```
(ب) (ب) أو مجرد نسخة احتياطية لفرع pr الخاص بك (إذا لم يكن لديك محلياً):
```console
git الخروج -b <backup-branch-name> الأصل /<pr-branch-name>
# مثال:
# git Checout -b backup-feat/add-numpy-video-question origin/feat/add-numpy-video-question
```
4. البدء بصفحة نظيفة:
```console
git الدفع -b <pr-branch-name> مشاريع python-
git cherry-seleck <commit-hash>
```
5. حل أي تضارب، وتنظيف، وتثبيت اختبارات التشغيل
```console
npm تشغيل نظيفة
npm ci
npm تشغيل الاختبار:منهج --superblock=<superblock-name>
# مثال:
# npm تشغيل الاختبار:منهج --superblock=python-for-all person
```
6. إذا بدا كل شيء جيدًا ضحك للعودة إلى اللعبة
```console
git push --أصل القوة <pr-branch-name>
```

546
docs/i18n/Arabic/how-to-setup-freecodecamp-locally.md Normal file
View File

@ -0,0 +1,546 @@
اتبع هذه المبادئ التوجيهية لإنشاء FreCodeCamp محليا على نظامك. وهذا أمر موصى به بشدة إذا كنت ترغب في المساهمة بانتظام.
لبعض تدفقات العمل المساهمة، تحتاج إلى أن يكون CodeCamp يعمل محلياً. على سبيل المثال، معاينة تحديات البرمجة أو تصحيح الأخطاء وإصلاحها في الكود البرمجي.
> [!TIP] إذا كنت غير مهتم بإعداد freeCodeCamp محليا التفكير في استخدام Gitpod، بيئة ديف مجانية على الإنترنت.
>
> [![فتح في Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
>
> (يبدأ بيئة dev جاهزة للبرمجة ل freeCodeCamp في المتصفح الخاص بك.)
## إعداد جهازك المحلي
ابدأ بتثبيت البرنامج الأساسي لنظام التشغيل الخاص بك.
نحن ندعم التطوير بشكل أساسي على أنظمة **\*nix**. يعمل موظفينا ومساهمو مجتمعنا بانتظام مع البرنامج البرمجي باستخدام الأدوات المثبتة على Ubuntu و macOS.
نحن أيضًا ندعم Windows 10 عبر WSL2، الذي يمكنك إعداده عن طريق [قراءة هذا الدليل](/how-to-setup-wsl).
كما يطور بعض أعضاء المجتمع المحلي على Windows 10 محلياً مع Git for Windows (Git Bash)، وأدوات أخرى مثبتة على Windows. ليس لدينا دعم رسمي لهذا الإعداد في هذا الوقت، ونحن نوصي باستخدام WSL2 بدلا من ذلك.
**الشروط:**
| الشروط المسبقة | الإصدار | الحواشي |
| --------------------------------------------------------------------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Node.js](http://nodejs.org) | `12.x` | [جدول LTS](https://github.com/nodejs/Release#release-schedule) |
| npm (تأتي مجمعة مع العقدة) | `6.x` | ليس لديها إصدارات LTS، نحن نستخدم الإصدار المجمع مع LTS العقدة |
| [خادم مجتمع MongoDB](https://docs.mongodb.com/manual/administration/install-community/) | `3.6` | [ملاحظات الإصدار](https://docs.mongodb.com/manual/release-notes/), ملاحظة: نحن حاليا في `3.6`, [من المقرر ترقية](https://github.com/freeCodeCamp/freeCodeCamp/issues/18275). |
> [!DANGER] إذا كان لديك إصدار مختلف، الرجاء تثبيت الإصدار الموصى به. يمكننا فقط دعم مشاكل التثبيت للإصدارات الموصى بها. راجع [استكشاف الأخطاء](#troubleshooting) للحصول على التفاصيل.
إذا تم بالفعل تثبيت Node.js على جهازك، قم بتشغيل الأوامر التالية للتحقق من صحة الإصدار:
```console
العقدة -v
npm -v
```
> [!TIP] نحن نوصي بشدة بالتحديث إلى أحدث إصدارات ثابتة من البرامج المذكورة أعلاه، والمعروفة أيضًا باسم إصدارات الدعم الطويل الأجل.
بمجرد أن يكون لديك المتطلبات الأساسية مثبتة، تحتاج إلى إعداد بيئة التطوير الخاصة بك. وهذا أمر شائع بالنسبة للعديد من تدفقات العمل التطويري، وسوف تحتاج إلى القيام بذلك مرة واحدة فقط.
**اتبع هذه الخطوات لجعل البيئة التنموية الخاصة بك جاهزة:**
1. قم بتثبيت [Git](https://git-scm.com/) أو عميل Git المفضل لديك، إذا لم تكن قد فعلت ذلك بالفعل. التحديث إلى أحدث إصدار؛ الإصدار الذي تم تجميعه مع نظام التشغيل الخاص بك قد يكون قديما.
2. (اختياري ولكن مستحسن) [إعداد مفتاح SSH](https://help.github.com/articles/generating-an-ssh-key/) لـ GitHub.
3. قم بتثبيت محرر تعليمة برمجية من اختيارك.
نوصي بشدة باستخدام [Visual Studio Code](https://code.visualstudio.com/) أو [Atom](https://atom.io/). هذه محررات برمجية عظيمة ومجانية ومفتوحة المصدر.
4. إعداد سطر لمحرر التعليمات البرمجية الخاص بك.
يجب أن يكون لديك [ESLint قيد التشغيل في محررك](http://eslint.org/docs/user-guide/integrations.html)، وستسلط الضوء على أي شيء لا يتوافق مع [دليل نمط جافا سكريبت في FreCodeCamp](http://forum.freecodecamp.org/t/free-code-camp-javascript-style-guide/19121).
> [تلميح] من فضلك لا تتجاهل أي أخطاء في التنبيه. القصد منها **مساعدتك** وضمان وجود شفرة نظيفة وبسيطة.
## اشترك في المستودع على GitHub
[الطلب](https://help.github.com/articles/about-forks/) هو خطوة حيث تحصل على نسخة خاصة بك من مستودع FreCodeCamp الرئيسي (يعرف أيضا باسم _repo_) على GitHub.
هذا أمر أساسي، لأنه يسمح لك بالعمل على نسختك الخاصة من FreCodeCamp على GitHub، أو لتحميل (استنساخ) مستودعك للعمل محلياً. في وقت لاحق، سوف تكون قادراً على طلب تغييرات لكي يتم سحبها إلى المستودع الرئيسي من الشوك الخاص بك عبر طلب سحب (PR).
> [!TIP] المستودع الرئيسي في `https://github.com/freeCodeCamp/freeCodeCamp` غالبا ما يشار إليه على أنه `مستودع أعلى`.
>
> الشوك الخاص بك في `https://github.com/YOUR_USER_NAME/freeCodeCamp` غالبا ما يشار إليه على أنه مستودع المنشأ ``.
**اتبع هذه الخطوات لتشوه `https://github.com/freeCodeCamp/freeCodeCamp` مستودع:**
1. انتقل إلى مستودع FreCodeCamp على GitHub: <https://github.com/freeCodeCamp/freeCodeCamp>
2. انقر فوق زر "Fork" في الزاوية العلوية اليمنى من الواجهة ([المزيد من التفاصيل هنا](https://help.github.com/articles/fork-a-repo/))
3. بعد أن يتم طلب المستودع، سيتم نقلك إلى نسختك من مستودع freeCodeCamp في `https://github.com/YOUR_USER_NAME/freeCodeCamp`
<details>
<summary>
كيف تشوه رمز المخيم الحرة على GitHub (لقطة شاشة)
</summary>
<br>
<img src="https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/master/docs/images/github/how-to-fork-freeCodeCamp.gif" alt="كيف تشوه معسكر مجاني على GitHub" />
</details>
## استنساخ شوكك من GitHub
[استنساخ](https://help.github.com/articles/cloning-a-repository/) هو المكان الذي تقوم فيه **بتنزيل** نسخة من مستودع من موقع `بعيد` تملكه أو يملكه شخص آخر. في حالتك ، هذا الموقع البعيد هو `فورك` الخاص بك من علبة freeCodeCamp التي يجب أن تكون متاحة على `https://github.com/YOUR_USER_NAME/freeCodeCamp`.
تشغيل هذه الأوامر على جهازك المحلي:
1. فتح المحطة الطرفية / الأوامر الفورية / Shell في دليل مشاريعك
_i..: `/yourprojectsdirectory/`_
2. استنسخ شوكك من FreCodeCamp، واستبدل `YOUR_USER_NAME` باسم مستخدم GitHub الخاص بك
```console
git clone --depth=1 https://github.com/YOUR_USER_NAME/freeCodeCamp.git
```
سيؤدي هذا إلى تحميل مستودع FreCodeCamp بأكمله إلى دليل مشاريعك.
ملاحظة: `--depth=1` ينشئ نسخة ضحلة من فورك، مع فقط أحدث التاريخ/الالتزام.
## إعداد المزامنة من الأصل
الآن بعد أن قمت بتنزيل نسخة من فورك، ستحتاج إلى إعداد `أعلى من` عن بعد إلى المستودع الأصلي.
[كما ذكر سابقاً](#fork-the-repository-on-github)، تم إحالة المستودع الرئيسي `مستودع في مرحلة ما قبل التشغيل`. الشوك الخاص بك مشار إليه على أنه مستودع `الأصل`
تحتاج إلى مرجع من استنساخك المحلية إلى مستودع `أعلى مسار` بالإضافة إلى مستودع `الأصل`. هذا يعني أنك تستطيع مزامنة التغييرات من المستودع الرئيسي دون الحاجة إلى التشيك والاستنساخ بشكل متكرر.
1. تغيير الدليل إلى مجلد freeCodeCamp الجديد:
```console
cd Free CodeCamp
```
2. إضافة مرجع عن بعد إلى مستودع FreCodeCamp الرئيسي:
```console
git قم بإضافة أعلى مجرى https://github.com/freeCodeCamp/freeCodeCamp.git
```
3. تأكد من أن التهيئة تبدو صحيحة:
```console
git البعيد -v
```
يجب أن يبدو المخرجات شيئا كأدناه:
```console
الأصل https://github.com/YOUR_USER_NAME/freeCodeCamp.git (fetch)
الأصل https://github.com/YOUR_USER_NAME/freeCodeCamp.git (push)
أعلى المسار https://github.com/freeCodeCamp/freeCodeCamp.git (fetch)
أعلى المسار https://github.com/freeCodeCamp/freeCodeCamp.git (push)
```
## تشغيل FreCodeCamp محليا
الآن بعد أن كان لديك نسخة محلية من معسكر FreCodep ، يمكنك اتباع هذه التعليمات لتشغيلها محلياً. سيسمح لك هذا بما يلي:
- معاينة التعديلات للصفحات كما ستظهر على منصة التعلم.
- العمل على قضايا واجهة المستخدم والتعزيزات.
- تصحيح الأخطاء وإصلاح المشكلات مع خوادم التطبيق وتطبيقات العميل.
إذا كنت تواجه مشكلات، قم أولاً بإجراء بحث على الويب عن مشكلتك لمعرفة ما إذا كان قد تم الرد عليها بالفعل. إذا لم تتمكن من العثور على حل، الرجاء البحث عن [مشكلات GitHub](https://github.com/freeCodeCamp/freeCodeCamp/issues) للحصول على حل والإبلاغ عن المشكلة إذا لم يتم الإبلاغ عنها بعد.
وكما هو الحال دائما، لا تتردد في الربط مع [مساهمين في غرفة الدردشة على Gitter](https://gitter.im/FreeCodeCamp/Contributors) أو [خادم ديسكورد](https://discord.gg/6vJYm9V)، للاستفسارات السريعة.
> [تلميح] يمكنك تخطي تشغيل FreCodeCamp محليا إذا كنت ببساطة تقوم بتحرير الملفات. على سبيل المثال، إجراء `إعادة قاعدة`أو حل `تنازع الدمج`.
>
> بإمكانك دائماً العودة إلى هذا الجزء من التعليمات في وقت لاحق. يجب عليك **** تخطي هذه الخطوة فقط إذا كنت لا تحتاج إلى تشغيل التطبيقات على جهازك.
>
> [تخطي لإجراء التغييرات](#making-changes-locally).
### تكوين الإعتمادات
#### الخطوة 1: إعداد ملف متغير البيئة
يتم تخزين مفاتيح API الافتراضية ومتغيرات البيئة في الملف `sample.env`. يحتاج هذا الملف إلى نسخ إلى ملف جديد يسمى `.env` الذي يتم الوصول إليه بشكل ديناميكي أثناء خطوة التثبيت.
```console
# إنشاء نسخة من "sample.env" واسمها ".env".
# احضره بمفاتيح API والأسرار اللازمة:
# macOS / Linux
عينة cp nv .env
# Windows
نسخ sample.env .env
```
المفاتيح في ملف `.env` ليست __ مطلوبة للتغيير لتشغيل التطبيق محلياً. يمكنك ترك القيم الافتراضية نسخة من `sample.env` كما هي.
> [!TIP] ضع نصب أعينك إذا كنت تريد استخدام خدمات مثل Auth0 أو Algolia، سوف تحتاج إلى الحصول على مفاتيح API الخاصة بك لهذه الخدمات وتحرير المدخلات تبعاً لذلك في `. nv` ملف
#### الخطوة 2: تثبيت الإعتمادات
سيتم تثبيت هذه الخطوة التبعيات المطلوبة للتطبيق لتشغيل:
```console
npm ci
```
#### الخطوة 3: بدء MongoDB وبذور قاعدة البيانات
قبل أن يكون بإمكانك تشغيل الطلب محلياً، يتوجب عليك البدء في خدمة MongoDB.
> [!NOTE] ما لم يكن لديك MongoDB قيد التشغيل في إعداد مختلف عن الافتراضي، عنوان URL المخزن كقيمة `MONGOHQ_URL` في `. nv` يجب أن يعمل الملف بشكل جيد. إذا كنت تستخدم تكوين مخصص، قم بتعديل هذه القيمة حسب الحاجة.
بدء تشغيل خادم MongoDB في محطة طرفية منفصلة:
- على macOS & Ubuntu:
```console
mongod
```
- على Windows، يجب عليك تحديد المسار الكامل إلى `mongod` الثنائي
```console
"C:\Program files\MongoDB\Server\3.6\bin\mongod"
```
تأكد من استبدال `3.6` بالإصدار الذي قمت بتثبيته
> [تلميح] يمكنك تجنب الحاجة إلى بدء MongoDB في كل مرة عن طريق تثبيته كخدمة خلفية. يمكنك [معرفة المزيد عنها في وثائقها لنظام التشغيل الخاص بك](https://docs.mongodb.com/manual/administration/install-community/)
بعد ذلك، دعونا نؤسس قاعدة البيانات. في هذه الخطوة، نقوم بتشغيل الأمر أدناه الذي يملأ خادم MongoDB ببعض مجموعات البيانات الأولية المطلوبة من الخدمات. وتشمل هذه البرامج عددا قليلا من المخططات، من بين أمور أخرى.
```console
npm تشغيل البذور
```
#### الخطوة 4: بدء تطبيق برنامج FreCodeCamp وخادم API
يمكنك الآن بدء تشغيل خادم API وتطبيقات العميل.
```console
npm قيد التطوير
```
هذا الأمر المنفرد سيطلق جميع الخدمات، بما في ذلك خادم API وتطبيقات العميل المتاحة لك للعمل.
> [!ملاحظة] مرة واحدة، افتح متصفح ويب و **قم بزيارة <http://localhost:8000>**. إذا قام التطبيق بتحميل، تهانينا - أنت معيّن! لديك الآن نسخة من منصة التعلم الخاصة بـ FreCodeCamp تعمل على جهازك المحلي.
> [!TIP] خادم API يخدم APIs في `http://localhost:3000`. تطبيق Gatsby يخدم تطبيق العميل في `http://localhost:8000`
> إذا قمت بزيارة <http://localhost:3000/explorer> يجب أن ترى APIs المتاحة.
## تسجيل الدخول باستخدام مستخدم محلي
الإعداد المحلي الخاص بك يقوم تلقائياً بتجميع مستخدم محلي في قاعدة البيانات. الضغط على زر `تسجيل الدخول` سيصادقك تلقائياً في التطبيق المحلي.
ومع ذلك، فإن الوصول إلى صفحة حافظة المستعملين أمر صعب بعض الشيء. في مرحلة التطوير، Gatsby يتسلم خدمة صفحات العملاء وبالتالي ستحصل على صفحة `404` لحافظة المستخدم عند العمل محليا.
ببساطة النقر على زر **"معاينة الصفحة 404"** سيتم توجيهك إلى الصفحة الصحيحة.
<details>
<summary>
كيفية تسجيل الدخول عند العمل محليا (لقطة الشاشة)
</summary>
<br>
<img src="https://user-images.githubusercontent.com/29990697/71541249-f63cdf00-2923-11ea-8a85-cefb6f9c9977.gif" alt="كيفية تسجيل الدخول عند العمل محليا" />
</details>
## إجراء التغييرات محليا
يمكنك الآن إجراء تغييرات على الملفات وإلزام بتغييراتك على النسخة المحلية من الشوك.
اتبع هذه الخطوات:
1. التحقق من أنك في فرع `الرئيسي`:
```console
git status
```
يجب أن تحصل على ناتج مثل هذا:
```console
في سيد الفرع
فرعك محدث بـ 'الأصلي/الماجستير'.
لا شيء للالتزام، دليل العمل تنظيف
```
إذا لم تكن على رأس أو أن دليل العمل الخاص بك غير نظيف، قم بحل أي ملفات/التزامات معلقة وسحب `الرئيسي`:
```console
سيد عملية الدفع
```
2. مزامنة أحدث التغييرات من فرع FreCodeCamp upstream `الرئيسي` إلى الفرع الرئيسي المحلي الخاص بك:
> [تحذير] إذا كان لديك أي طلب سحب معلق قمت به من فرع `الأستاذ` في فورمك، سوف تفقدهم في نهاية هذه الخطوة.
>
> يجب عليك التأكد من دمج طلب السحب الخاص بك من قبل مشرف قبل تنفيذ هذه الخطوة. لتجنب هذا السيناريو، يجب عليك **دائمًا** العمل على فرع غير `الرئيسي`.
هذه الخطوة **ستقوم بمزامنة أحدث التغييرات** من المستودع الرئيسي لـ freeCodeCamp. من المهم أن تقوم بإعادة بناء فرعك على قمة أحدث `برتقال/رشد` في أغلب الأحيان لتجنب التضارب لاحقاً.
قم بتحديث نسختك المحلية من مستودع FreCodeCamp في أعلى مجال:
```console
Git يجلب أعلى مجرى
```
قم بإعادة تعيين فرعك الرئيسي مع سيد رمز المخيم:
```console
إعادة تعيين git - أعلى التدفق/إتقان
```
دفع فرعك الرئيسي إلى منشئك للحصول على تاريخ نظيف على الشوك الخاص بك على GitHub:
```console
Git دفع الأصل الرئيسي - القوة
```
يمكنك التحقق من مطابقتك الرئيسية الحالية للتبسيط/الأستاذ عن طريق أداء مختلف:
```console
Git تقطع في واجهة التدفق/إتقان
```
وينبغي أن يكون الناتج الناتج الناتج فارغاً.
3. إنشاء فرع جديد جديد:
العمل على فرع منفصل لكل مشكلة يساعدك في الحفاظ على نسخة عملك المحلي نظيفة. يجب ألا تعمل أبدا على `سيد`. سيؤدي هذا إلى تربة نسختك من CodeCamp وقد تضطر إلى البدء باستنساخ جديد أو شوك.
تحقق من أنك على `سيد` كما تم شرحه سابقاً، والفرع من هناك:
```console
git الدفع -b إصلاح/تحديث الدليل-لxyz
```
يجب أن يبدأ اسم فرعك بـ `إصلاح/`، `الميزة /`، `docs/`، إلخ. تجنب استخدام أرقام المشاكل في الفروع. ابقائها قصيرة ومفيدة وفريدة.
وفيما يلي بعض الأمثلة على أسماء الفروع الجيدة:
```md
إصلاح/update-Challenes-for-react
fix/update-guide-for-html-css
fix/platform-bug-sign-issues
feat/add-guide-article-for-javascript
translate/add-spanish-basic-html
```
4. تحرير الصفحات والعمل على التعليمات البرمجية في محرر النص المفضل لديك.
5. بمجرد أن تكون سعيدا بالتغييرات يجب عليك اختياريا تشغيل FreCodeCamp محليا لمعاينة التغييرات.
6. تأكد من إصلاح أي أخطاء والتحقق من تنسيق التغييرات الخاصة بك.
7. تحقق من الملفات التي تقوم بتحديثها وتأكيدها:
```console
git status
```
يجب أن يظهر هذا قائمة من الملفات `غير مهيأة` التي قمت بتعديلها.
```console
على الميزة/التوثيق الفرعي
فرعك محدث مع 'upstream/feat/documentation'.
التغييرات غير معدة للالتزام:
(استخدم "git add/rm <file>... لتحديث ما سيتم الالتزام به)
(استخدم "git Checout -- <file>. " لاستبعاد التغييرات في دليل العمل)
معدل: المواصلات. (د)
معدلة: docs/README.md
معدلة: docs/how-to-setup-freecodecamp-محليا. (د)
معدلة: docs/howto-work-on-guide-articles.md
...
```
8. مرحلة التغييرات والتعهد بما يلي:
في هذه الخطوة، يجب عليك فقط وضع علامة على الملفات التي قمت بتعديلها أو إضافتها بنفسك. يمكنك إجراء إعادة تعيين وحل الملفات التي لم تكن تنوي تغييرها إذا لزم الأمر.
```console
git اضف المسار/إلى/my/changed/file.ext
```
أو يمكنك إضافة جميع ملفات `غير مهيأة` إلى منطقة التجهيز:
```console
git يضاف
```
فقط الملفات التي تم نقلها إلى منطقة التجهيز سيتم إضافتها عندما تقوم بالالتزام.
```console
git status
```
الناتج:
```console
على الميزة/التوثيق الفرعي
فرعك محدث مع 'upstream/feat/documentation'.
التغييرات التي سيتم الالتزام بها:
(استخدم "git reset HEAD <file>..." لإلغاء المرحلة)
معدلة: CONTRIBUTING.md
معدل: docs/README.md
معدلة: docs/how-to-setup-freecodecamp-locally.md
معدل: docs/howto-work-on-guide-articles.md
```
الآن، يمكنك إجراء التغييرات الخاصة بك برسالة قصيرة مثل هذا:
```console
git الالتزام -m "إصلاح: رسالة الالتزام القصيرة"
```
بعض الأمثلة:
```md
إصلاح: تحديث مقالة دليل جافا - لميزة حلقة
: إضافة مقالة دليل لمهارات ألكسا
```
اختياري:
ونحن نوصي بشدة بتوجيه رسالة التزام تقليدية. هذه ممارسة جيدة سوف تراها في بعض مستودعات المصادر المفتوحة الشائعة. كمطور، هذا يشجعك على اتباع الممارسات القياسية.
وفيما يلي بعض الأمثلة على رسائل الالتزام التقليدية:
```md
إصلاح: تحديث مقالة دليل HTML
إصلاح: تحديث نسخة البرامج النصية لبناء خاصية Tra/5/Add.CI
: إضافة مقالة لتحميل JavaScript
docs: تحديث المبادئ التوجيهية المساهمة
```
حافظ على هذه الأحرف القصيرة، لا أكثر من 50 حرفاً. يمكنك دائماً إضافة معلومات إضافية في وصف رسالة الالتزام.
هذا لا يستغرق أي وقت إضافي من رسالة غير تقليدية مثل 'تحديث الملف' أو 'إضافة index.md'
يمكنك معرفة المزيد حول لماذا يجب عليك استخدام الإلتزامات التقليدية [هنا](https://www.conventionalcommits.org/en/v1.0.0-beta.2/#why-use-conventional-commits).
9. إذا أدركت أنك بحاجة إلى تعديل ملف أو تحديث رسالة الالتزام بعد التعهد يمكنك القيام بذلك بعد تعديل الملفات مع:
```console
git ملتزمة--تعديل
```
سيؤدي هذا إلى فتح محرر نص افتراضي مثل `nano` أو `vi` حيث يمكنك تعديل عنوان رسالة الالتزام وإضافة/تحرير الوصف.
10. بعد ذلك، يمكنك دفع التغييرات الخاصة بك إلى الشوك:
```console
git دفع الأصل/فرع/اسم هنا
```
## اقتراح طلب سحب (PR)
بعد إجراء التغييرات الخاصة بك، تحقق هنا من [كيفية فتح طلب السحب](how-to-open-a-pull-request.md).
## مرجع الأوامر السريعة
مرجع سريع للأوامر التي ستحتاج إليها عند العمل محلياً.
| أمر | الوصف |
| ---------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| `npm ci` | تثبيت / إعادة تثبيت جميع التبعيات و التمهيدات، مختلف الخدمات. |
| `npm تشغيل البذور` | يقوم بتحليل جميع ملفات الـ markdown التحدي وإدراجها في MongoDB. |
| `npm قيد التطوير` | يبدأ تشغيل خادم API و تطبيقات العميل الخاص بـ FreCodeCamp |
| `npm اختبار` | تشغيل جميع اختبارات JS في النظام، بما في ذلك اختبارات العملاء والخادم والخط الخطي والتحديات. |
| `npm قم بتشغيل الاختبار:client` | تشغيل مجموعة اختبار العميل. |
| `npm تشغيل الاختبار:منهج دراسي` | تشغيل مجموعة اختبار المناهج الدراسية. |
| `npm قم بتشغيل الاختبار:منهج --block='HTML الأساسي و HTML5'` | اختبر كتلة محددة. |
| `npm قم بتشغيل الاختبار:منهج --superblock='responve-web-design'` | اختبر بلوك سوبر بلوك محدد. |
| `npm تشغيل اختبار المنهج الدراسي الكامل` | تشغيل مجموعة اختبار المنهج، دون الإنقاذ بعد الخطأ الأول |
| `npm قم بتشغيل الاختبار:server` | تشغيل جناح اختبار الخادم. |
| `npm تشغيل e2e` | تشغيل نهاية Cypress إلى اختبارات النهاية. |
| `npm تشغيل التنظيف` | إلغاء تثبيت جميع التبعيات وتنظيف المخبآت. |
## استكشاف الأخطاء
### مشاكل في تثبيت الشروط المسبقة الموصى بها
نقوم بانتظام بتطوير أحدث نظم التشغيل أو أكثرها شعبية مثل MacOS 10.15 أو أكثر، أو Ubuntu 18.04 أو بعدها و Windows 10 (مع WSL2).
من المستحسن البحث في مشكلتك المحددة حول الموارد مثل جوجل، ستراك أفلاك، بورصة البورصة. هناك فرصة جيدة لأن يواجه شخص ما نفس المشكلة وهناك بالفعل إجابة على استفسارك المحدد.
إذا كنت على نظام تشغيل مختلف و/أو لا تزال تواجه مشكلات، راجع [الحصول على المساعدة](#getting-help).
> [تحذير]
>
> الرجاء تجنب إنشاء مشاكل GitHub للمشكلات الأساسية. وهي خارج نطاق هذا المشروع.
### مشكلات مع واجهة المستخدم، الخطوط، أخطاء البناء إلخ.
إذا واجهت مشاكل مع واجهة المستخدم، خطوط أو شاهد أخطاء في الإنشاءات، يمكن أن يكون التنظيف مفيداً:
```console
npm تشغيل نظيف
npm ci
npm تشغيل بذرة
npm قيد التطوير
```
أو
استخدام الاختصار
```
npm تشغيل نظيف وتطوير
```
إذا استمرت في مواجهة المشكلات مع البناء، فينصح بتنظيف مساحة العمل.
استخدم `git Cle` في الوضع التداخلي:
```
git Cle-ifdX
```
<details>
<summary>
كيفية تنظيف الملفات الغير متعقبة (لقطة شاشة)
</summary>
<br>
<img src="https://user-images.githubusercontent.com/1884376/94270515-ca579400-ff5d-11ea-8ff1-152cade31654.gif" alt="كيفية تنظيف الملفات git الغير متعقبة" />
</details>
### مشكلات مع API، تسجيل الدخول، عروض التحدي، إلخ.
إذا لم تتمكن من تسجيل الدخول، وبدلا من ذلك سترى لافتة تحمل رسالة خطأ بأنه سيتم الإبلاغ عنها في معسكر FreCode، الرجاء التحقق مرتين من أن المنفذ المحلي الخاص بك `3000` غير مستخدم من قبل برنامج مختلف.
**على Linux / macOS / WSL على Windows - من المحطة الطرفية:**
```console
netstat -ab <unk> grep "3000"
tcp4 0 0.0.0.0:3000 DESKTOP LISTEN
```
**على Windows - من قوة عالية :**
```powershell
netstat -ab <unk> Select-String "3000"
TCP 0.0.0:3000 DESKTOP LSTENING
```
### مشكلات تثبيت الإعتمادات
إذا حصلت على أخطاء أثناء تثبيت التبعيات، الرجاء التأكد من أنك لست في شبكة مقيدة أو أن إعدادات جدار الحماية الخاص بك لا تمنعك من الوصول إلى الموارد.
أول مرة يمكن أن يستغرق فيها الإعداد بعض الوقت اعتماداً على عرض النطاق الترددي لشبكتك. كن صبورا، وإذا كنت مازلت عالقة قمنا بإستخدام GitPod بدلاً من إعداد غير متصل.
## الحصول على المساعدة
إذا كنت عالقا وتحتاج إلى مساعدة، دعنا نعرف عن طريق السؤال في فئة ['المساهمين' في المنتدى](https://forum.freecodecamp.org/c/contributors) أو [غرفة الدردشة المساهمين](https://gitter.im/FreeCodeCamp/Contributors) على Gitter.
قد يكون هناك خطأ في وحدة التحكم في المتصفح الخاص بك أو في Bash / المحطة الطرفية / سطر الأوامر الذي سيساعد على تحديد المشكلة. قم بتوفير رسالة الخطأ هذه في وصف المشكلة الخاص بك حتى يتمكن الآخرون من تحديد المشكلة بسهولة أكبر ومساعدتك في العثور على حل.

129
docs/i18n/Arabic/how-to-setup-wsl.md Normal file
View File

@ -0,0 +1,129 @@
# إنشاء FreCodeCamp على نظام ويندوز الفرعي للينوكس (WSL)
> [!ملاحظة] قبل أن تتبع هذه التعليمات تأكد من أن النظام الخاص بك يفي بالمتطلبات
>
> **WSL 2**: Windows 10 64-bit (الإصدار 2004، البناء 19041 أو أعلى) - متاح لجميع التوزيعات بما في ذلك Windows 10 Home.
>
> **Docker سطح المكتب للويندوز**: انظر المتطلبات ذات الصلة لـ [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)
ويغطي هذا الدليل بعض الخطوات الشائعة مع إعداد WSL2. حالما تعالج بعض القضايا المشتركة مع مؤتمر القمة العالمي الثاني المعني بمجتمع المعلومات، يجب أن تكون قادراً على متابعة دليل الإعداد المحلي الخاص بنا للعمل مع FreCodeCamp على ويندوز الذي يقوم بتشغيل شريط WSL مثل Ubuntu.
## تمكين WSL
اتبع الإرشادات في [الوثائق الرسمية](https://docs.microsoft.com/en-us/windows/wsl/install-win10) لتثبيت WSL1 ثم الترقية إلى WSL2.
## Install Ubuntu
1. لقد أوصينا باستخدام Ubuntu-18.04 أو أكثر مع WSL2.
> [!ملاحظة]
>
> بينما يمكنك استخدام الأقراص الأخرى غير الديدية، كلها تأتي مع الغوغتشات الخاصة بها وهي خارج نطاق هذا الدليل.
2. تحديث الإعتمادات لنظام التشغيل
```console
قم بتحديث sudo apt
sudo apt upd-y
# تنظيف
sudo apt autoremove -y
```
## إعداد Git
يأتي Git مثبتًا مسبقًا مع Ubuntu 18.04، تحقق من أن إصدار Git الخاص بك مع `git --version`.
```output
~
<unk> git --version
git الإصدار 2.25.1
```
(اختياري ولكن مستحسن) يمكنك الآن المضي قدما [في إعداد مفاتيح ssh](https://help.github.com/articles/generating-an-ssh-key) مع GitHub.
## تثبيت محرر التعليمات البرمجية
نوصي بشدة بتثبيت [Visual Studio Code](https://code.visualstudio.com) على Windows 10. لديها دعم كبير لـ WSL وتثبيت تلقائياً جميع الإضافات الضرورية على ذاكرة WSL الخاص بك.
بشكل أساسي، سوف تقوم بتعديل وتخزين التعليمات البرمجية الخاصة بك على Ubuntu-18.04 مع تثبيت رمز VS على Windows.
## تثبيت دوكر سطح المكتب
**سطح المكتب الخاص بـ Docker Windows** يسمح لك بتثبيت وتشغيل قاعدة البيانات والخدمات مثل MongoDB, NGINX, الخ. وهذا مفيد لتجنب المآزق المشتركة مع تثبيت MongoDB أو خدمات أخرى مباشرة على Windows أو WSL2.
اتبع دورة التعليمات على [الوثائق الرسمية](https://docs.docker.com/docker-for-windows/install) وقم بتثبيت دوكر سطح المكتب لتوزيع ويندوز الخاص بك.
هناك بعض المتطلبات الدنيا من المعدات لأفضل التجربة.
## تكوين سطح المكتب الخاص بـ Docker لـ WSL
بمجرد تثبيت سطح المكتب Docker ، [اتبع هذه التعليمات](https://docs.docker.com/docker-for-windows/wsl) وتهيئته لاستخدام تثبيت Ubuntu-18.04 كخلفية للنظام.
وهذا يجعل من الممكن تشغيل الحاويات على جانب WSL بدلا من تشغيلها على Windows. ستتمكن من الوصول إلى الخدمات عبر `http://localhost` على كل من Windows و Ubuntu.
## تثبيت MongoDB من Docker Hub
بمجرد تكوين سطح المكتب الخاص بـ Docker للعمل مع WSL2، اتبع هذه الخطوات لبدء خدمة MongoDB:
1. تشغيل محطة Ubuntu-18.04 جديدة
2. سحب `MongoDB 3.6` من Dockerhub
```console
docker pull mongo:3
```
3. بدء خدمة MongoDB في المنفذ `27017`، وتهيئتها لتشغيلها تلقائيا عند إعادة تشغيل النظام
```console
docker تشغيل -it \
-v mongodata:/data/db \
-p 27017:27017 \
--name mongodb \
--إعادة تشغيل بدون توقف \
-d Mongo:3
```
4. يمكنك الآن الوصول إلى الخدمة من Windows أو Ubuntu على `mongodb://localhost:27017`.
## تثبيت Node.js و npm
ننصحك بتثبيت إصدار LTS لـ Node.js مع مدير إصدار العقدة - [nvm](https://github.com/nvm-sh/nvm#installing-and-updating).
بمجرد تثبيت هذه الأوامر لتثبيت واستخدام إصدار Node.js حسب الحاجة
```console
تثبيت nvm --lts
# OR
# nvm install <version>
nvm install 14
# Usage
# nvm use <version>
nvm يستخدم 12
```
Node.js تأتي مجمعة مع `npm`، يمكنك التحديث إلى أحدث إصدارات `npm` مع:
```console
npm تثبيت -g npm@latest
```
## إعداد FreCodeCamp محليا
الآن بعد أن قمت بتثبيت المتطلبات المسبقة، اتبع [دليل الإعداد المحلي الخاص بنا](https://contribute.freecodecamp.org/#/how-to-setup-freecodecamp-locally) لاستنساخ وتثبيت وإعداد FreCodeCamp محليا على جهازك.
> [تحذير]
>
> يرجى ملاحظة أن الإعداد لاختبارات Cypress (وما يتصل بها من احتياجات واجهة المستخدمين) هو عمل جاري. يجب أن تكون قادراً على العمل في معظم الكود البرمجي.
## روابط مفيدة
- [إعداد WSL2 Dev مع Ubuntu 20.04, Node.js, MongoDB, VS Code و Docker](https://devlog.sh/wsl2-dev-setup-with-ubuntu-nodejs-mongodb-and-docker) - مقال من Mrugesh Mohapatra (مطور تاف على freeCodeCamp.org)
- الأسئلة المتكررة عن:
- [نظام Windows الفرعي لـ Linux](https://docs.microsoft.com/en-us/windows/wsl/faq)
- [دوكر سطح المكتب للويندوز](https://docs.docker.com/docker-for-windows/faqs)

15
docs/i18n/Arabic/how-to-use-docker-on-windows-home.md Normal file
View File

@ -0,0 +1,15 @@
# كيفية استخدام Docker على Windows Home
هناك بعض الخلل التي يجب تجنبها عند إعداد جهاز الإرسال على Windows Home. أولاً يجب عليك استخدام [صندوق أدوات Docker](https://docs.docker.com/toolbox/toolbox_install_windows/) كمدير. لسوء الحظ لا يدعم Windows Home Docker لنظام Windows Desktop، لذا يجب استخدام علبة الأدوات بدلاً من ذلك. ويجب تشغيله كمدير لأن التركيب يستخدم روابط رمزية، لا يمكن إنشاؤها بخلاف ذلك.
بمجرد تثبيت صندوق الأدوات، قم بتشغيل Docker Quickstart Terminal كمسؤول. سيؤدي هذا إلى إنشاء `آلة افتراضية` إذا لم تكن موجودة بالفعل. وبمجرد حدوث ذلك، أغلق المحطة الطرفية وفتح علبة الافتراضي (مرة أخرى كمدير). يجب أن تكون قادراً على رؤية جهاز `الافتراضي`. الموقع كثيف الموارد، لذلك أوقف الجهاز الافتراضي وارفع من الإعدادات قدر استطاعتك - الذاكرة على وجه الخصوص. وقد تأكد أنه يعمل مع 4 جيغابايت من الرام.
بمجرد أن تكون سعيدا لأن Docker يعمل، استنسخ مستودع FreCodeCamp إلى دليل داخل `C:\Users`. يتم مشاركة هذه الدلائل لمنح دوكر الوصول إلى الدلائل المحلية، والتي تحتاج إليها أثناء التثبيت.
إذا رأيت رسائل مثل
```shell
باش: change_volumes_owner.sh: لا يوجد مثل هذا الملف أو الدليل
```
عندما تقوم بتشغيل docker:init `npm` فمن المرجح أن يكون هذا هو المذنب.

543
docs/i18n/Arabic/how-to-work-on-coding-challenges.md Normal file
View File

@ -0,0 +1,543 @@
# كيفية العمل على تحديات البرمجة
هدفنا هو تطوير تجربة تعلم تفاعلية ممتعة وواضحة.
وتصميم تحديات البرمجة التفاعلية أمر صعب. سيكون من الأسهل بكثير كتابة شرح طويل أو إنشاء دروس فيديو، وهناك مكان للذين على موقع متوسط و يوتيوب. لكن، بالنسبة لمنهجنا الأساسي، نحن ملتزمون بما يصلح لمعظم الناس - تجربة تفاعلية تماما وشبه تجربة لعبة الفيديو.
نريد أن تحقق الكاميرات حالة التدفق. ونريد منهم أن يبنوا زخما وأن ينفجروا من خلال منهجنا الدراسي بأقل عدد ممكن من الزجاج. ونريد لهم أن يدخلوا في المشاريع بثقة وأن يتعرفوا على نطاق واسع على مفاهيم البرمجة.
ويتطلب خلق هذه التحديات إبداعا هائلا واهتماما بالتفاصيل. هناك الكثير من المساعدة المتاحة. ستحصل على دعم من فريق كامل من المساهمين الذين يمكنك أن ترتدي أفكارك وتجريب تحدياتك. ابقى نشطا في [غرفة المساهمين](https://gitter.im/freecodecamp/contributors) واطرح الكثير من الأسئلة.
بمساعدتك يمكننا تصميم منهج تعليمي تفاعلي سوف يساعد ملايين الناس على تعلم البرمجة لسنوات قادمة.
يتم تخزين محتوى كل تحدي في ملف markdown الخاص به. يتم تحويل هذا الملف في وقت لاحق إلى HTML باستخدام أدواتنا لإنشاء صفحات ويب تفاعلية.
يمكنك العثور على كل محتوى المنهج الدراسي لـ freeCodeCamp.org's في دليل [`/curriculum/challenges`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges).
## إعداد أدوات المنهج الدراسي
قبل أن تعمل على المناهج الدراسية، ستحتاج إلى إعداد بعض الأدوات لمساعدتك على اختبار التغييرات الخاصة بك. يمكنك استخدام أي خيار من الأسفل:
- يمكنك [إعداد FreCodeCamp محليا](how-to-setup-freecodecamp-locally.md). هذه **موصى بها بشدة** للمساهمات العادية/المتكررة. هذا الإعداد يسمح لك بالعمل واختبار التغييرات الخاصة بك.
- استخدام Gitpod، بيئة ديف مجانية على الإنترنت. النقر على الزر أدناه سيبدأ بيئة dev جاهزة للبرمجة الحرة في المتصفح الخاص بك. ويستغرق الأمر بضع دقائق فقط.
[![فتح في Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
- تعديل الملفات على واجهة GitHub، بالنقر على أيقونة قلم الرصاص للملف المقابل. في حين أن هذا هو أسرع طريقة، فإنه **غير مستحسن**، لأنك غير قادر على اختبار التغييرات الخاصة بك على GitHub. إذا خلص المشرفون لدينا إلى أن التغييرات التي أجريتها تحتاج إلى أن تختبر محلياً، سوف تحتاج إلى اتباع الأساليب أعلاه بدلاً من ذلك مرة أخرى.
## قالب التحدي
فيما يلي قالب لماهية التحديات التي تبدو عليها ملفات الدرجات السفلى حاليا. لمشاهدة القالب المبسط سنعتمد [أنظر أدناه](#upcoming-challenge-template).
````md
---
المعرف: معرف فريد (أبجدي رقمي, MongoDB_id)
العنوان: عنوان التحدي
تحدي: 0
فيديوورل: 'رابط تفسير الفيديو'
---
## وصف
<section id='description'>
وصف للتحدي وما هو مطلوب لتمرير
</section>
## تعليمات
<section id='instructions'>
تعليمات حول ما يجب القيام به بالضبط.
</section>
## اختبارات
<section id='tests'>
```ml
اختبار:
- نص: يجب أن يعيد "foo'
اختبار String: 'دالة سلسلة ربما باستخدام تأكيد تشاي'
````
</section>
## بذرة التحدي
<section id='challengeSeed'>
<div id='{ext}-seed'>
```{ext}
الكود المعروض في المحرر بشكل افتراضي.
وهذا جزء مطلوب لهذا التحدي.
```
</div>
### قبل الاختبار
<div id='{ext}-setup'>
```{ext}
رمز اختبار اختياري.
```
</div>
### بعد الاختبار
<div id='{ext}-teardown'>
```{ext}
اختبار اختياري لتمزيق التعليمات البرمجية.
```
</div>
</section>
## حل
<section id='solution'>
```{ext}
// الحل مطلوب
```
</section>
````
> [!NOTE]
>
> 1. في الفروع الواردة أعلاه، أمثلة على `{ext}` هي:
>
> - `html` - HTML/CSS
> - `js` - JavaScript
> - `jsx` - JSX
>
> 2. بالنسبة لقسم `الاختبارات` أعلاه، ينبغي أن تكون `text` و`testString` سلاسل YAML صالحة. 'testString' يمكن أن تكون دالة أو تعبير متسلسل يمكن أن تستخدم مزاعم تشاي.
## تحديات الترقيم
كل تحد يحتاج إلى `معرف`. إذا لم تحدد واحداً، سيقوم MongoDB بإنشاء واحد عشوائي جديد عندما يحفظ البيانات؛ ومع ذلك، نحن لا نريد أن نفعل ذلك، لأننا نريد أن تكون معارف التحدي متسقة عبر بيئات مختلفة (الإنتخابات التدريجية)، الإنتاج والكثير من المطورين المختلفين، إلخ.).
لإنشاء واحدة جديدة في قذيفة (بافتراض أن MongoDB يعمل بشكل منفصل):
1. تشغيل الأمر `mongo'.
2. تشغيل الأمر `objectId()'.
على سبيل المثال:
```bash
$ mongo
MongoDB Shell version v3.6.1
يتصل بـ: mongodb://127.0.0.1:27017
MongoDB Sersion: 3.4.10
...
$ ObjectId()
ObjectId("5a474d78df58bafeb3535d34")
````
النتيجة هي معد جديد، على سبيل المثال `5a474d78df58bafeb3535d34` أعلاه.
بمجرد أن يكون لديك بريدك، وضعه في ملف markdown كحقل `معرف` في الأعلى، على سبيل المثال.
```yml
---
المعرف: 5a474d78df58bafeb3535d34
عنوان: عنوان التحدي
```
## تحديات التسمية
تسمية الأشياء أمر صعب. لقد جعلنا الأمر أسهل من خلال فرض بعض القيود.
يجب أن تكون جميع عناوين التحدي صريحة ويجب أن تتبع هذا النمط:
\[verb\]\[شرط الكائن\]
فيما يلي بعض أسماء التحديات :
- استخدام التدوين على مدار الساعة لتحديد تعبئة العنصر
- مصفوفات مكثفة مع .خفض
- استخدم رمز مجموعة للعثور على الشخصية الأولى في سلسلة
## أوصاف/تعليمات التحدي
يجب أن تكون العقوبات واضحة وموجزة مع الحد الأدنى من الجرذون. وفي حالة استخدامها، ينبغي تعريف الجارجون فوراً باللغة الإنكليزية الواضحة.
إبقاء الفقرات قصيرة (نحو 1-4 جملة). ومن المرجح أن يقرأ الناس عدة فقرات قصيرة أكثر مما يقرأ جدارا للنص.
نص التحدي يجب أن يستخدم الشخص الثاني ("أنت") للمساعدة في إعطائه صوت محادثة. وبهذه الطريقة يبدو أن النص والتعليمات تتحدث مباشرة إلى كاميرا تعمل من خلال التحدي. حاول تجنب استخدام الشخص الأول ("I", "we", "let's", and "us").
لا تستخدم الروابط الصادرة. وهي تعرقل التدفق. وينبغي ألا يضطر كاميرون أبداً إلى إخفاء أي شيء خلال هذه التحديات. إذا كانت هناك موارد تعتقد أن كاميرات ستستفيد منها، فتضيفها إلى المقالة المتعلقة بالدليل الخاص بالطعن.
يمكنك إضافة رسوم بيانية إذا كان ذلك ضرورياً.
لا تستخدم الرموز التعبيرية أو الرموز التعبيرية في التحديات. FreCodeCamp لديه مجتمع عالمي، والمعنى الثقافي للرموز التعبيرية أو الانفعالية قد يكون مختلفا حول العالم. أيضًا، الرموز التعبيرية يمكن أن تكون مختلفة في أنظمة مختلفة.
الأسماء المناسبة يجب أن تستخدم الرسملة الصحيحة عندما يكون ذلك ممكنا. وترد أدناه قائمة بالكلمات التي ينبغي أن تظهر في التحديات.
- JavaScript (الأحرف الكبيرة في "J" و "S" و لا اختصار)
- Node.js
- تطوير الطرف الأمامي (شكل الصفة مع الشرطة) عندما تعمل على الطرف الأمامي (شكل اسم بدون شرطة). وينطبق نفس الشيء على "الطرف الخلفي" و"المكدس الكامل" والعديد من المصطلحات المركبة الأخرى.
### قاعدة دقيقتين
وينبغي أن يكون كل تحد قابلا للحل في غضون 120 ثانية بواسطة متحدث إنكليزي أصلي أكمل التحديات التي أدت إليه. هذا يشمل الوقت الذي يستغرقه قراءة الاتجاهات/التعليمات التي تفهم رمز البذر، اكتب التعليمات البرمجية الخاصة بهم واحصل على جميع الاختبارات لتمريرها.
إذا استغرق إكمال التحدي أكثر من دقيقتين، فلديك خياران:
- تبسيط التحدي، أو
- تقسيم التحدي إلى تحديين.
قاعدة دقيقتين تجبرك ، مصمم التحدي ، على جعل توجيهاتك موجزة، رمز البذور الخاص بك واضحة، واختبارك واضح.
نحن نتعقب الوقت الذي تستغرقه الكاميرات لحل التغييرات واستخدام هذه المعلومات لتحديد التحديات التي تحتاج إلى التبسيط أو التقسيم.
### الوحدة
وينبغي لكل تحد أن يدرس مفهوما واحدا بالضبط، وينبغي أن يكون هذا المفهوم واضحا من اسم التحدي.
يمكننا تعزيز المفاهيم التي سبق تغطيتها من خلال التكرار والتغييرات - على سبيل المثال، • إدخال عناصر h1 في تحد واحد، ثم عناصر h3 في وقت لاحق.
وهدفنا هو أن نواجه الآلاف من التحديات لمدة دقيقتين. ويمكن أن تتدفق هذه المفاهيم معا وتكرر تأكيد المفاهيم التي كانت مشمولة سابقا.
### تنسيق نص التحدي
وفيما يلي مبادئ توجيهية محددة بشأن التنسيق للنص الخاص بالتحدي والأمثلة:
- كلمات اللغة الرئيسية تدخل في `<code>` العلامات. على سبيل المثال، أسماء علامات HTML أو أسماء خصائص CSS
- المثيل الأول لكلمة مفتاحية عند تعريفها، أو الكلمات المفتاحية العامة (أي "الكائن" أو "الثابت") تذهب إلى `<dfn>` العلامات
- الإشارات إلى أجزاء التعليمات البرمجية (أي الدالة أو الطريقة أو أسماء المتغير) ينبغي تغليفها في `<code>` العلامات. انظر المثال أدناه:
- استخدم <code>parseInt</code> لتحويل المتغير <code>الواقع رقم</code> إلى عدد صحيح.
- يجب أن يسبق كتل التعليمات البرمجية متعددة الأسطر **سطر فارغ**. يجب أن يبدأ السطر التالي بثلاث خلفيات يعقبها مباشرة واحدة من [اللغات المدعومة](https://prismjs.com/#supported-languages). لإكمال كتلة التعليمات البرمجية، يجب عليك بدء سطر جديد يحتوي فقط على ثلاث خلفيات و **سطر فارغ آخر**. **ملاحظة:** إذا كنت ستستخدم رمز مثال في YAML ، استخدم `yaml` بدلاً من `yml` للغة إلى يمين الخلف.
انظر المثال أدناه:
````md
فيما يلي مثال على التعليمة البرمجية:
```{language}
[YOUR CODE HERE]
````
````
- ينبغي تنسيق معلومات إضافية في شكل ملاحظة `<strong>ملاحظة:</strong> استعرض نص الملاحظة...
- إذا كانت هناك حاجة إلى ملاحظات متعددة، ثم قم بقائمة جميع الملاحظات في جمل منفصلة باستخدام تنسيق `<strong>الملاحظات:</strong> نص الملاحظة الأولى. الحاشية الثانية نص.`.
- استخدام عبارات اقتباس مزدوجة حيث ينطبق
## اختبار الكتابة
يجب أن تحتوي التحديات على الحد الأدنى من الاختبارات اللازمة للتحقق من أن الكاميرا يفهم مفهوما.
وهدفنا هو الإبلاغ عن النقطة الوحيدة التي يحاول التحدي تعليمها، واختبار أنهم فهموا تلك النقطة.
يمكن أن تستخدم اختبارات التحدي مكتبات تأكيد Node.js و Chai.js. أيضًا، إذا لزم الأمر، يمكن الوصول إلى التعليمات البرمجية التي ينشئها المستخدم في متغير "الكود".
## تنسيق رمز البذور
إليك مبادئ توجيهية محددة لتنسيق رمز البذور التحدي:
- استخدم مسافتين لدخول
- بيانات جافا سكريبت تنتهي بفاصلة منها
- استخدم اقتباسات مزدوجة حيثما ينطبق
- التعليقات التي تم الإدلاء بها يجب أن يكون لها مساحة بين أحرف التعليق والتعليق نفسه
`// اصلاح هذا السطر`
## تلميحات وحلول
لكل تحد زر 'احصل على تلميح`، حتى يتمكن المستخدم من الوصول إلى أي تلميحات/حلول تم إنشاؤها للتحدي. توجد مواضيع تلميح/حلول المناهج الدراسية في [منتدانا] (https://forum.freecodecamp.org/c/guide) تحت فئة `الدليل'.
إذا وجدت مشكلة مع موضوع تلميح/حلول التحدي القائم، يمكنك تقديم اقتراحات في [فئة المساهمين] (https://forum.freecodecamp.org/c/contributors) في المنتدى. وسيقوم المشرفون والمستعملون ذوو المستوى 3 باستعراض التعليقات ويقررون ما إذا كانوا سيدرجون التغييرات في موضوع التلميح/الحلول المقابل.
### إضافة تلميحات/مواضيع جديدة للتحدي
اتخاذ الخطوات التالية عند إضافة تلميحات/حلول جديدة للتحدي.
1. ابدأ باتباع نفس الخطوات لإنشاء موضوع جديد ولكن راجع التالي لإنشاء العنوان.
2. ينبغي أن يبدأ عنوان الموضوع بـ 'دليل تحدي FreCodeCamp Challenge: ' متوافق مع العنوان الفعلي لتحدي المنهج الدراسي. فعلى سبيل المثال، إذا كان التحدي يسمى "`قرود شونكي`"، فإن عنوان الموضوع سيكون "`دليل تحدي freeCodeCamp Guide: Chunky Monkey`".
3. يجب أن يكون "الكامبربوت" مالك هذه المواضيع/المشاركات، لذا ستحتاج إلى طلب مشرف لتغيير ملكية الوظيفة الرئيسية إلى 'الكاميربوت`.
4. بمجرد إنشاء الموضوع الجديد، يتم إنشاء معرف موضوع المنتدى. يقع في نهاية عنوان URL لموضوع المنتدى. يجب إضافة هذا المعرف إلى الموضوع الأمامي لملف تحدي المنهج الدراسي من خلال عملية طلب السحب العادية لزر "الحصول على تلميح" لربط الموضوع.
### مبادئ توجيهية لمحتوى التلميحات ومواضيع الحلول
عند اقتراح حل لموضوع الدليل المتصل بتحدي المنهج، يجب إضافة الرمز الكامل. وهذا يشمل جميع شفرة البذور الأصلية بالإضافة إلى أي تغييرات لازمة لتجاوز جميع اختبارات التحدي. يجب استخدام القالب التالي عند إنشاء تلميحات/مواضيع حلول:
``md
# اسم التحدي هنا
---
## شرح المشكلة
يلخص ما يجب القيام به دون مجرد تكرار وصف التحدي و/أو التعليمات. هذا قسم اختياري
#### الروابط ذات الصلة
- [Link Text](link_url_goes_here)
- [Link Text](link_url_goes_here)
---
## # # Hints
#### Hint 1
Hint هنا
#### 2
تلميح هنا
---
## # الحلول
<details><summary>الحل 1 (اضغط على عرض/Hide)</summary>
```js
function myFunc() {
console. og('مرحبا بالعالم!');
}
````
#### شرح التعليمات البرمجية
- تفسير الرمز يذهب هنا
- تفسير الرمز يذهب هنا
#### الروابط ذات الصلة
- [نص الرابط](link_url_goes_here)
- [نص الرابط](link_url_goes_here)
</details>
````
## اختبار التحديات
أمامك [إنشاء طلب سحب] (كيف يمكن فتح - سحب الطلب). (د) بالنسبة للتغييرات الخاصة بك، تحتاج إلى التحقق من أن التغييرات التي قمت بها لا تسبب مشاكل مع التحدي عن غير قصد.
1. لاختبار جميع التحديات تشغيل الأمر أدناه من الدليل الجذر
````
npm تشغيل الاختبار:منهج دراسي
```
2. يمكنك أيضا اختبار كتلة أو كتلة خارقة من التحديات باستخدام هذه الأوامر
```
npm قم بتشغيل الاختبار:منهج --block='HTML الأساسي و HTML5'
```
```
npm قم بتشغيل الاختبار:curriculum --superblock=responve-web-design
```
يمكنك أيضًا اختبار تحدي واحد فردًا من خلال تنفيذ الخطوات التالية:
1. التبديل إلى دليل 'المنهاج الدراسي`:
```
منهج cd
```
2. قم بتشغيل ما يلي لكل ملف من ملفات التحدي التي قمت بتغيير ما يلي:
```
npm اختبار -- -g 'العنوان الإنجليزي الكامل للتحدي'
```
بمجرد التحقق من أن كل تحدي كنت قد عملت على اجتياز الاختبارات، [يرجى إنشاء طلب سحب] (https://github.com/freeCodeCamp/freeCodeCamp/blob/Master/docs/how-to-open-a-pull-request.md).
> [!TIP]
> يمكنك تعيين متغير البيئة `LOCALE` في `.env` إلى لغة التحدي (التحديات) التي تحتاج إلى اختبار.
>
> القيم المقبولة حاليا هي "الإنكليزية" و "chinese"، مع تعيين "english" بشكل افتراضي.
## قالب التحدي القادم
قالب التحدي في عملية التحديث إلى بنية أنظف وأقل تداخلا. لم يتم الانتهاء من ذلك تماما، ولكن ينبغي أن يكون ما يلي قريبا من الهيكل النهائي:
``mdx
--
id: المعرف الفريد (أبجدي رقمي، MongoDB_id)
عنوان: 'عنوان التحدي'
نوع التحدي: عدد صحيح، معرف في 'العميل/Us/ChallengeTypes. s`
فيديوورل: 'عنوان URL لشرح الفيديو'
forumTopicId: 12345
---
استيراد سكريبت من './script. dx';
## --step-description--
نص الوصف، في markdown
``html
<div>
مثال رمز
</div>
```
## --تلميحات الخطوات--
![test-id-1]
سيكون هناك عدد اعتباطي من ثلاث مرات للمعرفات والتعليمات (في markdown) والكتل البرمجية.
```js
كود الاختبار الأول
```
![test-id-2]
المزيد من الإرشادات في بناء الجملة markdown
```js
المزيد من التعليمات البرمجية
```
## --بذرة خطوة--
### --رمز المستخدم مسبقاً--
```lang
تم تقييم الرمز قبل المستخدم
```
### --رمز المستخدم --
```lang
تم تقييم الرمز بعد المستخدم، وقبل الاختبارات مباشرة
```
### --محتوى البذورة--
![index-html]
```html
بعض html
```
```css
بعض الشارات
```
```js
بعض Js
```
![index-js]
<Script ></p>
<h1 spaces-before="0">
--علامة الحل--
</h1>
<p spaces-before="0">
نفس الشيء بالضبط مع قسم البذور
</p>
<h2 spaces-before="0">
- علامة الحل التالية
</h2>
<p spaces-before="0">
نفس الشيء مرة أخرى
</p>
<h1 spaces-before="0">
- علامة استفهام
</h1>
<h2 spaces-before="0">
- علامة نصية
</h2>
<p spaces-before="0">
يطرح السؤال هنا (يستخدم فقط لتحديات الفيديو)
</p>
<h2 spaces-before="0">
--علامات الإجابة--
</h2>
<p spaces-before="0">
الإجابة 1
</p>
<hr />
<p spaces-before="0">
الإجابة 2
</p>
<hr />
<p spaces-before="0">
الإجابة 2
</p>
<h2 spaces-before="0">
--علامة الحل--
</h2>
<p spaces-before="0">
\<number of correct answer\>
</p>
<p spaces-before="0">
````
</p>
<h3 spaces-before="0">
روابط مفيدة
</h3>
<p spaces-before="0">
تحديات خلق وتحرير:
</p>
<ol start="1">
<li>
<p spaces-before="0">
<a href="https://github.com/freeCodeCamp/freeCodeCamp/blob/master/client/utils/challengeTypes.js#L1-L13">أنواع التحديات</a> - ما تعنيه قيم نوع التحدي الرقمي (عدد).
</p>
</li>
<li>
<p spaces-before="0">
<a href="https://www.youtube.com/watch?v=iOdD84OSfAE#t=2h49m55s">المساهمة في FreeCodeCamp - كتابة اختبار التحدي ES6</a> - فيديو يتبع <a href="https://twitter.com/ArrowoodTech">إيثان آروود</a> لأنه يساهم في النسخة القديمة من المنهج الدراسي.
</p>
</li>
</ol>

40
docs/i18n/Arabic/how-to-work-on-the-docs-theme.md Normal file
View File

@ -0,0 +1,40 @@
# كيفية العمل في موضوع الوثائق
> [!ملاحظة] تذكير سريع بأنك لست بحاجة إلى إعداد أي شيء للعمل على محتوى موقع التوثيق.
>
> للعمل على المبادئ التوجيهية للمساهمة، يمكنك تعديل أو إضافة ملفات في دليل `docs` [المتاح هنا](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/docs). عند دمج التغييرات الخاصة بك، سيتم إتاحتها تلقائياً في موقع التوثيق.
## هيكل موقع الوثائق على الإنترنت
تم إنشاء الموقع باستخدام [`docsify`](https://docsify.js.org)، وتم خدمته باستخدام صفحات GitHub .
عادة لن تحتاج إلى تغيير أي تكوين أو بناء الموقع محليا. في حالة إهتمامك، إليك كيفية عملها:
- مصدر الصفحة الرئيسية لهذا الموقع متاح في [`docs/index.html`](index.html).
- نحن نخدم هذا الملف كـ SPA باستخدام `docsify` وصفحات GitHub .
- البرنامج النصي `docsify` يولد محتوى `markdown` ملفات في `docs` دليل عند الطلب.
- تم إنشاء الصفحة الرئيسية من [`_coverpage.md`](_coverpage.md).
- التنقل في الشريط الجانبي يتم إنشاؤه من [`_sidebar.md`](_sidebar.md).
## تقديم الخدمات لموقع الوثائق محليا
استنساخ معسكر الترميز الحر:
```sh
استنساخ git https://github.com/freeCodeCamp/freeCodeCamp.git
docsify يخدم المستندات
```
تثبيت `docsify`:
```sh
npm install -g docsify
```
وخدمة دليل `/docs`
```sh
docsify يخدم المستندات
```
بدلاً من ذلك، إذا كنت قد قمت بتثبيت freeCodeCamp محلياً (انظر دليل الإعداد المحلي)، نقوم بتجميع CLI مع أدوات التطوير حتى يمكنك تشغيل `npm تشغيل docs:serve` من جذر المستودع.

8
docs/i18n/Arabic/how-to-work-on-the-news-theme.md Normal file
View File

@ -0,0 +1,8 @@
<!--
The source for this document is available at:
https://github.com/freeCodeCamp/news-theme/blob/master/CONTRIBUTING.md
Please edit that file instead.
--> https://raw.githubusercontent.com/freeCodeCamp/news-theme/master/CONTRIBUTING.md

45
docs/i18n/Arabic/index.md Normal file
View File

@ -0,0 +1,45 @@
مجتمع [freeCodeCamp.org](https://freecodecamp.org) ممكن بفضل آلاف المتطوعين الطيبين مثلك. ونحن نرحب بكل الإسهامات المقدمة إلى المجتمع وتحمسون للترحيب بكم على متن سفينة واحدة.
> [!ملاحظة] قبل المتابعة، يرجى أخذ دقيقتين سريعتين لقراءة [مدونة قواعد السلوك لدينا](https://www.freecodecamp.org/code-of-conduct). ونحن ننفذها بشكل صارم عبر مجتمعنا. نريد أن نسهم في FreCodeCamp.org لتكون تجربة آمنة وشاملة للجميع.
مساهمة سعيدة.
أنتم نرحب بما يلي:
- إنشاء وتحديث وإصلاح الأخطاء في [تحديات البرمجة](#coding-challenges) الخاصة بنا.
- Help us fix bugs in freeCodeCamp.org's [learning platform](#learning-platform).
- _(سيأتي قريبا)_ ساعدنا في ترجمة freeCodeCamp.org إلى اللغات العالمية.
لديك أسئلة؟ انتقل إلى [هذه الأسئلة الشائعة](/FAQ.md) حيث نجيب على بعض الاستفسارات الشائعة حول المساهمة.
## تحديات البرمجة
كل التحديات التي نواجهها في البرمجة يتصدى لها المجتمع، يجلب المعرفة المتخصصة من المتطوعين مثلكم.
يمكنك المساعدة في توسيعها وجعل صياغتها أفضل. يمكنك أيضًا تحديث قصص المستخدم لشرح المفهوم بشكل أفضل أو إزالة قصص زائدة عن الحاجة وتحسين اختبارات التحدي لجعلها أكثر دقة في اختبار رمز الناس.
**إذا كنت مهتما بتحسين تحديات البرمجة هذه، إليك [كيفية العمل على تحديات البرمجة](how-to-work-on-coding-challenges.md).**
## منصة التعلم
منصة التعلم لدينا تعمل على مجموعة جافا سكريبت حديثة. وهي تحتوي على مكونات وأدوات ومكتبات مختلفة، بما في ذلك على سبيل المثال لا الحصر Node.js, MongoDB, LoopBack, OAuth 2.0, React. Gatsby, Webpack, وأكثر من ذلك.
وعموما،
- لدينا خادم API القائم على Node.js.
- مجموعة من تطبيقات العملاء القائمة على التفاعل.
- برنامج نصي نستخدمه لتقييم مشاريعنا الأمامية.
والإسهام في هذا يتطلب بعض الفهم لواجهات API، وبناء الإيس-6، والكثير من الفضول.
وبشكل أساسي، نتوقع معرفة أساسية ببعض التكنولوجيات والأدوات والمكتبات المذكورة أعلاه. ومع ذلك، ليس مطلوبا منكم أن تكونوا خبيراً في هذه البلدان ليساهموا فيها.
**إذا كنت ترغب في مساعدتنا على تحسين الكود لدينا، يمكنك إما استخدام Gitpod، بيئة ديف مجانية على الإنترنت**
[![فتح في Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
(يبدأ بيئة dev جاهزة للبرمجة ل freeCodeCamp في المتصفح الخاص بك.)
أو
**يمكنك [إعداد FreCodeCamp محليا](how-to-setup-freecodecamp-locally.md) على جهازك.**

101
docs/i18n/Catalan/FAQ.md Normal file
View File

@ -0,0 +1,101 @@
### I am new to GitHub and Open Source, where should I start?
Read our ["How to Contribute to Open Source Guide"](https://github.com/freeCodeCamp/how-to-contribute-to-open-source). It's a compresensive resource of first timer friendly projects and guidelines.
### Can I translate freeCodeCamp's curriculum?
We will be kicking-off the localization efforts on freeCodeCamp starting with the **Chinese** first.
We intend to make the curriculum available in more languages, but can't commit to any deadlines yet. Several operational limits like staff, active contributors and server costs play a role in driving the internationalisation (i18n) efforts.
We intend to start i18n efforts in these languages: Arabic, Portuguese, Russian and Spanish (in no particular order) after we have released the curriculum in Chinese.
**Why are you focusing on Chinese curriculum first?**
China is the largest demographic regions, in our non-native English speaking audience. Currently, we have hundreds of thousands of users using an old version of the platform. Focusing on the Chinese curriculum will give us an estimate of logistics involved in the i18n.
We will focus on Latin America as the demographic region for Portuguese and Spanish.
We do not have any plans for i18n to any other languages other than the above for the foreseeable future.
We do not encourage you to work on i18n on the above languages. We may accept pull requests, without any expectation of any timelines on deployments.
### How can I report a new bug?
If you think you've found a bug, first read the ["Help I've Found a Bug"](https://forum.freecodecamp.org/t/how-to-report-a-bug/19543) article and follow its instructions.
If you're confident it's a new bug, go ahead and create a new GitHub issue. Be sure to include as much information as possible so that we can reproduce the bug. We have a pre-defined issue template to help you through this.
Please note that any issues that seek coding help on a challenge will be closed. The issue tracker is strictly for codebase related issues and discussions. Whenever in doubt, you should [seek assistance on the forum](https://forum.freecodecamp.org) before making a report.
### How can I report a security issue?
Please don't create GitHub issues for security issues. Instead, please send an email to `security@freecodecamp.org` and we'll look into it immediately.
### I am a student, can I or our team work on a feature for academic credits?
Yes, sure.
While, we are open to all contributions, please note we are unable to commit to any timelines that may be a requirement at your college or university. We receive many pull-requests and code contributions by volunteer developers, and we respect their time and efforts. We will not be able to give any PR any special attention to be fair to all.
We request you to plan ahead and work on a feature with this in mind.
### What do these different labels that are tagged on issues mean?
The code maintainers [triage](https://en.wikipedia.org/wiki/Software_bug#Bug_management) issues and pull requests based on their priority, severity, and other factors. You can [find a complete glossary of their meanings here](https://github.com/freecodecamp/freecodecamp/labels).
### Where do I start if I want to work on an issue?
You should go through [**`help wanted`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) or [**`first timers only`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22first+timers+only%22) issues for a quick overview of what is available for you to work on.
> [!TIP] **`help wanted`** issues are up for grabs, and you do not need to seek permission before working on them. However, issues with the **`first timers only`** label are reserved for people that have not contributed to the freeCodeCamp codebase before. If these issues lack clarity on what needs to be done, feel free to ask questions in the comments.
### I found a typo, should I report an issue before I can make a pull request?
For typos and other wording changes, you can directly open pull requests without creating an issue first. Issues are more for discussing larger problems associated with code or structural aspects of the curriculum.
However, please mention details, context etc. in the pull request's description area to help us understand and review your contribution even for minor changes.
### How do I get an issue assigned to me?
We typically do not assign issues to anyone other than long-time contributors to avoid ambiguous no-shows. Instead, we follow the below policy to be fair to everyone:
1. The first pull request for any issue is preferred to be merged.
2. In the case of multiple pull requests for the same issue, we give priority to the quality of the code in the pull requests.
- Did you include tests?
- Did you catch all usecases?
- Did you ensure all tests pass, and you confirmed everything works locally?
3. Finally, we favor pull requests which follow our recommended guidelines.
- Did you follow the pull request checklist?
- Did you name your pull request title meaningfully?
You do not need any permission for issues that are marked `help wanted` or `first timers only` as explained earlier.
Follow the guidelines carefully and open a pull request.
### I am stuck on something that is not included in this documentation.
**Feel free to ask for help in:**
- The `Contributors` category of [our community forum](https://forum.freecodecamp.org/c/contributors).
- The public `Contributors` [chat room on Gitter](https://gitter.im/FreeCodeCamp/Contributors).
- The `#Contributors` channel on [our Discord community server](https://discord.gg/pFspAhS).
We are excited to help you contribute to any of the topics that you would like to work on. Feel free to ask us questions on the related issue threads, and we will be glad to clarify. Make sure you search for your query before posting a new one.
Be polite and patient. Our community of volunteers and moderators are always around to guide you through your queries.
**Additional Assistance:**
If you have queries about the stack, architecture of the codebase, feel free to reach out to our staff dev team:
| Staff | Send message on Forum |
|:--------------------- |:---------------------------------------------------------------------------- |
| Mrugesh Mohapatra | [@raisedadead](https://forum.freecodecamp.org/u/raisedadead) |
| Ahmad Abdolsaheb | [@abdolsa](https://forum.freecodecamp.org/u/abdolsa) |
| Kristofer Koishigawa | [@scissorsneedfoodtoo](https://forum.freecodecamp.org/u/scissorsneedfoodtoo) |
| Tom Mondloc | [@moT01](https://forum.freecodecamp.org/u/moT01) |
| Oliver Eyton-Williams | [@ojeytonwilliams](https://forum.freecodecamp.org/u/ojeytonwilliams) |
| Randell Dawson | [@RandellDawson](https://forum.freecodecamp.org/u/randelldawson) |
**You can email our developer staff at: `dev[at]freecodecamp.org`**

36
docs/i18n/Catalan/_sidebar.md Normal file
View File

@ -0,0 +1,36 @@
- **Getting Started**
- [Introduction](/index.md "Contribute to the freeCodeCamp.org Community")
- [Frequently Asked Questions](/FAQ.md)
- **Code Contribution**
- - [Set up freeCodeCamp locally](/how-to-setup-freecodecamp-locally.md)
- [Open a pull request](/how-to-open-a-pull-request.md)
- [Work on coding challenges](/how-to-work-on-coding-challenges.md)
- [Work on video challenges](/how-to-help-with-video-challenges.md)
- [Work on the news theme](/how-to-work-on-the-news-theme.md)
- [Work on the docs theme](/how-to-work-on-the-docs-theme.md)
- **Optional Guides**
- [Catch outgoing emails locally](/how-to-catch-outgoing-emails-locally.md)
- [Set up freeCodeCamp on WSL](/how-to-setup-wsl.md)
---
- **中文社区贡献指南**
- [成为专栏作者](/i18n/chinese/news-author-application.md)
- [文章翻译计划](/i18n/chinese/news-translations.md)
- [视频翻译计划](/i18n/chinese/video-translations.md)
---
- **Flight Manuals** (for Staff & Mods)
- [Moderator Handbook](/flight-manuals/moderator-handbook.md)
- [Reply Templates](/flight-manuals/using-reply-templates.md)
- [DevOps Overview](/devops.md)
- [Working on Servers](/flight-manuals/working-on-virtual-machines.md)
---
- **Our Community**
- [**GitHub**](https://github.com/freecodecamp/freecodecamp)
- [**Discourse Forum**](https://freecodecamp.org/forum/c/contributors)
- [**Gitter Chat**](https://gitter.im/FreeCodeCamp/Contributors)
- [**Discord Server**](https://discord.gg/pFspAhS)

227
docs/i18n/Catalan/devops.md Normal file
View File

@ -0,0 +1,227 @@
# Developer Operations at freeCodeCamp.org
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.
## How do we build, test and deploy the codebase?
This repository is continuously built, tested and deployed to **separate sets of infrastructure (Servers, Databases, CDNs, etc.)**.
This involves three steps to be followed in sequence:
1. New changes (both fixes and features) are merged into our primary development branch (`master`) 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.
#### Building the codebase - Mapping Git Branches to Deployments.
Typically, [`master`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master) (the default development branch) is merged into the [`production-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) branch once a day and is released into an isolated infrastructure.
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.
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 [`production-current`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-current) branch.
This is the final release that moves changes to our production platforms on 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 [Travis CI](https://travis-ci.org/freeCodeCamp/freeCodeCamp) and [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.
> [!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.
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).
## Triggering a build, test and deployment.
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).
> [!NOTE] In the upcoming days we would improve this flow to be done via pull-requests, for better access management and transparency.
### Pushing changes to Staging Applications.
1. Configure your remotes correctly.
```sh
git remote -v
```
**Results:**
```
origin git@github.com:raisedadead/freeCodeCamp.git (fetch)
origin git@github.com:raisedadead/freeCodeCamp.git (push)
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (fetch)
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (push)
```
2. Make sure your `master` branch is pristine and in sync with the upstream.
```sh
git checkout master
git fetch --all --prune
git reset --hard upstream/master
```
3. Check that the Travis CI is passing on the `master` branch for upstream.
The [continuous integration](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) tests should be green and PASSING for the `master` branch.
<details> <summary> Checking status on Travis CI (screenshot) </summary>
<br>
![Check build status on Travis CI](https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/master/docs/images/devops/travis-build.png)
</details>
If this is failing you should stop and investigate the errors.
4. Confirm that you are able to build the repository locally.
```
npm run clean-and-develop
```
5. Move changes from `master` to `production-staging` via a fast-forward merge
```
git checkout production-staging
git merge master
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.
>
> If they do, you may have done something incorrectly and you should just start over.
The above steps will automatically trigger a run on the build pipeline for the `production-staging` branch. Once the build is complete, the artifacts are saved as `.zip` files in a cold storage to be retrieved and used later.
The release pipeline is triggered automatically when a fresh artifact is available from the connected build pipeline. For staging platforms, this process does not involve manual approval and the artifacts are pushed to the Client CDN and API servers.
> [!TIP|label:Estimates] Typically the build run takes ~20-25 minutes to complete followed by the release run which takes ~15-20 mins for the client, and ~5-10 mins for the API to be available live. From code push to being live on the staging platforms the whole process takes **~35-45 mins** in total.
### Pushing changes to Production Applications.
The process is mostly the same as the staging platforms, with a few extra checks in place. This is just to make sure, we do not break anything on freeCodeCamp.org which can see hundreds of users using it at any moment.
| Do NOT execute these commands unless you have verified that everything is working on the staging platform. You should not bypass or skip any testing on staging before proceeding further. |
|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| |
1. Make sure your `production-staging` branch is pristine and in sync with the upstream.
```sh
git checkout production-staging
git fetch --all --prune
git reset --hard upstream/production-staging
```
2. Move changes from `production-staging` to `production-current` via a fast-forward merge
```
git checkout production-current
git merge production-staging
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.
>
> If they do, you may have done something incorrectly and you should just start over.
The above steps will automatically trigger a run on the build pipeline for the `production-current` branch. Once a build artifact is ready, it will trigger a run on the release pipeline.
> [!TIP|label:Estimates] Typically the build run takes ~20-25 minutes to complete.
**Additional Steps for Staff Action**
One a release run is triggered, members of the developer staff team will receive an automated manual intervention email. They can either _approve_ or _reject_ the release run.
If the changes are working nicely and have been tested on the staging platform, then it can be approved. The approval must be given within 4 hours of the release being triggered before getting rejected automatically. A staff can re-trigger the release run manually for rejected runs, or wait for the next cycle of release.
For staff use:
| Check your email for a direct link or [go to the release dashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) after the build run is complete. |
|:------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| |
Once one of the staff members approves a release, the pipeline will push the changes live to freeCodeCamp.org's production CDN and API servers. They typically take ~15-20 mins for the client, and ~5 mins for the API servers to be available live.
> [!TIP|label:Estimates] The release run typically takes ~15-20 mins for each client instance, and ~5-10 mins for each API instance to be available live. From code push to being live on the production platforms the whole process takes **~90-120 mins** in total (not counting the wait time for the staff approval).
## Build, Test and Deployment Status
Here is the current test, build and deployment status of the codebase.
| Type | Branch | Status | Dashboard |
|:---------------- |:-------------------------------------------------------------------------------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |:----------------------------------------------------------------------------------------- |
| CI Tests | [`master`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master) | ![Travis CI Build Status](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=master) | [Go to status dashboard](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| CI Tests | [`production-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | ![Travis CI Build Status](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=production-staging) | [Go to status dashboard](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| Build Pipeline | [`production-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | [![Build Status](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_apis/build/status/dot-dev-ci?branchName=production-staging)](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build/latest?definitionId=15&branchName=production-staging) | [Go to status dashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build) |
| Release Pipeline | [`production-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | | [Go to status dashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) |
| CI Tests | [`production-current`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-current) | ![Travis CI Build Status](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=production-current) | [Go to status dashboard](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| Build Pipeline | [`production-current`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | [![Build Status](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_apis/build/status/dot-org-ci?branchName=production-current)](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build/latest?definitionId=17&branchName=production-current) | [Go to status dashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build) |
| Release Pipeline | [`production-current`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | | [Go to status dashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) |
## Early access and beta testing
We welcome you to test these releases in a **"public beta testing"** mode and get early access to upcoming features to the platforms. Sometimes these features/changes are referred to as **next, beta, staging,** etc. interchangeably.
Your contributions via feedback and issue reports will help us in making the production platforms at `freeCodeCamp.org` more **resilient**, **consistent** and **stable** for everyone.
We thank you for reporting bugs that you encounter and help in making freeCodeCamp.org better. You rock!
### Identifying the upcoming version of the platforms
Currently a public beta testing version is available at:
<h1 align="center"><a href='https://www.freecodecamp.dev' _target='blank'>freecodecamp.dev</a></h1>
> [!NOTE] The domain name is different than **`freeCodeCamp.org`**. This is intentional to prevent search engine indexing and avoid confusion for regular users of the platform.
### Identifying the current version of the platforms
**The current version of the platform is always available at [`freeCodeCamp.org`](https://www.freecodecamp.org).**
The dev-team merges changes from the `production-staging` branch to `production-current` when they release changes. The top commit should be what you see live on the site.
You can identify the exact version deployed by visiting the build and deployment logs available in the status section. Alternatively you can also ping us in the [contributors chat room](https://gitter.im/FreeCodeCamp/Contributors) for a confirmation.
### Known Limitations
There are some known limitations and tradeoffs when using the beta version of the platform.
- #### All data / personal progress on these beta platforms `will NOT be saved or carried over` to production.
**Users on the beta version will have a separate account from the production.** The beta version uses a physically separate database from production. This gives us the ability to prevent any accidental loss of data or modifications. The dev team may purge the database on this beta version as needed.
- #### There are no guarantees on the uptime and reliability of the beta platforms.
Deployment is expected to be frequent and in rapid iterations, sometimes multiple times a day. As a result there will be unexpected downtime at times or broken functionality on the beta version.
- #### Do not send regular users to this site as a measure of confirming a fix
The beta site is and always has been to augment local development and testing, nothing else. It's not a promise of what’s coming, but a glimpse of what is being worked upon.
- #### Sign page may look different than production
We use a test tenant for freecodecamp.dev on Auth0, and hence do not have the ability to set a custom domain. This makes it so that all the redirect callbacks and the login page appear at a default domain like: `https://freecodecamp-dev.auth0.com/`. This does not affect the functionality is as close to production as we can get.
## Reporting issues and leaving feedback
Please open fresh issues for discussions and reporting bugs. You can label them as **[`release: next/beta`](https://github.com/freeCodeCamp/freeCodeCamp/labels/release%3A%20next%2Fbeta)** for triage.
You may send an email to `dev[at]freecodecamp.org` if you have any queries. As always all security vulnerabilities should be reported to `security[at]freecodecamp.org` instead of the public tracker and forum.

326
docs/i18n/Catalan/flight-manuals/moderator-handbook.md Normal file
View File

@ -0,0 +1,326 @@
# The official freeCodeCamp Moderator Handbook.
This will help you moderate different places in our community, including:
- GitHub issues & pull requests
- The forum, chat rooms, Facebook groups, and other online meeting places
- In-person events like study groups, hackathons, and conferences
**All freeCodeCamp Moderators are community-wide moderators. That means that we trust you to oversee any of these places.**
This said, you can serve as a moderator in whichever places are of the most interest to you. Some moderators just help out on GitHub. Others just help out on the forum. Some moderators are active everywhere.
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.
> [!NOTE] "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.
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).
# Moderating GitHub
Moderators have the ability to close issues and accept or close pull requests.
Moderators have two primary responsibilities regarding GitHub:
1. QA'ing and merging pull requests
2. Evaluating and responding to issues
## Moderating Pull Requests
Pull Requests (PRs) are how contributors submit changes to freeCodeCamp's repository. It's important that we perform Quality Assurance (QA) on pull requests before we decide whether to merge them or close them.
### Types of Pull Requests
1. **Challenge Instruction Edits** 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. Also, contributors may try to add links to resources to the challenges. You can close these pull requests and reply to them with this:
> Thank you for your pull request.
>
> I am closing this pull request. Please add links and other details to the challenge's corresponding guide article instead.
>
> If you think I'm wrong in closing this issue, please reopen it and add further clarification. Thank you, and happy coding.
2. **Challenge Code Edits** 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 to make sure the challenge tests can still be passed with the current solution, and the new code doesn't introduce any errors. 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.
3. **Codebase Changes** These code edits change the functionality of the freeCodeCamp platform itself. 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. So 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. 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 @raisedadead so he can take a final look.
### How to merge or close pull requests
First of all, when you choose a pull request to QA, 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.
Depending on the type of pull request it is, follow the corresponding rules listed above.
Before merging any pull request, make sure that GitHub has green checkmarks for everything. If there are any X's, investigate them first and figure out how to get them turned into green checkmarks first.
Sometimes there will be a Merge Conflict. This means that another pull request has made a change to that exact 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 judgement. The pull request's changes will be on top, and the Master branch's changes will be on 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.
If the pull request looks ready to merge (and doesn't require approval from @raisedadead), you can go ahead and merge it. Be sure to use the default "Squash and Merge" functionality on GitHub. This will squash all the pull requests commits down into a single commit, which makes the Git history much easier to read.
You should then comment on the pull request, thanking the contributor in your own personal way.
If the author of the pull request 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:
![Copy_edits_for_Java_arrays_article_by_karentobo_%C2%B7_Pull_Request__20615_%C2%B7_freeCodeCamp_freeCodeCamp|690x281](https://i.imgur.com/dTQMjGM.png)
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.
Often, a pull request will be obviously low effort. You can often 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".
There are also situations where the contributor is trying to add a link to their own website, or include a library they themselves created, or has a frivolous edit that doesn't serve to help anyone but themselves.
In both of these situations, you should go ahead and close their pull request and reply with this standard message:
> 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.
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.
## Moderating GitHub Issues
freeCodeCamp is an active open source project. We get new issues every day, all of which need to be triaged and labeled.
### Types of GitHub Issues
1. **Code Help Requests**, which people have mistakenly created GitHub issues for. If someone is asking for help, paste the following message, then close the issue.
> 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 \*\*"Help"\*\* button on the challenge on freeCodeCamp, 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.
>
> 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.
2. **Bug or Clarification issues** Try to reproduce the bug yourself if you can. If not, ask them for the steps to reproduce the bug, and whether they have any screenshots, videos, or additional details that can help you reproduce the issue. Once you can reproduce the issue - or at least confirm it's a legit issue - label it `confirmed`. Then:
- If it's a simple change to an existing challenge, label as `first timers only`, otherwise label as `help wanted`. Use other labels as appropriate.
- If the issue is more significant, flag as `bug`. &nbsp; If there is any ambiguity as to the proper course of action on an issue, feel free to tag @raisedadead on the issue get his opinion on it, then add the `Discussing` label.
3. **Duplicate Issues** If an issue is the same as another reported issue, the prior reported issue should take precedence. Flag as `Duplicate`, paste the following message replacing `#XXXXX` with the issue number, then close the issue.
> 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 I am closing it as a duplicate.
>
> If you think I'm wrong in closing this issue, please reopen it and add further clarification. Thank you and happy coding.
4. **Fixed in staging** Some problems may have already been fixed in staging, but don't have a GitHub issue associated with them. If this is the case, you can paste the following message, close the issue, and add a `status: resolved/shipping` label:
> 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, I'm closing this issue.
>
> If you think I'm wrong in closing this issue, please reopen it and add further clarification. Thank you and happy coding.
### Closing Stale, Outdated, Inactive Issues and Pull Requests
- Stale Issues or PRs are those that have not seen any activity from the OP for 21 days (3 weeks from the last activity), but only after a moderator has requested more information/changes. These can be closed in an automated/bot script or by the moderators themselves.
- Activity is defined as: Comments requesting an update on the PR and triages like `status: update needed` label etc.
- If the OP 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 judgement to resolve the outstanding PR's status.
### Other guidelines for Moderators on 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.
Also, you should never accept your own PRs. They must be QA'd by another moderator, just like with any other 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 dev@freecodecamp.org with a link to the offending pull request and we can consider banning them from freeCodeCamp's GitHub organization entirely.
# 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."
![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)
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 smallest kindness may trigger a cascade of good deeds.
### Deleting forum posts
Forum moderators have the ability to 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.
### 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 follow the process above. Quietly block the user from posting (using the silence option on the User Admin panel), then send a warning with the Code of Conduct. Check the box in the private message indicating that your message is a "formal warning."
You can ask questions and report incidents in the in the [staff forum section](https://forum.freecodecamp.com/c/staff).
### Dealing with off-topic conversations
Posts or topics that seems 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 require that freeCodeCamp users be at least 13 years of age. In the event that 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). Then email [Quincy](https://forum.freecodecamp.org/u/QuincyLarson) (quincy@freecodecamp.org) or [Mrugesh](https://forum.freecodecamp.org/u/raisedadead) (mrugesh@freecodecamp.org) to delete the user's freeCodeCamp account as well.
```markdown
SUBJECT: Users under 13 are not allowed to use the forum per Terms of Service
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.
Please rejoin once you have reached at least 13 years of age.
Thank you for understanding.
```
# Moderating Facebook
If you see anything that seems to break our [Code of Conduct](https://code-of-conduct.freecodecamp.org/), you should delete it immediately.
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. In these cases, their post should be deleted, but the person who posted it doesn't necessarily need to be banned. By getting their post deleted, they will hopefully come to understand that what they posted was inappropriate.
But if it is an egregious offense that can't reasonably be attributed to a cultural difference or a misunderstanding of the English language, then you should strongly consider blocking the member from the Facebook group.
# Moderating Discord
Here's how moderators deal with violations of our [Code of Conduct](https://code-of-conduct.freecodecamp.org/) on Discord:
1. **Make sure it was intended to violate the Code of Conduct.** 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.
2. **If the camper clearly violates the Code of Conduct, the moderator will proceed as follows:**
- Suspend the offending camper, but don't warn or threaten them. Instead, quietly give them the Suspended role on Discord, then send them the following message:
```
This is a standard message notifying you that I had to temporarily suspend you from talking on the freeCodeCamp Discord server.
I am a moderator acting on behalf of our open source community. I can consider removing your suspension, but I need you to take the following 3 steps first:
1. Read our Code of Conduct: https://code-of-conduct.freecodecamp.org/
2. Message me back confirming that you have finished reading it.
3. Explain to me why you think I suspended you, and why I should remove your suspension.
```
- Report a short summary of the event and how they responded to it in the #admin channel. Here's an example of what such a summary might look like:
```
Suspended: _@username_
Reason(s): _Spamming, trolling_
Evidence: _One or more links to the offending message(s)_
CoC: _Sent_
```
- A report for removing a suspension should look like:
```
I’ve removed the suspension from ` @username `. I sent them the Code of Conduct. They just today realized they were suspended and apologized for what they did.
```
- Based on the offenders reply, the moderator will decide whether to remove the suspension from the offending camper. If they seem respectful and apologetic, the moderator can remove the suspension. As a matter of policy, moderators will be polite during this process, no matter how poorly the offending camper has behaved. If they aren't respectful or unwilling to accept the CoC, the suspension should be followed with a ban from the Discord server. Use the same summary as above, but replace "Suspended:" with "Banned:".
3. **How to ban and/or unban**
- In order to ban someone, right click on their username/profile picture and select "Ban <username>". You will be given the option to delete their previous messages - select "Don't delete any", as the messages should remain present as a historic record.
- If you decide to ban someone, it means they're unwilling to abide to our Code of Conduct. Therefore unbanning a Camper should rarely occur. However, if the need arises, you can do so by clicking on the server name, choosing "Server Settings", choosing "Bans", selecting the user you wish to unban, and clicking "Revoke Ban".
Discord Bans are global - you cannot ban a user from a specific channel, only from the entire server.
4. **Deleting messages** Moderators have the ability to delete messages on Discord. They should only exercise this ability in four very specific situations:
- 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) as to render chat completely unusable.
- Someone has posted 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 message as these are an important historic record. 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, but for the #activity-log it is sufficient to say the evidence was "removed due to sensitive content". 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.
5. **Don’t use @everyone or @here** Don’t use @everyone or @here under any circumstances! Every single person in that chat room will get a notification. In some cases, tens of thousands of people. Instead, if you want people to see an announcement, you can pin it to the channel to allow everyone to read it.
6. **Don’t threaten to ban or suspend** If a camper is breaking the code of conduct, don’t threaten to ban or suspend them, and never warn them in public. Instead, talk to them privately, or send them a DM and issue a suspension (per the above protocol). No one else in that channel needs to know that you banned / suspended the person - campers can view the summary in the #activity-log channel if they want to keep up on that information. 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:
- Camper posts a wall of code to request help
Moderator: @username Please use Codepen or Pastebin when posting large amounts of code.
- 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.
- 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/
7. **Don’t brag about being a moderator** 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 they’re doing nothing wrong. This is just human nature.
8. **Don’t contradict other moderators** If you disagree with the action of a moderator, talk with them in private or bring it up in the #mod-chat channel. Never override a ban, 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. Remember: we’re all on the same team. We want to dignify the role of moderators and present a unified front.
9. **Talk with other moderators** We have a room for moderators only. Use it! If you feel uncomfortable with how to handle 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 the input of every team member! Even if you totally disagree with anything in these guidelines or the Code of Conduct!
10. **Temporarily inactive** 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 in the server or not.
# How to become a moderator
If you are helping people in the community consistently over time, 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.
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), etc.
> [!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. This is required for us to be able to give you write access on 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:
> 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
Anyone is welcome in the [Contributors room on our Discord](https://discord.gg/KVUmVXA). It is the designated chat room for moderators and other campers who are contributing to our community in any number of ways, including through study groups.
Our assumption is that 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.
# Dealing with solicitors
You may be approached by organizations who want to partner or co-brand with freeCodeCamp in some way. Once you realize that this is what they're after, please stop talking to them and tell them to email quincy@freecodecamp.org. He gets proposals like this all the time and is 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 are seeking 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 at some point reflect back to fCC, 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. 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 Discord: Suspend the user. This is not to punish them! Suspending a user will create a private channel that's only accessible by the user and the team. This will benefit both the user and fCC in several ways:
- 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
> [!NOTE] Suspending a user automatically gives them a message about reading our Code of Conduct. Make sure you inform the user that you Suspended them to give them some privacy and that they're not being punished. This is very important! We absolutely want to avoid giving users the idea that they're being punished for reaching out to get help!
If you believe the user is capable of rejoining the community, right click on the private channel and copy the ID. Put the following message in #mod-log:
> Reference medical advice: <channel ID> <username>
After that, you can remove the Suspension from the user as you normally do.
Helpful URLs:
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 perfectly summarizes most communities' thoughts on free speech. So if someone defends something they're saying as "free speech" feel free to send it to them.
<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!

126
docs/i18n/Catalan/flight-manuals/using-reply-templates.md Normal file
View File

@ -0,0 +1,126 @@
# Using Reply Templates
These are some of the standard reply templates that you may use while reviewing pull requests and triaging issues.
> You can make your own with GitHub's built-in [**Saved replies**](https://github.com/settings/replies/) feature or use the ones below.
### 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)! 🎉
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
We would love to be able to merge your changes but it looks like there is an error with the Travis CI build. ⚠️
Once you resolve these issues, We will be able to review your PR and merge it. 😊
---
> Feel free to reference the [Style guide for writing articles](https://github.com/freeCodeCamp/freeCodeCamp#article-title) for this repo on formatting an article correctly so your Travis CI build passes. ✅
>
> Also, it's good practice on GitHub to write a brief description of your changes when creating a PR. 📝
```
### Syncing Fork
> When PR is not up to date with the `master` branch.
``````markdown
Hey @username
We would love to be able to merge your changes but it looks like there is an error with the Travis CI build. ⚠️
```bash
Error: ENOTDIR: not a directory, open 'src/pages/java/data-abstraction/index.md'
``````
This particular error was not caused by your file but was an old error caused by merging faulty code to the `master` branch. It has since been resolved.
To pass the build, you will have to sync the latest changes from the `master` branch of the `freeCodeCamp/freeCodeCamp` repo.
Using the command line, you can do this in three easy steps:
```bash
git remote add upstream git://github.com/freeCodeCamp/freeCodeCamp.git
git fetch upstream
git pull upstream master
```
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.
Once you sync your fork and pass the build, We will be able to review your PR and merge it. 😊
---
> 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. 🔄
>
> Also, it's good practice on GitHub to write a brief description of your changes when creating a PR. 📝
``````
### Merge Conflicts
> When PR has merge conflicts that need to be resolved.¹
```markdown
Hey @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. 😊
---
> 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/). 🔍️
>
> Also, it's good practice on GitHub to write a brief description of your changes when creating a 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.
```markdown
Hey @username
It seems that similar changes have already been accepted earlier for this article you are editing, sorry about that. 😓
If you feel you have more to add, please feel free to open up a new PR.
Thanks again! 😊
---
> If you have any questions, feel free to reach out through [Gitter](https://gitter.im/FreeCodeCamp/Contributors) or by commenting below. 💬
```
### Closing invalid pull requests
> When PR is invalid.
```markdown
Hey @username
You have not added any content, We will be closing this PR and marking it as `invalid`. 😓️
Feel free to open another PR though! 👍
```

475
docs/i18n/Catalan/flight-manuals/working-on-virtual-machines.md Normal file
View File

@ -0,0 +1,475 @@
# Flight Manual for working on Virtual Machines
As a member of the staff or the dev-team, you may have been given access to our cloud service providers like Azure, Digital Ocean, etc.
Here are some handy commands that you can use to work on the Virtual Machines (VM), for instance performing maintenance updates or doing general houeskeeping.
# Get a list of the VMs
> [!NOTE] While you may already have SSH access to the VMs, that alone will not let you list VMs unless you been granted access to the cloud portals as well.
## Azure
Install Azure CLI `az`: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli
> **(One-time) Install on macOS with [`homebrew`](https://brew.sh):**
```
brew install azure-cli
```
> **(One-time) Login:**
```
az login
```
> **Get the list of VM names and P addresses:**
```
az vm list-ip-addresses --output table
```
## Digital Ocean
Install Digital Ocean CLI `doctl`: https://github.com/digitalocean/doctl#installing-doctl
> **(One-time) Install on macOS with [`homebrew`](https://brew.sh):**
```
brew install doctl
```
> **(One-time) Login:**
Authentication and context switching: https://github.com/digitalocean/doctl#authenticating-with-digitalocean
```
doctl auth init
```
> **Get the list of VM names and IP addresses:**
```
doctl compute droplet list --format "ID,Name,PublicIPv4"
```
# Spin a VM (or VM Scale Set)
> Todo: Add instructions for spinning VM(s)
<!--
The below instructions are stale.
### 0. Prerequisites (workspace Setup) for Staff
Get a login session on `azure cli`, and clone the
[`infra`](https://github.com/freeCodeCamp/infra) for setting up template
workspace.
```console
az login
git clone https://github.com/freeCodeCamp/infra
cd infra
```
Use the Scratchpad subdirectory for temporary files, and making one-off edits.
The contents in this subdirectory are intentionally ignored from source control.
### 1. Provision VMs on Azure.
List all Resource Groups
```console
az group list --output table
```
```console
Name Location Status
--------------------------------- ------------- ---------
tools-rg eastus Succeeded
```
Create a Resource Group
```
az group create --location eastus --name stg-rg
```
```console
az group list --output table
```
```console
Name Location Status
--------------------------------- ------------- ---------
tools-rg eastus Succeeded
stg-rg eastus Succeeded
```
Next per the need, provision a single VM or a scaleset.
#### A. provision single instances
```console
az vm create \
--resource-group stg-rg-eastus \
--name <VIRTUAL_MACHINE_NAME> \
--image UbuntuLTS \
--size <VIRTUAL_MACHINE_SKU>
--custom-data cloud-init/nginx-cloud-init.yaml \
--admin-username <USERNAME> \
--ssh-key-values <SSH_KEYS>.pub
```
#### B. provision scaleset instance
```console
az vmss create \
--resource-group stg-rg-eastus \
--name <VIRTUAL_MACHINE_SCALESET_NAME> \
--image UbuntuLTS \
--size <VIRTUAL_MACHINE_SKU>
--upgrade-policy-mode automatic \
--custom-data cloud-init/nginx-cloud-init.yaml \
--admin-username <USERNAME> \
--ssh-key-values <SSH_KEYS>.pub
```
> [!NOTE]
>
> - The custom-data config should allow you to configure and add SSH keys,
> install packages etc. via the `cloud-init` templates in your local
> workspace. Tweak the files in your local workspace as needed. The cloud-init
> config is optional and you can omit it completely to do setups manually as
> well.
>
> - The virtual machine SKU is something like: **Standard_B2s** which can be
> retrived by executing something like
> `az vm list-sizes -l eastus --output table` or checking the Azure portal
> pricing.
-->
# Keep VMs updated
You should keep the VMs up to date by performing updates and upgrades. This will ensure that the virtual machine is patched with latest security fixes.
> [!WARNING] Before you run these commands:
>
> - Make sure that the VM has been provisioned completely and there is no post-install steps running.
> - If you are updating packages on a VM that is already serving an application, make sure the app has been stopped / saved. Package updates will cause network bandwidth, memory and/or CPU usage spikes leading to outages on running applications.
Update package information
```console
sudo apt update
```
Upgrade installed packages
```console
sudo apt upgrade -y
```
Cleanup unused packages
```console
sudo apt autoremove -y
```
# Work on Web Servers (Proxy)
We are running load balanced (Azure Load Balancer) instances for our web servers. These servers are running NGINX which reverse proxy all of the traffic to freeCodeCamp.org from various applications running on their own infrastructures.
The NGINX config is available on [this repository](https://github.com/freeCodeCamp/nginx-config).
## First Install
Provisioning VMs with the Code
### 1. (Optional) Install NGINX and configure from repository.
The basic setup should be ready OOTB, via the cloud-init configuration. SSH and make changes as necessary for the particular instance(s).
If you did not use the cloud-init config previously use the below for manual setup of NGINX and error pages:
```console
sudo su
cd /var/www/html
git clone https://github.com/freeCodeCamp/error-pages
cd /etc/
rm -rf nginx
git clone https://github.com/freeCodeCamp/nginx-config nginx
cd /etc/nginx
```
### 2. Install Cloudflare origin certificates and upstream application config.
Get the Cloudflare origin certificates from the secure storage and install at required locations.
**OR**
Move over existing certificates:
```console
# Local
scp -r username@source-server-public-ip:/etc/nginx/ssl ./
scp -pr ./ssl username@target-server-public-ip:/tmp/
# Remote
rm -rf ./ssl
mv /tmp/ssl ./
```
Update Upstream Configurations:
```console
vi configs/upstreams.conf
```
Add/update the source/origin application IP addresses.
### 3. Setup networking and firewalls.
Configure Azure firewalls and `ufw` as needed for ingress origin addresses.
### 4. Add the VM to the load balancer backend pool.
Configure and add rules to load balancer if needed. You may also need to add the VMs to load balancer backend pool if needed.
## Logging and Monitoring
1. Check status for NGINX service using the below command:
```console
sudo systemctl status nginx
```
2. Logging and monitoring for the servers are available at:
> <h3 align="center"><a href='https://amplify.nginx.com' _target='blank'>https://amplify.nginx.com</a></h3>
## Updating Instances (Maintenance)
Config changes to our NGINX instances are maintained on GitHub, these should be deployed on each instance like so:
1. SSH into the instance and enter sudo
```console
sudo su
```
2. Get the latest config code.
```console
cd /etc/nginx
git fetch --all --prune
git reset --hard origin/master
```
3. Test and reload the config [with Signals](https://docs.nginx.com/nginx/admin-guide/basic-functionality/runtime-control/#controlling-nginx).
```console
nginx -t
nginx -s reload
```
# Work on API Instances
1. Install build tools for node binaries (`node-gyp`) etc.
```console
sudo apt install build-essential
```
## First Install
Provisioning VMs with the Code
1. Install Node LTS.
2. Update `npm` and install PM2 and setup logrotate and startup on boot
```console
npm i -g npm
npm i -g pm2
pm2 install pm2-logrotate
pm2 startup
```
3. Clone freeCodeCamp, setup env and keys.
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
cd freeCodeCamp
git checkout production-current # or any other branch to be deployed
```
4. Create the `.env` from the secure credentials storage.
5. Create the `google-credentials.json` from the secure credentials storage.
6. Install dependencies
```console
npm ci
```
7. Build the server
```console
npm run ensure-env && npm run build:server
```
8. Start Instances
```console
cd api-server
pm2 start production-start.js -i max --max-memory-restart 600M --name org
```
## Logging and Monitoring
```console
pm2 logs
```
```console
pm2 monit
```
## Updating Instances (Maintenance)
Code changes need to be deployed to the API instances from time to time. It can be a rolling update or a manual update. The later is essential when changing dependencies or adding enviroment variables.
> [!DANGER] The automated pipelines are not handling dependencies updates at the minute. We need to do a manual update before any deployment pipeline runs.
### 1. Manual Updates - Used for updating dependencies, env variables.
1. Stop all instances
```console
pm2 stop all
```
2. Install dependencies
```console
npm ci
```
3. Build the server
```console
npm run ensure-env && npm run build:server
```
4. Start Instances
```console
pm2 start all --update-env && pm2 logs
```
### 2. Rolling updates - Used for logical changes to code.
```console
pm2 reload all --update-env && pm2 logs
```
> [!NOTE] We are handling rolling updates to code, logic, via pipelines. You should not need to run these commands. These are here for documentation.
# Work on Client Instances
1. Install build tools for node binaries (`node-gyp`) etc.
```console
sudo apt install build-essential
```
## First Install
Provisioning VMs with the Code
1. Install Node LTS.
2. Update `npm` and install PM2 and setup logrotate and startup on boot
```console
npm i -g npm
npm i -g pm2
npm install -g serve
pm2 install pm2-logrotate
pm2 startup
```
3. Clone client config, setup env and keys.
```console
git clone https://github.com/freeCodeCamp/client-config.git client
cd client
```
```console
git clone https://github.com/freeCodeCamp/client-config.git client
cd client
```
Start placeholder instances for the web client, these will be updated with artifacts from the Azure pipline.
> Todo: This setup needs to move to S3 or Azure Blob storage
>
> ```console
echo "serve -c ../../serve.json www -p 50505" >> client-start-primary.sh
chmod +x client-start-primary.sh
pm2 delete client-primary
pm2 start ./client-start-primary.sh --name client-primary
echo "serve -c ../../serve.json www -p 52525" >> client-start-secondary.sh
chmod +x client-start-secondary.sh
pm2 delete client-secondary
pm2 start ./client-start-secondary.sh --name client-secondary
```
## Logging and Monitoring
```console
pm2 logs
```
```console
pm2 monit
```
## Updating Instances (Maintenance)
Code changes need to be deployed to the API instances from time to time. It can be a rolling update or a manual update. The later is essential when changing dependencies or adding enviroment variables.
> [!DANGER] The automated pipelines are not handling dependencies updates at the minute. We need to do a manual update before any deployment pipeline runs.
### 1. Manual Updates - Used for updating dependencies, env variables.
1. Stop all instances
```console
pm2 stop all
```
2. Install or update dependencies
3. Start Instances
```console
pm2 start all --update-env && pm2 logs
```
### 2. Rolling updates - Used for logical changes to code.
```console
pm2 reload all --update-env && pm2 logs
```
> [!NOTE] We are handling rolling updates to code, logic, via pipelines. You should not need to run these commands. These are here for documentation.

100
docs/i18n/Catalan/how-to-catch-outgoing-emails-locally.md Normal file
View File

@ -0,0 +1,100 @@
> **Note:** This is an **optional** step and is required only when working with email workflows
## Introduction
Some email workflows, like updating a user's email, requires the back-end api-server to send outgoing emails. An alternative to using an email service provider to send actual email messages, Mailhog is a developer tool for email testing that will catch the email messages sent by your freeCodeCamp instance.
## Installing MailHog
MailHog can be installed on macOS, Windows and Linux.
- [Introduction](#introduction)
- [Installing MailHog](#installing-mailhog)
- [Installing MailHog on macOS](#installing-mailhog-on-macos)
- [Installing MailHog on Windows](#installing-mailhog-on-windows)
- [Installing MailHog on Linux](#installing-mailhog-on-linux)
- [Using MailHog](#using-mailhog)
- [Useful Links](#useful-links)
### Installing MailHog on macOS
Install MailHog on macOS with [Homebrew](https://brew.sh/):
```bash
brew install mailhog
brew services start mailhog
```
The above commands will start a mailhog service in the background.
When the installation completes, you can start [using MailHog](#using-mailhog).
### Installing MailHog on Windows
Download the latest version of MailHog from [MailHog's official repository](https://github.com/mailhog/MailHog/releases). Locate and click on the link for your Windows version (32 or 64 bit) and a .exe file will be downloaded to your computer.
When the download completes, click to open the file. A Windows firewall notification may appear, requesting access permission for MailHog. A standard Windows command line prompt will open where MailHog will be running once firewall access is granted.
Close MailHog by closing the command prompt window. To start MailHog again, click on the MailHog executable (.exe) file that was downloaded initially - it is not necessary to download a new MailHog installation file.
Start [using MailHog](#using-mailhog).
### Installing MailHog on Linux
First, install [Go](https://golang.org).
Run the following commands to install GO on Debian-based systems like Ubuntu and Linux Mint.
```bash
sudo apt-get install golang
```
Run the following commands to install GO on RPM-based systems like CentOS, Fedora, Red Hat Linux, etc.
```bash
sudo dnf install golang
```
Alternatively, run the following commands to install GO.
```bash
sudo yum install golang
```
Now set the path for Go with the following commands.
```bash
echo "export GOPATH=$HOME/go" >> ~/.profile
echo 'export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin' >> ~/.profile
source ~/.profile
```
Finally, enter the commands below to install and run MailHog.
```bash
go get github.com/mailhog/MailHog
sudo cp /home/$(whoami)/go/bin/MailHog /usr/local/bin/mailhog
mailhog
```
Start [using MailHog](#using-mailhog).
## Using MailHog
Open a new browser tab or window and navigate to [http://localhost:8025](http://localhost:8025) to open your MailHog inbox when the MailHog installation has completed and MailHog is running. The inbox will appear similar to the screen shot below.
![MailHog Screenshot 1](images/mailhog/1.jpg)
Emails sent by your freeCodeCamp installation will appear as below
![MailHog Screenshot 2](images/mailhog/2.jpg)
Two tabs that allow you to view either plain text or source content will be available when you open a given email. Ensure that the plain text tab is selected as below.
![MailHog Screenshot 3](images/mailhog/3.jpg)
All links in the email should be clickable and resolve to their URL.
## Useful Links
- Check out the [MailHog](https://github.com/mailhog/MailHog) repository for further information related to MailHog. Additional information is also available regarding custom MailHog configurations.

199
docs/i18n/Catalan/how-to-help-with-video-challenges.md Normal file
View File

@ -0,0 +1,199 @@
# How to help with video challenges
Video challenges are a new type of challenge in the freeCodeCamp curriculum.
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 the the next video challenge in the course.
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.
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
---
id: Unique identifier (alphanumerical, MongoDB_id)
title: Challenge Title
challengeType: 11
videoId: 'YouTube videoId for video challenge'
---
## Description
<section id='description'>
An optional description with helpful information related to the video.
</section>
## Tests
<section id='tests'>
```yml
question:
text: 'Question'
answers:
- 'Answer One'
- 'Answer Two'
- 'Answer Three'
solution: 3
````
</section>
````
## 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/master/curriculum/challenges/english/08-data-analysis-with-python/data-analysis-with-python-course)
- [TensorFlow 2.0 Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/11-machine-learning-with-python/tensorflow)
- [Numpy Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/08-data-analysis-with-python/numpy)
- [How Neural Networks Work Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/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 mutiple choice question
First, find the 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 layed out in a table format.
````
---
id: 5e9a093a74c4063ca6f7c14d title: Data Analysis Example A challengeType: 11
videoId: nVAaxZ34khk
---
```
Next, access the YouTube video with that videoId. The url for the video will be:
https://www.youtube.com/watch?v=[videoId] (add videoId to the URL without square brackets)
In the example above, the url is 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.
### Add the question to the markdown file
You can add the question locally or directly throught 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.
If a question has not yet been added to a particular video challenge, it will have the following default question:
```yml
question:
text: |
Question
answers:
- |
one
- |
two
- |
three
solution: 3
```
Update the word “Question” with your question. Update the “one”, “two”, and “three” with the possible answers. Make sure to update the solution number with which answer is correct. You can add more possible answers using the same format. The question and answers can be surrounded with quotation marks.
#### Use markdown to format your question
The text in the question is parsed as markdown. The simplest way to ensure that it is formatted correctly is to start the question with `text: |`, like this:
```yml
question:
text: |
Question
```
Then you need to make sure that your question is on a new line and indented one level more than `text: |`.
The same approach can be used for the answers, so the entire question becomes
```yml
question:
text: |
Question
answers:
- |
First answer
- |
Second
- |
Third
solution: 2
```
Make sure each answer is plausible but there is only one correct answer.
#### Use of HTML
Questions and answers can contain certain HTML tags like `<br>` for a new line. HTML tags should be used sparingly, when questions cannot be expressed without them.
### Question examples
#### Examples without HTML
````yml
question:
text: |
What does this JavaScript code log to the console?
```js
console.log('hello world');
````
Select an answer!
answers:
- | hello *world*
- | **hello** world
- | hello world solution: 3
````
````yml
question:
text: |
What will print out after running this code:
```py
width = 15
height = 12.0
print(height/3)
````
answers:
- | 39
- | 4
- | 4.0
- | 5.0
- | 5 solution: 3
````
#### Example with HTML
```yml
question:
text: |
What will print out after running this code:
<pre><code>width = 15<br>height = 12.0<br>print(height/3)<code></pre>
answers:
- |
39
- |
4
- |
4.0
- |
5.0
- |
5
solution: 3
````
The final example demonstrates that HTML can be used, but that it is not as readable as the version without it.
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/master/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).

179
docs/i18n/Catalan/how-to-open-a-pull-request.md Normal file
View File

@ -0,0 +1,179 @@
# How to open a Pull Request (PR)
A pull request 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, or coding challenges you should follow these guidelines to send a PR.
## Prepare a good PR title
We recommend using [conventional title and messages](https://www.conventionalcommits.org/) for commits and pull request. The convention has the following format:
> `<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.
**Type:**
| Type | When to select |
|:----- |:---------------------------------------------------------------------------- |
| fix | Changed or updated/improved functionality, tests, 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. |
**Scope:**
You can select a scope from [this list of labels](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.
Some examples of good PRs titles would be:
- `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.
![Image - Compare pull request prompt on GitHub](./images/github/compare-pull-request-prompt.png)
2. By default, all pull requests should be against the freeCodeCamp main repo, `master` branch.
Make sure that your Base Fork is set to freeCodeCamp/freeCodeCamp when raising a Pull Request.
![Image - Comparing forks when making a pull request](./images/github/comparing-forks-for-pull-request.png)
3. Submit the pull request from your branch to freeCodeCamp's `master` branch.
4. In the body of your PR include a more detailed summary of the changes you made and why.
- 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).
> Example: `Closes #123` will close issue 123
5. Indicate if you have tested on a local copy of the site or not.
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.
## Feedback on pull requests
> Congratulations! :tada: on making a PR and thanks a lot for taking the time to contribute.
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.
If you need any assistance please discuss in the [contributors chat room](https://gitter.im/FreeCodeCamp/Contributors), we are more than happy to help you.
> [!TIP] If you are to be contributing more pull requests, we recommend you read the [making changes and syncing](https://contribute.freecodecamp.org/#/how-to-setup-freecodecamp-locally?id=making-changes-locally) guidelines to avoid having to delete your fork.
## 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.
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 `master`, you are able to do a simple rebase:
1. Rebase your local copy:
```console
git checkout <pr-branch>
git pull --rebase upstream master
```
2. Resolve any conflicts and add / edit commits
```console
# Either
git add .
git commit -m "chore: resolve conflicts"
# Or
git add .
git commit --amend --no-edit
```
3. Push back your changes to the 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 do a cherry pick:
1. Make sure your upstream comes in sync with your local:
```console
git checkout master
git fetch --all --prune
git checkout next-python-projects
git reset --hard upstream/next-python-projects
```
2. Take backup
a. Either delete your local branch after taking a backup (if you still have it locally):
```console
git checkout <pr-branch-name>
# example:
# git checkout feat/add-numpy-video-question
git checkout -b <backup-branch-name>
# example:
# git checkout -b backup-feat/add-numpy-video-question
git branch -D <pr-branch-name>
```
b. Or just a backup of your pr branch (if you do not have it locally):
```console
git checkout -b <backup-branch-name> origin/<pr-branch-name>
# example:
# git checkout -b backup-feat/add-numpy-video-question origin/feat/add-numpy-video-question
```
4. Start off with a clean slate:
```console
git checkout -b <pr-branch-name> next-python-projects
git cherry-pick <commit-hash>
```
5. Resolve any conflicts, and cleanup, install run tests
```console
npm run clean
npm ci
npm run test:curriculum --superblock=<superblock-name>
# example:
# npm run test:curriculum --superblock=python-for-everybody
```
6. If everything looks good push back to the PR
```console
git push --force origin <pr-branch-name>
```

546
docs/i18n/Catalan/how-to-setup-freecodecamp-locally.md Normal file
View File

@ -0,0 +1,546 @@
Follow these guidelines for setting up freeCodeCamp locally on your system. This is highly recommended if you want to contribute regularly.
For some of the contribution workflows, you need to have freeCodeCamp running locally. For example, previewing coding challenges or debugging and fixing bugs in the codebase.
> [!TIP] If you are not interested in setting up freeCodeCamp locally consider using Gitpod, a free online dev environment.
>
> [![Open in 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.)
## Prepare your local machine
Start by installing the prerequisite software for your operating system.
We primarily support development on **\*nix** systems. Our staff and community contributors regularly work with the codebase using tools installed on Ubuntu and macOS.
We also support Windows 10 via WSL2, which you can prepare by [reading this guide](/how-to-setup-wsl).
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.
**Prerequisites:**
| Prerequisite | Version | Notes |
| --------------------------------------------------------------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Node.js](http://nodejs.org) | `12.x` | [LTS Schedule](https://github.com/nodejs/Release#release-schedule) |
| npm (comes bundled with Node) | `6.x` | Does not have LTS releases, we use the version bundled with Node LTS |
| [MongoDB Community Server](https://docs.mongodb.com/manual/administration/install-community/) | `3.6` | [Release Notes](https://docs.mongodb.com/manual/release-notes/), Note: We are currently on `3.6`, an [upgrade is planned](https://github.com/freeCodeCamp/freeCodeCamp/issues/18275). |
> [!DANGER] 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.
If Node.js is already installed on your machine, run the following commands to validate the versions:
```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.
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.
2. (Optional but recommended) [Set up an SSH Key](https://help.github.com/articles/generating-an-ssh-key/) for GitHub.
3. Install a code editor of your choice.
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.
4. Set up linting for your code editor.
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).
> [!TIP] Please do not ignore any linting errors. They are meant to **help** you and to ensure a clean and simple codebase.
## Fork the repository on 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.
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).
> [!TIP] The main repository at `https://github.com/freeCodeCamp/freeCodeCamp` is often referred to as the `upstream` repository.
>
> Your fork at `https://github.com/YOUR_USER_NAME/freeCodeCamp` is often referred to as the `origin` repository.
**Follow these steps to fork the `https://github.com/freeCodeCamp/freeCodeCamp` repository:**
1. Go to the freeCodeCamp repository on GitHub: <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/))
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`
<details>
<summary>
How to fork freeCodeCamp on GitHub (screenshot)
</summary>
<br>
<img src="https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/master/docs/images/github/how-to-fork-freeCodeCamp.gif" alt="How to fork freeCodeCamp on GitHub" />
</details>
## Clone your fork from 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`.
Run these commands on your local machine:
1. Open a Terminal / Command Prompt / Shell in your projects directory
_i.e.: `/yourprojectsdirectory/`_
2. Clone your fork of freeCodeCamp, replacing `YOUR_USER_NAME` with your GitHub Username
```console
git clone --depth=1 https://github.com/YOUR_USER_NAME/freeCodeCamp.git
```
This will download the entire freeCodeCamp repository to your projects directory.
Note: `--depth=1` creates a shallow clone of your fork, with only the most recent history/commit.
## 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.
[As mentioned earlier](#fork-the-repository-on-github), the main repository is referred `upstream` repository. Your fork referred to as the `origin` repository.
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.
1. Change directory to the new freeCodeCamp directory:
```console
cd freeCodeCamp
```
2. Add a remote reference to the main freeCodeCamp repository:
```console
git remote add upstream https://github.com/freeCodeCamp/freeCodeCamp.git
```
3. Ensure the configuration looks correct:
```console
git remote -v
```
The output should look something like below:
```console
origin https://github.com/YOUR_USER_NAME/freeCodeCamp.git (fetch)
origin https://github.com/YOUR_USER_NAME/freeCodeCamp.git (push)
upstream https://github.com/freeCodeCamp/freeCodeCamp.git (fetch)
upstream https://github.com/freeCodeCamp/freeCodeCamp.git (push)
```
## Running freeCodeCamp locally
Now that you have a local copy of freeCodeCamp, you can follow these instructions to run it locally. This will allow you to:
- 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.
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.
And as always, feel free to hop on to our [Contributors Chat room on Gitter](https://gitter.im/FreeCodeCamp/Contributors) or [our Discord server](https://discord.gg/6vJYm9V), for quick queries.
> [!TIP] You may skip running freeCodeCamp locally if you are simply editing files. For instance, performing a `rebase`, or resolving `merge` conflicts.
>
> 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).
### Configuring dependencies
#### Step 1: Set up the environment variable file
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.
```console
# Create a copy of the "sample.env" and name it ".env".
# Populate it with the necessary API keys and secrets:
# macOS / Linux
cp sample.env .env
# Windows
copy sample.env .env
```
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.
> [!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.
#### Step 2: Install dependencies
This step will install the dependencies required for the application to run:
```console
npm ci
```
#### Step 3: Start MongoDB and seed the database
Before you can run the application locally, you will need to start the MongoDB service.
> [!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.
Start the MongoDB server in a separate terminal:
- On macOS & Ubuntu:
```console
mongod
```
- On Windows, you must specify the full path to the `mongod` binary
```console
"C:\Program Files\MongoDB\Server\3.6\bin\mongod"
```
Make sure to replace `3.6` with the version you have installed
> [!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/)
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.
```console
npm run seed
```
#### Step 4: Start the freeCodeCamp client application and API server
You can now start up the API server and the client applications.
```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.
> [!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] The API Server serves APIs at `http://localhost:3000`. The Gatsby app serves the client application at `http://localhost:8000`
> If you visit <http://localhost:3000/explorer> you should see the available APIs.
## 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.
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.
Simply clicking the **"Preview Custom 404 Page"** button will forward you to the correct 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" />
</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 `master` branch:
```console
git status
```
You should get an output like this:
```console
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
```
If you are not on master or your working directory is not clean, resolve any outstanding files/commits and checkout `master`:
```console
git checkout master
```
2. Sync the latest changes from the freeCodeCamp upstream `master` branch to your local master branch:
> [!WARNING] If you have any outstanding pull request that you made from the `master` branch of your fork, you will lose them at the end of this step.
>
> 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 `master`.
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/master` as often as possible to avoid conflicts later.
Update your local copy of the freeCodeCamp upstream repository:
```console
git fetch upstream
```
Hard reset your master branch with the freeCodeCamp master:
```console
git reset --hard upstream/master
```
Push your master branch to your origin to have a clean history on your fork on GitHub:
```console
git push origin master --force
```
You can validate your current master matches the upstream/master by performing a diff:
```console
git diff upstream/master
```
The resulting output should be empty.
3. Create a fresh new branch:
Working on a separate branch for each issue helps you keep your local work copy clean. You should never work on the `master`. This will soil your copy of freeCodeCamp and you may have to start over with a fresh clone or fork.
Check that you are on `master` as explained previously, and branch off from there:
```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.
Some examples of good branch names are:
```md
fix/update-challenges-for-react
fix/update-guide-for-html-css
fix/platform-bug-sign-in-issues
feat/add-guide-article-for-javascript
translate/add-spanish-basic-html
```
4. Edit pages and work on code in your favorite text editor.
5. Once you are happy with the changes you should optionally run freeCodeCamp locally to preview the changes.
6. Make sure you fix any errors and check the formatting of your changes.
7. Check and confirm the files you are updating:
```console
git status
```
This should show a list of `unstaged` files that you have edited.
```console
On branch feat/documentation
Your branch is up to date with 'upstream/feat/documentation'.
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
modified: docs/README.md
modified: docs/how-to-setup-freecodecamp-locally.md
modified: docs/how-to-work-on-guide-articles.md
...
```
8. Stage the changes and make a commit:
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:
```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
Your branch is up to date with 'upstream/feat/documentation'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: CONTRIBUTING.md
modified: docs/README.md
modified: docs/how-to-setup-freecodecamp-locally.md
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
fix: update build scripts for Travis-CI
feat: add article for JavaScript hoisting
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.
This does not take any additional time than an unconventional message like 'update file' or '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).
9. If you realise 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:
```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.
10. Next, you can push your changes to your fork:
```console
git push origin branch/name-here
```
## Proposing a Pull Request (PR)
After you've committed your changes, check here for [how to open a Pull Request](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 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. |
## 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).
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.
If you are on a different OS and/or are still running into issues, see [getting help](#getting-help).
> [!WARNING]
>
> Please avoid creating GitHub issues for prerequisite issues. They are out of the scope of this project.
### Issues with the UI, Fonts, build errors etc.
If you face issues with the UI, Fonts or see builds errors a cleanup can be useful:
```console
npm run clean
npm ci
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 interative mode:
```
git clean -ifdX
```
<details>
<summary>
How to clean git untracked files (screenshot)
</summary>
<br>
<img src="https://user-images.githubusercontent.com/1884376/94270515-ca579400-ff5d-11ea-8ff1-152cade31654.gif" alt="How to clean git untracked files" />
</details>
### Issues with API, Login, Challenge Submissions, etc.
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.
**On Linux / macOS / WSL on Windows - From Terminal:**
```console
netstat -ab | grep "3000"
tcp4 0 0 0.0.0.0:3000 DESKTOP LISTEN
```
**On Windows - From Elevated PowerShell:**
```powershell
netstat -ab | Select-String "3000"
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 recommed using GitPod instead of an offline setup.
## Getting Help
If you are stuck and need help, let us know by asking in the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or the [Contributors chat room](https://gitter.im/FreeCodeCamp/Contributors) on Gitter.
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.

129
docs/i18n/Catalan/how-to-setup-wsl.md Normal file
View File

@ -0,0 +1,129 @@
# Set up freeCodeCamp on Windows Subsystem for Linux (WSL)
> [!NOTE] Before you follow these instructions make sure your system meets the requirements
>
> **WSL 2**: Windows 10 64-bit (Version 2004, Build 19041 or higher) - available for all distributions including 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)
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 the our local setup guide to work with freeCodeCamp on Windows running a WSL distro like Ubuntu.
## Enable 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.
## Install Ubuntu
1. We recommended using Ubuntu-18.04 or above with WSL2.
> [!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.
2. Update the dependencies for the OS
```console
sudo apt update
sudo apt upgrade -y
# cleanup
sudo apt autoremove -y
```
## Set up Git
Git comes pre-installed with Ubuntu 18.04, verify that your Git version with `git --version`.
```output
~
❯ git --version
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.
## 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.
Essentially, you will edit and store your code on Ubuntu-18.04 with VS Code installed on Windows.
## Installing Docker Desktop
**Docker Desktop for Windows** allows you to install and run database and services like MongoDB, NGINX, etc. This is useful to avoid common pitfalls with installing MongoDB or other services directly on Windows or WSL2.
Follow the instructuction on the [official documentation](https://docs.docker.com/docker-for-windows/install) and install Docker Desktop for your Windows distribution.
There are some minimum hardware requirements for the best experience.
## Configure 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.
This makes it so that the containers run on WSL side instead of running on Windows. You will be able to access the services over `http://localhost` on both Windows and Ubuntu.
## Install MongoDB from Docker Hub
Once you have configured Docker Desktop to work with WSL2, follow these steps to start a MongoDB service:
1. Launch a new Ubuntu-18.04 terminal
2. Pull `MongoDB 3.6` from dockerhub
```console
docker pull mongo:3
```
3. Start the MongoDB service at port `27017`, and configure it to run automatically on system restarts
```console
docker run -it \
-v mongodata:/data/db \
-p 27017:27017 \
--name mongodb \
--restart unless-stopped \
-d mongo:3
```
4. You can now access the service from both Windows or Ubuntu at `mongodb://localhost:27017`.
## Installing Node.js and 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).
Once installed use these commands to install and use the Node.js version as needed
```console
nvm install --lts
# OR
# nvm install <version>
nvm install 14
# Usage
# nvm use <version>
nvm use 12
```
Node.js comes bundled with `npm`, you can update to the latest versions of `npm` with:
```console
npm install -g npm@latest
```
## Set up freeCodeCamp locally
Now that you have installed the pre-requisites, follow [our local setup guide](https://contribute.freecodecamp.org/#/how-to-setup-freecodecamp-locally) to clone, install and setup freeCodeCamp locally on your machine.
> [!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.
## 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:
- [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)

15
docs/i18n/Catalan/how-to-use-docker-on-windows-home.md Normal file
View File

@ -0,0 +1,15 @@
# How to use Docker on Windows Home
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.
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.
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.
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.

541
docs/i18n/Catalan/how-to-work-on-coding-challenges.md Normal file
View File

@ -0,0 +1,541 @@
# 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, and there's a place for those on Medium and YouTube. However, 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.
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. Stay active in the [contributors room](https://gitter.im/freecodecamp/contributors) and ask lots of questions.
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 own markdown file. This markdown file is later converted to HTML using our tools to create interactive web pages.
You can find all of freeCodeCamp.org's curricular content in the [`/curriculum/challenges`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges) directory.
## 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.
[![Open in 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 again.
## Challenge Template
Below is a template of what the challenge markdown files look like currently. To see the streamlined template we will be adopting see [below](#upcoming-challenge-template).
````md
---
id: Unique identifier (alphanumerical, MongoDB_id)
title: Challenge Title
challengeType: 0
videoUrl: 'url of video explanation'
---
## Description
<section id='description'>
A Description of the challenge and what is required to pass
</section>
## Instructions
<section id='instructions'>
Instructions about what exactly needs to be done.
</section>
## Tests
<section id='tests'>
```yml
tests:
- text: Should return "foo"
testString: 'A stringified function possibly using Chai asserts'
````
</section>
## Challenge Seed
<section id='challengeSeed'>
<div id='{ext}-seed'>
```{ext}
Code displayed in the editor by default.
This is a required section for the challenge.
```
</div>
### Before Test
<div id='{ext}-setup'>
```{ext}
Optional Test setup code.
```
</div>
### After Test
<div id='{ext}-teardown'>
```{ext}
Optional Test tear down code.
```
</div>
</section>
## Solution
<section id='solution'>
```{ext}
// solution required
```
</section>
````
> [!NOTE]
>
> 1. In the above sections, examples of `{ext}` are:
>
> - `html` - HTML/CSS
> - `js` - JavaScript
> - `jsx` - JSX
>
> 2. For the `Tests` section above, `text` and `testString` should be valid YAML strings. `testString` can be a stringified function or expression using which could use Chai asserts.
## 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.).
To generate a new one in a shell (assuming MongoDB is running separately):
1. Run `mongo` command.
2. Run `ObjectId()` command.
For example:
```bash
$ mongo
MongoDB shell version v3.6.1
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.4.10
...
$ ObjectId()
ObjectId("5a474d78df58bafeb3535d34")
````
The result is a new id, for example `5a474d78df58bafeb3535d34` above.
Once you have your id, put it into the markdown file as the `id` field at the top, e.g.
```yml
---
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.
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").
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.
You can add diagrams if absolutely 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.
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)
- Node.js
- Front-end development (adjective form with a dash) is when you're working on the front end (noun form with no dash). The same goes with "back end", "full stack", and many other compound terms.
### The 2-minute rule
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 own code and get all the tests to pass.
If it takes longer than two minutes to complete the challenge, you have two options:
- Simplify the challenge, or
- Split the challenge into two challenges.
The 2-minute rule forces you, the challenge designer, to make your directions concise, your seed code clear, and your tests straight-forward.
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.
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.
Our goal is to have thousands of 2-minute challenges. These can flow together and reiterate previously-covered concepts.
### Formatting challenge text
Here are specific formatting guidelines for challenge text and examples:
- Language keywords go in `<code>` tags. For example, HTML tag names or CSS property names
- The first instance of a keyword when it's being defined, or general keywords (i.e. "object" or "immutable") go in `<dfn>` tags
- References to code parts (i.e. function, method or variable names) should be wrapped in `<code>` tags. See example below:
- Use <code>parseInt</code> to convert the variable <code>realNumber</code> into an integer.
- 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 newline which only has three backticks and **another empty line**. **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.
See example below:
````md
The following is an example of code:
```{language}
[YOUR CODE HERE]
````
````
- Additional information in the form of a note should be formatted `<strong>Note:</strong> Rest of note text...`
- If multiple notes are needed, then list all of the notes in separate sentences using the format `<strong>Notes:</strong> First note text. Second note text.`.
- Use double quotes where applicable
## 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.
## 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
- Comments made should have a space between the comment characters and the comment themselves
`// Fix this line`
## 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.
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.
### 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.
### 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 need 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)
---
## Hints
### Hint 1
Hint goes here
### Hint 2
Hint goes here
---
## Solutions
<details><summary>Solution 1 (Click to Show/Hide)</summary>
```js
function myFunc() {
console.log('Hello World!');
}
````
#### Code Explanation
- Code explanation goes here
- Code explanation goes here
#### Relevant Links
- [Link Text](link_url_goes_here)
- [Link Text](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.
1. To test all challenges run the below command from the root directory
````
npm run test:curriculum
```
2. You can also test a block or a superblock of challenges with these commands
```
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. Switch to the `curriculum` directory:
```
cd curriculum
```
2. Run the following for each challenge file for which you have changed:
```
npm run test -- -g 'the full English title of the challenge'
```
Once you have verified that each challenge you've worked on passes the tests, [please create a pull request](https://github.com/freeCodeCamp/freeCodeCamp/blob/master/docs/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.
>
> The currently accepted values are `english` and `chinese`, with `english` being set by default.
## Upcoming Challenge Template
The challenge template in the process of being updated to a cleaner, less nested structure. This has not been completely finalized, but the following should close to the final structure:
````mdx
---
id: Unique identifier (alphanumerical, MongoDB_id)
title: 'Challenge Title'
challengeType: Integer, defined in `client/utils/challengeTypes.js`
videoUrl: 'url of video explanation'
forumTopicId: 12345
---
import Script from './script.mdx';
## --step-description--
Description text, in markdown
```html
<div>
example code
</div>
```
## --step-hints--
![test-id-1]
There will be an arbitrary number of triples of ids, instructions (in markdown) and code blocks.
```js
Code for test one
```
![test-id-2]
More instructions in markdown syntax
```js
More code
```
## --step-seed--
### --before-user-code--
```lang
Code evaluated before the user’s
```
### --after-user-code--
```lang
Code evaluated after the user’s, and just before the tests
```
### --seed-content--
![index-html]
```html
Some html
```
```css
Some css
```
```js
Some js
```
![index-js]
<Script ></p>
<h1 spaces-before="0">
--solution-marker--
</h1>
<p spaces-before="0">
Exactly the same as the seeds section
</p>
<h2 spaces-before="0">
--next-solution-marker
</h2>
<p spaces-before="0">
Same again
</p>
<h1 spaces-before="0">
--question-marker--
</h1>
<h2 spaces-before="0">
--text-marker--
</h2>
<p spaces-before="0">
The question would go here (only used for video challenges)
</p>
<h2 spaces-before="0">
--answers-marker--
</h2>
<p spaces-before="0">
Answer 1
</p>
<hr />
<p spaces-before="0">
Answer 2
</p>
<hr />
<p spaces-before="0">
More answers
</p>
<h2 spaces-before="0">
--solution-marker--
</h2>
<p spaces-before="0">
\<number of correct answer\>
</p>
<p spaces-before="0">
````
</p>
<h3 spaces-before="0">
Useful Links
</h3>
<p spaces-before="0">
Creating and Editing Challenges:
</p>
<ol start="1">
<li>
<p spaces-before="0">
<a href="https://github.com/freeCodeCamp/freeCodeCamp/blob/master/client/utils/challengeTypes.js#L1-L13">Challenge types</a> - what the numeric challenge type values mean (enum).
</p>
</li>
<li>
<p spaces-before="0">
<a href="https://www.youtube.com/watch?v=iOdD84OSfAE#t=2h49m55s">Contributing to FreeCodeCamp - Writing ES6 Challenge Tests</a> - a video following <a href="https://twitter.com/ArrowoodTech">Ethan Arrowood</a> as he contributes to the old version of the curriculum.
</p>
</li>
</ol>

40
docs/i18n/Catalan/how-to-work-on-the-docs-theme.md Normal file
View File

@ -0,0 +1,40 @@
# 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.
>
> To work on the contributing guidelines, you can edit or add files in the `docs` directory [available here](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/docs). When your changes are merged, it will be made available automatically at the documentation site.
## Structure of the docs website
The site is generated using [`docsify`](https://docsify.js.org), and served using GitHub pages.
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).
## Serving the documentation site locally
Clone freeCodeCamp:
```sh
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
docsify serve docs
```
Install `docsify`:
```sh
npm install -g docsify
```
and serve the `/docs` directory
```sh
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 `npm run docs:serve` from the root of the repo.

10
docs/i18n/Catalan/how-to-work-on-the-news-theme.md Normal file
View File

@ -0,0 +1,10 @@
<!--
The source for this document is available at:
https://github.com/freeCodeCamp/news-theme/blob/master/CONTRIBUTING.md
Please edit that file instead.
-->
[remote-markdown-url](https://raw.githubusercontent.com/freeCodeCamp/news-theme/master/CONTRIBUTING.md)

45
docs/i18n/Catalan/index.md Normal file
View File

@ -0,0 +1,45 @@
The [freeCodeCamp.org](https://freecodecamp.org) community is possible thanks to thousands of kind volunteers like you. We welcome any and all contributions to the community and are excited to welcome you aboard.
> [!NOTE] Before you proceed, please take a quick 2 minutes to read our [Code of Conduct](https://www.freecodecamp.org/code-of-conduct). We enforce it strictly across our community. We want contributing to freeCodeCamp.org to be a safe and inclusive experience for everyone.
Happy contributing.
You are welcome to:
- Create, update and fix bugs in our [coding challenges](#coding-challenges).
- Help us fix bugs in freeCodeCamp.org's [learning platform](#learning-platform).
- _(Coming Soon)_ Help us translate freeCodeCamp.org to world languages.
Have questions? Head over to [these FAQs](/FAQ.md) where we answer some common queries about contributing.
## Coding Challenges
All our coding challenges are curated by the community, bringing in expert knowledge from volunteers like you.
You can help expand them and make their wording better. You can also update the user stories to explain the concept better or remove redundant ones and improve the challenge tests to make them more accurately test people's code.
**If you're interested in improving these coding challenges, here's [how to work on coding challenges](how-to-work-on-coding-challenges.md).**
## Learning Platform
Our learning platform runs on a modern JavaScript stack. It has various components, tools, and libraries, including but not limited to, Node.js, MongoDB, LoopBack, OAuth 2.0, React, Gatsby, Webpack, and more.
Broadly,
- We have a Node.js based API server.
- A set of React-based client applications.
- A script that we use to evaluate our front-end projects.
Contributing to this requires some understanding of APIs, ES6 Syntax, and a lot of curiosity.
Essentially, we expect basic familiarity with some of the aforementioned technologies, tools, and libraries. With that being said, you are not required to be an expert on them to contribute.
**If you want to help us improve our codebase, you can either use Gitpod, a free online dev environment**
[![Open in 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.)
OR
**you can [set up freeCodeCamp locally](how-to-setup-freecodecamp-locally.md) on your machine.**

101
docs/i18n/Chinese/FAQ.md Normal file
View File

@ -0,0 +1,101 @@
### 我是 GitHub 和 Open Source, 我应该从哪里开始？
阅读我们的 ["如何为开源指南做出贡献"](https://github.com/freeCodeCamp/how-to-contribute-to-open-source)。 它是第一个适合计时器的项目和准则的令人愉快的资源。
### 我可以翻译免费CodeCamp的课程吗？
我们将首先从 **中文** 开始在免费CodeCamp上启动本地化工作。
我们打算以更多的语言提供课程，但是我们还不能承诺遵守任何最后期限。 一些操作限制，例如工作人员、积极贡献者和服务器费用，在推动国际化努力方面发挥了一定作用。
我们打算以阿拉伯语、葡萄牙语等语言开始i18n的努力。 在我们发布了中文课程之后，俄语和西班牙语(无特定顺序)。
**您为什么先集中精力处理中文课程？**
中国是人口最多的地区，在我国非母语英语听众中也是如此。 目前，我们有数十万用户使用旧版本的平台。 以中文课程为重点，将为我们提供对i18所涉后勤问题的估计。
我们将把重点放在作为葡萄牙语和西班牙语人口区域的拉丁美洲上。
在可预见的将来，除了上述语言之外，我们没有任何关于i18n语的计划。
我们不鼓励您在i18n上使用上述语言。 我们可以接受拉动请求，而不期待任何部署时间表。
### 我如何报告一个新的 bug？
如果你觉得你发现了一个 bug，请先阅读 ["帮助我找到了一个 Bug "](https://forum.freecodecamp.org/t/how-to-report-a-bug/19543) 篇文章，然后按照它的说明操作。
如果你相信这是一个新的bug，继续前进并创建一个新的 GitHub 问题。 请务必包含尽可能多的信息，以便我们能够复制漏洞。 我们有一个预先定义的问题模板来帮助您完成这个任务。
请注意，在挑战中寻求编码帮助的任何问题都将被关闭。 问题跟踪器严格用于编程相关问题和讨论。 Whenever in doubt, you should [seek assistance on the forum](https://forum.freecodecamp.org) before making a report.
### 我如何报告一个安全问题？
请不要为安全问题创建 GitHub 问题。 相反，请向 `security@freecodecamp.org` 发送一封电子邮件，我们将立即进行调查。
### 我是学生，我或我们的团队能否研究一种学分功能？
是的，確認。
虽然我们愿意提供所有捐款。 请注意我们无法对你的学院或大学可能需要的任何时间表作出承诺。 我们收到志愿开发者的许多提取请求和代码贡献，并且我们尊重他们的时间和努力。 我们将无法对任何公共责任给予任何特别关注，使之对所有人都是公平的。
我们请你考虑到这一点，事先计划和开发一个功能。
### 这些不同的标签在问题上意味着什么？
代码维护者 [triage](https://en.wikipedia.org/wiki/Software_bug#Bug_management) issues and pull request 依据他们的优先级、严重性和其他因素。 You can [find a complete glossary of their meanings here](https://github.com/freecodecamp/freecodecamp/labels).
### 如果我想就一个问题开展工作，我将从哪里开始？
您应该通过 [**`帮助您需要`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) 或 [**`第一次计时器`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22first+timers+only%22) 一些问题来快速概述您可以做些什么。
> [!TIP] **`需要帮助`** 问题已经解决到抓取的时候，您不需要在处理这些问题之前寻求权限。 然而，只有 **`第一次计时器`** 标签被保留给以前没有贡献免费CodeCamp代码库的人。 如果这些问题不清楚需要做些什么，请随时在评论中提出问题。
### 我找到了一个搭配器，我是否应该在提出拉取请求之前报告一个问题？
对于typo和其他文字更改，您可以直接打开合并请求，而不需要先创建一个问题。 讨论与守则或课程结构有关的更大问题的问题更多。
然而，请在拉取请求的描述区域中提及详细信息和上下文等，以帮助我们理解和审查您的贡献，即使是做了小的修改。
### 如何分配给我的问题？
我们通常不把问题分配给任何人，而不是长期的贡献者，以避免模棱两可的表现。 相反，我们奉行以下政策，对每个人都是公平的：
1. 任何问题的第一个拉取请求更喜欢被合并。
2. 在同一问题的多个合并请求中，我们优先考虑合并请求中的代码质量。
- 您是否包括测试？
- 捕获所有用户吗？
- 您是否确认了所有测试通过，并确认了所有在本地运行的测试？
3. 最后，我们赞成按照我们建议的准则拉取请求。
- 您是否遵循拉取请求列表？
- 您是否有意义地命名了您的拉请求标题？
您不需要任何权限来处理标记为 `有帮助需要` 或 `首次计时器如先前所解释的`。
仔细遵循准则并打开拉取请求。
### 我被困在这份文件中没有包含的东西上。
**随时请求帮助：**
- The `Contributors` category of [our community forum](https://forum.freecodecamp.org/c/contributors).
- The public `Contributors` [chat room on Gitter](https://gitter.im/FreeCodeCamp/Contributors).
- The `#Contributors` channel on [our Discord community server](https://discord.gg/pFspAhS).
我们很高兴能帮助您为您想要处理的任何主题做出贡献。 请随时就相关的问题向我们提出问题，我们将乐于加以澄清。 请确保您在发布新查询之前搜索您的查询。
耐心和礼貌。 我们的志愿者和版主一直围绕着你来指导你完成你的查询。
**额外援助：**
如果您有关于编解码器堆栈架构的查询，请随时联系我们的员工开发团队：
| 工作人员 | 发送论坛消息 |
|:--------------------- |:---------------------------------------------------------------------------- |
| Mrugesh Mohamatra | [@raisedadead](https://forum.freecodecamp.org/u/raisedadead) |
| 2. Ahmad Abdolsaheb | [@abdolsa](https://forum.freecodecamp.org/u/abdolsa) |
| Kristofer Koishigawa | [@scissorsneedfoodtoo](https://forum.freecodecamp.org/u/scissorsneedfoodtoo) |
| Tom Mondloc | [@moT01](https://forum.freecodecamp.org/u/moT01) |
| Oliver Eyton-Williams | [@ojeytonwilliams](https://forum.freecodecamp.org/u/ojeytonwilliams) |
| Randel Dawson | [@RandellDawson](https://forum.freecodecamp.org/u/randelldawson) |
**您可以发送电子邮件给我们的开发人员： `dev[at]freecodecamp.org`**

36
docs/i18n/Chinese/_sidebar.md Normal file
View File

@ -0,0 +1,36 @@
- **正在开始**
- [一. 导言](/index.md "为FreeCodeCamp.org 社区贡献")
- [常见问题](/FAQ.md)
- **代码贡献**
- - [在本地设置免费CodeCamp](/how-to-setup-freecodecamp-locally.md)
- [打开拉取请求](/how-to-open-a-pull-request.md)
- [关于编码挑战的工作](/how-to-work-on-coding-challenges.md)
- [关于视频挑战的工作](/how-to-help-with-video-challenges.md)
- [关于新闻主题的工作](/how-to-work-on-the-news-theme.md)
- [关于文件主题的工作](/how-to-work-on-the-docs-theme.md)
- **可选指南**
- [捕获本地发送的电子邮件](/how-to-catch-outgoing-emails-locally.md)
- [在 WSL 上设置免费CodeCamp](/how-to-setup-wsl.md)
---
- **中文社区贡献指南**
- [成为专栏作者](/i18n/chinese/news-author-application.md)
- [文章翻译计划](/i18n/chinese/news-translations.md)
- [视频翻译计划](/i18n/chinese/video-translations.md)
---
- **飞行手册** (适合员 & 模式)
- [版主手册](/flight-manuals/moderator-handbook.md)
- [回复模板](/flight-manuals/using-reply-templates.md)
- [DevOps 概述](/devops.md)
- [在服务器上工作](/flight-manuals/working-on-virtual-machines.md)
---
- **我们的社区**
- [**GitHub**](https://github.com/freecodecamp/freecodecamp)
- [**讨论区**](https://freecodecamp.org/forum/c/contributors)
- [**Gitter 聊天**](https://gitter.im/FreeCodeCamp/Contributors)
- [**Discord Server**](https://discord.gg/pFspAhS)

227
docs/i18n/Chinese/devops.md Normal file
View File

@ -0,0 +1,227 @@
# 在FreeCodeCamp.org开发者操作
本指南将帮助您了解我们的基础设施堆栈以及我们如何维护我们的平台。 虽然本指南没有关于所有操作的详尽无遗的细节，但可以用来作为你理解系统的参考。
让我们知道，如果你有反馈意见或询问，我们将乐于加以澄清。
## 我们如何构建、测试和部署代码库？
这个仓库是持续构建、测试和部署到 **个独立的基础设施组合(塞尔维亚、 数据库、 CDN 等)**。
这涉及按顺序采取的三个步骤：
1. 新的更改(修复和功能)通过拉取请求合并到我们的初级开发分支(`主`)。
2. 这些更改是通过一系列自动测试进行的。
3. 测试通过后，我们会发布更改（或在需要时更新它们）以部署到我们的基础设施。
#### 构建代码库-映射Git分支到部署。
典型的 [`master`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master) (默认开发分支) 已合并到 [`生产暂存`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) 分支每天一次并释放到一个孤立的基础设施。
这是我们的开发者和志愿贡献者的中间版本。 它也被称为“暂存”或“乙型”释放。
它与我们在 `freeCodeCamp.org`的现场生产环境完全相同，而不是使用一套单独的数据库、服务器、网络代理等。 这种隔离使我们能够在像场景一样的“生产”中测试正在进行的开发和功能，而不会影响到FreeCodeCamp.org主平台的正常用户。
开发人员团队 [`@freeCodeCamp/dev-team`](https://github.com/orgs/freeCodeCamp/teams/dev-team/members) 对Staging平台上的更改感到高兴。 这些更改每隔几天移动到 [`当前生产`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-current) 分支。
这是移动我们在 FreeCodeCamp.org 上生产平台更改的最后版本。
#### 测试更改 - 集成和用户接受测试。
我们采用不同程度的整合和验收测试来检查守则的质量。 我们所有的测试都是通过诸如 [Travis CI](https://travis-ci.org/freeCodeCamp/freeCodeCamp) 和 [Azure Pelines](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp) 等软件完成的。
我们有测试挑战解决方案、服务器 API 和客户端用户界面的单元测试。 这有助于我们检验不同组成部分之间的一体化。
> [!注意] 我们也正在编写终端用户测试，这将有助于复制真实的世界情景，如更新电子邮件或拨打到 API 或第三方服务。
这些测试一起有助于防止问题重复发生，并确保我们在处理另一个错误或功能时不会引入错误。
#### 正在部署更改 - 正在推送对服务器的更改。
我们配置了连续传送软件，将更改推送到我们的开发和生产服务器。
一旦更改被推送到受保护的释放分支，构建管道将自动触发到该分支。 建造管道负责建造人工制品并将其存放在冷藏库以供日后使用。
构建管道继续启动，如果它成功运行，就会触发相应的释放管道。 释放管道负责收集建筑工材，将其移动到服务器并投入运行。
构建和发布状态 [可在这里访问](#build-test-and-deployment-status)。
## 触发建造、试验和部署。
目前，只有开发者团队的成员可以推送到生产分支。 `production-*` 分支的更改只能通过快速合并到 [`上游`](https://github.com/freeCodeCamp/freeCodeCamp) 降落。
> [!注意] 在今后几天中，我们将通过提取请求来改善这种流动，以更好地管理访问和提高透明度。
### 正在推送对待发布应用程序的更改。
1. 正确配置您的遥控器。
```sh
git 远程-v
```
**结果：**
```
original git@github.com:raisedadead/freeCodeCamp.git (fetch)
origin git@github.com:raisedadead/freeCodeCamp.git (pack)
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (fetch)
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (pus)
```
2. 请确保您的 `主分支` 原始并与上游同步。
```sh
git 签出master
git 获取--all --prune
git reset --hard upstream/master
```
3. 检查Travis CI正在上游的 `主` 分支上。
[连续集成](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) 测试应该是绿色的， `` 分支应该是绿色的。
<details> <summary> 正在检查Travis CI上的状态(屏幕截图) </summary>
<br>
![在 Travis CI 上检查构建状态](https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/master/docs/images/devops/travis-build.png)
</details>
如果这个失败，您应该停止并调查错误。
4. 确认您能够在本地构建资源库。
```
npm 运行清理和开发
```
5. 通过快速合并将更改从 `主` 移动到 `生产暂存`
```
git 签出生产暂存
git 合并主
git 推送上流
```
> [!注意] 您将无法强制推送，如果您已经重写了历史记录，这些命令将会出去。
>
> 如果他们这样做，你可能做了一些不正确的事情，你应该刚刚开始。
上述步骤将自动触发运行于 `生产暂存` 分支的构建管道。 一旦构建完成，伪影将被保存为冷存储中的 `.zip` 文件，以后检索和使用。
当从已连接的构建管道中可以找到新的艺术品时，释放管道会自动触发。 对于暂存平台，这个过程不需要手动批准，伪影被推送到客户端 CDN 和 API 服务器。
> [!TIP|label:估计数] 通常运行需要 ~20-25分钟才能完成安装，客户端运行需要 ~15-20 分钟， 和 ~5-10 分钟让API能够在线使用。 从代码推送到在分阶段平台上运行，整个过程总共需要 **~35-45 分钟**。
### 推送对生产应用程序的更改。
这个过程基本上与中转平台相同，还有几个额外的检查。 这仅仅是为了确保我们不会在 freeCodeCamp.org 上断开任何东西，因为它可以看到数以百计的用户在任何时候使用它。
| 不要执行这些命令，除非您已经验证所有的工作都在暂存平台上。 您不应在继续进行之前绕过或跳过任何预览测试。 |
|:---------------------------------------------------- |
| |
1. 请确保您的 `生产暂存` 分支原始并与上游同步。
```sh
git 签出生产暂存
git 抓取--all --prune
git reset --hard upstream/production-staging
```
2. 通过快速合并将变化从 `生产暂存` 移动到 `生产当前`
```
git 签出当前production-current
git 合并production-staging
git 推送上流
```
> [!注意] 您将无法强制推送，如果您已经重写了历史记录，这些命令将会出去。
>
> 如果他们这样做，你可能做了一些不正确的事情，你应该刚刚开始。
上述步骤将自动触发 `生产-当前` 分支在构建管道上的运行。 一旦建筑工件准备就绪，它将触发释放管道上的运行。
> [!TIP|label:估计数] 通常构建运行需要20-25分钟才能完成。
**工作人员行动的其他步骤**
一个版本运行触发，开发人员团队成员将收到自动手动干预电子邮件。 他们可以通过 _批准_ 或 _拒绝发布_。
如果更改运行得很好，并且已经在暂存平台上测试，那么它就可以被批准。 批准必须在被自动拒绝之前4小时内发出。 员工可以重新启动手动运行的被拒绝的释放，或者等待下一个释放周期。
工作人员使用：
| 请检查您的电子邮件直接链接或 [在构建运行完成后转到发布面板](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release)。 |
|:---------------------------------------------------------------------------------------------- |
| |
一旦一名工作人员批准发布，管道将把更改现场推送到FreeCodeCodeCamp.org的生产CDN和API服务器。 他们通常需要 ~15-20 分钟的客户端，还需要 ~5 分钟的API服务器才能正常使用。
> [!TIP|label:估算] 运行的版本通常需要 ~15-20 分钟，每一个 API 实例的 ~5-10 分钟即可使用。 从代码推送到在生产平台上运行，整个过程总共需要 **~90-120 分钟** (不算等待员工批准的时间)。
## 构建、测试和部署状态
这里是代码库的当前测试、构建和部署状态。
| 类型 | 分支 | 状态 | 仪表板 |
|:----- |:------------------------------------------------------------------------------- |:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |:-------------------------------------------------------------------------- |
| CI 测试 | [`master`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master) | ![Travis CI 构建状态](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=master) | [转到状态仪表板](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| CI 测试 | [`生产暂存中`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | ![Travis CI 构建状态](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=production-staging) | [转到状态仪表板](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| 构建管道线 | [`生产暂存中`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | [![构建状态](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_apis/build/status/dot-dev-ci?branchName=production-staging)](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build/latest?definitionId=15&branchName=production-staging) | [转到状态仪表板](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build) |
| 释放流线 | [`生产暂存中`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | | [转到状态仪表板](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) |
| CI 测试 | [`当前生产`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-current) | ![Travis CI 构建状态](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=production-current) | [转到状态仪表板](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| 构建管道线 | [`当前生产`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | [![构建状态](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_apis/build/status/dot-org-ci?branchName=production-current)](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build/latest?definitionId=17&branchName=production-current) | [转到状态仪表板](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build) |
| 释放流线 | [`当前生产`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | | [转到状态仪表板](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) |
## 早期访问和测试测试版
我们欢迎您在 **"公开测试"** 模式中测试这些版本，并尽早访问平台上即将出现的功能。 有时这些功能/变化会被称为接下来的 **、殴打、挂起** 等。
您通过反馈和发布报告做出的贡献将帮助我们在 `免费CodeCodeCamp上创建生产平台。 rg` 更多 **复原力**, **一致性** 和 **稳定** 对所有人来说都是如此。
我们感谢您报告了您遇到的bug，并帮助使FreeCodeCamp.org变得更好。 你摇一摇！
### 确定平台即将到来的版本
目前有一个公开测试版本：
<h1 align="center"><a href='https://www.freecodecamp.dev' _target='blank'>Freecodecamp.dev</a></h1>
> [!注意] 域名与 **`freeCodeCamp.org`** 不同。 这是为了防止搜索引擎索引并避免平台的普通用户感到困惑。
### 确定平台的当前版本
**The current version of the platform is always available at [`freeCodeCamp.org`](https://www.freecodecamp.org).**
开发团队在发布更改时将从 `生产暂存` 分支合并到 `生产当前` 的变化。 顶部提交应该是您在网站上看到的活动内容。
您可以通过访问状态部分中可用的构建和部署日志来识别部署的确切版本。 或者，您也可以在 [贡献者聊天室](https://gitter.im/FreeCodeCamp/Contributors) 打扰我们以获得确认。
### 已知限制
使用平台的 beta 版本时有一些已知的限制和权衡。
- #### 这些测试平台上的所有数据 / 个人进度 `不会被保存或传输到` 生产。
**测试版上的用户将有一个与生产分开的帐户。** 测试版使用一个与生产分开的实际数据库。 这使我们有能力防止任何意外丢失数据或修改。 开发团队可以根据需要清理这个测试版上的数据库。
- #### 测试平台的使用时间和可靠性没有保障。
预计部署工作将频繁进行，有时是每天多次。 因此，测试版有时会出现意外故障或功能中断。
- #### 不要向这个站点发送普通用户作为确认修复的措施
测试站现在是，而且一直是为了加强当地的发展和测试，没有其它东西。 这不是对即将到来的许诺，而是对正在进行的工作的概述。
- #### 签名页面可能看起来不同于生产
我们在作者0上使用 Freecodecamp.dev 的测试租户，因此没有能力设置自定义域。 这使得所有重定向回调和登录页面都出现在默认域名上： `https://freecodecamp-dev.auth0.com/`。 这不会影响我们能够获得的功能接近生产。
## 报告问题和留下反馈
请为讨论和报告错误打开新问题。 您可以将他们标记为 **[`发布：下次/测试`](https://github.com/freeCodeCamp/freeCodeCamp/labels/release%3A%20next%2Fbeta)** 进行测试。
如果您有任何查询，您可以向 `dev[at]freecodecamp.org` 发送一封电子邮件。 因为所有安全漏洞都应该报告给 `安全[at]Freecodecamp.org` 而不是公共跟踪器和论坛。

326
docs/i18n/Chinese/flight-manuals/moderator-handbook.md Normal file
View File

@ -0,0 +1,326 @@
# 官方免费CodeCamp版主手册。
这将帮助您管理我们社区中的不同地方，包括：
- GitHub 问题 & 合并请求
- 论坛、聊天室、Facebook小组和其他在线会议
- 亲自活动，如学习小组、黑客和会议
**所有免费CodeCamp版主都是全社区的版主。 这意味着我们相信你们能够监督其中的任何地方。**
尽管如此，你可以在你最感兴趣的任何地方担任主持人。 一些版主只是在 GitHub 上帮忙。 其他人只是在论坛上提供帮助。 一些版主在各地都很活跃。
底线是我们想让你享受一个版主， 并将你稀少的时间投入到你感兴趣的地方。
> [!注意] "有了伟大的力量就会有极大的责任。" - Uncle Ben
作为调解人，温度比技术技能更重要。
已收听。 帮忙。 不要滥用你的力量。
免费CodeCamp是一个包容性的社区，我们需要这样做。
我们有一个适用于我们整个社会的单一行为守则。 规则越少，就越容易记住。 您可以阅读这些规则并将其提交到内存 [这里](https://code-of-conduct.freecodecamp.org)。
# Moderating GitHub
版主有能力关闭问题并接受或关闭拉取请求。
主持人对GitHub负有两项主要责任：
1. QA'ing和合并拉取请求
2. 评价和应对问题
## 管理拉取请求
合并请求(PRs) 是贡献者如何向FreeCodeCamp仓库提交更改。 在我们决定是合并还是关闭它们之前，我们必须对合并请求执行质量保证(QA)。
### 合并请求的类型
1. **挑战性说明编辑** 这些是挑战文本――描述、说明或测试文本的更改。 您也可以在 GitHub 上查看这些权利，并决定是否合并它们。 我们需要更加谨慎地对待这些问题，因为数百万人将在通过免费CodeCamp课程工作时遇到这种文本。 拉取请求是否使文本更加清晰而不长久？ 编辑是否相关，是否过于罗盘？ 请记住，我们的目标是使挑战尽可能明确和简短。 他们不是模糊细节的地方。 此外，捐助者可能会设法增加资源与挑战之间的联系。 您可以关闭这些合并请求并回复这些请求：
> 感谢您的拉取请求。
>
> 我正在关闭此拉取请求。 请将链接和其他细节添加到挑战相应的指南文章中。
>
> 如果你认为我关闭这个问题是错误的，请重新打开它并添加进一步的澄清。 谢谢你和快乐的编码。
2. **挑战代码编辑** 这些是挑战中对代码的更改 - 挑战种子、挑战解决方案和测试字符串。 这些合并请求需要从GitHub 下拉并在您的本地计算机上测试，以确保挑战测试仍然可以通过当前的解决方案。 并且新代码不会引入任何错误。 一些贡献者可能会试图添加更多测试以覆盖行星角案例。 我们必须谨慎，不要使这一挑战变得太复杂。 这些挑战及其测试应当尽可能简单和直觉。 除了算法挑战和面谈前部分之外，学员应能够在大约2分钟内解决每个挑战。
3. **代码代码更改** 这些代码更改了免费CodeCamp平台本身的功能。 有时贡献者试图在没有多少解释的情况下进行更改，但是对于代码更改，我们需要确保真正需要改变。 因此，这些拉取请求应参考一个现有的GitHub 问题，因为该问题讨论了变化的原因。 然后您可以在计算机上打开拉取请求并在本地测试它们。 在你这样做之后，如果更改看起来很好，请不要合并它们。 您可以评论拉取请求“LGTM”，然后提及@raisedadead，这样他就可以看到最后的景象。
### 如何合并或关闭合并请求
首先，当您选择一个合并请求到 QA 时，您应该将自己分配给它。 您可以通过点击GitHub 界面右手列的“受让人”下面的“分配给自己”链接来做到这一点。
根据拉请求的类型，遵循上面列出的相应规则。
在合并任何拉取请求之前，请确保GitHub 对一切都有绿色的检查标记。 如果有X，首先对它们进行调查，然后确定如何将它们变成绿色的检查标记。
有时会出现合并冲突。 这意味着另一个拉取请求已经对同一文件的那一部分作了修改。 GitHub 拥有处理GitHub 上这些合并冲突的工具。 你可以尝试解决这些冲突。 只需使用你最好的判断。 合并请求的更改将在顶端，主分支的更改将在底端。 有时会有多余的信息可以删除。 Before you finish, be sure to delete the `<<<<<<`, `======`, and `>>>>>>` that Git adds to indicate areas of conflict.
如果合并请求已准备好合并(不需要@raisedadead的批准)，你可以继续合并它。 请务必使用 GitHub 上的默认“平方和合并”功能。 这将挤掉所有合并请求提交到单个提交，从而使Git历史更容易阅读。
然后你应该评论拉取请求，感谢贡献者自己的个人方式。
如果合并请求的作者是一个“第一次贡献者”, 你也应该祝贺他们第一次合并合并的合并请求到资源库。 你可以看看PR身体的右上角来确定第一次贡献者。 它将显示 `首次贡献者` 如下所示：
![Copy_edits_for_JavaScrip_arrays_article_by_karentobo_%C2%B7_Pull_Request__20615_%C2%B7_freeCodeCamp_freeCodeCamp|690x281](https://i.imgur.com/dTQMjGM.png)
如果拉取请求看来没有准备好合并，你可以长时间回复，告诉作者他们应该做些什么来准备好它。 希望他们能够回复并使他们的拉请求更接近于准备就绪。
拉请求的努力往往很小。 当贡献者没有检查合并请求模板中的复选框时，您可以立即告诉它。 或使用了一个类似于“做出更改”或“更新索引”的通用拉请求标题。 d”。
还有一些情况下，贡献者试图添加一个链接到自己的网站。 或者包含他们自己创建的图书馆，或者有一个无意义的编辑，不能帮助任何人，而只能帮助自己。
在这两种情况下，您应该继续，关闭他们的拉请求并以这个标准信息回答：
> 感谢您打开此拉取请求。
>
> 这是一个通知您的标准消息，我们已经审查了您的合并请求并决定不合并它。 我们欢迎您今后提出拉取请求。
>
> 谢谢你，快乐的编码。
如果您需要对拉请求发表第二个意见，请先着手，然后留下您对拉请求的评论。 然后将"讨论"标签添加到拉取请求。
## 管理 GitHub 问题
免费CodeCamp 是一个活跃的开源项目。 我们每天都有新的问题，所有这些问题都需要尝试和贴上标签。
### GitHub 问题类型
1. **代码帮助请求**，那些人错误地创建了 GitHub 问题。 如果有人请求帮助，请粘贴以下信息，然后关闭问题。
> 感谢您报告这个问题。
>
> 这是一个标准消息，通知您，这个问题似乎是一个请求帮助的请求。 不要在这里寻求帮助，请在免费CodeCamp上点击\*\*“帮助”\*\*按钮。 这将帮助您在论坛的正确部分创建一个问题。 论坛上的志愿者通常在几个小时内回答问题，并可以帮助确定您的代码或挑战的测试是否有问题。
>
> 如果论坛成员确定你的代码没有任何错误，你可以请求重新打开这个问题。
>
> 谢谢你，快乐的编码。
2. **Bug or Clarification issues** Try to reproduce the bug yourself if you can. 如果没有，请他们采取步骤复制错误，他们是否有任何屏幕截图， 视频，或可以帮助您重现问题的附加详细信息。 一旦您可以复制问题 - 或至少确认它是一个legit issue - 标记它 `已确认`。 然后：
- 如果是对现有挑战的简单更改，标记为 `第一次计时器为`，否则标签为 `帮助您想要的`。 使用其他适当的标签。
- 如果这个问题更重要，则标记为 `bug`。 &nbsp; 如果对某个问题的适当行动方针有任何模棱两可之处。 您可以随意在@raisedadead上添加标签。然后添加 `讨论` 标签。
3. **重复问题** 如果一个问题与另一个报告的问题相同, 先前报告的问题应该优先处理。 标记为 `重复`, 粘贴以下信息替换 `#XXXXX` 并使用问题编号, 然后关闭问题。
> 感谢您报告这个问题。
>
> 这是一个标准消息，通知您，这个问题似乎与问题#XXXXX非常相似。 所以我是作为一个重复结案的。
>
> 如果你认为我关闭这个问题是错误的，请重新打开它并添加进一步的澄清。 谢谢你，快乐的编码。
4. **修复了暂存** 一些问题可能已经被解决，但没有与此相关的 GitHub 问题。 如果情况如此，您可以粘贴以下消息，关闭问题，并添加 `状态：解析/配送` 标签：
> 感谢您报告这个问题。
>
> 这是一个标准消息，通知您这里提到的问题存在于生产中。 但这个问题已经被分阶段解决。 这意味着我们下次将我们的分行推向生产时，这个问题应该得到解决。 因此，我要结束这个问题。
>
> 如果你认为我关闭这个问题是错误的，请重新打开它并添加进一步的澄清。 谢谢你，快乐的编码。
### 关闭卡片，过期，不活动的问题和拉取请求
- 陈旧问题或PR是指在21天内没有看到任何活动的问题(最后一次活动的3周内)， 但只有在版主请求更多信息/更改后才能使用。 这些可以由自动/机器人脚本或由版主自己关闭。
- 活动定义为：要求更新的 PR 条目和试用记录，例如 `状态：需要更新的` 标签等。
- 如果执行部分第1段要求提供更多的援助，甚至要求时间，在作出答复后可以放松和重新审查上述情况。 无论如何，模组应利用其最佳判断来解决未决的PR地位。
### GitHub 版主其他准则
虽然你可以写访问FreeCodeCamp的仓库，但 **你不应该直接将代码推到FreeCodeCamp仓库**。 所有代码都应该输入免费CodeCamp的代码，其形式是从仓库的一个叉中的拉取请求。
此外，您不应接受您自己的PR。 他们必须是另一位主持人QA'd，就像其他任何PR一样。
如果你注意到有人在 GitHub 问题上违反了 [行为守则](https://code-of-conduct.freecodecamp.org) ， 或打开含有恶意内容或代码的拉取请求，email dev@freecodecamp。 rg 与冒犯性的拉请求链接，我们可以考虑完全禁止它们加入FreeCodeCamp的GitHub 组织。
# 主持论坛
作为管理员，你帮助我们的社区成为任何人学习和获得帮助的愉快场所。 您将处理已标记的帖子并处理垃圾邮件、主题外和其他不恰当的对话。
请注意，一旦您是论坛版主，您将开始看到论坛成员的蓝色版主提示。 像“这是 [person] 第一次发布-让我们欢迎他们来到社区！ 或 "[person] 已经很长时间没有发布-让我们欢迎他们返回。"
![一个蓝色的文字消息，说 "这是第一次发表了 [person] - 我们欢迎他们加入社区！](https://i.imgur.com/mPmVgzK.png)
这是你们欢迎他们并使他们感到更加特殊的机会。 你从来不知道哪一个人稍有参与可能成为我们的下一个超级帮手，帮助许多其他人在他们编码的旅程。 即使是最小的善意，也可能引发一系列好事。
### 正在删除论坛帖子
论坛版主有能力删除用户的帖子。 您只能为以下实例做这件事：
1. 有人张贴了色情或生动暴力的图像。
2. 有人张贴了一个恶意的链接或代码，可能伤害点击它的其他骆驼。
3. 有人把大量的垃圾信息淹没了一个线程。
### 处理垃圾信息
对于用户的第一个垃圾邮件帖子，向他们发送解释问题的消息，并酌情删除链接或帖子。 在用户的个人资料上留下一个笔记，解释您已经采取的行动。 如果问题仍然存在，就跟随上面的进程。 安静地阻止用户发布(在用户管理面板上使用静音选项)，然后发出警告。 选中私人消息中的复选框，表示您的消息是一个“正式警告”。
您可以在 [员工论坛部分](https://forum.freecodecamp.com/c/staff) 中提问并报告事件。
### 处理主题外对话
似乎在错误地点的职位或专题可以重新分类或重新命名为适当的职位。
在特殊情况下，主持人可能宜将讨论分成多个主题。
同样，如果您有任何问题或疑问，请在工作人员职类中发布您的行动帖子。 并标记其他版主，如果你想要他们审查你的管理操作。
### 未成年用户
我们的服务条款要求免费CodeCamp用户至少13岁。 如果用户发现他们不满13岁， 向他们发送以下消息并删除他们的论坛帐户(如果删除不可用，暂停帐户已足够)。 然后电邮 [Quincy](https://forum.freecodecamp.org/u/QuincyLarson) (quincy@freecodecamp.org) 或 [Mrugesh](https://forum.freecodecamp.org/u/raisedadead) (mrugesh@freecodecamp.org) 也删除用户的 FreeCodeCam。
```markdown
SUBJECT: 13岁以下的用户不允许按照服务条款
使用论坛。我们注意到您未满13岁。 每个[免费CodeCamp服务条款](https://www.freecodecamp.org/news/ters-of-service)，您必须至少13岁才能使用网站或论坛。 我们将删除您的免费CodeCamp帐户和论坛帐户。 这一限制使我们遵守美国法律。
一旦您年满13岁，请重新加入。
谢谢你们的理解。
```
# 审核Facebook
如果你看到任何似乎破坏我们的 [行为准则](https://code-of-conduct.freecodecamp.org/)的东西，你应该立即删除它。
有时，人们会发表他们认为有趣的事情。 他们不知道他们所说的或他们共同的内容可以被解释为冒犯。 在这种情况下，他们的帖子应予删除，但是发布者不一定要被禁止。 如果删除他们的帖子，希望他们能够理解他们所张贴的内容是不恰当的。
但如果这是一种令人震惊的罪行，无法合理地归因于文化差异或对英语的误解， 然后你应该强烈考虑阻止Facebook小组中的成员。
# 审核Discord
这里是版主如何处理违反我们的 [Discord 行为准则](https://code-of-conduct.freecodecamp.org/) 的行为：
1. **确保其目的是违反《行为守则》。** 并非所有违反该守则的行为都是为了这样做。 一个新的骆驼可能会发布大量的帮助代码，不知道这可以被视为垃圾信息。 在这些情况下，您只能要求他们用 Codepen 或 Pastebin 等服务粘贴代码。
2. **如果骆驼明显违反《行为守则》，主持人将采取以下行动：**
- 挂起冒犯的骆驼，但不要警告或威胁他们。 相反，悄悄地给予他们Discord上的暂停角色，然后向他们发送以下消息：
```
这是一条标准消息，通知您我不得不暂时中止您在FreeCodeCamp Discord服务器上的对话。
我是代表我们开放源码社区行事的主持人。 我可以考虑删除你的暂停，但我需要你们先采取以下3个步骤：
1。 阅读我们的行为守则：https://code-of-conduct.freecodecamp.org/
2。 给我回信确认你已经完成了阅读。
3。 向我解释为什么你认为你暂停你的工作，为什么我应该删除你的暂停。
```
- 报告一个简短的事件摘要以及他们在#admin频道中对它的反应。 下面是这种总结可能是什么样子的示例：
```
挂起：_@username_
原因(s): _Spaming, trolling_
证据: _一个或多个链接到触发消息(s)_
CoC: _Sent_
```
- 关于取消暂停的报告应该如下所示：
```
我已经从`@username`中删除了暂停。 我向他们送交了《行为守则》。 就在今天，他们认识到他们被中止，并为他们的所作所为道歉。
```
- 根据犯罪者的答复，调解人将决定是否取消对违规骆驼的暂停。 如果它们似乎是尊重的，也是阿波利萨里奥阵线的成员，主持人可以取消暂停。 作为一项政策，调解人将在这一过程中表现出礼貌，不管冒犯的骆驼有多么糟糕。 如果他们不尊重或不愿意接受CoC，就应该在中止后禁止Discord服务器。 使用与上面相同的摘要，但将“暂停：”改为“禁止：”。
3. **如何禁止和/或解除封禁**
- 为了禁止某人，右键点击他们的用户名/个人资料图片并选择“封禁 <username>". 您将被赋予删除之前消息的选项 - 选择"不要删除任何", 由于这些信息应作为历史记录继续存在。
- 如果你决定禁止某人，这意味着他们不愿意遵守我们的《行为守则》。 因此，取消对一个露营的禁令很少发生。 然而，如果有必要，您可以点击服务器名称，选择“服务器设置”来做到这一点。 选择"禁止"，选择您想要取消禁止的用户，并单击"撤销禁止"。
Discord 禁止是全局性的 - 您不能从指定的频道禁止用户，只能从整个服务器上禁止用户。
4. **正在删除消息** 版主有能力删除Discord上的消息。 他们只能在四种非常具体的情况下行使这种能力：
- 有人张贴了色情或生动暴力的图像。
- 有人张贴了一个恶意的链接或代码，可能伤害点击它的其他骆驼。
- 有人把大量的垃圾信息淹没在聊天室中，达到了极大的程度(通常涉及机器人)，使聊天完全无法使用。
- 有人发布了广告和/或自促的消息/图像(社交媒体)。
在所有其他情况下，即使是行为守则遭到违反的情况下，主持人也不应删除这一信息，因为这些都是一个重要的历史记录。 当您确实删除一条消息时，请确保您先进行屏幕截图！ 屏幕截图可以在 #mod-log 通道登录， 但在 #activity-log 中，只需说证据因敏感内容而被删除就足够了。 注：如果信息含有非法截取的材料， 复制消息链接 - 提供该消息链接到 @raisedadead 转发到 Discord 的信任和安全团队。
5. **不要使用 @everyone 或 @here** 在任何情况下不要使用 @everyone 或 @here ！ 聊天室的每一个人都会收到通知。 在某些情况下，有数万人受到影响。 相反，如果你想让人们看到一个公告，你可以把它固定在频道上，允许每个人阅读它。
6. **不要威胁要封禁或暂停** 如果骆驼破坏了行为守则。 不要威胁禁止或暂停他们，也不要公开警告他们。 相反，与他们私下交谈，或向他们发送一份管理文件并签发中止令(根据上述协议)。 该频道中没有其他人需要知道您已经封禁/暂停了这个人——如果他们想要跟上这个信息，他们可以在 #activity-log 频道中查看摘要。 如果违反行为显然是无意的并且不需要暂停或私下对话， 让冒犯的摄像头知道他/她的行动，而不会被当作警告。 例如：
- 放置一堵要求帮助的代码墙
版主：@username 请使用 Codepen 或 Pastebin 发布大量代码。
- 或者如果你真的必须解释原因：
版主：@username 请使用 Codepen 或 Pastebin 发布大量代码。 因为它扰乱了每个人的聊天，并且可以根据我们的《行为守则》被视为垃圾信息。
- 轻微和无意违反行为守则
主持人：这是一个友好的提醒，让每个人都遵循行为守则：https://code-of-conduct.freecodecamp.org/。
7. **不要担心自己是版主** 不要看到自己在社区上面。 你是社区。 而且社区相信你可以帮助保护我们大家分享的稀有东西——一个新开发者的 _欢迎_ 位置。 如果你敢于成为版主，你周围的人可能会感觉不舒服。 正如人们可能对一名警官感到不安的那样，即使他们没有做任何错事。 这只是人性的。
8. **不要反驳其他版主** 如果您不同意版主的行动。 与他们私下交谈或在#mod-聊天频道中提升它。 永远不要推翻禁令，决不要公开违背其他主持人。 相反，在模式聊天中进行冷却式的讨论，并使主持人相信，他们自己应当扭转禁令或改变他们的观点。 记住：我们都在同一团队。 我们想要使主持人的作用更加光明并提出一个统一的战线。
9. **与其他版主** 我们只有版主空间。 使用它！ 如果你对如何处理某个情势感到不舒服，请其他版主帮忙。 如果你认为应该讨论一些问题，就这样做。 你是团队成员，我们珍视每个团队成员的投入！ 即使你完全不同意这些准则或行为守则中的任何内容！
10. **暂时不活动** 如果你因休假而暂时不活跃作为版主， 疾病或任何其他原因，请务必在 #mod-chet 渠道让其他人知道。 因此，我们知道我们是否可以指望您在服务器上定期活跃。
# 如何成为版主
如果你在一段时间内不断地帮助社区中的人们，我们的版主团队将最终注意到这一点。 并且其中一人会提到你可能是 [我们的工作人员](https://forum.freecodecamp.org/g/Team) 的版主。 没有成为版主的捷径。
如果您获得批准，我们将在 [GitHub](https://github.com/orgs/freeCodeCamp/teams/moderators)、 [论坛](https://forum.freecodecamp.org/g/moderators)等上将您加入我们的版主团队。
> [!注意] > **用于 GitHub :** 在您被接受为版主后，您将收到一个 Github 版本库邀请。 您需要走向 [免费CodeCamp GitHub 组织邀请](https://github.com/orgs/freeCodeCamp/invitation) 才能接受邀请。 为了让您能够在我们的某些仓库上写入访问权限，我们需要这样做。
# 我们如何退休非活动版主
请注意，我们将经常移除我们认为不活跃的模组。 当我们这样做时，我们将发出以下信息：
> 这是一个通知您的标准消息， 由于你最近似乎没有成为活跃的版主，我们正在把你从我们的版主团队中删除。 我们深切感谢你过去的帮助。
> 如果你认为我们这样做是错误的，或者一旦你准备好返回并做出更多贡献， 只是回复此消息，让我知道。
# 我们的贡献者房间是如何工作的
任何人都欢迎来到我们Discord 上的 [贡献者房间](https://discord.gg/KVUmVXA)。 它是为以各种方式为我们社区作出贡献的主持人和其他骆驼骑手指定的聊天室。 包括通过学习小组。
我们的假设是，贡献者将在这个房间中阅读任何直接提到他们的内容，使用 `@username`。 其他一切都是可选的。 但可以随意阅读任何在那里的帖子并进行互动。
# 与律师交易
想要以某种方式与免费CodeCamp合作或共同品牌的组织可能会与您联系。 一旦你认识到这是他们之后的事情，请停止与他们交谈，然后告诉他们电子邮件quincy@freecodecamp.org。 他一直得到这样的建议，并且能够最好地判断这种关系对我们社会是否值得(而且很少有这种关系)。
# 处理（精神）健康调查
您可能会遇到使用者正在寻求医疗咨询或正在处理心理健康问题并寻求支助的情况。 作为一项政策，你应该避免私下谈论这些问题。 如果某个时候的情况反映回到协调委员会，我们希望将对话记录在案。 明确我们不是医疗专业人员，您鼓励用户寻找专业帮助。 尽管有时可能很难，但避免提供任何建议或建议，只是指向用户提供专业帮助！
如果发生在Discord：挂起用户。 这不是为了惩罚他们！ 暂停用户将创建一个只有用户和团队可以访问的私人频道。 这将以几种方式使用户和fCC都受益：
- 用户有些隐私保障
- 公共聊天不再中断。
- 其他团队成员可以进入。如果你不舒服地处理自己的情况
> [!注意] 暂停用户自动给他们一个关于阅读我们的《行为守则》的消息。 请确保您通知用户，您已暂停他们以给他们一些隐私，并且他们不会受到惩罚。 这是非常重要的！ 我们绝对想要避免给用户一种想法，即他们因外出寻求帮助而受到惩罚！
如果您认为用户能够重新加入社区，请右键点击私人频道并复制ID。 将以下消息放入#mod-log中：
> 医疗咨询： <channel ID> <username>
之后，您可以像通常那样从用户中移除暂停。
有用的 URL：
http://www.suicide.org/international-suicide-hotlines.html
# 关于言论自由的笔记
有时，人们会捍卫他们所说的“自由言论”冒犯或煽动性的东西。
这种XKCD漫画完美地概括了大多数社区对言论自由的想法。 所以，如果有人为他们说的“自由发言”辩护，就会自由地向他们发送。
<div align="center"><img src='https://aws1.discourse-cdn.com/freecodecamp/original/3X/4/3/43a8b2eafe4c8622e02838f66f1dc6227de32c70.png' width="400" height="400" /></div>
感谢您阅读这一点，并感谢您帮助开发者社区！

126
docs/i18n/Chinese/flight-manuals/using-reply-templates.md Normal file
View File

@ -0,0 +1,126 @@
# 使用回复模板
这些是您在审查合并请求和尝试问题时可以使用的一些标准回复模板。
> 您可以使用 GitHub 内置的 [**保存的回复**](https://github.com/settings/replies/) 功能或使用下面的功能。
### 谢谢你
```markdown
感谢您对页面的贡献！ :thumbs_up：
我们很高兴接受这些更改，并期待着未来的贡献。 🎉
```
### 谢谢你和组合。
> 感谢并鼓励首次提供捐助者。
```markdown
您好 @username 恭喜您的第一个拉取请求 (PR) ！ :party_poper:
谢谢您对页面的贡献！ :thumbs_up：
我们很高兴接受这些更改，并期待着未来的贡献。 📝
```
### 构建错误
```markdown
您好 @username
我们希望能够合并您的更改，但看起来与 Travis CI 构建有一个错误。 :waring_selector:
一旦您解决了这些问题，我们将能够审阅您的 PR 并合并它。 :smiling_fac_with_smiling_eyes:
----
> 自由参考[撰写文章的风格指南](https://github)。 在正确格式化一篇文章的时候, 这个repo的番茄/免费CodeCamp/免费CodeCamp#article-title) 可以正确格式化你的 Travis CI 构建通行证。 :whit_heavy_check_mark:
>
> 另外，它在 GitHub 上编写您在创建 PR时所作更改的简要说明。 📝
```
### 正在同步Fork
> 当PR 不是最新的 `master` 分支。
``````markdown
您好 @username
我们希望能够合并您的更改，但看起来与 Travis CI 构建有一个错误。 ⚠️
```bash
错误：ENOTDIR: 不是一个目录，打开 'src/pages/java/data-abastraction/index.md'
``````
这个特定的错误不是由您的文件引起的，而是由于将错误代码合并到 `主` 分支而造成的旧错误。 自那时以来，这个问题已得到解决。
要传递这个版本，您必须同步来自 `FreeCodeCamp/freeCodeCodeCamp` 仓库的 `主` 分支的最新更改。
使用命令行，您可以通过以下三个简单步骤做到这一点：
```bash
git 远程添加上游流的 git://github.com/freeCodeCamp/freeCodeCamp.git
git 获取上游流
git 拉取上游流管理员
```
如果您正在使用GUI，您可以只需 `添加一个新的遥控器...` 并使用 `github.com/freeCodeCamp/freeCodeCamp.git` 上面的链接。
一旦你同步你的分叉并通过构建，我们将能够审核并合并它。 😊
---
> 请随时参考GitHub 上的 [同步一个Fork](https://help.github.com/articles/syncing-a-fork/) 文章，以便更深入地了解如何跟上上游版本库更新你的叉。 🔄
>
> 另外，它在 GitHub 上的良好做法是在创建PR时对您的更改作简要说明。 📝
``````
### 合并冲突
> 当PR 合并冲突需要解决时。
```markdown
Hey @username
我们希望能够合并你的更改，但看起来你有一些合并冲突。 :waring_selector:
一旦您解决了这些冲突，我们将能够审阅您的 PR 并合并它。 :smiling_fac_with_smiling_eyes:
----
> 如果你不熟悉合并冲突进程 请随时查看GitHub的指南["解决合并冲突"](https://help)。 ithub.com/articles/resolving-a-merge-conflict on-github/)。 :magnifying_glass_tilted_left：
>
> 另外，GitHub 上的良好做法是在创建PR时对您的更改编写简要说明。 📝
``````
1 如果第一个时间贡献者发生合并冲突，维护者将为他们解决冲突。
### Duplicate
> 当PR 是重复或重复时。
```markdown
你好 @username
这篇文章早些时候已经接受了类似的更改，很抱歉。 :downcast_fac_with_sweat:
如果你觉得要添加更多内容，请随时打开一个新的 PR。
再次谢谢！ :smiling_fac_with_smiling_eyes:
----
> 如果你有任何疑问，请随时通过 [Gitter](https://gitter.im/FreeCodeCamp/Contributors)或通过下面的评论进行联系。 💬
```
### 关闭无效的合并请求
> 当PR 无效
```markdown
您好 @username
您没有添加任何内容，我们将关闭此PR 并将其标记为“无效”。 :downcast_fac_with_sweat:
自由地打开另一个PR ！ 👍
```

475
docs/i18n/Chinese/flight-manuals/working-on-virtual-machines.md Normal file
View File

@ -0,0 +1,475 @@
# Flight Manual for working on Virtual Machines
As a member of the staff or the dev-team, you may have been given access to our cloud service providers like Azure, Digital Ocean, etc.
Here are some handy commands that you can use to work on the Virtual Machines (VM), for instance performing maintenance updates or doing general houeskeeping.
# Get a list of the VMs
> [!NOTE] While you may already have SSH access to the VMs, that alone will not let you list VMs unless you been granted access to the cloud portals as well.
## Azure
Install Azure CLI `az`: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli
> **(One-time) Install on macOS with [`homebrew`](https://brew.sh):**
```
brew install azure-cli
```
> **(One-time) Login:**
```
az login
```
> **Get the list of VM names and P addresses:**
```
az vm list-ip-addresses --output table
```
## Digital Ocean
Install Digital Ocean CLI `doctl`: https://github.com/digitalocean/doctl#installing-doctl
> **(One-time) Install on macOS with [`homebrew`](https://brew.sh):**
```
brew install doctl
```
> **(One-time) Login:**
Authentication and context switching: https://github.com/digitalocean/doctl#authenticating-with-digitalocean
```
doctl auth init
```
> **Get the list of VM names and IP addresses:**
```
doctl compute droplet list --format "ID,Name,PublicIPv4"
```
# Spin a VM (or VM Scale Set)
> Todo: Add instructions for spinning VM(s)
<!--
The below instructions are stale.
### 0. Prerequisites (workspace Setup) for Staff
Get a login session on `azure cli`, and clone the
[`infra`](https://github.com/freeCodeCamp/infra) for setting up template
workspace.
```console
az login
git clone https://github.com/freeCodeCamp/infra
cd infra
```
Use the Scratchpad subdirectory for temporary files, and making one-off edits.
The contents in this subdirectory are intentionally ignored from source control.
### 1. Provision VMs on Azure.
List all Resource Groups
```console
az group list --output table
```
```console
Name Location Status
--------------------------------- ------------- ---------
tools-rg eastus Succeeded
```
Create a Resource Group
```
az group create --location eastus --name stg-rg
```
```console
az group list --output table
```
```console
Name Location Status
--------------------------------- ------------- ---------
tools-rg eastus Succeeded
stg-rg eastus Succeeded
```
Next per the need, provision a single VM or a scaleset.
#### A. provision single instances
```console
az vm create \
--resource-group stg-rg-eastus \
--name <VIRTUAL_MACHINE_NAME> \
--image UbuntuLTS \
--size <VIRTUAL_MACHINE_SKU>
--custom-data cloud-init/nginx-cloud-init.yaml \
--admin-username <USERNAME> \
--ssh-key-values <SSH_KEYS>.pub
```
#### B. provision scaleset instance
```console
az vmss create \
--resource-group stg-rg-eastus \
--name <VIRTUAL_MACHINE_SCALESET_NAME> \
--image UbuntuLTS \
--size <VIRTUAL_MACHINE_SKU>
--upgrade-policy-mode automatic \
--custom-data cloud-init/nginx-cloud-init.yaml \
--admin-username <USERNAME> \
--ssh-key-values <SSH_KEYS>.pub
```
> [!NOTE]
>
> - The custom-data config should allow you to configure and add SSH keys,
> install packages etc. via the `cloud-init` templates in your local
> workspace. Tweak the files in your local workspace as needed. The cloud-init
> config is optional and you can omit it completely to do setups manually as
> well.
>
> - The virtual machine SKU is something like: **Standard_B2s** which can be
> retrived by executing something like
> `az vm list-sizes -l eastus --output table` or checking the Azure portal
> pricing.
-->
# Keep VMs updated
You should keep the VMs up to date by performing updates and upgrades. This will ensure that the virtual machine is patched with latest security fixes.
> [!WARNING] Before you run these commands:
>
> - Make sure that the VM has been provisioned completely and there is no post-install steps running.
> - If you are updating packages on a VM that is already serving an application, make sure the app has been stopped / saved. Package updates will cause network bandwidth, memory and/or CPU usage spikes leading to outages on running applications.
Update package information
```console
sudo apt update
```
Upgrade installed packages
```console
sudo apt upgrade -y
```
Cleanup unused packages
```console
sudo apt autoremove -y
```
# Work on Web Servers (Proxy)
We are running load balanced (Azure Load Balancer) instances for our web servers. These servers are running NGINX which reverse proxy all of the traffic to freeCodeCamp.org from various applications running on their own infrastructures.
The NGINX config is available on [this repository](https://github.com/freeCodeCamp/nginx-config).
## First Install
Provisioning VMs with the Code
### 1. (Optional) Install NGINX and configure from repository.
The basic setup should be ready OOTB, via the cloud-init configuration. SSH and make changes as necessary for the particular instance(s).
If you did not use the cloud-init config previously use the below for manual setup of NGINX and error pages:
```console
sudo su
cd /var/www/html
git clone https://github.com/freeCodeCamp/error-pages
cd /etc/
rm -rf nginx
git clone https://github.com/freeCodeCamp/nginx-config nginx
cd /etc/nginx
```
### 2. Install Cloudflare origin certificates and upstream application config.
Get the Cloudflare origin certificates from the secure storage and install at required locations.
**OR**
Move over existing certificates:
```console
# Local
scp -r username@source-server-public-ip:/etc/nginx/ssl ./
scp -pr ./ssl username@target-server-public-ip:/tmp/
# Remote
rm -rf ./ssl
mv /tmp/ssl ./
```
Update Upstream Configurations:
```console
vi configs/upstreams.conf
```
Add/update the source/origin application IP addresses.
### 3. Setup networking and firewalls.
Configure Azure firewalls and `ufw` as needed for ingress origin addresses.
### 4. Add the VM to the load balancer backend pool.
Configure and add rules to load balancer if needed. You may also need to add the VMs to load balancer backend pool if needed.
## Logging and Monitoring
1. Check status for NGINX service using the below command:
```console
sudo systemctl status nginx
```
2. Logging and monitoring for the servers are available at:
> <h3 align="center"><a href='https://amplify.nginx.com' _target='blank'>https://amplify.nginx.com</a></h3>
## Updating Instances (Maintenance)
Config changes to our NGINX instances are maintained on GitHub, these should be deployed on each instance like so:
1. SSH into the instance and enter sudo
```console
sudo su
```
2. Get the latest config code.
```console
cd /etc/nginx
git fetch --all --prune
git reset --hard origin/master
```
3. Test and reload the config [with Signals](https://docs.nginx.com/nginx/admin-guide/basic-functionality/runtime-control/#controlling-nginx).
```console
nginx -t
nginx -s reload
```
# Work on API Instances
1. Install build tools for node binaries (`node-gyp`) etc.
```console
sudo apt install build-essential
```
## First Install
Provisioning VMs with the Code
1. Install Node LTS.
2. Update `npm` and install PM2 and setup logrotate and startup on boot
```console
npm i -g npm
npm i -g pm2
pm2 install pm2-logrotate
pm2 startup
```
3. Clone freeCodeCamp, setup env and keys.
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
cd freeCodeCamp
git checkout production-current # or any other branch to be deployed
```
4. Create the `.env` from the secure credentials storage.
5. Create the `google-credentials.json` from the secure credentials storage.
6. Install dependencies
```console
npm ci
```
7. Build the server
```console
npm run ensure-env && npm run build:server
```
8. Start Instances
```console
cd api-server
pm2 start production-start.js -i max --max-memory-restart 600M --name org
```
## Logging and Monitoring
```console
pm2 logs
```
```console
pm2 monit
```
## Updating Instances (Maintenance)
Code changes need to be deployed to the API instances from time to time. It can be a rolling update or a manual update. The later is essential when changing dependencies or adding enviroment variables.
> [!DANGER] The automated pipelines are not handling dependencies updates at the minute. We need to do a manual update before any deployment pipeline runs.
### 1. Manual Updates - Used for updating dependencies, env variables.
1. Stop all instances
```console
pm2 stop all
```
2. Install dependencies
```console
npm ci
```
3. Build the server
```console
npm run ensure-env && npm run build:server
```
4. Start Instances
```console
pm2 start all --update-env && pm2 logs
```
### 2. Rolling updates - Used for logical changes to code.
```console
pm2 reload all --update-env && pm2 logs
```
> [!NOTE] We are handling rolling updates to code, logic, via pipelines. You should not need to run these commands. These are here for documentation.
# Work on Client Instances
1. Install build tools for node binaries (`node-gyp`) etc.
```console
sudo apt install build-essential
```
## First Install
Provisioning VMs with the Code
1. Install Node LTS.
2. Update `npm` and install PM2 and setup logrotate and startup on boot
```console
npm i -g npm
npm i -g pm2
npm install -g serve
pm2 install pm2-logrotate
pm2 startup
```
3. Clone client config, setup env and keys.
```console
git clone https://github.com/freeCodeCamp/client-config.git client
cd client
```
```console
git clone https://github.com/freeCodeCamp/client-config.git client
cd client
```
Start placeholder instances for the web client, these will be updated with artifacts from the Azure pipline.
> Todo: This setup needs to move to S3 or Azure Blob storage
>
> ```console
echo "serve -c ../../serve.json www -p 50505" >> client-start-primary.sh
chmod +x client-start-primary.sh
pm2 delete client-primary
pm2 start ./client-start-primary.sh --name client-primary
echo "serve -c ../../serve.json www -p 52525" >> client-start-secondary.sh
chmod +x client-start-secondary.sh
pm2 delete client-secondary
pm2 start ./client-start-secondary.sh --name client-secondary
```
## Logging and Monitoring
```console
pm2 logs
```
```console
pm2 monit
```
## Updating Instances (Maintenance)
Code changes need to be deployed to the API instances from time to time. It can be a rolling update or a manual update. The later is essential when changing dependencies or adding enviroment variables.
> [!DANGER] The automated pipelines are not handling dependencies updates at the minute. We need to do a manual update before any deployment pipeline runs.
### 1. Manual Updates - Used for updating dependencies, env variables.
1. Stop all instances
```console
pm2 stop all
```
2. Install or update dependencies
3. Start Instances
```console
pm2 start all --update-env && pm2 logs
```
### 2. Rolling updates - Used for logical changes to code.
```console
pm2 reload all --update-env && pm2 logs
```
> [!NOTE] We are handling rolling updates to code, logic, via pipelines. You should not need to run these commands. These are here for documentation.

125
docs/i18n/Chinese/how-to-catch-outgoing-emails-locally.md Normal file
View File

@ -0,0 +1,125 @@
> **注意：** 这是一个 **可选的** 步骤，并且仅在处理电子邮件工作流时需要
## 一. 导言
一些电子邮件工作流，如更新用户的电子邮件，需要后端api-server发送发送电子邮件。 一个替代使用电子邮件服务提供商发送实际邮件信息的替代办法 Mailhog 是电子邮件测试的开发者工具，它将捕获您的FreeCodeCamp实例发送的邮件。
## 正在安装 MailHog
MailHog可以在 macOS, Windows 和 Linux 上安装。
- [一. 导言](#introduction)
- [正在安装 MailHog](#installing-mailhog)
- [在 macOS 上安装 MailHog。](#installing-mailhog-on-macos)
- [在 Windows 上安装 MailHog](#installing-mailhog-on-windows)
- [在 Linux 上安装 MailHog。](#installing-mailhog-on-linux)
- [使用 MailHog](#using-mailhog)
- [有用的链接](#useful-links)
### 在 macOS 上安装 MailHog。
使用 [自制程序](https://brew.sh/) 在 macOS 上安装 MailHog：
```bash
酿造安装mailhog
酿造服务开始邮件hog。
```
上述命令将在后台启动邮件钩子服务。
安装完成后，您可以使用 MailHog</a> 启动
。</p>
### 在 Windows 上安装 MailHog
从 [MailHog的官方存储库](https://github.com/mailhog/MailHog/releases) 下载最新版本的 MailHog。 定位并点击您的 Windows 版本 (32 或64 位) 的链接，一个 .exe 文件将下载到您的计算机。
下载完成后，点击打开文件。 可能出现了 Windows 防火墙通知，请求访问 MailHog的权限。 标准的 Windows 命令行提示将打开，一旦获得防火墙访问许可，MailHog将在那里运行。
关闭命令提示窗口以关闭 MailHog。 若要再次启动 MailHog，请点击MailHog可执行文件 (。)。 (xe) 最初下载的文件 - 无需下载新的 MailHog安装文件。
使用 MailHog</a> 启动 。</p>
### 在 Linux 上安装 MailHog。
首先，安装 [升级](https://golang.org)。
运行以下命令，在基于 Debian的系统上安装 GO，如Ubuntu 和 Linux Mint 。
```bash
sudo apt-get install golang
```
运行以下命令，在基于 RPM 的系统上安装GO，如CentOS、Fedora、Red Hat Linux 等。
```bash
sudo dnf install golang
```
或者，运行下面的命令来安装GO。
```bash
sudo yum install golang
```
现在设置下面命令的路径。
```bash
echo "export GOPATH=$HOME/go" >> ~/.profile
echo 'export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin' >> ~/.profile
source ~/.profile
```
最后，输入下面的命令来安装和运行 MailHog。
```bash
go get github.com/mailhog/MailHog
sudo cp /home/$(whoami)/go/bin/MailHog /usr/local/bin/mailhog
mailhog
```
使用 MailHog</a> 启动 。</p>
## 使用 MailHog
打开一个新的浏览器标签页或窗口，并导航到 [http://localhost:8025](http://localhost:8025) 来打开您的 MailHog收件箱，当MailHog安装完成并且正在运行 MailHog。 收件箱将显示类似于下面的屏幕截图。
![MailHog屏幕截图 1](images/mailhog/1.jpg)
您的免费CodeCamp安装发送的电子邮件将显示在下方：
![MailHog屏幕截图 2](images/mailhog/2.jpg)
当您打开指定的电子邮件时，允许您查看纯文本或源内容的两个选项卡。 确保下面选择纯文本标签。
![MailHog屏幕截图 3](images/mailhog/3.jpg)
电子邮件中的所有链接都应该可以点击并解决到他们的URL。
## 有用的链接
- 查看 [MailHog](https://github.com/mailhog/MailHog) 存储库以获取更多与 MailHog相关的信息。 关于自定义MailHog配置的额外信息也可用。

199
docs/i18n/Chinese/how-to-help-with-video-challenges.md Normal file
View File

@ -0,0 +1,199 @@
# 如何帮助应对视频挑战
视频挑战是免费CodeCamp课程中一种新型挑战。
视频挑战是关于某一特定主题的长篇视频课程的一小部分。 视频挑战页面包含YouTube视频。 每个挑战页面都有一个与视频相关的多项选择问题。 在课程中继续下一个视频挑战之前，用户必须正确回答这个问题。
视频挑战页面是由免费CodeCamp团队成员创建的。 YouTube视频也由免费CodeCamp团队成员上传。 许多视频挑战还没有与此相关的问题。
您可以通过创建与视频部分相关的多个选择问题以及为视频挑战将问题添加到Markdown文件中来提供帮助。
## 挑战模板
下面是挑战Markdown 文件的模板。
````md
---
id: 唯一标识符 (字母数字, MongoDB_id
title: Challenge Title
challengeType: 11
video Id: 'YouTube video Id for video challenge'
--
## 描述
<section id='description'>
可选描述，带有与视频有关的有用信息。
</section>
## 测试
<section id='tests'>
```yml
问题:
text: 'Question'
答案:
- '答案 On'
- '答案两'
- '答案三'
解决方法: 3
````
</section>
````
## 为视频挑战创建问题
### 访问视频挑战Markdown 文件
您可以在以下课程中找到视频挑战的 markdown 文件：
- [与Python Course的数据分析](https://github)。 om/freeCodeCamp/freeCodeCamp/tree/master/courum/challenges/english/08/data-analysis-with-Python/data-analysis-with-python-course)
- [TensorFlow 2.0 Course](https://github)。 om/freeCodeCamp/freeCodeCamp/tree/master/curcourum/challenges/english/11-mechanise-learning-with-python/tensorflow)
- [数字课程](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/courum/challenges/english/08-data-analysis-with-python/numpy)
- [如何神经网络工作课程](https://github.com/freeCodeCamp/tree/master/courum/challenges/english/ 111-mechande-learning-with-python/how -neural-networks-work)
从上述选项
### Skim through the video associated with the challenge and create a mutiple option question
First, seek the video Id.
例如，在视频挑战标记文件页眉的下面代码中，视频Id 是“nVAaxZ34khk”。 关于GitHub，信息应以表格格式排列。
````
---
id: 5e9a093a74c4063ca6f7c14d title: Data Analysis 示例A challengeType: 11
videoId: nVAaxZ34khk
---
```
接下来，使用该视频ID访问YouTube视频。 视频的 url 将是：
https://www.youtube om/watch?v=[videoId] (将视频Id 添加到没有方括号的URL)
在上面的例子中，网址是 https://www。 outube.com/watch?v=nVAaxZ34khk
用该视频Id Skim YouTube视频，并想到一个基于视频内容的多个选择问题。
### 添加问题到Markdown文件
您可以在本地或直接通过 GitHub 接口添加问题。 要在本地添加问题，您需要[本地设置免费CodeCamp](howto setup-freecodecamp-locally.md)。 您也可以在 GitHub 上找到文件，然后点击编辑按钮在您的浏览器中添加问题。
如果一个问题尚未添加到某个视频挑战中， 它将有以下默认问题:
```yml
问题:
文本: |
问题
答案:
- |
一个
- |
两个
- |
三个
解决方法: 3
```
用你的问题更新“问题”一词。 用可能的答案更新“一个”、“两个”和“三个”。 请务必更新答案正确的解决方案号。 您可以使用相同的格式添加更多可能的答案。 问题和答案可以用引号包围。
#### 使用 Markdown 格式化您的问题
问题中的文本被解析为Markdown。 确保正确格式化的最简单方式是用 `文本开始提问：|`如这样：
```yml
问题:
文本: |
问题
```
然后您需要确保您的问题在新的行上，并且缩进了一个级别超过 `文本：|`。
同样的方法可以用来回答整个问题。
```yml
问题:
文本: |
问题
答案:
- |
第一个答案
- |
第二个
- |
第三个
解决方案: 2
```
请确保每个答案都是合理的，但只有一个正确的答案。
#### 使用 HTML
问题和答案可以包含某些HTML标签，如 `<br>` 作为新行。 当问题无法在没有它们的情况下表达时，应该少量使用HTML标记。
### 提问示例
#### 没有HTML的示例
````yml
问题:
文本: |
此 JavaScript 代码日志到控制台是什么？
```js
console.log('hello world');
````
选择答案！
回答：
- | 你好 *世界*
- | **你好** 世界
- | 你好世界 解决方案: 3
````
``yml
问题:
text: |
运行此代码后打印出来的内容:
```py
宽度 = 15
高度 = 12。
打印(height/3)
````
回答：
- | 39
- | 4
- | 4.0
- | 5.0
- | 5 解决方案: 3
````
#### HTML
```yml
问题的示例：
text：|
运行此代码后会打印什么：
<pre><code>宽度= 15<br>高度 = 12。<br>打印(height/3)<code></pre>
答案：
- |
39
- |
4 - |
- |
4
- |
5.
- |
5
解决方法: 3
````
最后一个例子表明，HTML可以使用，但它不能像没有它的版本那样可读。
更多的示例，您可以查看下一个视频课程的 markdown 文件。 所有挑战都已经有问题： [Python适用于每个人课程](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/07-scientific-computing-with-python/python-for-everybody)
## 打开拉取请求
在创建一个或多个问题后，您可以将更改提交给一个新分支并 [打开一个拉取请求](how-to-open-a-pull-request.md)。

179
docs/i18n/Chinese/how-to-open-a-pull-request.md Normal file
View File

@ -0,0 +1,179 @@
# 如何打开合并请求 (PR)
一个拉取请求使您能够将您在 GitHub 上的分叉中的更改发送到FreeCodeCodeCamp.org的主仓库中。 一旦您完成了代码的更改或编码挑战，您应该遵循这些指南来发送一个 PR。
## 准备一个好的 PR 标题
我们建议使用 [常规标题和消息](https://www.conventionalcommits.org/) 来提交和拉取请求。 公约有以下形式：
> `<type>([可选范围(s)]): <description>`
>
> 例如：
>
> `修复(学习)：在循环挑战的同时进行此项测试......`
当打开合并请求(PR)，您可以使用下面的方法来确定类型、范围(可选)和描述。
**类型:**
| 类型 | 何时选择 |
|:---- |:--------------------- |
| 修复 | 已更改或更新/改进功能、测试、课本等。 |
| feat | 仅当您正在添加新功能、测试等。 |
| 合唱团 | 与课程的代码、测试或顶点无关的更改。 |
| 文档 | 更改为 `/docs` 目录或贡献指南等。 |
**范围：**
您可以从 [此标签列表](https://github.com/freeCodeCamp/freeCodeCamp/labels?q=scope) 中选择一个范围。
**Description:**
保持简短(小于30个字符)，您可以在 PR 描述框和评论中添加更多信息。
优秀PRs标题的一些例子包括：
- `修复(a11): 改进搜索栏对比度`
- `功能：添加更多测试到 html 和 css 挑战`
- `修复 (api,client): 防止提交窗体时发生CORS 错误`
- `docs(i18n)：本地设置的中文翻译`
## 提出拉取请求
1. 一旦编辑完成，您将被提示在您的 GitHub 页面上创建一个拉取请求。
![图像 - 比较GitHub 上的拉取请求](./images/github/compare-pull-request-prompt.png)
2. 默认情况下，所有合并请求都应该与免费CodeCamp的主仓库相对应， `主分支`。
请确保您的基叉已设置为免费CodeCamp/免费CodeCamp 在提升合并请求。
![图像 - 在提出拉取请求时比较叉数](./images/github/comparing-forks-for-pull-request.png)
3. 将您的分支拉取请求提交给FreeCodeCamp的 `主` 分支。
4. 在您的 PR 正文中包含一个更详细的您所做的更改及其原因。
- 您将收到拉请求模板。 这是一个您在打开拉取请求之前应该遵循的核对表。
- 填写你认为合适的详细信息。 此信息将被审核，审核者将决定您的拉取请求是否被接受。
- 如果PR 是为了解决现有的 GitHub 问题，那么，在 结束时，您的 PR's 描述实体， 使用关键字 _关闭了有问题号的_ 到 [自动关闭了该问题，如果接受并合并了](https://help.github.com/en/articles/closing-issues-using-keywords)。
> 示例： `关闭 #123` 将关闭问题 123
5. 注明是否在网站的本地副本上进行过测试。
在进行不仅仅是编辑文档或挑战描述等文本内容的更改时，这一点非常重要。 需要本地测试的更改实例包括JavaScript、CSS 或 HTML 可能改变页面功能或布局。
## 对合并请求的反馈
> 恭喜！ :tada: 即将创建一个PR 并非常感谢花费时间做出贡献。
我们的版主现在看看看并留下反馈。 请耐心看看同伴版主并尊重他们的时间。 所有合并请求都在适当时候得到审查。
如果您需要任何帮助，请在 [贡献者聊天室](https://gitter.im/FreeCodeCamp/Contributors)中讨论，我们非常乐意帮助您。
> [!提示] 如果您想要提交更多的拉取请求。 我们建议您阅读 [做出更改并同步](https://contribute.freecodecamp.org/#/how-to-setup-freecodecamp-locally?id=making-changes-locally) 指南，以避免必须删除您的叉。
## 在合并请求上冲突
可能会发生冲突，因为许多贡献者在仓库中工作，并且更改可能会破坏您正在等待审查和合并的PR 。
你可能经常不需要重置基地，因为我们会挤掉所有的提交， 但是，如果在此请求重置基础，这是你应该做的。
### 通常错误修复和功能
When you are working on regular bugs and features on our development branch `master`, you are able to do a simple rebase:
1. 重置您的本地副本：
```console
git 结帐 <pr-branch>
git pull --rebase 上游管理员
```
2. 解决任何冲突并添加/编辑提交
```console
#
git 添加 .
git 提交 -m "chore: 解决冲突"
# 或
git 添加 .
git 提交 --revise --no-edit
```
3. 将您的更改推回到PR
```console
git 推送--force 来源 <pr-branch>
```
### 即将开设的课程和功能
当您正在为我们即将上来的课程 `下一个*` 分支开发功能时，您已经做了一次棋盘选择：
1. 请确保您的上游与您的本地同步：
```console
git 签出master
git 获取--all --prune
git 签出下一个 python-project
git 重置 --hard upstream/next python-projects
```
2. 备份备份
a. 备份后删除您的本地分支(如果您仍然有本地分支)：
```console
git 结帐 <pr-branch-name>
# 示例：
git 结帐功能/附加numpy-video-question
git 结帐-b <backup-branch-name>
# 示例：
# git 结帐-b 备份功能/附加numpy-video-question
git branch -D <pr-branch-name>
```
b. 会议文件。 或者仅备份您的 pr 分支(如果您没有本地分支的话)：
```console
git 结帐-b <backup-branch-name> origin/<pr-branch-name>
# 例如：
# git 结帐-b b备份功能/附加numpy-video question origin/feate/addnumpy-video question
```
4. 开始时有一个干净的套件：
```console
git 签出 -b <pr-branch-name> 下一个 python-projects
git cherry-self <commit-hash>
```
5. 解决任何冲突并清理，安装运行测试
```console
npm 运行清洁
npm ci
npm 运行测试:course --superblock=<superblock-name>
# 例如：
# npm 运行测试:course --superblock=python-for everyone
```
6. 如果一切看起来都很好，请回到PR
```console
git 推送--force 来源 <pr-branch-name>
```

546
docs/i18n/Chinese/how-to-setup-freecodecamp-locally.md Normal file
View File

@ -0,0 +1,546 @@
遵循这些准则在您的系统上本地建立免费CodeCamp。 如果您想要定期捐款，这将是强烈推荐的。
对于一些贡献的工作流，您需要在本地运行免费CodeCamp。 例如，预览编码挑战或调试和修复编解码器中的bug。
> [!提示] 如果您不想在本地建立免费CodeCamp，请使用 Gitpod，免费的在线开发环境。
>
> [![在 Gitpod 中打开](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
>
> (在您的浏览器中为FreeCodeCodeCamp启动一个现成的开发环境。)
## 准备您的本地机
首先为您的操作系统安装必备软件。
我们主要支持开发 **\*nix** 系统。 我们的工作人员和社区贡献者经常使用安装在 Ubuntu 和 macOS 上的工具与代码库合作。
我们还通过 WSL 2 支持Windows 10，您可以通过 [阅读本指南](/how-to-setup-wsl) 来准备它。
一些社区成员还在Windows 10上使用Git for Windows (Git Bash)开发，以及安装在Windows上的其他工具。 我们目前对这种设置没有官方支持，我们建议使用WSL2。
**前提条件：**
| 前提条件： | 版本 | 注 |
| ---------------------------------------------------------------------------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
| [Node.js](http://nodejs.org) | `12.x` | [LTS 计划](https://github.com/nodejs/Release#release-schedule) |
| npm (随后与节点捆绑) | `6.x` | 没有LTS版本，我们使用与节点LTS捆绑的版本 |
| [MongoDB 社区服务器](https://docs.mongodb.com/manual/administration/install-community/) | `3.6` | [发布笔记](https://docs.mongodb.com/manual/release-notes/), 注意：我们目前在 `3.6`, 计划进行 [升级](https://github.com/freeCodeCamp/freeCodeCamp/issues/18275) |
> [!DANGER] 如果您有不同的版本，请安装推荐版本。 我们只能支持推荐版本的安装问题。 详情见 [故障排除](#troubleshooting)。
如果Node.js已经安装在您的机器上，运行以下命令来验证版本：
```console
节点-v
npm -v
```
> [!提示] 我们强烈建议更新上面列出的软件的最新稳定版本，也称为长期支持(LTS)版本。
一旦安装了前提条件，您需要准备您的开发环境。 这对许多发展工作流来说是常见的，你只需要做一次这么做。
**按照这些步骤准备好您的发展环境：**
1. 如果您还没有安装 [Git](https://git-scm.com/) 或您最喜欢的 Git 客户端。 更新到最新版本；与您的操作系统捆绑的版本可能已经过时。
2. (可选但推荐) [为 GitHub 设置一个 SSH 密钥](https://help.github.com/articles/generating-an-ssh-key/)。
3. 安装您选择的代码编辑器。
我们强烈建议使用 [Visual Studio 代码](https://code.visualstudio.com/) 或 [Atom](https://atom.io/)。 这些是巨大的、免费的和开源代码编辑器。
4. 为您的代码编辑器设置行号。
您应该在您的编辑器中运行 [ESLint](http://eslint.org/docs/user-guide/integrations.html)并且它将突出任何不符合 [免费CodeCamp的 JavaScript 风格指南](http://forum.freecodecamp.org/t/free-code-camp-javascript-style-guide/19121) 的内容。
> [!提示] 请不要忽略任何行号错误。 They are meant to **help** you and to ensure a clean and simple codebase.
## 在 GitHub 上派生仓库
[Forcing](https://help.github.com/articles/about-forks/) 是你在GitHub 上获取你自己的 FreeCodeCamp的主要存储库 (a.k.a _repo_) 的一个步骤。
这是非常重要的，因为它允许您在GitHub上使用您自己的免费CodeCamp， 或者下载 (克隆) 您的资源库在本地工作。 稍后，您将能够通过拉取请求(PR)从分叉中提取到主存储库。
> [!TIP] 主仓库在 `https://github.com/freeCodeCamp/freeCodeCode` 经常被称为 `上游的` 仓库.
>
> 您在 `https://github.com/YOUR_USER_NAME/freeCodeCamp` 的叉经常被称为 `来源` 资源库。
**按照这些步骤派生 `https://github.com/freeCodeCamp/freeCodeCodeCamp` 仓库：**
1. 转到GitHub上的免费CodeCamp仓库： [https://github.com/freeCodeCodeCamp/freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp)
2. 点击接口右上角的“Fork”按钮([此处有更多详细信息](https://help.github.com/articles/fork-a-repo/))
3. 当仓库被解压后，你将被带到你的免费CodeCamp 仓库的副本： `https://github.com/YOUR_USER_NAME/freeCodeCamp`
<details>
<summary>
如何派生GitHub 上的 FreeCodeCamp (screshot)
</summary>
<br>
<img src="https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/master/docs/images/github/how-to-fork-freeCodeCamp.gif" alt="如何在 GitHub 上派生免费CodeCamp" />
</details>
## 从GitHub 复制你的叉文件
[克隆](https://help.github.com/articles/cloning-a-repository/) 是您的位置 **下载** 从 `远程` 处下载的仓库副本，由您或其他人拥有。 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`.
在本地机器上运行这些命令：
1. 在您的工程目录中打开终端/命令提示/Shell
_i.e. : `/你的项目目录/`_
2. 克隆你的免费CodeCamp，用你的 GitHub 用户名替换 `YOUR_USER_NAME`
```console
git 克隆--depth=1 https://github.com/YOUR_USER_NAME/freeCodeCamp.git
```
这将下载整个免费CodeCamp 仓库到您的项目目录。
注意： `--depth=1` 创建了一个你的叉中的浅色克隆，只有最近的历史/提交。
## 设置父同步
既然你已经下载了你的叉副本，你将需要设置一个 `上游` 远程到父仓库中。
[如前面提到的](#fork-the-repository-on-github), 主仓库已被调用 `上游的` 仓库. 你的叉被称为 `来源` 仓库。
除了 `来源于` 仓库外，您还需要本地克隆的引用到 `上游` 存储库。 这是为了您可以同步主仓库中的更改，而无需重复叉和克隆。
1. 将目录更改为新的 FreeCodeCamp 目录：
```console
cd 免费CodeCamp
```
2. 添加远程引用到主FreeCodeCamp仓库：
```console
git 远程添加上游版 https://github.com/freeCodeCamp/freeCodeCamp.git
```
3. 确保配置正确：
```console
git 远程-v
```
输出应该像下面这样：
```console
原点 https://github.com/YOUR_USER_NAME/freeCodeCamp.git (fetch)
原点 https://github.com/YOUR_USER_NAME/freeCodeCamp.git (pack)
上游流https://github.com/freeCodeCamp/freeCodeCamp.git (fetch)
上游流 https://github.com/freeCodeCamp/freeCodeCamp.git (pus)
```
## 在本地运行免费CodeCamp
现在你有一个本地的免费CodeCamp，你可以按照这些指示在本地运行。 这将允许您：
- 预览将出现在学习平台上的页面.
- 4. 关于与用户界面有关的问题和改进的工作。
- 与应用程序服务器和客户端应用程序调试和修复问题。
如果您确实遇到了问题，请先对您的问题进行网页搜索，并查看是否已经回答过了。 如果您找不到解决方案， 如果尚未报告，请搜索我们的 [GitHub 问题](https://github.com/freeCodeCamp/freeCodeCamp/issues) 页面并报告问题。
一如既往， 觉得可以随时连接到我们的 [贡献者聊天室在 Gitter](https://gitter.im/FreeCodeCamp/Contributors) 或 [我们的 Discord 服务器](https://discord.gg/6vJYm9V), 快速查询。
> [!提示] 如果你只是编辑文件，你可能会跳过本地免费运行CodeCamp。 例如，执行 `rebase`, 或解决 `合并` 冲突。
>
> 以后您总是可以返回说明的这一部分。 You should **only** skip this step if you do not need to run the apps on your machine.
>
> [跳过进行更改](#making-changes-locally)。
### 配置依赖项
#### 第 1 步：设置环境变量文件
默认 API 密钥和环境变量存储在文件 `sample.env` 中。 此文件需要复制到一个名为 `.env` 的新文件，该文件是在安装过程中动态访问的。
```console
# 创建一个 "sample.env" 的副本，并命名它".env"。
# 用必要的 API 密钥和密钥填充它：
# macOS / Linux
cp 样本。 nv .env
# Windows
复制 sample.env .env
```
`.env` 文件中的密钥 _并不需要更改_ 才能本地运行应用程序。 您可以保留从 `sample.env` 复制的默认值。
> [!提示] 如果您想要使用像Auth0 或 Algolia 这样的服务，请记住。 您必须为这些服务获取您自己的 API 密钥，并相应地在 `中编辑条目。 nv` 文件。
#### 步骤 2: 安装依赖关系
此步骤将安装应用程序运行所需的依赖关系：
```console
npm ci
```
#### 步骤 3: 启动 MongoDB 并种子数据库
在本地运行应用程序之前，您需要启动 MongoDB 服务。
> [!注意] 除非您在 MongoDB 中运行的设置不同于默认， 在 `中存储为 <code>MONGOHQ_URL` 值的 URL。 nv</code> 文件应该正常工作。 如果您正在使用自定义配置，请根据需要修改此值。
在 MongoDB 服务器单独的终端中启动：
- 在 macOS & Ubuntu：
```console
mongod
```
- 在 Windows上，您必须指定 `怪物` 双进制的完整路径
```console
"C:\Program Files\MongoDB\Server\3.6\bin\mongod"
```
请确保将 `3.6` 替换为您已安装的版本
> [!提示] 您可以通过安装它作为后台服务来避免每次启动 MongoDB 。 您可以 [在他们为您的操作系统提供的文档中了解更多关于它的信息](https://docs.mongodb.com/manual/administration/install-community/)
接下来，让我们来做数据库的种子。 在这个步骤中，我们运行下面的命令，将MongoDB 服务器填充一些服务所需的初始数据集。 除其他外，其中包括一些计划。
```console
npm 运行种子
```
#### 步骤 4: 启动免费CodeCam客户端应用程序和 API 服务器
您现在可以启动 API 服务器和客户端应用程序。
```console
npm 运行开发
```
这个单一命令将会发射所有的服务，包括API服务器和客户端应用程序供您使用。
> [!注意] 一旦准备就绪, 打开网页浏览器和 **访问 <http://localhost:8000>** 如果应用程序加载，恭喜——你都已设置！ 您现在有一个免费CodeCamp的整个学习平台在您的本地机器上运行。
> [!提示] API 服务器在 `http://localhost:3000` 上提供 API。 Gatsby应用在 `http://localhost:8000` 为客户端应用程序服务
> 如果您访问 <http://localhost:3000/explorer> ，您应该看到可用的 API。
## 使用本地用户登录
您的本地设置自动将本地用户添加到数据库中。 点击 `登录` 按钮将自动认证您进入本地应用程序。
然而，访问用户组合页面有点微妙。 在发展中， Gatsby接管了客户端页面的服务，因此在本地工作时，您将获得用户组合的 `404` 页面。
只需点击 **"预览自定义 404 页面"** 按钮会将您转到正确的页面。
<details>
<summary>
如何在本地工作时登录 (屏幕截图)
</summary>
<br>
<img src="https://user-images.githubusercontent.com/29990697/71541249-f63cdf00-2923-11ea-8a85-cefb6f9c9977.gif" alt="如何在本地工作时登录" />
</details>
## 在当地进行变化
您现在可以对文件进行更改并将您的更改提交给您的本地叉。
跟随这些步骤：
1. 验证您在 `master` 分支：
```console
git status
```
您应该获得如下输出：
```console
对于分支管理员
您的分支是最新的，带有“原始/主”
无需提交，工作目录清理
```
如果您不在主目录，或者您的工作目录没有被清理，解决任何未处理的文件/提交和结帐 `主`:
```console
git 结帐管理员
```
2. 从上游的FreeCodeCamp `master` 分支同步到您的本地主分支的最新更改：
> [!警告] 如果你有任何未完成的拉取请求是从你的叉的 `主` 分支提出的 在这一步结束时，你会丢失他们。
>
> 您应该确保您的拉取请求在执行此步骤之前由版主合并。 To avoid this scenario, you should **always** work on a branch other than the `master`.
这个步骤 **将同步来自免费CodeCamp主要仓库的最新更改**。 重要的是您尽可能频繁地将分支重新建立在最新的 `上面/主` 上面，以避免以后发生冲突。
更新您本地的 FreeCodeCamp 上游版本库：
```console
git 获取上流
```
使用免费CodeCamp大师重置您的主分支：
```console
git 重置 --hard 上游/管理员
```
将您的主分支推送到您的原始位置，在GitHub上的叉上有一个干净的历史记录：
```console
git 推送原始主--force
```
您可以通过执行一个分支来验证您当前的主匹配的上游/主：
```console
git diff 上游/大师
```
生成的输出应为空。
3. 创建新分支：
为每个问题单独工作一个分支有助于您保持本地工作副本干净。 你永远不应该在 `主` 上工作。 这将使您的免费CodeCamp的副本土生土长，并且您可能必须从新的克隆或叉开始。
检查您是否像以前解释过的那样在 `主` 上，并从那里关闭分支：
```console
git 结帐-b fix/update-guide-for-xyz
```
您的分支名称应该以 `修复/`、 `feature/`、 `docs/`等开头。 避免在分支中使用问题编号。 保持其简短、有意义和独特性。
良好的分支名称的一些例子包括：
```md
修复/update-challenges-for-action
fix/update-guide-for-html-css
fix/platform-bug-sign-in issues
feat/add-guide-article-for-javascript
translate/add-spanish-basic-html
```
4. 在您最喜欢的文本编辑器中编辑页面并使用代码。
5. 一旦您对更改感到满意，您应该可以在本地免费运行CodeCamp来预览更改。
6. 请确保您修复任何错误并检查您更改的格式。
7. 检查并确认您正在更新的文件：
```console
git status
```
这将显示您编辑的 `未发布的` 文件列表。
```console
对于分支功能/文档
您的分支是最新的 "upstream/feate/documentation"。
更改尚未提交：
(使用 git add/rm <file>... 更新将要执行的内容
(使用 "git 结帐" - <file>." 放弃工作目录中的更改)
修改: CONTRIBUTING。 d
修改：docsor README.md
修改：docs/howto setup-freecodecamp-local。 d
修改: docs/how-work-on-guide-articles.md
...
```
8. 阶段更改并提交：
在这个步骤中，您只应标记您自己编辑或添加的文件。 您可以执行重置和解析文件，如果需要，您不打算更改这些文件。
```console
git 添加路径到/my/changed/file.ext
```
或者您可以将所有 `未发布的` 文件添加到暂存区域：
```console
git 添加
```
只有移到暂存区域的文件才会在提交时被添加。
```console
git status
```
输出:
```console
对于分支功能/文档
您的分支是最新的 "upstream/feate/documentation"。
要进行的更改：
(使用 "git reset HEAD <file>..." to unstage)
修改：CONTRIBUTING.md
修改：docs/README.md
修改：docs/howto setup-freecodecamp-locally.md
修改：docs/how-work-on-guide-articles.md
```
现在，您可以用这样一个简短的消息来提交您的更改：
```console
git 提交 -m "修复：我的短提交信息"
```
一些例子：
```md
修复：为 Java 更新指南文章 - 循环
功能：为alexa 技能添加指南文章
```
可选：
我们强烈建议发表一项常规承诺信息。 这是一个好的做法，您将在一些受欢迎的开源仓库中看到。 作为开发者，这鼓励您遵循标准做法。
常规承诺信息的一些例子是：
```md
修复：更新 HTML 指南文章
修复：更新 Travis-CI 版本的脚本
功能：为JavaScript 钩子
文档添加文章：更新贡献指南
```
保持这些短篇幅不超过50个字符。 您总是可以在提交消息的描述中添加额外信息。
这不需要任何额外的时间，只需要一个非常规信息，例如“更新文件”或“添加索引.md”
您可以了解更多关于您为什么要在这里使用常规提交 [](https://www.conventionalcommits.org/en/v1.0.0-beta.2/#why-use-conventional-commits)。
9. 如果您意识到需要编辑文件或在提交后更新提交消息，您可以在编辑文件后这样做：
```console
git 提交 --revision
```
这将打开一个默认文本编辑器，如 `nano` or `vi` ，您可以在那里编辑提交的消息标题并添加/编辑描述。
10. 接下来，你可以将你的更改推到你的叉中：
```console
git 推送来源分支/名称到这里
```
## 提出合并请求(PR)
在您提交了您的更改后，请在这里检查 [如何打开一个合并请求](how-to-open-a-pull-request.md)。
## 快速命令参考
快速引用您在本地工作时需要的命令。
| 命令 | description |
| ---------------------------------------------------------- | ---------------------------------- |
| `npm ci` | 安装/重新安装所有依赖关系和引导不同的服务。 |
| `npm 运行种子` | 解析所有挑战Markdown文件并将其插入MongoDB。 |
| `npm 运行开发` | 启动免费CodeCamp API 服务器和客户端应用程序。 |
| `npm 测试` | 在系统中运行所有 JS 测试，包括客户端、服务器、 直线和挑战测试。 |
| `npm 运行测试：客户端` | 运行客户端测试套件。 |
| `npm 运行测试：课程` | 运行课程测试套件。 |
| `npm 运行测试:course --block='Basic HTML 和 HTML5'` | 测试特定方块。 |
| `npm 运行 test:course --superblock='responsible web-design'` | 测试一个特定的超级块。 |
| `npm 运行测试课程全文输出` | 运行课程测试套件，而不会在第一个错误后进行保养。 |
| `npm 运行测试：服务器` | 运行服务器测试套件。 |
| `npm 运行e2e` | 运行 Cypress 端口来结束测试。 |
| `npm 运行清理` | 卸载所有依赖关系并清理缓存。 |
## 故障排除
### 安装推荐前提条件的问题
我们经常在最新或最受欢迎的操作系统上开发，如macOS 10.15或更高版本，Ubuntu 18.04或更高版本，以及Windows 10(WSL2)。
建议在资源上研究您的具体问题，例如谷歌、堆栈溢出和堆栈交换。 有一个很好的机会让某人面临同样的问题，你的具体查询已经有一个答案。
如果您处于不同的操作系统和/或仍在出现问题，请参阅 [获取帮助](#getting-help)。
> [!警告]
>
> 请避免为前提问题创建 GitHub 问题。 它们超出了该项目的范围。
### UI、字体、构建错误等问题。
如果您面临UI问题，字体或看到构建错误，清理可能有用：
```console
npm 运行清洁
npm ci
npm 运行种子
npm 运行开发
```
或
使用快捷方式
```
npm 运行清理和开发
```
如果你继续面临建筑物问题，清理工作区是推荐的。
在交互模式下使用 `git 净化`
```
git 清理-ifdX
```
<details>
<summary>
如何清理git 解压过的文件(屏幕截图)
</summary>
<br>
<img src="https://user-images.githubusercontent.com/1884376/94270515-ca579400-ff5d-11ea-8ff1-152cade31654.gif" alt="如何清理git 解压过的文件" />
</details>
### API、登录、挑战提交等问题
如果您不能登录，而是看到一个带有错误消息的横幅，它将被报告给FreeCodeCodeCamp， 请再次检查您的本地端口 `3000` 是否没有被另一个程序使用。
**在 Linux / macOS / WSL 窗口上 - 从终端：**
```console
netstat -ab | grep "3000"
tcp4 0 0 0.0.0.0:3000 DESKTOP LISTEN
```
**在 Windows 上 - 从高亮的电源架：**
```powershell
netstat -ab | 选择字符串"3000"
TCP 0.0.0:3000DESKTOP 列表正在注意中
```
### 安装依赖关系的问题
如果您在安装依赖时遇到错误， 请确保您不在受限制的网络中，或您的防火墙设置不会阻止您访问资源。
首次设置可能需要一段时间，取决于您的网络带宽。 耐心等待，如果你仍然被卡住，我们使用GitPod 而不是脱机设置。
## 获取帮助
如果您被卡住并需要帮助。 通过在 [中在我们的论坛](https://forum.freecodecamp.org/c/contributors) 上询问贡献者的类别或在 Gitter 上的 [贡献者聊天室](https://gitter.im/FreeCodeCamp/Contributors) 来让我们知道。
在您的浏览器控制台或Bash / Terminal / Command 行中可能有错误，将有助于识别问题。 在您的问题描述中提供此错误信息，以便其他人能够更容易地识别问题并帮助您找到解决方案。

129
docs/i18n/Chinese/how-to-setup-wsl.md Normal file
View File

@ -0,0 +1,129 @@
# 在 Windows 子系统上为 Linux (WSL) 设置 FreeCodeCamp
> [!注意] 在您遵循这些说明之前，请确保您的系统符合要求
>
> **WSL 2**: Windows 10 64-bit (2004版本，构建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)
本指南涵盖一些通用步骤，并设置了WSL2。 一旦解决了WSL2的一些共同问题。 您应该能够遵循我们的本地设置指南，在运行WSL 磁盘的Windows上使用 FreeCodeCodeCamp，比如Ubuntu。
## 启用 WSL
按照 [官方文档](https://docs.microsoft.com/en-us/windows/wsl/install-win10) 上的说明安装 WSL1，然后升级到 WSL2。
## Install Ubuntu
1. 我们建议使用 Ubuntu-18.04 或更高版本的 WSL2。
> [!注意]
>
> 虽然你可以使用其他非德语的碎片，但他们都有自己的东西，超出了本指南的范围。
2. 更新操作系统的依赖关系
```console
sudo apt update 更新
sudo apt 升级 -y
# 清理
sudo apt autoremove -y
```
## 设置 Git
Git 是通过 Ubuntu 18.04 预先安装的，请确认您的 Git 版本是 `git --version`。
```output
~
变量--version
git 版本 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.
## 安装代码编辑器
我们强烈建议在 Windows 10 上安装 [Visual Studio 代码](https://code.visualstudio.com)。 它非常支持WSL 并自动在您的 WSL 磁盘上安装所有必要的扩展。
基本上，您将编辑和存储在 Ubuntu-18.04 上的 VS 代码安装在 Windows上。
## 安装 Docker 桌面
**Windows停靠桌面** 允许您安装和运行数据库和服务，如MongoDB、NGINX等。 这有助于避免在Windows或WSL2上直接安装MongoDB或其他服务的常见陷阱。
在 [官方文档](https://docs.docker.com/docker-for-windows/install) 上跟随指令并安装 Docker 桌面以进行Windows分发。
最佳经验有一些最起码的硬件要求。
## 配置 WSL 的 Docker 桌面
安装Docker 桌面后， [按照这些说明](https://docs.docker.com/docker-for-windows/wsl) 进行配置以使用 Ubuntu-18.04 安装作为后端。
这样容器就可以在WSL一边运行，而不是在Windows上运行。 您可以在 Windows 和 Ubuntu 上访问 `http://localhost` 服务。
## 从 Docker Hub 安装 MongoDB
一旦您配置Docker 桌面与 WSL 2 合作，按照这些步骤启动 MongoDB 服务：
1. 启动一个新的 Ubuntu-18.04 终端
2. 从Docker枢纽拉取 `MongoDB 3.6`
```console
docker pull mongo:3
```
3. 在端口 `27017`启动MongoDB 服务，并配置它在系统重启时自动运行
```console
docker 运行 -it \
-v mongodata:/data/db \
-p 27017:27017 \
--name mongodb
--rehread unless-standarded \
-d mongo:3
```
4. 您现在可以在 `mongodb://localhost:27017` 访问Windows或Ubuntu 的服务。
## 安装 Node.js 和 npm
我们建议您用节点版本管理器安装 Node.js LTS 版本号 - [nvm](https://github.com/nvm-sh/nvm#installing-and-updating)。
安装后使用这些命令来安装和使用Node.js版本所需的
```console
nvm install --lts
# 或
# nvm install <version>
nvm install 14
# 用法
# nvm 使用 <version>
nvm 使用 12
```
Node.js 与 `npm`捆绑在一起，您可以更新到 `npm` 的最新版本：
```console
npm 安装-g npm@最新版本
```
## 本地设置免费CodeCamp
既然您已经安装了前提条件，按照 [我们的本地设置指南](https://contribute.freecodecamp.org/#/how-to-setup-freecodecamp-locally) 克隆、在您的机器上安装和安装免费CodeCamp。
> [!警告]
>
> 请注意目前为Cypress测试(以及相关的GUI需要)设置的工作正在进行之中。 您仍然应该能够在大部分代码片段上工作。
## 有用的链接
- [一个 WSL2 开发与Ubuntu 20.04, Node.js, MongoDB, VS Code and Docker](https://devlog.sh/wsl2-dev-setup-with-ubuntu-nodejs-mongodb-and-docker) - 一篇由Mrugesh Mohamapatra 编写的文章 (免费CodeCamp.org员工开发者)
- 经常提出的问题有：
- [Linux Windows子系统](https://docs.microsoft.com/en-us/windows/wsl/faq)
- [Windows停靠桌面](https://docs.docker.com/docker-for-windows/faqs)

15
docs/i18n/Chinese/how-to-use-docker-on-windows-home.md Normal file
View File

@ -0,0 +1,15 @@
# 如何在 Windows Home 上使用 Docker
在WindowsHome上设置停靠台时要避免一些陷阱。 首先，您必须使用 [Docker 工具箱](https://docs.docker.com/toolbox/toolbox_install_windows/) 作为管理员。 很抱歉，Windows Home 不支持 Docker for Windows Desktop，所以必须使用工具箱。 它必须作为管理员运行，因为安装使用符号链接，否则无法创建。
安装工具箱后，作为管理员运行Docker Quickstart 终端。 如果它不存在，它将创建 `默认` 虚拟机. 一旦发生这种情况，关闭终端和打开 VirtualBox (再次作为管理员)。 您应该能看到 `默认` 机。 站点资源非常密集，所以停止虚拟机并尽可能提高设置 - 尤其是内存。 它已被证实与4GB ram合作。
一旦你很高兴Docker正在运行，请克隆免费CodeCamp仓库到 `C:\User` 内的目录。 这些目录是共享的 Docker 访问它在安装期间需要的本地目录的权限。
如果您看到的消息就像这样了
```shell
bash: change_volumes_owners.sh: 没有这样的文件或目录
```
当你 `npm 运行docker:init` 这可能是罪魁祸首。

541
docs/i18n/Chinese/how-to-work-on-coding-challenges.md Normal file
View File

@ -0,0 +1,541 @@
# 如何处理编码挑战
我们的目标是发展一个有趣和明确的互动学习体验。
设计互动式编码挑战是困难的。 编写长篇解释或创建视频教程要容易得多， 还有中型和YouTube上的人。 然而，就我们的核心课程而言，我们坚持的是对大多数人来说最有效的东西――一种完全交互式的视频游戏经验。
我们想要骆驼达到流量状态。 我们希望他们尽可能少地利用我们的课程来建立势头和爆炸。 我们希望他们充满信心地参加这些项目，并广泛接触到方案拟订概念。
创造这些挑战需要极大的创造性和对细节的关注。 有大量的帮助。 你将得到整个贡献者团队的支持，你可以反弹和展示你的挑战。 保持在 [贡献者房间](https://gitter.im/freecodecamp/contributors) 中活动并提问大量问题。
在你的帮助下，我们可以设计一个交互式编码课程，帮助数以百万计的人学习如何编程。
每个挑战的内容都存储在自己的Markdown文件中。 这个Markdown 文件后来被转换为 HTML ，使用我们的工具来创建交互式的网页。
您可以在 [`/courum/challenges`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges) 目录中找到所有免费CodeCodeCodeCamp.org的课程内容。
## 设置课程的配刀工具
在您完成课程之前，您需要设置一些工具来帮助您测试您的更改。 您可以使用下面的任何选项：
- 您可以 [在本地建立免费CodeCamp](how-to-setup-freecodecamp-locally.md)。 对于经常/重复捐款来说，这是 **个强烈推荐的** 个。 此设置允许您工作并测试您的更改。
- 使用 Gitpod，免费在线开发环境。 点击下面的按钮将在您的浏览器中为免费CodeCodeCamp启动一个现成的开发环境。 这只需要几分钟。
[![在 Gitpod 中打开](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
- 点击相应文件的铅笔图标编辑GitHub 界面上的文件。 虽然这是最快的方式，但不推荐 ****，因为您无法测试您在 GitHub 上的更改。 如果我们的维护者认为您所做的更改需要在本地测试，您将需要再次遵循以上方法。
## 挑战模板
下面是挑战Markdown 文件当前看起来的模板。 To see the streamlined template we will be adopting see [below](#upcoming-challenge-template).
````md
---
id: 唯一标识符 (字母数字, MongoDB_id
title: Challenge Title
challengeType: 0
videoUrl: 'url of video explanation'
-
#description
<section id='description'>
The description of the challenge and what is required to passe
</section>
## Instructions
<section id='instructions'>
instructions on the corresponding what is needs.
</section>
## 测试
<section id='tests'>
```yml
测试：
- 文本：应该返回 "foo"
测试字符串：'一个严格的函数可能使用Chai断言'
````
</section>
## Challenge Seed
<section id='challengeSeed'>
<div id='{ext}-seed'>
默认情况下在编辑器中显示的 ```{ext}
代码。
这是应对这一挑战的一个必要部分。
```
</div>
### Before Test
<div id='{ext}-setup' mark="crwd-mark">
```{ext}
可选的测试设置代码。
```
</div>
### After Test
<div id='{ext}-teardown'>
```{ext}
可选的测试拆解代码。
```
</div>
</section>
## Solution
<section id='solution'>
```{ext}
// solution 需要
```
</section>
````
> [!注意]
>
> 1。 在以上各节中，{ext}的例子是：
>
> - `html` - HTML/CSS
> - `js` - JavaScript
> - `jsx` - JSX
>
> 2。 对于上面的 `Tests` 部分，`text` 和 `testString` 应该是有效的 YAML 字符串。 `testString`可以是一个严格的函数或表达式，可以使用 Chai断言。
## 挑战数量
每个挑战都需要一个 'id'。 如果您没有指定一个，则MongoDB将创建一个新的随机数据保存过程； 然而，我们不想这样做，因为我们希望挑战的标本在不同的环境中保持连贯一致(阶段性工作)， 生产，许多不同的开发者等。
若要在 shell 中生成一个新的 shell (假设MongoDB 是分开运行)：
1。 运行 `mongo` 命令。
2. 运行 `ObjectId()` 命令。
例如：
```bash
$ mongo
MongoDB shell 版本 v3.6.1
连接到: mongodb:127.0.1:27017
MongoDB server version: 3.4.10
...
$ ObjectId()
ObjectId("5a474d78df58bafeb3535d34")
````
结果是一个新的 id，例如上面 `a474d78df58bafeb3535d34`。
一旦你有您的 id，将它放入Markdown 文件作为顶部的 `id` 字段，例如：
```yml
---
id：5a474d78df58bafeb3535d34
标题：挑战标题
```
## 命名挑战
命名东西是很难的。 我们通过施加一些限制使它变得更加容易。
所有挑战标题都应该是明确的，应该遵循这种模式：
\[verb\]\[对象条款\]
这里有一些示例挑战名称：
- Use Clockwise Notation to Specify the Padding of an Element
- 带.reduce压缩数组
- Use Bracket Notation to Find the First Character in a String
## 挑战描述/说明
刑期应当简明扼要，只要使用最起码的术语。 如果使用这些术语，应立即用英文对术语加以界定。
保持段落简短(约1-4句)。 人们更可能阅读几个简短的段落，而不是一堵墙的文本。
挑战文本应该使用第二个人("你")来帮助给它一个话音。 这样，案文和指示似乎直接与面临挑战的骆驼骑手说话。 尝试避免使用第一个人("I", "we", "let", and "us").
不要使用出站链接。 这些会中断流程。 在这些挑战中，耕种者绝不应需要做任何事情。 如果有资源，你认为收藏家会从中受益，将它们添加到挑战相关的文章中。
如果绝对必要，您可以添加图表。
挑战中不使用表情或表情符号。 免费CodeCamp有一个全球社区，世界各地表情或表情的文化含义可能不同。 另外，Emoji可能会在不同的系统中以不同的方式呈现。
适当的封口在可能时应使用正确的大写。 下面是挑战中应该出现的一系列词语。
- JavaScript (大写字母"J" 和 "S" 且无缩略语)
- Node.js
- 前端开发(带有破折号的形状)是当您在前端工作时(无破折号的窗体)。 “后端”、“完整堆栈”和许多其他复合条款也是如此。
### 2分钟规则
每项挑战都应在120秒内由一位母语英语发言者来解决，他已经完成了迎接挑战的任务。 这包括阅读方向/说明理解种子代码所需的时间。 写他们自己的代码并获得所有测试通过。
如果完成挑战需要超过两分钟，您有两个选项：
- 简化挑战，或
- 将挑战分为两项挑战。
2分钟规则迫使你这个挑战设计师简洁、你的种子代码清晰、你的测试向前进行。
我们跟踪玩家需要多长时间来解决变化，并使用这种信息来确定需要简化或分割的挑战。
### 模块化
每一项挑战都应传授一种概念，这一概念应从挑战的名称中看出。
我们可以通过重复和变异来加强先前涵盖的概念――例如： 在一个挑战中提出h1元素，然后再提出3元素，然后提出几个挑战。
我们的目标是面临数千分钟的挑战。 这些问题可以一起出现，重申先前涵盖的概念。
### 格式化挑战文本
以下是质疑性案文和实例的具体格式准则：
- 语言关键字在 `<code>` 标签中。 例如，HTML 标签名称或 CSS 属性名称
- 定义关键字的第一个实例，或是一般关键词(例如"对象"或 "不可变") 在 `<dfn>` 标签
- 代码部件的引用(例如函数、方法或变量名称)应该用 `<code>` 标签包裹。 见下面的示例：
- 使用 <code>parseint</code> 将变量 <code>实数</code> 转换为整数。
- 多行代码块 **之前必须是空行**。 下一行必须以三个背杆开头，紧接着是 [支持的语言之一](https://prismjs.com/#supported-languages)。 要完成代码块，您必须开始一个仅有三个背面和 **另一个空行** 的换行符。 **注意：** 如果您要在 YAML 中使用示例代码 使用 `yaml` 而不是 `yml` 来查看右侧的语言。
见下面的示例：
````md
以下是代码的示例：
```{language}
[YOUR CODE HERE]
````
````
- 应格式化笔记形式的附加信息<strong>注意：</strong> 笔记文本...
- 如果需要多个笔记 然后使用格式`<strong>注：</strong> 首注文本，单独列出所有注释。 第二个注文。
- 在适用的情况下使用双引文
## 写作测试
挑战应该有最低数量的必要测试来验证骆驼是否理解一个概念。
我们的目标是传达挑战试图传授的唯一观点，并检验他们对这一点的理解。
挑战测试可以使用 Node.js 和 Chai.js 断言库。 此外，如有必要，用户生成的代码可以在 `code` 变量中访问。
## 格式化种子代码
这里是挑战种子代码的特定格式准则：
- 使用两个空格缩进
- JavaScript 语句结尾有分号
- 在适用的地方使用双引号
- 评论字符和评论本身之间应该有空格
`// 修复此行`
## 提示和解决方案
每个挑战都有一个“获取提示” 按钮， 这样用户可以访问为挑战创建的任何提示/解决方案。 课程提示/解决方案主题位于`Guide`类别下[我们的论坛](https://forum.freecodecamp.org/c/guide)。
如果你发现一个现有挑战的提示/解决方案主题有问题，你可以在论坛上[贡献者类别](https://forum.freecodecamp.org/c/contributors) 提出建议。 信任等级3的版主和用户将审查评论意见，并决定是否列入相应的提示/解决办法专题。
### 添加新的挑战提示/解决方案主题
在添加新的挑战提示/解决方案主题时采取以下步骤。
1. 首先按照相同步骤创建一个新主题，但审查下一个步骤以创建标题。
2. 主题的标题应该从`freeCodeCamp挑战指南：`中包含课程挑战的实际标题开始。 例如，如果挑战被命名为“`Chunky Mankey`”，主题标题将是“`freeCodeCamp挑战指南：Chunky Mokey`”。
3. `camperbot`应该是这些主题/帖子的所有者。 所以你需要请求一个管理员来将主帖子的所有权更改为“camperbot”。
4. 一旦创建了新主题，论坛主题ID将被创建。 它位于论坛主题URL末尾。 必须通过通常的拉请求过程将此ID添加到课程挑战文件的前台，让“获取提示”按钮链接到主题中。
### 提示和解决方案主题内容指南
为课程挑战相关指南主题提出解决方案时 必须添加完整的代码。 这包括所有原始种子代码以及通过所有挑战测试所需的任何更改。 创建新的提示/解决方案主题时应使用以下模板：
``md
# 挑战名称进入这里
-
## 问题解释
这概述了需要做些什么，而不只是重置挑战说明和/或说明。 这是一个可选的章节
#### 相关链接
- [Link Text](link_url_goes_here)
- [Link Text](link_url_goes_here)
---
## 提示
### # 提示1
提示在此处
### Hint 2
提示在这里
-
## 解决方案
<details><summary>Svolution 1 (click to Show/Hide)</summary>
```js
function my(
console. og('Hello World!');
}
````
#### 代码解释
- 代码解释在此处
- 代码解释在此处
#### 相关链接
- [链接文本](link_url_goes_here)
- [链接文本](link_url_goes_here)
</details>
````
## 测试挑战
在您之前[创建拉取请求](how-open-a pull-request)。 d) 对于您的更改，您需要确认您所做的更改不会无意中造成挑战问题。
1. 要测试所有挑战，请从根目录运行下面的命令
````
npm 运行测试：课程
```
2. 您也可以通过这些命令测试一个块或一个超级挑战块
```
npm 运行测试:course --block='Basic HTML 和 HTML5'
```
```
npm 运行 test:course --superblock=responsible web-design
```
您也可以通过执行以下步骤来测试一个挑战：
1。 切换到“课程”目录：
```
cd 课程
```
2. 对您更改过的每个挑战文件运行以下：
```
npm 运行测试-- -g '挑战的完整英文标题'
```
一旦您验证了每一个挑战通过测试，[请创建一个拉取请求](https://github.com/freeCodeCamp/freeCodeCamp/blob/master/docs/howto opena-pull-request.md)。
> [!提示]
> 你可以将 `.env` 中的环境变量`LOCALE` 设置为你需要测试的挑战语言。
>
> 当前接受的值是 'english' 和 '中文, 默认设置为 'english' 。
## 即将到来的挑战模板
正在更新到更清洁、更少嵌套结构的挑战模板。 这还没有完全完成，但以下内容应该接近最终结构：
``mdx
---
id：唯一的标识符(字母和数字, MongoDB_id
标题: '挑战标题'
challengeType: Integer, defined in "client/utils/challengeType s`
videoUrl: 'url of video explanation'
forumTopicId: 12345
-
import Script from './script dx';
## --step-description--
文字描述，Markdown
```html
<div>
示例代码
</div>
```
## --step-hints--
![test-id-1]
将会有任意数量的 id、 说明 (Markdown) 和代码块。
```js
测试代码
```
![test-id-2]
Markdown 语法中的更多说明
```js
更多代码
```
## --step-seed--
### --before-user-code--
```lang
在用户之前评价过的代码
```
### --后用户代码--
```lang
在用户完成后和测试前评估的代码
```
### --seed-content--
![index-html]
```html
部分html
```
```css
一些css
```
```js
一些js
```
![index-js]
<Script ></p>
<h1 spaces-before="0">
--solution-marker--
</h1>
<p spaces-before="0">
与种子部分完全相同
</p>
<h2 spaces-before="0">
--next 解决-标记
</h2>
<p spaces-before="0">
再次相同
</p>
<h1 spaces-before="0">
--question-marker--
</h1>
<h2 spaces-before="0">
--text-marker--
</h2>
<p spaces-before="0">
问题在此处(仅用于视频挑战)
</p>
<h2 spaces-before="0">
--ansters-marker--
</h2>
<p spaces-before="0">
答案 1
</p>
<hr />
<p spaces-before="0">
答案 2
</p>
<hr />
<p spaces-before="0">
更多答案
</p>
<h2 spaces-before="0">
--solution-marker--
</h2>
<p spaces-before="0">
\<number of correct answer\>
</p>
<p spaces-before="0">
````
</p>
<h3 spaces-before="0">
有用的链接
</h3>
<p spaces-before="0">
创建和编辑挑战：
</p>
<ol start="1">
<li>
<p spaces-before="0">
<a href="https://github.com/freeCodeCamp/freeCodeCamp/blob/master/client/utils/challengeTypes.js#L1-L13">挑战类型</a> - 数字挑战类型值是什么(枚举)。
</p>
</li>
<li>
<p spaces-before="0">
<a href="https://www.youtube.com/watch?v=iOdD84OSfAE#t=2h49m55s">为FreeCodeCamp - 写入 ES6 挑战测试</a> - 一个视频跟随 <a href="https://twitter.com/ArrowoodTech">Ethan Arrowood</a> ，因为他为旧版课程做出了贡献。
</p>
</li>
</ol>

40
docs/i18n/Chinese/how-to-work-on-the-docs-theme.md Normal file
View File

@ -0,0 +1,40 @@
# 如何在文档主题上工作
> [!注意] 一个快速提醒, 你不需要为文档站点的内容设置任何操作。
>
> 要在贡献指南上工作，您可以在这里编辑或添加 `文档` 目录 [中的文件](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/docs)。 当您的更改被合并时，它将自动在文档网站上提供。
## 文档网站的结构
网站使用 [`docsify`](https://docsify.js.org)生成，并使用GitHub 页面。
通常，您不需要更改任何配置或本地构建站点。 如果你有兴趣，这里是它的工作方式：
- 此站点的主页源在 [`docs/index.html`](index.html) 中可用。
- 我们使用 `将` 和 GitHub 页面作为一个 SPA 服务于这个文件。
- `Docsify` 脚本生成 `markdown` 文件的内容在 `docs` 目录需要时生成.
- 主页来自 [`_coverpage.md`](_coverpage.md)
- 侧边栏导航由 [`_sidebar.md`](_sidebar.md) 生成。
## 在当地服务文件网站
克隆免费CodeCamp：
```sh
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
docsify service docs
```
安装 `对码化`：
```sh
npm install -g docsify
```
并服务 `/docs` 目录
```sh
对服务文档
```
或者，如果您已经在本地安装了免费CodeCamp(见本地安装指南)， 我们将CLI与开发工具捆绑在一起，以便您可以从仓库的根目录运行 `npm 运行文档：服务`。

10
docs/i18n/Chinese/how-to-work-on-the-news-theme.md Normal file
View File

@ -0,0 +1,10 @@
<!--
The source for this document is available at:
https://github.com/freeCodeCamp/news-theme/blob/master/CONTRIBUTING.md
Please edit that file instead.
-->
[remote-markdown-url](https://raw.githubusercontent.com/freeCodeCamp/news-theme/master/CONTRIBUTING.md)

45
docs/i18n/Chinese/index.md Normal file
View File

@ -0,0 +1,45 @@
[FreeCodeCamp.org](https://freecodecamp.org) 社区是可能的，因为像你这样的数以千计的善意志愿者。 我们欢迎对社区作出的任何和所有贡献，并高兴地欢迎你们在一起。
> [!注意] 在您继续之前，请快速2分钟阅读我们的 [行为守则](https://www.freecodecamp.org/code-of-conduct) 我们在整个社会严格执行这项政策。 我们想要为FreeCodeCamp.org做出贡献，这对每个人来说都是一个安全和包容的经历。
贡献愉快。
欢迎：
- 在我们的 [编码挑战中创建、更新和修复错误](#coding-challenges)。
- 帮助我们修复FreeCodeCamp.org的 [学习平台](#learning-platform) 中的 bug 。
- _(即将来临)_ 帮助我们将FreeCodeCamp.org翻译成世界语言。
有问题？ 走到 [这些常见问题](/FAQ.md) ，我们在那里回答一些常见的关于贡献的问题。
## 编码挑战
我们的所有编码挑战都由社区管理，带来像你这样的志愿者的专家知识。
你们可以帮助扩大它们，并使它们的措辞更好。 您也可以更新用户故事来更好地解释概念或删除多余的故事，并改进挑战测试，使其更准确地测试人们的代码。
**如果您有兴趣改进这些编码挑战，这里 [如何处理编码挑战](how-to-work-on-coding-challenges.md)。**
## 学习平台
我们的学习平台运行在一个现代的 JavaScript 堆栈上。 它有各种组件、工具和库，包括但不限于：Node.js、MongoDB、LoopBack、OAuth 2.0、React、Gatsby、Webpack等等。
广义而言，
- 我们有基于 Node.js 的 API 服务器。
- 基于React的客户端应用集。
- 一个我们用来评估我们的前端项目的脚本。
为此做出贡献需要对API、ES6语法和许多好奇心有所了解。
从根本上讲，我们期望基本上熟悉上述一些技术、工具和图书馆。 话虽如此，你们不必是他们的专家。
**如果你想要帮助我们改进我们的代码库，你可以使用 Gitpod，免费的在线开发环境**
[![在 Gitpod 中打开](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
(在您的浏览器中为FreeCodeCodeCamp启动一个现成的开发环境。)
或
**you can [set up freeCodeCamp locally](how-to-setup-freecodecamp-locally.md) on your machine.**

101
docs/i18n/Czech/FAQ.md Normal file
View File

@ -0,0 +1,101 @@
### Jsem nováček na GitHubu a Open Source, kde bych měl začít?
Přečtěte si naše ["Jak přispět k Open Source příručce"](https://github.com/freeCodeCamp/how-to-contribute-to-open-source). Je to kompenzační zdroj projektů a pokynů prvního časovače.
### Dokážu přeložit studijní programy zdarmaCodeCamp?
Na bezplatném CodeCamp začneme nejprve s **čínskou** snahou o lokalizaci.
Plánujeme zpřístupnit učební plány ve více jazycích, ale zatím se nemůžeme zavázat k žádným termínům. Několik provozních limitů, jako jsou zaměstnanci, aktivní přispěvatelé a náklady na servery hrají roli při prosazování internacionalizace (i18n) úsilí.
Máme v úmyslu zahájit i18n úsilí v těchto jazycích: arabštině, portugalštině, Ruština a španělština (bez zvláštního pořádku) poté, co jsme v čínštině uvolnili osnovy.
**Proč se nejprve zaměřujete na čínské učební plány?**
Čína je největšími demografickými regiony, v naší nerodné angličtině mluvící publikum. V současné době máme statisíce uživatelů pomocí staré verze platformy. Zaměření na čínské učební plány nám poskytne odhad logistiky zapojené do i18n.
Zaměříme se na Latinskou Ameriku jako demografický region pro portugalský a španělský.
V dohledné budoucnosti nemáme žádné plány na i18n v jiných jazycích, než jsou výše uvedené.
Nevybízíme vás, abyste pracovali na i18n ve výše uvedených jazycích. Můžeme přijmout požadavky na natažení, aniž bychom očekávali termíny nasazení.
### Jak mohu nahlásit novou chybu?
Pokud si myslíte, že jste našli chybu, přečtěte si nejprve článek ["Pomoz mi najít chybu"](https://forum.freecodecamp.org/t/how-to-report-a-bug/19543) a postupujte podle jeho pokynů.
Pokud si myslíte, že je to nová chyba, pokračujte a vytvořte nový GitHub problém. Nezapomeňte zahrnout co nejvíce informací, abychom mohli reprodukovat chybu. Máme předem definovanou šablonu problému, která vám pomůže s tímto problémem.
Vezměte prosím na vědomí, že všechny problémy, které hledají pomoc s kódováním na challenge keši, budou uzavřeny. Sledování problémů je přísně určeno pro otázky a diskuze související s kódovou databází. Kdykoli máte pochybnosti, měli byste [požádat o pomoc na fóru](https://forum.freecodecamp.org) před vypracováním zprávy.
### Jak mohu nahlásit bezpečnostní problém?
Pro bezpečnostní problémy prosím nevytvářejte GitHub problémy. Namísto toho pošlete e-mail na `security@freecodecamp.org` a my se ho budeme okamžitě zabývat.
### Jsem student, mohu já nebo náš tým pracovat na funkci akademických kreditů?
Ano, jisté.
I když jsme otevřeni všem příspěvkům, Vezměte prosím na vědomí, že nejsme schopni zavázat se k žádným lhůtám, které mohou být vyžadovány na vaší vysoké škole nebo na vysoké školě. Dostáváme mnoho žádostí o natažení a příspěvků na kód od dobrovolníků vývojářů, respektujeme jejich čas a úsilí. Nebudeme schopni věnovat žádnou zvláštní pozornost PR tomu, abychom byli spravedliví vůči všem.
Žádáme vás, abyste plánovali dopředu a pracovali na této funkci.
### Co znamenají tyto různé štítky, které jsou označovány v otázkách?
Správce kódu [zkouší](https://en.wikipedia.org/wiki/Software_bug#Bug_management) problémy a tahá požadavky na základě jejich priority, závažnosti a dalších faktorů. [můžete najít kompletní seznam jejich významů zde](https://github.com/freecodecamp/freecodecamp/labels).
### Kde začnu, když chci pracovat na nějakém problému?
Měl bys projít [**`pomoc si přát`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) nebo [**`první časovače pouze`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22first+timers+only%22) problémy pro rychlý přehled toho, na čem máš možnost pracovat.
> [!TIP] **`Pomoc chtěla, aby`** problémy byly nastaveny a abyste na nich pracovali, nemusíte žádat o povolení. Problémy s **`prvním časovačem jsou však vyhrazeny pouze`** pro lidi, kteří nepřispěli do bezplatné kódovací základny CodeCamp dříve. Pokud tyto otázky nejsou jasné, co je třeba udělat, neváhejte klást v komentářích otázky.
### Našel jsem typo, mám nahlásit problém, než mohu podat žádost o natažení?
Pro překlepy a jiné změny formulací můžete přímo otevřít požadavky na natažení, aniž byste nejprve vytvořili problém. Otázky jsou spíše předmětem diskuse o větších problémech spojených s kódem nebo strukturálními aspekty učebních plánů.
Nicméně, uveďte podrobnosti, kontext atd. v popisné oblasti požadavku na natažení, abyste nám pomohli porozumět a zkontrolovat váš příspěvek i pro drobné změny.
### Jak mi bude přidělen úkol?
Obvykle nepřisuzujeme problémy nikomu jinému, než je dlouholetý přispěvatel, abychom se vyhnuli nejednoznačným ukázkám. Namísto toho sledujeme následující politiku, abychom byli spravedliví vůči každému:
1. První žádost o natažení pro jakýkoli problém je třeba sloučit.
2. V případě vícenásobných žádostí o natažení pro tutéž otázku upřednostňujeme kvalitu kódu v žádostech o natažení.
- Obsahovali jste testy?
- Zachytili jste všechna použití?
- Zajistili jste, aby všechny testy prošly, a potvrdili jste, že vše funguje lokálně?
3. A konečně, upřednostňujeme požadavky na natažení, které se řídí našimi doporučenými pokyny.
- Sledovali jste kontrolní seznam požadavků na natažení?
- Věnovali jste název požadavku na natažení smysluplně?
Nepotřebujete žádné oprávnění pro úkoly, které jsou označeny jako `pomoc a které chtěly` nebo `první časovače` jak bylo vysvětleno dříve.
Postupujte pečlivě podle pokynů a otevřete žádost o natažení.
### Jsem uvězněn na něčem, co není v této dokumentaci obsaženo.
**Neváhejte požádat o pomoc v:**
- The `Contributors` category of [our community forum](https://forum.freecodecamp.org/c/contributors).
- The public `Contributors` [chat room on Gitter](https://gitter.im/FreeCodeCamp/Contributors).
- The `#Contributors` channel on [our Discord community server](https://discord.gg/pFspAhS).
Jsme rádi, že vám pomůžeme přispět k nějakému tématu, na kterém byste rádi pracovali. Nebojte se nám položit otázky ohledně související problematiky a s potěšením to vyjasníme. Před odesláním nového dotazu se ujistěte, že hledáte váš dotaz.
Buďte zdvořilí a trpěliví. Naše komunita dobrovolníků a moderátorů vás vždy vede vašimi dotazy.
**Další pomoc:**
Máte-li dotazy o stohu, architektuře codebase, neváhejte se obrátit na náš personál dev týmu:
| Zaměstnanci | Odeslat zprávu na fóru |
|:--------------------- |:---------------------------------------------------------------------------- |
| Mrugesh Mohapatra | [@raisedadead](https://forum.freecodecamp.org/u/raisedadead) |
| Ahmad Abdolsaheb | [@abdolsa](https://forum.freecodecamp.org/u/abdolsa) |
| Kristofer Koishigawa | [@scissorsneedfoodtoo](https://forum.freecodecamp.org/u/scissorsneedfoodtoo) |
| Tom Mondloc | [@moT01](https://forum.freecodecamp.org/u/moT01) |
| Oliver Eyton-Williams | [@ojeytonwilliams](https://forum.freecodecamp.org/u/ojeytonwilliams) |
| Randell Dawson | [@RandellDawson](https://forum.freecodecamp.org/u/randelldawson) |
**Náš vývojářský personál můžete poslat e-mailem na: `dev[at]freecodecamp.org`**

36
docs/i18n/Czech/_sidebar.md Normal file
View File

@ -0,0 +1,36 @@
- **Začněme**
- [Úvod](/index.md "Přispějte do komunity freeCodeCamp.org")
- [Často kladené otázky](/FAQ.md)
- **Přispění kódu**
- - [Nastavte volný CodeCamp lokálně](/how-to-setup-freecodecamp-locally.md)
- [Otevřít požadavek na natažení](/how-to-open-a-pull-request.md)
- [Práce na výzvách v kódování](/how-to-work-on-coding-challenges.md)
- [Pracovat na výzvách spojených s videem](/how-to-help-with-video-challenges.md)
- [Práce na tématu novinek](/how-to-work-on-the-news-theme.md)
- [Práce na motivu dokumentace](/how-to-work-on-the-docs-theme.md)
- **Volitelné návody**
- [Ukládat odchozí e-maily lokálně](/how-to-catch-outgoing-emails-locally.md)
- [Nastavit freeCodeCamp na WSL](/how-to-setup-wsl.md)
---
- **中文社区贡献指南**
- [成为专栏作者](/i18n/chinese/news-author-application.md)
- [文章翻译计划](/i18n/chinese/news-translations.md)
- [视频翻译计划](/i18n/chinese/video-translations.md)
---
- **Letové příručky** (pro zaměstnance & režimy)
- [Moderátor příručka](/flight-manuals/moderator-handbook.md)
- [Šablony odpovědí](/flight-manuals/using-reply-templates.md)
- [Přehled DevOps](/devops.md)
- [Práce na serverech](/flight-manuals/working-on-virtual-machines.md)
---
- **Naše komunita**
- [**GitHub**](https://github.com/freecodecamp/freecodecamp)
- [**Fórum diskuze**](https://freecodecamp.org/forum/c/contributors)
- [**Chat Gitteru**](https://gitter.im/FreeCodeCamp/Contributors)
- [**Discord Server**](https://discord.gg/pFspAhS)

227
docs/i18n/Czech/devops.md Normal file
View File

@ -0,0 +1,227 @@
# Operace vývojáře na freeCodeCamp.org
Tento průvodce vám pomůže pochopit náš stack infrastruktury a jak udržujeme naše platformy. Ačkoli tato příručka nemá vyčerpávající podrobnosti pro všechny operace, mohla by být použita jako reference pro vaše pochopení systémů.
Dejte nám vědět, pokud máte zpětnou vazbu nebo dotazy a rádi si vyjasníme.
## Jak vytvoříme, otestujeme a nasadíme kódovou základnu?
Tento repozitář je neustále budován, testován a nasazen do **oddělených souborů infrastruktury (Servers, databáze, CDN atd.)**.
To zahrnuje tři kroky, které je třeba dodržovat v posloupnosti:
1. Nové změny (opravy i funkce) jsou sloučeny do naší primární vývojové větve (`master`) prostřednictvím požadavků na natažení.
2. Tyto změny probíhají prostřednictvím řady automatizovaných testů.
3. Jakmile testy projdou, uvolníme změny (nebo je v případě potřeby aktualizujte) na nasazení do naší infrastruktury.
#### Vytváření kódové základny - mapování větví Gitu k zaměstnancům.
Typically, [`master`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master) (the default development branch) is merged into the [`production-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) branch once a day and is released into an isolated infrastructure.
Jedná se o průběžné vydání pro naše vývojáře a dobrovolnické přispěvatele. Je také známá jako naše "staging" nebo "beta".
Je identický s naším živým produkčním prostředím na `freeCodeCamp.org`jiné než pomocí samostatného souboru databází, serverů, web-proxies, atd. Tato izolace nám umožňuje testovat probíhající vývoj a vlastnosti v "výrobě" jako scénář, aniž by ovlivňovala běžné uživatele hlavních platforem FreeCodeCamp.org.
Jakmile je vývojářský tým [`@freeCodeCamp/dev-team`](https://github.com/orgs/freeCodeCamp/teams/dev-team/members) spokojen se změnami na přípravné platformě, tyto změny se přesouvají každých několik dní do větví [`produkčních a aktuálních`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-current).
Toto je finální verze, která přesouvá změny do našich produkčních platforem na freeCodeCamp.org.
#### Testování změn - testování integrace a akceptace uživatelů.
Pro kontrolu kvality kódu používáme různé úrovně integrace a testování. Všechny naše testy jsou prováděny prostřednictvím softwaru jako [Travis CI](https://travis-ci.org/freeCodeCamp/freeCodeCamp) a [Azure Pipelines](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp).
Máme jednotkové testy pro testování našich challenge řešení, API serveru a uživatelských rozhraní klienta. Ty nám pomáhají otestovat integraci mezi různými složkami.
> [!POZNÁMKA] Jsme také v procesu psaní konečných uživatelských testů, které pomohou při kopírování scénářů reálného světa, jako je aktualizace e-mailu nebo volání na API nebo služby třetích stran.
Tyto testy společně pomáhají zabránit opakování problémů a zajistit, že při práci s jinou chybou nebo funkcí nezavádíme chybu.
#### Publikování změn - Odesílání změn na servery.
Nakonfigurovali jsme kontinuální doručovací software, který tlačí změny na naše vývojové a výrobní servery.
Jakmile jsou změny odeslány do chráněných distribučních větví, spustí se pro větvi automaticky spustí stavěný potrubí. Stavební plynovody jsou zodpovědné za výstavbu artefaktů a jejich udržování v chladírenském skladu pro pozdější použití.
Stavební plynovod pokračuje tak, aby spustil odpovídající vypouštěcí plynovod po dokončení úspěšného jízdy. Vypouštěcí potrubí jsou zodpovědná za sběr stavěných artefaktů, jejich přesun na servery a život.
Stav sestavení a vydání je [k dispozici zde](#build-test-and-deployment-status).
## Spuštění sestavení, testování a nasazení.
V současné době mohou do výrobních větví tlačit pouze členové vývojářského týmu. The changes to the `production-*` branches can land only via fast-forward merge to the [`upstream`](https://github.com/freeCodeCamp/freeCodeCamp).
> [!POZNÁMKA] V nadcházejících dnech bychom zlepšili tento tok pomocí požadavků na natažení, pro lepší řízení přístupu a transparentnost.
### Odesílání změn do Přípravných aplikací.
1. Konfigurace dálkových ovladačů správně.
```sh
git remote -v
```
**Výsledky:**
```
původ git@github.com:raisedadead/freeCodeCamp.git (fetch)
origin git@github.com:raisedadead/freeCodeCamp.git (push)
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (fetch)
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (push)
```
2. Ujistěte se, že vaše `master` větev je nepravdivá a synchronizuje s upstreamem.
```sh
git checkout master
git fetch --all --prune
git reset --hard upstream/master
```
3. Zkontrolujte, zda Cesta CI pokračuje na značce `master` pro předcházející proud.
Testy [kontinuální integrace](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) by měly být zelené a PASIVNÍ pro hlavu ``.
<details> <summary> Kontrola stavu Travis CI (screenshot) </summary>
<br>
![Zkontrolovat stav sestavení na Cestě CI](https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/master/docs/images/devops/travis-build.png)
</details>
Pokud to chybí, měli byste se zastavit a vyšetřit chyby.
4. Potvrďte, že jste schopni vytvořit repozitář lokálně.
```
npm běh čištění a vývoj
```
5. Přesunout změny z `master` do `přípravné výroby` rychlým sloučením
```
git Checkout production-staging
sloučení git master
git push upstream
```
> [!POZNÁMKA] Nebudeš moci vynutit tlačení a pokud jsi přepsal historii tak, že tyto příkazy budou chybné.
>
> Pokud ano, možná jste udělali něco nesprávně a měli byste začít znovu.
Výše uvedené kroky automaticky spustí běh na stavěném potrubí pro větev `výroby`. Po dokončení sestavení jsou artefakty uloženy jako `.zip` soubory v chladném úložišti, které mají být načteny a použity později.
Vypouštěcí potrubí se spustí automaticky, pokud je k dispozici čerstvý artefakt z připojeného stavebního potrubí. Pro přípravné platformy tento proces nezahrnuje ruční schválení a artefakty jsou přenášeny na servery CDN a API.
> [!TIP|label:Estimates] Dokončování běhu sestavení trvá obvykle ~20-25 minut a následně běh verze trvá ~15-20 minut pro klienta, a ~5-10 minut pro API je dostupné živé. Od volání kódu k živému na přípravných platformách trvá celý proces **~35-45 minut**.
### Tlačítko změn výrobních aplikací.
Proces je většinou stejný jako přípravné platformy, s několika dalšími kontrolami. To je jen proto, abychom se ujistili, že nerozbijeme nic na freeCodeCamp.org, který může vidět stovky uživatelů, kteří jej používají kdykoliv.
| Neprovádět tyto příkazy, pokud jste neověřili, že vše pracuje na platformě pro přípravu. Neměl bys obcházet ani přeskočit žádné testování přípravy, než budeš pokračovat. |
|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
1. Ujistěte se, že vaše `výrobní příprava` větev je nedokonalá a synchronizovaná s předním proudem.
```sh
git checkout production-staging
git fetch --all --prune
git reset --hard upstream/production-staging
```
2. Přesunout změny z `výroby` do `produkčního proudu` rychlým sloučením
```
git checkout produkci-aktuální
sloučení výroby
git push proti stream
```
> [!POZNÁMKA] Nebudeš moci vynutit tlačení a pokud jsi přepsal historii tak, že tyto příkazy budou chybné.
>
> Pokud ano, možná jste udělali něco nesprávně a měli byste začít znovu.
Výše uvedené kroky automaticky spustí běh na vývojovém potrubí pro větev `produkčně proudu` </code>. Jakmile bude stavební artefakt připraven, spustí běh na vypouštěcí potrubí.
> [!TIP|label:Estimates] Dokončování běhu sestavení trvá obvykle ~20-25 minut.
**Další kroky pro činnost zaměstnanců**
Jeden běh vydání je spuštěn, členové týmu vývojáře obdrží automatický manuální zásahový e-mail. Mohou buď _schválit_ nebo _odmítnout_ spuštění vydání.
Pokud změny fungují pěkně a byly testovány na přípravné plošině, pak mohou být schváleny. Schválení musí být uděleno do čtyř hodin od spuštění uvolnění před automatickým odmítnutím. Personál může pro odmítnuté jízdy znovu spustit spuštění ručně, nebo počkat na další cyklus vydání.
Pro zaměstnance:
| Zkontrolujte svůj e-mail pro přímý odkaz nebo [přejděte na dashboard vydání](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) po dokončení spuštění sestavení. |
|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
Jakmile jeden z zaměstnanců schválí vydání, bude plynovod tlačit změny na produkční CDN a API servery freeCodeCamp.org. Obvykle zabírají ~15-20 minut pro klienta a ~5 minut pro servery API, aby byly k dispozici živé.
> [!TIP|label:Estimates] Běh vydání obvykle trvá ~15-20 minut pro každou instanci klienta a ~5-10 minut pro každou instanci API je k dispozici naživu. Od kódového tlačení k živému na produkčních platformách celý proces trvá **~90-120 minut** celkem (nezapočítává se doba čekání na schválení personálem).
## Postavení, test a stav nasazení
Zde je aktuální test, sestavení a stav nasazení kódové základny.
| Typ | Větev | Stav | Nástěnka |
|:---------------- |:-------------------------------------------------------------------------------------------- |:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |:------------------------------------------------------------------------------------------ |
| Zkoušky CI | [`mistr`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master) | ![Stav sestavení cestování CI](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=master) | [Přejít na stavový panel](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| Zkoušky CI | [`přípravná produkce`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | ![Stav sestavení cestování CI](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=production-staging) | [Přejít na stavový panel](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| Sestavit potrubí | [`přípravná produkce`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | [![Stav sestavení](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_apis/build/status/dot-dev-ci?branchName=production-staging)](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build/latest?definitionId=15&branchName=production-staging) | [Přejít na stavový panel](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build) |
| Uvolnit potrubí | [`přípravná produkce`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | | [Přejít na stavový panel](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) |
| Zkoušky CI | [`výrobní proud`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-current) | ![Stav sestavení cestování CI](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=production-current) | [Přejít na stavový panel](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| Sestavit potrubí | [`výrobní proud`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | [![Stav sestavení](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_apis/build/status/dot-org-ci?branchName=production-current)](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build/latest?definitionId=17&branchName=production-current) | [Přejít na stavový panel](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build) |
| Uvolnit potrubí | [`výrobní proud`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | | [Přejít na stavový panel](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) |
## Předčasný přístup a beta testování
Vítáme Vás otestovat tyto verze v režimu **"Public beta testing"** a získat včasný přístup k nadcházejícím funkcím platform. Někdy jsou tyto funkce/změny označovány jako **další, beta, staging,** atd. zaměnitelné.
Vaše příspěvky prostřednictvím zpětné vazby a hlášení problémů nám pomohou vytvořit produkční platformy na `freeCodeCamp. rg` více **odolné**, **konzistentní** a **stabilní** pro všechny.
Děkujeme vám za hlášení chyb, se kterými jste narazili a pomohli zlepšit freeCodeCamp.org. bubble raider
### Určení nadcházející verze platforem
V současné době je veřejná beta testovací verze k dispozici na:
<h1 align="center"><a href='https://www.freecodecamp.dev' _target='blank'>freecodecamp.dev</a></h1>
> [!POZNÁMKA] Název domény se liší od **`freeCodeCamp.org`**. Toto je záměrem zabránit indexování vyhledávačů a vyhnout se nejasnostem pro běžné uživatele platformy.
### Identifikace aktuální verze platforem
**Aktuální verze platformy je vždy k dispozici na [`freeCodeCamp.org`](https://www.freecodecamp.org).**
dev-team spojuje změny z `výrobní přípravy` větví na `produkčně aktuálně` , když se změní. Nejlepší commit by měl být, co vidíte na webu.
Přesnou verzi zavedenou můžete identifikovat návštěvou protokolů sestavení a nasazení dostupných ve stavové sekci. Případně nás můžete také kontaktovat v [přispěvatelské chatovací místnosti](https://gitter.im/FreeCodeCamp/Contributors) pro potvrzení.
### Známá omezení
Při používání beta verze platformy existují některá známá omezení a kompromisy.
- #### Všechna data / osobní postup na těchto beta platformách `NEBUDE uložena nebo přenesena` do produkce.
**Uživatelé na beta verzi budou mít oddělený účet od produkce.** Beta verze používá fyzicky oddělenou databázi od produkce. To nám dává možnost zabránit náhodným ztrátám údajů nebo úpravám. Dev tým může vymazat databázi v této beta verzi, jak je potřeba.
- #### Na počátku a spolehlivost beta platforem nejsou žádné záruky.
Očekává se, že nasazení bude časté a v rychlých iteracích, někdy několikanásobně denně. Výsledkem bude neočekávaná výpadek v časech nebo porušená funkčnost v beta verzi.
- #### Neposílejte na tento web běžné uživatele jako měřítko potvrzení opravy
Beta stránka je a vždy byla rozšiřovat místní vývoj a testování, nic jiného. Není to příslib toho, co se blíží, ale pouhý pohled na to, na co se pracuje.
- #### Značka může vypadat jinak než v produkci
Používáme testovacího nájemníka pro freecodecamp.dev na Auth0, a proto nemáme možnost nastavit vlastní doménu. Tím se všechny přesměrované volání a přihlašovací stránka zobrazí na výchozí doméně, jako: `https://freecodecamp-dev.auth0.com/`. To nemá vliv na funkčnost co nejblíže k produkci, jak můžeme získat.
## Hlášení problémů a zanechání zpětné vazby
Prosím otevřete nové problémy pro diskuzi a hlášení chyb. Můžete je označit jako **[`vydání: next/beta`](https://github.com/freeCodeCamp/freeCodeCamp/labels/release%3A%20next%2Fbeta)** pro triage.
Pokud máte nějaké dotazy, můžete poslat e-mail na `vývojáře[at]freecodecamp.org`. Jako vždy by všechny bezpečnostní chyby měly být nahlášeny na `bezpečnost[at]freecamp.org` namísto veřejného trackeru a fóra.

326
docs/i18n/Czech/flight-manuals/moderator-handbook.md Normal file
View File

@ -0,0 +1,326 @@
# Oficiální příručka FreeCodeCamp Moderator.
To vám pomůže zvládnout různá místa v naší komunitě, včetně:
- Problémy s GitHub & tahání žádostí
- Fórum, chatovací místnosti, Facebookové skupiny a další online zasedací místa
- Události v osobách, jako jsou studijní skupiny, hackathony a konference
**Všichni moderátoři FreeCodeCamp jsou moderátoři v celé komunitě. To znamená, že věříme, že budete na kterékoliv z těchto míst dohlížet.**
To znamená, že můžete sloužit jako moderátor na všech místech, která vás nejvíce zajímají. Někteří moderátoři jen pomáhají na GitHubu. Jiní jen pomáhají na fóru. Někteří moderátoři jsou aktivní všude.
Rozhodující je, že chceme, abyste byl moderátorem, a investujte svůj vzácný čas do míst, která vás zajímají.
> [!POZNÁMKA] "S velmocí přichází velká odpovědnost." - Strýc Ben
Jako moderátor je temperament důležitější než technické dovednosti.
Poslouchejte. Buďte nápomocní. Nezneužívejte své pravomoci.
freeCodeCamp je inkluzivní komunita a my ji musíme udržet tímto způsobem.
Máme jednotný kodex chování, který řídí celou naši komunitu. Čím méně pravidel, tím snazší budou mít na paměti. Tato pravidla si můžete přečíst a vložit je do paměti [zde](https://code-of-conduct.freecodecamp.org).
# Moderating GitHub
Moderátoři mají možnost zavřít problémy a přijmout nebo zavřít požadavky na natažení.
Moderátoři mají v souvislosti s GitHubem dvě hlavní odpovědnosti:
1. QA'ing a sloučení požadavků na natažení
2. Hodnocení otázek a odpovědi na ně
## Moderování požadavků na natažení
Pull requesty (PR) jsou způsob, jakým přispěvatelé odesílají změny do úložiště freeCodeCamp. Je důležité, abychom na žádost o stažení provedli zabezpečování kvality (QA) dříve, než se rozhodneme, zda je sloučíme, nebo je zavřete.
### Typy požadavků na natažení
1. **Edity instrukcí výzvy** Toto jsou změny textu challenge - popis, instrukce nebo testovací text. Můžete také zkontrolovat toto právo na GitHubu a rozhodnout, zda je sloučit. Musíme být v této věci trochu opatrnější, protože miliony lidí se s tímto textem setkají při práci prostřednictvím osnov FreeCodeCamp . Dává požadavek na natažení text jasněji, aniž by ho dával mnohem déle? Jsou úpravy relevantní a nejsou příliš pedantické? Nezapomeňte, že naším cílem je, aby byly výzvy co nejjasnější a co nejkratší. Nejsou místem pro skryté detaily. Také přispěvatelé se mohou pokusit přidat odkazy na zdroje k výzvám. Tyto požadavky na natažení můžete zavřít a odpovědět na ně takto:
> Děkujeme za váš požadavek na natažení.
>
> Tento požadavek na natažení uzavírám. Přidejte místo toho odkazy a další podrobnosti do odpovídajícího průvodce výzvy.
>
> Pokud si myslíte, že se mýlím při uzavírání tohoto problému, otevřete jej prosím znovu a přidejte další vysvětlení. Děkuji vám a šťastné kódování.
2. **Editace kódu Výzvy** Toto jsou změny kódu v challenge - Zdroj výzvy, řešení výzev a testovací řetězce. Tyto požadavky na natažení musí být staženy z GitHubu a testovány na vašem místním počítači, aby se zajistilo, že testovací testy budou i nadále vyhovovat současnému řešení, a nový kód nezavádí žádné chyby. Někteří přispěvatelé se mohou pokusit přidat další testy k pokrytí rohových případů u pedanů. Musíme být opatrní, abychom tuto výzvu příliš nekomplikovali. Tyto výzvy a jejich testy by měly být co nejjednodušší a intuitivnější. Vedle výzev algoritmu a náhledu by studenti měli být schopni vyřešit každou výzvu asi do 2 minut.
3. **Codebase mění** Tento kód mění funkčnost platformy freeCodeCamp samotné. Někdy se přispěvatelé snaží provádět změny bez velkého vysvětlení, ale pro změny kódu musíme zajistit, aby byla změna skutečně potřebná. Takže tyto žádosti o stažení by měly odkazovat na existující GitHub, kde se diskutuje o důvodech změny. Pak můžete otevřít požadavek na natažení na vašem počítači a vyzkoušet jej lokálně. Poté co to uděláte, pokud změny vypadají dobře, nesloučte je docela docela docela docela docela dohromady. Můžete komentovat požadavek na natažení a označit @raisedadead, aby se mohl konečně podívat.
### Jak sloučit nebo zavřít požadavky na natažení
Za prvé, když zvolíte požadavek na natažení pro QA, měli byste se k němu přiřadit. Můžete to udělat kliknutím na odkaz "přiřadit sebe" pod částí "pověřenci" v pravém sloupci rozhraní GitHubu.
V závislosti na typu žádosti o natažení se řídí příslušnými výše uvedenými pravidly.
Před sloučením požadavku na natažení se ujistěte, že GitHub má zelené zaškrtávací značky pro všechno. Pokud existuje nějaký X, nejprve je prozkoumejte a zjistěte, jak je nejdříve změnit na zelené zaškrtávací značky.
Někdy dojde ke konfliktu o sloučení. To znamená, že jiná žádost o natažení provedla změnu přesně stejné části stejného souboru. GitHub má nástroj pro řešení těchto fúzních konfliktů přímo na GitHubu. Můžete se pokusit tyto konflikty řešit. Použijte pouze svůj nejlepší úsudek. Změny požadavku na natažení budou nahoře a změny v hlavní větvi budou dole nastaveny. Někdy budou k dispozici nadbytečné informace, které lze odstranit. Než skončíte, nezapomeňte odstranit `<<<<<<` `======`a `>>>>>>` , které Git přidává k označení oblastí konfliktu.
Vypadá to, že požadavek na natažení je připraven ke sloučení (a nevyžaduje schválení od @raisedadead), můžete ho dále sloučit a sloučit. Ujistěte se, že používáte výchozí funkci "Squash and Merge" na GitHubu. Tím se všechny požadavky na natažení převedou do jediného úkolu, díky čemuž je Git historie mnohem snazší přečíst.
Poté byste se měli vyjádřit k žádosti o natažení, poděkování přispěvateli vlastním osobním způsobem.
Pokud autor žádosti o natažení je "poprvé přispěvatel", měli byste jim také poblahopřát k jejich prvnímu sloučenému požadavku na natažení do úložiště. Můžete se podívat na horní pravý roh těla PR, abyste určili prvního přispěvatele. Zobrazí `přispěvatele na první úvazek` , jak je uvedeno níže:
![Copy_edits_for_<unk> _arrays_article_by_karentobo_%C2%B7_Pull_Request__20615_%C2%B7_freeCodeCamp_freeCodeCamp|690x281](https://i.imgur.com/dTQMjGM.png)
Pokud požadavek na natažení nevypadá jako připravený ke sloučení, můžete zdvořile odpovědět autorovi, co by měli udělat, aby byl připraven. Doufejme, že na svůj požadavek na natažení odpoví a připraví jej.
Často bude požadavek na natažení očividně malé úsilí. Často to můžete okamžitě sdělit, když přispěvatel neobtěžoval zaškrtávací políčka v šabloně Pull Request Template, nebo použil obecný název požadavku na natažení jako "made changes" nebo "Update index. d“.
Existují také situace, kdy se přispěvatel snaží přidat odkaz na své vlastní webové stránky, nebo zahrnout knihovnu, kterou sami vytvořili, nebo má lehkovážnou úpravu, která neslouží nikomu jinému, ale samému.
V obou těchto situacích byste měli pokračovat a uzavřít jejich žádost o natažení a odpovědět na tuto standardní zprávu:
> Děkujeme vám za otevření tohoto požadavku na natažení.
>
> Toto je standardní zpráva upozorňující vás, že jsme zkontrolovali váš požadavek na natažení a rozhodli jsme se jej nesloučit. Uvítali bychom, že vás budou stahovat budoucí požadavky.
>
> Děkujeme vám a šťastné kódování.
Pokud potřebujete druhé stanovisko k žádosti o natažení, pokračujte a nechte své připomínky k žádosti o natažení, poté přidejte štítek "diskuze" k požadavku na natažení.
## Moderování GitHub problémů
freeCodeCamp je aktivní open source projekt. Každý den se dostáváme k novým otázkám, které je třeba vyzkoušet a oklamat.
### Typy GitHub problémů
1. **Požadavky na pomoc s kódem**, pro které lidé chybně vytvořili GitHub problémy. Pokud někdo žádá o pomoc, vložte následující zprávu, zavřete problém.
> Děkuji vám za nahlášení tohoto problému.
>
> Toto je standardní zpráva, která vás upozorňuje, že tento problém se zdá být požadavkem na pomoc. Namísto žádání o pomoc zde prosím klikněte na tlačítko \*\*"Nápověda"\*\* na tlačítko výzvy na bezplatném CodeCamp, která vám pomůže vytvořit otázku v správné části fóra. Dobrovolníci na fóru obvykle reagují na otázky během několika hodin a mohou pomoci zjistit, zda je problém s vaším kódem nebo testem výzvy.
>
> Pokud členové fóra zjistí, že není nic špatného s vaším kódem, můžete požádat o znovuotevření tohoto problému.
>
> Děkujeme vám a šťastné kódování.
2. **Problémy s chybou nebo vyjasněním** Pokuste se reprodukovat chybu sami, pokud můžete. Pokud ne, požádejte je o kroky k reprodukci chyby a zda mají nějaké snímky obrazovky, videa, nebo další podrobnosti, které vám mohou pomoci s reprodukcí problému. Jakmile můžete problém reprodukovat - nebo alespoň potvrdit, že se jedná o problém legit - označte ho `potvrzený`. Poté
- Pokud je to jednoduchá změna na existující výzvu, označte ji jako `první časovače pouze`, jinak označte jako `pomoc s přáním`. V případě potřeby použijte jiné štítky.
- Pokud je problém významnější, označte jako `chybu`. &nbsp; Pokud existuje nějaká nejasnost, pokud jde o správný průběh jednání v otázce, neváhejte označit @raisedadead na tuto problematiku a pak přidejte značku `s diskuzí`.
3. **Duplicitní problémy** Pokud je úkol stejný jako jiný hlášený úkol, měl by mít přednost předchozí hlášené úkoly. Označit jako `Duplikát`, vložte následující zprávu nahrazující `#XXXXX` číslem problému a pak problém uzavřete.
> Děkuji vám za nahlášení tohoto problému.
>
> Toto je standardní zpráva, která vás oznamuje, že tento problém se zdá být velmi podobný problému #XXXXX, uzavírám ji jako duplikát.
>
> Pokud si myslíte, že se mýlím při uzavírání tohoto problému, otevřete jej prosím znovu a přidejte další vysvětlení. Děkujeme vám a šťastné kódování.
4. **Opraveno ve stadiu** Některé problémy již byly opraveny ve stadiu, ale nemáte přiřazený problém na GitHubu. Pokud tomu tak je, můžete vložit následující zprávu, zavřít problém a přidat stav `: vyřešený/dodací štítek`:
> Děkuji vám za nahlášení tohoto problému.
>
> Toto je standardní zpráva, která vás oznamuje, že problém, který jste zde zmínili, se vyskytuje ve výrobě, ale že již byla opravena ve stagnaci. To znamená, že až příště nasměrujeme svou přípravnou větvi na výrobu, měl by být tento problém napraven. Z toho důvodu tento problém uzavírám.
>
> Pokud si myslíte, že se mýlím při uzavírání tohoto problému, otevřete jej prosím znovu a přidejte další vysvětlení. Děkujeme vám a šťastné kódování.
### Uzavírací schel, zastaralé, neaktivní problémy a požadavky na natažení
- Stale Issues or PRS jsou ty, které nevidí žádnou činnost z OP po dobu 21 dnů (3 týdny od poslední činnosti), ale až poté, co moderátor požaduje více informací/změn. Ty mohou být uzavřeny ve skriptu automatického bota nebo samotnými moderátory.
- Aktivita je definována jako: Komentáře vyžadující aktualizaci PR a triages jako `stav: potřebná aktualizace` popisek atd.
- Pokud OPP požádá o další pomoc, nebo dokonce o dobu, lze výše uvedené uvolnit a revidovat po obdržení odpovědi. V každém případě by měly modifikace využít svého nejlepšího úsudku k vyřešení stavu zbývajících PR.
### Další pokyny pro moderátory na GitHub
Přestože budete mít přístup k úložišti freeCodeCamp, **nikdy byste neměli odesílat kód přímo do repozitářů zdarma CodeCamp**. Veškerý kód by měl vložit kódovací základnu bezplatného CodeCampu ve formě žádosti o natažení z vidlice úložiště.
Také byste nikdy neměli přijímat vlastní PR. Musí být QA jiným moderátorem, stejně jako u jiných PR.
Pokud si všimnete někoho, kdo porušuje [kodex chování](https://code-of-conduct.freecodecamp.org) na GitHub problémy, nebo otevírání požadavků na stažení se škodlivým obsahem nebo kódem, napište na e-mail dev@freecodecamp. rg s odkazem na urážející požadavek na natažení a můžeme zvážit jejich zákaz v GitHubu organizaci freeCodeCamp.
# Moderování fóra
Jako moderátor pomáháte udržet naši komunitu v příjemném místě pro každého, kdo se může naučit a získat pomoc. Budete se zabývat označenými příspěvky a zpracovat spam, offtopy a další nevhodné konverzace.
Všimněte si, že jakmile budete moderátorem na fóru, začnete vidět modré moderátorské nápovědy o členech fóra, jako "toto je poprvé, co [person] zveřejnil - pojďme je přivítat v komunitě! nebo "[person] neodeslal za dlouhou dobu - pojďme je přivítat zpět."
![Modrá textová zpráva, která říká "toto je poprvé, [person] zveřejnila - pojďme je přivítat v komunitě!](https://i.imgur.com/mPmVgzK.png)
Toto jsou příležitosti, jak je přivítat a donutit je k tomu, aby se cítili zvláštní. Nikdy nevíte, který člověk, který je okrajově zapojen, se může stát naším dalším superpomocníkem, který pomůže mnoha dalším lidem v jejich cestě. I nejmenší laskavost může vyvolat kaskádu dobrých činů.
### Mazání příspěvků na fóru
Moderátoři fóra mají možnost odstranit příspěvky uživatele. Měli byste to udělat pouze pro následující instance:
1. Někdo zveřejnil pornografický nebo graficky násilný obraz.
2. Někdo zveřejnil odkaz nebo kód, který je svou povahou škodlivý a mohl by poškodit jiné kamery, kteří na něj kliknou.
3. Někdo zaplavil vlákno se spoustou nevyžádaných zpráv.
### Řešení se spamem
Pro první spam post uživatele jim pošlete zprávu vysvětlující problém a podle potřeby odstraňte odkaz nebo příspěvek. Ponechte na profilu uživatele poznámku vysvětlující opatření, která jste provedli. Pokud problém přetrvává, pak postupujte podle výše uvedeného procesu. V tichosti zablokovat uživateli publikování (pomocí možnosti ticha na panelu Správce uživatelů), poté poslat varování s kodexem chování. Zaškrtněte políčko v soukromé zprávě označující, že vaše zpráva je "formální varování".
Můžete klást otázky a nahlásit incidenty v [fóru](https://forum.freecodecamp.com/c/staff).
### Řešení konverzací mimo téma
Příspěvky nebo témata, která se zdají být na nesprávném místě, mohou být přeřazeny do nové kategorie nebo přejmenovány na cokoli, co by bylo vhodné.
Ve výjimečných případech může být vhodné, aby moderátor rozeslal diskusi o více vláknech.
Pokud máte nějaké problémy nebo otázky, proveďte příspěvek se svými akcemi v kategorii zaměstnanců, a označte jiného moderátora, pokud chcete, aby přezkoumali své moderátorské akce.
### Uživatelé nezletilých
Naše smluvní podmínky vyžadují, aby uživatelé bezplatného CodeCamp měli alespoň 13 let. V případě, že uživatel zjistí, že je mladší 13 let, pošlete jim níže uvedenou zprávu a smažte jejich účet na fóru (pokud není smazání dostupné, pozastavení účtu je dostatečné). Potom napište e-mail [Quincy](https://forum.freecodecamp.org/u/QuincyLarson) (quincy@freecodecamp.org) nebo [Mrugesh](https://forum.freecodecamp.org/u/raisedadead) (mrugesh@freecodecamp.org) pro odstranění uživatelova účtu zdarmaCodeCamp
```markdown
PŘEDMĚT: Uživatelé mladší 13 let nesmějí používat fórum pro smluvní podmínky
Upozornili na to, že jste mladší 13 let. Za [freeCodeCamp podmínky služby](https://www.freecodecamp.org/news/terms-of-service), musíte být alespoň 13 let, abyste mohli používat tuto stránku nebo fórum. Budeme odstraňovat jak váš účet zdarmaCodeCamp tak váš účet na fóru. Toto omezení nás drží v souladu s právními předpisy Spojených států.
Připojte se prosím znovu, jakmile dosáhnete alespoň 13 let věku.
Děkuji vám za pochopení.
```
# Moderování Facebooku
Pokud uvidíte cokoliv, co se zdá být porušením našeho [Kodexu chování](https://code-of-conduct.freecodecamp.org/), měli byste jej okamžitě odstranit.
Někdy lidé publikují věci, o nichž si myslí, že jsou zábavné. Neuvědomují si, že to, co řekli nebo co sdíleli, by bylo možné interpretovat jako urážlivé. V těchto případech by jejich funkce měla být odstraněna, ale osoba, která ji vyslala, nemusí být nutně zakázána. Doufejme, že tím, že své místo vymažou, pochopí, že to, co vyslali, je nevhodné.
Jenže je-li to nehorázný přestupek, který nelze přiměřeně přičítat kulturním rozdílům nebo nedorozumění angličtině, pak byste měli důkladně zvážit blokování člena z Facebookové skupiny.
# Moderování Discordu
Zde je, jak moderátoři řeší porušování našeho [kodexu chování](https://code-of-conduct.freecodecamp.org/) na Discordu:
1. **Ujistěte se, že mělo být porušeno kodex chování.** Ne všechna porušení kodexu chování byla jako taková zamýšlena. Nový kamerátor by mohl odeslat velké množství kódu pro pomoc, nevědí, že to může být považováno za spamming. V těchto případech je můžete požádat o vložení jejich kódu se službami, jako jsou Codepen nebo Pastebin.
2. **Pokud kamper jasně porušuje kodex chování, moderátor postupuje takto:**
- Pozastavit útočného kamaráda, ale nevarovat ani hrozit. Namísto toho jim v tichosti dáte pozastavenou roli na Discordu, pak jim pošlete následující zprávu:
```
Toto je standardní zpráva oznamující, že jsem tě musel dočasně pozastavit od rozhovorů na serveru Discord freeCodeCamp.
Jsem moderátor jednající jménem naší komunity s otevřeným zdrojovým kódem. Mohu zvážit odstranění vašeho pozastavení, ale nejdříve musíte udělat tři následující kroky:
1. Přečtěte si náš kodex chování: https://code-of-conduct.freecodecamp.org/
2. Napište mi zpět potvrzení, že jste ji dokončili.
3. Vysvětlete mi, proč si myslíte, že vás pozastavil a proč bych měl vaše pozastavení zrušit.
```
- Nahlaste krátké shrnutí události a jak na ni reagovali v #admin kanálu. Zde je příklad toho, jak by takové shrnutí mohlo vypadat:
```
Pozastaveno: _@username_
Důvod(y): _Spamming, trolling_
Událost: _Jedno nebo více odkazů na urážející zprávu(y)_
CoC: _Sent_
```
- Zpráva o odstranění pozastavení by měla vypadat takto:
```
Odebral jsem pozastavení z ` @username `. Poslal jsem jim kodex chování. Právě dnes si uvědomili, že byli pozastaveni a omluveni za to, co udělali.
```
- Na základě odpovědi pachatelů se moderátor rozhodne, zda odebere pozastavení z útočného kamera. Pokud se zdají být uctivé a omluvitelné, moderátor může pozastavení odstranit. Moderátoři budou v rámci politiky během tohoto procesu zdvořilí, ať už se urážející kamera chová jakkoliv. Pokud nejsou respektováni nebo ochotni CoC přijmout, mělo by po pozastavení následovat zákaz na serveru Discord. Použijte stejný souhrn jako výše, ale nahraďte "Pozastaveno:" "Zablokováno:".
3. **Jak zakázat a/nebo odbanovat**
- Chcete-li někomu zakázat, klikněte pravým tlačítkem myši na jeho uživatelské jméno/profilový obrázek a vyberte "Zabanovat" <username>". Budete mít možnost odstranit jejich předchozí zprávy - vyberte "Neodstraňovat niko", zprávy by měly zůstat zachovány jako historický záznam.
- Pokud se rozhodnete někoho zakázat, znamená to, že nejsou ochotni dodržovat náš kodex chování. Proto by k odblokování kamery mělo dojít jen zřídka. Pokud je to potřeba, můžete tak učinit kliknutím na název serveru, zvolením "Nastavení serveru", výběrem "Bans", výběrem uživatele, kterého chcete odbanovat, a kliknutím na tlačítko "Zrušit ban".
Discord Bany jsou globální - nelze zablokovat uživatele z konkrétního kanálu, pouze z celého serveru.
4. **Odstranění zpráv** moderátoři mají možnost odstranit zprávy na Discordu. Tuto schopnost by měli vykonávat pouze ve čtyřech velmi specifických situacích:
- Někdo zveřejnil pornografický nebo graficky násilný obraz.
- Někdo zveřejnil odkaz nebo kód, který je svou povahou škodlivý a mohl by poškodit jiné kamery, kteří na něj kliknou.
- Někdo zaplavil chat tak extrémním způsobem (obvykle s pomocí robotů), že je chatování zcela nepoužitelné.
- Někdo zveřejnil reklamu a / nebo samopropagující zprávu / obrázek (sociální média).
Ve všech ostatních situacích - a to i v situacích, kdy je kodex chování porušován - by moderátoři neměli tuto zprávu smazat, protože se jedná o významný historický záznam. Když odstraníte zprávu, ujistěte se, že jste si ji nejdříve pořídili! Snímek obrazovky lze přihlásit do kanálu #mod-log, ale pokud jde o #activity-log, stačí říci, že důkazy byly "odstraněny z důvodu citlivého obsahu". Poznámka: Pokud zpráva obsahuje materiál, který by byl nezákonný pro pořízení snímku obrazovky, místo toho zkopírujte odkaz na zprávu - poskytněte odkaz na zprávu @raisedadead pro přeposlání do týmu důvěry a bezpečnosti Discordu.
5. **Nepoužívejte @everyone nebo @here** Nepoužívejte @everyone nebo @here za žádných okolností! Každá osoba v této chatovací místnosti obdrží oznámení. V některých případech desetitisíce lidí. Místo toho chcete-li, aby lidé viděli oznámení, můžete ho připnout k kanálu, aby ho všichni mohli přečíst.
6. **Nevyhrožujte zákazem nebo pozastavením** Pokud kamera porušuje kodex chování, nehrozit jejich zákazem nebo pozastavením a nikdy je na veřejnosti nevarovat. Namísto toho s nimi soukromě, nebo jim pošlete DM a vystavte pozastavení (podle výše uvedeného protokolu). Nikdo jiný v tomto kanálu nepotřebuje vědět, že jste zakázán/pozastavil osobu - kamery mohou zobrazit shrnutí v #aktivita-log kanálu, pokud chtějí držet krok s těmito informacemi. Pokud bylo porušení zjevně nezamýšleno a neopravňuje k pozastavení nebo soukromé konverzaci, aby urážlivý kamera věděl o svých / svých akcích, aniž by přišel jako varování. Například:
- Kampaň publikuje zeď kódu pro žádost o pomoc
Moderátor: @username použijte prosím Codepen nebo Pastebin při vkládání velkých množství kódu.
- Nebo pokud opravdu musíte vysvětlit, proč:
Moderátor: @username použijte prosím Codepen nebo Pastebin při vkládání velkého množství kódu, protože narušuje chat pro každého a mohl by být považován za spamování podle našeho kodexu chování.
- V případě mírného a neúmyslného porušení kodexu chování
Moderátor: Toto je přátelská připomínka pro každého, aby dodržoval kodex chování: https://code-of-conduct.freecodecamp.org/
7. **Nedělejte se stát moderátorem** Nevidějte se jako nad komunitou. Jste komunita. Komunita vám věřila, že vám pomůže chránit něco vzácného, co všichni sdílíme - _vítající_ místo pro nové vývojáře. Pokud se budete chtít stát moderátorem, lidé se mohou cítit znepokojeni kolem vás, stejným způsobem, jakým se lidé mohou cítit znepokojeni kolem policisty, i když nedělají nic špatného. To je jen lidská povaha.
8. **Neodporujte ostatním moderátorům** Pokud nesouhlasíte s akcí moderátora, mluví s nimi v soukromém nebo ho vychatu na #mod-chatu. Nikdy zákaz nenahrazovat a nikdy neodporovat ostatním moderátorům/moderátorům veřejnosti. Místo toho se v mod-chatu diskutuje s chladnou hlavou a umírněnce přesvědčuje, že by sami měli zrušit zákaz nebo změnit svůj názor. Nezapomeňte: jsme všichni ve stejném týmu. Chceme důstojně plnit úlohu moderátorů a vystupovat jednotně.
9. **Mluvte s ostatními moderátory** Máme místo pouze pro moderátory. Použij ho! Pokud se vám nelíbí, jak zvládnout určitou situaci, požádejte ostatní moderátory o pomoc. Pokud si myslíte, že by se o něčem mělo diskutovat, udělejte to. Jste součástí týmu a my si ceníme vstupu každého člena týmu! I když naprosto nesouhlasíte s něčím v těchto pokynech nebo s kodexem chování!
10. **Dočasně neaktivní** Pokud nebudete kvůli dovolené aktivní jako moderátor, nemoc nebo jiný důvod se ujistěte, že ostatní vědí v kanálu #mod-chatu. To je tak, že víme, zda se můžeme spolehnout na tebe pravidelně na serveru, nebo ne.
# Jak se stát moderátorem
Pokud pomáháte lidem v komunitě důsledně v průběhu času, náš moderátorský tým si nakonec všimne, a jeden z nich vás zmíní jako možného moderátora [našeho personálu](https://forum.freecodecamp.org/g/Team). Neexistují žádné zkratky, které by se mohly stát moderátorem.
Pokud jste schváleni, přidáme vás do našich moderátorových týmů na [GitHub](https://github.com/orgs/freeCodeCamp/teams/moderators), [fóru](https://forum.freecodecamp.org/g/moderators)atd.
> [!POZNÁMKA] > **Pro GitHub:** Po přijetí jako moderátor obdržíte pozvánku na repozitář Github. Abyste mohli přijmout pozvánku, musíte přejít na [bezplatného CodeCamp GitHub organizace](https://github.com/orgs/freeCodeCamp/invitation). Toto je vyžadováno, abychom vám mohli dát přístup k zápisu do některých našich repozitářů.
# Jak odcházíme do důchodu neaktivní moderátoři
Vezměte prosím na vědomí, že budeme často odstraňovat mody, které považujeme za neaktivní. Až tak učiníme, pošleme následující zprávu:
> Toto je standardní zpráva, která vás o tom informuje: protože se zdá, že jste v poslední době nebyl aktivním moderátorem, odstraňujeme vás z našeho moderátorského týmu. Velice si vážíme vaší pomoci v minulosti.
> Pokud si myslíte, že jsme to udělali omylem, nebo jakmile jste připraveni se vrátit a přispět více, stačí odpovědět na tuto zprávu, která mi dá vědět.
# Jak funguje naše přispěvatelská místnost
Kdokoli je vítán v [přispěvatelské místnosti na našem Discordu](https://discord.gg/KVUmVXA). Je to určená chatovací místnost pro moderátory a další kamery, kteří přispívají do naší komunity všemi způsoby, včetně prostřednictvím skupin studií.
Předpokládáme, že přispěvatelé si v této místnosti přečtou cokoli, co je přímo zmiňuje s `@username`. Všechno ostatní je nepovinné. Ale neváhejte si přečíst cokoliv, co tam někdo příspěvky a komunikovat.
# Zacházení s advokáty
K vám mohou přistupovat organizace, které chtějí nějakým způsobem partnera nebo spoluznačky s freeCodeCamp. Jakmile si uvědomíte, že to je to, co jsou, přestaňte s nimi mluvit a řekněte jim, aby zaslali e-mail quincy@freecodecamp.org. Takovýto návrh dostává vždy a je v nejlepším postavení, aby mohl posoudit, zda takový vztah bude pro naši komunitu cenný (a jen zřídka).
# Řešení (duševních) zdravotních šetření
Můžete se setkat se situacemi, kdy uživatelé hledají lékařskou radu nebo se zabývají otázkami duševního zdraví a hledají podporu. Pokud jde o politiku, neměli byste o těchto záležitostech hovořit soukromě. Pokud by se situace v určitém okamžiku odrazila zpět na fCC, chceme, aby byla konverzace zaznamenána. Dejte jasně najevo, že nejsme lékaři a že doporučujete uživateli, aby našel profesionální pomoc. Jak obtížné, jak to může někdy být, vyhněte se poskytovat tipy nebo rady jiné než ukazovat uživatele ve směru profesionální pomoci!
Pokud se tak stane na Discordu: Pozastavte uživatele. Tím nechci je trestat! Pozastavení uživatele vytvoří soukromý kanál, který je přístupný pouze uživateli a týmu. Z toho bude mít prospěch jak uživatel, tak i fCC několika způsoby:
- Uživatel má zaručeno nějaké soukromí
- Veřejný chat již není přerušen
- Další členové týmu se mohou stavět, pokud byste nebyli spokojeni se situací sami
> [!POZNÁMKA] Pozastavení uživatele automaticky dává zprávu o čtení našeho kodexu chování. Ujistěte se, že jste uživatele pozastavili, abyste jim poskytli nějaké soukromí a že nejsou potrestáni. To je velmi důležité! Naprosto se chceme vyhnout tomu, abychom uživatelům dali představu, že jsou trestáni za oslovení a získání pomoci!
Pokud se domníváte, že se uživatel může připojit k komunitě, klikněte pravým tlačítkem myši na soukromý kanál a zkopírujte ID. Vložte následující zprávu do #mod-log:
> Referenční lékařská poradenství: <channel ID> <username>
Poté můžete odebrat pozastavení uživatele jako obvykle.
Pomocné URL:
http://www.suicide.org/international-suicide-hotlines.html
# Poznámka ke svobodnému projevu
Někdy budou lidé hájit něco urážlivého či zápalného, co řekli jako ,,svobodný projev".
Tento XKCD komic dokonale shrnuje myšlenky většiny komunit na svobodu projevu. Pokud tedy někdo obhajuje něco, co říká jako ,,svobodný projev", má se k tomu svobodný pocit, že jim to posílá.
<div align="center"><img src='https://aws1.discourse-cdn.com/freecodecamp/original/3X/4/3/43a8b2eafe4c8622e02838f66f1dc6227de32c70.png' width="400" height="400" /></div>
Děkujeme, že jste si to přečetli, a děkuji za pomoc vývojářské komunitě!

126
docs/i18n/Czech/flight-manuals/using-reply-templates.md Normal file
View File

@ -0,0 +1,126 @@
# Použití šablon odpovědí
Toto jsou některé standardní šablony odpovědí, které můžete použít při přezkoumávání požadavků na natažení a pokusů.
> Můžete si vytvořit vlastní s vestavěnou funkcí [**Uložené odpovědi**](https://github.com/settings/replies/) nebo použít níže uvedené funkce.
### Děkujeme
```markdown
Děkujeme za váš příspěvek na stránku! 👍
Jsme rádi, že přijmeme tyto změny a těšíme se na budoucí příspěvky. 🎉
```
### Děkuji vám a Gratulacím
> Za poděkování a povzbuzení přispěvatelů na první místo.
```markdown
Ahoj @username. Gratulujeme k prvnímu požadavku na natažení (PR)! 🎉
Děkujeme vám za váš příspěvek na stránku! 👍
Jsme rádi, že přijmeme tyto změny a těšíme se na budoucí příspěvky. 📝
```
### Chyba sestavení
```markdown
Ahoj @username
Rádi bychom byli schopni vaše změny sloučit, ale zdá se, že došlo k chybě při vytváření Travis CI build. ⚠️
Jakmile tyto problémy vyřešíte, budeme moci zkontrolovat váš PR a sloučit. 😊
---
> Neváhejte odkazovat na [Style Průvodce psaním článků](https://github. om/freeCodeCamp/freeCodeCamp#article-title) pro tento repo při správném formátování článku, takže vaše Travis CI build passes. ✅
>
> Také je to dobrý postup na GitHub psát stručný popis vašich změn při vytváření PR. 📝
```
### Synchronizace fork
> Když PR není aktualizován na `master` větvi.
``````markdown
Ahoj @username
Rádi bychom byli schopni vaše změny sloučit, ale zdá se, že došlo k chybě při vytváření Travis CI build. ⚠️
```bash
Chyba: ENOTDIR: není adresář, otevřít 'src/pages/java/data-abstraction/index.md'
``````
Tato konkrétní chyba nebyla způsobena vaším souborem, ale byla starou chybou způsobenou sloučením chybného kódu s větví `master` Od té doby byla vyřešena.
Chcete-li předat sestavení, budete muset synchronizovat nejnovější změny z repou `master` větve `freeCodeCamp/freeCodeCamp`.
Pomocí příkazové řádky to můžeš udělat ve třech jednoduchých krocích:
```bash
git remote add upstream git://github.com/freeCodeCamp/freeCodeCamp.git
git fetch upstream
git pull upstream
```
Pokud používáte GUI, můžete jednoduše `přidat novou vzdálenou...` a použít odkaz `git://github.com/freeCodeCamp/freeCodeCamp.git` shora.
Jakmile synchronizujete rozštěpení a předejdete sestavení, budeme moci zkontrolovat Váš PR a sloučit. 😊
---
> Neváhejte odkazovat na [synchronizaci článku Fork](https://help.github.com/articles/syncing-a-fork/) na GitHub pro více informací o tom, jak udržet rozštěp s předním repozitářem. 🔄
>
> Také je to dobrá praxe na GitHubu psát stručný popis vašich změn při vytváření PR. 📝
``````
### Sloučit konflikty
> Pokud PR spojuje konflikty, které je třeba vyřešit..1
```markdown
Ahoj @username
Rádi bychom byli schopni sloučit vaše změny, ale zdá se, že máte nějaké fúzní konflikty. ⚠️
Jakmile tyto konflikty vyřešíte, budeme moci zkontrolovat Váš PR a sloučit. 😊
---
> Pokud nejste obeznámeni s procesem slučování, Neváhejte a podívejte se na GitHubův průvodce ["Vyřešení merge conflict"](https://help. ithub.com/articles/resolving-a-merge-conflict-on-github/). 🔍
>
> Také je dobré na GitHub napsat stručný popis vašich změn při vytváření PR. 📝
``````
1 Pokud má první přispěvatel fúzní konflikt, udržovatelé konflikt vyřeší.
### Duplicate
> Pokud je PR opakovaná nebo duplicitní.
```markdown
Hey @username
Zdá se, že podobné změny již byly přijaty dříve pro tento článek, který upravujete, je to líto. 😓
Pokud máte pocit, že jste přidali více, neváhejte otevřít nové PR.
Znovu děkuji! 😊
---
> Pokud máte jakékoliv dotazy, neváhejte se kontaktovat prostřednictvím [Gitter](https://gitter.im/FreeCodeCamp/Contributors) nebo níže uvedeným komentářem. 💬
```
### Zavření neplatných požadavků na natažení
> Když je PR neplatný.
```markdown
Ahoj @username
Nepřidali jste žádný obsah, zavříme tento PR a označíme jej jako `neplatné`. 😓
Nebojte se však otevřít další PR! 👍
```

481
docs/i18n/Czech/flight-manuals/working-on-virtual-machines.md Normal file
View File

@ -0,0 +1,481 @@
# Flight Manual for working on Virtual Machines
jako zaměstnanec nebo dev-team, vám byl umožněn přístup k našim poskytovatelům cloudových služeb, jako je Azure, Digital Ocean, atd.
Zde jsou nějaké přímočaré příkazy, které můžete použít k práci na virtuálních strojích (VM), například provádění aktualizací údržby nebo obecné houeskeeping.
# Get a list of the VMs
> [!POZNÁMKA] Zatímco již máte přístup k VM SSH, to samo o sobě vám neumožní seznam VM, pokud vám nebude umožněn přístup k cloudovým portálům.
## Azure
Nainstalujte Azure CLI `az`: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli
> **(One-time) Install on macOS with [`homebrew`](https://brew.sh):**
```
brew install azure-cli
```
> **(One-time) Login:**
```
az login
```
> **Get the list of VM names and P addresses:**
```
az vm list-ip-addresses --output table
```
## Digital Ocean
Nainstalujte si CLI Digital Ocean `doctl`: https://github.com/digitalocean/doctl#installing-doctl
> **(One-time) Install on macOS with [`homebrew`](https://brew.sh):**
```
brew install doctl
```
> **(One-time) Login:**
Přepínání ověřování a kontextů: https://github.com/digitalocean/doctl#auticating-with-digitalocean
```
doctl auth init
```
> **Get the list of VM names and IP addresses:**
```
doctl compute droplet list --format "ID,Name,PublicIPv4"
```
# Spin a VM (or VM Scale Set)
> Todo: Add instructions for spinning VM(s)
<!--
The below instructions are stale.
### 0. Prerequisites (workspace Setup) for Staff
Get a login session on `azure cli`, and clone the
[`infra`](https://github.com/freeCodeCamp/infra) for setting up template
workspace.
```console
az login
git clone https://github.com/freeCodeCamp/infra
cd infra
```
Use the Scratchpad subdirectory for temporary files, and making one-off edits.
The contents in this subdirectory are intentionally ignored from source control.
### 1. Provision VMs on Azure.
List all Resource Groups
```console
az group list --output table
```
```console
Name Location Status
--------------------------------- ------------- ---------
tools-rg eastus Succeeded
```
Create a Resource Group
```
az group create --location eastus --name stg-rg
```
```console
az group list --output table
```
```console
Name Location Status
--------------------------------- ------------- ---------
tools-rg eastus Succeeded
stg-rg eastus Succeeded
```
Next per the need, provision a single VM or a scaleset.
#### A. provision single instances
```console
az vm create \
--resource-group stg-rg-eastus \
--name <VIRTUAL_MACHINE_NAME> \
--image UbuntuLTS \
--size <VIRTUAL_MACHINE_SKU>
--custom-data cloud-init/nginx-cloud-init.yaml \
--admin-username <USERNAME> \
--ssh-key-values <SSH_KEYS>.pub
```
#### B. provision scaleset instance
```console
az vmss create \
--resource-group stg-rg-eastus \
--name <VIRTUAL_MACHINE_SCALESET_NAME> \
--image UbuntuLTS \
--size <VIRTUAL_MACHINE_SKU>
--upgrade-policy-mode automatic \
--custom-data cloud-init/nginx-cloud-init.yaml \
--admin-username <USERNAME> \
--ssh-key-values <SSH_KEYS>.pub
```
> [!NOTE]
>
> - The custom-data config should allow you to configure and add SSH keys,
> install packages etc. via the `cloud-init` templates in your local
> workspace. Tweak the files in your local workspace as needed. The cloud-init
> config is optional and you can omit it completely to do setups manually as
> well.
>
> - The virtual machine SKU is something like: **Standard_B2s** which can be
> retrived by executing something like
> `az vm list-sizes -l eastus --output table` or checking the Azure portal
> pricing.
-->
# Keep VMs updated
You should keep the VMs up to date by performing updates and upgrades. This will ensure that the virtual machine is patched with latest security fixes.
> [!WARNING] Before you run these commands:
>
> - Ujistěte se, že VM bylo poskytnuto zcela a neexistují žádné kroky po instalaci.
> - If you are updating packages on a VM that is already serving an application, make sure the app has been stopped / saved. Package updates will cause network bandwidth, memory and/or CPU usage spikes leading to outages on running applications.
Update package information
```console
sudo apt update
```
Upgrade installed packages
```console
sudo apt upgrade -y
```
Cleanup unused packages
```console
sudo apt autoremove -y
```
# Work on Web Servers (Proxy)
We are running load balanced (Azure Load Balancer) instances for our web servers. These servers are running NGINX which reverse proxy all of the traffic to freeCodeCamp.org from various applications running on their own infrastructures.
Konfigurace NGINX je k dispozici na [tomto repozitáři](https://github.com/freeCodeCamp/nginx-config).
## First Install
Provisioning VMs with the Code
### 1. (Optional) Install NGINX and configure from repository.
The basic setup should be ready OOTB, via the cloud-init configuration. SSH and make changes as necessary for the particular instance(s).
Pokud jste nepoužili konfiguraci cloud-init dříve použijte níže uvedené pro ruční nastavení NGINX a chybové stránky:
```console
sudo su
cd /var/www/html
git clone https://github.com/freeCodeCamp/error-pages
cd /etc/
rm -rf nginx
git clone https://github.com/freeCodeCamp/nginx-config nginx
cd /etc/nginx
```
### 2. Install Cloudflare origin certificates and upstream application config.
Získejte certifikáty původu Cloudflare z zabezpečeného úložiště a nainstalujte na požadovaných místech.
**OR**
Move over existing certificates:
```console
# Local
scp -r username@source-server-public-ip:/etc/nginx/ssl ./
scp -pr ./ssl username@target-server-public-ip:/tmp/
# Remote
rm -rf ./ssl
mv /tmp/ssl ./
```
Update Upstream Configurations:
```console
vi configs/upstreams.conf
```
Add/update the source/origin application IP addresses.
### 3. Setup networking and firewalls.
Configure Azure firewalls and `ufw` as needed for ingress origin addresses.
### 4. Add the VM to the load balancer backend pool.
Configure and add rules to load balancer if needed. You may also need to add the VMs to load balancer backend pool if needed.
## Aktualizace instancí (Maintenance)
1. Check status for NGINX service using the below command:
```console
sudo systemctl status nginx
```
2. Logging and monitoring for the servers are available at:
> <h3 align="center"><a href='https://amplify.nginx.com' _target='blank'>https://amplify.nginx.com</a></h3>
## Updating Instances (Maintenance)
Změny konfigurace v našich instancích NGINX jsou udržovány na GitHubu, měly by být nasazeny v každé instanci, jako také:
1. SSH into the instance and enter sudo
```console
sudo su
```
2. Get the latest config code.
```console
cd /etc/nginx
git fetch --all --prune
git reset --hard origin/master
```
3. Vyzkoušejte a obnovte konfiguraci [se signály](https://docs.nginx.com/nginx/admin-guide/basic-functionality/runtime-control/#controlling-nginx).
```console
nginx -t
nginx -s reload
```
# Work on API Instances
1. Install build tools for node binaries (`node-gyp`) etc.
```console
sudo apt install build-essential
```
## First Install
Provisioning VMs with the Code
1. Install Node LTS.
2. Update `npm` and install PM2 and setup logrotate and startup on boot
```console
npm i -g npm
npm i -g pm2
pm2 install pm2-logrotate
pm2 startup
```
3. Clone freeCodeCamp, setup env and keys.
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
cd freeCodeCamp
git checkout production-current # or any other branch to be deployed
```
4. Create the `.env` from the secure credentials storage.
5. Create the `google-credentials.json` from the secure credentials storage.
6. Install dependencies
```console
npm ci
```
7. Build the server
```console
npm run ensure-env && npm run build:server
```
8. Start Instances
```console
cd api-server
pm2 start production-start.js -i max --max-memory-restart 600M --name org
```
## Aktualizace instancí (Maintenance)
```console
## Logování a sledování
```console
pm2 logů
```
```console
pm2 monit
```
## Updating Instances (Maintenance)
Code changes need to be deployed to the API instances from time to time. It can be a rolling update or a manual update. The later is essential when changing dependencies or adding enviroment variables.
> [!DANGER] The automated pipelines are not handling dependencies updates at the minute. We need to do a manual update before any deployment pipeline runs.
### 1. Manual Updates - Used for updating dependencies, env variables.
1. Stop all instances
```console
pm2 stop all
```
2. Install dependencies
```console
npm ci
```
3. Build the server
```console
npm run ensure-env && npm run build:server
```
4. Start Instances
```console
pm2 start all --update-env && pm2 logs
```
### 2. Rolling updates - Used for logical changes to code.
```console
pm2 reload all --update-env && pm2 logs
```
> [!NOTE] We are handling rolling updates to code, logic, via pipelines. You should not need to run these commands. These are here for documentation.
# Work on Client Instances
1. Install build tools for node binaries (`node-gyp`) etc.
```console
sudo apt install build-essential
```
## First Install
Provisioning VMs with the Code
1. Install Node LTS.
2. Update `npm` and install PM2 and setup logrotate and startup on boot
```console
npm i -g npm
npm i -g pm2
npm install -g serve
pm2 install pm2-logrotate
pm2 startup
```
3. Clone client config, setup env and keys.
```console
git clone https://github.com/freeCodeCamp/client-config.git client
cd client
```
```console
git clone https://github.com/freeCodeCamp/client-config.git client
cd client
```
Spusťte zástupné instance pro webového klienta, budou aktualizovány s artefakty z Azure pipline.
> Todo: This setup needs to move to S3 or Azure Blob storage
>
> ```console
echo "serve -c ../../serve.json www -p 50505" >> client-start-primary.sh
chmod +x client-start-primary.sh
pm2 delete client-primary
pm2 start ./client-start-primary.sh --name client-primary
echo "serve -c ../../serve.json www -p 52525" >> client-start-secondary.sh
chmod +x client-start-secondary.sh
pm2 delete client-secondary
pm2 start ./client-start-secondary.sh --name client-secondary
```
## Aktualizace instancí (Maintenance)
```console
## Logování a sledování
```console
pm2 logů
```
```console
pm2 monit
```
## Updating Instances (Maintenance)
Code changes need to be deployed to the API instances from time to time. It can be a rolling update or a manual update. The later is essential when changing dependencies or adding enviroment variables.
> [!DANGER] The automated pipelines are not handling dependencies updates at the minute. We need to do a manual update before any deployment pipeline runs.
### 1. Manual Updates - Used for updating dependencies, env variables.
1. Stop all instances
```console
pm2 stop all
```
2. Install or update dependencies
3. Start Instances
```console
pm2 start all --update-env && pm2 logs
```
### 2. Rolling updates - Used for logical changes to code.
```console
pm2 reload all --update-env && pm2 logs
```
> [!NOTE] We are handling rolling updates to code, logic, via pipelines. You should not need to run these commands. These are here for documentation.

100
docs/i18n/Czech/how-to-catch-outgoing-emails-locally.md Normal file
View File

@ -0,0 +1,100 @@
> **Poznámka:** Toto je **volitelný** krok a je vyžadován pouze při práci s e-mailovými pracovními postupy
## Úvod
Některé e-mailové workflow, jako je aktualizace e-mailu uživatele, vyžaduje api-server na back-end odeslání odchozích e-mailů. alternativou k použití poskytovatele e-mailové služby pro odesílání aktuálních e-mailových zpráv, Mailhog je vývojářský nástroj pro testování e-mailů, který bude chytat zprávy odeslané instancí vašeho freeCodeCamp.
## Instalace MailHog
MailHog může být nainstalován na macOS, Windows a Linux.
- [Úvod](#introduction)
- [Instalace MailHog](#installing-mailhog)
- [Instalace MailHog na macOS](#installing-mailhog-on-macos)
- [Instalace MailHog na Windows](#installing-mailhog-on-windows)
- [Instalace MailHog na Linux](#installing-mailhog-on-linux)
- [Použití MailHog](#using-mailhog)
- [Užitečné odkazy](#useful-links)
### Instalace MailHog na macOS
Nainstalujte MailHog na macOS s [Homebrew](https://brew.sh/):
```bash
brew install mailhog
brew services start mailhog
```
Výše uvedené příkazy spustí mailhog službu na pozadí.
Po dokončení instalace můžete spustit [pomocí MailHog](#using-mailhog).
### Instalace MailHog na Windows
Stáhněte si nejnovější verzi MailHog z oficiálního repositáře [MailHog's](https://github.com/mailhog/MailHog/releases). Najděte a klikněte na odkaz pro verzi Windows (32 nebo 64 bitů) a soubor .exe bude stažen do vašeho počítače.
Po dokončení stahování klikněte pro otevření souboru. Může se objevit notifikace Windows firewall s žádostí o přístupové oprávnění pro MailHog. Standardní příkazová řádka Windows se otevře tam, kde bude MailHog spuštěn, jakmile bude umožněn přístup k firewall.
Zavřete MailHog zavřením okna s výzvou k příkazu. Chcete-li znovu spustit MailHog, klikněte na spustitelný soubor MailHog (. xe) soubor, který byl původně stažen - není nutné stahovat nový instalační soubor MailHog.
Začněte [používat MailHog](#using-mailhog).
### Instalace MailHog na Linux
Nejprve nainstalujte [Go](https://golang.org).
Spusťte následující příkazy k instalaci GO na systémy jako Ubuntu a Linux Mint.
```bash
sudo apt-get install golang
```
Spusťte následující příkazy k instalaci GO na systémy založené na RPM jako CentOS, Fedora, Red Hat Linux, atd.
```bash
sudo dnf install golang
```
Případně spusťte následující příkazy k instalaci GO.
```bash
sudo yum install golang
```
Nyní nastavte cestu pro Jít s následujícími příkazy.
```bash
echo "export GOPATH=$HOME/go" >> ~/.profile
ozvěna 'export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin' >> ~/.profile
source ~/.profile
```
Konečně zadejte příkazy níže pro instalaci a spuštění MailHog.
```bash
go get github.com/mailhog/MailHog
sudo cp /home/$(whoami)/go/bin/MailHog /usr/local/bin/mailhog
mailhog
```
Začněte [používat MailHog](#using-mailhog).
## Použití MailHog
Otevřete novou záložku nebo okno prohlížeče a přejděte na [http://localhost:8025](http://localhost:8025) pro otevření vaší schránky MailHog po dokončení instalace MailHog a spuštění MailHog. Doručená pošta se zobrazí podobně jako snímek obrazovky níže.
![MailHog Screenshot 1](images/mailhog/1.jpg)
E-maily odeslané vaší instalací freeCodeCamp se zobrazí níže
![MailHog Screenshot 2](images/mailhog/2.jpg)
Při otevření daného e-mailu budou k dispozici dvě záložky, které vám umožní zobrazit prostý text nebo zdrojový obsah. Ujistěte se, že je vybrána záložka prostého textu, jak je uvedeno níže.
![MailHog Screenshot 3](images/mailhog/3.jpg)
Všechny odkazy v e-mailu by měly být možné kliknout a vyřešit jejich URL.
## Užitečné odkazy
- Podívejte se na úložiště [MailHog](https://github.com/mailhog/MailHog) pro další informace týkající se MailHog. Další informace jsou k dispozici také o vlastních konfiguracích MailHog.

199
docs/i18n/Czech/how-to-help-with-video-challenges.md Normal file
View File

@ -0,0 +1,199 @@
# Jak pomoci s výzvami videa
Video výzvy jsou novým typem výzvy v osnovách freeCodeCamp.
Video výzva je malá část videohovoru s plnou délkou na konkrétní téma. Stránka s výzvou pro video vloží YouTube video. Každá stránka s výzvou má jednu otázku s možností výběru z více možností, která se týká videa. Uživatel musí odpovědět na otázku správně, než v kurzu přejde na další videohovor.
Stránky video challenge jsou vytvořeny členy týmu freeCodeCamp. YouTube videa jsou také nahrávána členy FreeCodeCamp týmu. Mnohé z videohovorů s nimi ještě nejsou spojeny.
Můžete pomoci vytvořením otázek s více možnostmi souvisejících s kapitolami video a přidáním otázek do souborů markdown pro videohovory.
## Šablona výzvy
Níže je šablona toho, jak vypadají soubory challenge markdown.
````md
---
id: jedinečný identifikátor (alfanumerický, MongoDB_id)
název: Challenge Title
challengeType: 11
videoId: 'YouTube videoId pro video challenge'
---
## Popis
<section id='description'>
Volitelný popis s užitečnými informacemi o videu.
</section>
## Testy
<section id='tests'>
```yml
otázka:
text: 'Otázka'
odpovědi:
- 'Odpovězte na jedno'
- 'Odpověď'
- 'Odpověď'
řešení: 3
````
</section>
````
## Vytváření otázek pro videohovory challenge markdown
### Přístup k souborům pro video challenge markdown
Najdete soubory markdown pro videohovory na následujících místech ve učebních osnovách:
- [Datová analýza s Pythonovým kurzem](https://github. om/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/08-data-analysis-with-python/data-analysis-with-python-course)
- [TensorFlow 2.0 Course](https://github. om/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/11-machine-learning-with-python/tensorflow)
- [Numpy Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/08-data-analysis-with-python/numpy)
- [How Neural Networks Work Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/11-machine-learning-with-python/how-neural-networks-work)
Pick a challenge markdown soubor z možností výše.
### Skim přes video spojené s výzvou a vytvořte otázku "mutiple select"
Nejprve najděte videoId.
Například, v následujícím kódu z záhlaví video challenge markdown souboru, videoId je "nVAaxZ34khk". Na GitHubu by informace měly být rozvrženy ve formátu tabulky.
````
---
id: 5e9a093a74c4063ca6f7c14d title: Data Analysis Příklad A challengeType: 11
videoId: nVAaxZ34khk
---
```
Dále získejte přístup k YouTube video s tímto videem. Adresa url videa bude:
https://www.youtube. om/watch?v=[videoId] (přidat videoID k URL bez hranatých závorek)
V příkladu výše je url https://www. outube.com/watch?v=nVAaxZ34khk
Skim YouTube video s tímto videoID a přemýšlejte o otázce s vícenásobným výběrem na základě obsahu videa.
### Přidejte otázku do souboru markdown
Otázku můžete přidat lokálně nebo přímo přes rozhraní GitHub. Chceš-li tuto otázku lokálně přidat, musíš [nastavit freeCodeCamp lokálně](how-to-setup-freecodecamp-locally.md). Na GitHub můžete také najít soubor a kliknout na tlačítko upravit pro přidání otázky přímo ve vašem prohlížeči.
Pokud otázka ještě nebyla přidána do konkrétní video výzvy, bude mít následující výchozí otázku:
```yml
otázka:
text: |
Odpovědi
:
- |
jeden
- |
dva
- |
tři
řešení: 3
```
Aktualizujte slovo „otázka“ na vaši otázku. Aktualizujte „jeden“, „dva“ a „tři“ s možnými odpověďmi. Ujistěte se, že aktualizujete číslo řešení, se kterým je odpověď správná. Můžete přidat více možných odpovědí pomocí stejného formátu. Otázka a odpovědi mohou být obklopeny uvozovkami.
#### Použijte markdown pro formátování otázky
Text v této otázce je uveden jako markdown. Nejjednodušším způsobem, jak se ujistit, že je správně naformátovaný, je začít s `textem: |`, jako je toto:
```yml
otázka:
text: |
Otázka
```
Potom se musíte ujistit, že vaše otázka je na nové řádce a odsazená o jednu úroveň je více než `text: |`.
Stejný přístup lze použít i pro odpovědi, takže se celá otázka stane
```yml
Otázka:
text: |
Odpovědi
- |
První odpověď
- |
Druhý
- |
Třetí
řešení: 2
```
Ujistěte se, že je každá odpověď věrohodná, ale existuje pouze jedna správná odpověď.
#### Použití HTML
Otázky a odpovědi mohou obsahovat určité HTML tagy jako `<br>` pro nový řádek. HTML tagy by měly být používány opatrně, když bez nich nemohou být vyjádřeny otázky.
### Příklady otázek
#### Příklady bez HTML
````yml
Otázka:
text: |
Co dělá tento JavaScript kód log?
```js
console.log('hello world');
````
Vyberte odpověď!
odpovědi:
- | ahoj *svět*
- | **ahoj** svět
- | Ahoj svět řešení: 3
````
````yml
otázka:
text: |
Co se vytiskne po spuštění tohoto kódu:
```py
šířka = 15
výška = 12.
vytisknout (výška/3)
````
odpovědi:
- | 39
- | 4
- | 4.0
- | 5.0
- | 5 roztok: 3
````
#### Příklad s HTML
```yml
otázka:
text: |
Co se vytiskne po spuštění tohoto kódu:
<pre><code>šířka = 15<br>výška = 12.<br>tiskárny (výška/3)<code></pre>
odpovědí:
- |
39
- |
4
- |
4.
- |
5.
- |
5
roztok: 3
````
Konečný příklad ukazuje, že HTML lze použít, ale není tak čitelná jako verze bez ní.
Více příkladů se můžete podívat na soubory markdown pro následující video kurz. Všechny challenge keše již mají otázky: [Python pro každý kurz](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/07-scientific-computing-with-python/python-for-everybody)
## Otevřít požadavek na natažení
Po vytvoření jedné nebo více otázek můžete provést změny do nové větve a [otevřít požadavek na natažení](how-to-open-a-pull-request.md).

179
docs/i18n/Czech/how-to-open-a-pull-request.md Normal file
View File

@ -0,0 +1,179 @@
# Jak otevřít požadavek na natažení (PR)
Požadavek na natažení umožňuje odesílat změny z tvého rozštěpení na GitHubu na hlavní repositář FreeCodeCamp.org. Jakmile provedete změny kódu, nebo kódovací výzvy, měli byste se řídit těmito pokyny a poslat PR.
## Připravte dobrý PR název
Doporučujeme použít [běžný název a zprávy](https://www.conventionalcommits.org/) pro revize a požadavek na natažení. Úmluva má tento formát:
> `<type>([volitelný rozsah(y)]): <description>`
>
> Například:
>
> `fix(naučení): testy pro to... zatímco smyčka výzva`
Při otevírání Pull Request(PR) můžete použít níže uvedené k určení typu, rozsahu (volitelné) a popisu.
**Typ:**
| Typ | Kdy vybrat |
|:----------- |:---------------------------------------------------------------------------- |
| opravit | Změněná nebo aktualizovaná/vylepšená/funkčnost, zkoušky, verbiáž lekce, atd. |
| pek | Pouze pokud přidáváte nové funkce, testy atd. |
| koruna | Změny, které se nevztahují k kódu, testům nebo slovnímu znění lekce. |
| dokumentace | Změny adresáře `/docs` nebo pokynů pro přispívání atd. |
**Oblast působnosti:**
Můžete si vybrat rozsah z [tohoto seznamu štítků](https://github.com/freeCodeCamp/freeCodeCamp/labels?q=scope).
**Popis:**
Zachovejte ji krátkou (méně než 30 znaků) a jednoduše můžete přidat více informací do políčka pro popis PR a komentáře.
Některé příklady dobrých PRS by byly:
- `fixa11y): zlepšený kontrast vyhledávací lišty`
- `funkce: přidejte další testy do html a css challenge`
- `oprava (api,client): brání chybám CORS při vkládání formulářů`
- `Dokumenty(i18n): Čínský překlad lokálního nastavení`
## Návrh požadavku na natažení
1. Jakmile budou provedeny úpravy, budete vyzváni k vytvoření požadavku na natažení na GitHubu stránce.
![Obrázek - Porovnat požadavek na natažení na GitHubu](./images/github/compare-pull-request-prompt.png)
2. Ve výchozím nastavení by všechny požadavky na natažení měly být proti hlavnímu repozitáři freeCamp `, master` větvi.
Ujistěte se, že při zvednutí požadavku na natažení je vaše základní rozštěpení nastaveno na volný CodeCamp/freeCodeCamp
![Obrázek - porovnávání vidlic při požadavku na natažení](./images/github/comparing-forks-for-pull-request.png)
3. Odešlete požadavek na natažení od větev na pobočku freeCodeCamp's `master` FreeCamp.
4. V těle vašeho PR uveďte podrobnější shrnutí změn, které jste provedli a proč.
- Budete prezentováni s šablonou požadavku na natažení. Toto je kontrolní seznam, který jste měli před otevřením požadavku na natažení následovat.
- Vyplňte podrobnosti, jak to považujete za vhodné. Tyto informace budou přezkoumány a hodnotitelé rozhodnou, zda je vaše žádost o natažení přijata, či nikoli.
- Pokud má PR řešit existující GitHub problém, pak na konci popisného orgánu vašeho PR, použít klíčové slovo _Zavře_ s číslem úkolu [automaticky zavřít tento úkol, pokud je PR přijat a sloučen](https://help.github.com/en/articles/closing-issues-using-keywords).
> Příklad: `Uzavře #123` zavře úkol 123
5. Uveďte, zda jste testovali na místní kopii stránky, nebo ne.
To je velmi důležité při provádění změn, které nejsou pouhými úpravami textového obsahu, jako je dokumentace nebo popis výzvy. Příklady změn, které vyžadují místní testování, zahrnují JavaScript, CSS nebo HTML, které mohou změnit funkčnost nebo rozložení stránky.
## Zpětná vazba na požadavky na natažení
> Blahopřejeme! :tada: při vytváření PR a moc děkujeme za to, že věnoval čas na příspěvek.
Naši moderátoři se nyní podívají a zanechají vám zpětnou vazbu. Buďte prosím trpěliví s kolegy moderátory a respektujte jejich čas. Všechny požadavky na natažení jsou včas přezkoumány.
Pokud potřebujete pomoc, prosím diskutujte v chatovací místnosti [přispěvatelů](https://gitter.im/FreeCodeCamp/Contributors), rádi Vám pomůžeme.
> [!TIP] Pokud chcete přispět dalšími požadavky na natažení, doporučujeme přečíst si [dělat změny a synchronizovat](https://contribute.freecodecamp.org/#/how-to-setup-freecodecamp-locally?id=making-changes-locally) pokyny, abyste nemuseli mazat vaše rozštěpení.
## Konflikty na žádost o stažení
Konflikty mohou nastat, protože mnoho přispěvatelů pracuje v úložišti a změny mohou poškodit váš PR, který čeká na recenzi a fúzi.
Častěji než nemusíte vyžadovat rebázi, protože všechny závazky rozmělňujeme, Nicméně pokud je zde požadována rebace, je to, co byste měli udělat.
### Pro běžné opravy chyb a funkce
Když pracujete na běžných chybách a funkcích na naší vývojové větvi `master`můžete udělat jednoduchou rebázi:
1. Rebujte svou místní kopii:
```console
git checkout <pr-branch>
git pull --rebase proti master
```
2. Vyřešit konflikty a přidat / upravit revize
```console
# Buď
git add .
git commit -m "chore: resolve conflicts"
# Or
git add .
git commit --amend --no-edit
```
3. Přesuňte změny zpět do PR
```console
git push --force původ <pr-branch>
```
### Pro nadcházející učební plány a funkce
Když pracujete na funkcích pro naše nadcházející učební osnovy `další*` pobočky, máte možnost vybrat:
1. Ujistěte se, že váš předcházející stream je synchronizován s vašimi lokálními:
```console
git checkout master
git fetch --all --prune
git checkout next-python-projects
git reset --hard upstream/next-python-projects
```
2. Vytvořit zálohu
„Technologie“ ve smyslu všeobecné poznámky k technologii pro „vývoj“, „výrobu“ nebo „užití“ zařízení nebo „softwaru“ uvedených v položkách 3A, 3B nebo 3D. Buď smažte svou místní větev po přijetí zálohy (pokud ji stále lokálně máte):
```console
git checkout <pr-branch-name>
# příklad:
# git checkout feat/add-numpy-video-question
git checkout -b <backup-branch-name>
# příklad:
# git checkout -b backup-feat/add-numpy-video-question
git branch -D <pr-branch-name>
```
„Technologie“ ve smyslu všeobecné poznámky k technologii pro „vývoj“, „výrobu“ nebo „užití“ zařízení nebo „softwaru“ uvedených v položkách 7A, 7B nebo 7C. Nebo jen zálohu vaší pr větve (pokud ji lokálně nemáte):
```console
git checkout -b <backup-branch-name> origin/<pr-branch-name>
# příklad:
# git checkout -b backup-feat/add-numpy-video-question origin/feat/add-numpy-video-question
```
4. Začněte s čistým slatem:
```console
git checkout -b <pr-branch-name> next-python-projects
git cherry-pick <commit-hash>
```
5. Vyřešit konflikty a vyčistit, nainstalovat testy
```console
npm run clean
npm ci
npm run test:curriculum --superblock=<superblock-name>
# example:
# npm run test:curriculum --superblock=python-for-everybody
```
6. Pokud vše vypadá dobře zpátky do PR
```console
git push --force původ <pr-branch-name>
```

546
docs/i18n/Czech/how-to-setup-freecodecamp-locally.md Normal file
View File

@ -0,0 +1,546 @@
Postupujte podle těchto pravidel pro lokální nastavení freeCodeCamp ve vašem systému. To je velmi doporučeno, pokud chcete přispívat pravidelně.
Pro některé příspěvkové workflow, musíte mít freeCodeCamp běžet lokálně. Například, prohlížení výzev kódování nebo ladění a opravování chyb v kódu.
> [!TIP] Pokud nemáte zájem o nastavení bezplatného CodeCamp lokálně zvážit použití Gitpod, bezplatné online prostředí pro vývojáře.
>
> [![Otevřít v Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
>
> (Spustí prostředí vývojáře připraveného ke kódu pro freeCodeCamp ve vašem prohlížeči.)
## Připravte svůj místní stroj
Začněte instalací nezbytného softwaru pro váš operační systém.
Podporujeme především vývoj na **\*nix** systémech. Naši zaměstnanci a přispěvatelé komunity pravidelně pracují s kódovou databází pomocí nástrojů nainstalovaných na Ubuntu a macOS.
Podporujeme také Windows 10 prostřednictvím WSL2, který můžete připravit na [čtení tohoto průvodce](/how-to-setup-wsl).
Někteří členové komunity se také vyvíjejí na Windows 10 nativně s Git pro Windows (Git Bash) a dalšími nástroji nainstalovanými v Windows. V tuto chvíli nemáme oficiální podporu pro takové nastavení, doporučujeme místo toho použít WSL2.
**Předpoklady:**
| Předpokladem | Verze | Poznámky |
| --------------------------------------------------------------------------------------------- | ----- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Node.js](http://nodejs.org) | `12x` | [LTS rozvrh](https://github.com/nodejs/Release#release-schedule) |
| npm (přichází s Nodem) | `6.x` | Nemá žádné verze LTS, používáme verzi propojenou s Node LTS |
| [MongoDB komunitní server](https://docs.mongodb.com/manual/administration/install-community/) | `3.6` | [Poznámky k vydání](https://docs.mongodb.com/manual/release-notes/), Poznámka: Aktuálně jsme na `3.6`, [aktualizace je naplánována](https://github.com/freeCodeCamp/freeCodeCamp/issues/18275). |
> [!DANGER] Pokud máte jinou verzi, nainstalujte prosím doporučenou verzi. Podporujeme pouze problémy s instalací doporučených verzí. Detaily viz [řešení problémů](#troubleshooting).
Pokud je Node.js již nainstalován na vašem počítači, spusťte následující příkazy pro ověření verzí:
```console
uzel -v
npm -v
```
> [!TIP] Důrazně doporučujeme aktualizovat na nejnovější stabilní verze výše uvedeného softwaru, známého také jako Long Term Support (LTS) release.
Jakmile máte nainstalované předpoklady, musíte připravit své vývojové prostředí. To je běžné u mnoha vývojových pracovních postupů a budete to muset udělat pouze jednou.
**Postupujte podle těchto kroků, abyste mohli své vývojové prostředí připravit:**
1. Nainstalujte [Git](https://git-scm.com/) nebo Vašeho oblíbeného Git klienta, pokud již nemáte. Aktualizujte na nejnovější verzi; verze, která byla připojena k vašemu OS může být zastaralá.
2. (Volitelné, ale doporučeno) [Nastavte klíč SSH](https://help.github.com/articles/generating-an-ssh-key/) pro GitHub.
3. Nainstalujte si editor kódu dle vašeho výběru.
Důrazně doporučujeme používat [Visual Studio Code](https://code.visualstudio.com/) nebo [Atom](https://atom.io/). Jsou to skvělé, zdarma a open source editory.
4. Nastavte odkaz pro editor kódu.
V editoru byste měli mít [ESLint](http://eslint.org/docs/user-guide/integrations.html), a zvýrazní vše, co neodpovídá
> [!TIP] Neignorujte prosím žádné chyby odkazu. Mají pomoci **vám** a zajistit čistou a jednoduchou kódovou základnu.
## Rozštěpit úložiště na GitHubu
příručce JavaScriptů [ freeCodeCamp.](http://forum.freecodecamp.org/t/free-code-camp-javascript-style-guide/19121).
Toto je nezbytné, protože umožňuje pracovat na vlastní kopii freeCodeCamp na GitHubu, nebo stáhnout (klonovat) váš repozitář, aby fungoval lokálně. Později budete moci prostřednictvím požadavku na natažení (PR) požádat o změny na hlavní repozitář.
> [!TIP] Hlavní repozitář na `https://github.com/freeCodeCamp/freeCodeCamp` je často označován jako `předcházející repozitář`.
>
> Vaše rozštěpení na `https://github.com/YOUR_USER_NAME/freeCodeCamp` je často označováno jako `původ`.
**Postupujte podle těchto kroků a rozštěpte repozitář `https://github.com/freeCodeCamp/freeCodeCamp`:**
1. Přejděte do repositáře freeCodeCamp na GitHub: <https://github.com/freeCodeCamp/freeCodeCamp>
2. Klikněte na tlačítko "Fork" v pravém horním rohu rozhraní ([Další podrobnosti](https://help.github.com/articles/fork-a-repo/))
3. Po rozdělení repozitáře budete pořízeni do kopie repositáře freeCodeCamp na `https://github.com/YOUR_USER_NAME/freeCodeCamp`
<details>
<summary>
Jak rozštěpit volný CodeCamp na GitHubu (snímek obrazovky)
</summary>
<br>
<img src="https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/master/docs/images/github/how-to-fork-freeCodeCamp.gif" alt="Jak rozštěpit bezplatný CodeCamp na GitHubu" />
</details>
## Klonovat rozštěpení z GitHub
[Klonování](https://help.github.com/articles/cloning-a-repository/) je místo, kde **stáhnete** kopii repozitáře z `vzdálené` polohy, kterou buď vlastníte, nebo někdo jiný. V takovém případě je toto vzdálené umístění vaší `fork` z repozitáře freeCodeCamp, který by měl být k dispozici na `https://github.com/YOUR_USER_NAME/freeCodeCamp`.
Spustit tyto příkazy na vašem lokálním počítači:
1. Otevřete Terminál / Příkazový příkaz / Shell v adresáři projektů
_tj.: `/yourprojectsdirectory/`_
2. Klonujte si rozštěpení volného CodeCamp, nahrazte `YOUR_USER_NAME` vaším GitHub uživatelským jménem
```console
git klonovat --depth=1 https://github.com/YOUR_USER_NAME/freeCodeCamp.git
```
Spustit tyto příkazy na vašem lokálním počítači:
Toto stáhne celý freeCodeCamp repositář do adresáře projektů.
## Nastavit synchronizaci od nadřazeného
Poznámka: `--depth=1` vytvoří mělký klon tvého vidlice s nejaktuálnější historií/commit.
[Jak již bylo zmíněno](#fork-the-repository-on-github), hlavní repozitář je určen `před repozitářem`. Vaše rozštěpení označované jako `původ`.
Potřebujete odkaz z vašeho lokálního klonu do `předcházejícího` repozitáře kromě `původu`. To je tak, že můžete synchronizovat změny z hlavního repositáře bez požadavku na opakované vytváření a klonování.
1. Změnit adresář na nový freeCodeCamp adresář:
```console
cd bezplatný CodeCamp
```
2. Přidat vzdálený odkaz do hlavního repositáře freeCodeCamp:
```console
git remote add upstream https://github.com/freeCodeCamp/freeCodeCamp.git
```
3. Ujistěte se, že konfigurace vypadá správně:
```console
git remote -v
```
Výstup by měl vypadat jako níže:
```console
původ https://github.com/YOUR_USER_NAME/freeCodeCamp.git (fetch)
původ https://github.com/YOUR_USER_NAME/freeCodeCamp.git (push)
upstream https://github.com/freeCodeCamp/freeCodeCamp.git (fetch)
upstream https://github.com/freeCodeCamp/freeCodeCamp.git (push)
```
## Místně spuštěný bezplatný CodeCamp
Nyní, když máte lokální kopii freeCodeCamp, můžete sledovat tyto instrukce a spustit je lokálně. To vám umožní:
- Náhled úprav na stránky, jak by se objevily na platformě učení.
- Práce na problémech a vylepšeních souvisejících s uživatelským rozhraním.
- Ladit a opravit problémy s aplikačními servery a klientskými aplikacemi.
Pokud se narazíte na problémy, nejprve proveďte vyhledání vašeho problému a zjistěte, zda byl již zodpovězen. Pokud nemůžete najít řešení, prosím prohledejte naše [GitHub problémy](https://github.com/freeCodeCamp/freeCodeCamp/issues) pro řešení a nahlaste problém, pokud ještě nebyl nahlášen.
A jako vždy, neváhejte skočit na naši [Chatovací místnost na Gitteru](https://gitter.im/FreeCodeCamp/Contributors) nebo [náš Discord server](https://discord.gg/6vJYm9V), pro rychlé dotazy.
> [!TIP] Pokud jednoduše upravujete soubory, můžete ho přeskočit lokálně. Například provedení `rebase`nebo řešení `sloučení` konfliktů.
>
> Do této části pokynů se vždy můžete vrátit později. Měli byste **** tento krok přeskočit, pokud nepotřebujete spouštět aplikace na vašem počítači.
>
> [Přeskočit na provedení změn](#making-changes-locally).
### Nastavení závislostí
#### Krok 1: Nastavte proměnnou prostředí
Výchozí API klíče a proměnné prostředí jsou uloženy v souboru `sample.env`. Tento soubor musí být zkopírován do nového souboru s názvem `.env` , který je dynamicky přístupný během instalačního kroku.
```console
# Vytvořte kopii "sample.env" a pojmenujte ji ".env".
# Vyplňte potřebné API klíče a tajné klíče:
# macOS / Linux
cp vzorek. nv .env
# Windows
copy sample.env .env
```
Klávesy v souboru `.env` nejsou __ vyžadovány pro místní spuštění aplikace. Můžete ponechat výchozí hodnoty zkopírované z `vzor.env` jako.
> [!TIP] Mějte na paměti, pokud chcete používat služby jako Auth0 nebo Algolia, pro tyto služby budete muset získat vlastní API klíče a odpovídajícím způsobem upravit položky v `. nv` soubor.
#### Krok 2: Instalovat závislosti
Tento krok nainstaluje závislosti, které jsou nezbytné pro spuštění aplikace:
```console
npm ci
```
#### Krok 3: Start MongoDB a seed databáze
Než budete moci spustit aplikaci lokálně, budete muset spustit službu MongoDB.
> [!POZNÁMKA] Pokud není MongoDB spuštěno v jiném nastavení, než je výchozí nastavení, URL uložená jako hodnota `MONGOHQ_URL` v `. nv` soubor by měl fungovat v pořádku. Pokud používáte vlastní konfiguraci, upravte tuto hodnotu podle potřeby.
Tento krok nainstaluje závislosti, které jsou nezbytné pro spuštění aplikace:
- Na macOS & Ubuntu:
```console
mongod
```
- V systému Windows musíte zadat úplnou cestu k binárnímu `mongod`
```console
"C:\Program Soubory\MongoDB\Server\3.6\bin\mongod"
```
Ujistěte se, že chcete nahradit `3.6` verzí, kterou jste nainstalovali
> [!TIP] Můžete se vyhnout tomu, abyste MongoDB museli kdykoliv spustit instalací služby na pozadí. Můžete se o tom [dozvědět více v jejich dokumentaci pro váš OS](https://docs.mongodb.com/manual/administration/install-community/)
Dále pojďme získat databázi. V tomto kroku spustíme níže uvedený příkaz, který vyplňuje server MongoDB s počátečními datovými sadami, které jsou vyžadovány službami. Patří k nim mimo jiné několik schémat.
```console
npm run seed
```
#### Krok 4: Spusťte klientskou aplikaci FreeCamp a API server
Spusťte MongoDB server v samostatném terminálu:
```console
vývoj npm běhu
```
Ujistěte se, že chcete nahradit `3.6` verzí, kterou jste nainstalovali
> [!POZNÁMKA] Jakmile je tento prohlížeč připraven, otevřete webový prohlížeč a **navštivte <http://localhost:8000>**. Pokud se aplikace načítá, blahopřejeme – vše je nastaveno! Nyní máte kopii celé vzdělávací platformy FreeCodeCamp, která běží na vašem místním počítači.
> [!TIP] API Server slouží API na `http://localhost:3000`. Aplikace Gatsby slouží klientské aplikaci na `http://localhost:8000`
> Pokud navštívíte [http://localhost:3000/Explorer](http://localhost:3000/explorer) , měli byste vidět dostupné API.
## Přihlásit se s místním uživatelem
Vaše místní nastavení automaticky vyplní místního uživatele v databázi. Kliknutím na tlačítko `Přihlásit se` vás automaticky ověří do místní aplikace.
Nicméně přístup k uživatelským portfoliovým stránkám je trochu trický. Ve vývoji, Gatsby přebírá obsluhu stránek na straně klienta a proto dostanete `404` stránku pro uživatelské portfolio při lokálním fungování.
Tento jediný příkaz spustí všechny služby, včetně API serveru a klientských aplikací, na kterých můžete pracovat.
<details>
<summary>
Jak se přihlásit při práci na místě (snímek obrazovky)
</summary>
<br>
<img src="https://user-images.githubusercontent.com/29990697/71541249-f63cdf00-2923-11ea-8a85-cefb6f9c9977.gif" alt="Jak se přihlásit při práci na místě" />
</details>
## Probíhá lokální změny
Nyní můžete provést změny v souborech a provést změny v místním klonu rozštěpení.
Postupujte podle těchto kroků:
1. Ověřte, že jste na `master` větvi:
```console
git status
```
Měli byste získat výstup takto:
```console
Na pobočce master
Vaše větev je aktuální s 'původ/mistrovství'.
nic k ověření, čištění pracovního adresáře
```
Pokud nejste na mistru nebo není váš pracovní adresář čistý, vyřešte všechny nevyřízené soubory/commity a pokladnu `master`:
```console
mistr git pokladny
```
2. Synchronizujte nejnovější změny z volné CodeCamp proti proudu `master` do vaší místní hlavní větve:
> [!VAROVÁNÍ] Pokud máte nějaký nevyřízený požadavek na natažení, který jste podali od `master` větve tvého vidlice, na konci tohoto kroku je ztratíte.
>
> Před provedením tohoto kroku byste měli zajistit, aby byl váš požadavek na natažení sloučen moderátorem. Abychom se tomuto scénáři vyhnuli, měli byste **vždy** pracovat na jiné větvi než je `master`.
Tento krok **synchronizuje nejnovější změny** z hlavního repositáře freeCodeCamp. Je důležité, abyste přeorientovali větev na nejnovější `upstream/master` co nejčastěji, abyste se později vyhnuli konfliktům.
Aktualizujte svou lokální kopii repositáře freeCodeCamp před repozitářem:
```console
git načíst proti proudu
```
Těžko resetovat svou hlavní větev pomocí volného CodeCamp master:
```console
git resetuje --hard upstream/master
```
Stiskněte svou hlavní větev do svého původu, abyste měli čistou historii na tvém forku na GitHubu:
```console
git push origin master --force
```
Váš aktuální mistr se shoduje s aktuálním streamem/mistrem tím, že provedete rozdíl:
```console
git odlišit nahoru/master
```
Výsledný výstup by měl být prázdný.
3. Vytvořit novou větev:
Práce na samostatné pobočce pro každý problém vám pomůže udržet vaši místní kopii čistý. Nikdy byste neměli pracovat na `mistrovi`. Uloží vaši kopii freeCodeCamp a možná budete muset začít s novým klonem nebo vidlicí.
Zkontrolujte, zda jste na `master` , jak bylo vysvětleno výše, a odsud odešlete od:
```console
git checkout -b fix/update-guide-for-xyz
```
Název větve by měl začínat `fix/`, `funkcí/`, `dokumentací/`, atd. Vyhněte se používání čísel úkolů v větvích. Uchovávejte je krátké, smysluplné a jedinečné.
Mezi dobré názvy poboček patří:
```md
fix/update-challenges-for-react
fix/update-guide-for-html-css
fix/platform-bug-sign-in-issues
feat/add-guide-article-for-javascript
translate/add-spanish-basic-html
```
4. Upravte stránky a pracujte na kódu v oblíbeném textovém editoru.
5. Jakmile jste spokojeni se změnami, měli byste volitelně spustit freeCodeCamp pro zobrazení změn.
6. Ujistěte se, že jste opravili chyby a zkontrolujte formátování změn.
7. Zkontrolujte a potvrďte aktualizované soubory:
```console
git status
```
Toto by mělo zobrazit seznam `nefázovaných` souborů, které jste upravili.
```console
Funkce větev / dokumentace
Vaše větev je aktuální s 'upstream/feat/documentation'.
Změny nejsou ve stadiu pro commit:
(použijte "git add/rm <file>... pro aktualizaci toho, co bude přidáno)
(použijte "git checkout -- <file>. " pro odstranění změn v pracovním adresáři)
změněny: PŘÍSPĚVEK d
změněn: dokumenty/README.md
změněny: dokumenty/how-to-setup-freecodecamp-local. d
změněny: dokumentaci/jak-work-on-guide-articles.md
...
```
8. Funguje změny a učiní závazek:
V tomto kroku byste měli označit pouze soubory, které jste upravili nebo přidali. Můžete provést resetování a vyřešit soubory, které jste v případě potřeby nezamýšleli změnit.
```console
git přidat cestu/do/my/changed/file.ext
```
Nebo můžete přidat všechny `nefázované` soubory do oblasti přípravy:
```console
git add .
```
Až vytvoříte commit, budou přidány pouze soubory, které byly přesunuty do přípravné oblasti.
```console
git status
```
Výstup:
```console
Funkce větev / dokumentace
Vaše větev je aktuální s 'upstream/feat/documentation'.
Změny, které mají být provedeny:
(použijte "git reset HEAD <file>..." to unstage)
změněny: CONTRIBUTING.md
změněny: docs/README.md
změněny: docs/how-to-setup-freecodecamp-locally.md
upraveno: docs/how-to-work-on-guide-articles.md
```
Nyní můžete provést své změny s krátkou zprávou, jako je toto:
```console
git commit -m "opravit: moje krátká zpráva commitu"
```
Některé příklady:
```md
oprava: update guide article for Java - for smyčka
feat: add guide article for alexa skills
```
Nepovinné:
Důrazně doporučujeme vytvořit konvenční zprávu commitu. Toto je dobrá praxe, kterou uvidíte u některých populárních Open Source repozitářů. Jako vývojář vás to povzbuzuje ke sledování standardních postupů.
Některé příklady konvenčních zpráv commitů jsou:
```md
oprava: update HTML guide article
fix: update build scripts for Travis-CI
feat: add article for JavaScript hoisting
docs: update přispívající pravidla
```
Zachovat tyto krátké, ne více než 50 znaků. V popisu zprávy commitu můžete vždy přidat další informace.
Netrvá to více času než nekonvenční zpráva jako 'update file' nebo 'add index.md'
Více informací o tom, proč byste měli používat konvenční commity [zde](https://www.conventionalcommits.org/en/v1.0.0-beta.2/#why-use-conventional-commits).
9. Pokud si uvědomíte, že po provedení revize je třeba upravit soubor nebo aktualizovat zprávu commitu, můžete tak učinit po úpravě souborů:
```console
git commit --amend
```
Tímto se otevře výchozí textový editor, jako je `nano` nebo `vi` , kde můžete upravit název zprávy a přidat/upravit popis.
10. Dále můžete odeslat své změny na rozštěpení:
```console
git push origin branch/name-here
```
## Návrh požadavku na natažení (PR)
Poté, co jste změnili své změny, podívejte se zde na [jak otevřít Pull Request](how-to-open-a-pull-request.md).
## Odkaz na rychlé příkazy
Nyní můžete provést změny v souborech a provést změny v místním klonu rozštěpení.
| příkaz | Popis |
| -------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| `npm ci` | Instalujte / přeinstalujte všechny závislosti a bootstrapy různé služby. |
| `npm run seed` | Analyzuje všechny soubory challenge markdown a vloží je do MongoDB. |
| `vývoj npm běhu` | Spustí Free CodeCamp API Server a aplikace klienta. |
| `npm test` | Spustit všechny JS testy v systému, včetně klienta, serveru, linky a challenge testů. |
| `npm run test:klient` | Spustit klientskou testovací sadu. |
| `npm run test:curriculum` | Spustit testovací sadu učebních plánů. |
| `npm run test:curriculum --block='Základní HTML a HTML5'` | Vyzkoušejte specifický blok. |
| `npm run test:curriculum --superblock='responsive-web-design'` | Vyzkoušejte specifický SuperBlock. |
| `npm run test-curriculum full-výstup` | Po první chybě spustit testovací sadu učebních osnov |
| `npm run test:server` | Spustit serverovou testovací sadu. |
| `npm běh e2e` | Spusťte konec Cypresu pro ukončení testů. |
| `npm vyčistit` | Odinstaluje všechny závislosti a vyčistí mezipaměti. |
## Řešení problémů
### Problémy s instalací doporučených předpokladů
Postupujte podle těchto kroků:
Doporučujeme prozkoumat váš konkrétní problém u zdrojů, jako je Google, Stack Overflow nebo Stack Exchange. Existuje velká šance, že někdo čelil stejnému problému a na váš konkrétní dotaz již existuje odpověď.
Pokud jste na jiném OS a/nebo stále běžejí problémy, podívejte se na [získání nápovědy](#getting-help).
> Pokud navštívíte [http://localhost:3000/Explorer](http://localhost:3000/explorer) , měli byste vidět dostupné API.
>
> Vyhněte se prosím vytváření GitHub problémů v nezbytných podmínkách. Jsou mimo rozsah tohoto projektu.
### Problémy s uživatelským rozhraním, písmy, chyby sestavení atd.
Pokud narazíte na problémy s UI, fonty nebo uvidíte chyby sestavení, může být čištění užitečné:
```console
npm run clean
npm ci
npm run seed
npm run develop
```
NEBO
Použít zástupce
```
npm běh čištění a vývoj
```
Výsledný výstup by měl být prázdný.
Použít `git čištění` v interativním režimu:
```
git clean -ifdX
```
<details>
<summary>
Jak vyčistit git nesledované soubory (screenshot)
</summary>
<br>
<img src="https://user-images.githubusercontent.com/1884376/94270515-ca579400-ff5d-11ea-8ff1-152cade31654.gif" alt="Jak vyčistit git nesledované soubory" />
</details>
### Problémy s API, přihlášením, podáním výzvy atd.
Pokud se nemůžete přihlásit a místo toho uvidíte banner s chybovou zprávou, že bude nahlášen na freeCodeCamp, prosím zkontrolujte, zda váš místní port `3000` není používán jiným programem.
**Na Linuxu / macOS / WSL na Windows - Z terminálu:**
```console
netstat -ab | grep "3000"
tcp4 0 0.0.0.0:3000 DESKTOP LISTEN
```
**Na Windows - Z Elevated PowerShell:**
```powershell
netstat -ab | Vybraný řetězec "3000"
TCP 0.0.0:3000 DESKTOP LISTENING
```
### Problémy při instalaci závislostí
Nepovinné:
Nastavení může chvíli trvat poprvé, v závislosti na šířce pásma. Buďte trpěliví, a pokud jste stále uvězněni, obnovujeme místo offline nastavení GitPod.
## Získávání nápovědy
Pokud jste uvízli a potřebujete pomoc, dejte nám vědět tím, že se zeptáte v kategorii ['přispěvatelé' na našem fóru](https://forum.freecodecamp.org/c/contributors) nebo [přispěvatelé](https://gitter.im/FreeCodeCamp/Contributors) na Gitteru.
V konzoli prohlížeče nebo v Bash / Terminálu / příkazovém řádku může být chyba, která pomůže identifikovat problém. Zadejte tuto chybovou zprávu v popisu problému, aby ostatní mohli problém snadněji identifikovat a pomohli vám najít řešení.

129
docs/i18n/Czech/how-to-setup-wsl.md Normal file
View File

@ -0,0 +1,129 @@
# Nastavit freeCodeCamp na Windows Subsystem pro Linux (WSL)
> [!POZNÁMKA] Dříve než budete postupovat podle těchto pokynů, ujistěte se, že váš systém splňuje požadavky
>
> **WSL 2**: Windows 10 64-bit (verze 2004, Build 19041 nebo vyšší) - k dispozici pro všechny distribuce včetně Windows 10 Domů.
>
> **Docker Desktop pro Windows**: Viz příslušné požadavky pro [Windows 10 Pro](https://docs.docker.com/docker-for-windows/install/#system-requirements) a [Windows 10 Home](https://docs.docker.com/docker-for-windows/install-windows-home/#system-requirements)
Tento návod pokrývá některé společné kroky s nastavením WSL2. jakmile se řeší některé společné problémy s WSL2, byste měli být schopni sledovat náš místní průvodce nastavením a pracovat s freeCodeCamp na systému Windows a běžet tak jako Ubuntu.
## Povolit WSL
Postupujte podle pokynů na [oficiální dokumentaci](https://docs.microsoft.com/en-us/windows/wsl/install-win10) a nainstalujte WSL1 a poté přejděte na WSL2.
## Install Ubuntu
1. Doporučujeme používat Ubuntu-18.04 nebo vyšší s WSL2.
> [!POZNÁMKA]
>
> I když můžete použít jiné nedebianské distros, všechny přicházejí s jejich vlastními gotchas a jsou mimo rámec tohoto průvodce.
2. Aktualizovat závislosti pro OS
```console
sudo apt update
sudo apt upgrade -y
# čištění
sudo apt autoremove -y
```
## Nastavit Git
Git přichází předinstalovaný s Ubuntu 18.04, ověřte, zda vaše Git verze s `git --version`.
```output
~
<unk> git --version
git verze 2.25.1
```
(Volitelné, ale doporučeno) Nyní můžete pokračovat v [nastavení ssh klíče](https://help.github.com/articles/generating-an-ssh-key) pomocí GitHub.
## Instalace editoru kódu
Důrazně doporučujeme nainstalovat [Visual Studio Code](https://code.visualstudio.com) na Windows 10. Má velkou podporu pro WSL a automaticky nainstaluje všechna potřebná rozšíření do distro.
V podstatě upravíte a uložíte svůj kód na Ubuntu-18.04 s VS kódem nainstalovaným v Windows.
## Instalace Docker Desktop
**Docker Desktop pro Windows** umožňuje instalovat a spouštět databázi a služby jako MongoDB, NGINX, atd. To je užitečné, abychom se vyhnuli běžným nástrahám při instalaci MongoDB nebo jiných služeb přímo na Windows nebo WSL2.
Postupujte podle instrukcí na [oficiální dokumentaci](https://docs.docker.com/docker-for-windows/install) a nainstalujte Docker Desktop pro vaši distribuci Windows.
Existují minimální požadavky na hardware pro nejlepší zážitky.
## Konfigurace Docker pro WSL
Jakmile je Docker Desktop nainstalován, [postupujte podle těchto instrukcí](https://docs.docker.com/docker-for-windows/wsl) a nastavte jej tak, aby byla jako backend použita instalace Ubuntu-18.04.
To znamená, že kontejnery běží na WSL místo běhu na Windows. Budete mít přístup ke službám přes `http://localhost` jak na Windows, tak na Ubuntu.
## Instalovat MongoDB z Docker Hub
Jakmile jste nakonfigurovali Docker pro práci s WSL2, postupujte podle těchto kroků pro spuštění služby MongoDB:
1. Spustit nový terminál Ubuntu-18.04
2. Pull `MongoDB 3.6` z dockerhub
```console
docker pull mongo:3
```
3. Spusťte službu MongoDB na portu `27017`a nastavte ji tak, aby běžela automaticky při restartování systému
```console
docker run -it \
-v mongodata:/data/db \
-p 27017:27017 \
--name mongodb \
--restart unless-stopped \
-d mongo:3
```
4. Nyní máte přístup ke službě jak z Windows tak z Ubuntu na `mongodb://localhost:27017`.
## Instalace Node.js a npm
Doporučujeme nainstalovat verzi LTS pro Node.js se správcem verzí uzlu - [nvm](https://github.com/nvm-sh/nvm#installing-and-updating).
Po instalaci použijte tyto příkazy k instalaci a použijte podle potřeby verzi Node.js
```console
nvm install --lts
# OR
# nvm install <version>
nvm install 14
# Usage
# nvm use <version>
nvm use 12
```
Node.js přichází s `npm`, můžete aktualizovat na nejnovější verze `npm` pomocí:
```console
npm install -g npm@latest
```
## Nastavit volný CodeCamp lokálně
Nyní, když jste nainstalovali předběžné požadavky, postupujte podle [našeho místního průvodce nastavením](https://contribute.freecodecamp.org/#/how-to-setup-freecodecamp-locally) pro klonování, instalaci a nastavení freeCodeCamp lokálně na vašem počítači.
> [!VAROVÁNÍ]
>
> Mějte prosím na paměti, že právě probíhá nastavení Cypress testů (a související potřeby GUI). Měli byste být stále schopni pracovat na většině kódu.
## Užitečné odkazy
- [WSL2 Dev Setup s Ubuntu 20.04, Node.js, MongoDB, VS Code a Docker](https://devlog.sh/wsl2-dev-setup-with-ubuntu-nodejs-mongodb-and-docker) - článek Mrugesh Mohapatra (Staff Developer na freeCodeCamp.org)
- Často kladené otázky na:
- [Podsystém Windows pro Linux](https://docs.microsoft.com/en-us/windows/wsl/faq)
- [Docker pro Windows](https://docs.docker.com/docker-for-windows/faqs)

15
docs/i18n/Czech/how-to-use-docker-on-windows-home.md Normal file
View File

@ -0,0 +1,15 @@
# Jak používat Docker na Windows Home
Při nastavení doku na Windows Home je třeba se vyhnout několika nástrahám. Nejprve musíte použít [Docker Toolbox](https://docs.docker.com/toolbox/toolbox_install_windows/) jako správce. Windows Home bohužel nepodporuje Docker pro Windows Desktop, proto musí být místo toho použit panel nástrojů. Musí být spuštěn jako administrátor, protože instalace používá symlinky, které nelze vytvořit jinak.
Po instalaci panelu nástrojů spusťte Docker Quickstart Terminal jako správce. Tímto vytvoříte `výchozí` virtuální stroj, pokud již neexistuje. Jakmile k tomu došlo, zavřete terminál a otevřete VirtualBox (opět jako Administrator). Měli byste mít možnost vidět `výchozí` počítač. Stránka je poměrně náročná na zdroje, takže zastavit virtuální stroj a zvýšit nastavení co nejvíce můžete - zejména paměť. Bylo potvrzeno, že pracuje se 4GB rázu.
Jakmile jste spokojeni, že Docker funguje, naklonujte freeCodeCamp repositář do adresáře uvnitř `C:\Users`. Tyto adresáře jsou sdíleny tak, aby dokovací adresáře měly přístup k místním adresářům, které potřebuje během instalace.
Pokud vidíte zprávy jako
```shell
bash: change_volumes_owner.sh: žádný takový soubor nebo adresář
```
když `npm spustíte docker:init` je to pravděpodobně viník.

541
docs/i18n/Czech/how-to-work-on-coding-challenges.md Normal file
View File

@ -0,0 +1,541 @@
# Jak pracovat na programování úkolů
Naším cílem je rozvíjet zábavné a jasné interaktivní učení.
Navrhování interaktivních úkolů kódování je obtížné. Bylo by mnohem snazší napsat dlouhé vysvětlení nebo vytvořit video tutoriál, a je zde místo pro lidi na středním a YouTube. Nicméně pro naše základní osnovy se držíme toho, co funguje nejlépe pro většinu lidí - plně interaktivní zážitek z videoher.
Chceme kamery, aby se dosáhlo stavu toku. Chceme, aby prostřednictvím našich osnov vytvořili hybnou sílu a s co nejmenším počtem hlemýžďů. Chceme, aby se zapojili do projektů s důvěrou a získali velké vystavení koncepcím programování.
Vytváření těchto výzev vyžaduje obrovskou tvořivost a pozornost k detailům. K dispozici je spousta pomoci. Budete mít podporu od celého týmu přispěvatelů, kterým se můžete odvracet nápady a demo své výzvy. Zůstaňte aktivní v [přispěvatelském sále](https://gitter.im/freecodecamp/contributors) a položte mnoho otázek.
S Vaší pomocí můžeme navrhnout interaktivní programovací osnovy, které pomohou milionům lidí naučit se programovat v následujících letech.
Obsah každé výzvy je uložen v jeho vlastním markdown souboru. Tento soubor markdown je později převeden na HTML pomocí našich nástrojů pro vytváření interaktivních webových stránek.
Veškerý obsah měn freeCodeCamp.org naleznete v adresáři [`/curriculum/challenge`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges).
## Nastavit nástroj pro učební plány
Než budete pracovat na učebních plánech, musíte nastavit nějaké nástroje, které vám pomohou vyzkoušet vaše změny. Můžete použít libovolnou možnost z níže:
- Můžete [nastavit volný CodeCamp lokálně](how-to-setup-freecodecamp-locally.md). To je **vysoce doporučeno** pro pravidelné/opakované příspěvky. Toto nastavení vám umožní pracovat a otestovat vaše změny.
- Použijte Gitpod, bezplatné online prostředí pro vývojáře. Kliknutím na tlačítko níže spustíte prostředí pro vývojáře freeCodeCamp ve vašem prohlížeči. Trvá to jen několik minut.
[![Otevřít v Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
- Upravte soubory na rozhraní GitHubu kliknutím na ikonu tužky pro odpovídající soubor. I když je to nejrychlejší způsob, není doporučeno ****, protože nejste schopni otestovat změny na GitHubu. Pokud naši správci dospějí k závěru, že změny, které jste provedli, musí být vyzkoušeny lokálně, musíte místo toho znovu použít výše uvedené metody.
## Šablona výzvy
Níže je šablona toho, jak vypadají soubory challenge markdown v současné době. Chcete-li zobrazit zjednodušenou šablonu, uvidíme [níže](#upcoming-challenge-template).
````md
---
id: jedinečný identifikátor (alfanumerický, MongoDB_id)
název: Challenge Title
challengeType: 0
videoUrl: 'url of video explanation'
---
## Popis
<section id='description'>
Popis challenge a co je nutné předat
</section>
## Instrukce
<section id='instructions'>
Instrukce o tom, co přesně je třeba udělat.
</section>
## Testy
<section id='tests'>
```yml
testy:
- text: Měl by vrátit "foo"
testString: 'Stringified funkce možná pomocí Chai asserts'
````
</section>
## Seed výzvy
<section id='challengeSeed'>
<div id='{ext}-seed'>
```{ext}
Kód zobrazený ve výchozím nastavení v editoru.
Toto je požadovaná sekce pro výzvu.
```
</div>
### Před zkouškou
<div id='{ext}-setup'>
```{ext}
Volitelný kód pro testovací nastavení.
```
</div>
### Po zkoušce
<div id='{ext}-teardown'>
```{ext}
Volitelný kód testu dolů.
```
</div>
</section>
## Roztok
<section id='solution'>
```{ext}
// řešení vyžadováno
```
</section>
````
> [!POZNÁMKA]
>
> 1. Ve výše uvedených oddílech příklady `{ext}` jsou:
>
> - `html` - HTML/CSS
> - `js` - JavaScript
> - `jsx` - JSX
>
> 2. Pro část `Tests` výše, `text` a `testString` by měly být platné YAML řetězce. `testString` může být stringified funkce nebo výraz, který může používat Chai tvrzení.
## Číslování výzev
Každá výzva potřebuje `id`. Pokud jej nespecifikujete, MongoDB vytvoří náhodně nový při ukládání dat; nechceme to však udělat, protože chceme, aby byly děti spojené s výzvou napříč různými prostředími (stagnace, výroba, spousta různých vývojářů atd.).
Možnost generovat nový ve skořápce (za předpokladu, že MongoDB běží samostatně):
1. Spustit příkaz `mongo`.
2. Spustit příkaz `ObjectId()`.
Například:
```bash
$ mongo
MongoDB shell verze v3.6.1
připojující se k: mongodb://127.0.0.1:27017
MongoDB verze serveru: 3.4.10
...
$ ObjectId()
ObjectId("5a474d78df58bafeb3535d34")
````
Výsledkem je nový id, například `5a474d78df58bafeb35d34`.
Jakmile budete mít své id , vložte jej do souboru markdown jako pole `id` nahoře, např.
```yml
---
id: 5a474d78df58bafeb35d34
název: Challenge Title
```
## Pojmenovávání úkolů
Pojmenování věcí je těžké. Usnadnili jsme to zavedením určitých omezení.
Všechny názvy výzev by měly být explicitní a měly by odpovídat tomuto vzoru:
\[verb\]\[klauzule objektu\]
Zde je několik příkladů názvů výzev:
- Použít upozornění ve směru hodinových ručiček pro zadání Padding prvku
- Kondenzovaná pole s .redukcí
- Použijte poznámku závorek k nalezení první postavy v řetězci
## Popisy/pokyny k výzvě
Věty by měly být jasné a stručné s minimálním žargonem. V případě použití by měl být žargon okamžitě definován v jednoduché angličtině.
Zachovejte odstavce krátké (kolem 1-4 vět). Pravděpodobně si lidé přečtou několik krátkých odstavců než zeď textu.
Text výzvy by měl použít druhou osobu („vy“), aby jí pomohl dát konverzační tón. Tímto způsobem text a instrukce vypadají, že mluví přímo s kamerem, který pracuje výzvou. Zkuste se vyhnout používání první osoby ("I", "my", "let's" a "ná").
Nepoužívat odchozí odkazy. To přerušilo tok. Kameraři by nikdy neměli v těchto výzvách nic vygoognovat. Pokud existují zdroje, které by podle vás mohly mít užitek, přidejte je do článku příručky pro výzvu.
V případě potřeby můžete přidat diagramy.
Nepoužívat emoji ani emotikony v výzvách. freeCodeCamp má globální komunitu a kulturní význam emoji nebo emotikonu se může po celém světě lišit. Na různých systémech se mohou zobrazovat emoji odlišně.
Řádné nouny by měly používat správnou kapitalizaci, pokud je to možné. Níže je seznam slov, která by se měla objevit v výzvách.
- JavaScript (velká písmena v "J" a "S" a bez zkratek)
- Node.js
- Vývoj front-end (přídavný formulář s pomlčkou) je při práci na předním konci (jmenný formulář bez pomlčky). Totéž platí pro "back end", "full stack" a mnoho dalších složených termínů.
### Dvouminutové pravidlo
Každá výzva by měla být vyřešena do 120 sekund rodilým anglickým mluvčím, který dokončil výzvy, které jí přináší. To zahrnuje dobu potřebnou k přečtení směrů/instrukcí rozumí kódu seedu, napište svůj vlastní kód a získejte všechny testy.
Pokud to trvá déle než dvě minuty, máte dvě možnosti:
- Zjednodušit výzvu, nebo
- Rozdělte výzvu na dvě výzvy.
Dvouminutové pravidlo tlačí tvůj návrhář, aby tvé pokyny byly stručné, aby tvůj zdrojový kód byl jasný a tvé testy byly jednoduché.
Sledujeme, jak dlouho trvá kamera, aby vyřešili změny a použili tyto informace k identifikaci výzev, které je třeba zjednodušit nebo rozdělit.
### Modularita
Každá výzva by měla naučit přesně jeden koncept a tento koncept by měl být zřejmý z názvu výzvy.
Dříve zakryté koncepty můžeme posílit opakováním a odlišnostmi - například zavedení prvků h1 do jedné výzvy, poté h3 bude mít později několik výzev.
Naším cílem je mít tisíce dvouminutových výzev. Ty mohou společně proudit a zopakovat dříve zakryté koncepce.
### Formátování textu výzvy
Zde jsou konkrétní směry formátování pro text výzvy a příklady:
- Klíčová slova jazyka jdou do značek `<code>`. Například, názvy HTML značek nebo názvy CSS vlastností
- První instance klíčového slova, když je definováno, nebo obecná klíčová slova (např. "objekt" nebo "neměnitelná") jdou na `<dfn>` tagy
- Odkazy na části kódu (tj. funkce, metoda nebo názvy proměnných) by měly být baleny do značek `<code>`. Viz příklad níže:
- Použijte <code>parseInt</code> k převodu proměnné <code>realNumber</code> na celé číslo.
- Bloky víceřádkových kódů **musí předcházet prázdný řádek**. Další řádek musí začínat třemi zadními vrátky, po nichž bezprostředně následuje jeden z [podporovaných jazyků](https://prismjs.com/#supported-languages). Chcete-li dokončit blok kódu, musíte spustit novou řádek, který má pouze tři zadky a **další prázdný řádek**. **Poznámka:** Pokud chcete použít příklad kódu v YAML, použít `yaml` místo `yml` pro jazyk vpravo od backtiků.
Viz příklad níže:
````md
Příklad kódu:
```{language}
[VAŠE KÓD ŠERE]
````
````
- Další informace ve formě poznámky by měly být formátovány `<strong>Poznámka:</strong> Zbytek textu poznámky...
- Pokud je zapotřebí více poznámek, pak uveďte všechny poznámky v samostatných větách ve formátu `<strong>Poznámky:</strong> Text první poznámky. Text druhé poznámky.`.
- Použijte v případě potřeby dvojí uvozovky
## Testy psaní
Výzvy by měly mít minimální počet zkoušek nutný k ověření, že kampery rozumí koncepci.
Naším cílem je komunikovat o jediném bodu, který se výzva snaží vyučovat, a otestovat, zda tento bod pochopili.
Testy výzev mohou využít výpočetní knihovny Node.js a Chai.js. V případě potřeby je k dispozici uživatelsky generovaný kód v proměnné `code`.
## Formátování kódu seedu
Zde jsou specifické pokyny pro formátování kódu challenge seedu:
- Používejte dvě mezery k odsazení
- příkazy JavaScriptu končí středníkem
- Použijte dvojité uvozovky, kde je to na místě,
- Komentáře by měly mít mezeru mezi znaky komentáře a komentářem samotným
`// Opravit tuto řádek`
## Hints and Solutions
Každá výzva má tlačítko `Získat nápovědu`, aby uživatel měl přístup k jakýmkoli nápovědám/řešením, která byla vytvořena pro výzvu. Témata kuriculum hints/solutions jsou umístěna na [našem fórum](https://forum.freecodecamp.org/c/guide) v kategorii `Guide`.
Pokud najdeš problém s tématem nápovědy/řešení existující výzvy, můžeš předložit návrhy v kategorii [přispěvatelů](https://forum.freecodecamp.org/c/contributors) na fóru. Moderátoři a uživatelé s úrovní důvěry 3 prověří připomínky a rozhodnou, zda zahrnou změny do příslušného tématu h/řešení.
### Přidání nových nápověd/řešení výzev
Proveďte následující kroky při přidání nových nápověd/řešení souvisejících otázek.
1. Začněte sledováním stejných kroků pro vytvoření nového tématu, ale podívejte se na další pro vytvoření titulku.
2. Titulek tématu by měl začínat `freeCodeCamp Challenge Guide: ` spojen se skutečným názvem výzvy učebních plánů. Například, pokud je výzva pojmenována ""Chunky Monkey", titulek tématu bude ""freeCodeCamp Challenge Guide: Chunky Monkey".
3. `camperbot` by měl být vlastníkem těchto témat/příspěvků, takže budete muset požádat správce, aby změnil vlastnictví hlavního příspěvku na `camperbot`.
4. Jakmile je nové téma vytvořeno, je vytvořeno ID tématu fóra. Je umístěn na konci URL tématu fóra. Toto ID musí být přidáno do fronty souboru výzev učebních plánů pomocí normálního procesu požadavku na natažení pro tlačítko `Získat nápovědu` pro propojení s tématem.
### Pokyny pro obsah témat tipů a řešení
Při navrhování řešení pro téma průvodce učebních osnov, musí být přidán celý kód. To zahrnuje všechny původní kódy osiva a veškeré změny potřebné k provedení všech provokačních testů. Následující šablona by měla být použita při vytváření nových témat nápověd/řešení:
````md
# Challenge Name Goes Here
---
## Vysvětlení problémů
Toto shrnuje, co je třeba udělat, aniž by jen opakovalo popis challenge a/nebo pokyny. Toto je volitelná sekce
#### Relevant Links
- [Link Text](link_url_goes_here e)
- [Link Text](link_url_goes_here)
---
## Hints
### Hint 1
Hint zde
### Hint 2
Hint zde
---
## Solutions
<details><summary>Řešení 1 (Click to Show/Hide)</summary>
```js
funkce myFunc() {
konzola. og('Hello World!');
}
````
#### Vysvětlení kódu
- Vysvětlení kódu je zde
- Vysvětlení kódu je zde
#### Relevantní odkazy
- [Text odkazu](link_url_goes_here)
- [Text odkazu](link_url_goes_here)
</details>
````
## Testování výzev
Předtím, než [vytvoříš požadavek na natažení](how-to-open-a-pull-request. d) pro vaše změny, musíte potvrdit, že změny, které jste provedli, nezpůsobují neúmyslně problémy s výzvou.
1. Pro otestování všech challenge spusťte příkaz níže z kořenového adresáře
````
npm run test:curriculum
```
2. Můžeš také otestovat blok nebo superblok výzev pomocí těchto příkazů
```
npm run test:curriculum --block='Základní HTML a HTML5'
```
```
npm run test:curriculum --superblock=responsive-web-design
```
Můžete také vyzkoušet jednu výzvu individuálně provedením následujících kroků:
1. Přepněte do adresáře `curriculum`:
```
cd osnovy
```
2. Spusťte následující pro každý soubor s výzvou, pro který jste změnili:
```
npm run test -- -g 'The full Czech title of the challenge'
```
Jakmile jste ověřili, že každá výzva prošla testy, [prosím vytvořte požadavek na natažení](https://github.com/freeCodeCamp/freeCodeCamp/blob/master/docs/how-to-open-a-pull-request.md).
> [!TIP]
> Můžete nastavit proměnnou prostředí `LOCALE` v jazyce `.env` na jazyk výzev, které musíte testovat.
>
> Aktuálně přijaté hodnoty jsou `english` a `chinese`, přičemž `english` je ve výchozím nastavení nastaveno.
## Nadcházející šablona výzvy
Šablona výzvy v procesu aktualizace na čistší, méně vnořenou strukturu. Toto nebylo úplně dokončeno, ale následující by měly být blízko konečné struktury:
``mdx
---
id: jedinečný identifikátor (alfanumerický, Název MongoDB_id)
: 'Název výzvy'
challengeType: Integer, definovaný v `client/utils/challengeTypes. s`
videoUrl: 'url of video explanation'
forumTopicId: 12345
---
import skriptu z './script. dx';
## --step-description--
Popis textu v markdown
```html
<div>
příklad kódu
</div>
```
## --step-hints--
![test-id-1]
Bude existovat libovolný počet trojic idů, instrukcí (v markdown) a kódových bloků.
```js
Kód pro zkoušku č. 1
```
![test-id-2]
Další pokyny v markdown syntaxi
```js
Další kód
```
## --step-seed--
### --before-user-code--
```lang
Kód vyhodnocen před uživatelem.
```
### --after-user-code--
```lang
Kód vyhodnocen po provedení testu uživatele a těsně před testy.
```
### --seed-content--
![index-html]
```html
Některé html
```
```css
Nějaký css
```
```js
Několik js
```
![index-js]
<Script ></p>
<h1 spaces-before="0">
--solution-marker--
</h1>
<p spaces-before="0">
Přesně stejná jako sekce osiva
</p>
<h2 spaces-before="0">
--next-solution-marker
</h2>
<p spaces-before="0">
Znovu stejné
</p>
<h1 spaces-before="0">
--question-marker--
</h1>
<h2 spaces-before="0">
--text-marker--
</h2>
<p spaces-before="0">
Otázka by šla sem (pouze pro videohovory)
</p>
<h2 spaces-before="0">
--answers-marker--
</h2>
<p spaces-before="0">
Odpověď 1
</p>
<hr />
<p spaces-before="0">
Odpověď 2
</p>
<hr />
<p spaces-before="0">
Odpověď 2
</p>
<h2 spaces-before="0">
--solution-marker--
</h2>
<p spaces-before="0">
\<number of correct answer\>
</p>
<p spaces-before="0">
````
</p>
<h3 spaces-before="0">
Užitečné odkazy
</h3>
<p spaces-before="0">
Vytváření a editace výzev:
</p>
<ol start="1">
<li>
<p spaces-before="0">
<a href="https://github.com/freeCodeCamp/freeCodeCamp/blob/master/client/utils/challengeTypes.js#L1-L13">Typy výzev</a> - co znamenají numerické hodnoty typu výzvy (enum).
</p>
</li>
<li>
<p spaces-before="0">
<a href="https://www.youtube.com/watch?v=iOdD84OSfAE#t=2h49m55s">Přispění k FreeCodeCamp - psaní testů výzev ES6</a> - video po <a href="https://twitter.com/ArrowoodTech">Ethan Arrowood</a> , protože přispívá ke staré verzi učebních plánů.
</p>
</li>
</ol>

40
docs/i18n/Czech/how-to-work-on-the-docs-theme.md Normal file
View File

@ -0,0 +1,40 @@
# Jak pracovat na tématu dokumentace
> [!POZNÁMKA] Rychlé upozornění, že nemusíte nic nastavovat pro práci na obsahu stránky dokumentace.
>
> Chcete-li pracovat na pokynech pro přispívání, můžete upravit nebo přidat soubory do adresáře `dokumentace` [k dispozici zde](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/docs). Jakmile budou vaše změny sloučeny, budou automaticky zpřístupněny na stránce dokumentace.
## Struktura internetových stránek dokumentace
Stránka je generována pomocí [`docsify`](https://docsify.js.org)a servírována pomocí stránek GitHub.
Obvykle byste nemuseli měnit žádnou konfiguraci nebo stavět web lokálně. V případě, že máte zájem, zde je to, jak funguje:
- Zdroj domovské stránky je k dispozici v [`docs/index.html`](index.html).
- Tento soubor slouží jako SPA pomocí `docsify` a GitHub stránek.
- Skript `docsify` na vyžádání generuje obsah souborů `markdown` v `dokumentech`.
- Domovská stránka je generována z [`_coverpage.md`](_coverpage.md).
- postranní navigace je generována z [`_sidebar.md`](_sidebar.md).
## Místní obsluha stránky dokumentace
Klonovat volný CodeCamp:
```sh
git klonovat https://github.com/freeCodeCamp/freeCodeCamp.git
docsify serve docs
```
Nainstalovat `docsify`:
```sh
npm install -g docsify
```
a obsluhovat adresář `/docs`
```sh
docsify servisní dokumenty
```
Případně pokud jste nainstalovali freeCodeCamp lokálně (viz příručka lokálního nastavení), spojujeme CLI s vývojovými nástroji, takže můžete spustit `npm run docs:serve` od kořene repo.

10
docs/i18n/Czech/how-to-work-on-the-news-theme.md Normal file
View File

@ -0,0 +1,10 @@
<!--
The source for this document is available at:
https://github.com/freeCodeCamp/news-theme/blob/master/CONTRIBUTING.md
Please edit that file instead.
-->
[remote-markdown-url](https://raw.githubusercontent.com/freeCodeCamp/news-theme/master/CONTRIBUTING.md)

45
docs/i18n/Czech/index.md Normal file
View File

@ -0,0 +1,45 @@
Komunita [freeCodeCamp.org](https://freecodecamp.org) je možná díky tisícům milých dobrovolníků, jako jste Vy. Vítáme všechny příspěvky do komunity a rádi vás přivítáme na palubě.
> [!POZNÁMKA] Než budete pokračovat, přečtěte si prosím rychle 2 minuty našeho [Kodexu chování](https://www.freecodecamp.org/code-of-conduct). Striktně ji prosazujeme napříč naší komunitou. Chceme, aby přispěl k bezplatnému CodeCamp.org aby byl bezpečný a inkluzivní zážitek pro všechny.
Šťastný příspěvek.
Jste vítáni:
- Vytvořit, aktualizovat a opravit chyby v našich [programovacích výzvách](#coding-challenges).
- Pomozte nám opravit chyby ve [vzdělávací platformě freeCamp.org](#learning-platform).
- _(již brzy)_ Pomozte nám přeložit zdarma CodeCamp.org do světových jazyků.
Máte otázky? Přejděte na [tyto FAQ](/FAQ.md) , kde odpovídáme na některé běžné dotazy o příspěvku.
## Výzvy programování
Všechny naše programovací výzvy jsou zredukovány komunitou a přinášejí odborné znalosti od dobrovolníků, jako je Vy.
Můžete jim pomoci rozšířit a zlepšit jejich znění. Můžete také aktualizovat uživatelské příběhy, abyste lépe vysvětlili koncept nebo odstranili ty nadbytečné a vylepšili challenge testy, aby byli přesněji testováni lidským kódem.
**Pokud máte zájem o vylepšení těchto úkolů v kódování, je zde [jak pracovat na programování úkolů](how-to-work-on-coding-challenges.md).**
## Platforma pro učení
Naše vzdělávací platforma běží na moderním JavaScriptovém zásobníku. Má různé komponenty, nástroje a knihovny, včetně Node.js, MongoDB, LoopBack, OAuth 2.0, React, Gatsby, Webpack, a další.
Celkově
- Máme API server založený na Node.js.
- Soubor klientských aplikací založených na reakci.
- Skript, který používáme k hodnocení našich front-end projektů.
Přispívání k tomu vyžaduje pochopení API, syntaxe ES6 a mnoho zvědavosti.
V zásadě očekáváme základní znalost některých výše uvedených technologií, nástrojů a knihoven. S tím se od vás nevyžaduje, abyste na ně přispíval odborníkem.
**Pokud nám chcete pomoci zlepšit naši základnu kódu, můžete použít buď Gitpod, bezplatné prostředí online vývojáře**
[![Otevřít v Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
(Spustí prostředí vývojáře připraveného ke kódu pro freeCodeCamp ve vašem prohlížeči.)
NEBO
**můžete [nastavit volný CodeCamp lokálně](how-to-setup-freecodecamp-locally.md) na vašem počítači.**

101
docs/i18n/Danish/FAQ.md Normal file
View File

@ -0,0 +1,101 @@
### Jeg er ny til GitHub og Open Source, hvor skal jeg starte?
Læs vores ["Sådan bidrager du til Open Source Guide"](https://github.com/freeCodeCamp/how-to-contribute-to-open-source). Det er en kompressiv ressource af første timer venlige projekter og retningslinjer.
### Kan jeg oversætte freeCodeCamp's pensume?
Vi vil kicking-off lokaliseringsindsatsen på freeCodeCamp starter med **kinesisk** først.
Vi agter at gøre pensum tilgængelig på flere sprog, men kan ikke forpligte sig til nogen frister endnu. Flere operationelle grænser som personale, aktive bidragsydere og server omkostninger spiller en rolle i at drive internationaliseringen (i18n) indsats.
Vi agter at starte i18n indsats på disse sprog: arabisk, portugisisk Russisk og spansk (i ingen bestemt rækkefølge) efter vi har udgivet pensum på kinesisk.
**Hvorfor fokuserer du først på kinesisk læseplan?**
Kina er de største demografiske regioner i vores ikke-indfødte engelsktalende publikum. I øjeblikket har vi hundredtusindvis af brugere, der bruger en gammel version af platformen. Fokus på den kinesiske pensum vil give os et skøn over logistik involveret i i18n.
Vi vil fokusere på Latinamerika som den demografiske region for portugisisk og spansk.
Vi har ikke nogen planer om i18n til andre sprog end ovenstående inden for en overskuelig fremtid.
Vi opfordrer Dem ikke til at arbejde på i18n på ovenstående sprog. Vi kan acceptere pull requests, uden nogen forventning om nogen tidslinjer på implementeringer.
### Hvordan kan jeg rapportere en ny fejl?
Hvis du tror, du har fundet en fejl, så læs først artiklen ["Hjælp jeg har fundet en fejl"](https://forum.freecodecamp.org/t/how-to-report-a-bug/19543) og følg dens instruktioner.
Hvis du er sikker på, at det er en ny fejl, skal du gå videre og oprette et nyt GitHub problem. Sørg for at inkludere så mange oplysninger som muligt, så vi kan reproducere fejlen. Vi har en foruddefineret problemskabelon til at hjælpe dig gennem dette.
Bemærk, at eventuelle problemer, der søger kodning hjælp på en udfordring, vil blive lukket. Spørgsmålet tracker er strengt til kodebase relaterede spørgsmål og diskussioner. Når du er i tvivl, bør du [søge hjælp på forummet](https://forum.freecodecamp.org) , før du laver en rapport.
### Hvordan kan jeg rapportere et sikkerhedsproblem?
Opret ikke GitHub problemer for sikkerhedsproblemer. I stedet skal du sende en e-mail til `security@freecodecamp.org` , og vi vil undersøge den med det samme.
### Jeg er studerende, kan jeg eller vores team arbejde på en funktion til akademiske kreditter?
Ja, sikker.
Mens vi er åbne over for alle bidrag, Bemærk venligst, at vi ikke er i stand til at forpligte os til tidsfrister, der kan være et krav på dit kollegium eller universitet. Vi modtager mange pull-anmodninger og kodebidrag fra frivillige udviklere, og vi respekterer deres tid og indsats. Vi vil ikke være i stand til at give nogen PR nogen særlig opmærksomhed til at være retfærdig over for alle.
Vi beder dig om at planlægge forude og arbejde på en funktion med dette i tankerne.
### Hvad betyder disse forskellige etiketter, der er mærket på emner?
Kodevedligeholderne [triage](https://en.wikipedia.org/wiki/Software_bug#Bug_management) issues og pull requests baseret på deres prioritet, sværhedsgrad og andre faktorer. Du kan [finde en komplet ordliste over deres betydninger her](https://github.com/freecodecamp/freecodecamp/labels).
### Hvor starter jeg, hvis jeg ønsker at arbejde på et spørgsmål?
Du bør gå gennem [**`hjælp ønskede`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) eller [**`første timere kun`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22first+timers+only%22) problemer for en hurtig oversigt over, hvad der er tilgængeligt for dig at arbejde på.
> [!TIP] **`hjælp ønskede`** problemer er op til grabs, og du behøver ikke at søge tilladelse, før du arbejder på dem. Problemer med den **`første timer kun`** etiket er dog reserveret til personer, der ikke har bidraget til freeCodeCamp kodebase før. Hvis disse spørgsmål mangler klarhed om, hvad der skal gøres, er du velkommen til at stille spørgsmål i kommentarerne.
### Jeg fandt en stavefejl, skulle jeg rapportere et problem, før jeg kan lave en pull-anmodning?
For taxier og andre ordlyd ændringer, kan du direkte åbne pull anmodninger uden at oprette et problem først. Spørgsmål er mere for at diskutere større problemer forbundet med kode eller strukturelle aspekter af pensum.
Dog bedes du nævne detaljer, kontekst osv. i pull request's beskrivelse område for at hjælpe os med at forstå og gennemgå dit bidrag selv for mindre ændringer.
### Hvordan får jeg et problem tildelt mig?
Vi tildeler typisk ikke problemer til andre end mangeårige bidragsydere for at undgå tvetydige no-shows. I stedet følger vi nedenstående politik for at være retfærdig over for alle:
1. Den første pull-anmodning for ethvert problem er foretrukket at blive flettet.
2. I tilfælde af flere pull anmodninger om samme emne, vi prioriterer kvaliteten af koden i pull requests.
- Har du inkluderet test?
- Fangede du alle usecases?
- Har du sikret, at alle tests passerer, og du har bekræftet alt fungerer lokalt?
3. Endelig går vi ind for anmodninger, der følger vores anbefalede retningslinjer.
- Har du fulgt tjeklisten for pull request?
- Har du navngivet din pull request titel meningsfuldt?
Du behøver ikke tilladelse til problemer, der er markeret `hjælp ønskede` eller `første timere` som forklaret tidligere.
Følg retningslinjerne omhyggeligt og åbn en pull-anmodning.
### Jeg er fast besluttet på noget, der ikke er medtaget i denne dokumentation.
**Du er velkommen til at bede om hjælp i:**
- The `Contributors` category of [our community forum](https://forum.freecodecamp.org/c/contributors).
- The public `Contributors` [chat room on Gitter](https://gitter.im/FreeCodeCamp/Contributors).
- The `#Contributors` channel on [our Discord community server](https://discord.gg/pFspAhS).
Vi er glade for at hjælpe dig med at bidrage til alle de emner, du gerne vil arbejde på. Du er velkommen til at stille os spørgsmål om de relaterede emner tråde, og vi vil med glæde præcisere. Sørg for at søge efter din forespørgsel, før du sender en ny.
Vær høflig og tålmodig. Vores fællesskab af frivillige og moderatorer er altid rundt for at guide dig gennem dine forespørgsler.
**Yderligere Assistans:**
Hvis du har spørgsmål om stakken, arkitektur af kodebasen, velkommen til at nå ud til vores personale dev team:
| Personale | Send besked på forum |
|:--------------------- |:---------------------------------------------------------------------------- |
| Mrugesh Mohapatra | [@raisedadead](https://forum.freecodecamp.org/u/raisedadead) |
| Ahmad Abdolsaheb | [@abdolsa](https://forum.freecodecamp.org/u/abdolsa) |
| Kristofer Koishigawa | [@scissorsneedfoodtoo](https://forum.freecodecamp.org/u/scissorsneedfoodtoo) |
| Tom Mondloc | [@moT01](https://forum.freecodecamp.org/u/moT01) |
| Oliver Eyton-Williams | [@ojeytonwilliams](https://forum.freecodecamp.org/u/ojeytonwilliams) |
| Randell Dawson | [@RandellDawson](https://forum.freecodecamp.org/u/randelldawson) |
**Du kan e-maile vores udviklerpersonale på: `dev[at]freecodecamp.org`**

36
docs/i18n/Danish/_sidebar.md Normal file
View File

@ -0,0 +1,36 @@
- **Kom I Gang**
- [Indledning](/index.md "Bidrag til freeCodeCamp.org Fællesskabet")
- [Ofte Stillede Spørgsmål](/FAQ.md)
- **Kode Bidrag**
- - [Opsæt freeCodeCamp lokalt](/how-to-setup-freecodecamp-locally.md)
- [Åbn en pull-anmodning](/how-to-open-a-pull-request.md)
- [Arbejde med kodningsudfordringer](/how-to-work-on-coding-challenges.md)
- [Arbejde med videoudfordringer](/how-to-help-with-video-challenges.md)
- [Arbejd på nyheder tema](/how-to-work-on-the-news-theme.md)
- [Arbejde på dokument-temaet](/how-to-work-on-the-docs-theme.md)
- **Valgfrie Guider**
- [Fang udgående e-mails lokalt](/how-to-catch-outgoing-emails-locally.md)
- [Konfigurer freeCodeCamp på WSL](/how-to-setup-wsl.md)
---
- **中文社区贡献指南**
- [成为专栏作者](/i18n/chinese/news-author-application.md)
- [文章翻译计划](/i18n/chinese/news-translations.md)
- [视频翻译计划](/i18n/chinese/video-translations.md)
---
- **Flyvemanualer** (for medarbejdere & møder)
- [Moderator Håndbog](/flight-manuals/moderator-handbook.md)
- [Svar Skabeloner](/flight-manuals/using-reply-templates.md)
- [Oversigt Over DevOps](/devops.md)
- [Arbejder på servere](/flight-manuals/working-on-virtual-machines.md)
---
- **Vores Fællesskab**
- [**GitHub**](https://github.com/freecodecamp/freecodecamp)
- [**Discourse Forum**](https://freecodecamp.org/forum/c/contributors)
- [**Gitter Chat**](https://gitter.im/FreeCodeCamp/Contributors)
- [**Discord Server**](https://discord.gg/pFspAhS)

227
docs/i18n/Danish/devops.md Normal file
View File

@ -0,0 +1,227 @@
# Udvikleroperationer på freeCodeCamp.org
Denne guide vil hjælpe dig med at forstå vores infrastruktur stak og hvordan vi vedligeholder vores platforme. Mens denne guide ikke har udtømmende detaljer for alle operationer, kan den bruges som reference for din forståelse af systemerne.
Lad os vide, hvis du har feedback eller forespørgsler, og vi vil med glæde præcisere.
## Hvordan kan vi opbygge, teste og implementere kodebasen?
Dette repository bygges løbende, testes og implementeres til **separate sæt af infrastruktur (servere, databaser, CDN'er osv.)**.
Dette indebærer tre trin, der skal følges i rækkefølge:
1. Nye ændringer (både rettelser og funktioner) fusioneres til vores primære udviklingsgren (`master`) via pull requests.
2. Disse ændringer gennemføres gennem en række automatiserede tests.
3. Når testene passerer, frigiver vi ændringerne (eller opdaterer dem, hvis det er nødvendigt) til implementering på vores infrastruktur.
#### Opbygning af kodebase - Mapping Git Branches til implementeringer.
Typisk [`master`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master) (standard udviklingsgrenen) er fusioneret til [`produktions-iscenesættelse`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) filial en gang om dagen og frigives til en isoleret infrastruktur.
Dette er en mellemudgivelse for vores udviklere og frivillige bidragsydere. Det er også kendt som vores "iscenesættelse" eller "beta" udgivelse.
Det er identisk med vores live produktionsmiljø på `freeCodeCamp.org`, bortset fra det ved hjælp af et separat sæt databaser, servere, web-fuldmagter osv. Denne isolation lader os teste løbende udvikling og funktioner i en "produktion" som scenario, uden at påvirke almindelige brugere af freeCodeCamp.org's hovedplatforme.
Når udviklerteamet [`@freeCodeCamp/dev-team`](https://github.com/orgs/freeCodeCamp/teams/dev-team/members) er tilfreds med ændringerne på iscenesættelsesplatformen, disse ændringer flyttes hvert par dage til [`produktions-nuværende`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-current) filial.
Dette er den endelige udgivelse, der flytter ændringer til vores produktionsplatforme på freeCodeCamp.org.
#### Testændringer - Integration og Brugeraccepttest.
Vi anvender forskellige niveauer af integrations- og accepttest for at kontrollere kvaliteten af kodeksen. Alle vores test er udført gennem software som [Travis CI](https://travis-ci.org/freeCodeCamp/freeCodeCamp) og [Azure rørledninger](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp).
Vi har enhedstest til at teste vores udfordringsløsninger, Server API'er og Client User interfaces. Disse hjælper os med at teste integrationen mellem forskellige komponenter.
> [!BEMÆRK] Vi er også i færd med at skrive slutbrugertest, som vil hjælpe med at kopiere virkelige verden scenarier som opdatering af en e-mail eller foretage et opkald til API eller tredjeparts tjenester.
Sammen hjælper disse tests med at forhindre problemer i at gentage sig selv og sikre, at vi ikke introducerer en fejl, mens vi arbejder på en anden fejl eller en funktion.
#### Deploying Changes - Pushing ændringer til servere.
Vi har konfigureret løbende levering software til at skubbe ændringer til vores udviklings- og produktionsservere.
Når ændringerne er skubbet til de beskyttede udgivelsesgrene, udløses en byggerørledning automatisk for filialen. Bygningsrørledningerne er ansvarlige for at bygge artefakter og holde dem på kølelager til senere brug.
Byggeledningen fortsætter med at udløse en tilsvarende udløsningsrørledning, hvis den fuldfører en vellykket kørsel. Udgivelsesrørledningerne er ansvarlige for at indsamle de bygge artefakter, flytte dem til serverne og gå levende.
Status for byggeri og udgivelser er [tilgængelig her](#build-test-and-deployment-status).
## Udløsning af en bygning, test og implementering.
I øjeblikket kan kun medlemmer på udviklerteamet skubbe til produktionsgrene. Ændringerne af `produktion-*` grene kan kun lande via en hurtig sammenlægning til [`upstream`](https://github.com/freeCodeCamp/freeCodeCamp).
> [!BEMÆRK] I de kommende dage vil vi forbedre dette flow til at blive gjort via pull-requests, for bedre adgang forvaltning og gennemsigtighed.
### Skubber ændringer til Staging-programmer.
1. Konfigurer dine fjernbetjeninger korrekt.
```sh
git remote -v
```
**Resultater:**
```
oprindelse git@github.com:raisedadead/freeCodeCamp.git (fetch)
oprindelse git@github.com:raisedadead/freeCodeCamp.git (push)
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (fetch)
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (push)
```
2. Sørg for, at din `master` gren er uberørt og synkroniseret med upstream.
```sh
git checkout master
git henter --all --prune
git reset --hard upstream/master
```
3. Kontrollér, at Travis CI kører videre på `master-` -grenen for upstream.
De [kontinuerlige integrationstest](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) skal være grønne og PASSING for `master` -grenen.
<details> <summary> Kontrollerer status på Travis CI (skærmbillede) </summary>
<br>
![Tjek build status på Travis CI](https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/master/docs/images/devops/travis-build.png)
</details>
Hvis dette ikke er tilfældet, bør du stoppe og undersøge fejlene.
4. Bekræft at du er i stand til at bygge depotet lokalt.
```
npm run clean-and-develop
```
5. Flyt ændringer fra `master` til `produktions-iscenesættelse` via en hurtig sammenfletning
```
git checkout produktion-iscenesættelse
git merge master
git push upstream
```
> [!BEMÆRK] Du vil ikke være i stand til at tvinge skubb, og hvis du har omskrevet historikken på alligevel vil disse kommandoer fejle ud.
>
> Hvis de gør, kan du have gjort noget forkert, og du bør lige starte forfra.
Ovenstående trin vil automatisk udløse en kørsel på byggerørledningen til `produktions-iscenesættelse` gren. Når byggeriet er færdig, gemmes artefakterne som `.zip` filer i et koldt lager, der skal hentes og bruges senere.
Udløsningsrørledningen udløses automatisk, når en ny artefakt er tilgængelig fra den tilsluttede byggerørledning. For iscenesættelsesplatforme indebærer denne proces ikke manuel godkendelse, og artefakterne skubbes til klientens CDN og API-serverne.
> [!TIP label:Estimates] Typisk byggekørslen tager ~20-25 minutter at fuldføre efterfulgt af udgivelsen kørsel, som tager ~15-20 minutter for klienten, og ~5-10 minutter for API'en til rådighed live. Fra kode push til at være live på iscenesættelsesplatformene tager hele processen **~ 35-45 minutter** i alt.
### Skub ændringer til produktionsprogrammer.
Processen er for det meste den samme som mellemstationen platforme, med et par ekstra kontrol på plads. Dette er blot for at sikre, at vi ikke bryder noget på freeCodeCamp.org, som kan se hundredvis af brugere bruge det når som helst.
| Udfør IKKE disse kommandoer, medmindre du har bekræftet, at alt fungerer på iscenesættelsesplatformen. Du bør ikke omgå eller springe nogen test på iscenesættelse, før du fortsætter yderligere. |
|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
1. Sørg for, at din `produktions-iscenesættelse` gren er uberørt og synkroniseret med upstream.
```sh
git checkout production-staging
git fetch --all --prune
git reset --hard upstream/production-staging
```
2. Flyt ændringer fra `produktionsfaser` til `produktionsstrøm` via en hurtig sammenfletning
```
git checkout production-current
git merge production-staging
git push upstream
```
> [!BEMÆRK] Du vil ikke være i stand til at tvinge skubb, og hvis du har omskrevet historikken på alligevel vil disse kommandoer fejle ud.
>
> Hvis de gør, kan du have gjort noget forkert, og du bør lige starte forfra.
Ovenstående trin vil automatisk udløse en kørsel på byggerørledningen for `produktionsstrømmen` gren. Når en build artefakt er klar, vil det udløse en kørsel på udgivelsesrørledningen.
> [!TIP label:Estimates] Typisk byggekørslen tager ~20-25 minutter at fuldføre.
**Yderligere trin for personalets indsats**
En udgivelseskørsel er udløst, medlemmer af udviklerpersonalet vil modtage en automatisk manuel intervention e-mail. De kan enten _godkende_ eller _afvise_ udgivelsesrunden.
Hvis ændringerne fungerer pænt og er blevet testet på mellemstationsplatformen, kan den godkendes. Godkendelsen skal gives senest 4 timer efter, at udgivelsen er udløst, før den automatisk afvises. Et personale kan re-trigger release køre manuelt for afviste kørsler, eller vente på den næste cyklus af udgivelse.
Til brug for personalet:
| Tjek din e-mail for et direkte link eller [gå til udgivelsesinstrumentbrættet](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) , når byggekørslen er færdig. |
|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
Når en af personalet godkender en udgivelse, vil rørledningen skubbe ændringerne live til freeCodeCamp.org's produktion CDN og API-servere. De tager typisk ~15-20 minutter for klienten, og ~5 minutter for API servere til at være til rådighed live.
> [!TIP label:Estimates] Udgivelsen køre typisk tager ~15-20 minutter for hver klient eksempel, og ~5-10 minutter for hver API instans at være til rådighed live. Fra kode push til at være levende på produktionsplatformene hele processen tager **~ 90-120 mins** i alt (ikke tælle ventetiden til personalets godkendelse).
## Opbygning, test og implementering Status
Her er den aktuelle test, opbygge og implementere status af kodebasen.
| Type | Gren | Status | Instrumentbræt |
|:--------------- |:--------------------------------------------------------------------------------------------------- |:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |:----------------------------------------------------------------------------------------- |
| CI Test | [`mester`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master) | ![Travis Ci Byg Status](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=master) | [Gå til statusdashboard](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| CI Test | [`produktion-iscenesættelse`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | ![Travis Ci Byg Status](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=production-staging) | [Gå til statusdashboard](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| Byg Rørledning | [`produktion-iscenesættelse`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | [![Byg Status](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_apis/build/status/dot-dev-ci?branchName=production-staging)](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build/latest?definitionId=15&branchName=production-staging) | [Gå til statusdashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build) |
| Slip Rørledning | [`produktion-iscenesættelse`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | | [Gå til statusdashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) |
| CI Test | [`produktionsstrøm`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-current) | ![Travis Ci Byg Status](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=production-current) | [Gå til statusdashboard](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| Byg Rørledning | [`produktionsstrøm`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | [![Byg Status](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_apis/build/status/dot-org-ci?branchName=production-current)](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build/latest?definitionId=17&branchName=production-current) | [Gå til statusdashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build) |
| Slip Rørledning | [`produktionsstrøm`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | | [Gå til statusdashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) |
## Tidlig adgang og beta-test
Vi byder dig velkommen til at teste disse udgivelser i en **"public beta testing"** tilstand og få tidlig adgang til kommende funktioner på platformene. Nogle gange bliver disse funktioner/ændringer omtalt som **næste, beta, iscenesættelse,** osv. udskifteligt.
Dine bidrag via feedback og issue reports vil hjælpe os med at gøre produktionen platforme på `freeCodeCamp. rg` more **resilient**, **konsekvent** og **stabil** for alle.
Vi takker dig for at have rapporteret fejl, som du støder på og hjælper med at gøre freeCodeCamp.org bedre. Du klippe!
### Identifikation af den kommende version af platformene
I øjeblikket er en offentlig beta-test version tilgængelig på:
<h1 align="center"><a href='https://www.freecodecamp.dev' _target='blank'>freecodecamp.dev</a></h1>
> [!BEMÆRK] Domænenavnet er forskelligt fra **`freeCodeCamp.org`**. Dette er tilsigtet at forhindre søgemaskine indeksering og undgå forvirring for almindelige brugere af platformen.
### Identificering af den aktuelle version af platformene
**Den aktuelle version af platformen er altid tilgængelig på [`freeCodeCamp.org`](https://www.freecodecamp.org).**
Dev-teamet fusionerer skifter fra `produktions-staging` filialen til `produktions-current` , når de udgiver ændringer. Den øverste begår bør være, hvad du ser live på webstedet.
Du kan identificere den nøjagtige version implementeret ved at besøge build og implementering logs tilgængelige i statussektionen. Alternativt kan du også ping os i [bidragsyderes chatrum](https://gitter.im/FreeCodeCamp/Contributors) for en bekræftelse.
### Kendte Begrænsninger
Der er nogle kendte begrænsninger og tradeoffs, når du bruger betaversionen af platformen.
- #### Alle data / personlige fremskridt på disse beta platforme `vil IKKE blive gemt eller overført` til produktion.
**Brugere på betaversionen vil have en separat konto fra produktionen.** Beta-versionen bruger en fysisk adskilt database fra produktion. Dette giver os mulighed for at forhindre enhver utilsigtet tab af data eller ændringer. Dev teamet kan rense databasen på denne betaversion efter behov.
- #### Der er ingen garantier for oppetid og pålidelighed af beta platforme.
Deployering forventes at være hyppig og i hurtige iterationer, undertiden flere gange om dagen. Som et resultat vil der være uventet nedetid til tider eller brudt funktionalitet på beta-versionen.
- #### Send ikke almindelige brugere til dette websted som et mål for at bekræfte en rettelse
Beta-stedet er og har altid været at øge den lokale udvikling og afprøvning, intet andet. Det er ikke et løfte om, hvad der kommer, men et glimt af, hvad der arbejdes på.
- #### Signsiden kan se anderledes ud end produktionen
Vi bruger en testlejer til freecodecamp.dev på Auth0, og har derfor ikke mulighed for at indstille et brugerdefineret domæne. Dette gør det således, at alle omdirigeringstilbagekaldelser og login-siden vises på et standard domæne som: `https://freecodecamp-dev.auth0.com/`. Dette påvirker ikke funktionaliteten er så tæt på produktion, som vi kan få.
## Rapporteringsproblemer og tilbagemelding
Åbne nye problemer for diskussioner og rapportering af fejl. Du kan mærke dem som **[`udgivelse: next/beta`](https://github.com/freeCodeCamp/freeCodeCamp/labels/release%3A%20next%2Fbeta)** for triage.
Du kan sende en e-mail til `dev[at]freecodecamp.org` , hvis du har spørgsmål. Som altid bør alle sikkerhedssårbarheder rapporteres til `sikkerhed[at]freecodecamp.org` i stedet for den offentlige tracker og forum.

326
docs/i18n/Danish/flight-manuals/moderator-handbook.md Normal file
View File

@ -0,0 +1,326 @@
# Den officielle freeCodeCamp Moderator Handbook.
Dette vil hjælpe dig med at moderere forskellige steder i vores samfund, herunder:
- GitHub issues & pull requests
- Forummet, chatrum, Facebook-grupper og andre online mødesteder
- In-person begivenheder som studiegrupper, hackathons, og konferencer
**Alle freeCodeCamp Moderatorer er moderatorer i hele samfundet. Det betyder, at vi har tillid til, at du fører tilsyn med nogen af disse steder.**
Dette er sagt, kan du tjene som en moderator i hvilke steder er af mest interesse for dig. Nogle moderatorer hjælper bare på GitHub. Andre hjælper bare på forummet. Nogle moderatorer er aktive overalt.
Den nederste linje er, at vi vil have dig til at nyde at være en moderator, og investere din knappe tid på steder, der er af interesse for dig.
> [!BEMÆRK] "Med stor magt kommer stort ansvar." - Onkel Ben
Som moderator er temperament vigtigere end tekniske færdigheder.
Lyt. Vær Hjælpfuld. Må ikke misbruge din magt.
freeCodeCamp er et rummeligt fællesskab, og vi er nødt til at bevare det på den måde.
Vi har en fælles adfærdskodeks, der styrer hele vores fællesskab. Jo færre regler, jo lettere er de at huske. Du kan læse disse regler og forpligte dem til hukommelse [her](https://code-of-conduct.freecodecamp.org).
# Moderating GitHub
Moderatorerne har mulighed for at lukke problemer og acceptere eller lukke pull anmodninger.
Moderatorer har to primære ansvarsområder vedrørende GitHub:
1. QA'ing and fletning pull requests
2. Evaluering og svar på spørgsmål
## Modererende Pull-forespørgsler
Pull Requests (PR'er) er, hvordan bidragsydere indsender ændringer til freeCodeCamp's repository. Det er vigtigt, at vi udfører kvalitetssikring (QA) på pull anmodninger, før vi beslutter, om vi vil fusionere dem eller lukke dem.
### Typer af Pull-forespørgsler
1. **Challenge Instruction Edits** Dette er ændringer i teksten af udfordringer - Beskrivelse, Instruktioner eller Test Text. Du kan også gennemgå disse højre på GitHub og beslutte, om at flette dem. Vi er nødt til at være lidt mere forsigtige med disse, fordi millioner af mennesker vil støde på denne tekst, mens de arbejder gennem freeCodeCamp pensum. Gør pull-anmodningen teksten mere klar uden at gøre den meget længere? Er redigeringerne relevante og ikke alt for pedantiske? Husk, at vores mål er, at udfordringerne skal være så klare og så korte som muligt. De er ikke stedet for obskure detaljer. Bidragydere kan også forsøge at tilføje links til ressourcer til udfordringerne. Du kan lukke disse pull anmodninger og besvare dem med dette:
> Tak for din pull-anmodning.
>
> Jeg er ved at afslutte denne anmodning. Tilføj links og andre detaljer til udfordringens tilsvarende guide artikel i stedet.
>
> Hvis du tror, jeg er forkert i at lukke dette problem, skal du genåbne det og tilføje yderligere afklaring. Tak og glad kodning.
2. **Challenge Code Edits** Dette er ændringer af koden i en udfordring - Challenge Seed, Challenge Solution, and Test Strings. Disse pull-anmodninger skal trækkes ned fra GitHub og testes på din lokale computer for at sikre, at udfordringstestene stadig kan bestået med den aktuelle løsning, og den nye kode ikke indføre nogen fejl. Nogle bidragsydere kan forsøge at tilføje yderligere test til at dække pedantiske hjørnetilfælde. Vi skal passe på, at vi ikke gør udfordringen for kompliceret. Disse udfordringer og deres test bør være så enkle og intuitive som muligt. Bortset fra de algoritme udfordringer og interview prep sektion, bør eleverne være i stand til at løse hver udfordring inden for omkring 2 minutter.
3. **Kodebase Ændringer** Disse kode redigerer ændre funktionaliteten af freeCodeCamp platformen selv. Nogle gange forsøger bidragsydere at foretage ændringer uden megen forklaring, men for kodeændringer er vi nødt til at sikre, at der er et reelt behov for ændringen. Så disse pull anmodninger bør henvise til en eksisterende GitHub problem, hvor årsagerne til ændringen er drøftet. Derefter kan du åbne pull request på din computer og teste dem ud lokalt. Når du har gjort det, hvis ændringerne ser godt ud, så lad være med at flette dem helt endnu. Du kan kommentere på pull request siger "LGTM", og derefter nævne @raisedadead, så han kan tage et endeligt udseende.
### Sådan flettes eller lukkes pull anmodninger
Først og fremmest, når du vælger en pull anmodning til QA, bør du tildele dig selv til det. Du kan gøre dette ved at klikke på "tildele dig selv" linket under "tildelte" del i højre kolonne i GitHub interface.
Afhængigt af typen af pull anmodning det er, følge de tilsvarende regler anført ovenfor.
Før du sammenfletter en pull-anmodning, skal du sørge for, at GitHub har grønne checkmarks for alt. Hvis der er nogen X's, undersøge dem først og finde ud af, hvordan du får dem forvandlet til grønne checkmarks først.
Nogle gange vil der være en sammenfletningskonflikt. Det betyder, at en anden pull request har foretaget en ændring af den nøjagtige samme del af samme fil. GitHub har et værktøj til at løse disse sammenfletningskonflikter direkte på GitHub. Du kan forsøge at løse disse konflikter. Bare brug din bedste bedømmelse. pull request's ændringer vil være på toppen, og Master branchens ændringer vil være i bunden. Nogle gange vil der være overflødige oplysninger deri, der kan slettes. Før du er færdig, skal du sørge for at slette `<<<<<<`, `=======`, og `>>>>>>` at Git bidrager til at angive konfliktområder.
Hvis pull request ser klar til at flette (og kræver ikke godkendelse fra @raisedadead), kan du gå videre og flette det. Vær sikker på at bruge standard "Squash og Merge" funktionalitet på GitHub. Dette vil klemme alle pull anmodninger forpligter sig ned i et enkelt fællesskab, hvilket gør Git historie meget lettere at læse.
Du skal derefter kommentere på pull anmodningen, takke bidragsyderen på din egen personlige måde.
Hvis forfatteren til pull-forespørgslen er en "førstegangsbidragsyder", bør du også lykønske dem med deres første sammenlagte pull-anmodning til lageret. Du kan se på øverste højre hjørne af PR's krop for at bestemme en førstegangsbidragsyder. Det vil vise `Førstegangsbidragsyder` som vist nedenfor:
![Copy_edits_for_Java_arrays_article_by_karentobo_%C2%B7_Pull_Request__20615_%C2%B7_freeCodeCamp_freeCodeCamp~690x281](https://i.imgur.com/dTQMjGM.png)
Hvis pull-anmodningen ikke ser ud klar til at flette, kan du høfligt svare forfatteren hvad de skal gøre for at få det klar. Forhåbentlig vil de svare og få deres pull-anmodning tættere på klar.
Ofte vil en pull-anmodning naturligvis være en lav indsats. Du kan ofte fortælle dette med det samme, når bidragsyderen ikke generede afkrydsningsfelterne i Pull Request Template eller brugte en generisk pull request titel som "made changes" eller "Update index. d".
Der er også situationer, hvor bidragsyderen forsøger at tilføje et link til deres egen hjemmeside, eller inkludere et bibliotek, de selv har skabt, eller har en useriøs redigering, der ikke tjener til at hjælpe nogen, men selv.
I begge disse situationer, bør du gå videre og lukke deres pull anmodning og svare med denne standard besked:
> Tak for at åbne denne pull anmodning.
>
> Dette er en standard besked, der fortæller dig, at vi har gennemgået din pull-anmodning og har besluttet ikke at flette den. Vi ville glæde os over fremtidige anmodninger fra Dem.
>
> Tak og glad kodning.
Hvis du har brug for en anden udtalelse om en pull-anmodning, gå videre og efterlade dine kommentarer til pull-anmodningen, derefter tilføje "diskuterende" etiket til pull anmodningen.
## Modererende GitHub Problemer
freeCodeCamp er et aktivt open source-projekt. Vi får nye spørgsmål hver dag, som alle skal forsøges og mærkes.
### Typer af GitHub Issues
1. **Code Help Requests**, hvilke folk har fejlagtigt oprettet GitHub problemer for. Hvis nogen beder om hjælp, indsæt følgende besked, så luk problemet.
> Tak for din rapportering om dette problem.
>
> Dette er en standard besked om, at dette problem synes at være en anmodning om hjælp. I stedet for at bede om hjælp her, klik venligst på \*\*"Hjælp"\*\* knappen på udfordringen på freeCodeCamp, som vil hjælpe dig med at skabe et spørgsmål i den rigtige del af forummet. Frivillige på forummet svarer normalt på spørgsmål inden for et par timer og kan hjælpe med at afgøre, om der er et problem med din kode eller udfordringens tests.
>
> Hvis forummedlemmerne afgør, at der ikke er noget galt med din kode, kan du anmode om at dette problem genåbnes.
>
> Tak og glad kodning.
2. **Fejl- eller afklaringsproblemer** Prøv selv at reproducere fejlen, hvis du kan. Hvis ikke, så spørg dem om trinene for at reproducere fejlen, og om de har screenshots, videoer, eller yderligere detaljer, der kan hjælpe dig med at gengive problemet. Når du kan gengive problemet - eller i det mindste bekræfte det er et legit problem - etiket det `bekræftet`. Så:
- Hvis det er en simpel ændring til en eksisterende udfordring, etiket som `første timer kun`, ellers etiket som `hjælp ønskede`. Brug andre etiketter efter behov.
- Hvis problemet er mere betydningsfuldt, flag som `bug`. &nbsp; Hvis der er nogen tvetydighed med hensyn til den korrekte fremgangsmåde i en sag, er velkommen til at tagge @raisedadead om problemet få sin mening om det, og derefter tilføje `Diskutere` etiketten.
3. **Duplikerede problemer** Hvis et problem er det samme som et andet rapporteret problem, bør det tidligere rapporterede problem have forrang. Markér som `Dupliker`, indsæt følgende besked, der erstatter `#XXXXX` med problemnummeret, og luk derefter problemet.
> Tak for din rapportering om dette problem.
>
> Dette er en standard besked om, at dette problem synes at være meget lig udstedelse # XXXXX, så jeg er ved at lukke det som et duplikat.
>
> Hvis du tror, jeg er forkert i at lukke dette problem, skal du genåbne det og tilføje yderligere afklaring. Tak og glad kodning.
4. **Fast i iscenesættelse** Nogle problemer er måske allerede blevet rettet i iscenesættelse, men har ikke et GitHub problem forbundet med dem. Hvis dette er tilfældet, kan du indsætte følgende besked, lukke problemet og tilføje en `status: løst/shipping` etiket:
> Tak for din rapportering om dette problem.
>
> Dette er et standardbudskab til Dem om, at det problem, De nævnte her, er til stede i produktionen, men at det allerede er blevet fastsat i etaper. Det betyder, at næste gang vi skubber vores iscenesættelse til produktion, bør dette problem løses. På grund af dette, jeg lukker dette problem.
>
> Hvis du tror, jeg er forkert i at lukke dette problem, skal du genåbne det og tilføje yderligere afklaring. Tak og glad kodning.
### Lukning af Stale, forældede, inaktive spørgsmål og Pull-forespørgsler
- Gamle problemer eller PR'er er dem, der ikke har set nogen aktivitet fra OP i 21 dage (3 uger fra sidste aktivitet) men først efter en moderator har anmodet om flere oplysninger/ændringer. Disse kan lukkes i et automatiseret / bot script eller af moderatorerne selv.
- Aktivitet er defineret som: Kommentarer der anmoder om en opdatering på PR og triages som `status: Opdater nødvendig` etiket osv.
- Hvis OP beder om yderligere hjælp eller endda tid, kan ovenstående blive afslappet og genbesøgt efter et svar er givet. Under alle omstændigheder bør mods bruge deres bedste vurdering til at løse den udestående PR's status.
### Andre retningslinjer for moderatorer på GitHub
Selvom du vil have skriveadgang til freeCodeCamp's repositorie, **bør du aldrig skubbe kode direkte til freeCodeCamp repositorier**. Al kode skal indtaste freeCodeCamp's kodebase i form af en pull-anmodning fra en gaffel fra lageret.
Du bør heller aldrig acceptere din egen PR. De skal være QA'd af en anden moderator, ligesom med enhver anden PR.
Hvis du bemærker nogen bryder [adfærdskodeksen](https://code-of-conduct.freecodecamp.org) på GitHub spørgsmål, eller åbning af pull requests med skadeligt indhold eller kode, e-mail dev@freecodecamp. rg med et link til den krænkende pull-anmodning, og vi kan overveje at forbyde dem fra freeCodeCamp's GitHub organisation helt.
# Moderation af forummet
Som moderator hjælper du med at holde vores fællesskab et behageligt sted, hvor alle kan lære og få hjælp. Du vil beskæftige sig med flagede indlæg og håndtere spam, off-topic, og andre upassende samtaler.
Bemærk, at når du er moderator på forummet, vil du begynde at se blå moderator tips om forum medlemmer, som "dette er første gang [person] har sendt - lad os byde dem velkommen til fællesskabet! eller "[person] har ikke postet i lang tid - lad os byde dem velkommen tilbage."
![En blå tekst besked siger "dette er første gang [person] har sendt - lad os byde dem velkommen til fællesskabet!](https://i.imgur.com/mPmVgzK.png)
Disse er muligheder for dig at byde dem velkommen og få dem til at føle sig ekstra specielle. Du ved aldrig, hvilken person, der er marginalt involveret, kan blive vores næste superhjælper, hjælpe mange andre mennesker i deres kodning rejse. Selv den mindste venlighed kan udløse en kaskade af gode gerninger.
### Sletter forumindlæg
Forum moderatorer har mulighed for at slette brugerens indlæg. Du bør kun gøre dette i følgende tilfælde:
1. Nogen har sendt et pornografisk eller grafisk voldeligt billede.
2. Nogen har udstationeret et link eller kode, der er skadelig i naturen, og kunne skade andre campister, der klikker på det.
3. Nogen har oversvømmet en tråd med masser af spambeskeder.
### Håndtering af spam
For det første spam-indlæg af en bruger, send dem en meddelelse, der forklarer problemet, og fjerne linket eller indlægget efter behov. Efterlad et notat på brugerens profil, der forklarer hvilken handling du har foretaget. Hvis problemet fortsætter, så følg processen ovenfor. Blokér brugeren stille og roligt fra at poste (ved hjælp af indstillingen stilhed i brugeradministratorpanelet), og send derefter en advarsel med Adfærdskodeksen. Markér feltet i den private besked, der angiver, at din besked er en "formel advarsel".
Du kan stille spørgsmål og rapportere hændelser i [personaleforummet](https://forum.freecodecamp.com/c/staff).
### Håndtering af samtaler, der ikke er emnet
Indlæg eller emner, der synes at være på det forkerte sted, kan blive re-kategoriseret eller omdøbt til hvad der ville være passende.
Under særlige omstændigheder kan det være hensigtsmæssigt, at en moderator gaffler en diskussion i flere tråde.
Igen, hvis du har problemer eller spørgsmål, lave et indlæg med dine handlinger i personalet kategori, og tag en anden moderator, hvis du vil have dem til at gennemgå dine modererende handlinger.
### Mindreårige Brugere
Vores servicevilkår kræver, at freeCodeCamp brugere er mindst 13 år. I tilfælde af, at en bruger afslører, at de er under 13 år, sende dem nedenstående besked og slette deres forum konto (hvis sletning ikke er tilgængelig, suspension af kontoen er tilstrækkelig). Send derefter [Quincy](https://forum.freecodecamp.org/u/QuincyLarson) (quincy@freecodecamp.org) eller [Mrugesh](https://forum.freecodecamp.org/u/raisedadead) (mrugesh@freecodecamp.org) for at slette brugerens freeCodeCamp-konto.
```markdown
EMNE: Brugere under 13 må ikke bruge forummet i henhold til servicevilkår
Det er kommet til vores opmærksomhed, at du er under 13 år. Per [freeCodeCamp terms of service](https://www.freecodecamp.org/news/terms-of-service), du skal være mindst 13 år gammel for at bruge webstedet eller forummet. Vi vil slette både din freeCodeCamp konto og din forum konto. Denne begrænsning holder os i overensstemmelse med USA's lovgivning.
Vær venlig at vende tilbage når du har nået mindst 13 år.
Tak for Deres forståelse.
```
# Modererende Facebook
Hvis du ser noget, der synes at bryde vores [Code of Conduct](https://code-of-conduct.freecodecamp.org/), skal du slette det med det samme.
Nogle gange vil folk sende ting, som de synes er sjove. De er ikke klar over, at det, de sagde, eller hvad de delte, kunne fortolkes som krænkende. I disse tilfælde skal deres indlæg slettes, men den person, der har udstationeret det, behøver ikke nødvendigvis at blive forbudt. Ved at få deres indlæg slettet, vil de forhåbentlig komme til at forstå, at hvad de udstationerede var upassende.
Men hvis det er en overgreb, der ikke med rimelighed kan tilskrives en kulturel forskel eller en misforståelse af det engelske sprog, så bør du på det kraftigste overveje at blokere medlemmet fra Facebook-gruppen.
# Modererende Discord
Her er hvordan moderatorer håndtere overtrædelser af vores [Code of Conduct](https://code-of-conduct.freecodecamp.org/) på Discord:
1. **Sørg for, at det var hensigten at krænke adfærdskodeksen.** Ikke alle overtrædelser af komitéen var beregnet som sådan. En ny autocamper kan sende en stor mængde kode til hjælp, uvidende om, at dette kan betragtes som spamming. I disse tilfælde kan du bare bede dem om at indsætte deres kode med tjenester som Codepen eller Pastebin.
2. **Hvis autocamperen klart overtræder adfærdskodeksen, vil moderatoren fortsætte på følgende måde:**
- Suspendér den krænkende autocamper, men advarer ikke eller truer dem. I stedet, stille og roligt give dem den suspenderede rolle på Discord, så send dem følgende meddelelse:
```
Dette er en standard besked om, at jeg var nødt til midlertidigt at suspendere dig fra at tale på freeCodeCamp Discord serveren.
Jeg er moderator, der handler på vegne af vores open source-fællesskab. Jeg kan overveje at fjerne din suspension, men jeg har brug for dig til at tage følgende 3 skridt først:
1. Læs vores adfærdskodeks: https://code-of-conduct.freecodecamp.org/
2. Besked mig tilbage bekræfter, at du er færdig med at læse den.
3. Forklar mig, hvorfor De mener, at jeg suspenderede Dem, og hvorfor jeg skulle fjerne Deres suspension.
```
- Rapportér en kort oversigt over begivenheden, og hvordan de reagerede på det i #admin kanalen. Her er et eksempel på, hvordan en sådan oversigt kan se ud:
```
Suspenderet: _@username_
Reason(s): _Spamming, trolling_
Evidence: _One eller flere links til de(n) krænkende meddelelse(r)_
CoC: _Sent_
```
- En rapport til fjernelse af en suspension bør se sådan ud:
```
Jeg har fjernet suspensionen fra ` @username `. Jeg sendte dem adfærdskodeksen. De indså i dag, at de blev suspenderet og undskyldt for, hvad de gjorde.
```
- Baseret på gerningsmændenes svar, vil moderatoren beslutte, om at fjerne suspensionen fra den krænkende camper. Hvis de synes respektfulde og undskyldende, kan moderatoren fjerne suspensionen. Som en politisk sag vil moderatorer være høflige i denne proces, uanset hvor dårligt den krænkende autocamper har opført. Hvis de ikke er respektfulde eller uvillige til at acceptere komitéen, bør suspensionen følges med et forbud fra Discord serveren. Brug det samme resumé som ovenfor, men erstat "Suspended:" med "Banned:".
3. **Sådan bandlyses og/eller afskaffes**
- For at forbyde nogen, højreklik på deres brugernavn / profil billede og vælg "Ban <username>". Du vil blive givet mulighed for at slette deres tidligere beskeder - vælg "Slet ikke", da meddelelserne bør forblive til stede som en historisk rekord.
- Hvis du beslutter dig for at forbyde nogen, betyder det, at de er uvillige til at overholde vores adfærdskodeks. Derfor bør der sjældent forekomme forbud mod en Camper. Men hvis behovet opstår, kan du gøre det ved at klikke på servernavnet, vælge "Server Indstillinger", vælge "Bans", vælge den bruger, du ønsker at fjerne forbud, og klikke på "Tilbagekald Ban".
Discord Bans er globale - du kan ikke udelukke en bruger fra en bestemt kanal, kun fra hele serveren.
4. **Sletning af beskeder** Moderatorer har mulighed for at slette beskeder på Discord. De bør kun udøve denne evne i fire meget specifikke situationer:
- Nogen har sendt et pornografisk eller grafisk voldeligt billede.
- Nogen har udstationeret et link eller kode, der er skadelig i naturen, og kunne skade andre campister, der klikker på det.
- Nogen har oversvømmet chatten med masser af spam-beskeder til en sådan ekstrem grad (normalt involverer bots) at gøre chat helt ubrugelig.
- Nogen har sendt reklame og / eller en selvpromoverende besked / billede (sociale medier).
I alle andre situationer - selv situationer, hvor adfærdskodeksen overtrædes - bør moderatorerne ikke slette meddelelsen, da disse er en vigtig historisk rekord. Når du sletter en besked, skal du sørge for at tage et skærmbillede af den først! Skærmbilledet kan være logget på #mod-log-kanalen, men for #activity-loggen er det tilstrækkeligt at sige, at beviserne blev "fjernet på grund af følsomt indhold". Bemærk: Hvis meddelelsen indeholder materiale, der ville være ulovligt at tage et skærmbillede af, kopier i stedet beskedlinket - giv dette beskedlink til @raisedadead for at videresende til Discord's Trust and Safety Team.
5. **Brug ikke @everyone eller @here** Brug ikke @everyone eller @here under ingen omstændigheder! Hver enkelt person i dette chatrum får en notifikation. I nogle tilfælde titusinder af mennesker. I stedet, hvis du vil have folk til at se en meddelelse, du kan fastgøre det til den kanal til at tillade alle at læse det.
6. **Trues ikke at forbyde eller suspendere** Hvis en autocamper bryder adfærdskodeksen, ikke true med at forbyde eller suspendere dem, og aldrig advare dem offentligt. I stedet, tale med dem privat, eller sende dem en DM og udstede en suspension (per ovenstående protokol). Ingen andre i denne kanal har brug for at vide, at du bandlyste / suspenderede personen - campister kan se resuméet i #activity-log-kanalen, hvis de ønsker at holde op på disse oplysninger. Hvis en overtrædelse var klart utilsigtet og ikke garanterer en suspension eller privat samtale, gøre den krænkende autocamper opmærksom på hans / hendes handlinger uden at gøre det kommer på tværs som en advarsel. For eksempel:
- Camper sender en kodevæg for at anmode om hjælp
Moderator: @username Brug venligst Codepen eller Pastebin når du sender store mængder kode.
- Eller hvis du virkelig nødt til at forklare hvorfor:
Moderator: @username Brug venligst Codepen eller Pastebin når du sender store mængder kode, fordi det forstyrrer chatten for alle og kan betragtes som spamming i henhold til vores adfærdskodeks.
- For milde og utilsigtede overtrædelser af adfærdskodeksen
Moderator: Dette er en venlig påmindelse for alle at følge adfærdskodeksen: https://code-of-conduct.freecodecamp.org/
7. **Må ikke prale af at være en moderator** Se ikke dig selv som over fællesskabet. Du er fællesskabet. Og fællesskabet har tillid til dig for at hjælpe med at beskytte noget sjældent, som vi alle deler - et _indbydende_ sted for nye udviklere. Hvis du praler om at være en moderator, folk kan føle sig utrygge omkring dig, på samme måde, som folk kan føle sig utrygge omkring en politibetjent, selv hvis de ikke gør noget galt. Det er kun den menneskelige natur.
8. **Modsiger ikke andre moderatorer** Hvis du er uenig i en moderators handling tale med dem i privat eller bringe det op i den #mod-chat kanal. Aldrig tilsidesætte et forbud, og aldrig modsige de andre moderator(er) offentligt. I stedet har en kølig diskussion i mod-chat og overbevise moderatoren om, at de selv bør vende deres forbud eller ændre deres synspunkt. Husk: Vi er alle på det samme team. Vi ønsker at værdsætte moderatorernes rolle og præsentere en fælles front.
9. **Tal med andre moderatorer** Vi har kun plads til moderatorer. Brug det! Hvis du føler dig ubehagelig med at håndtere en bestemt situation, så spørg andre moderatorer om hjælp. Hvis De mener, at der skal diskuteres noget, så gør det. Du er en del af teamet, og vi sætter pris på input fra alle teammedlemmer! Selv om De er fuldstændig uenig i noget i disse retningslinjer eller i adfærdskodeksen!
10. **Midlertidigt inaktiv** Hvis du ikke vil være aktiv som moderator i et stykke tid på grund af ferie, sygdom eller anden grund, sørge for at lade de andre vide i den #mod-chat kanal. Dette er så vi ved, om vi kan regne med, at du regelmæssigt er aktiv på serveren eller ej.
# Sådan bliver du en moderator
Hvis du hjælper folk i samfundet konsekvent over tid, vil vores Moderator Team til sidst tage til efterretning, og en af dem vil nævne dig som en mulig moderator til [vores personale](https://forum.freecodecamp.org/g/Team). Der er ingen genveje til at blive moderator.
Hvis du er godkendt, vil vi føje dig til vores Moderator Teams på [GitHub](https://github.com/orgs/freeCodeCamp/teams/moderators), [forum](https://forum.freecodecamp.org/g/moderators)osv.
> [!NOTE] > **For GitHub:** Når du er blevet accepteret som moderator, vil du modtage en Github repository invitation. Du er nødt til at gå over mod [freeCodeCamp GitHub Organisation Invitation](https://github.com/orgs/freeCodeCamp/invitation) for at kunne acceptere invitationen. Dette er nødvendigt, for at vi kan give dig skriveadgang på nogle af vores depoter.
# Hvordan vi pensionerer inaktive moderatorer
Bemærk venligst, at vi ofte vil fjerne mods, som vi mener er inaktive. Når vi gør dette, vil vi sende følgende meddelelse:
> Dette er en standard besked, der underretter dig om, at, da du ikke synes at have været en aktiv moderator for nylig, fjerner vi dig fra vores Moderator-team. Vi værdsætter dybt jeres hjælp i fortiden.
> Hvis du tror, vi gjorde det ved en fejl, eller når du er klar til at komme tilbage og bidrage mere, besvar blot denne besked, så jeg kan vide.
# Sådan fungerer vores bidragyderrum
Alle er velkomne i [Contributors room på vores Discord](https://discord.gg/KVUmVXA). Det er det udpegede chatrum til moderatorer og andre campister, der bidrager til vores fællesskab på en hvilken som helst måde herunder gennem studiegrupper.
Vores antagelse er, at bidragsydere vil læse alt i dette rum, der direkte nævner dem med et `@username`. Alt andet er valgfrit. Men du er velkommen til at læse noget som helst indlæg derinde og interagere.
# Håndtering af advokater
Du kan blive kontaktet af organisationer, der ønsker at partner eller co-brand med freeCodeCamp på en eller anden måde. Når du indser, at dette er, hvad de er efter, skal du stoppe med at tale med dem og fortælle dem at e-maile quincy@freecodecamp.org. Han får hele tiden forslag som dette og er i den bedste position til at bedømme, om et sådant forhold vil være det værd for vores samfund (og det er sjældent).
# Håndtering af (mental) sundhedsforespørgsler
Du kan komme på tværs af situationer, hvor brugere søger lægehjælp eller beskæftiger sig med mental sundhed og søger støtte. Som en politisk sag bør De undgå at tale privat om disse spørgsmål. Hvis situationen på et tidspunkt afspejler sig tilbage til fCC, ønsker vi at føre samtalen på posten. Gør det klart, at vi ikke er sundhedspersonale, og at du opfordrer brugeren til at finde professionel hjælp. Så svært som det nogle gange kan være, undgå at give nogen tips eller råd, bortset fra at pege brugeren i retning af professionel hjælp!
Hvis dette sker på Discord: Suspendér brugeren. Det er ikke at straffe dem! Suspenderer en bruger vil skabe en privat kanal, der kun er tilgængelig for brugeren og holdet. Dette vil gavne både brugeren og fCC på flere måder:
- Brugeren er garanteret noget privatliv
- Offentlig chat er ikke længere forstyrret
- Andre teammedlemmer kan rejse ind, hvis du er ubehageligt at håndtere situationen selv
> [!BEMÆRK] Suspenderer en bruger automatisk giver dem en besked om at læse vores adfærdskodeks. Sørg for at du informerer brugeren om, at du Suspenderede dem for at give dem noget privatliv, og at de ikke bliver straffet. Det er meget vigtigt! Vi ønsker absolut at undgå at give brugerne den idé, at de bliver straffet for at nå ud for at få hjælp!
Hvis du mener, at brugeren er i stand til at slutte sig til samfundet, skal du højreklikke på den private kanal og kopiere ID. Sæt følgende besked i #mod-log:
> Henvisning til lægelig rådgivning: <channel ID> <username>
Derefter kan du fjerne suspensionen fra brugeren, som du normalt gør.
Nyttige URL'er:
http://www.suicide.org/international-suicide-hotlines.html
# Et notat om ytringsfrihed
Nogle gange vil folk forsvare noget stødende eller antændende, at de sagde som "ytringsfrihed".
Denne XKCD tegneserie opsummerer perfekt de fleste samfunds tanker om ytringsfrihed. Så hvis nogen forsvarer noget, de siger som "ytringsfrihed" velkommen til at sende det til dem.
<div align="center"><img src='https://aws1.discourse-cdn.com/freecodecamp/original/3X/4/3/43a8b2eafe4c8622e02838f66f1dc6227de32c70.png' width="400" height="400" /></div>
Tak for at læse dette, og tak for at hjælpe udviklerfællesskabet!

126
docs/i18n/Danish/flight-manuals/using-reply-templates.md Normal file
View File

@ -0,0 +1,126 @@
# Brug Af Svar Skabeloner
Disse er nogle af de standard svar skabeloner, som du kan bruge, mens du gennemgår pull requests og triaging spørgsmål.
> Du kan selv lave dine egne med GitHubs indbyggede [**Gemte svar**](https://github.com/settings/replies/) -funktion eller bruge dem nedenfor.
### Mange tak
```markdown
Tak for dit bidrag til siden! 👍
Vi accepterer gerne disse ændringer og ser frem til fremtidige bidrag. 🎉
```
### Tak og tillykke
> For at takke og opmuntre førstegangsbidragsydere.
```markdown
Hej @username. Tillykke med din første pull-anmodning (PR)! 🎉
Tak for dit bidrag til siden! 👍
Vi accepterer gerne disse ændringer og ser frem til fremtidige bidrag. 📝
```
### Fejl Ved Bygning
```markdown
Hej @username
Vi vil elske at kunne flette dine ændringer, men det ser ud til, at der er en fejl med Travis CI build. ⚠️
Når du har løst disse problemer, vil vi kunne gennemgå din PR og flette den. 😊
---
> Du er velkommen til at henvise til [Style guide for at skrive artikler](https://github. om/freeCodeCamp/freeCodeCamp#artikeltitel) til dette repo ved at formatere en artikel korrekt så din Travis CI bygger passer. ✅
>
> Det er også god praksis på GitHub at skrive en kort beskrivelse af dine ændringer, når du opretter en PR. 📝
```
### Synkroniserer Gaffel
> Når PR ikke er opdateret med `master` -grenen.
``````markdown
Hej @username
Vi vil elske at kunne flette dine ændringer, men det ser ud til, at der er en fejl med Travis CI build. ⚠️
```bash
Fejl: ENOTDIR: ikke en mappe, åben 'src/pages/java/data-abstraction/index.md'
``````
Denne særlige fejl var ikke forårsaget af din fil, men var en gammel fejl forårsaget af sammenlægning defekt kode til `master` filialen. Det er siden blevet løst.
For at bestå bygningen, skal du synkronisere de seneste ændringer fra `master` gren af `freeCodeCamp/freeCodeCamp` repo.
Ved hjælp af kommandolinjen, kan du gøre dette i tre nemme trin:
```bash
git remote add upstream git://github.com/freeCodeCamp/freeCodeCamp.git
git fetch upstream
git pull upstream master
```
Hvis du bruger en GUI, kan du blot `Tilføj en ny fjernbetjening...` og bruge linket `git://github.com/freeCodeCamp/freeCodeCamp.git` fra oven.
Når du synkroniserer din gaffel og passerer bygningen, Vi vil være i stand til at gennemgå din PR og fusionere den. 😊
---
> Du er velkommen til at henvise til artiklen [Synkronisering af en gaffel](https://help.github.com/articles/syncing-a-fork/) på GitHub for mere indsigt i, hvordan du holder din gaffel opdateret med upstream repository. 🔄
>
> Det er også god praksis på GitHub at skrive en kort beskrivelse af dine ændringer, når du opretter en PR. 📝
``````
### Sammenfletningskonflikter
> Når PR har sammenfletningskonflikter, der skal løses.1
```markdown
Hey @username
Vi vil elske at kunne flette dine ændringer, men det ser ud til, at du har nogle sammenfletningskonflikter. ⚠️
Når du har løst disse konflikter, vil vi være i stand til at gennemgå din PR og flette den. 😊
---
> Hvis du ikke er bekendt med sammenfletningskonfliktprocessen, er velkommen til at kigge over GitHubs guide på ["Løs en sammenfletningskonflikt"](https://help. ithub.com/articles/resolving-a-merge-conflict-on-github/). 🔍
>
> Det er også god praksis på GitHub at skrive en kort beskrivelse af dine ændringer, når du opretter en PR. 📝
``````
1 Hvis en førstegangsbidragsyder har en fusionskonflikt, vil vedligeholdere løse konflikten for dem.
### Duplicate
> Når PR er repetitiv eller en dublet.
```markdown
Hej @username
Det lader til, at lignende ændringer allerede er blevet accepteret tidligere for denne artikel du redigerer, ked af det. 😓
Hvis du føler, du har mere at tilføje, er du velkommen til at åbne en ny PR.
Tak igen! 😊
---
> Hvis du har spørgsmål, er du velkommen til at kontakte [Gitter](https://gitter.im/FreeCodeCamp/Contributors) eller ved at kommentere nedenfor. 💬
```
### Lukker ugyldige pull anmodninger
> Når PR er ugyldig.
```markdown
Hej @username
Du har ikke tilføjet noget indhold, Vi lukker denne PR og markerer den som 'ugyldig'. 😓
Du er dog velkommen til at åbne en anden PR! 👍
```

481
docs/i18n/Danish/flight-manuals/working-on-virtual-machines.md Normal file
View File

@ -0,0 +1,481 @@
# Flight Manual for working on Virtual Machines
Som medlem af personalet eller dev-teamet du kan have fået adgang til vores cloud serviceudbydere som Azure, Digital Ocean, etc.
Her er nogle praktiske kommandoer, som du kan bruge til at arbejde på de virtuelle maskiner (VM), for eksempel udfører vedligeholdelsesopdateringer eller laver generel houeskeeping.
# Get a list of the VMs
> [!BEMÆRK] Mens du måske allerede har SSH adgang til VM'erne, det alene vil ikke lade dig liste VM'er, medmindre du er blevet tildelt adgang til cloud-portaler samt.
## Azure
Installer Azure CLI `az`: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli
> **(One-time) Install on macOS with [`homebrew`](https://brew.sh):**
```
brew install azure-cli
```
> **(One-time) Login:**
```
az login
```
> **Get the list of VM names and P addresses:**
```
az vm list-ip-addresses --output table
```
## Digital Ocean
Installer Digital Ocean CLI `doctl`: https://github.com/digitalocean/doctl#installing-doctl
> **(One-time) Install on macOS with [`homebrew`](https://brew.sh):**
```
brew install doctl
```
> **(One-time) Login:**
Autentificering og kontekstskift: https://github.com/digitalocean/doctl#authenticating-with-digitalocean
```
doctl auth init
```
> **Get the list of VM names and IP addresses:**
```
doctl compute droplet list --format "ID,Name,PublicIPv4"
```
# Spin a VM (or VM Scale Set)
> Todo: Add instructions for spinning VM(s)
<!--
The below instructions are stale.
### 0. Prerequisites (workspace Setup) for Staff
Get a login session on `azure cli`, and clone the
[`infra`](https://github.com/freeCodeCamp/infra) for setting up template
workspace.
```console
az login
git clone https://github.com/freeCodeCamp/infra
cd infra
```
Use the Scratchpad subdirectory for temporary files, and making one-off edits.
The contents in this subdirectory are intentionally ignored from source control.
### 1. Provision VMs on Azure.
List all Resource Groups
```console
az group list --output table
```
```console
Name Location Status
--------------------------------- ------------- ---------
tools-rg eastus Succeeded
```
Create a Resource Group
```
az group create --location eastus --name stg-rg
```
```console
az group list --output table
```
```console
Name Location Status
--------------------------------- ------------- ---------
tools-rg eastus Succeeded
stg-rg eastus Succeeded
```
Next per the need, provision a single VM or a scaleset.
#### A. provision single instances
```console
az vm create \
--resource-group stg-rg-eastus \
--name <VIRTUAL_MACHINE_NAME> \
--image UbuntuLTS \
--size <VIRTUAL_MACHINE_SKU>
--custom-data cloud-init/nginx-cloud-init.yaml \
--admin-username <USERNAME> \
--ssh-key-values <SSH_KEYS>.pub
```
#### B. provision scaleset instance
```console
az vmss create \
--resource-group stg-rg-eastus \
--name <VIRTUAL_MACHINE_SCALESET_NAME> \
--image UbuntuLTS \
--size <VIRTUAL_MACHINE_SKU>
--upgrade-policy-mode automatic \
--custom-data cloud-init/nginx-cloud-init.yaml \
--admin-username <USERNAME> \
--ssh-key-values <SSH_KEYS>.pub
```
> [!NOTE]
>
> - The custom-data config should allow you to configure and add SSH keys,
> install packages etc. via the `cloud-init` templates in your local
> workspace. Tweak the files in your local workspace as needed. The cloud-init
> config is optional and you can omit it completely to do setups manually as
> well.
>
> - The virtual machine SKU is something like: **Standard_B2s** which can be
> retrived by executing something like
> `az vm list-sizes -l eastus --output table` or checking the Azure portal
> pricing.
-->
# Keep VMs updated
You should keep the VMs up to date by performing updates and upgrades. This will ensure that the virtual machine is patched with latest security fixes.
> [!WARNING] Before you run these commands:
>
> - Sørg for, at VM er blevet leveret fuldstændigt, og der er ingen efter installationstrin kører.
> - If you are updating packages on a VM that is already serving an application, make sure the app has been stopped / saved. Package updates will cause network bandwidth, memory and/or CPU usage spikes leading to outages on running applications.
Update package information
```console
sudo apt update
```
Upgrade installed packages
```console
sudo apt upgrade -y
```
Cleanup unused packages
```console
sudo apt autoremove -y
```
# Work on Web Servers (Proxy)
We are running load balanced (Azure Load Balancer) instances for our web servers. These servers are running NGINX which reverse proxy all of the traffic to freeCodeCamp.org from various applications running on their own infrastructures.
NGINX config er tilgængelig på [dette repository](https://github.com/freeCodeCamp/nginx-config).
## First Install
Provisioning VMs with the Code
### 1. (Optional) Install NGINX and configure from repository.
The basic setup should be ready OOTB, via the cloud-init configuration. SSH and make changes as necessary for the particular instance(s).
Hvis du ikke bruger cloud-init config tidligere bruge nedenstående til manuel opsætning af NGINX og fejlsider:
```console
sudo su
cd /var/www/html
git clone https://github.com/freeCodeCamp/error-pages
cd /etc/
rm -rf nginx
git clone https://github.com/freeCodeCamp/nginx-config nginx
cd /etc/nginx
```
### 2. Install Cloudflare origin certificates and upstream application config.
Få Cloudflare oprindelsescertifikater fra den sikre opbevaring og installere på krævede steder.
**OR**
Move over existing certificates:
```console
# Local
scp -r username@source-server-public-ip:/etc/nginx/ssl ./
scp -pr ./ssl username@target-server-public-ip:/tmp/
# Remote
rm -rf ./ssl
mv /tmp/ssl ./
```
Update Upstream Configurations:
```console
vi configs/upstreams.conf
```
Add/update the source/origin application IP addresses.
### 3. Setup networking and firewalls.
Configure Azure firewalls and `ufw` as needed for ingress origin addresses.
### 4. Add the VM to the load balancer backend pool.
Configure and add rules to load balancer if needed. You may also need to add the VMs to load balancer backend pool if needed.
## Opdatering Af Instanser (Maintenance)
1. Check status for NGINX service using the below command:
```console
sudo systemctl status nginx
```
2. Logging and monitoring for the servers are available at:
> <h3 align="center"><a href='https://amplify.nginx.com' _target='blank'>https://amplify.nginx.com</a></h3>
## Updating Instances (Maintenance)
Konfigurer ændringer i vores NGINX forekomster vedligeholdes på GitHub, disse bør implementeres på hver instans som så:
1. SSH into the instance and enter sudo
```console
sudo su
```
2. Get the latest config code.
```console
cd /etc/nginx
git fetch --all --prune
git reset --hard origin/master
```
3. Test og genindlæs konfigurationen [med signaler](https://docs.nginx.com/nginx/admin-guide/basic-functionality/runtime-control/#controlling-nginx).
```console
nginx -t
nginx -s reload
```
# Work on API Instances
1. Install build tools for node binaries (`node-gyp`) etc.
```console
sudo apt install build-essential
```
## First Install
Provisioning VMs with the Code
1. Install Node LTS.
2. Update `npm` and install PM2 and setup logrotate and startup on boot
```console
npm i -g npm
npm i -g pm2
pm2 install pm2-logrotate
pm2 startup
```
3. Clone freeCodeCamp, setup env and keys.
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
cd freeCodeCamp
git checkout production-current # or any other branch to be deployed
```
4. Create the `.env` from the secure credentials storage.
5. Create the `google-credentials.json` from the secure credentials storage.
6. Install dependencies
```console
npm ci
```
7. Build the server
```console
npm run ensure-env && npm run build:server
```
8. Start Instances
```console
cd api-server
pm2 start production-start.js -i max --max-memory-restart 600M --name org
```
## Opdatering Af Instanser (Maintenance)
```console
## Logning og overvågning
```console
pm2 logfiler
```
```console
pm2 monit
```
## Updating Instances (Maintenance)
Code changes need to be deployed to the API instances from time to time. It can be a rolling update or a manual update. The later is essential when changing dependencies or adding enviroment variables.
> [!DANGER] The automated pipelines are not handling dependencies updates at the minute. We need to do a manual update before any deployment pipeline runs.
### 1. Manual Updates - Used for updating dependencies, env variables.
1. Stop all instances
```console
pm2 stop all
```
2. Install dependencies
```console
npm ci
```
3. Build the server
```console
npm run ensure-env && npm run build:server
```
4. Start Instances
```console
pm2 start all --update-env && pm2 logs
```
### 2. Rolling updates - Used for logical changes to code.
```console
pm2 reload all --update-env && pm2 logs
```
> [!NOTE] We are handling rolling updates to code, logic, via pipelines. You should not need to run these commands. These are here for documentation.
# Work on Client Instances
1. Install build tools for node binaries (`node-gyp`) etc.
```console
sudo apt install build-essential
```
## First Install
Provisioning VMs with the Code
1. Install Node LTS.
2. Update `npm` and install PM2 and setup logrotate and startup on boot
```console
npm i -g npm
npm i -g pm2
npm install -g serve
pm2 install pm2-logrotate
pm2 startup
```
3. Clone client config, setup env and keys.
```console
git clone https://github.com/freeCodeCamp/client-config.git client
cd client
```
```console
git clone https://github.com/freeCodeCamp/client-config.git client
cd client
```
Start pladsholder instanser for webklienten, disse vil blive opdateret med artefakter fra Azure pipline.
> Todo: This setup needs to move to S3 or Azure Blob storage
>
> ```console
echo "serve -c ../../serve.json www -p 50505" >> client-start-primary.sh
chmod +x client-start-primary.sh
pm2 delete client-primary
pm2 start ./client-start-primary.sh --name client-primary
echo "serve -c ../../serve.json www -p 52525" >> client-start-secondary.sh
chmod +x client-start-secondary.sh
pm2 delete client-secondary
pm2 start ./client-start-secondary.sh --name client-secondary
```
## Opdatering Af Instanser (Maintenance)
```console
## Logning og overvågning
```console
pm2 logfiler
```
```console
pm2 monit
```
## Updating Instances (Maintenance)
Code changes need to be deployed to the API instances from time to time. It can be a rolling update or a manual update. The later is essential when changing dependencies or adding enviroment variables.
> [!DANGER] The automated pipelines are not handling dependencies updates at the minute. We need to do a manual update before any deployment pipeline runs.
### 1. Manual Updates - Used for updating dependencies, env variables.
1. Stop all instances
```console
pm2 stop all
```
2. Install or update dependencies
3. Start Instances
```console
pm2 start all --update-env && pm2 logs
```
### 2. Rolling updates - Used for logical changes to code.
```console
pm2 reload all --update-env && pm2 logs
```
> [!NOTE] We are handling rolling updates to code, logic, via pipelines. You should not need to run these commands. These are here for documentation.

100
docs/i18n/Danish/how-to-catch-outgoing-emails-locally.md Normal file
View File

@ -0,0 +1,100 @@
> **Bemærk:** Dette er et **valgfrit** trin og er kun påkrævet, når du arbejder med e-mail arbejdsgange
## Indledning
Nogle e-mailarbejdsgange kræver som opdatering af en brugers e-mail, at back-end api-serveren sender udgående e-mails. Et alternativ til at bruge en e-mail-tjenesteudbyder til at sende faktiske e-mails, Mailhog er et udviklerværktøj til e-mail-test, der vil fange e-mails sendt af din freeCodeCamp forekomst.
## Installerer MailHog
MailHog kan installeres på macOS, Windows og Linux.
- [Indledning](#introduction)
- [Installerer MailHog](#installing-mailhog)
- [Installerer MailHog på macOS](#installing-mailhog-on-macos)
- [Installerer MailHog på Windows](#installing-mailhog-on-windows)
- [Installerer MailHog på Linux](#installing-mailhog-on-linux)
- [Brug Af MailHog](#using-mailhog)
- [Nyttige Links](#useful-links)
### Installerer MailHog på macOS
Installér MailHog på macOS med [Homebrew](https://brew.sh/):
```bash
bryg installere mailhog
bryg tjenester starte mailhog
```
Ovenstående kommandoer vil starte en mailhog service i baggrunden.
Når installationen er færdig, kan du begynde at [bruge MailHog](#using-mailhog).
### Installerer MailHog på Windows
Download den seneste version af MailHog fra [MailHogs officielle arkiv](https://github.com/mailhog/MailHog/releases). Find og klik på linket til din Windows-version (32 eller 64 bit) og en .exe-fil vil blive hentet til din computer.
Når overførslen er færdig, skal du klikke for at åbne filen. En Windows firewall meddelelse kan vises, anmoder om adgangstilladelse til MailHog. En standard Windows kommandolinje prompt vil åbne, hvor MailHog vil køre, når firewall adgang er givet.
Luk MailHog ved at lukke kommandoprompten vinduet. For at starte MailHog igen, skal du klikke på MailHog eksekverbare (. xe) fil, der blev hentet i starten - det er ikke nødvendigt at downloade en ny MailHog installationsfil.
Start [med at bruge MailHog](#using-mailhog).
### Installerer MailHog på Linux
Installér først [Gå](https://golang.org).
Kør følgende kommandoer for at installere GO på Debian-baserede systemer som Ubuntu og Linux Mint.
```bash
sudo apt-get install golang
```
Kør følgende kommandoer for at installere GO på RPM-baserede systemer som CentOS, Fedora, Red Hat Linux, etc.
```bash
sudo dnf install golang
```
Alternativt kan du køre følgende kommandoer for at installere GO.
```bash
sudo yum install golang
```
Sæt nu stien til Go med følgende kommandoer.
```bash
echo "export GOPATH=$HOME/go" >> ~/.profile
echo 'export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin' >> ~/.profile
source ~/.profile
```
Endelig, indtaste kommandoerne nedenfor for at installere og køre MailHog.
```bash
go get github.com/mailhog/MailHog
sudo cp /home/$(whoami)/go/bin/MailHog /usr/local/bin/mailhog
mailhog
```
Start [med at bruge MailHog](#using-mailhog).
## Brug Af MailHog
Åbn en ny browserfane eller -vindue og gå til [http://localhost:8025](http://localhost:8025) for at åbne din MailHog indbakke, når MailHog installationen er afsluttet, og MailHog kører. Indbakken vises i lighed med skærmbilledet nedenfor.
![MailHog Skærmbillede 1](images/mailhog/1.jpg)
E-mails sendt fra din freeCodeCamp installation vises som nedenfor
![MailHog Skærmbillede 2](images/mailhog/2.jpg)
To faner, der giver dig mulighed for at se enten almindelig tekst eller kildeindhold, vil være tilgængelige, når du åbner en given e-mail. Sørg for at det almindelige tekstfaneblad er valgt som nedenfor.
![MailHog Skærmbillede 3](images/mailhog/3.jpg)
Alle links i e-mailen skal være klikbare og løse til deres URL.
## Nyttige Links
- Tjek [MailHog](https://github.com/mailhog/MailHog) depotet for yderligere oplysninger vedrørende MailHog. Yderligere oplysninger er også tilgængelige om brugerdefinerede MailHog konfigurationer.

199
docs/i18n/Danish/how-to-help-with-video-challenges.md Normal file
View File

@ -0,0 +1,199 @@
# Hvordan man kan hjælpe med videoudfordringer
Video udfordringer er en ny type udfordring i freeCodeCamp pensum.
En videoudfordring er en lille del af et videokursus i fuld længde om et bestemt emne. En video udfordring side indlejrer en YouTube-video. Hver challenge side har et enkelt multiple-choice-spørgsmål relateret til videoen. En bruger skal besvare spørgsmålet korrekt, før du flytter på den næste video udfordring i kurset.
De video udfordring sider er skabt af medlemmer af freeCodeCamp team. YouTube-videoer er også uploadet af medlemmer af freeCodeCamp teamet. Mange af videoudfordringerne har endnu ikke spørgsmål forbundet med dem.
Du kan hjælpe ved at oprette multiple choice spørgsmål relateret til video sektioner og tilføje spørgsmålene til markdown filer til videoudfordringerne.
## Udfordring Skabelon
Nedenfor er en skabelon af, hvordan udfordringen markdown filer ser ud.
````md
---
id: Unik identifikator (alfanumerisk, MongoDB_id)
title: Challenge Titel
challengeType: 11
videoId: 'YouTube videoId for video challenge'
---
## Beskrivelse
<section id='description'>
En valgfri beskrivelse med nyttige oplysninger relateret til videoen.
</section>
## Tests
<section id='tests'>
```yml
spørgsmål:
tekst: 'Spørgsmål'
svar:
- 'Svar En'
- 'Svar to'
- 'Svar tre'
løsning: 3
````
</section>
````
## Oprettelse af spørgsmål til videoudfordringer
### Få adgang til videoudfordringsmarkdown filer
Du kan finde markdown filer til videoudfordringer på følgende steder i læseplanen:
- [Dataanalyse med Python Kursus](https://github. om/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/08-data-analysis-with-python/data-analysis-with-python-course)
- [TensorFlow 2.0 Course](https://github. om/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/11-machine-learning-with-python/tensorflow)
- [Numpy Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/08-data-analysis-with-python/numpy)
- [How Neural Networks Work Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/11-machine-learning-with-python/how-neural-networks-work)
Vælg en challenge markdown-fil fra ovenstående muligheder.
### Skim gennem videoen, der er forbundet med udfordringen og opret et mutiple choice-spørgsmål
Find først video-id'et.
For eksempel, i følgende kode fra overskriften på en video challenge markdown fil, video-Id er "nVAaxZ34khk". På GitHub skal oplysningerne laves ud i tabelformat.
````
---
id: 5e9a093a74c4063ca6f7c14d titel: Dataanalyse Eksempel A challengeType: 11
videoId: nVAaxZ34khk
---
```
Dernæst skal du tilgå YouTube-videoen med den video-Id. URLen til videoen vil være:
https://www.youtube. om/watch?v=[videoId] (tilføj videoId til URL'en uden firkantede parenteser)
I eksemplet ovenfor er url https://www. outube.com/watch?v=nVAaxZ34khk
Skim YouTube-videoen med den videoId og tænk på et multiple choice-spørgsmål baseret på indholdet af videoen.
### Tilføj spørgsmålet til markdown filen
Du kan tilføje spørgsmålet lokalt eller direkte til GitHub interfacet. For at tilføje spørgsmålet lokalt, skal du [opsætte freeCodeCamp lokalt](how-to-setup-freecodecamp-locally.md). Du kan også finde filen på GitHub og klikke på redigeringsknappen for at tilføje spørgsmålet til højre i din browser.
Hvis et spørgsmål endnu ikke er blevet tilføjet til en bestemt videoudfordring, det vil have følgende standard spørgsmål:
```yml
spørgsmål:
tekst: ●
Spørgsmål
svar:
- ●
one
- ●
to
- ●
tre
løsning: 3
```
Opdater ordet “Spørgsmål” med dit spørgsmål. Opdater “en”, “to”, og “tre” med de mulige svar. Sørg for at opdatere løsningsnummeret, med hvilket svaret er korrekt. Du kan tilføje flere mulige svar ved hjælp af samme format. Spørgsmålet og svarene kan omringes med citationstegn.
#### Brug markdown til at formatere dit spørgsmål
Teksten i spørgsmålet fortolkes som markdown. Den enkleste måde at sikre, at det er formateret korrekt, er at starte spørgsmålet med `tekst: -`, sådan her:
```yml
spørgsmål:
tekst: Error
Spørgsmål
```
Så skal du sørge for, at dit spørgsmål er på en ny linje og indrykket et niveau mere end `tekst: ●`.
Den samme fremgangsmåde kan bruges til svarene, så hele spørgsmålet bliver til
```yml
spørgsmål:
Tekst
Spørgsmål
svar:
- ●
Første svar
- ●
Anden
- ●
Tredje
løsning: 2
```
Sørg for, at hvert svar er plausibelt, men der er kun ét rigtigt svar.
#### Brug af HTML
Spørgsmål og svar kan indeholde visse HTML-tags som `<br>` for en ny linje. HTML-tags skal bruges sparsomt, når spørgsmål ikke kan udtrykkes uden dem.
### Eksempler på spørgsmål
#### Eksempler uden HTML
````yml
spørgsmål:
tekst: ¤
Hvad logger denne JavaScript-kode på konsollen?
```js
console.log('god-verden');
````
Vælg et svar!
svar:
- Ž goddag *verden*
- Ž **goddag** verden
- ● hej verden løsning: 3
````
````yml
spørgsmål:
tekst: ¤
Hvad vil udskrive efter kørsel af denne kode:
```py
bredde = 15
højde = 12.
print(højde/3)
````
svar:
- | 39
- | 4
- Ž 4.0
- ● 5,0
- ● 5 løsning: 3
````
#### Eksempel med HTML-
``yml
spørgsmål:
tekst: ¤
Hvad vil udskrive efter kørsel af denne kode:
<pre><code>bredde = 15<br>højde = 12.<br>print(højde/3)<code></pre>
svar:
- Økologisk
39
- Økologisk
4
- Økologisk
4.
- ¤
5.
- ●
5
løsning: 3
````
Det sidste eksempel viser, at HTML kan bruges, men at det ikke er så læsbar som den version uden det.
For flere eksempler, kan du se på markdown filer til følgende video kursus. Alle udfordringerne har allerede spørgsmål: [Python for Everybody Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/07-scientific-computing-with-python/python-for-everybody)
## Åbn en pull-anmodning
Når du har oprettet et eller flere spørgsmål, kan du forpligte ændringerne til en ny filial og [åbne en pull request](how-to-open-a-pull-request.md).

179
docs/i18n/Danish/how-to-open-a-pull-request.md Normal file
View File

@ -0,0 +1,179 @@
# Sådan åbnes en Pull Request (PR)
En pull-anmodning gør det muligt at sende ændringer fra din gaffel på GitHub til freeCodeCamp.org's hovedarkiv. Når du er færdig med at foretage ændringer i koden, eller kodning udfordringer, bør du følge disse retningslinjer for at sende en PR.
## Forbered en god PR titel
Vi anbefaler at bruge [konventionel titel og beskeder](https://www.conventionalcommits.org/) til commits og pull request. Konventionen har følgende format:
> `<type>([valgfrit område(r)]): <description>`
>
> For eksempel:
>
> `fix(learn): tests for do...while loop challenge`
Når du åbner en Pull Request(PR), kan du bruge nedenstående til at afgøre typen, scope (valgfri) og beskrivelse.
**Type:**
| Type | Hvornår skal du vælge |
|:---- |:-------------------------------------------------------------------------------------- |
| fix | Ændret eller opdateret / forbedret funktionalitet, tests, verbiage af en lektion, etc. |
| feat | Kun hvis du tilføjer ny funktionalitet, test osv. |
| øm | Ændringer, der ikke er relateret til kode, tests eller verbiage af en lektion. |
| docs | Ændringer til `/docs` mappe eller de bidragende retningslinjer osv. |
**Anvendelsesområde:**
Du kan vælge et anvendelsesområde fra [denne liste af etiketter](https://github.com/freeCodeCamp/freeCodeCamp/labels?q=scope).
**Beskrivelse:**
Behold den kort (mindre end 30 tegn) og enkel, kan du tilføje flere oplysninger i PR beskrivelse boksen og kommentarer.
Nogle eksempler på gode PRs titler ville være:
- `fix(a11y): forbedret søgebjælke kontrast`
- `feat: tilføj flere test til html og css udfordringer`
- `fix(api,client): forhindre CORS fejl ved formularindsendelse`
- `docs(i18n): Kinesisk oversættelse af lokal opsætning`
## Foreslår en pull-anmodning
1. Når redigeringerne er blevet begået, vil du blive bedt om at oprette en pull-anmodning på din gaffels GitHub side.
![Billede - Sammenlign pull request prompt på GitHub](./images/github/compare-pull-request-prompt.png)
2. Som standard skal alle pull anmodninger være imod freeCodeCamp hovedrepo, `master` filial.
Sørg for, at din grundgaffel er indstillet til freeCodeCamp/freeCodeCamp når du rejser en Pull-anmodning.
![Image - Sammenligning af gafler når du laver en pull request](./images/github/comparing-forks-for-pull-request.png)
3. Indsend pull anmodning fra din filial til freeCodeCamp's `master` filial.
4. I kroppen af din PR indeholde en mere detaljeret oversigt over de ændringer, du har foretaget, og hvorfor.
- Du vil blive præsenteret for en pull request skabelon. Dette er en tjekliste, som du skal have fulgt før du åbner pull anmodningen.
- Udfyld detaljerne, som du finder passende. Disse oplysninger vil blive gennemgået, og anmelderne vil afgøre, om din pull-anmodning er accepteret eller ej.
- Hvis PR er beregnet til at behandle en eksisterende GitHub Issue så ved udgangen af din PR's beskrivelse organ, brug søgeordet _Lukker_ med issue nummer til [automatisk lukke dette problem, hvis PR er accepteret og fusioneret](https://help.github.com/en/articles/closing-issues-using-keywords).
> Eksempel: `Lukker #123` lukker problemet 123
5. Angiv, om du har testet på en lokal kopi af webstedet eller ej.
Dette er meget vigtigt, når du foretager ændringer, der ikke bare redigerer tekstindhold som dokumentation eller en challenge beskrivelse. Eksempler på ændringer, der har brug for lokal test omfatter JavaScript, CSS, eller HTML, der kan ændre funktionalitet eller layout af en side.
## Tilbagemelding ved pull anmodninger
> Tillykke! :tada: når du laver en PR og takker meget for at have brugt tid på at bidrage.
Vores moderatorer vil nu tage et kig og efterlade dig feedback. Vær tålmodig med de andre moderatorer og respektere deres tid. Alle pull anmodninger gennemgås når tiden er inde.
Hvis du har brug for hjælp, så diskuter i [bidragsyderes chatrum](https://gitter.im/FreeCodeCamp/Contributors), er vi mere end glade for at hjælpe dig.
> [!TIP] Hvis du skal bidrage med flere pull requests, Vi anbefaler, at du læser [foretage ændringer og synkroniserer](https://contribute.freecodecamp.org/#/how-to-setup-freecodecamp-locally?id=making-changes-locally) retningslinjer for at undgå at skulle slette din gaffel.
## Konflikter på en pull-anmodning
Konflikter kan opstå, fordi mange bidragsydere arbejder på lageret, og ændringer kan ødelægge din PR, som afventer en gennemgang og sammenfletning.
Oftere end ikke kan du ikke kræve en rebase, fordi vi squash alle forpligtelser, men hvis der anmodes om en rebase her er, hvad du skal gøre.
### For sædvanlige fejlrettelser og funktioner
Når du arbejder på almindelige fejl og funktioner på vores udviklingsgren `master`, er du i stand til at foretage en simpel rebase:
1. Rebase din lokale kopi:
```console
git checkout <pr-branch>
git pull --rebase upstream master
```
2. Løs eventuelle konflikter og tilføj / rediger commits
```console
# Enten
git tilføj .
git commit -m "chore: resolve conflicts"
# Or
git add .
git commit --amend --no-edit
```
3. Skub dine ændringer tilbage til PR
```console
git push --force oprindelse <pr-branch>
```
### For kommende pensum og funktioner
Når du arbejder på funktioner til vores kommende curriculum `next-*` grene, har du gjort en kirsebær pluk:
1. Sørg for, at din opstrøm synkroniseres med din lokale:
```console
git checkout master
git henter --all --prune
git checkout next-python-projects
git reset --hard upstream/next-python-projects
```
2. Tag backup
a. Slet enten din lokale filial efter at have taget en sikkerhedskopi (hvis du stadig har den lokalt):
```console
git checkout <pr-branch-name>
# eksempel:
# git checkout feat/add-numpy-video-spørgsmål
git checkout -b <backup-branch-name>
# eksempel:
# git checkout -b backup-feat/add-numpy-video-spørgsmål
git branch -D <pr-branch-name>
```
b. Eller bare en sikkerhedskopi af din pr- gren (hvis du ikke har den lokalt):
```console
git checkout -b <backup-branch-name> origin/<pr-branch-name>
# eksempel:
# git checkout -b backup-feat/add-numpy-video-spørgsmål origin/feat/add-numpy-video-spørgsmål
```
4. Start med en ren skive:
```console
git checkout -b <pr-branch-name> next-python-projekter
git cherry-pick <commit-hash>
```
5. Løs eventuelle konflikter og oprydning, installer kør tests
```console
npm run clean
npm ci
npm run test:curriculum --superblock=<superblock-name>
# eksempel:
# npm run test:curriculum --superblock=python-for-all
```
6. Hvis alt ser godt ud til at skubbe tilbage til PR
```console
git push --force oprindelse <pr-branch-name>
```

546
docs/i18n/Danish/how-to-setup-freecodecamp-locally.md Normal file
View File

@ -0,0 +1,546 @@
Følg disse retningslinjer for opsætning af freeCodeCamp lokalt på dit system. Dette anbefales på det kraftigste, hvis du ønsker at bidrage regelmæssigt.
For nogle af de bidrag arbejdsgange, du har brug for at have freeCodeCamp kører lokalt. For eksempel, forhåndsvisning kodning udfordringer eller fejlfinding og fastsættelse af fejl i kodebasen.
> [!TIP] Hvis du ikke er interesseret i at oprette freeCodeCamp lokalt, overveje at bruge Gitpod, et gratis online dev miljø.
>
> [![Åbn i Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
>
> (Starter et klar-til-kode dev miljø til freeCodeCamp i din browser.)
## Forbered din lokale maskine
Start med at installere forudsætningssoftware til dit operativsystem.
Vi støtter primært udvikling på **\*nix** systemer. Vores medarbejdere og community bidragsydere arbejder regelmæssigt med kodebase ved hjælp af værktøjer, der er installeret på Ubuntu og macOS.
Vi understøtter også Windows 10 via WSL2, som du kan forberede ved at [læse denne guide](/how-to-setup-wsl).
Nogle medlemmer af fællesskabet udvikler også på Windows 10 indbygget med Git til Windows (Git Bash), og andre værktøjer installeret på Windows. Vi har ikke officiel støtte til en sådan opsætning på dette tidspunkt, vi anbefaler at bruge WSL2 i stedet.
**Forudsætninger:**
| Forudsætning | Version | Noter |
| --------------------------------------------------------------------------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Node.js](http://nodejs.org) | `12. x` | [LTS Skema](https://github.com/nodejs/Release#release-schedule) |
| npm (kommer sammen med Node) | `6. x` | Har ikke LTS-udgivelser, vi bruger versionen bundtet med Node LTS |
| [MongoDB Community Server](https://docs.mongodb.com/manual/administration/install-community/) | `3.6` | [Udgivelsesnoter](https://docs.mongodb.com/manual/release-notes/), Note: We are currently on `3.6`, an [upgrade is planned](https://github.com/freeCodeCamp/freeCodeCamp/issues/18275). |
> [!DANGER] Hvis du har en anden version, skal du installere den anbefalede version. Vi kan kun støtte installationsproblemer for anbefalede versioner. Se [fejlfinding](#troubleshooting) for detaljer.
Hvis Node.js allerede er installeret på din maskine, skal du køre følgende kommandoer for at validere versionerne:
```console
node -v
npm -v
```
> [!TIP] Vi anbefaler stærkt opdatering til de seneste stabile udgivelser af ovennævnte software, også kendt som Langsigtet Support (LTS) udgivelser.
Når du har installeret forudsætningerne, skal du forberede dit udviklingsmiljø. Dette er almindeligt for mange udviklingsarbejdsgange, og det behøver I kun at gøre én gang.
**Følg disse trin for at få dit udviklingsmiljø klar:**
1. Installer [Git](https://git-scm.com/) eller din favorit Git klient, hvis du ikke allerede har. Opdater til den nyeste version; den version, der kom bundtet med dit operativsystem, kan være forældet.
2. (Valgfri, men anbefales) [Opsæt en SSH-nøgle](https://help.github.com/articles/generating-an-ssh-key/) for GitHub.
3. Installer en kodeeditor efter eget valg.
Vi anbefaler stærkt at bruge [Visual Studio Code](https://code.visualstudio.com/) eller [Atom](https://atom.io/). Disse er store, gratis og open source kode editorer.
4. Konfigurer linting til din kodeeditor.
Du skal have [ESLint kørende i din editor](http://eslint.org/docs/user-guide/integrations.html), og det vil fremhæve noget, der ikke overholder [freeCodeCamp's JavaScript Style Guide](http://forum.freecodecamp.org/t/free-code-camp-javascript-style-guide/19121).
> [!TIP] Ignorér venligst ikke nogen lining-fejl. De er beregnet til at **hjælpe** dig og sikre en ren og enkel kodebase.
## Gaffel af depotet på GitHub
[Forking](https://help.github.com/articles/about-forks/) er et skridt, hvor du får din egen kopi af freeCodeCamp's hovedlager (alias _repo_) på GitHub.
Dette er vigtigt, da det giver dig mulighed for at arbejde på din egen kopi af freeCodeCamp på GitHub, eller for at downloade (klon) dit repository til at arbejde på lokalt. Senere, vil du være i stand til at anmode om ændringer til at blive trukket ind i hoveddepotet fra din gaffel via en pull request (PR).
> [!TIP] The main repository at `https://github.com/freeCodeCamp/freeCodeCamp` is often referred to as the `upstream` repository. (Automatic Copy)
>
> Din gaffel på `https://github.com/YOUR_USER_NAME/freeCodeCamp` er ofte omtalt som `oprindelse` -lageret.
**Følg disse trin for at gaffel `https://github.com/freeCodeCamp/freeCodeCamp` -lageret:**
1. Gå til freeCodeCamp på GitHub: <https://github.com/freeCodeCamp/freeCodeCamp>
2. Klik på "Fork"-knappen i øverste højre hjørne af grænsefladen ([Flere detaljer Her](https://help.github.com/articles/fork-a-repo/))
3. Efter at depotet er blevet forked, vil du blive ført til din kopi af freeCodeCamp repository på `https://github.com/YOUR_USER_NAME/freeCodeCamp`
<details>
<summary>
Sådan gaffel freeCodeCamp på GitHub (skærmbillede)
</summary>
<br>
<img src="https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/master/docs/images/github/how-to-fork-freeCodeCamp.gif" alt="Sådan gaffel freeCodeCamp på GitHub" />
</details>
## Klon din gaffel fra GitHub
[Kloning](https://help.github.com/articles/cloning-a-repository/) er hvor du **downloade** en kopi af et depot fra en `fjern-` -placering, der enten ejes af dig eller af en anden. I dit tilfælde er denne fjernplacering din `gaffel` af freeCodeCamp's repository som skal være tilgængelig på `https://github.com/YOUR_USER_NAME/freeCodeCamp`.
Kør disse kommandoer på din lokale maskine:
1. Åbn en terminal / Kommandoprompt / Shell i din projektmappe
_dvs.: `/yourprojectsdirectory/`_
2. Klon din gaffel af freeCodeCamp, erstatter `YOUR_USER_NAME` med dit GitHub brugernavn
```console
git clone --depth=1 https://github.com/YOUR_USER_NAME/freeCodeCamp.git
```
Dette vil downloade hele freeCodeCamp repository til din projektmappe.
Bemærk: `--depth=1` skaber en overfladisk klon af din gaffel, med kun den seneste historie/commit.
## Konfigurer synkronisering fra overordnet
Nu hvor du har downloadet en kopi af din gaffel, skal du oprette en `upstream` fjernbetjening til det overordnede arkiv.
[Som nævnt tidligere](#fork-the-repository-on-github)er hovedlageret henvist til `upstream` -lageret. Din gaffel refereret til som `oprindelse` -lageret.
Du skal have en reference fra din lokale klon til `upstream` -depotet ud over `oprindelse` -depotet. Dette er så du kan synkronisere ændringer fra hoveddepotet uden krav om gaffel og kloning gentagne gange.
1. Skift mappe til den nye freeCodeCamp mappe:
```console
cd freeCodeCamp
```
2. Tilføj en fjernreference til det vigtigste freeCodeCamp repository:
```console
git fjernbetjening tilføj opstream https://github.com/freeCodeCamp/freeCodeCamp.git
```
3. Sørg for, at konfigurationen ser korrekt ud:
```console
git remote -v
```
Outputtet skal se ud som nedenfor:
```console
oprindelse https://github.com/YOUR_USER_NAME/freeCodeCamp.git (fetch)
oprindelse https://github.com/YOUR_USER_NAME/freeCodeCamp.git (push)
upstream https://github.com/freeCodeCamp/freeCodeCamp.git (fetch)
upstream https://github.com/freeCodeCamp/freeCodeCamp.git (push)
```
## Kører freeCodeCamp lokalt
Nu hvor du har en lokal kopi af freeCodeCamp, kan du følge disse instruktioner for at køre det lokalt. Dette vil give dig mulighed for at:
- Forhåndsvisning redigerer til sider, som de vises på læringsplatformen.
- Arbejdet med UI-relaterede spørgsmål og forbedringer.
- Fejlsøg og løse problemer med applikationsservere og klient apps.
Hvis du løber ind i problemer, skal du først udføre en websøgning efter dit problem og se, om det allerede er blevet besvaret. Hvis du ikke kan finde en løsning, søg venligst vores [GitHub issues](https://github.com/freeCodeCamp/freeCodeCamp/issues) side for en løsning og rapporter problemet, hvis det endnu ikke er blevet rapporteret.
Og som altid, er velkommen til at hoppe videre til vores [Contributors Chat room på Gitter](https://gitter.im/FreeCodeCamp/Contributors) eller [vores Discord server](https://discord.gg/6vJYm9V), for hurtige forespørgsler.
> [!TIP] Du kan springe kører freeCodeCamp lokalt, hvis du blot redigerer filer. For eksempel, udføre en `rebase`eller løse `fusionere` konflikter.
>
> Du kan altid vende tilbage til denne del af vejledningen senere. Du bør **kun** springe dette trin, hvis du ikke behøver at køre apps på din maskine.
>
> [Spring over for at foretage ændringer](#making-changes-locally).
### Indstil afhængigheder
#### Trin 1: Opsæt miljøvariablen fil
Standard API-nøgler og miljøvariabler gemmes i filen `sample.env`. Denne fil skal kopieres til en ny fil med navnet `.env` , der er tilgået dynamisk under installationstrinnet.
```console
# Opret en kopi af "sample.env" og navngiv den ".env".
# Udfyld den med de nødvendige API-nøgler og hemmeligheder:
# macOS / Linux
cp sample. nv .env
# Windows
kopier sample.env .env
```
Nøglerne i filen `.env` er _ikke_ forpligtet til at blive ændret for at køre appen lokalt. Du kan efterlade standardværdierne kopieret over fra `sample.env` som-is.
> [!TIP] Husk på, hvis du vil bruge tjenester som Forfatter eller Algolia, du skal købe dine egne API-nøgler til disse tjenester og redigere poster i overensstemmelse hermed i `. nv` fil.
#### Trin 2: Installer afhængigheder
Dette trin vil installere de afhængigheder, der kræves for at programmet skal køre:
```console
npm ci
```
#### Trin 3: Start MongoDB og seed databasen
Før du kan køre programmet lokalt, skal du starte MongoDB-tjenesten.
> [!BEMÆRK] Medmindre du har MongoDB kørende i en anden opsætning end standarden, den URL , der er gemt som værdien `MONGOHQ_URL` i `. nv` filen skal virke fint. Hvis du bruger en brugerdefineret konfiguration, skal du ændre denne værdi efter behov.
Start MongoDB-serveren i en separat terminal:
- På macOS & Ubuntu:
```console
mongod
```
- I Windows skal du angive den fulde sti til `mongod` binær
```console
"C:\Program Files\MongoDB\Server\3.6\bin\mongod"
```
Sørg for at erstatte `3.6` med den version, du har installeret
> [!TIP] Du kan undgå at skulle starte MongoDB hver gang ved at installere det som en baggrundstjeneste. Du kan [lære mere om det i deres dokumentation for dit operativsystem](https://docs.mongodb.com/manual/administration/install-community/)
Dernæst lad os se databasen. I dette trin kører vi nedenstående kommando, der udfylder MongoDB-serveren med nogle oprindelige datasæt, der kræves af tjenester. Disse omfatter bl.a. et par ordninger.
```console
npm løberfrø
```
#### Trin 4: Start freeCodeCamp klient ansøgning og API server
Du kan nu starte API-serveren og klientprogrammerne.
```console
npm kør udvikling
```
Denne enkelt kommando vil affyre alle de tjenester, herunder API-serveren og klientapplikationer, der er tilgængelige for dig at arbejde på.
> [!BEMÆRK] Når du er klar, skal du åbne en webbrowser og **besøge <http://localhost:8000>**. Hvis app'en indlæser, tillykke – du er alle indstillet! Du har nu en kopi af freeCodeCamp's hele læringsplatform, der kører på din lokale maskine.
> [!TIP] API-serveren serverer API'er på `http://localhost:3000`. Gatsby-appen betjener klientprogrammet på `http://localhost:8000`
> Hvis du besøger <http://localhost:3000/explorer> bør du se de tilgængelige API'er.
## Log ind med en lokal bruger
Din lokale opsætning udfylder automatisk en lokal bruger i databasen. Klik på knappen `Log ind` vil automatisk godkende dig i den lokale applikation.
Men adgang til brugerporteføljen side er lidt vanskelig. Under udvikling Gatsby overtager betjeningen af klientsiden sider og dermed vil du få en `404` side for brugerporteføljen, når du arbejder lokalt.
Du skal blot klikke på **"Preview Custom 404 Page"** knappen vil videresende dig til den korrekte side.
<details>
<summary>
Sådan logger du på, når du arbejder lokalt (skærmbillede)
</summary>
<br>
<img src="https://user-images.githubusercontent.com/29990697/71541249-f63cdf00-2923-11ea-8a85-cefb6f9c9977.gif" alt="Sådan logger du på, når du arbejder lokalt" />
</details>
## Foretager ændringer lokalt
Du kan nu foretage ændringer i filer og forpligte dine ændringer til din lokale klon af din gaffel.
Følg disse trin:
1. Validér at du er på `master` grenen:
```console
git status
```
Du bør få et output som dette:
```console
På grenmaster
Din gren er opdateret med 'oprindelse/master'.
intet at begå, arbejdsmappe ren
```
Hvis du ikke er på master eller din arbejdsmappe ikke er ren, skal du løse udestående filer/commits og checkout `master`:
```console
git checkout master
```
2. Synkroniser de seneste ændringer fra freeCodeCamp upstream `master` -grenen til din lokale hovedgren:
> [!ADVARSEL] Hvis du har en udestående pull-anmodning fra `master-` gren af din gaffel, vil du miste dem i slutningen af dette trin.
>
> Du bør sikre, at din pull-anmodning bliver flettet af en moderator, før du udfører dette trin. For at undgå dette scenarie, bør du **altid** arbejde på en anden gren end `master`.
Dette trin **vil synkronisere de seneste ændringer** fra freeCodeCamps hovedlager. Det er vigtigt, at du genbaserer din gren på toppen af den seneste `upstream/master` så ofte som muligt for at undgå konflikter senere.
Opdater din lokale kopi af freeCodeCamp upstream-depotet:
```console
git hente opstrøms
```
Hårdt nulstille din hovedfilial med freeCodeCamp master:
```console
git reset --hard upstream/master
```
Skub din hovedgren til din oprindelse for at få en ren historik på din gaffel på GitHub:
```console
git push origin master --force
```
Du kan validere din nuværende master matcher upstream/master ved at udføre en diff:
```console
git diff opstrøm/master
```
Den resulterende output skal være tom.
3. Opret en ny ny filial:
At arbejde på en separat gren for hvert problem hjælper dig med at holde din lokale arbejdskopi ren. Du bør aldrig arbejde på `master`. Dette vil jage din kopi af freeCodeCamp og du kan være nødt til at starte forfra med en frisk klon eller gaffel.
Kontroller, at du er på `master` som forklaret tidligere, og filial derfra:
```console
git checkout -b fix/update-guide-for-xyz
```
Dit filialnavn skal starte med en `fix/`, `feat/`, `docs/`, osv. Undgå at bruge issue numre i filialer. Hold dem korte, meningsfulde og unikke.
Nogle eksempler på gode filialnavne er:
```md
fix/update-challenges-for-react
fix/update-guide-for-html-css
fix/platform-bug-sign-in-issues
feat/add-guide-article-for-javascript
translate/add-spanish-basic-html
```
4. Rediger sider og arbejde med kode i din foretrukne teksteditor.
5. Når du er tilfreds med de ændringer, bør du eventuelt køre freeCodeCamp lokalt for at få vist ændringerne.
6. Sørg for at rette eventuelle fejl og kontrollere formateringen af dine ændringer.
7. Tjek og bekræft de filer, du opdaterer:
```console
git status
```
Dette bør vise en liste over `unstaged` filer, som du har redigeret.
```console
På grenfunktion/dokumentation
Din gren er opdateret med 'upstream/feat/documentation'.
Ændringer ikke iscenesat for commit:
(brug "git add/rm <file>... for at opdatere hvad der vil blive indgået)
(brug "git checkout -- <file>. ." at kassere ændringer i arbejdsmappen)
ændret: KONTROLLING. d
ændret: docs/README.md
ændret: docs/how-to-setup-freecodecamp-locally. d
ændret: docs/how-to-work-on-guide-articles.md
...
```
8. Trin ændringerne og lav en forpligtelse:
I dette trin bør du kun markere filer, som du har redigeret eller tilføjet dig selv. Du kan udføre en nulstilling og løse filer, som du ikke har til hensigt at ændre, hvis det er nødvendigt.
```console
git tilføj sti/til/min/ændret/file.ext
```
Eller du kan tilføje alle de `unstaged` filer til iscenesættelse:
```console
git tilføj .
```
Kun de filer, der blev flyttet til iscenesættelsesområdet vil blive tilføjet, når du laver en forpligtelse.
```console
git status
```
Output:
```console
På grenfunktion/dokumentation
Din gren er opdateret med 'upstream/feat/documentation'.
Ændringer, der skal foretages:
(brug "git reset HEAD <file>..." til unstage)
ændret: CONTRIBUTING.md
ændret: docs/README.md
ændret: docs/how-to-setup-freecodecamp-locally.md
ændret: docs/how-to-work-on-guide-articles.md
```
Nu kan du begå dine ændringer med en kort besked som så:
```console
git commit -m "fix: min korte commit besked"
```
Nogle eksempler:
```md
fix: opdatering guide artikel til Java - for loop
feat: Tilføj guide artikel for alexa færdigheder
```
Valgfri:
Vi anbefaler stærkt at lave en konventionel begå besked. Dette er en god praksis, som du vil se på nogle af de populære Open Source repositories. Som udvikler opfordrer dette dig til at følge standard praksis.
Nogle eksempler på konventionelle begå meddelelser er:
```md
fix: update HTML guide article
fix: update build scripts for Travis-CI
feat: add article for JavaScript hoisting
docs: update contributing guidelines
```
Behold disse kort, ikke mere end 50 tegn. Du kan altid tilføje yderligere oplysninger i beskrivelsen af commit beskeden.
Dette tager ikke længere tid end en ukonventionel meddelelse som 'opdateringsfil' eller 'tilføj index.md'
Du kan lære mere om, hvorfor du skal bruge konventionelle commits [her](https://www.conventionalcommits.org/en/v1.0.0-beta.2/#why-use-conventional-commits).
9. Hvis du indser, at du har brug for at redigere en fil eller opdatere commit beskeden efter at have lavet en commit kan du gøre det efter redigering af filerne med:
```console
git commit -- amend
```
Dette vil åbne en standard teksteditor som `nano` eller `vi` , hvor du kan redigere commit besked titel og tilføj/redigere beskrivelsen.
10. Dernæst kan du skubbe dine ændringer til din gaffel:
```console
git push-oprindelse filial/navn-her
```
## Foreslå en Pull Request (PR)
Når du har foretaget dine ændringer, så tjek her for [hvordan du åbner en Pull Request](how-to-open-a-pull-request.md).
## Hurtige kommandoer reference
En hurtig reference til de kommandoer, som du får brug for, når du arbejder lokalt.
| kommando | beskrivelse |
| -------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| `npm ci` | Installerer / geninstaller alle afhængigheder og bootstraps de forskellige tjenester. |
| `npm løberfrø` | Fortolker alle de challenge markdown filer og indsætter dem i MongoDB. |
| `npm kør udvikling` | Starter freeCodeCamp API Server og klient applikationer. |
| `npm test` | Kør alle JS-test i systemet, herunder klient, server, lint og challenge tests. |
| `npm run test:client` | Kør klient test suite. |
| `npm kørselstest:curriculum` | Kør curriculum test suite. |
| `npm run test: curriculum --block='Basic HTML og HTML5'` | Test en specifik blok. |
| `npm run test:curriculum --superblock='responsive-web-design'` | Test en specifik SuperBlock. |
| `npm kørsel test-curriculum-fuld-output` | Kør curriculum test suite, uden at gemme efter den første fejl |
| `Npm kør test:server` | Kør serverens testsuite. |
| `npm run e2e` | Kør Cypressen slutter med at afslutte tests. |
| `npm kør ren` | Afinstallerer alle afhængigheder og rydder op caches. |
## Fejlfinding
### Problemer med installation af de anbefalede forudsætninger
Vi udvikler jævnligt på de nyeste eller mest populære operativsystemer som macOS 10.15 eller senere, Ubuntu 18.04 eller senere og Windows 10 (med WSL2).
Det anbefales at forske i dit specifikke spørgsmål om ressourcer såsom Google, Stack Overflow og Stack Exchange. Der er en god chance for, at nogen har stået over for det samme problem, og der er allerede et svar på din specifikke forespørgsel.
Hvis du er på et andet operativsystem og/eller stadig er ved at løbe ind i problemer, se [få hjælp](#getting-help).
> [!WARNING]
>
> Undgå at oprette GitHub problemer for forudsætningsproblemer. De er uden for dette projekts anvendelsesområde.
### Problemer med brugergrænseflade, skrifttyper, opbyg fejl mv.
Hvis du står over for problemer med UI, Skrifttyper eller se bygger fejl en oprydning kan være nyttig:
```console
npm run clean
npm ci
npm run seed
npm run develop
```
ELLER
Brug genvejen
```
npm run clean-and-develop
```
Hvis du fortsat står over for problemer med bygningen, anbefales det at rense arbejdsområdet.
Brug `git clean` i interativ tilstand:
```
git clean -ifdX
```
<details>
<summary>
Hvordan man renser git usporet filer (skærmbillede)
</summary>
<br>
<img src="https://user-images.githubusercontent.com/1884376/94270515-ca579400-ff5d-11ea-8ff1-152cade31654.gif" alt="Hvordan man renser git usporet filer" />
</details>
### Problemer med API, Login, Challenge Indsendelser, osv.
Hvis du ikke kan logge på, og i stedet ser du et banner med en fejlmeddelelse om, at det vil blive rapporteret til freeCodeCamp, dobbelttjek venligst at din lokale port `3000` ikke er i brug af et andet program.
**På Linux / MacOS / WSL på Windows - Fra Terminal:**
```console
netstat -ab ¤ grep "3000"
tcp4 0 0 0.0.0.0:3000 DESKTOP LISTEN
```
**På Windows - Fra Forhøjet PowerShell:**
```powershell
netstat -ab ¤ Select-String "3000"
TCP 0.0.0.0.0: 3000 DESKTOP LISTENING
```
### Problemer med installation af afhængigheder
Hvis du får fejl under installation af afhængigheder, sørg for, at du ikke befinder dig i et begrænset netværk, eller at dine firewall-indstillinger ikke forhindrer dig i at få adgang til ressourcer.
Første gang opsætningen kan tage et stykke tid afhængigt af din netværks båndbredde. Vær tålmodig, og hvis du stadig sidder fast, vi komprimeret ved hjælp af GitPod i stedet for en offline opsætning.
## Få Hjælp
Hvis du sidder fast og har brug for hjælp, Lad os vide ved at spørge i kategorien ['Bidragydere' på vores forum](https://forum.freecodecamp.org/c/contributors) eller [Bidragyderne chatrum](https://gitter.im/FreeCodeCamp/Contributors) på Gitter.
Der kan være en fejl i konsollen i din browser eller i Bash / Terminal / Kommandolinje, der vil hjælpe med at identificere problemet. Giv denne fejlmeddelelse i din problembeskrivelse, så andre lettere kan identificere problemet og hjælpe dig med at finde en løsning.

129
docs/i18n/Danish/how-to-setup-wsl.md Normal file
View File

@ -0,0 +1,129 @@
# Konfigurer freeCodeCamp på Windows Undersystem til Linux (WSL)
> [!BEMÆRK] Før du følger disse instruktioner, skal du sørge for, at dit system opfylder kravene
>
> **WSL 2**: Windows 10 64-bit (Version 2004, Byg 19041 eller højere) - tilgængelig for alle distributioner, herunder Windows 10 Home.
>
> **Docker Desktop til Windows**: Se de respektive krav til [Windows 10 Pro](https://docs.docker.com/docker-for-windows/install/#system-requirements) og [Windows 10 Home](https://docs.docker.com/docker-for-windows/install-windows-home/#system-requirements)
Denne vejledning dækker nogle fælles trin med opsætningen af WSL2. Når nogle af de fælles problemer med WSL2 er løst, du bør være i stand til at følge vores lokale setup guide til at arbejde med freeCodeCamp på Windows, der kører en WSL distro som Ubuntu.
## Aktiver WSL
Følg instruktionerne på den [officielle dokumentation](https://docs.microsoft.com/en-us/windows/wsl/install-win10) for at installere WSL1 og efterfulgt af opgradering til WSL2.
## Install Ubuntu
1. Vi anbefalede at bruge Ubuntu-18.04 eller derover med WSL2.
> [!BEMÆRK]
>
> Mens du kan bruge andre ikke-debiske baserede distros, de alle kommer med deres egen gotchas og er uden for rækkevidden af denne guide.
2. Opdater afhængighederne for OS
```console
sudo apt update
sudo apt upgrade -y
# oprydning
sudo apt autoremove -y
```
## Opsæt Git
Git leveres forudinstalleret med Ubuntu 18.04, verificer at din Git-version med `git --version`.
```output
~
~git --version
git version 2.25.1
```
(Valgfri, men anbefales) Du kan nu gå videre til [opsætning af dine ssh-nøgler](https://help.github.com/articles/generating-an-ssh-key) med GitHub.
## Installerer en kodeeditor
Vi anbefaler stærkt at installere [Visual Studio Code](https://code.visualstudio.com) på Windows 10. Det har stor støtte til WSL og installerer automatisk alle de nødvendige udvidelser på din WSL distro.
Essentielt vil du redigere og gemme din kode på Ubuntu-18.04 med VS-kode installeret på Windows.
## Installerer Docker- Skrivebord
**Docker Desktop til Windows** giver dig mulighed for at installere og køre database og tjenester som MongoDB, NGINX osv. Dette er nyttigt for at undgå almindelige faldgruber med at installere MongoDB eller andre tjenester direkte på Windows eller WSL2.
Følg instruktionen på den [officielle dokumentation](https://docs.docker.com/docker-for-windows/install) og installer Docker Desktop til din Windows-distribution.
Der er nogle minimale hardwarekrav til den bedste oplevelse.
## Indstil Docker- skrivebord til WSL
Når Docker Desktop er installeret, [følg disse instruktioner](https://docs.docker.com/docker-for-windows/wsl) og konfigurér den til at bruge Ubuntu-18.04 installation som en backend.
Dette gør det, så containerne kører på WSL side i stedet for at køre på Windows. Du vil kunne tilgå tjenesterne via `http://localhost` på både Windows og Ubuntu.
## Installer MongoDB fra Docker Hub
Når du har konfigureret Docker Desktop til at arbejde med WSL2, skal du følge disse trin for at starte en MongoDB tjeneste:
1. Start en ny Ubuntu-18.04 terminal
2. Træk `MongoDB 3.6` fra dockerhub
```console
docker pull mongo:3
```
3. Start MongoDB-tjenesten på port `27017`og konfigurér den til automatisk at køre på systemgenstart
```console
docker run - it \
- v mongodata:/data/db \
- p 27017:27017 \
--name mongodb \
--restart unless-stopped \
-d mongo:3
```
4. Du kan nu få adgang til tjenesten fra både Windows eller Ubuntu på `mongodb://localhost:27017`.
## Installerer node.js og npm
Vi anbefaler, at du installerer LTS-udgivelsen til Node.js med en node version manager - [nvm](https://github.com/nvm-sh/nvm#installing-and-updating).
Når det er installeret bruge disse kommandoer til at installere og bruge Node.js version efter behov
```console
nvm install --lts
# OR
# nvm install <version>
nvm install 14
# Usage
# nvm use <version>
nvm use 12
```
Node.js kommer bundtet med `npm`, du kan opdatere til de nyeste versioner af `npm` med:
```console
npm install -g npm@latest
```
## Konfigurer freeCodeCamp lokalt
Nu hvor du har installeret forudsætningerne, så følg [vores lokale installationsguide](https://contribute.freecodecamp.org/#/how-to-setup-freecodecamp-locally) for at klone, installere og opsætte freeCodeCamp lokalt på din maskine.
> [!WARNING]
>
> Bemærk, at på dette tidspunkt er opsætningen til Cypress tests (og relaterede GUI behov) et arbejde i gang. Du bør stadig være i stand til at arbejde på det meste af kodebasen.
## Nyttige 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) - en artikel af Mrugesh Mohapatra (Staff Developer at freeCodeCamp.org)
- Ofte stillede spørgsmål om:
- [Windows-delsystem til Linux](https://docs.microsoft.com/en-us/windows/wsl/faq)
- [Docker Desktop til Windows](https://docs.docker.com/docker-for-windows/faqs)

15
docs/i18n/Danish/how-to-use-docker-on-windows-home.md Normal file
View File

@ -0,0 +1,15 @@
# Sådan bruger du Docker på Windows Home
Der er et par faldgruber, der skal undgås, når du opretter docker på Windows Home. Først og fremmest skal du bruge [Docker Toolbox](https://docs.docker.com/toolbox/toolbox_install_windows/) som administrator. Desværre understøtter Windows Home ikke Docker til Windows Desktop, så værktøjskassen skal bruges i stedet. Det skal køres som Administrator, da installationen bruger symlinks, som ikke kan oprettes på anden måde.
Når du har installeret værktøjskassen, skal du køre Docker Quickstart terminal som administrator. Dette vil oprette en `standard` virtuel maskine, hvis den ikke allerede eksisterer. Når det er sket, lukke terminalen og åbne VirtualBox (igen som administrator). Du bør være i stand til at se `standard` maskine. Webstedet er ganske ressourceintensiv, så stop den virtuelle maskine og hæve indstillingerne så meget som du kan - hukommelse i særdeleshed. Det er blevet bekræftet at arbejde med 4 GB ram.
Når du er glad for, at Docker arbejder, klone freeCodeCamp repository til en mappe inde i `C:\Brugere`. Disse mapper deles giver Docker adgang til de lokale mapper, som den skal bruge under installationen.
Hvis du ser beskeder som
```shell
bash: change_volumes_owner.sh: Ingen sådan fil eller mappe
```
når du `npm kører docker:init` dette er sandsynligvis synderen.

541
docs/i18n/Danish/how-to-work-on-coding-challenges.md Normal file
View File

@ -0,0 +1,541 @@
# Hvordan man arbejder på kodning udfordringer
Vores mål er at udvikle en sjov og klar interaktiv læringsoplevelse.
Det er vanskeligt at designe interaktive kodningsudfordringer. Det ville være meget lettere at skrive en lang forklaring eller at oprette en video tutorial, og der er et sted for dem på Medium og YouTube. Men for vores kerne pensum holder vi os til det, der virker bedst for de fleste mennesker - en fuldt interaktiv, videospil-lignende oplevelse.
Vi ønsker, at campister skal nå frem til en flydetilstand. Vi ønsker, at de skal bygge momentum og blast gennem vores pensum med så få snags som muligt. Vi ønsker, at de skal gå ind i projekterne med tillid og opnå en bred udsættelse for programmeringskoncepter.
At skabe disse udfordringer kræver enorm kreativitet og opmærksomhed på detaljer. Der er masser af hjælp til rådighed. Du vil have støtte fra et helt team af bidragsydere, til hvem du kan hoppe ideer ud og demo dine udfordringer. Bliv aktiv i [bidragsyderlokalet](https://gitter.im/freecodecamp/contributors) og stil masser af spørgsmål.
Med din hjælp kan vi designe en interaktiv kodning pensum, der vil hjælpe millioner af mennesker med at lære at kode i mange år fremover.
Indholdet for hver udfordring gemmes i sin egen markdown fil. Denne markdown fil konverteres senere til HTML ved hjælp af vores værktøjer til at oprette interaktive websider.
Du kan finde alt freeCodeCamp.org's curricular indhold i mappen [`/curriculum/challenges`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges).
## Opsæt værktøjet til pensum
Før du arbejder på pensum, vil du nødt til at oprette nogle værktøjer til at hjælpe dig med at teste dine ændringer. Du kan bruge enhver mulighed fra nedenstående:
- Du kan [konfigurere freeCodeCamp lokalt](how-to-setup-freecodecamp-locally.md). Dette er **stærkt anbefalet** til regelmæssige/gentagne bidrag. Denne opsætning giver dig mulighed for at arbejde og teste dine ændringer.
- Brug Gitpod, et gratis online udviklermiljø. Hvis du klikker på knappen nedenfor, vil du starte et klar-til-kode udviklermiljø for freeCodeCamp i din browser. Det tager kun et par minutter.
[![Åbn i Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
- Rediger filerne på GitHub interface ved at klikke på blyant-ikonet for den tilsvarende fil. Mens dette er den hurtigste måde, anbefales det **ikke**, fordi du ikke kan teste dine ændringer på GitHub. Hvis vores vedligeholdere konkluderer, at de ændringer, du har foretaget, skal testes lokalt, skal du følge metoderne ovenfor i stedet igen.
## Udfordring Skabelon
Nedenfor er en skabelon af, hvad udfordringen markdown filer ser ud i øjeblikket. For at se den strømlinede skabelon vil vi vedtage se [nedenfor](#upcoming-challenge-template).
````md
---
id: Unik identifikator (alfanumerisk, MongoDB_id)
title: Challenge Titel
challengeType: 0
videoUrl: 'url of video explanation'
---
## Beskrivelse
<section id='description'>
A Beskrivelse af udfordringen og hvad der kræves for at bestå
</section>
## Instruktioner
<section id='instructions'>
Instruktioner om, hvad der præcist skal gøres.
</section>
## Tests
<section id='tests'>
```yml
tests:
- tekst: Skal returnere "foo"
testString: 'En strenget funktion muligvis ved brug af Chai påstande'
````
</section>
## Udfordring Frø
<section id='challengeSeed'>
<div id='{ext}-seed'>
```{ext}
Kode, der vises i editoren som standard.
Dette er en nødvendig sektion for udfordringen.
```
</div>
### Før Test
<div id='{ext}-setup'>
```{ext}
Valgfri Test setup kode.
```
</div>
### Efter Test
<div id='{ext}-teardown'>
```{ext}
Valgfri Test rive ned kode.
```
</div>
</section>
## Løsning
<section id='solution'>
```{ext}
// løsning påkrævet
```
</section>
````
> [!BEMÆRK]
>
> 1. I ovenstående afsnit eksempler på `{ext}` er:
>
> - `html` - HTML/CSS
> - `js` - JavaScript
> - `jsx` - JSX
>
> 2. For afsnittet `Tests` ovenfor skal `text` og `testString` være gyldige YAML strenge. `testString` kan være en streng funktion eller udtryk ved hjælp af hvilke kunne bruge Chai påstande.
## Nummerering Udfordringer
Hver udfordring har brug for en `id`. Hvis du ikke angiver en, så vil MongoDB oprette en ny tilfældig en når den gemmer data; dog ønsker vi ikke, at det skal gøre det, da vi ønsker, at udfordringen id'er skal være konsistente på tværs af forskellige miljøer (iscenesættelse, produktion, masser af forskellige udviklere mv.).
For at generere en ny i en shell (forudsat at MongoDB kører separat):
1. Kør `mongo` kommando.
2. Kør `ObjectId()` kommando.
For eksempel:
```bash
$ mongo
MongoDB shell version v3.6.1
forbinder til: mongodb://127.0.0.1:27017
MongoDB server version: 3.4.10
...
$ ObjectId()
ObjectId("5a474d78df58bafeb3535d34")
````
Resultatet er et nyt id, for eksempel `5a474d78df58bafeb3535d34` ovenfor.
Når du har dit id, skal du sætte det i markdown filen som `id` feltet øverst, f.eks.
```yml
---
id: 5a474d78df58bafeb3535d34
title: Challenge Title
```
## Navngivning udfordringer
Det er svært at navngive tingene. Vi har gjort det lettere ved at pålægge nogle begrænsninger.
Alle challenge titler skal være eksplicitte og skal følge dette mønster:
\[verb\]\[objektklausul\]
Her er nogle eksempel challenge navne:
- Brug med uret Notation til at angive polstring af et element
- Kondensér arrays med .reduce
- Brug parentes Notation til at finde det første tegn i en streng
## Udfordring beskrivelser / instruktioner
Sætninger skal være klare og koncise med minimal jargon. Hvis det anvendes, skal jargon straks defineres på almindeligt engelsk.
Behold afsnit korte (omkring 1-4 sætninger). Det er mere sandsynligt, at folk læser flere korte afsnit end en tekstvæg.
Udfordringsteksten skal bruge den anden person ("dig") til at hjælpe med at give den en samtaletone. På denne måde synes teksten og instruktionerne at tale direkte med autocamperen om udfordringen. Prøv at undgå at bruge den første person ("I", "vi", "let's", og "os").
Brug ikke udgående links. Disse afbryder strømmen. Campers bør aldrig nødt til at google noget under disse udfordringer. Hvis der er ressourcer, du tror campister ville drage fordel af, skal du tilføje dem til udfordringens Guide-relaterede artikel.
Du kan tilføje diagrammer, hvis det er absolut nødvendigt.
Brug ikke emojis eller emotikoner i udfordringer. freeCodeCamp har et globalt fællesskab, og den kulturelle betydning af en emoji eller emotik kan være forskellig i hele verden. Også emojis kan gøre forskelligt på forskellige systemer.
Korrekte navneord bør bruge korrekt kapitalisering, når det er muligt. Nedenfor er en liste over ord, som de skal vises i udfordringerne.
- JavaScript (store bogstaver i "J" og "S" og ingen forkortelser)
- Node.js
- Front-end udvikling (adjektiv form med en bindestreg) er, når du arbejder på forsiden (noun form uden bindestreg). Det samme gælder med "back end", "full stack" og mange andre sammensatte udtryk.
### Reglen på 2 minutter
Hver udfordring skal løses inden for 120 sekunder af en indfødt engelsk taler, der har fuldført de udfordringer, der fører op til det. Dette omfatter den tid det tager at læse anvisningerne / instruktionerne forstå den seedede kode skrive deres egen kode og få alle tests til at passere.
Hvis det tager mere end to minutter at fuldføre udfordringen, har du to muligheder:
- Forenkle udfordringen, eller
- Opdel udfordringen i to udfordringer.
Den 2-minutters regel tvinger dig, udfordringen designer, at gøre dine retninger kortfattede, din seed kode klar, og dine tests ligetil.
Vi sporer, hvor lang tid det tager for campister at løse ændringer og bruge disse oplysninger til at identificere udfordringer, der skal forenkles eller splittes.
### Modularitet
Hver udfordring skal undervise i præcis ét koncept, og dette koncept skal fremgå af udfordringens navn.
Vi kan forstærke tidligere dækkede begreber gennem gentagelse og variationer - f.eks. indføre h1 elementer i én udfordring, derefter h3 elementer et par udfordringer senere.
Vores mål er at have tusindvis af 2-minutters udfordringer. Disse kan flyde sammen og gentage tidligere dækkede begreber.
### Formaterer challenge text
Her er specifikke formateringsretningslinjer for challenge tekst og eksempler:
- Sprog søgeord gå i `<code>` tags. For eksempel HTML tag navne eller CSS egenskabsnavne
- Den første udgave af et søgeord, når det er ved at blive defineret, eller generelle søgeord (dvs. "objekt" eller "uforanderlig") gå i `<dfn>` tags
- Henvisninger til kodedele (dvs. funktion, metode eller variabelnavne) skal indpakkes i `<code>` tags. Se eksemplet nedenfor:
- Brug <code>parseInt</code> til at konvertere variablen <code>realNumber</code> til et heltal.
- Multi-line code blocks **must be eded by a empty line**. Den næste linje skal starte med tre backticks efterfulgt straks af et af de [understøttede sprog](https://prismjs.com/#supported-languages). For at fuldføre kodeblokken, skal du starte en ny linje som kun har tre backticks og **en anden tom linje**. **Bemærk:** Hvis du vil bruge et eksempel kode i YAML, brug `yaml` i stedet for `yml` for sproget til højre for backticks.
Se eksemplet nedenfor:
````md
Følgende er et eksempel på kode:
```{language}
[DIN KODE HER]
````
````
- Yderligere oplysninger i form af en note bør formateres `<strong>Note:</strong> Resten af note text...
- Hvis der er behov for flere noter, listen derefter alle noter i separate sætninger ved hjælp af formatet `<strong>Noter:</strong> Første note tekst. Anden note tekst.«
- Brug dobbelte citater hvor det er relevant
## Skrivningstest
Udfordringer skal have det mindste antal test, der er nødvendige for at kontrollere, at en camper forstår et koncept.
Vores mål er at kommunikere det eneste punkt, som udfordringen forsøger at undervise, og afprøve, at de har forstået det.
Udfordringstest kan gøre brug af node.js og Chai.js påstand biblioteker. Også, hvis det er nødvendigt, brugergenereret kode kan tilgås i `code` variablen.
## Formatering af seed code
Her er specifikke retningslinjer for formatering af challenge seed code:
- Brug to mellemrum til at indrykke
- JavaScript udsagn slutter med et semikolon
- Brug dobbelte citater hvor det er relevant
- Kommentarer lavet skal have et mellemrum mellem kommentar tegn og kommentaren selv
`// Fix this line`
## Tips and Solutions
Hver udfordring har en `Få en Hint` knap, så en bruger kan få adgang til alle hints/løsninger, der er blevet skabt til udfordringen. Curriculum hints/solutions topics are located on [our forum](https://forum.freecodecamp.org/c/guide) under the `Guide` category.
Hvis du finder et problem med en eksisterende challenge's hints/solutions emne, kan du stille forslag i [bidragsydere kategori] (https://forum.freecodecamp.org/c/contributors) på forummet. Moderatorer og brugere med tillidsniveau 3 vil gennemgå kommentarerne og beslutte, om de vil inkludere ændringerne i det tilsvarende hint/løsninger emne.
### Tilføjelse af nye Challenge hints/solutions Emner
Tag følgende skridt, når du tilføjer en ny challenge hints/solutions relateret emne.
1. Start med at følge de samme trin for at oprette et nyt emne, men gennemse det næste for at oprette titlen.
2. Titlen på emnet bør starte med `freeCodeCamp Challenge Guide: ` sammenkædet med den faktiske titel på curriculum challenge. For eksempel, hvis udfordringen hedder "`Chunky Monkey`", emnet titel ville være "`freeCodeCamp Challenge Guide: Chunky Monkey`".
3. `camperbot` skal være ejeren af disse emner/opslag så du bliver nødt til at anmode en admin til at ændre ejerskabet af hovedindlægget til `camperbot`.
4. Når det nye emne er oprettet, oprettes et forum topic id. Det er placeret i slutningen af forum topic URL. Dette id skal tilføjes til forsiden af curriculum challenge filen via den normale pull request proces for at få en Hint` knappen til at linke til emnet.
### Retningslinjer for indhold af hints og løsningsemner
Når du foreslår en løsning til et curriculum udfordringsrelateret guideemne den fulde kode skal tilføjes. Dette omfatter al den oprindelige seed kode plus eventuelle ændringer, der er nødvendige for at bestå alle challenge tests. Følgende skabelon skal bruges ved oprettelse af nye hints/solutions emner:
````md
# Challenge Name Goes Here
---
## Problem Forklaring
Dette opsummerer, hvad der skal gøres uden blot at gentage challenge beskrivelsen og/eller instruktionerne. Dette er et valgfrit afsnit
#### Relevante Links
- [Link Text](link_url_goes_here)
- [Link Text](link_url_goes_here)
---
## Tips
### Tip 1
Tip går her
### Tip 2
Tip går her
---
## Løsninger
<details><summary>Løsning 1 (Klik på Vis/Skjul)</summary>
``js
funktion myFunc() {
konsol. og('Hej Verden!');
}
````
#### Kode Forklaring
- Kodeforklaring vises her
- Kodeforklaring vises her
#### Relevante Links
- [Link Tekst](link_url_goes_here)
- [Link Tekst](link_url_goes_here)
</details>
````
## Test Udfordringer
Før du [opret en pull request](how-to-open-a-pull-request. d) for dine ændringer, skal du validere at de ændringer, du har foretaget, ikke uforvarende forårsage problemer med udfordringen.
1. For at teste alle challenges, køres kommandoen nedenfor fra rodmappen
````
npm kørselstest:curriculum
```
2. Du kan også teste en blok eller en superblok af udfordringer med disse kommandoer
```
npm run test: curriculum --block='Basic HTML og HTML5'
```
```
npm run test:curriculum --superblock=responsive-web-design
```
Du kan også teste en udfordring individuelt ved at udføre følgende trin:
1. Skift til 'curriculum'-mappen:
```
cd- pensum
```
2. Kør følgende for hver challenge fil, som du har ændret:
```
npm run test -- -g 'den fulde engelske titel på udfordringen'
```
Når du har bekræftet, at hver challenge du har arbejdet på består testene, [opret venligst en pull request](https://github.com/freeCodeCamp/freeCodeCamp/blob/master/docs/how-to-open-a-pull-request.md).
> [!TIP]
> Du kan indstille miljøvariablen `LOKALE` i `.env` til sproget i den eller de udfordringer, du skal teste.
>
> De aktuelt accepterede værdier er `english` og `chinese`, hvor `english` sættes som standard.
## Kommende Udfordringsskabelon
Udfordringsskabelonen i processen med at blive opdateret til en renere, mindre indlejret struktur. Dette er ikke fuldstændigt afsluttet, men følgende skal være tæt på den endelige struktur:
````mdx
---
id: Unik identifikator (alfanumerisk, MongoDB_id)
titel: 'Challenge Title'
challengeType: Integer, defineret i 'client/utils/challengeTypes. s`
videoUrl: 'url of video explanation'
forumTopicId: 12345
---
import Script fra './script. dx';
## --step-description--
Beskrivelse tekst, i markdown
```html
<div>
eksempel kode
</div>
```
## --step-hints--
![test-id-1]
Der vil være et vilkårligt antal tripler af id'er, instruktioner (i markdown) og kodeblokke.
```js
Kode for test 1
```
![test-id-2]
Flere instruktioner i markdown syntaks
```js
Mere kode
```
## -- step-seed--
### --før-bruger-kode--
```lang
Kode evalueret før brugerens
```
### --after-user-code--
```lang
Kode evalueret efter brugeren, og lige før testene
```
### --seed-content--
![index-html]
```html
Nogle html
```
```css
Nogle css
```
```js
Nogle js
```
![index-js]
<Script ></p>
<h1 spaces-before="0">
--solution-marker--
</h1>
<p spaces-before="0">
Præcis det samme som sektionen med frø
</p>
<h2 spaces-before="0">
-- next-solution-marker
</h2>
<p spaces-before="0">
Samme igen
</p>
<h1 spaces-before="0">
-- question-marker--
</h1>
<h2 spaces-before="0">
-- text-marker--
</h2>
<p spaces-before="0">
Spørgsmålet ville gå her (bruges kun til videoudfordringer)
</p>
<h2 spaces-before="0">
--answers-marker--
</h2>
<p spaces-before="0">
Svar 1
</p>
<hr />
<p spaces-before="0">
Svar 2
</p>
<hr />
<p spaces-before="0">
Svar 2
</p>
<h2 spaces-before="0">
--solution-marker--
</h2>
<p spaces-before="0">
\<number of correct answer\>
</p>
<p spaces-before="0">
````
</p>
<h3 spaces-before="0">
Nyttige Links
</h3>
<p spaces-before="0">
Oprettelse og redigering udfordringer:
</p>
<ol start="1">
<li>
<p spaces-before="0">
<a href="https://github.com/freeCodeCamp/freeCodeCamp/blob/master/client/utils/challengeTypes.js#L1-L13">Challenge typer</a> - hvad den numeriske challenge type værdier betyder (enum).
</p>
</li>
<li>
<p spaces-before="0">
<a href="https://www.youtube.com/watch?v=iOdD84OSfAE#t=2h49m55s">Bidrag til FreeCodeCamp - Skrive ES6 Challenge Tests</a> - en video følgende <a href="https://twitter.com/ArrowoodTech">Ethan Arrowood</a> , da han bidrager til den gamle version af pensum.
</p>
</li>
</ol>

40
docs/i18n/Danish/how-to-work-on-the-docs-theme.md Normal file
View File

@ -0,0 +1,40 @@
# Hvordan man arbejder på docs tema
> [!BEMÆRK] En hurtig påmindelse om, at du ikke behøver at opsætte noget for at arbejde på indholdet til dokumentationswebstedet.
>
> For at arbejde på de bidragende retningslinjer, kan du redigere eller tilføje filer i `docs` mappen [tilgængelig her](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/docs). Når dine ændringer er flettet, vil det blive gjort tilgængelige automatisk på dokumentationssiden.
## Struktur af docs hjemmeside
Webstedet er genereret ved hjælp af [`docsify`](https://docsify.js.org)og tjente ved hjælp af GitHub sider.
Typisk behøver du ikke at ændre nogen konfiguration eller bygge webstedet lokalt. Hvis du er interesseret, her er hvordan det virker:
- Hjemmesidens kilde til dette websted er tilgængelig i [`docs/index.html`](index.html).
- Vi tjener denne fil som en SPA ved hjælp af `docsify` og GitHub Sider.
- Scriptet `docsify` genererer indholdet af `markdown` filer i `docs` mappe efter behov.
- Hjemmesiden er genereret fra [`_coverpage.md`](_coverpage.md).
- sidepanelets navigation er genereret fra [`_sidebar.md`](_sidebar.md).
## Servering af dokumentationsstedet lokalt
Klon freeCodeCamp:
```sh
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
docsify serve docs
```
Installer `docsify`:
```sh
npm install -g docsify
```
og servere mappen `/docs`
```sh
docsify tjene docs
```
Alternativt, hvis du har installeret freeCodeCamp lokalt (se den lokale opsætningsguide), vi samler CLI med udviklingsværktøjerne, så du kan køre `npm run docs:serve` from the root of the repo.

10
docs/i18n/Danish/how-to-work-on-the-news-theme.md Normal file
View File

@ -0,0 +1,10 @@
<!--
The source for this document is available at:
https://github.com/freeCodeCamp/news-theme/blob/master/CONTRIBUTING.md
Please edit that file instead.
-->
[remote-markdown-url](https://raw.githubusercontent.com/freeCodeCamp/news-theme/master/CONTRIBUTING.md)

45
docs/i18n/Danish/index.md Normal file
View File

@ -0,0 +1,45 @@
Fællesskabet [freeCodeCamp.org](https://freecodecamp.org) er muligt takket være tusindvis af venlige frivillige som dig. Vi byder alle bidrag til fællesskabet velkommen og er glade for at byde dig velkommen ombord.
> [!BEMÆRK] Før du fortsætter, skal du tage et hurtigt 2 minutter at læse vores [Code of Conduct](https://www.freecodecamp.org/code-of-conduct). Vi håndhæver den strengt på tværs af vores samfund. Vi ønsker at bidrage til freeCodeCamp.org for at være en sikker og inklusiv oplevelse for alle.
Glad bidrag.
Du er velkommen til:
- Opret, opdater og reparer fejl i vores [kodningsudfordringer](#coding-challenges).
- Hjælp os med at rette fejl i freeCodeCamp.org's [læringsplatform](#learning-platform).
- _(Kommer snart)_ Hjælp os med at oversætte freeCodeCamp.org til verdens sprog.
Har du spørgsmål? Gå over til [disse ofte stillede spørgsmål](/FAQ.md) , hvor vi besvarer nogle almindelige spørgsmål om at bidrage.
## Kodning Udfordringer
Alle vores kodningsudfordringer er kurateret af fællesskabet, der bringer ekspert viden fra frivillige som dig.
Du kan hjælpe med at udvide dem og gøre deres ordlyd bedre. Du kan også opdatere brugerhistorierne for at forklare konceptet bedre eller fjerne overflødige og forbedre udfordringstestene for at gøre dem mere præcist teste folks kode.
**Hvis du er interesseret i at forbedre disse kodningsudfordringer, her er [hvordan man arbejder på kodningsudfordringer](how-to-work-on-coding-challenges.md).**
## Læringsplatform
Vores læringsplatform kører på en moderne JavaScript stack. Det har forskellige komponenter, værktøjer og biblioteker, herunder men ikke begrænset til, Node.js, MongoDB, LoopBack, OAuth 2.0, React, Gatsby, Webpack, og meget mere.
Bredt
- Vi har en node.js-baseret API-server.
- Et sæt React-baserede klientprogrammer.
- Et script, som vi bruger til at evaluere vores front-end projekter.
Bidrag til dette kræver en vis forståelse af API'er, ES6 Syntax, og en masse nysgerrighed.
I bund og grund forventer vi grundlæggende kendskab til nogle af de førnævnte teknologier, værktøjer og biblioteker. Når det er sagt, er De ikke forpligtet til at være ekspert i dem for at bidrage.
**Hvis du ønsker at hjælpe os med at forbedre vores kodebase, kan du enten bruge Gitpod, et gratis online dev miljø**
[![Åbn i Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
(Starter et klar-til-kode dev miljø til freeCodeCamp i din browser.)
ELLER
**du kan [konfigurere freeCodeCamp lokalt](how-to-setup-freecodecamp-locally.md) på din maskine.**

101
docs/i18n/Dutch/FAQ.md Normal file
View File

@ -0,0 +1,101 @@
### Ik ben nieuw bij GitHub en Open Source, waar moet ik beginnen?
Lees onze ["Hoe deel te nemen aan de Open Source Handleiding"](https://github.com/freeCodeCamp/how-to-contribute-to-open-source). Het is een compresensieve bron van eerste timer vriendelijke projecten en richtsnoeren.
### Kan ik het curriculum van freeCode vertalen?
We zullen de lokalisatie-inspanningen aftrap op freeCodeCamp beginnend met de **Chinese** eerst.
We zijn van plan om het curriculum in meer talen beschikbaar te maken, maar kunnen ons nog niet aan termijnen binden. Verschillende operationele limieten, zoals personeel, actieve bijdragers en serverkosten, spelen een rol in de internationalisering (i18n) inspanningen.
Wij zijn van plan i18n te beginnen in deze talen: Arabisch, Portugees, Russisch en Spaans (in geen specifieke volgorde) nadat we het curriculum in het Chinees hebben vrijgegeven.
**Waarom richt je je eerst op het Chinese curriculum?**
China is de grootste demografische regio's van ons niet-oorspronkelijke Engelse sprekende publiek. Momenteel hebben we honderdduizenden gebruikers die een oude versie van het platform gebruiken. Als we ons richten op het Chinese curriculum geven we een schatting van de logistiek die betrokken is bij het i18n.
We zullen ons richten op Latijns-Amerika als demografische regio voor Portugees en Spaans.
We hebben binnen afzienbare tijd geen plannen voor i18n voor andere talen dan de bovengenoemde talen.
Wij moedigen u niet aan om aan i18n aan de bovengenoemde talen te werken. We kunnen pull requests accepteren, zonder enige verwachting van tijdslijnen over implementaties.
### Hoe kan ik een nieuwe bug melden?
Als je denkt dat je een bug hebt gevonden, lees dan eerst het ["Help ik een Bug"](https://forum.freecodecamp.org/t/how-to-report-a-bug/19543) artikel en volg de instructies.
Als je er zeker van bent dat het een nieuwe bug is, ga dan door en maak een nieuw GitHub probleem. Zorg ervoor dat je zoveel mogelijk informatie toevoegt zodat we de bug kunnen reproduceren. We hebben een vooraf gedefinieerde issue template om u hierbij te helpen.
Houd er rekening mee dat eventuele problemen met coderingshulp op een uitdaging zullen worden opgelost. De kwestie tracker is strikt voor kwesties in verband met de codebasis en besprekingen. Wanneer u twijfelt, moet u [hulp zoeken op het forum](https://forum.freecodecamp.org) voordat u een rapport maakt.
### Hoe kan ik een veiligheidsprobleem melden?
Maak alsjeblieft geen GitHub problemen aan voor veiligheidsproblemen. Stuur in plaats daarvan een e-mail naar `security@freecodecamp.org` en we zullen het onmiddellijk onderzoeken.
### Ik ben een student, kan ik of ons team werken aan een functie voor academische kredieten?
Zeker, zeker.
We staan open voor alle bijdragen, hoewel Houd er rekening mee dat we ons niet kunnen vastleggen op tijdlijnen die vereist kunnen zijn aan uw hogeschool of universiteit. We ontvangen veel pull-aanvragen en code-bijdragen van vrijwilligers en we respecteren hun tijd en hun inspanningen. We zullen geen speciale aandacht kunnen besteden aan PR om voor iedereen eerlijk te zijn.
We verzoeken u om vooruit te plannen en met dit in gedachten te werken aan een functie.
### Wat betekenen deze verschillende etiketten die op problemen worden gemerkt?
De code onderhoudt [triage](https://en.wikipedia.org/wiki/Software_bug#Bug_management) problemen en pull requests op basis van hun prioriteit, ernst en andere factoren. Hier vindt u [een volledige woordenlijst van hun betekenis](https://github.com/freecodecamp/freecodecamp/labels).
### Waar begin ik als ik aan een onderwerp wil werken?
Je zou [**`hulp willen zoeken`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) of [**`eerste timers moeten doorlopen`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22first+timers+only%22) problemen voor een snel overzicht van waar je aan kunt werken.
> [!TIP] **`hulp gewild`** problemen zijn te grijpen, en je hoeft geen toestemming te zoeken voordat je er aan werkt. Problemen met de **`eerste timers alleen`** label zijn echter gereserveerd voor mensen die niet eerder hebben bijgedragen aan de freeCodeCamp codebase. Als deze kwesties niet duidelijk zijn over wat er gedaan moet worden, voel je dan vrij om vragen te stellen in de opmerkingen.
### Ik vond een typo, moet ik een probleem melden voordat ik een pull-verzoek kan indienen?
Voor typos en andere formuleringen kunt u pull requests direct openen zonder eerst een probleem aan te maken. Issues zijn meer voor het bespreken van grotere problemen in verband met code of structurele aspecten van het curriculum.
Noem echter details, context etc. in het beschrijving gebied van de pull request om ons te helpen uw bijdrage te begrijpen en te bekijken, zelfs voor kleine wijzigingen.
### Hoe krijg ik een issue aan mij toegewezen?
We wijzen meestal geen problemen toe aan iemand anders dan lange tijd bijdragers om dubbelzinnige shows te voorkomen. In plaats daarvan volgen we het onderstaande beleid om eerlijk te zijn voor iedereen:
1. Wij geven er de voorkeur aan dat de eerste pull-aanvraag voor elk onderwerp wordt samengevoegd.
2. In het geval van verzoeken om meerdere pull-aanvragen voor dezelfde kwestie geven we prioriteit aan de kwaliteit van de code in de pull-aanvragen.
- Hebt u tests opgenomen?
- Heb je alle usecases gehaald?
- Heb je alle tests pass gegarandeerd en je hebt lokaal bevestigd dat alles werkt?
3. Tot slot zijn wij voorstander van aanvragen voor het volgen van onze aanbevolen richtsnoeren.
- Heb je de checklist voor pull request gevolgd?
- Heb je je pull request titel goed benoemd?
Je hebt geen toestemming nodig voor problemen die gemarkeerd zijn met `hulp gewenst` of `eerste keer alleen` zoals eerder uitgelegd.
Volg de richtlijnen zorgvuldig en open een pull request.
### Ik houd vast aan iets dat niet in deze documentatie is opgenomen.
**Voel je vrij om hulp te vragen in:**
- The `Contributors` category of [our community forum](https://forum.freecodecamp.org/c/contributors).
- The public `Contributors` [chat room on Gitter](https://gitter.im/FreeCodeCamp/Contributors).
- The `#Contributors` channel on [our Discord community server](https://discord.gg/pFspAhS).
We zijn erg blij je te helpen bij het bijdragen aan een van de onderwerpen waar je aan wilt werken. Voel je vrij om ons vragen te stellen over de onderwerpen die hiermee verband houden, en we zullen graag opheldering verschaffen. Zorg ervoor dat u zoekt naar uw zoekopdracht voordat u een nieuwe plaatst.
Wees beleefd en geduldig. Onze gemeenschap van vrijwilligers en moderators zijn er altijd om je door je vragen te leiden.
**Extra ondersteuning:**
Als je vragen hebt over de stapel, de architectuur van de codebase, voel je vrij om contact op te nemen met onze medewerkers:
| Medewerkers | Bericht verzenden op forum |
|:--------------------- |:---------------------------------------------------------------------------- |
| Mohapatra rugesj | [@raisedadead](https://forum.freecodecamp.org/u/raisedadead) |
| Ahmad Abdolsaheb | [@abdolsa](https://forum.freecodecamp.org/u/abdolsa) |
| Kristofer Koishigawa | [@scissorsneedfoodtoo](https://forum.freecodecamp.org/u/scissorsneedfoodtoo) |
| Tom Mondloc | [@moT01](https://forum.freecodecamp.org/u/moT01) |
| Oliver Eyton-Williams | [@ojeytonwilliams](https://forum.freecodecamp.org/u/ojeytonwilliams) |
| Randelaar Dawson | [@RandellDawson](https://forum.freecodecamp.org/u/randelldawson) |
**U kunt onze ontwikkelaarstaf e-mailen op: `dev[at]freecodecamp.org`**

36
docs/i18n/Dutch/_sidebar.md Normal file
View File

@ -0,0 +1,36 @@
- **Aan de slag**
- [Introductie](/index.md "Draag bij aan de freeCodeCamp.org Gemeenschap")
- [Veelgestelde vragen (FAQ's)](/FAQ.md)
- **Code bijdrage**
- - [Stel het freeCodeCamp lokaal in](/how-to-setup-freecodecamp-locally.md)
- [Open een pull-aanvraag](/how-to-open-a-pull-request.md)
- [Werk aan coderingsuitdagingen](/how-to-work-on-coding-challenges.md)
- [Werk aan video uitdagingen](/how-to-help-with-video-challenges.md)
- [Werk aan het nieuws thema](/how-to-work-on-the-news-theme.md)
- [Werk aan het thema documenten](/how-to-work-on-the-docs-theme.md)
- **Optionele handleidingen**
- [Groeps uitgaande e-mails lokaal](/how-to-catch-outgoing-emails-locally.md)
- [Gratis CodeCamp op WSL instellen](/how-to-setup-wsl.md)
---
- **中文社区贡献指南**
- [成为专栏作者](/i18n/chinese/news-author-application.md)
- [文章翻译计划](/i18n/chinese/news-translations.md)
- [视频翻译计划](/i18n/chinese/video-translations.md)
---
- **Vlucht handleidingen** (voor medewerkers & Mods)
- [Moderator handboek](/flight-manuals/moderator-handbook.md)
- [Antwoord sjablonen](/flight-manuals/using-reply-templates.md)
- [DevOps overzicht](/devops.md)
- [Werken aan servers](/flight-manuals/working-on-virtual-machines.md)
---
- **Onze Gemeenschap**
- [**GitHub**](https://github.com/freecodecamp/freecodecamp)
- [**Weergeef Forum**](https://freecodecamp.org/forum/c/contributors)
- [**Gitter Chat**](https://gitter.im/FreeCodeCamp/Contributors)
- [**Discord Server**](https://discord.gg/pFspAhS)

227
docs/i18n/Dutch/devops.md Normal file
View File

@ -0,0 +1,227 @@
# Ontwikkelaars Bewerkingen op freeCodeCamp.org
Deze handleiding zal je helpen onze infrastructuurstapel te begrijpen en hoe we onze platformen onderhouden. Hoewel deze handleiding niet over uitputtende gegevens voor alle activiteiten beschikt, kan het worden gebruikt als referentie voor uw begrip van de systemen.
Laat ons weten, als u feedback of vragen hebt, en we zullen daar graag opheldering over geven.
## Hoe bouwen we, testen en inzetten we de codebase?
Deze repository wordt continu gebouwd, getest en geïmplementeerd in **afzonderlijke infrastructuursets (Servers, Databases, CDNs, etc.)**.
Daarbij gaat het om drie stappen die in de rij moeten worden gevolgd:
1. Nieuwe wijzigingen (zowel fixes als functies) worden samengevoegd tot onze primaire ontwikkelingssector (`master`) via pull requests.
2. Deze wijzigingen worden uitgevoerd door een reeks geautomatiseerde tests.
3. Zodra de tests zijn uitgevoerd, brengen we de wijzigingen vrij (of wijzigen ze indien nodig) voor de inzet van onze infrastructuur.
#### Bouwen van de codebase - aftappende Git filialen tot afzetting.
Typisch [`master`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master) (de standaard ontwikkelingsbranch) wordt eenmaal per dag samengevoegd in de [`productiestaging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) tak en wordt vrijgegeven in een geïsoleerde infrastructuur.
Dit is een tussenliggende release voor onze ontwikkelaars en vrijwilligers. Het staat ook bekend als onze "staging" of "beta" vrijlating.
Het is identiek aan onze live productie omgeving op `freeCodeCamp.org`, anders dan het met behulp van een aparte set databases, servers, webproxies, enz. Deze isolatie laat ons doorlopende ontwikkeling en functies in een "productie" zoals scenario, zonder de reguliere gebruikers van freeCodeCamp.org te beïnvloeden. Deze isolatie laat ons doorlopende ontwikkeling en functies in een "productie" zoals scenario, zonder de reguliere gebruikers van freeCodeCamp.org te beïnvloeden.
Zodra het ontwikkelteam [`@freeCodeCamp/dev-team`](https://github.com/orgs/freeCodeCamp/teams/dev-team/members) tevreden is met de wijzigingen op het ontwikkelingsplatform, deze wijzigingen worden om de paar dagen verplaatst naar de [`productie-current`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-current) branch.
Dit is de definitieve versie die veranderingen verplaatst naar onze productieplatforms op freeCodeCamp.org.
#### Wijzigingen testen - Integratie en Gebruikers Acceptatie Testen.
We passen verschillende niveaus van integratie en acceptatie toe om de kwaliteit van de code te controleren. Al onze tests worden gedaan via software zoals [Travis CI](https://travis-ci.org/freeCodeCamp/freeCodeCamp) en [Azure Pipelines](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp).
We hebben eenheidstests voor het testen van onze challenge oplossingen, Server API's en Client User Interfaces. Deze helpen ons om de integratie tussen verschillende componenten te testen.
> We zijn ook bezig met het schrijven van eindgebruikerstests die helpen bij het repliceren van echte wereldscenario's zoals het bijwerken van een e-mail of het bellen naar de API of derden diensten.
Samen helpen deze tests voorkomen dat problemen zich herhalen en ervoor zorgen dat we geen bug introduceren terwijl we aan een andere bug of een functie werken.
#### Wijzigingen implementeren - wijzigingen uitvoeren op servers.
We hebben continu toedieningssoftware geconfigureerd om wijzigingen in onze ontwikkeling- en productieservers door te voeren.
Zodra de wijzigingen naar de beschermde release-takken worden geduwd, wordt een bouwpijplijn automatisch geactiveerd voor de branche. De bouw van pijpleidingen is verantwoordelijk voor het bouwen van artefacten en het bewaren ervan in een koude opslag voor later gebruik.
De bouw pipeline gaat verder om een overeenkomende release pipeline te activeren als deze een succesvolle uitvoering voltooit. De release pipelines zijn verantwoordelijk voor het verzamelen van de build artefacten, ze verplaatsen naar de servers en gaan leven.
Status van builds en releases zijn [hier beschikbaar](#build-test-and-deployment-status).
## Een gebouw, test en inzet van de server.
Momenteel kunnen alleen leden van het ontwikkelingsteam naar de productiesectoren pushen. De wijzigingen in de `productie *` branches kunnen alleen landen door snel samen te voegen naar [`upstream`](https://github.com/freeCodeCamp/freeCodeCamp).
> [!NOT] In de komende dagen zullen we deze stroom verbeteren via pull-requests, voor beter beheer van toegang en transparantie.
### Veranderingen doorvoeren van Staging Applicaties.
1. Configureer je afstandsbedieningen correct.
```sh
git afstandsbediening -v
```
**Resultaten:**
```
origin git@github.com:raisedadead/freeCodeCamp.git (fetch)
origin git@github.com:raisedadeadad/freeCodeCamp.git (push)
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (fetch)
upstream git@github.com:freeCodeCamp.git (push)
```
2. Zorg ervoor dat je `master` branch pristine is en gesynchroniseerd is met de upstream.
```sh
Git checkout master
git fetch --all --prune
git reset --hard upstream/master
```
3. Controleer of de Travis CI de `master` branch doorgeeft voor upstream.
De [continue integratie](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) testen moeten groen en PASSING zijn voor de `master` branch.
<details> <summary> Controleer de status van Travis CI (screenshot) </summary>
<br>
![Controleer de bouwstatus op Travis CI](https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/master/docs/images/devops/travis-build.png)
</details>
Als dit mislukt moet u stoppen en de fouten onderzoeken.
4. Bevestig dat u de repository lokaal kunt bouwen.
```
npm run clean-and-develop
```
5. Verplaats wijzigingen van `master` naar `productie-staging` via een snelle merge
```
Git checkout productie-staging
git merge master
git push upstream
```
> [!NOT] Je zult niet in staat zijn om pushen te forceren en als je de geschiedenis toch hebt herschreven, zullen deze commando's een fout maken.
>
> Als ze dat wel doen, heeft u misschien iets verkeerd gedaan en moet u gewoon opnieuw beginnen.
De bovenstaande stappen zullen automatisch een uitvoering op de bouw pipeline uitvoeren voor de `productie-staging` branch. Zodra het bouwwerk klaar is, worden de artefacten opgeslagen als `.zip` bestanden in koude opslag die later worden gebruikt en opgehaald.
De release pipeline wordt automatisch geactiveerd als er een nieuw artefact beschikbaar is via de verbonden build pijplijn. Voor stagingplatforms, houdt dit proces geen handmatige goedkeuring in en de artefacten worden naar de Client CDN en API servers gepusht.
> [!TIP label:Offertingen] Meestal duurt de build run ~20-25 minuten om te volgen op de release run die ~15-20 minuten duurt voor de client, en ~5-10 minuten voor de API om live beschikbaar te zijn. Van code push naar live zijn op de stagingplatforms neemt het hele proces **~35-45 min** in totaal.
### Versturen wijzigingen van de Productie Applicaties.
Het proces is grotendeels hetzelfde als de stagingplatforms, met een paar extra controles. Dit is alleen om ervoor te zorgen dat we niets breken op freeCodeCamp.org die honderden gebruikers op elk moment kunnen zien die het gebruiken.
| Voer deze opdrachten NIET uit, tenzij u hebt geverifieerd dat alles werkt op het staging platform. U moet geen tests tijdens staging omzeilen of overslaan voordat u verder gaat. |
|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
1. Zorg ervoor dat je `productie-staging` tak priester is en gesynchroniseerd is met de upstream.
```sh
git checkout productie-staging
git fetch --all --prune
git reset --hard upstream/productie-staging
```
2. Verplaats wijzigingen van `productie-staging` naar `productie-current` door middel van een snelle merge
```
Git checkout productie-huidige
git producties samenvoegen
git push upstream
```
> [!NOT] Je zult niet in staat zijn om pushen te forceren en als je de geschiedenis toch hebt herschreven, zullen deze commando's een fout maken.
>
> Als ze dat wel doen, heeft u misschien iets verkeerd gedaan en moet u gewoon opnieuw beginnen.
De bovenstaande stappen zullen automatisch een uitvoering van de bouw pipeline starten voor de `productie-huidige` branch. Zodra een build artefact klaar is, zal het een run op de release pipeline starten.
> [!TIP︎ label:Estimates] Meestal duurt de build run ~20-25 minuten om te voltooien.
**Extra stappen voor de actie van het personeel**
Eén release run wordt geactiveerd, leden van het medewerkerteam van de ontwikkelaars ontvangen een geautomatiseerde handmatige interventie e-mail. They can either _approve_ or _reject_ the release run.
Als de veranderingen goed werken en zijn getest op het halteplatform, dan kan het worden goedgekeurd. De goedkeuring moet worden gegeven binnen 4 uur nadat de vrijlating in gang is gezet voordat deze automatisch wordt afgewezen. Een medewerker kan de release handmatig uitvoeren voor afgewezen uitvoeren of wachten op de volgende release-cyclus.
Voor medewerker:
| Controleer je e-mail voor een directe link of [ga naar het release-dashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) nadat de build is uitgevoerd. |
|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| |
Zodra een van de staff leden een release goedkeurt, zal de pipeline de wijzigingen live duwen naar freeCodeCamp.org productie CDN en API servers. Ze nemen meestal ~15-20 minuten voor de client, en ~5 minuten voor de API-servers om live beschikbaar te zijn.
> [!TIPKoflabel:Estimates] De release run duurt meestal ~15-20 minuten voor elke client instantie, en ~5-10 minuten voor elke API instantie om live te zijn. Van code push naar live zijn op de productieplatforms duurt het hele proces **~90-120 min** in totaal (niet het tellen van de wachttijd voor de personeelsgoedkeuring).
## Bouw, Test en Implementatiestatus
Hier is de huidige test, bouw en implementatie status van de codebase.
| Type | Filiaal | status | Dashboard |
|:------------------ |:------------------------------------------------------------------------------------------- |:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |:---------------------------------------------------------------------------------------------- |
| CI tests | [`meester`](https://github.com/freeCodeCamp/freeCodeCamp/tree/master) | ![Travis CI Bouw Status](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=master) | [Ga naar de status dashboard](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| CI tests | [`productie-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | ![Travis CI Bouw Status](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=production-staging) | [Ga naar de status dashboard](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| Bouw Pijplijn | [`productie-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | [![Bouw status](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_apis/build/status/dot-dev-ci?branchName=production-staging)](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build/latest?definitionId=15&branchName=production-staging) | [Ga naar de status dashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build) |
| Pijplijn vrijgeven | [`productie-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | | [Ga naar de status dashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) |
| CI tests | [`productie-stroom`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-current) | ![Travis CI Bouw Status](https://travis-ci.com/freeCodeCamp/freeCodeCamp.svg?branch=production-current) | [Ga naar de status dashboard](https://travis-ci.com/github/freeCodeCamp/freeCodeCamp/branches) |
| Bouw Pijplijn | [`productie-stroom`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | [![Bouw status](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_apis/build/status/dot-org-ci?branchName=production-current)](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build/latest?definitionId=17&branchName=production-current) | [Ga naar de status dashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build) |
| Pijplijn vrijgeven | [`productie-stroom`](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-staging) | | [Ga naar de status dashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release) |
## Vroegtijdige toegang en bèta-tests
We verwelkomen je om deze releases te testen in een **"openbare bèta-testing"** modus en krijg vroege toegang tot toekomstige functies op de platformen. Soms worden deze functies/wijzigingen aangeduid als **volgende, beta, staging,** enz.
Uw bijdragen via feedback en probleemrapporten zullen ons helpen bij het maken van de productieplatforms bij `freeCodeCamp. rg` meer **weerstandsvermogen**, **consistent** en **stabiel** voor iedereen.
Wij danken u voor het melden van fouten die u tegenkomt en helpen bij het verbeteren van freeCodeCamp.org. Je bent geweldig! Je bent geweldig!
### Identificeren van de aankomende versie van de platforms
Momenteel is er een publieke beta-versie beschikbaar op:
<h1 align="center"><a href='https://www.freecodecamp.dev' _target='blank'>freecodecamp.dev</a></h1>
> [!NOTE] De domeinnaam is anders dan **`freeCodeCamp.org`**. Dit is opzettelijk om het indexeren van zoekmachines te voorkomen en verwarring te voorkomen voor reguliere gebruikers van het platform.
### Identificeren van de huidige versie van de platforms
**De huidige versie van het platform is altijd beschikbaar op [`freeCodeCamp.org`](https://www.freecodecamp.org).**
Het dev-team voegt wijzigingen samen van de `productie-staging` branch naar `productie-current` wanneer ze wijzigingen vrijgeven. De beste commit is wat je live ziet op de site.
U kunt de exacte versie die in gebruik is door de bouw en implementatie logboeken te bezoeken die beschikbaar zijn in de statussectie. Als alternatief kun je ons ook pingen in de [bijdragers chat room](https://gitter.im/FreeCodeCamp/Contributors) voor een bevestiging.
### Bekende beperkingen
Er zijn enkele bekende beperkingen en afschrijvingen bij het gebruik van de bètaversie van het platform.
- #### Alle gegevens / persoonlijke vooruitgang op deze bètaplatforms `zullen NIET worden opgeslagen of overgedragen aan` naar productie.
**Gebruikers in de beta versie zullen een apart account hebben van de productie.** De beta versie gebruikt een fysiek gescheiden database van de productie. Dit geeft ons de mogelijkheid om onbedoeld gegevensverlies of wijzigingen te voorkomen. Het dev team kan de database leegmaken op deze bètaversie indien nodig.
- #### Er zijn geen garanties op de uptime en betrouwbaarheid van de bèta-platforms.
De inzet zal naar verwachting frequenter zijn en bij snelle iteraties soms meerdere keren per dag. Als gevolg hiervan zullen er soms onverwachte downtime of een onjuiste functionaliteit in de beta versie verschijnen.
- #### Stuur geen reguliere gebruikers naar deze site als een maatstaf voor het bevestigen van een oplossing
De beta site is en is altijd geweest om de lokale ontwikkeling en het testen ervan aan te vullen. Het is geen belofte van wat er komt, maar een glimp van waar aan gewerkt wordt.
- #### Onderteken pagina kan er anders uitzien dan productie
We gebruiken een testinstantie voor freecodecamp.dev op Auth0, en hebben dus niet de mogelijkheid om een aangepast domein in te stellen. Dit zorgt ervoor dat alle callbacks en inlogpagina op een standaard domein verschijnen: `https://freecodecamp-dev.auth0.com/`. Dit heeft geen invloed op de functionaliteit zoals we die kunnen krijgen.
## Problemen melden en feedback geven
Open nieuwe problemen voor discussies en het melden van bugs. Je kunt ze labelen als **[`release: next/beta`](https://github.com/freeCodeCamp/freeCodeCamp/labels/release%3A%20next%2Fbeta)** voor de triage.
Je kunt een e-mail sturen naar `dev[at]freecodecamp.org` als je vragen hebt. Zoals altijd moeten alle beveiligingskwetsbaarheden worden gemeld aan `beveiliging[at]freecodecamp.org` in plaats van de publieke tracker en het forum.

325
docs/i18n/Dutch/flight-manuals/moderator-handbook.md Normal file
View File

@ -0,0 +1,325 @@
# Het officiële freeCodeCamp Moderator Handboek.
Dit zal je helpen om verschillende plaatsen in onze gemeenschap te modereren, waaronder:
- GitHub problemen & pull-verzoeken
- Het forum, chatrooms, Facebook groepen en andere online vergaderplaatsen
- Persoonlijke evenementen zoals studiegroepen, hackathons en conferenties
**Alle freeCodeCamp moderators zijn globale moderators. Dat betekent dat wij u vertrouwen om toezicht te houden op al onze platforms.**
Dit gezegd hebbende, kunt u dienen als moderator op welke plaatsen u het meest interesseert. Sommige moderators helpen gewoon op GitHub. Anderen helpen gewoon op het forum. Sommige moderators zijn overal actief.
Wij willen dat je van moderator geniet en investeer je schaarse tijd op plaatsen die voor u interessant zijn.
> [!NOTE] "Met grote macht komt grote verantwoordelijkheid." - Oom Ben - Oom Ben
Als moderator is temperament belangrijker dan technische vaardigheden.
Luister. Wees nuttig. Maak geen misbruik van uw macht.
freeCodeCamp is een inclusieve gemeenschap en we moeten het zo houden.
We hebben één enkele gedragscode die onze hele gemeenschap reguleert. Hoe minder regels, hoe gemakkelijker men zich kan herinneren. U kunt deze regels lezen en ze toewijzen aan het geheugen [hier](https://code-of-conduct.freecodecamp.org).
# Moderating GitHub
Moderators hebben de mogelijkheid om problemen te sluiten en pull requests te accepteren of af te sluiten.
Moderators hebben twee primaire verantwoordelijkheden met betrekking tot GitHub:
1. QA'en en samenvoegen van pull requests
2. Evalueren en reageren op problemen
## Pull Requests modereren
Pull Requests (PR's) zijn hoe bijdragers wijzigingen verzenden naar de freeCodeCamp's repository. Het is belangrijk dat we kwaliteitsborging (QA) uitvoeren op aanvragen voor pull requests voordat we besluiten deze samen te voegen of te sluiten.
### Soorten Pull requests
1. **Uitdagingsinstructies bewerkingen** Dit zijn wijzigingen in de tekst van uitdagingen - de beschrijving, instructies of test tekst. Je kunt deze rechten ook bekijken op GitHub en beslissen of je ze wilt samenvoegen. We moeten hier wat voorzichtiger mee omgaan, want miljoenen mensen zullen deze tekst tegenkomen terwijl ze via het freeCodeCamp curriculum werken. Maakt de pull-aanvraag de tekst duidelijker zonder de tekst veel langer te maken? Zijn de bewerkingen relevant en niet al te pietluttiek? Vergeet niet dat ons doel is dat uitdagingen zo duidelijk en zo kort mogelijk zijn. Ze zijn niet de plek voor duistere details. Bovendien kunnen bijdragers proberen koppeling toe te voegen aan middelen aan de uitdagingen. Je kunt deze pull-aanvragen sluiten en ze met dit antwoord beantwoorden:
> Bedankt voor je pull-aanvraag.
>
> Ik sluit dit pull-verzoek af. Voeg in plaats daarvan links en andere details toe aan het overeenkomstige handleidingartikel van de challenge.
>
> Als je denkt dat ik me vergis bij het sluiten van dit probleem, open het dan opnieuw en voeg dan verdere uitleg toe. Dank u wel, en een goede programmering.
2. **Uitdagingscode bewerkingen** Dit zijn wijzigingen in de code in een uitdaging - de Challenge Seed, Challenge Oplossing en Test Strings. Deze pull-verzoeken moeten van GitHub worden verwijderd en op je lokale computer worden getest om er zeker van te zijn dat de challenge tests nog steeds kunnen worden uitgevoerd met de huidige oplossing, en de nieuwe code introduceert geen fouten. Sommige bijdragers kunnen proberen extra tests toe te voegen om pedantische hoekzaken te dekken. We moeten oppassen dat we de uitdaging niet te ingewikkeld maken. Deze uitdagingen en hun tests moeten zo eenvoudig en intuïtief mogelijk zijn. Los van het algoritme uitdagingen en het prep-gedeelte van het interview moeten leerlingen in staat zijn om elke uitdaging binnen ongeveer 2 minuten op te lossen.
3. **Codebase Wijzigingen** Deze code wijzigt de functionaliteit van het freeCodeCamp platform zelf. Soms proberen bijdragers wijzigingen door te voeren zonder veel uitleg te geven, maar voor wijzigingen in de code moeten we ervoor zorgen dat de verandering echt nodig is. Dus deze pull-aanvragen moeten verwijzen naar een bestaande GitHub kwestie waarbij de redenen voor de verandering worden besproken. Dan kun je de pull-aanvraag op je computer openen en ze lokaal testen. Nadat je dit hebt gedaan, als de wijzigingen er goed uitzien, voegen ze ze nog niet samen. Je kunt reageren op het pull-verzoek dat "LGTM" zegt, en daarna @raisedadead vermelden zodat hij een laatste kijkje kan nemen.
### Hoe pull requests samenvoegen of sluiten
Ten eerste, wanneer je een pull-aanvraag voor QA kiest, moet je er zelf aan toewijzen. U kunt dit doen door te klikken op de "Wijs jezelf" link onder het "taak" deel in de rechterkolom van GitHub's interface.
Afhankelijk van het type pull-verzoek is het de overeenkomstige regels die hierboven worden vermeld.
Voordat u een pull request samenvoegt, zorg ervoor dat GitHub groene checkmarks heeft voor alles. Als er al een X is, kijk dan eerst na en ontdek hoe je ze eerst in groene vinkjes kunt laten veranderen.
Soms zal er sprake zijn van een samenvoegingsconflict. Dit betekent dat een ander pull-verzoek een wijziging heeft aangebracht in precies hetzelfde deel van datzelfde bestand. GitHub heeft een tool om deze samenvoegconflicten recht op GitHub aan te pakken. U kunt proberen deze conflicten aan te pakken. Gebruik gewoon uw beste oordeel. De wijzigingen van de pull-aanvraag staan bovenaan, en de wijzigingen van de Master branch staan onderaan. Soms zullen er overbodige informatie zijn die kan worden verwijderd. Voordat je klaar bent, zorg dat je de `<<<<<<`verwijdert, `======`, en `>>>>>>` die Git toevoegt om conflictgebieden aan te geven.
Als de pull-aanvraag klaar lijkt om samen te voegen (en geen goedkeuring van @raisedadead vereist), kan je deze doorgaan en samenvoegen. Zorg ervoor dat u de standaard functionaliteit "Squash and Merge" gebruikt op GitHub. Dit zal alle pull requests verpletteren in een enkele commit, wat de geschiedenis van Git veel leesbaarder maakt.
Vervolgens moet je reageren op het pull-verzoek, waarbij je de bijdrager persoonlijk bedankt.
Als de auteur van de pull request een "eerste keer bijdrager" is, moet je hen ook feliciteren met hun eerste samengevoegde pull request aan de repository. Je kunt naar de rechterbovenhoek van het lichaam van de PR's kijken om een eerste bijdrager te bepalen. Het zal `de eerste bijdrage` laten zien zoals hieronder wordt weergegeven:
![Copy_edits_for_Java_arrays_article_by_karentobo_%C2%B7_Pull_Request__20615_%C2%B7_freeCodeCamp_freeCodeCamp6.690x281](https://i.imgur.com/dTQMjGM.png)
Als de pull request niet klaar lijkt om samen te voegen kan je beleefd antwoorden aan de auteur vertellen wat ze moeten doen om hem klaar te krijgen. Hopelijk zullen zij antwoord geven en hun pull-verzoek dichter bij elkaar brengen.
Vaak is een pull-aanvraag duidelijk weinig inspanning. U kunt dit vaak meteen vertellen toen de bijdrager de selectievakjes in het Pull Request-sjabloon niet controleerde, of gebruikte een algemene pull request titel zoals "made changes" of "Update index.
Er zijn ook situaties waarin de bijdrager probeert een link toe te voegen naar zijn eigen website. of voeg een bibliotheek toe die ze zelf hebben gemaakt, of heeft een lichtzinnige bewerking die niemand helpt behalve zichzelf.
In beide gevallen moet u hun pull-aanvraag afsluiten en antwoorden met deze standaardboodschap:
> Bedankt voor het openen van dit pull-verzoek.
>
> Dit is een standaard bericht dat we je pull-aanvraag hebben beoordeeld en hebben besloten deze niet samen te voegen. Wij zouden graag toekomstige aanvragen van u ontvangen.
>
> Dank u wel en prettige programmering.
Als je een tweede mening nodig hebt over een pull-verzoek, ga dan door en laat je commentaar achter over het pull-verzoek. voeg dan het label "discussie" toe aan het pull-verzoek.
## GitHub problemen modereren
freeCodeCamp is een actief open source project. Dagelijks krijgen we nieuwe kwesties, die allemaal moeten worden getriaged en geëtiketteerd.
### GitHub problemen
1. **Code Help-verzoeken**, waarvoor mensen per ongeluk GitHub problemen hebben gemaakt. Als iemand om hulp vraagt, plak dan de volgende boodschap en sluit het probleem af.
> Dank u voor het melden van deze kwestie.
>
> Dit is een standaardbericht dat u informeert dat dit probleem een verzoek om hulp lijkt te zijn. In plaats van hier om hulp te vragen, klik op de \*\*"Help"\*\* knop op de challenge op freeCodeCamp, waarmee je een vraag in het juiste deel van het forum kunt maken. Vrijwilligers op het forum reageren meestal binnen een paar uur op vragen en kunnen helpen te bepalen of er een probleem is met uw code of de challenge tests.
>
> Als de forumleden bepalen dat er niets mis is met uw code, kunt u verzoeken dit probleem te heropenen.
>
> Dank u wel en prettige programmering.
2. **Bug or Clarification issues** Probeer de bug zelf te reproduceren als je kunt. Zo niet, vraag ze om de stappen om de bug te reproduceren en of ze screenshots hebben, video's of aanvullende details die u kunnen helpen het probleem te reproduceren. Zodra u het probleem kunt reproduceren - of ten minste kunt bevestigen dat het een legit issue is - label het `bevestigd`. Dan:
- Als het een eenvoudige wijziging is in een bestaande uitdaging, label dan alleen als `eerste keer`, anders label als `help wil`. Gebruik andere labels als geschikt.
- Als het probleem significanter is, flag dan als `bug`. &nbsp; Als er onduidelijkheid bestaat over de juiste koers in een kwestie voel je vrij om @raisedadead over het probleem te labelen en voeg vervolgens het `Discussing` label toe.
3. **Duplicate Issues** Als een probleem hetzelfde is als een ander gerapporteerd probleem, moet het eerder gerapporteerde issue voorrang krijgen. Meld als `Duplicaat`, plak het volgende bericht dat `#XXXXX` vervangt met het issuenummer, en sluit daarna het issue af.
> Dank u voor het melden van deze kwestie.
>
> Dit is een standaard bericht dat lijkt op een issue dat lijkt op #XXXXX, dus ik sluit het af als een dubbel.
>
> Als je denkt dat ik me vergis bij het sluiten van dit probleem, open het dan opnieuw en voeg dan verdere uitleg toe. Dank u wel en prettige programmering.
4. **is opgelost in staging** Sommige problemen kunnen al zijn opgelost, maar er is geen GitHub probleem aan gekoppeld. Als dit het geval is, kunt u het volgende bericht plakken, het probleem sluiten en een `status toevoegen: opgelost/verzend` label:
> Dank u voor het melden van deze kwestie.
>
> Dit is een standaardbericht dat u meedeelt dat het probleem dat u hier noemde aanwezig is in de productie. maar dat is al vastgelopen. Dit betekent dat als we de volgende keer onze bouwsector naar de productie verschuiven, dit probleem moet worden opgelost. Daarom sluit ik deze kwestie af.
>
> Als je denkt dat ik me vergis bij het sluiten van dit probleem, open het dan opnieuw en voeg dan verdere uitleg toe. Dank u wel en prettige programmering.
### Sluiting Stal, verouderd, Inactieve Issues en Pull Requests
- Verouderde problemen of PRs zijn die welke geen activiteit van de OP hebben gezien gedurende 21 dagen (3 weken vanaf de laatste activiteit), maar pas nadat een moderator meer informatie/wijzigingen heeft aangevraagd. Deze kunnen worden gesloten in een geautomatiseerd bot script of door de moderators zelf.
- Activiteit is gedefinieerd als: Reacties die een update vragen op de PR en triages zoals `status: benodigd` label etc.
- Als de OP om extra hulp of zelfs om tijd vraagt, kan het bovengenoemde worden versoepeld en na een antwoord worden herzien. In elk geval moeten de mods hun beste oordeel gebruiken om de uitstaande PR's status op te lossen.
### Andere richtlijnen voor moderators op GitHub
Alhoewel u schrijftoegang zult hebben tot de freeCodeCamp's repository, **moet u nooit rechtstreeks code pushen naar freeCodeCamp repositories**. Alle code moet freeCodeCamp's codebase invoeren in de vorm van een pull-aanvraag van een vork van de repository.
U mag ook nooit uw eigen PRs accepteren. Ze moeten QA worden uitgevoerd door een andere moderator, net als bij elke andere PR.
Als je iemand opmerkt die de [gedragscode](https://code-of-conduct.freecodecamp.org) schendt op GitHub problemen, of opent pull requests met kwaadaardige inhoud of code, e-mail dev@freecodecamp. rg met een link naar de aanstootgevende pull-aanvraag en we kunnen overwegen om ze volledig te bannen uit freeCodeCamp's GitHub organisatie.
# Modereer het Forum
Als Moderator houd je onze gemeenschap een leuke plek voor iedereen om te leren en hulp te krijgen. Je houdt je bezig met gemarkeerde berichten en behandelt spam, off-topic en andere ongepaste gesprekken.
Merk op dat zodra je moderator bent op het forum, je blauwe hints van de moderator over de forumleden zal zien zoals "dit is de eerste keer dat [person] iets geplaatst heeft - laten we ze welkom heten in de gemeenschap! of "[person] is niet lang gepost - laten we hen terug verwelkomen."
![Een blauw sms die zegt "dit is de eerste keer dat [person] gepost heeft - laten we ze welkom heten in de gemeenschap!](https://i.imgur.com/mPmVgzK.png)
Dit zijn mogelijkheden voor u om ze te verwelkomen en ze extra speciaal te laten voelen. U weet nooit wie er in een klein stadium bij betrokken is, onze superhelper kan worden en vele andere mensen kan helpen bij hun codeerreis. Zelfs de kleinste vriendelijkheid kan leiden tot een cascade van goede daden.
### Forum berichten verwijderen
Forum moderators hebben de mogelijkheid om berichten van gebruikers te verwijderen. Je moet dit alleen doen voor de volgende instanties:
1. Iemand heeft een pornografisch of grafisch gewelddadig beeld geschetst.
2. Iemand heeft een link of code gepost die kwaadaardig van aard is en andere campers die erop klikken, kan schaden.
3. Iemand heeft een conversatie overspoeld met veel spamberichten.
### Omgaan met spam
Stuur hen een bericht om het probleem uit te leggen voor de eerste spampost van een gebruiker, en verwijder de link of post naar behoren. Laat een notitie achter op het gebruikersprofiel met uitleg over de actie die u hebt ondernomen. Als het probleem aanhoudt, volg dan het bovenstaande proces. Sneller blokkeert de gebruiker om te posten (gebruik de stilte optie op het Admin paneel) en stuur daarna een waarschuwing met de Gedragscode. Vink het vakje aan in het privébericht dat aangeeft dat uw bericht een "formele waarschuwing" is.
U kunt vragen stellen en incidenten rapporteren in het [staff forum sectie](https://forum.freecodecamp.com/c/staff).
### Omgaan met off-topic gesprekken
Berichten of topics die op de verkeerde plek lijken te staan, kunnen opnieuw gecategoriseerd worden of hernoemd worden naar wat gepast is.
In uitzonderlijke omstandigheden kan het gepast zijn als een moderator een discussie in meerdere threads plaatst.
Nogmaals, als je problemen of vragen hebt, maak dan een bericht met je acties in de personeelscategorie, en label een andere moderator als je wilt dat ze je modererende acties herzien.
### minderjarige gebruikers
Onze gebruiksvoorwaarden vereisen dat gebruikers van freeCodeCamp ten minste 13 jaar oud zijn. In het geval dat een gebruiker onthult dat hij jonger dan 13 jaar is. stuur hen het onderstaande bericht en verwijder hun forumaccount (als het verwijderen niet beschikbaar is, het opschorten van het account is voldoende). Email vervolgens [Quincy](https://forum.freecodecamp.org/u/QuincyLarson) (quincy@freecodecamp.org) of [Mrugesh](https://forum.freecodecamp.org/u/raisedadead) (mrugesh@freecodecamp.org) om ook de freeCodeCamp account van de gebruiker te verwijderen.
```markdown
SUBJECT: Gebruikers onder de 13 hebben geen toestemming om het forum per Gebruiksvoorwaarden te gebruiken
Het is onder onze aandacht gebracht dat u jonger bent dan 13 jaar. Per de [freeCodeCamp voorwaarden](https://www.freecodecamp.org/news/terms-of-service), moet je ten minste 13 jaar oud zijn om de site of het forum te gebruiken. We zullen zowel uw freeCodeCamp account en uw forum account verwijderen. Deze beperking houdt ons aan de wetten van de Verenigde Staten.
Gelieve opnieuw aan te sluiten zodra u ten minste 13 jaar heeft bereikt.
Dank u voor uw begrip.
```
# Facebook modereren
Als je iets ziet dat onze [Gedragscode](https://code-of-conduct.freecodecamp.org/)lijkt te breken, moet je het onmiddellijk verwijderen.
Soms zullen mensen dingen posten waarvan ze denken dat ze grappig zijn. Ze realiseren zich niet dat wat ze zeiden of wat ze deelden, als beledigend kan worden geïnterpreteerd. In deze gevallen moet hun post worden verwijderd, maar degene die haar gedetacheerd heeft hoeft niet per se te worden verboden. Door hun post te laten verwijderen, zullen ze hopelijk begrijpen dat wat ze hebben gepost niet gepast was.
Maar als het een grove belediging is die redelijkerwijs niet kan worden toegeschreven aan een cultureel verschil of aan een misverstand over de Engelse taal. dan moet je sterk overwegen om het lid van de Facebook-groep te blokkeren.
# Modereer Discord
Dit is hoe moderators omgaan met schendingen van onze [Gedragscode](https://code-of-conduct.freecodecamp.org/) op Discord:
1. **Zorg ervoor dat het bedoeld was om de Gedragscode te schenden.** Niet alle overtredingen van de CoC waren als zodanig bedoeld. Een nieuwe camper kan een grote hoeveelheid code posten voor hulp, zonder te weten dat dit als spam kan worden beschouwd. In deze gevallen kun je ze gewoon vragen om hun code te plakken met diensten zoals Codepen of Pastebin.
2. **Als het kamp de Gedragscode duidelijk schendt, zal de moderator als volgt te werk gaan:**
- Schorst de levendige kamper maar waarschuw hem niet of bedreigt ze. In plaats daarvan geef ze rustig de onderbroken rol op Discord, en stuur ze dan het volgende bericht:
```
Dit is een standaard bericht dat ik u tijdelijk moest onderbreken om te praten op de freeCodeCamp Discord server.
Ik ben een moderator die namens onze open source gemeenschap optreedt. Ik kan overwegen om je schorsing op te heffen, maar je moet eerst de volgende 3 stappen zetten:
1. Lees onze Gedragscode: https://code-of-conduct.freecodecamp.org/
2. Bericht me terug en bevestig dat je klaar bent met lezen. 3. Leg me uit waarom je denkt dat ik je heb geschorst en waarom ik je schorsing moet opheffen.
```
- Rapporteer een korte samenvatting van het evenement en hoe ze daarop hebben gereageerd in het #admin kanaal. Hier is een voorbeeld van hoe een dergelijke samenvatting eruit zou kunnen zien:
```
Opgeschorst: _@username_
Reden(en): _Spamming, trolling_
vidence: _Eén of meer koppelingen naar de offend bericht(en)_
CoC: _Verzonden_
```
- Een rapport voor het opheffen van de opschorting zou er als volgt uit moeten zien:
```
Ik heb de schorsing van ` @username ` verwijderd. Ik heb ze de Gedragscode gestuurd. Zij hebben zich juist vandaag gerealiseerd dat zij werden geschorst en zich verontschuldigd hebben voor wat zij hebben gedaan.
```
- Op basis van het antwoord van de overtreders zal de moderator beslissen of hij de schorsing van het overtredende kamp wil verwijderen. Als ze respectvol en apologetisch lijken, kan de moderator de schorsing verwijderen. Wat het beleid betreft, zullen de gematigden zich tijdens dit proces beleefd gedragen, hoe slecht de misdadige kamper zich ook gedraagt. Als ze de Code niet respecteren of niet willen accepteren, moet de opschorting worden gevolgd met een verbod van de Discord server. Gebruik dezelfde samenvatting als hierboven, maar vervang "Verstoppen:" door "Verbannen:".
3. **Hoe verbannen en/of unbannen**
- Om iemand te verbannen, klik met de rechtermuisknop op zijn gebruikersnaam/profielfoto en selecteer "Ban <username>". U krijgt de optie om hun vorige berichten te verwijderen - selecteer "Niets verwijderen", aangezien de boodschappen een historisch record moeten blijven.
- Als je besluit om iemand te verbieden betekent dat dat ze niet bereid zijn zich aan onze gedragscode te houden. Daarom hoeft er zelden een verbod op een Camper te worden ingesteld. Als er echter behoefte aan is, kunt u dit doen door op de servernaam te klikken, door te kiezen voor "Serverinstellingen", kies voor "Bans", selecteer de gebruiker die je wilt unbannen, en klik op "Banaan intrekken".
Discord Bans zijn globaal - je kunt geen gebruiker verbannen van een specifiek kanaal, alleen van de hele server.
4. **Berichten verwijderen** moderators kunnen berichten verwijderen op Discord. Zij moeten alleen in vier zeer specifieke situaties gebruik maken van deze mogelijkheden:
- Iemand heeft een pornografisch of grafisch gewelddadig beeld geschetst.
- Iemand heeft een link of code gepost die kwaadaardig van aard is en andere campers die erop klikken, kan schaden.
- Iemand heeft de chat overspoeld met veel spam berichten (meestal met bots) om chat volledig onbruikbaar te maken.
- Iemand heeft advertenties en/of een zelfbevorderend bericht / afbeelding (social media) geplaatst.
In alle andere situaties - zelfs in situaties waarin de gedragscode wordt geschonden - mogen de moderators de boodschap niet verwijderen, aangezien dit een belangrijk historisch record is. Wanneer je een bericht verwijdert, zorg er dan voor dat je er eerst een screenshot van maakt! De schermafbeelding kan worden ingelogd in het #mod-log kanaal, maar voor de #activity-log is het voldoende om te zeggen dat het bewijs is verwijderd door "gevoelige inhoud". Opmerking: als het bericht materiaal bevat dat illegaal is om een schermafbeelding van te maken kopieer in plaats daarvan de berichtkoppeling - geef die link naar @raisedadead om door te sturen naar het Discord's Trust en Safety team.
5. **Gebruik niet @all of @here** niet @all of @here onder alle omstandigheden! Elke persoon in die chat room krijgt een melding. In sommige gevallen zijn er tienduizenden mensen. Als je wilt dat mensen een aankondiging zien, kun je die op het kanaal zetten zodat iedereen ze kan lezen.
6. **dreigen niet met het verbieden of opschorten** Als een kamper de gedragscode schendt dreigen ze niet te verbieden of op te schorten en waarschuwt ze ook niet in het openbaar. Praat met hen in plaats daarvan privé, of stuur hen een DM en geef een opschorting (per bovengenoemde protocol). Niemand anders in dat kanaal hoeft te weten dat u de persoon hebt verbannen / opgeschort - campers kunnen de samenvatting in het #activity-log kanaal bekijken als ze die informatie willen behouden. Als een overtreding duidelijk onbedoeld was en geen opschorting of privégesprek rechtvaardigt, maak de kwaadaardige camper op de hoogte van zijn of haar acties zonder het als waarschuwing te laten overkomen. Bijvoorbeeld:
- Camper een prikbord met code om hulp te vragen
Moderator: @username Gebruik Codepen of Pastebin bij het plaatsen van grote hoeveelheden code.
- Of als je echt moet uitleggen waarom:
Moderator: @username Gebruik Codepen of Pastebin bij het plaatsen van grote hoeveelheden code omdat het de chat voor iedereen verstoort en als spamming kan worden beschouwd volgens onze gedragscode.
- Voor milde en onopzettelijke schendingen van de gedragscode
Moderator: Dit is een vriendelijke herinnering voor iedereen om de gedragscode te volgen: https://code-of-conduct.freecodecamp.org/
7. **Niet schromen om moderator te zijn** Zie jezelf niet als hierboven de gemeenschap. U bent de community. En de gemeenschap vertrouwt je op het beschermen van iets zeldzaam dat we allemaal delen - een _welkome_ plaats voor nieuwe ontwikkelaars. Als je bang bent om een moderator te zijn, kunnen mensen zich ongemakkelijk voelen om je heen op dezelfde manier als mensen zich ongemakkelijk kunnen voelen rond een politieagent, zelfs als ze niets verkeerd doen. Dat is gewoon menselijk van aard.
8. **Ontmoet andere moderators** Als je het niet eens bent met de actie van een moderator praat met hen privé of breng het op in het #mod-chatkanaal. Overschrijft nooit een ban en spreekt nooit de andere moderator(s) publiekelijk tegen. Neem in plaats daarvan een koelbloedige discussie in het gekletter en overtuig de moderator ervan dat hij zelf zijn verbod moet omkeren of zijn standpunt moet wijzigen. Vergeet niet dat we allemaal in hetzelfde team zitten. We willen de rol van de moderators waarmaken en een gemeenschappelijk front vormen.
9. **Praat met andere moderators** We hebben alleen een ruimte voor moderators. Gebruik het! Als je je ongemakkelijk voelt met het omgaan met een bepaalde situatie, vraag dan andere moderators om hulp. Als u denkt dat er iets besproken moet worden, moet u dat doen. Je maakt deel uit van het team en wij waarderen de invoer van elk teamlid! Zelfs als je het totaal oneens bent met iets in deze richtlijnen of de gedragscode!
10. **Tijdelijk inactief** Als je niet actief zal zijn als moderator voor een tijdje door vakantie ziekte of welke andere reden dan ook, zorg ervoor dat je de anderen op de hoogte houdt in het #mod-chatkanaal. Dit is dus zo dat we weten of we erop kunnen rekenen dat u regelmatig in de server actief bent of niet.
# Hoe moderator worden
Als je mensen in de gemeenschap in de loop der tijd consequent helpt, zal ons Moderator Team uiteindelijk aandacht krijgen, en een van hen zal je noemen als een mogelijke moderator voor [onze staf](https://forum.freecodecamp.org/g/Team). Er zijn geen snelkoppelingen om moderator te worden.
Als je goedgekeurd bent, voegen we je toe aan onze Moderator Teams op [GitHub](https://github.com/orgs/freeCodeCamp/teams/moderators), [forum](https://forum.freecodecamp.org/g/moderators), etc.
> [!NOTE] > **Voor GitHub:** Nadat u bent geaccepteerd als moderator, ontvangt u een uitnodiging voor de repository van Github. Je moet naar [freeCodeCamp GitHub Organisation](https://github.com/orgs/freeCodeCamp/invitation) gaan om de uitnodiging te kunnen accepteren. Dit is vereist voor ons om je schrijfrechten te kunnen geven op enkele van onze repositories.
# Hoe we inactieve moderators stoppen
Houd er rekening mee dat we vaak mods verwijderen waarvan we denken dat ze inactief zijn. Wanneer we dit doen, sturen we de volgende boodschap:
> Dit is een standaard bericht dat je hiervan op de hoogte stelt, Aangezien je de laatste tijd geen actieve moderator bent geweest, verwijderen we je uit ons Moderator team. Wij waarderen uw hulp in het verleden ten zeerste.
> Als je denkt dat we dit ten onrechte hebben gedaan, of als je er klaar voor bent om terug te komen en er meer bij te dragen, antwoord gewoon op dit bericht dat mij laat weten.
# Hoe de werkruimte van onze bijdragers werkt
Iedereen is welkom in de [Bijdragers kamer in onze Discord](https://discord.gg/KVUmVXA). Het is de aangewezen chat room voor moderators en andere kampers die op allerlei manieren bijdragen aan onze gemeenschap. inclusief via studiegroepen.
We gaan ervan uit dat bijdragers alles in deze kamer zullen lezen dat ze direct noemt met een `@username`. Al het andere is optioneel. Maar voel je vrij om alles te lezen wat daar post is en om interactie.
# Omgaan met verzoeken
U kunt benaderd worden door organisaties die op de een of andere manier willen samenwerken met freeCodeCamp. Als je beseft dat dit is wat ze willen, stop dan met te praten met hen en vertel ze om quincy@freecodecamp.org te e-mailen. Hij krijgt altijd voorstellen als deze en is in de beste positie om te beoordelen of een dergelijke relatie het waard is voor onze gemeenschap (en dat gebeurt zelden ook).
# Omgaan met (geestelijke) gezondheidsonderzoeken
Je kunt situaties tegenkomen waarin gebruikers medisch advies zoeken of zich bezighouden met psychische gezondheidsproblemen en op zoek zijn naar ondersteuning. Politiek gezien zou u moeten vermijden om over deze zaken privé te praten. Mocht de situatie op een gegeven moment teruggaan naar fCC, dan willen we de gesprek(sen) in de notulen laten opnemen. Maak het duidelijk dat wij geen medische professionals zijn en dat u de gebruiker aanmoedigt om professionele hulp te vinden. Hoe moeilijk het soms ook kan zijn, vermijd andere tips of adviezen te geven dan de gebruiker te wijzen in de richting van professionele hulp!
Als dit gebeurt op Discord: breek de gebruiker op. Dit is niet om hen te bestraffen! Het schorsen van een gebruiker zal een privékanaal aanmaken dat alleen toegankelijk is voor de gebruiker en het team. Dit zal zowel de gebruiker als fCC op verschillende manieren ten goede komen:
- De gebruiker is gegarandeerd wat privacy
- Openbare chat is niet langer onderbroken
- Andere teamleden kunnen zich inlaten, mocht u zich ongemakkelijk voelen om de situatie zelf aan te pakken
> [!NOT] Een gebruiker die een gebruiker blokkeert geeft hem automatisch een bericht over het lezen van onze gedragscode. Zorg ervoor dat je de gebruiker informeert dat je hem hebt geschorst om hem privacy te geven en dat hij niet wordt gestraft. Dat is heel belangrijk! We willen absoluut vermijden om gebruikers het idee te geven dat ze gestraft worden voor het bereiken van hulp op je manier!
Als u denkt dat de gebruiker in staat is om opnieuw deel te nemen aan de community, klik dan met de rechtermuisknop op het privékanaal en kopieer het ID. Plaats het volgende bericht in het #mod-log:
> Referentie medisch advies: <channel ID> <username>
Daarna kunt u de opschortingen van de gebruiker verwijderen, zoals u normaal doet.
Nuttige URL's:
http://www.zelfmoord.org/internationaal-zelfmoord-hotlines.html
# Een opmerking over de vrijheid van meningsuiting
Soms zullen mensen iets beledigend of opruiend verdedigen dat ze als "vrije meningsuiting" hebben betiteld.
Deze XKCD-comic vat perfect de gedachten van de meeste gemeenschappen over de vrijheid van meningsuiting samen. Dus als iemand iets verdedigt dat hij als "vrije meningsuiting" zegt, voel je vrij om het naar hem te sturen.
<div align="center"><img src='https://aws1.discourse-cdn.com/freecodecamp/original/3X/4/3/43a8b2eafe4c8622e02838f66f1dc6227de32c70.png' width="400" height="400" /></div>
Bedankt voor het lezen van dit en bedankt voor het helpen van de ontwikkelaargemeenschap!

Some files were not shown because too many files have changed in this diff Show More