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

fix(docs): Configure docs folder with Crowdin (#40776)

Browse Source
This commit is contained in:
Randell Dawson
2021-01-24 20:09:57 -07:00
committed by GitHub
parent d41630ee19
commit 32e80aa351
415 changed files with 111 additions and 81794 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
docs/_translations.md
View File

@ -9,33 +9,10 @@
<div class='i18n-lang-list'>
- [English](/index.md)
- [Afrikaans](/i18n/Afrikaans/index.md)
- [Arabic](/i18n/Arabic/index.md)
- [Catalan](/i18n/Catalan/index.md)
- [Chinese](/i18n/Chinese/index.md)
- [Czech](/i18n/Czech/index.md)
- [Danish](/i18n/Danish/index.md)
- [Dutch](/i18n/Dutch/index.md)
- [Finnish](/i18n/Finnish/index.md)
- [French](/i18n/French/index.md)
- [German](/i18n/German/index.md)
- [Greek](/i18n/Greek/index.md)
- [Hebrew](/i18n/Hebrew/index.md)
- [Hindi](/i18n/Hindi/index.md)
- [Hungarian](/i18n/Hungarian/index.md)
- [Italian](/i18n/Italian/index.md)
- [Japanese](/i18n/Japanese/index.md)
- [Korean](/i18n/Korean/index.md)
- [Norwegian](/i18n/Norwegian/index.md)
- [Polish](/i18n/Polish/index.md)
- [Portuguese](/i18n/Portuguese/index.md)
- [Romanian](/i18n/Romanian/index.md)
- [Russian](/i18n/Russian/index.md)
- [Serbian](/i18n/Serbian/index.md)
- [Swedish](/i18n/Swedish/index.md)
- [Turkish](/i18n/Turkish/index.md)
- [Ukrainian](/i18n/Ukrainian/index.md)
- [Vietnamese](/i18n/Vietnamese/index.md)
- [Chinese](/i18n/chinese/index.md)
- [Espanol](/i18n/espano/index.md)
- [Hindi](/i18n/hindi/index.md)
- [Italian](/i18n/italian/index.md)
</div>

24
docs/crowdin.yml
View File

@ -1,4 +1,4 @@
"project_id_env": "CROWDIN_PROJECT_ID_DOCS"
"project_id_env": "CROWDIN_PROJECT_ID"
"api_token_env": "CROWDIN_PERSONAL_TOKEN"
"base_path_env": "CROWDIN_BASE_PATH"
"base_url_env": "CROWDIN_BASE_URL"
@ -7,22 +7,14 @@
files: [
{
"source" : "/*.md",
"translation" : "/i18n/%language%/%original_file_name%",
"source" : "/docs/*.md",
"translation" : "/docs/i18n/%language%/%original_file_name%",
"ignore" : [
"_coverpage.md",
"_navbar.md",
"_translations.md",
"README.md",
],
# "languages_mapping" : {
# "language" : {
# }
# },
"update_option": "update_without_changes"
"/docs/_coverpage.md",
"/docs/_navbar.md",
"/docs/_translations.md",
"/docs/README.md",
]
}
]

38
docs/i18n/Arabic/_sidebar.md
View File

@ -1,38 +0,0 @@
- **Getting Started**
- [Introduction](index.md "Contribute to the freeCodeCamp.org Community")
- [Frequently Asked Questions](FAQ.md)
- **Code Contribution**
- [إعداد freeCodeCamp محليا](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)
---
<!-- The section below should not use relative linking -->
- **中文社区贡献指南**
- [成为专栏作者](/i18n/Chinese/news-author-application.md)
- [文章翻译计划](/i18n/Chinese/news-translations.md)
- [视频翻译计划](/i18n/Chinese/video-translations.md)
<!-- The section above should not use relative linking -->
---
- **Flight Manuals** (for Staff & Mods)
- [Moderator Handbook](moderator-handbook.md)
- [DevOps Handbook](devops.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)

54
docs/i18n/Chinese/how-to-work-on-the-docs-theme.md
View File

@ -1,54 +0,0 @@
# 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:
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
docsify serve docs
```
Install `docsify`:
```console
npm install -g docsify
```
and serve the `/docs` directory
```console
docsify serve docs
```
Alternatively, if you have installed freeCodeCamp locally (see the local setup guide), we bundle the CLI with the development tools so you can run any of the below commands as needed from the root of the repo:
### Serve and launch the documentation site only
```console
npm run docs:serve
```
### Serve the documentation site alongside freeCodeCamp locally:
```console
npm run develop
```
> The documentation site should be available at <http://localhost:3200>

456
docs/i18n/Chinese/moderator-handbook.md
View File

@ -1,456 +0,0 @@
# 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!
## 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 ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
```
### Closing invalid pull requests
> When PR is invalid.
```markdown
Hey @username
Thank you for opening this pull request.
This is a standard message notifying you that we've reviewed your pull request and have decided not to merge it. We would welcome future pull requests from you.
Thank you and happy coding.
```

82
docs/i18n/Czech/FAQ.md
View File

@ -1,82 +0,0 @@
### 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 comprehensive reference for first-timer-friendly projects. And it includes a lot of open source contribution tips.
### Can I translate freeCodeCamp's curriculum?
Yes. We will roll out the tools for translating freeCodeCamp's curriculum soon.
Eventually, we intend to localize freeCodeCamp into several major world languages, starting with: Arabic, Chinese, Hindi, Portuguese, Russian, and Spanish.
### 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 these GitHub issues are for codebase-related issues and discussions – not for getting help with learning to code. Whenever in doubt, you should [seek assistance on the forum](https://forum.freecodecamp.org) before creating a GitHub issue.
### 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 work on a feature for academic credits?
Yes. Please note we are unable to commit to any timelines or paperwork that may be a requirement by your college or university. We receive many pull-requests and code contributions by volunteer developers, and we respect their time and efforts. Out of respect for all of our other contributors, we will not give any PR special priority just because it happens to be school-related.
We request you to plan ahead and work on code contributions 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 special issues that are designed for people who have not contributed to the freeCodeCamp codebase before.
### 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. Please be sure to mention details in the pull request description to help us understand and review your contribution – even if it's just a minor change.
Please do create an issue if you want to discuss bigger aspects of the codebase or curriculum.
### How can I get an issue assigned to me?
We typically do not assign issues to anyone other than long-time contributors. Instead, we follow the below policy to be fair to everyone:
1. We are most likely to merge the first pull request that addresses the issue.
2. In the case of multiple contributors opening a pull request for the same issue at around the same time, we will give priority to the pull request that best addresses the issue. Some of the things we consider:
- Did you include tests?
- Did you catch all usecases?
- Did you ensure all tests pass, and confirm everything works locally?
3. Finally, we give priority to pull requests which follow our recommended guidelines.
- Did you follow the pull request checklist?
- Did you give your pull request a meaningful title?
### 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 `#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. If you ask us questions on the related issue threads, we will be glad to clarify. Be sure to search for your question before posting a new one.
Thanks in advance for being polite and patient. Remember – this community is run mainly by volunteers.
**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`**

38
docs/i18n/Czech/_sidebar.md
View File

@ -1,38 +0,0 @@
- **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)
---
<!-- The section below should not use relative linking -->
- **中文社区贡献指南**
- [成为专栏作者](/i18n/Chinese/news-author-application.md)
- [文章翻译计划](/i18n/Chinese/news-translations.md)
- [视频翻译计划](/i18n/Chinese/video-translations.md)
<!-- The section above should not use relative linking -->
---
- **Flight Manuals** (for Staff & Mods)
- [Moderator Handbook](moderator-handbook.md)
- [DevOps Handbook](devops.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)

708
docs/i18n/Czech/devops.md
View File

@ -1,708 +0,0 @@
# DevOps Handbook
This guide will help you understand our infrastructure stack and how we maintain our platforms. While this guide does not have exhaustive details for all operations, it could be used as a reference for your understanding of the systems.
Let us know, if you have feedback or queries, and we will be happy to clarify.
# Flight Manual - Code deployments
This repository is continuously built, tested and deployed to **separate sets of infrastructure (Servers, Databases, CDNs, etc.)**.
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).
## Trigger a build, test and deploy
Currently, only members on the developer team can push to the production branches. The changes to the `production-*` branches can land only via fast-forward merge to the [`upstream`](https://github.com/freeCodeCamp/freeCodeCamp).
> [!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.
# Flight Manual - Server Maintenance
> [!WARNING]
>
> 1. The guide applies to the **freeCodeCamp Staff members only**.
> 2. These instructions should not be considered exhaustive, please use caution.
As a member of the staff, 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/Czech/how-to-catch-outgoing-emails-locally.md
View File

@ -1,100 +0,0 @@
> **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/Czech/how-to-help-with-video-challenges.md
View File

@ -1,199 +0,0 @@
# 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/Czech/how-to-open-a-pull-request.md
View File

@ -1,179 +0,0 @@
# How to open a Pull Request (PR)
A pull request (PR) enables you to send changes from your fork on GitHub to freeCodeCamp.org's main repository. Once you are done making changes to the code, you can follow these guidelines to open a PR.
## 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.
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
> [!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/Czech/how-to-setup-freecodecamp-locally.md
View File

@ -1,546 +0,0 @@
Follow these guidelines for setting up freeCodeCamp locally on your system. This is highly recommended if you want to contribute regularly.
Some of these contribution workflows – like fixing bugs in the codebase or curriculum – need you to run freeCodeCamp locally on your computer.
> [!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.)
### How to prepare your local machine
Start by installing the prerequisite software for your operating system.
We primarily support development on Linux and Unix-based systems. Our staff and community contributors regularly work with the codebase using tools installed on Ubuntu and macOS.
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 ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
> [!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, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
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/Czech/how-to-setup-wsl.md
View File

@ -1,129 +0,0 @@
# 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/Czech/how-to-use-docker-on-windows-home.md
View File

@ -1,15 +0,0 @@
# 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.

622
docs/i18n/Czech/how-to-work-on-coding-challenges.md
View File

@ -1,622 +0,0 @@
# How to work on coding challenges
Our goal is to develop a fun and clear interactive learning experience.
Designing interactive coding challenges is difficult. It would be much easier to write a lengthy explanation or to create a video tutorial. But for our core curriculum, we're sticking with what works best for most people - a fully interactive, video game-like experience.
We want campers to achieve a flow state. We want them to build momentum and blast through our curriculum with as few snags as possible. We want them to go into the projects with confidence and gain a wide exposure to programming concepts.
Note that for Version 7.0 of the freeCodeCamp curriculum, we are moving toward [an entirely project-focused model with a lot more repetition](https://www.freecodecamp.org/news/python-curriculum-is-live/).
Creating these challenges requires immense creativity and attention to detail. There's plenty of help available. You'll have support from a whole team of contributors to whom you can bounce ideas off and demo your challenges.
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
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 (e.g. "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:
```md
Use <code>parseInt</code> to convert the variable <code>realNumber</code> into an integer.
```
- References to file names and path directories (e.g. `package.json`, `src/components`) should be wrapped in `<code>` tags.
- 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**. See example below:
**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.
````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 single-quotes where applicable
**Note:** The equivalent _Markdown_ should be used, where applicable, in place of _HTML_ tags.
## 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
### Seed code comments
We have a [comment dictionary](/curriculum/dictionaries/english/comments.js) that contains the only comments that can be used within the seed code. The exact case and spacing of the dictionary comment must be used. The comment dictionary should not be expanded without prior discussion with the dev-team.
Comments used should have a space between the comment characters and the comment themselves. In general comments should be used sparingly. Always consider rewriting a challenge's description or instructions if it could avoid using a seed code comment.
Example of valid single line JavaScript comment:
```js
// Only change code below this line
````
Example of a valid CSS comment:
```js
/* Only change code above this line */
```
If a challenge only has a single place where code changes are needed, please use the comments in the following example to instruct the user where changes should be made.
```js
var a = 3;
var b = 17;
var c = 12;
// Only change code below this line
a = a + 12;
b = 9 + b;
c = c + 7;
```
If a challenge has multiple places where the user is expected to change code (i.e. the React challenges)
```jsx
class MyComponent extends React.Component {
constructor(props) {
super(props);
this.state = {
text: "Hello"
};
// Change code below this line
// Change code above this line
}
handleClick() {
this.setState({
text: "You clicked!"
});
}
render() {
return (
<div>
{ /* Change code below this line */ }
<button>Click Me</button>
{ /* Change code above this line */ }
<h1>{this.state.text}</h1>
</div>
);
}
};
```
### Translation of seed code comments
There are separate comment dictionaries for each language. The [English vesion of the comment dictionary](/curriculum/dictionaries/english/comments.js) is the basis for the translations found in the corresponding non-English versions of the files. The non-English version of the Chinese comment dictionary would be located at `/curriculum/dictionaries/chinese/comments.js`. Each dictionary consists of an array of objects with a unique `id` property and a `text` property. Only the `text` should be modified to encompass the translation of the corresponding English comment.
Some comments may contain a word/phrase that should not be translated. For example, variable names or proper library names like "React" should not be translated. See the comment below as an example. The word `myGlobal` should not be translated.
```text
Declare the myGlobal variable below this line
```
> [!NOTE]
>
> We are working on an integration to make it possible to work on i18n for the comment dictionary.
## 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>

54
docs/i18n/Czech/how-to-work-on-the-docs-theme.md
View File

@ -1,54 +0,0 @@
# 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:
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
docsify serve docs
```
Install `docsify`:
```console
npm install -g docsify
```
and serve the `/docs` directory
```console
docsify serve docs
```
Alternatively, if you have installed freeCodeCamp locally (see the local setup guide), we bundle the CLI with the development tools so you can run any of the below commands as needed from the root of the repo:
### Serve and launch the documentation site only
```console
npm run docs:serve
```
### Serve the documentation site alongside freeCodeCamp locally:
```console
npm run develop
```
> The documentation site should be available at <http://localhost:3200>

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

@ -1,99 +0,0 @@
# How to work on freeCodeCamp.org's developer news theme
The developer news also known as [`/news`](https://www.freecodecamp.org/news) site is powered by [Ghost](https://ghost.org/). We use a custom theme for the look and feel of the site. The source code of the theme is available here: <https://github.com/freeCodeCamp/news-theme>.
## The Theme
Ghost uses a simple templating language called [Handlebars](http://handlebarsjs.com/) for its themes. The theme used on `/news` is based off of the default [casper theme](https://github.com/TryGhost/Casper).
The default theme pretty heavily so that it should be fairly easy to work out what's going on just by reading the code and the comments. Once you feel comfortable with how everything works, Ghost also has a full [theme API documentation](https://themes.ghost.org) which explains every possible Handlebars helper and template.
**The main files are:**
- `default.hbs` - The main template file
- `index.hbs` - Used for the home page
- `post.hbs` - Used for individual posts
- `page.hbs` - Used for individual pages
- `tag.hbs` - Used for tag archives
- `author.hbs` - Used for author archives
One really neat trick is that you can also create custom one-off templates just by adding the slug of a page to a template file. For example:
- `page-about.hbs` - Custom template for the `/about/` page
- `tag-news.hbs` - Custom template for `/tag/news/` archive
- `author-ali.hbs` - Custom template for `/author/ali/` archive
## Development
1. Get Ghost installed locally.
```sh
npm install -g ghost-cli@latest
mkdir ghost-local-site
cd ghost-local-site
```
```sh
ghost install local
ghost start
```
> Note: Currently freeCodeCamp uses Ghost version `2.9.0`, so make sure you are using a version higher than that.
Be sure to run `ghost` commands from the `ghost-local-site` directory. Follow additional instructions on [Ghost's official documentation](https://docs.ghost.org) if are not familiar with its interface.
2. Fork and clone the repository in your theme directory:
```sh
cd content/themes/
git clone https://github.com/YOUR_USERNAME/news-theme.git
```
3. Make sure you have all the pre-requisites.
The theme styles are compiled using Gulp/PostCSS to polyfill future CSS spec. You'll need [Node.js](https://nodejs.org/). Make sure that your Node.js version is compatible with `ghost`.
4. Install dependencies and develop the theme
```sh
npm ci
npm run develop
```
5. Now you can edit `/assets/css/` files, which will be compiled to `/assets/built/` automatically.
6. Access the development site.
a. Enter `http://localhost:2368/ghost/` into your address bar. Continue with the setup prompted on the page (if running ghost for the first time).
b. _(One-time only, during setup)_ Restart Ghost, on a separate terminal once to ensure the theme is available.
```sh
cd ghost-local-site
ghost restart
```
c. _(One-time only, during setup)_ Once you've done this, go to `http://localhost:2368/ghost/#/settings/design` and scroll to the bottom. Make sure you click activate on the `freecodecamp-news-theme`.
7. Zip the final code and make a pull-request
The `zip` Gulp task packages the theme files into `dist/<theme-name>.zip`, which we can then upload to the production site.
When you make a PR, please make sure you have run the below script prior to commiting the code and sending a PR.
```sh
npm run zip
```
## Other Reference and resources
### PostCSS Features Used
- Autoprefixer - Don't worry about writing browser prefixes of any kind, it's all done automatically with support for the latest 2 major versions of every browser.
- Variables - Simple pure CSS variables
- [Color Function](https://github.com/postcss/postcss-color-function)
### SVG Icons
The theme uses inline SVG icons, included via Handlebars partials. You can find all icons inside `/partials/icons`. To use an icon just include the name of the relevant file, eg. To include the SVG icon in `/partials/icons/rss.hbs` - use `{{> "icons/rss"}}`.
You can add your own SVG icons in the same manner.

43
docs/i18n/Czech/index.md
View File

@ -1,43 +0,0 @@
The [freeCodeCamp.org](https://freecodecamp.org) community is possible thanks to thousands of kind volunteers like you. If you want to contribute your time and expertise, we would be excited to welcome you aboard.
> [!NOTE] Before you proceed, please take a quick 2 minutes to read our [Code of Conduct](https://www.freecodecamp.org/code-of-conduct). We strictly enforce it across our community so that contributing to freeCodeCamp.org is a safe, inclusive experience for everyone.
Happy contributing.
You are welcome to:
- Create, update and fix bugs in our [curriculum](#curriculum).
- Help us fix bugs in freeCodeCamp.org's [learning platform](#learning-platform).
- _(Coming Soon)_ Help us translate freeCodeCamp.org to world languages.
We answer the most common questions about contributing [in our contributor FAQ](/FAQ.md).
## Curriculum
Our curriculum is curated by the global freeCodeCamp community. This way, we are able to incorporate expert knowledge from volunteers like you.
You can help expand and improve the curriculum. You can also update project user stories to better-explain concepts. And you can improve our automated tests so that we can more accurately test people's code.
**If you're interested in improving our curriculum, here's [how to contribute to the curriculum](how-to-work-on-coding-challenges.md).**
## Learning Platform
Our learning platform runs on a modern JavaScript stack. It has various components, tools, and libraries. These include Node.js, MongoDB, OAuth 2.0, React, Gatsby, Webpack, and more.
Broadly, we use
- a Node.js based API server
- a set of React-based client applications
- and testing scripts to evaluate camper-submitted curriculum projects.
If you want to productively contribute to the curriculum, we recommend some familiarity with these tools.
If you want to help us improve our codebase...
**you can either use Gitpod, a free online dev environment that starts a ready-to-code dev environment for freeCodeCamp in your browser.**
[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
Or you can...
**[set up freeCodeCamp locally](how-to-setup-freecodecamp-locally.md) on your machine.**

456
docs/i18n/Czech/moderator-handbook.md
View File

@ -1,456 +0,0 @@
# 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!
## 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 ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
```
### Closing invalid pull requests
> When PR is invalid.
```markdown
Hey @username
Thank you for opening this pull request.
This is a standard message notifying you that we've reviewed your pull request and have decided not to merge it. We would welcome future pull requests from you.
Thank you and happy coding.
```

82
docs/i18n/Danish/FAQ.md
View File

@ -1,82 +0,0 @@
### 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 comprehensive reference for first-timer-friendly projects. And it includes a lot of open source contribution tips.
### Can I translate freeCodeCamp's curriculum?
Yes. We will roll out the tools for translating freeCodeCamp's curriculum soon.
Eventually, we intend to localize freeCodeCamp into several major world languages, starting with: Arabic, Chinese, Hindi, Portuguese, Russian, and Spanish.
### 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 these GitHub issues are for codebase-related issues and discussions – not for getting help with learning to code. Whenever in doubt, you should [seek assistance on the forum](https://forum.freecodecamp.org) before creating a GitHub issue.
### 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 work on a feature for academic credits?
Yes. Please note we are unable to commit to any timelines or paperwork that may be a requirement by your college or university. We receive many pull-requests and code contributions by volunteer developers, and we respect their time and efforts. Out of respect for all of our other contributors, we will not give any PR special priority just because it happens to be school-related.
We request you to plan ahead and work on code contributions 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 special issues that are designed for people who have not contributed to the freeCodeCamp codebase before.
### 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. Please be sure to mention details in the pull request description to help us understand and review your contribution – even if it's just a minor change.
Please do create an issue if you want to discuss bigger aspects of the codebase or curriculum.
### How can I get an issue assigned to me?
We typically do not assign issues to anyone other than long-time contributors. Instead, we follow the below policy to be fair to everyone:
1. We are most likely to merge the first pull request that addresses the issue.
2. In the case of multiple contributors opening a pull request for the same issue at around the same time, we will give priority to the pull request that best addresses the issue. Some of the things we consider:
- Did you include tests?
- Did you catch all usecases?
- Did you ensure all tests pass, and confirm everything works locally?
3. Finally, we give priority to pull requests which follow our recommended guidelines.
- Did you follow the pull request checklist?
- Did you give your pull request a meaningful title?
### 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 `#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. If you ask us questions on the related issue threads, we will be glad to clarify. Be sure to search for your question before posting a new one.
Thanks in advance for being polite and patient. Remember – this community is run mainly by volunteers.
**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`**

38
docs/i18n/Danish/_sidebar.md
View File

@ -1,38 +0,0 @@
- **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)
---
<!-- The section below should not use relative linking -->
- **中文社区贡献指南**
- [成为专栏作者](/i18n/Chinese/news-author-application.md)
- [文章翻译计划](/i18n/Chinese/news-translations.md)
- [视频翻译计划](/i18n/Chinese/video-translations.md)
<!-- The section above should not use relative linking -->
---
- **Flight Manuals** (for Staff & Mods)
- [Moderator Handbook](moderator-handbook.md)
- [DevOps Handbook](devops.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)

708
docs/i18n/Danish/devops.md
View File

@ -1,708 +0,0 @@
# DevOps Handbook
This guide will help you understand our infrastructure stack and how we maintain our platforms. While this guide does not have exhaustive details for all operations, it could be used as a reference for your understanding of the systems.
Let us know, if you have feedback or queries, and we will be happy to clarify.
# Flight Manual - Code deployments
This repository is continuously built, tested and deployed to **separate sets of infrastructure (Servers, Databases, CDNs, etc.)**.
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).
## Trigger a build, test and deploy
Currently, only members on the developer team can push to the production branches. The changes to the `production-*` branches can land only via fast-forward merge to the [`upstream`](https://github.com/freeCodeCamp/freeCodeCamp).
> [!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.
# Flight Manual - Server Maintenance
> [!WARNING]
>
> 1. The guide applies to the **freeCodeCamp Staff members only**.
> 2. These instructions should not be considered exhaustive, please use caution.
As a member of the staff, 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/Danish/how-to-catch-outgoing-emails-locally.md
View File

@ -1,100 +0,0 @@
> **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/Danish/how-to-help-with-video-challenges.md
View File

@ -1,199 +0,0 @@
# 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/Danish/how-to-open-a-pull-request.md
View File

@ -1,179 +0,0 @@
# How to open a Pull Request (PR)
A pull request (PR) enables you to send changes from your fork on GitHub to freeCodeCamp.org's main repository. Once you are done making changes to the code, you can follow these guidelines to open a PR.
## 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.
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
> [!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/Danish/how-to-setup-freecodecamp-locally.md
View File

@ -1,546 +0,0 @@
Follow these guidelines for setting up freeCodeCamp locally on your system. This is highly recommended if you want to contribute regularly.
Some of these contribution workflows – like fixing bugs in the codebase or curriculum – need you to run freeCodeCamp locally on your computer.
> [!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.)
### How to prepare your local machine
Start by installing the prerequisite software for your operating system.
We primarily support development on Linux and Unix-based systems. Our staff and community contributors regularly work with the codebase using tools installed on Ubuntu and macOS.
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 ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
> [!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, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
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/Danish/how-to-setup-wsl.md
View File

@ -1,129 +0,0 @@
# 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/Danish/how-to-use-docker-on-windows-home.md
View File

@ -1,15 +0,0 @@
# 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.

622
docs/i18n/Danish/how-to-work-on-coding-challenges.md
View File

@ -1,622 +0,0 @@
# How to work on coding challenges
Our goal is to develop a fun and clear interactive learning experience.
Designing interactive coding challenges is difficult. It would be much easier to write a lengthy explanation or to create a video tutorial. But for our core curriculum, we're sticking with what works best for most people - a fully interactive, video game-like experience.
We want campers to achieve a flow state. We want them to build momentum and blast through our curriculum with as few snags as possible. We want them to go into the projects with confidence and gain a wide exposure to programming concepts.
Note that for Version 7.0 of the freeCodeCamp curriculum, we are moving toward [an entirely project-focused model with a lot more repetition](https://www.freecodecamp.org/news/python-curriculum-is-live/).
Creating these challenges requires immense creativity and attention to detail. There's plenty of help available. You'll have support from a whole team of contributors to whom you can bounce ideas off and demo your challenges.
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
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 (e.g. "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:
```md
Use <code>parseInt</code> to convert the variable <code>realNumber</code> into an integer.
```
- References to file names and path directories (e.g. `package.json`, `src/components`) should be wrapped in `<code>` tags.
- 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**. See example below:
**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.
````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 single-quotes where applicable
**Note:** The equivalent _Markdown_ should be used, where applicable, in place of _HTML_ tags.
## 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
### Seed code comments
We have a [comment dictionary](/curriculum/dictionaries/english/comments.js) that contains the only comments that can be used within the seed code. The exact case and spacing of the dictionary comment must be used. The comment dictionary should not be expanded without prior discussion with the dev-team.
Comments used should have a space between the comment characters and the comment themselves. In general comments should be used sparingly. Always consider rewriting a challenge's description or instructions if it could avoid using a seed code comment.
Example of valid single line JavaScript comment:
```js
// Only change code below this line
````
Example of a valid CSS comment:
```js
/* Only change code above this line */
```
If a challenge only has a single place where code changes are needed, please use the comments in the following example to instruct the user where changes should be made.
```js
var a = 3;
var b = 17;
var c = 12;
// Only change code below this line
a = a + 12;
b = 9 + b;
c = c + 7;
```
If a challenge has multiple places where the user is expected to change code (i.e. the React challenges)
```jsx
class MyComponent extends React.Component {
constructor(props) {
super(props);
this.state = {
text: "Hello"
};
// Change code below this line
// Change code above this line
}
handleClick() {
this.setState({
text: "You clicked!"
});
}
render() {
return (
<div>
{ /* Change code below this line */ }
<button>Click Me</button>
{ /* Change code above this line */ }
<h1>{this.state.text}</h1>
</div>
);
}
};
```
### Translation of seed code comments
There are separate comment dictionaries for each language. The [English vesion of the comment dictionary](/curriculum/dictionaries/english/comments.js) is the basis for the translations found in the corresponding non-English versions of the files. The non-English version of the Chinese comment dictionary would be located at `/curriculum/dictionaries/chinese/comments.js`. Each dictionary consists of an array of objects with a unique `id` property and a `text` property. Only the `text` should be modified to encompass the translation of the corresponding English comment.
Some comments may contain a word/phrase that should not be translated. For example, variable names or proper library names like "React" should not be translated. See the comment below as an example. The word `myGlobal` should not be translated.
```text
Declare the myGlobal variable below this line
```
> [!NOTE]
>
> We are working on an integration to make it possible to work on i18n for the comment dictionary.
## 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>

54
docs/i18n/Danish/how-to-work-on-the-docs-theme.md
View File

@ -1,54 +0,0 @@
# 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:
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
docsify serve docs
```
Install `docsify`:
```console
npm install -g docsify
```
and serve the `/docs` directory
```console
docsify serve docs
```
Alternatively, if you have installed freeCodeCamp locally (see the local setup guide), we bundle the CLI with the development tools so you can run any of the below commands as needed from the root of the repo:
### Serve and launch the documentation site only
```console
npm run docs:serve
```
### Serve the documentation site alongside freeCodeCamp locally:
```console
npm run develop
```
> The documentation site should be available at <http://localhost:3200>

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

@ -1,99 +0,0 @@
# How to work on freeCodeCamp.org's developer news theme
The developer news also known as [`/news`](https://www.freecodecamp.org/news) site is powered by [Ghost](https://ghost.org/). We use a custom theme for the look and feel of the site. The source code of the theme is available here: <https://github.com/freeCodeCamp/news-theme>.
## The Theme
Ghost uses a simple templating language called [Handlebars](http://handlebarsjs.com/) for its themes. The theme used on `/news` is based off of the default [casper theme](https://github.com/TryGhost/Casper).
The default theme pretty heavily so that it should be fairly easy to work out what's going on just by reading the code and the comments. Once you feel comfortable with how everything works, Ghost also has a full [theme API documentation](https://themes.ghost.org) which explains every possible Handlebars helper and template.
**The main files are:**
- `default.hbs` - The main template file
- `index.hbs` - Used for the home page
- `post.hbs` - Used for individual posts
- `page.hbs` - Used for individual pages
- `tag.hbs` - Used for tag archives
- `author.hbs` - Used for author archives
One really neat trick is that you can also create custom one-off templates just by adding the slug of a page to a template file. For example:
- `page-about.hbs` - Custom template for the `/about/` page
- `tag-news.hbs` - Custom template for `/tag/news/` archive
- `author-ali.hbs` - Custom template for `/author/ali/` archive
## Development
1. Get Ghost installed locally.
```sh
npm install -g ghost-cli@latest
mkdir ghost-local-site
cd ghost-local-site
```
```sh
ghost install local
ghost start
```
> Note: Currently freeCodeCamp uses Ghost version `2.9.0`, so make sure you are using a version higher than that.
Be sure to run `ghost` commands from the `ghost-local-site` directory. Follow additional instructions on [Ghost's official documentation](https://docs.ghost.org) if are not familiar with its interface.
2. Fork and clone the repository in your theme directory:
```sh
cd content/themes/
git clone https://github.com/YOUR_USERNAME/news-theme.git
```
3. Make sure you have all the pre-requisites.
The theme styles are compiled using Gulp/PostCSS to polyfill future CSS spec. You'll need [Node.js](https://nodejs.org/). Make sure that your Node.js version is compatible with `ghost`.
4. Install dependencies and develop the theme
```sh
npm ci
npm run develop
```
5. Now you can edit `/assets/css/` files, which will be compiled to `/assets/built/` automatically.
6. Access the development site.
a. Enter `http://localhost:2368/ghost/` into your address bar. Continue with the setup prompted on the page (if running ghost for the first time).
b. _(One-time only, during setup)_ Restart Ghost, on a separate terminal once to ensure the theme is available.
```sh
cd ghost-local-site
ghost restart
```
c. _(One-time only, during setup)_ Once you've done this, go to `http://localhost:2368/ghost/#/settings/design` and scroll to the bottom. Make sure you click activate on the `freecodecamp-news-theme`.
7. Zip the final code and make a pull-request
The `zip` Gulp task packages the theme files into `dist/<theme-name>.zip`, which we can then upload to the production site.
When you make a PR, please make sure you have run the below script prior to commiting the code and sending a PR.
```sh
npm run zip
```
## Other Reference and resources
### PostCSS Features Used
- Autoprefixer - Don't worry about writing browser prefixes of any kind, it's all done automatically with support for the latest 2 major versions of every browser.
- Variables - Simple pure CSS variables
- [Color Function](https://github.com/postcss/postcss-color-function)
### SVG Icons
The theme uses inline SVG icons, included via Handlebars partials. You can find all icons inside `/partials/icons`. To use an icon just include the name of the relevant file, eg. To include the SVG icon in `/partials/icons/rss.hbs` - use `{{> "icons/rss"}}`.
You can add your own SVG icons in the same manner.

43
docs/i18n/Danish/index.md
View File

@ -1,43 +0,0 @@
The [freeCodeCamp.org](https://freecodecamp.org) community is possible thanks to thousands of kind volunteers like you. If you want to contribute your time and expertise, we would be excited to welcome you aboard.
> [!NOTE] Before you proceed, please take a quick 2 minutes to read our [Code of Conduct](https://www.freecodecamp.org/code-of-conduct). We strictly enforce it across our community so that contributing to freeCodeCamp.org is a safe, inclusive experience for everyone.
Happy contributing.
You are welcome to:
- Create, update and fix bugs in our [curriculum](#curriculum).
- Help us fix bugs in freeCodeCamp.org's [learning platform](#learning-platform).
- _(Coming Soon)_ Help us translate freeCodeCamp.org to world languages.
We answer the most common questions about contributing [in our contributor FAQ](/FAQ.md).
## Curriculum
Our curriculum is curated by the global freeCodeCamp community. This way, we are able to incorporate expert knowledge from volunteers like you.
You can help expand and improve the curriculum. You can also update project user stories to better-explain concepts. And you can improve our automated tests so that we can more accurately test people's code.
**If you're interested in improving our curriculum, here's [how to contribute to the curriculum](how-to-work-on-coding-challenges.md).**
## Learning Platform
Our learning platform runs on a modern JavaScript stack. It has various components, tools, and libraries. These include Node.js, MongoDB, OAuth 2.0, React, Gatsby, Webpack, and more.
Broadly, we use
- a Node.js based API server
- a set of React-based client applications
- and testing scripts to evaluate camper-submitted curriculum projects.
If you want to productively contribute to the curriculum, we recommend some familiarity with these tools.
If you want to help us improve our codebase...
**you can either use Gitpod, a free online dev environment that starts a ready-to-code dev environment for freeCodeCamp in your browser.**
[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
Or you can...
**[set up freeCodeCamp locally](how-to-setup-freecodecamp-locally.md) on your machine.**

456
docs/i18n/Danish/moderator-handbook.md
View File

@ -1,456 +0,0 @@
# 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!
## 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 ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
```
### Closing invalid pull requests
> When PR is invalid.
```markdown
Hey @username
Thank you for opening this pull request.
This is a standard message notifying you that we've reviewed your pull request and have decided not to merge it. We would welcome future pull requests from you.
Thank you and happy coding.
```

82
docs/i18n/Dutch/FAQ.md
View File

@ -1,82 +0,0 @@
### 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 comprehensive reference for first-timer-friendly projects. And it includes a lot of open source contribution tips.
### Can I translate freeCodeCamp's curriculum?
Yes. We will roll out the tools for translating freeCodeCamp's curriculum soon.
Eventually, we intend to localize freeCodeCamp into several major world languages, starting with: Arabic, Chinese, Hindi, Portuguese, Russian, and Spanish.
### 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 these GitHub issues are for codebase-related issues and discussions – not for getting help with learning to code. Whenever in doubt, you should [seek assistance on the forum](https://forum.freecodecamp.org) before creating a GitHub issue.
### 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 work on a feature for academic credits?
Yes. Please note we are unable to commit to any timelines or paperwork that may be a requirement by your college or university. We receive many pull-requests and code contributions by volunteer developers, and we respect their time and efforts. Out of respect for all of our other contributors, we will not give any PR special priority just because it happens to be school-related.
We request you to plan ahead and work on code contributions 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 special issues that are designed for people who have not contributed to the freeCodeCamp codebase before.
### 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. Please be sure to mention details in the pull request description to help us understand and review your contribution – even if it's just a minor change.
Please do create an issue if you want to discuss bigger aspects of the codebase or curriculum.
### How can I get an issue assigned to me?
We typically do not assign issues to anyone other than long-time contributors. Instead, we follow the below policy to be fair to everyone:
1. We are most likely to merge the first pull request that addresses the issue.
2. In the case of multiple contributors opening a pull request for the same issue at around the same time, we will give priority to the pull request that best addresses the issue. Some of the things we consider:
- Did you include tests?
- Did you catch all usecases?
- Did you ensure all tests pass, and confirm everything works locally?
3. Finally, we give priority to pull requests which follow our recommended guidelines.
- Did you follow the pull request checklist?
- Did you give your pull request a meaningful title?
### 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 `#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. If you ask us questions on the related issue threads, we will be glad to clarify. Be sure to search for your question before posting a new one.
Thanks in advance for being polite and patient. Remember – this community is run mainly by volunteers.
**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`**

38
docs/i18n/Dutch/_sidebar.md
View File

@ -1,38 +0,0 @@
- **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)
---
<!-- The section below should not use relative linking -->
- **中文社区贡献指南**
- [成为专栏作者](/i18n/Chinese/news-author-application.md)
- [文章翻译计划](/i18n/Chinese/news-translations.md)
- [视频翻译计划](/i18n/Chinese/video-translations.md)
<!-- The section above should not use relative linking -->
---
- **Flight Manuals** (for Staff & Mods)
- [Moderator Handbook](moderator-handbook.md)
- [DevOps Handbook](devops.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)

708
docs/i18n/Dutch/devops.md
View File

@ -1,708 +0,0 @@
# DevOps Handbook
This guide will help you understand our infrastructure stack and how we maintain our platforms. While this guide does not have exhaustive details for all operations, it could be used as a reference for your understanding of the systems.
Let us know, if you have feedback or queries, and we will be happy to clarify.
# Flight Manual - Code deployments
This repository is continuously built, tested and deployed to **separate sets of infrastructure (Servers, Databases, CDNs, etc.)**.
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).
## Trigger a build, test and deploy
Currently, only members on the developer team can push to the production branches. The changes to the `production-*` branches can land only via fast-forward merge to the [`upstream`](https://github.com/freeCodeCamp/freeCodeCamp).
> [!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.
# Flight Manual - Server Maintenance
> [!WARNING]
>
> 1. The guide applies to the **freeCodeCamp Staff members only**.
> 2. These instructions should not be considered exhaustive, please use caution.
As a member of the staff, 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/Dutch/how-to-catch-outgoing-emails-locally.md
View File

@ -1,100 +0,0 @@
> **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/Dutch/how-to-help-with-video-challenges.md
View File

@ -1,199 +0,0 @@
# 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/Dutch/how-to-open-a-pull-request.md
View File

@ -1,179 +0,0 @@
# How to open a Pull Request (PR)
A pull request (PR) enables you to send changes from your fork on GitHub to freeCodeCamp.org's main repository. Once you are done making changes to the code, you can follow these guidelines to open a PR.
## 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.
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
> [!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/Dutch/how-to-setup-freecodecamp-locally.md
View File

@ -1,546 +0,0 @@
Follow these guidelines for setting up freeCodeCamp locally on your system. This is highly recommended if you want to contribute regularly.
Some of these contribution workflows – like fixing bugs in the codebase or curriculum – need you to run freeCodeCamp locally on your computer.
> [!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.)
### How to prepare your local machine
Start by installing the prerequisite software for your operating system.
We primarily support development on Linux and Unix-based systems. Our staff and community contributors regularly work with the codebase using tools installed on Ubuntu and macOS.
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 ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
> [!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, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
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/Dutch/how-to-setup-wsl.md
View File

@ -1,129 +0,0 @@
# 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/Dutch/how-to-use-docker-on-windows-home.md
View File

@ -1,15 +0,0 @@
# 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.

622
docs/i18n/Dutch/how-to-work-on-coding-challenges.md
View File

@ -1,622 +0,0 @@
# How to work on coding challenges
Our goal is to develop a fun and clear interactive learning experience.
Designing interactive coding challenges is difficult. It would be much easier to write a lengthy explanation or to create a video tutorial. But for our core curriculum, we're sticking with what works best for most people - a fully interactive, video game-like experience.
We want campers to achieve a flow state. We want them to build momentum and blast through our curriculum with as few snags as possible. We want them to go into the projects with confidence and gain a wide exposure to programming concepts.
Note that for Version 7.0 of the freeCodeCamp curriculum, we are moving toward [an entirely project-focused model with a lot more repetition](https://www.freecodecamp.org/news/python-curriculum-is-live/).
Creating these challenges requires immense creativity and attention to detail. There's plenty of help available. You'll have support from a whole team of contributors to whom you can bounce ideas off and demo your challenges.
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
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 (e.g. "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:
```md
Use <code>parseInt</code> to convert the variable <code>realNumber</code> into an integer.
```
- References to file names and path directories (e.g. `package.json`, `src/components`) should be wrapped in `<code>` tags.
- 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**. See example below:
**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.
````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 single-quotes where applicable
**Note:** The equivalent _Markdown_ should be used, where applicable, in place of _HTML_ tags.
## 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
### Seed code comments
We have a [comment dictionary](/curriculum/dictionaries/english/comments.js) that contains the only comments that can be used within the seed code. The exact case and spacing of the dictionary comment must be used. The comment dictionary should not be expanded without prior discussion with the dev-team.
Comments used should have a space between the comment characters and the comment themselves. In general comments should be used sparingly. Always consider rewriting a challenge's description or instructions if it could avoid using a seed code comment.
Example of valid single line JavaScript comment:
```js
// Only change code below this line
````
Example of a valid CSS comment:
```js
/* Only change code above this line */
```
If a challenge only has a single place where code changes are needed, please use the comments in the following example to instruct the user where changes should be made.
```js
var a = 3;
var b = 17;
var c = 12;
// Only change code below this line
a = a + 12;
b = 9 + b;
c = c + 7;
```
If a challenge has multiple places where the user is expected to change code (i.e. the React challenges)
```jsx
class MyComponent extends React.Component {
constructor(props) {
super(props);
this.state = {
text: "Hello"
};
// Change code below this line
// Change code above this line
}
handleClick() {
this.setState({
text: "You clicked!"
});
}
render() {
return (
<div>
{ /* Change code below this line */ }
<button>Click Me</button>
{ /* Change code above this line */ }
<h1>{this.state.text}</h1>
</div>
);
}
};
```
### Translation of seed code comments
There are separate comment dictionaries for each language. The [English vesion of the comment dictionary](/curriculum/dictionaries/english/comments.js) is the basis for the translations found in the corresponding non-English versions of the files. The non-English version of the Chinese comment dictionary would be located at `/curriculum/dictionaries/chinese/comments.js`. Each dictionary consists of an array of objects with a unique `id` property and a `text` property. Only the `text` should be modified to encompass the translation of the corresponding English comment.
Some comments may contain a word/phrase that should not be translated. For example, variable names or proper library names like "React" should not be translated. See the comment below as an example. The word `myGlobal` should not be translated.
```text
Declare the myGlobal variable below this line
```
> [!NOTE]
>
> We are working on an integration to make it possible to work on i18n for the comment dictionary.
## 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>

54
docs/i18n/Dutch/how-to-work-on-the-docs-theme.md
View File

@ -1,54 +0,0 @@
# 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:
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
docsify serve docs
```
Install `docsify`:
```console
npm install -g docsify
```
and serve the `/docs` directory
```console
docsify serve docs
```
Alternatively, if you have installed freeCodeCamp locally (see the local setup guide), we bundle the CLI with the development tools so you can run any of the below commands as needed from the root of the repo:
### Serve and launch the documentation site only
```console
npm run docs:serve
```
### Serve the documentation site alongside freeCodeCamp locally:
```console
npm run develop
```
> The documentation site should be available at <http://localhost:3200>

99
docs/i18n/Dutch/how-to-work-on-the-news-theme.md
View File

@ -1,99 +0,0 @@
# How to work on freeCodeCamp.org's developer news theme
The developer news also known as [`/news`](https://www.freecodecamp.org/news) site is powered by [Ghost](https://ghost.org/). We use a custom theme for the look and feel of the site. The source code of the theme is available here: <https://github.com/freeCodeCamp/news-theme>.
## The Theme
Ghost uses a simple templating language called [Handlebars](http://handlebarsjs.com/) for its themes. The theme used on `/news` is based off of the default [casper theme](https://github.com/TryGhost/Casper).
The default theme pretty heavily so that it should be fairly easy to work out what's going on just by reading the code and the comments. Once you feel comfortable with how everything works, Ghost also has a full [theme API documentation](https://themes.ghost.org) which explains every possible Handlebars helper and template.
**The main files are:**
- `default.hbs` - The main template file
- `index.hbs` - Used for the home page
- `post.hbs` - Used for individual posts
- `page.hbs` - Used for individual pages
- `tag.hbs` - Used for tag archives
- `author.hbs` - Used for author archives
One really neat trick is that you can also create custom one-off templates just by adding the slug of a page to a template file. For example:
- `page-about.hbs` - Custom template for the `/about/` page
- `tag-news.hbs` - Custom template for `/tag/news/` archive
- `author-ali.hbs` - Custom template for `/author/ali/` archive
## Development
1. Get Ghost installed locally.
```sh
npm install -g ghost-cli@latest
mkdir ghost-local-site
cd ghost-local-site
```
```sh
ghost install local
ghost start
```
> Note: Currently freeCodeCamp uses Ghost version `2.9.0`, so make sure you are using a version higher than that.
Be sure to run `ghost` commands from the `ghost-local-site` directory. Follow additional instructions on [Ghost's official documentation](https://docs.ghost.org) if are not familiar with its interface.
2. Fork and clone the repository in your theme directory:
```sh
cd content/themes/
git clone https://github.com/YOUR_USERNAME/news-theme.git
```
3. Make sure you have all the pre-requisites.
The theme styles are compiled using Gulp/PostCSS to polyfill future CSS spec. You'll need [Node.js](https://nodejs.org/). Make sure that your Node.js version is compatible with `ghost`.
4. Install dependencies and develop the theme
```sh
npm ci
npm run develop
```
5. Now you can edit `/assets/css/` files, which will be compiled to `/assets/built/` automatically.
6. Access the development site.
a. Enter `http://localhost:2368/ghost/` into your address bar. Continue with the setup prompted on the page (if running ghost for the first time).
b. _(One-time only, during setup)_ Restart Ghost, on a separate terminal once to ensure the theme is available.
```sh
cd ghost-local-site
ghost restart
```
c. _(One-time only, during setup)_ Once you've done this, go to `http://localhost:2368/ghost/#/settings/design` and scroll to the bottom. Make sure you click activate on the `freecodecamp-news-theme`.
7. Zip the final code and make a pull-request
The `zip` Gulp task packages the theme files into `dist/<theme-name>.zip`, which we can then upload to the production site.
When you make a PR, please make sure you have run the below script prior to commiting the code and sending a PR.
```sh
npm run zip
```
## Other Reference and resources
### PostCSS Features Used
- Autoprefixer - Don't worry about writing browser prefixes of any kind, it's all done automatically with support for the latest 2 major versions of every browser.
- Variables - Simple pure CSS variables
- [Color Function](https://github.com/postcss/postcss-color-function)
### SVG Icons
The theme uses inline SVG icons, included via Handlebars partials. You can find all icons inside `/partials/icons`. To use an icon just include the name of the relevant file, eg. To include the SVG icon in `/partials/icons/rss.hbs` - use `{{> "icons/rss"}}`.
You can add your own SVG icons in the same manner.

43
docs/i18n/Dutch/index.md
View File

@ -1,43 +0,0 @@
The [freeCodeCamp.org](https://freecodecamp.org) community is possible thanks to thousands of kind volunteers like you. If you want to contribute your time and expertise, we would be excited to welcome you aboard.
> [!NOTE] Before you proceed, please take a quick 2 minutes to read our [Code of Conduct](https://www.freecodecamp.org/code-of-conduct). We strictly enforce it across our community so that contributing to freeCodeCamp.org is a safe, inclusive experience for everyone.
Happy contributing.
You are welcome to:
- Create, update and fix bugs in our [curriculum](#curriculum).
- Help us fix bugs in freeCodeCamp.org's [learning platform](#learning-platform).
- _(Coming Soon)_ Help us translate freeCodeCamp.org to world languages.
We answer the most common questions about contributing [in our contributor FAQ](/FAQ.md).
## Curriculum
Our curriculum is curated by the global freeCodeCamp community. This way, we are able to incorporate expert knowledge from volunteers like you.
You can help expand and improve the curriculum. You can also update project user stories to better-explain concepts. And you can improve our automated tests so that we can more accurately test people's code.
**If you're interested in improving our curriculum, here's [how to contribute to the curriculum](how-to-work-on-coding-challenges.md).**
## Learning Platform
Our learning platform runs on a modern JavaScript stack. It has various components, tools, and libraries. These include Node.js, MongoDB, OAuth 2.0, React, Gatsby, Webpack, and more.
Broadly, we use
- a Node.js based API server
- a set of React-based client applications
- and testing scripts to evaluate camper-submitted curriculum projects.
If you want to productively contribute to the curriculum, we recommend some familiarity with these tools.
If you want to help us improve our codebase...
**you can either use Gitpod, a free online dev environment that starts a ready-to-code dev environment for freeCodeCamp in your browser.**
[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
Or you can...
**[set up freeCodeCamp locally](how-to-setup-freecodecamp-locally.md) on your machine.**

456
docs/i18n/Dutch/moderator-handbook.md
View File

@ -1,456 +0,0 @@
# 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!
## 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 ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
```
### Closing invalid pull requests
> When PR is invalid.
```markdown
Hey @username
Thank you for opening this pull request.
This is a standard message notifying you that we've reviewed your pull request and have decided not to merge it. We would welcome future pull requests from you.
Thank you and happy coding.
```

82
docs/i18n/Finnish/FAQ.md
View File

@ -1,82 +0,0 @@
### 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 comprehensive reference for first-timer-friendly projects. And it includes a lot of open source contribution tips.
### Can I translate freeCodeCamp's curriculum?
Yes. We will roll out the tools for translating freeCodeCamp's curriculum soon.
Eventually, we intend to localize freeCodeCamp into several major world languages, starting with: Arabic, Chinese, Hindi, Portuguese, Russian, and Spanish.
### 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 these GitHub issues are for codebase-related issues and discussions – not for getting help with learning to code. Whenever in doubt, you should [seek assistance on the forum](https://forum.freecodecamp.org) before creating a GitHub issue.
### 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 work on a feature for academic credits?
Yes. Please note we are unable to commit to any timelines or paperwork that may be a requirement by your college or university. We receive many pull-requests and code contributions by volunteer developers, and we respect their time and efforts. Out of respect for all of our other contributors, we will not give any PR special priority just because it happens to be school-related.
We request you to plan ahead and work on code contributions 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 special issues that are designed for people who have not contributed to the freeCodeCamp codebase before.
### 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. Please be sure to mention details in the pull request description to help us understand and review your contribution – even if it's just a minor change.
Please do create an issue if you want to discuss bigger aspects of the codebase or curriculum.
### How can I get an issue assigned to me?
We typically do not assign issues to anyone other than long-time contributors. Instead, we follow the below policy to be fair to everyone:
1. We are most likely to merge the first pull request that addresses the issue.
2. In the case of multiple contributors opening a pull request for the same issue at around the same time, we will give priority to the pull request that best addresses the issue. Some of the things we consider:
- Did you include tests?
- Did you catch all usecases?
- Did you ensure all tests pass, and confirm everything works locally?
3. Finally, we give priority to pull requests which follow our recommended guidelines.
- Did you follow the pull request checklist?
- Did you give your pull request a meaningful title?
### 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 `#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. If you ask us questions on the related issue threads, we will be glad to clarify. Be sure to search for your question before posting a new one.
Thanks in advance for being polite and patient. Remember – this community is run mainly by volunteers.
**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`**

38
docs/i18n/Finnish/_sidebar.md
View File

@ -1,38 +0,0 @@
- **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)
---
<!-- The section below should not use relative linking -->
- **中文社区贡献指南**
- [成为专栏作者](/i18n/Chinese/news-author-application.md)
- [文章翻译计划](/i18n/Chinese/news-translations.md)
- [视频翻译计划](/i18n/Chinese/video-translations.md)
<!-- The section above should not use relative linking -->
---
- **Flight Manuals** (for Staff & Mods)
- [Moderator Handbook](moderator-handbook.md)
- [DevOps Handbook](devops.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)

708
docs/i18n/Finnish/devops.md
View File

@ -1,708 +0,0 @@
# DevOps Handbook
This guide will help you understand our infrastructure stack and how we maintain our platforms. While this guide does not have exhaustive details for all operations, it could be used as a reference for your understanding of the systems.
Let us know, if you have feedback or queries, and we will be happy to clarify.
# Flight Manual - Code deployments
This repository is continuously built, tested and deployed to **separate sets of infrastructure (Servers, Databases, CDNs, etc.)**.
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).
## Trigger a build, test and deploy
Currently, only members on the developer team can push to the production branches. The changes to the `production-*` branches can land only via fast-forward merge to the [`upstream`](https://github.com/freeCodeCamp/freeCodeCamp).
> [!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.
# Flight Manual - Server Maintenance
> [!WARNING]
>
> 1. The guide applies to the **freeCodeCamp Staff members only**.
> 2. These instructions should not be considered exhaustive, please use caution.
As a member of the staff, 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/Finnish/how-to-catch-outgoing-emails-locally.md
View File

@ -1,100 +0,0 @@
> **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/Finnish/how-to-help-with-video-challenges.md
View File

@ -1,199 +0,0 @@
# 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/Finnish/how-to-open-a-pull-request.md
View File

@ -1,179 +0,0 @@
# How to open a Pull Request (PR)
A pull request (PR) enables you to send changes from your fork on GitHub to freeCodeCamp.org's main repository. Once you are done making changes to the code, you can follow these guidelines to open a PR.
## 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.
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
> [!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/Finnish/how-to-setup-freecodecamp-locally.md
View File

@ -1,546 +0,0 @@
Follow these guidelines for setting up freeCodeCamp locally on your system. This is highly recommended if you want to contribute regularly.
Some of these contribution workflows – like fixing bugs in the codebase or curriculum – need you to run freeCodeCamp locally on your computer.
> [!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.)
### How to prepare your local machine
Start by installing the prerequisite software for your operating system.
We primarily support development on Linux and Unix-based systems. Our staff and community contributors regularly work with the codebase using tools installed on Ubuntu and macOS.
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 ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
> [!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, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
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/Finnish/how-to-setup-wsl.md
View File

@ -1,129 +0,0 @@
# 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/Finnish/how-to-use-docker-on-windows-home.md
View File

@ -1,15 +0,0 @@
# 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.

622
docs/i18n/Finnish/how-to-work-on-coding-challenges.md
View File

@ -1,622 +0,0 @@
# How to work on coding challenges
Our goal is to develop a fun and clear interactive learning experience.
Designing interactive coding challenges is difficult. It would be much easier to write a lengthy explanation or to create a video tutorial. But for our core curriculum, we're sticking with what works best for most people - a fully interactive, video game-like experience.
We want campers to achieve a flow state. We want them to build momentum and blast through our curriculum with as few snags as possible. We want them to go into the projects with confidence and gain a wide exposure to programming concepts.
Note that for Version 7.0 of the freeCodeCamp curriculum, we are moving toward [an entirely project-focused model with a lot more repetition](https://www.freecodecamp.org/news/python-curriculum-is-live/).
Creating these challenges requires immense creativity and attention to detail. There's plenty of help available. You'll have support from a whole team of contributors to whom you can bounce ideas off and demo your challenges.
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
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 (e.g. "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:
```md
Use <code>parseInt</code> to convert the variable <code>realNumber</code> into an integer.
```
- References to file names and path directories (e.g. `package.json`, `src/components`) should be wrapped in `<code>` tags.
- 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**. See example below:
**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.
````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 single-quotes where applicable
**Note:** The equivalent _Markdown_ should be used, where applicable, in place of _HTML_ tags.
## 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
### Seed code comments
We have a [comment dictionary](/curriculum/dictionaries/english/comments.js) that contains the only comments that can be used within the seed code. The exact case and spacing of the dictionary comment must be used. The comment dictionary should not be expanded without prior discussion with the dev-team.
Comments used should have a space between the comment characters and the comment themselves. In general comments should be used sparingly. Always consider rewriting a challenge's description or instructions if it could avoid using a seed code comment.
Example of valid single line JavaScript comment:
```js
// Only change code below this line
````
Example of a valid CSS comment:
```js
/* Only change code above this line */
```
If a challenge only has a single place where code changes are needed, please use the comments in the following example to instruct the user where changes should be made.
```js
var a = 3;
var b = 17;
var c = 12;
// Only change code below this line
a = a + 12;
b = 9 + b;
c = c + 7;
```
If a challenge has multiple places where the user is expected to change code (i.e. the React challenges)
```jsx
class MyComponent extends React.Component {
constructor(props) {
super(props);
this.state = {
text: "Hello"
};
// Change code below this line
// Change code above this line
}
handleClick() {
this.setState({
text: "You clicked!"
});
}
render() {
return (
<div>
{ /* Change code below this line */ }
<button>Click Me</button>
{ /* Change code above this line */ }
<h1>{this.state.text}</h1>
</div>
);
}
};
```
### Translation of seed code comments
There are separate comment dictionaries for each language. The [English vesion of the comment dictionary](/curriculum/dictionaries/english/comments.js) is the basis for the translations found in the corresponding non-English versions of the files. The non-English version of the Chinese comment dictionary would be located at `/curriculum/dictionaries/chinese/comments.js`. Each dictionary consists of an array of objects with a unique `id` property and a `text` property. Only the `text` should be modified to encompass the translation of the corresponding English comment.
Some comments may contain a word/phrase that should not be translated. For example, variable names or proper library names like "React" should not be translated. See the comment below as an example. The word `myGlobal` should not be translated.
```text
Declare the myGlobal variable below this line
```
> [!NOTE]
>
> We are working on an integration to make it possible to work on i18n for the comment dictionary.
## 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>

54
docs/i18n/Finnish/how-to-work-on-the-docs-theme.md
View File

@ -1,54 +0,0 @@
# 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:
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
docsify serve docs
```
Install `docsify`:
```console
npm install -g docsify
```
and serve the `/docs` directory
```console
docsify serve docs
```
Alternatively, if you have installed freeCodeCamp locally (see the local setup guide), we bundle the CLI with the development tools so you can run any of the below commands as needed from the root of the repo:
### Serve and launch the documentation site only
```console
npm run docs:serve
```
### Serve the documentation site alongside freeCodeCamp locally:
```console
npm run develop
```
> The documentation site should be available at <http://localhost:3200>

99
docs/i18n/Finnish/how-to-work-on-the-news-theme.md
View File

@ -1,99 +0,0 @@
# How to work on freeCodeCamp.org's developer news theme
The developer news also known as [`/news`](https://www.freecodecamp.org/news) site is powered by [Ghost](https://ghost.org/). We use a custom theme for the look and feel of the site. The source code of the theme is available here: <https://github.com/freeCodeCamp/news-theme>.
## The Theme
Ghost uses a simple templating language called [Handlebars](http://handlebarsjs.com/) for its themes. The theme used on `/news` is based off of the default [casper theme](https://github.com/TryGhost/Casper).
The default theme pretty heavily so that it should be fairly easy to work out what's going on just by reading the code and the comments. Once you feel comfortable with how everything works, Ghost also has a full [theme API documentation](https://themes.ghost.org) which explains every possible Handlebars helper and template.
**The main files are:**
- `default.hbs` - The main template file
- `index.hbs` - Used for the home page
- `post.hbs` - Used for individual posts
- `page.hbs` - Used for individual pages
- `tag.hbs` - Used for tag archives
- `author.hbs` - Used for author archives
One really neat trick is that you can also create custom one-off templates just by adding the slug of a page to a template file. For example:
- `page-about.hbs` - Custom template for the `/about/` page
- `tag-news.hbs` - Custom template for `/tag/news/` archive
- `author-ali.hbs` - Custom template for `/author/ali/` archive
## Development
1. Get Ghost installed locally.
```sh
npm install -g ghost-cli@latest
mkdir ghost-local-site
cd ghost-local-site
```
```sh
ghost install local
ghost start
```
> Note: Currently freeCodeCamp uses Ghost version `2.9.0`, so make sure you are using a version higher than that.
Be sure to run `ghost` commands from the `ghost-local-site` directory. Follow additional instructions on [Ghost's official documentation](https://docs.ghost.org) if are not familiar with its interface.
2. Fork and clone the repository in your theme directory:
```sh
cd content/themes/
git clone https://github.com/YOUR_USERNAME/news-theme.git
```
3. Make sure you have all the pre-requisites.
The theme styles are compiled using Gulp/PostCSS to polyfill future CSS spec. You'll need [Node.js](https://nodejs.org/). Make sure that your Node.js version is compatible with `ghost`.
4. Install dependencies and develop the theme
```sh
npm ci
npm run develop
```
5. Now you can edit `/assets/css/` files, which will be compiled to `/assets/built/` automatically.
6. Access the development site.
a. Enter `http://localhost:2368/ghost/` into your address bar. Continue with the setup prompted on the page (if running ghost for the first time).
b. _(One-time only, during setup)_ Restart Ghost, on a separate terminal once to ensure the theme is available.
```sh
cd ghost-local-site
ghost restart
```
c. _(One-time only, during setup)_ Once you've done this, go to `http://localhost:2368/ghost/#/settings/design` and scroll to the bottom. Make sure you click activate on the `freecodecamp-news-theme`.
7. Zip the final code and make a pull-request
The `zip` Gulp task packages the theme files into `dist/<theme-name>.zip`, which we can then upload to the production site.
When you make a PR, please make sure you have run the below script prior to commiting the code and sending a PR.
```sh
npm run zip
```
## Other Reference and resources
### PostCSS Features Used
- Autoprefixer - Don't worry about writing browser prefixes of any kind, it's all done automatically with support for the latest 2 major versions of every browser.
- Variables - Simple pure CSS variables
- [Color Function](https://github.com/postcss/postcss-color-function)
### SVG Icons
The theme uses inline SVG icons, included via Handlebars partials. You can find all icons inside `/partials/icons`. To use an icon just include the name of the relevant file, eg. To include the SVG icon in `/partials/icons/rss.hbs` - use `{{> "icons/rss"}}`.
You can add your own SVG icons in the same manner.

43
docs/i18n/Finnish/index.md
View File

@ -1,43 +0,0 @@
The [freeCodeCamp.org](https://freecodecamp.org) community is possible thanks to thousands of kind volunteers like you. If you want to contribute your time and expertise, we would be excited to welcome you aboard.
> [!NOTE] Before you proceed, please take a quick 2 minutes to read our [Code of Conduct](https://www.freecodecamp.org/code-of-conduct). We strictly enforce it across our community so that contributing to freeCodeCamp.org is a safe, inclusive experience for everyone.
Happy contributing.
You are welcome to:
- Create, update and fix bugs in our [curriculum](#curriculum).
- Help us fix bugs in freeCodeCamp.org's [learning platform](#learning-platform).
- _(Coming Soon)_ Help us translate freeCodeCamp.org to world languages.
We answer the most common questions about contributing [in our contributor FAQ](/FAQ.md).
## Curriculum
Our curriculum is curated by the global freeCodeCamp community. This way, we are able to incorporate expert knowledge from volunteers like you.
You can help expand and improve the curriculum. You can also update project user stories to better-explain concepts. And you can improve our automated tests so that we can more accurately test people's code.
**If you're interested in improving our curriculum, here's [how to contribute to the curriculum](how-to-work-on-coding-challenges.md).**
## Learning Platform
Our learning platform runs on a modern JavaScript stack. It has various components, tools, and libraries. These include Node.js, MongoDB, OAuth 2.0, React, Gatsby, Webpack, and more.
Broadly, we use
- a Node.js based API server
- a set of React-based client applications
- and testing scripts to evaluate camper-submitted curriculum projects.
If you want to productively contribute to the curriculum, we recommend some familiarity with these tools.
If you want to help us improve our codebase...
**you can either use Gitpod, a free online dev environment that starts a ready-to-code dev environment for freeCodeCamp in your browser.**
[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
Or you can...
**[set up freeCodeCamp locally](how-to-setup-freecodecamp-locally.md) on your machine.**

456
docs/i18n/Finnish/moderator-handbook.md
View File

@ -1,456 +0,0 @@
# 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!
## 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 ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
```
### Closing invalid pull requests
> When PR is invalid.
```markdown
Hey @username
Thank you for opening this pull request.
This is a standard message notifying you that we've reviewed your pull request and have decided not to merge it. We would welcome future pull requests from you.
Thank you and happy coding.
```

82
docs/i18n/French/FAQ.md
View File

@ -1,82 +0,0 @@
### 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 comprehensive reference for first-timer-friendly projects. And it includes a lot of open source contribution tips.
### Can I translate freeCodeCamp's curriculum?
Yes. We will roll out the tools for translating freeCodeCamp's curriculum soon.
Eventually, we intend to localize freeCodeCamp into several major world languages, starting with: Arabic, Chinese, Hindi, Portuguese, Russian, and Spanish.
### 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 these GitHub issues are for codebase-related issues and discussions – not for getting help with learning to code. Whenever in doubt, you should [seek assistance on the forum](https://forum.freecodecamp.org) before creating a GitHub issue.
### 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 work on a feature for academic credits?
Yes. Please note we are unable to commit to any timelines or paperwork that may be a requirement by your college or university. We receive many pull-requests and code contributions by volunteer developers, and we respect their time and efforts. Out of respect for all of our other contributors, we will not give any PR special priority just because it happens to be school-related.
We request you to plan ahead and work on code contributions 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 special issues that are designed for people who have not contributed to the freeCodeCamp codebase before.
### 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. Please be sure to mention details in the pull request description to help us understand and review your contribution – even if it's just a minor change.
Please do create an issue if you want to discuss bigger aspects of the codebase or curriculum.
### How can I get an issue assigned to me?
We typically do not assign issues to anyone other than long-time contributors. Instead, we follow the below policy to be fair to everyone:
1. We are most likely to merge the first pull request that addresses the issue.
2. In the case of multiple contributors opening a pull request for the same issue at around the same time, we will give priority to the pull request that best addresses the issue. Some of the things we consider:
- Did you include tests?
- Did you catch all usecases?
- Did you ensure all tests pass, and confirm everything works locally?
3. Finally, we give priority to pull requests which follow our recommended guidelines.
- Did you follow the pull request checklist?
- Did you give your pull request a meaningful title?
### 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 `#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. If you ask us questions on the related issue threads, we will be glad to clarify. Be sure to search for your question before posting a new one.
Thanks in advance for being polite and patient. Remember – this community is run mainly by volunteers.
**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`**

38
docs/i18n/French/_sidebar.md
View File

@ -1,38 +0,0 @@
- **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)
---
<!-- The section below should not use relative linking -->
- **中文社区贡献指南**
- [成为专栏作者](/i18n/Chinese/news-author-application.md)
- [文章翻译计划](/i18n/Chinese/news-translations.md)
- [视频翻译计划](/i18n/Chinese/video-translations.md)
<!-- The section above should not use relative linking -->
---
- **Flight Manuals** (for Staff & Mods)
- [Moderator Handbook](moderator-handbook.md)
- [DevOps Handbook](devops.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)

708
docs/i18n/French/devops.md
View File

@ -1,708 +0,0 @@
# DevOps Handbook
This guide will help you understand our infrastructure stack and how we maintain our platforms. While this guide does not have exhaustive details for all operations, it could be used as a reference for your understanding of the systems.
Let us know, if you have feedback or queries, and we will be happy to clarify.
# Flight Manual - Code deployments
This repository is continuously built, tested and deployed to **separate sets of infrastructure (Servers, Databases, CDNs, etc.)**.
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).
## Trigger a build, test and deploy
Currently, only members on the developer team can push to the production branches. The changes to the `production-*` branches can land only via fast-forward merge to the [`upstream`](https://github.com/freeCodeCamp/freeCodeCamp).
> [!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.
# Flight Manual - Server Maintenance
> [!WARNING]
>
> 1. The guide applies to the **freeCodeCamp Staff members only**.
> 2. These instructions should not be considered exhaustive, please use caution.
As a member of the staff, 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/French/how-to-catch-outgoing-emails-locally.md
View File

@ -1,100 +0,0 @@
> **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/French/how-to-help-with-video-challenges.md
View File

@ -1,199 +0,0 @@
# 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/French/how-to-open-a-pull-request.md
View File

@ -1,179 +0,0 @@
# How to open a Pull Request (PR)
A pull request (PR) enables you to send changes from your fork on GitHub to freeCodeCamp.org's main repository. Once you are done making changes to the code, you can follow these guidelines to open a PR.
## 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.
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
> [!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/French/how-to-setup-freecodecamp-locally.md
View File

@ -1,546 +0,0 @@
Follow these guidelines for setting up freeCodeCamp locally on your system. This is highly recommended if you want to contribute regularly.
Some of these contribution workflows – like fixing bugs in the codebase or curriculum – need you to run freeCodeCamp locally on your computer.
> [!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.)
### How to prepare your local machine
Start by installing the prerequisite software for your operating system.
We primarily support development on Linux and Unix-based systems. Our staff and community contributors regularly work with the codebase using tools installed on Ubuntu and macOS.
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 ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
> [!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, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
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/French/how-to-setup-wsl.md
View File

@ -1,129 +0,0 @@
# 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/French/how-to-use-docker-on-windows-home.md
View File

@ -1,15 +0,0 @@
# 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.

622
docs/i18n/French/how-to-work-on-coding-challenges.md
View File

@ -1,622 +0,0 @@
# How to work on coding challenges
Our goal is to develop a fun and clear interactive learning experience.
Designing interactive coding challenges is difficult. It would be much easier to write a lengthy explanation or to create a video tutorial. But for our core curriculum, we're sticking with what works best for most people - a fully interactive, video game-like experience.
We want campers to achieve a flow state. We want them to build momentum and blast through our curriculum with as few snags as possible. We want them to go into the projects with confidence and gain a wide exposure to programming concepts.
Note that for Version 7.0 of the freeCodeCamp curriculum, we are moving toward [an entirely project-focused model with a lot more repetition](https://www.freecodecamp.org/news/python-curriculum-is-live/).
Creating these challenges requires immense creativity and attention to detail. There's plenty of help available. You'll have support from a whole team of contributors to whom you can bounce ideas off and demo your challenges.
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
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 (e.g. "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:
```md
Use <code>parseInt</code> to convert the variable <code>realNumber</code> into an integer.
```
- References to file names and path directories (e.g. `package.json`, `src/components`) should be wrapped in `<code>` tags.
- 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**. See example below:
**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.
````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 single-quotes where applicable
**Note:** The equivalent _Markdown_ should be used, where applicable, in place of _HTML_ tags.
## 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
### Seed code comments
We have a [comment dictionary](/curriculum/dictionaries/english/comments.js) that contains the only comments that can be used within the seed code. The exact case and spacing of the dictionary comment must be used. The comment dictionary should not be expanded without prior discussion with the dev-team.
Comments used should have a space between the comment characters and the comment themselves. In general comments should be used sparingly. Always consider rewriting a challenge's description or instructions if it could avoid using a seed code comment.
Example of valid single line JavaScript comment:
```js
// Only change code below this line
````
Example of a valid CSS comment:
```js
/* Only change code above this line */
```
If a challenge only has a single place where code changes are needed, please use the comments in the following example to instruct the user where changes should be made.
```js
var a = 3;
var b = 17;
var c = 12;
// Only change code below this line
a = a + 12;
b = 9 + b;
c = c + 7;
```
If a challenge has multiple places where the user is expected to change code (i.e. the React challenges)
```jsx
class MyComponent extends React.Component {
constructor(props) {
super(props);
this.state = {
text: "Hello"
};
// Change code below this line
// Change code above this line
}
handleClick() {
this.setState({
text: "You clicked!"
});
}
render() {
return (
<div>
{ /* Change code below this line */ }
<button>Click Me</button>
{ /* Change code above this line */ }
<h1>{this.state.text}</h1>
</div>
);
}
};
```
### Translation of seed code comments
There are separate comment dictionaries for each language. The [English vesion of the comment dictionary](/curriculum/dictionaries/english/comments.js) is the basis for the translations found in the corresponding non-English versions of the files. The non-English version of the Chinese comment dictionary would be located at `/curriculum/dictionaries/chinese/comments.js`. Each dictionary consists of an array of objects with a unique `id` property and a `text` property. Only the `text` should be modified to encompass the translation of the corresponding English comment.
Some comments may contain a word/phrase that should not be translated. For example, variable names or proper library names like "React" should not be translated. See the comment below as an example. The word `myGlobal` should not be translated.
```text
Declare the myGlobal variable below this line
```
> [!NOTE]
>
> We are working on an integration to make it possible to work on i18n for the comment dictionary.
## 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>

54
docs/i18n/French/how-to-work-on-the-docs-theme.md
View File

@ -1,54 +0,0 @@
# 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:
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
docsify serve docs
```
Install `docsify`:
```console
npm install -g docsify
```
and serve the `/docs` directory
```console
docsify serve docs
```
Alternatively, if you have installed freeCodeCamp locally (see the local setup guide), we bundle the CLI with the development tools so you can run any of the below commands as needed from the root of the repo:
### Serve and launch the documentation site only
```console
npm run docs:serve
```
### Serve the documentation site alongside freeCodeCamp locally:
```console
npm run develop
```
> The documentation site should be available at <http://localhost:3200>

99
docs/i18n/French/how-to-work-on-the-news-theme.md
View File

@ -1,99 +0,0 @@
# How to work on freeCodeCamp.org's developer news theme
The developer news also known as [`/news`](https://www.freecodecamp.org/news) site is powered by [Ghost](https://ghost.org/). We use a custom theme for the look and feel of the site. The source code of the theme is available here: <https://github.com/freeCodeCamp/news-theme>.
## The Theme
Ghost uses a simple templating language called [Handlebars](http://handlebarsjs.com/) for its themes. The theme used on `/news` is based off of the default [casper theme](https://github.com/TryGhost/Casper).
The default theme pretty heavily so that it should be fairly easy to work out what's going on just by reading the code and the comments. Once you feel comfortable with how everything works, Ghost also has a full [theme API documentation](https://themes.ghost.org) which explains every possible Handlebars helper and template.
**The main files are:**
- `default.hbs` - The main template file
- `index.hbs` - Used for the home page
- `post.hbs` - Used for individual posts
- `page.hbs` - Used for individual pages
- `tag.hbs` - Used for tag archives
- `author.hbs` - Used for author archives
One really neat trick is that you can also create custom one-off templates just by adding the slug of a page to a template file. For example:
- `page-about.hbs` - Custom template for the `/about/` page
- `tag-news.hbs` - Custom template for `/tag/news/` archive
- `author-ali.hbs` - Custom template for `/author/ali/` archive
## Development
1. Get Ghost installed locally.
```sh
npm install -g ghost-cli@latest
mkdir ghost-local-site
cd ghost-local-site
```
```sh
ghost install local
ghost start
```
> Note: Currently freeCodeCamp uses Ghost version `2.9.0`, so make sure you are using a version higher than that.
Be sure to run `ghost` commands from the `ghost-local-site` directory. Follow additional instructions on [Ghost's official documentation](https://docs.ghost.org) if are not familiar with its interface.
2. Fork and clone the repository in your theme directory:
```sh
cd content/themes/
git clone https://github.com/YOUR_USERNAME/news-theme.git
```
3. Make sure you have all the pre-requisites.
The theme styles are compiled using Gulp/PostCSS to polyfill future CSS spec. You'll need [Node.js](https://nodejs.org/). Make sure that your Node.js version is compatible with `ghost`.
4. Install dependencies and develop the theme
```sh
npm ci
npm run develop
```
5. Now you can edit `/assets/css/` files, which will be compiled to `/assets/built/` automatically.
6. Access the development site.
a. Enter `http://localhost:2368/ghost/` into your address bar. Continue with the setup prompted on the page (if running ghost for the first time).
b. _(One-time only, during setup)_ Restart Ghost, on a separate terminal once to ensure the theme is available.
```sh
cd ghost-local-site
ghost restart
```
c. _(One-time only, during setup)_ Once you've done this, go to `http://localhost:2368/ghost/#/settings/design` and scroll to the bottom. Make sure you click activate on the `freecodecamp-news-theme`.
7. Zip the final code and make a pull-request
The `zip` Gulp task packages the theme files into `dist/<theme-name>.zip`, which we can then upload to the production site.
When you make a PR, please make sure you have run the below script prior to commiting the code and sending a PR.
```sh
npm run zip
```
## Other Reference and resources
### PostCSS Features Used
- Autoprefixer - Don't worry about writing browser prefixes of any kind, it's all done automatically with support for the latest 2 major versions of every browser.
- Variables - Simple pure CSS variables
- [Color Function](https://github.com/postcss/postcss-color-function)
### SVG Icons
The theme uses inline SVG icons, included via Handlebars partials. You can find all icons inside `/partials/icons`. To use an icon just include the name of the relevant file, eg. To include the SVG icon in `/partials/icons/rss.hbs` - use `{{> "icons/rss"}}`.
You can add your own SVG icons in the same manner.

43
docs/i18n/French/index.md
View File

@ -1,43 +0,0 @@
The [freeCodeCamp.org](https://freecodecamp.org) community is possible thanks to thousands of kind volunteers like you. If you want to contribute your time and expertise, we would be excited to welcome you aboard.
> [!NOTE] Before you proceed, please take a quick 2 minutes to read our [Code of Conduct](https://www.freecodecamp.org/code-of-conduct). We strictly enforce it across our community so that contributing to freeCodeCamp.org is a safe, inclusive experience for everyone.
Happy contributing.
You are welcome to:
- Create, update and fix bugs in our [curriculum](#curriculum).
- Help us fix bugs in freeCodeCamp.org's [learning platform](#learning-platform).
- _(Coming Soon)_ Help us translate freeCodeCamp.org to world languages.
We answer the most common questions about contributing [in our contributor FAQ](/FAQ.md).
## Curriculum
Our curriculum is curated by the global freeCodeCamp community. This way, we are able to incorporate expert knowledge from volunteers like you.
You can help expand and improve the curriculum. You can also update project user stories to better-explain concepts. And you can improve our automated tests so that we can more accurately test people's code.
**If you're interested in improving our curriculum, here's [how to contribute to the curriculum](how-to-work-on-coding-challenges.md).**
## Learning Platform
Our learning platform runs on a modern JavaScript stack. It has various components, tools, and libraries. These include Node.js, MongoDB, OAuth 2.0, React, Gatsby, Webpack, and more.
Broadly, we use
- a Node.js based API server
- a set of React-based client applications
- and testing scripts to evaluate camper-submitted curriculum projects.
If you want to productively contribute to the curriculum, we recommend some familiarity with these tools.
If you want to help us improve our codebase...
**you can either use Gitpod, a free online dev environment that starts a ready-to-code dev environment for freeCodeCamp in your browser.**
[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
Or you can...
**[set up freeCodeCamp locally](how-to-setup-freecodecamp-locally.md) on your machine.**

456
docs/i18n/French/moderator-handbook.md
View File

@ -1,456 +0,0 @@
# 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!
## 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 ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
```
### Closing invalid pull requests
> When PR is invalid.
```markdown
Hey @username
Thank you for opening this pull request.
This is a standard message notifying you that we've reviewed your pull request and have decided not to merge it. We would welcome future pull requests from you.
Thank you and happy coding.
```

82
docs/i18n/German/FAQ.md
View File

@ -1,82 +0,0 @@
### 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 comprehensive reference for first-timer-friendly projects. And it includes a lot of open source contribution tips.
### Can I translate freeCodeCamp's curriculum?
Yes. We will roll out the tools for translating freeCodeCamp's curriculum soon.
Eventually, we intend to localize freeCodeCamp into several major world languages, starting with: Arabic, Chinese, Hindi, Portuguese, Russian, and Spanish.
### 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 these GitHub issues are for codebase-related issues and discussions – not for getting help with learning to code. Whenever in doubt, you should [seek assistance on the forum](https://forum.freecodecamp.org) before creating a GitHub issue.
### 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 work on a feature for academic credits?
Yes. Please note we are unable to commit to any timelines or paperwork that may be a requirement by your college or university. We receive many pull-requests and code contributions by volunteer developers, and we respect their time and efforts. Out of respect for all of our other contributors, we will not give any PR special priority just because it happens to be school-related.
We request you to plan ahead and work on code contributions 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?
Sie sollten durch [**`<code> Hilfe gesucht, die`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) oder [**`Erster Timer nur`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22first+timers+only%22) Tickets für einen schnellen Überblick über das zur Verfügung steht, an dem Sie arbeiten können.
> [!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 special issues that are designed for people who have not contributed to the freeCodeCamp codebase before.
### 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. Please be sure to mention details in the pull request description to help us understand and review your contribution – even if it's just a minor change.
Please do create an issue if you want to discuss bigger aspects of the codebase or curriculum.
### How can I get an issue assigned to me?
We typically do not assign issues to anyone other than long-time contributors. Instead, we follow the below policy to be fair to everyone:
1. We are most likely to merge the first pull request that addresses the issue.
2. In the case of multiple contributors opening a pull request for the same issue at around the same time, we will give priority to the pull request that best addresses the issue. Some of the things we consider:
- Did you include tests?
- Did you catch all usecases?
- Did you ensure all tests pass, and confirm everything works locally?
3. Finally, we give priority to pull requests which follow our recommended guidelines.
- Did you follow the pull request checklist?
- Did you give your pull request a meaningful title?
### I am stuck on something that is not included in this documentation.
**Feel free to ask for help in:**
- Die `Community` Kategorie von [unserem Community-Forum](https://forum.freecodecamp.org/c/contributors).
- Der `#Contributors` Kanal auf [unserem 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. If you ask us questions on the related issue threads, we will be glad to clarify. Be sure to search for your question before posting a new one.
Thanks in advance for being polite and patient. Remember – this community is run mainly by volunteers.
**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`**

38
docs/i18n/German/_sidebar.md
View File

@ -1,38 +0,0 @@
- **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)
---
<!-- The section below should not use relative linking -->
- **中文社区贡献指南**
- [成为专栏作者](/i18n/Chinese/news-author-application.md)
- [文章翻译计划](/i18n/Chinese/news-translations.md)
- [视频翻译计划](/i18n/Chinese/video-translations.md)
<!-- The section above should not use relative linking -->
---
- **Flight Manuals** (for Staff & Mods)
- [Moderator Handbook](moderator-handbook.md)
- [DevOps Handbook](devops.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)

715
docs/i18n/German/devops.md
View File

@ -1,715 +0,0 @@
# DevOps Handbook
This guide will help you understand our infrastructure stack and how we maintain our platforms. While this guide does not have exhaustive details for all operations, it could be used as a reference for your understanding of the systems.
Let us know, if you have feedback or queries, and we will be happy to clarify.
# Flight Manual - Code deployments
This repository is continuously built, tested and deployed to **separate sets of infrastructure (Servers, Databases, CDNs, etc.)**.
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.
Es ist identisch mit unserer Live-Produktionsumgebung unter `freeCodeCamp.org`, außer mit einem separaten Satz von Datenbanken, Servern, Webproxies usw. Diese Isolierung ermöglicht es uns, laufende Entwicklungen und Features in einem "Produktion" wie dem Szenario zu testen, ohne die normalen Benutzer der Hauptplattformen von FreeCodeCamp.org zu beeinträchtigen. This isolation lets us test ongoing development and features in a "production" like scenario, without affecting regular users of freeCodeCamp.org's main platforms.
Sobald das Entwicklerteam [`@freeCodeCamp/dev-team`](https://github.com/orgs/freeCodeCamp/teams/dev-team/members) mit den Änderungen auf der Staging-Plattform zufrieden ist, diese Änderungen werden alle paar Tage in den Produktionszweig [``](https://github.com/freeCodeCamp/freeCodeCamp/tree/production-current) verschoben.
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.
> [!HINWEIS] Wir sind auch dabei, Endanwender-Tests zu schreiben, die dazu beitragen, reale Weltszenarien wie das Aktualisieren einer E-Mail oder einen Aufruf an die API oder die Dienste von Drittanbietern zu replizieren.
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).
## Trigger a build, test and deploy
Currently, only members on the developer team can push to the production branches. The changes to the `production-*` branches can land only via fast-forward merge to the [`upstream`](https://github.com/freeCodeCamp/freeCodeCamp).
> [!HINWEIS] In den kommenden Tagen würden wir diesen Fluss verbessern, der über Pull-Requests erfolgen soll, um das Zugangsmanagement und die Transparenz zu verbessern.
### 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
```
> [!HINWEIS] Du wirst nicht in der Lage sein, Push zu erzwingen und wenn du den Verlauf auf jeden Fall neu geschrieben hast, werden diese Befehle fehlerhaft sein.
>
> 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] Der Build-Run dauert normalerweise ~20-25 Minuten, um den Release-Run abzuschließen, der ~15-20 Minuten dauert, für den Client und ~5-10 Minuten für die API verfügbar sein. 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
```
> [!HINWEIS] Du wirst nicht in der Lage sein, Push zu erzwingen und wenn du den Verlauf auf jeden Fall neu geschrieben hast, werden diese Befehle fehlerhaft sein.
>
> 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] Der Build-Run dauert normalerweise ~20-25 Minuten.
**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] Der Release-Run benötigt normalerweise ~15-20 Minuten für jede Clientinstanz, und ~5-10 Minuten für jede API-Instanz, um live verfügbar zu sein. 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. Manchmal werden diese Funktionen/Änderungen als **, Beta, Staging,** usw. bezeichnet.
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>
> [!HINWEIS] Der Domainname unterscheidet sich von **`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.
# Flight Manual - Server Maintenance
> [!WARNING]
>
> 1. The guide applies to the **freeCodeCamp Staff members only**.
> 2. These instructions should not be considered exhaustive, please use caution.
As a member of the staff, 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.
## Abfragen einer Liste der VMs
> [!HINWEIS] Während Sie möglicherweise bereits SSH-Zugriff auf die VMs haben, dass allein Ihnen keine VMs anzeigen lässt, es sei denn, Ihnen wurde auch Zugriff auf die Cloud-Portale gewährt.
### Azure
Install Azure CLI `az`: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli
> **(Einmalig) Installation unter macOS mit [`homebrew`](https://brew.sh):**
```
brew install azure-cli
```
> **(Einmalig) Login:**
```
az login
```
> **Abfragen der Liste der VM-Namen und IP-Adressen:**
```
az vm list-ip-addresses --output table
```
### Digital Ocean
Installiere Digital Ocean CLI `doctl`: https://github.com/digitalocean/doctl#installing-doctl
> **(Einmalig) Installation unter macOS mit [`homebrew`](https://brew.sh):**
```
brew install doctl
```
> **(Einmalig) Login:**
Authentifizierung und Kontextwechsel: https://github.com/digitalocean/doctl#Authentifizierung mit-digitalocean
```
doctl auth init
```
> **Abfragen der Liste VM-Namen und IP-Adressen:**
```
doctl compute droplet list --format "ID,Name,PublicIPv4"
```
## Hochfahren einer VM (oder eines VM Scale Set)
> Zu erledigen: Hinzufügen von Anleitungen zum Hoch- und Herunterfahren von 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.
-->
## VMs aktuell halten
Sie sollten die VMs auf dem Laufenden halten, indem Sie Updates und Upgrades durchführen. Dies wird sicherstellen, dass die virtuelle Maschine mit den neuesten Sicherheitskorrekturen gepatcht wird.
> [!WARNUNG] Bevor Sie diese Befehle ausführen:
>
> - Vergewissern Sie sich, dass die VM vollständig bereitgestellt wurde und dass nach der Installation keine Schritte ausgeführt werden.
> - Wenn Sie Pakete auf einer VM aktualisieren, die bereits eine Anwendung bedient, stellen Sie sicher, dass die App angehalten / gespeichert wurde. Paket-Aktualisierungen verursachen Netzwerk-Bandbreite, Speicher und/oder CPU-Auslastungsspikes, die zu Ausfällen bei laufenden Anwendungen führen.
Paket-Informationen aktualisieren
```console
sudo apt update
```
Installierte Pakete aktualisieren
```console
sudo apt upgrade -y
```
Unbenutzte Pakete entfernen
```console
sudo apt autoremove -y
```
## Arbeiten mit Web-Servern (Proxy)
Wir führen Lastbalancierungen (Azure Load Balancer) Instanzen für unsere Web-Server aus. Auf diesen Servern läuft NGINX, die den gesamten Datenverkehr auf FreeCodeCamp.org von verschiedenen Anwendungen rückgängig machen, die auf eigenen Infrastrukturen laufen.
Die NGINX-Konfiguration ist auf [dieses Repository](https://github.com/freeCodeCamp/nginx-config) verfügbar.
### Erste Installation
Provisionieren der VMs mit Code
#### 1. (Optional) Installieren Sie NGINX und konfigurieren Sie aus dem Repository.
Die Grundeinstellung sollte über die cloud-init-Konfiguration bereits vorhanden sein. SSH und nehmen Änderungen vor, die für die jeweilige Instanz(en) notwendig sind.
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. Installieren von Cloudflare Origin Certificates und Upstream-Anwendungskonfiguration.
Holen Sie sich die Cloudflare Ursprungszertifikate vom sicheren Speicher und installieren Sie an benötigten Standorten.
**ODER**
Vorhandene Zertifikate übertragen:
```console
# Lokal
scp -r username@source-server-public-ip:/etc/nginx/ssl ./
scp -pr ./ssl username@target-server-public-ip:/tmp/
# Auf dem Server
rm -rf ./ssl
mv /tmp/ssl ./
```
Upstream-Konfigurationen aktualisieren:
```console
vi configs/upstreams.conf
```
IP-Adressen der Quell-/Ursprungsanwendung hinzufügen/aktualisieren.
#### 3. Netzwerk und Firewalls einrichten.
Konfigurieren Sie Azure Firewalls und `ufw` je nach Bedarfsfall für eingehende Ursprungsadressen.
#### 4. Fügen Sie die VM dem Loadbalancer Backend Pool hinzu.
Falls erforderlich, konfigurieren und fügen Sie Regeln für den Loadbalancer hinzu. Möglicherweise müssen Sie auch die VMs hinzufügen, um den Bilanz-Backend Pool zu laden, falls nötig.
### Aktualisiere Instanzen (Wartung)
1. Prüfen Sie den Status des NGINX Services mit folgendem Befehl:
```console
sudo systemctl status nginx
```
2. Protokollierung und Überwachung der Server sind zu finden unter:
> <h3 align="center"><a href='https://amplify.nginx.com' _target='blank'>https://amplify.nginx.com</a></h3>
### Aktualisieren von Instanzen (Wartung)
Config Änderungen an unseren NGINX-Instanzen werden auf GitHub gepflegt. Diese sollten in jeder Instanz wie folgt eingesetzt werden:
1. Per SSH mit der Instanz verbinden und sudo eingeben
```console
sudo su
```
2. Herunterladen des neuesten Konfigurationscodes.
```console
cd /etc/nginx
git fetch --all --prune
git reset --hard origin/master
```
3. Testen und laden Sie die Konfiguration [mit Signalen](https://docs.nginx.com/nginx/admin-guide/basic-functionality/runtime-control/#controlling-nginx) neu.
```console
nginx -t
nginx -s reload
```
## Arbeiten an API-Instanzen
1. Installieren Sie Build-Tools für Node Binaries (`node-gyp`) etc.
```console
sudo apt install build-essential
```
### Erste Installation
Provisionieren der VMs mit Code
1. Node LTS installieren.
2. `npm` aktualisieren und PM2 installieren und Logrotate und Start beim Booten einrichten
```console
npm i -g npm
npm i -g pm2
pm2 install pm2-logrotate
pm2 startup
```
3. Klonen von freeCodeCamp, einrichten von env und Schlüsseln.
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
cd freeCodeCamp
git checkout production-current # oder einen andere auszurollenden Zweig
```
4. Erstellen Sie die `.env` aus dem geschützten Zugangsdatenspeicher.
5. Erstellen Sie die `google-credentials.json` aus dem geschützten Zugangsdatenspeicher.
6. Installation von Abhängigkeiten
```console
npm ci
```
7. Erstellen des Servers
```console
npm run ensure-env && npm run build:server
```
8. Starte Instanz
```console
cd api-server
pm2 start production-start.js -i max --max-memory-restart 600M --name org
```
### Aktualisiere Instanzen (Wartung)
```console
## Protokollierung und Überwachung
```console
pm2 Logs
```
```console
pm2 monit
```
### Aktualisieren von Instanzen (Wartung)
Code-Änderungen müssen von Zeit zu Zeit in den API-Instanzen verteilt werden. Es kann ein rollendes Update oder ein manuelles Update sein. Das spätere ist notwendig, wenn Abhängigkeiten geändert oder Umgebungsvariablen hinzugefügt werden.
> [!DANGER] Die automatisierten Pipelines bearbeiten keine Abhängigkeitsaktualisierungen in der Minute. Wir müssen eine manuelle Aktualisierung durchführen, bevor eine Deployment-Pipeline läuft.
#### 1. Manuelle Aktualisierungen - Wird für das Aktualisieren von Abhängigkeiten und env Variablen verwendet.
1. Stoppen aller Instanzen
```console
pm2 stop all
```
2. Installation von Abhängigkeiten
```console
npm ci
```
3. Erstellen des Servers
```console
npm run ensure-env && npm run build:server
```
4. Starte Instanz
```console
pm2 start all --update-env && pm2 logs
```
#### 2. Rollende Aktualisierungen - Wird für logische Änderungen am Code verwendet.
```console
pm2 reload all --update-env && pm2 logs
```
> [!NOTE] Wir handhaben rollende Aktualisierungen am Code, Logik, über Pipelines. You should not need to run these commands. Diese dienen der Dokumentation.
## Arbeiten an Client-Instanzen
1. Installieren Sie Build-Tools für Node Binaries (`node-gyp`) etc.
```console
sudo apt install build-essential
```
### Erste Installation
Provisionieren der VMs mit Code
1. Node LTS installieren.
2. `npm` aktualisieren und PM2 installieren und Logrotate und Start beim Booten einrichten
```console
npm i -g npm
npm i -g pm2
npm install -g serve
pm2 install pm2-logrotate
pm2 startup
```
3. Klonen von Client-Konfiguration, einrichten von env und Schlüsseln.
```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
```
Starte Platzhalter-Instanzen für den Web-Client, diese werden mit Artefakten aus der Azure Pipline aktualisiert.
> Todo: Dieses Setup muss in den S3 oder Azure Blob Speicher verschoben werden
>
> ```console
```console
echo "serve -c ../../serve.json www -p 50505" &#062;&#062; client-start-primary.sh
chmod +x client-start-primary. h
pm2 löschen Kunden primäre
pm2 Start . client-start-primary.sh --name client-primary
echo "serve -c . /../serve.json www -p 52525" &#062;&#062; client-start-secondary.sh
chmod +x client-start-secondary. h
pm2 löschen Kunde Sekundär
pm2 Start ./client-start-secondary.sh --name client-secondary
```
### Aktualisiere Instanzen (Wartung)
```console
## Protokollierung und Überwachung
```console
pm2 Logs
```
```console
pm2 monit
```
### Aktualisieren von Instanzen (Wartung)
Code-Änderungen müssen von Zeit zu Zeit in den API-Instanzen verteilt werden. Es kann ein rollendes Update oder ein manuelles Update sein. Das spätere ist notwendig, wenn Abhängigkeiten geändert oder Umgebungsvariablen hinzugefügt werden.
> [!DANGER] Die automatisierten Pipelines bearbeiten keine Abhängigkeitsaktualisierungen in der Minute. Wir müssen eine manuelle Aktualisierung durchführen, bevor eine Deployment-Pipeline läuft.
#### 1. Manuelle Aktualisierungen - Wird für das Aktualisieren von Abhängigkeiten und env Variablen verwendet.
1. Stoppen aller Instanzen
```console
pm2 stop all
```
2. Abhängigkeiten installieren oder aktualisieren
3. Starte Instanz
```console
pm2 start all --update-env && pm2 logs
```
#### 2. Rollende Aktualisierungen - Wird für logische Änderungen am Code verwendet.
```console
pm2 reload all --update-env && pm2 logs
```
> [!NOTE] Wir handhaben rollende Aktualisierungen am Code, Logik, über Pipelines. You should not need to run these commands. Diese dienen der Dokumentation.

100
docs/i18n/German/how-to-catch-outgoing-emails-locally.md
View File

@ -1,100 +0,0 @@
> **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.

195
docs/i18n/German/how-to-help-with-video-challenges.md
View File

@ -1,195 +0,0 @@
# 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: Eindeutige Kennung (alphanumerisch, MongoDB_id)
title: Challenge Title
challengeType: 11
videoId: 'YouTube videoId for video challenge'
--- ## Beschreibung
<section id='description'>
Eine optionale Beschreibung mit hilfreichen Informationen im Zusammenhang mit dem Video.
</section>
## Tests
<section id='tests'>
```yml
Frage:
Text: 'Frage'
Antworten:
-
````
</section>
````
## Erstellen von Fragen für Video-Challenge
### Zugriff auf die Video-Challenge-Markdown Dateien
Sie finden die Markdown Dateien für Video-Challenge an den folgenden Stellen im Lehrplan:
- [Datenanalyse mit Python-Kurse](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/german/11-machine-learning-with-python/tensorflow)
- [Numpy Course](https://github.com/freeCodeCamp/tree/master/curriculum/challenges/gerish/08-data-analysis-with-python/numpy)
- [How Neurral Networks Work Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/master/curriculum/challenges/english/11-machine-learning-with-python/how-neural-networks-work)
Wählen Sie eine Datei aus den obigen Optionen. ### Skim durch das Video, das mit der Challenge verbunden ist, und erstellen Sie eine mehrfache Frage
Zuerst finden Sie die videoID.
### 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 Titel: Datenanalyse Beispiel A ChallgeType: 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:
- | Hallo *Welt*
- | **Hallo** Welt
- | Hallo Welt Lösung: 3
````
``yml
Frage:
text: |
Was wird nach dem Ausführen dieses Codes ausgeben:
```py
Breite = 15
Höhe = 12. Drucken (Höhe/3)
````
answers:
- | 39
- | 4
- | 4.0
- | 5.0
- | 5 Lösung: 3
````
#### Beispiel mit HTML
```yml
Frage:
text: |
Was wird nach dem Ausführen dieses Codes ausgegeben:
<pre><code>Breite = 15<br>Höhe = 12.<br>print(height/3)<code></pre>
Antworten:
- |
39
- |
4
- |
4. |
5. |
5
Lösung: 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).

182
docs/i18n/German/how-to-open-a-pull-request.md
View File

@ -1,182 +0,0 @@
# How to open a Pull Request (PR)
A pull request (PR) enables you to send changes from your fork on GitHub to freeCodeCamp.org's main repository. Once you are done making changes to the code, you can follow these guidelines to open a PR.
## 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.
- Wenn der PR ein bestehendes GitHub Problem beheben soll, dann am Ende von der Beschreibungstext deines PR verwenden Sie das Schlüsselwort _Schließt_ mit der Ticketnummer zu [automatisch schließen, wenn der PR akzeptiert und zusammengeführt wird](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.
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
> [!TIPP] Wenn du mehr Pull-Requests beisteuern möchtest, wir empfehlen Ihnen, die [Änderungen durchzuführen und](https://contribute.freecodecamp.org/#/how-to-setup-freecodecamp-locally?id=making-changes-locally) Richtlinien zu synchronisieren, um zu vermeiden, dass Sie Ihren Fork löschen müssen.
## 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 .
# Entweder
git add .
git commit -m "chore: resolve conflicts"
# Oder
git add .
git commit --amend --no-edit
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/German/how-to-setup-freecodecamp-locally.md
View File

@ -1,546 +0,0 @@
Follow these guidelines for setting up freeCodeCamp locally on your system. This is highly recommended if you want to contribute regularly.
Some of these contribution workflows – like fixing bugs in the codebase or curriculum – need you to run freeCodeCamp locally on your computer.
> [!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.)
### How to prepare your local machine
Start by installing the prerequisite software for your operating system.
We primarily support development on Linux and Unix-based systems. Our staff and community contributors regularly work with the codebase using tools installed on Ubuntu and macOS.
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] Wenn Sie eine andere Version haben, installieren Sie bitte die empfohlene 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] Wir empfehlen dringend, die neuesten stabilen Versionen der oben aufgeführten Software zu aktualisieren, auch bekannt als 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] Bitte ignorieren Sie keine Verlinkungsfehler. 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] Das Hauptrepository unter `https://github.com/freeCodeCamp/freeCodeCamp` wird oft als das `Upstream` Repository bezeichnet.
>
> 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. Gehe zum FreeCodeCamp Repository auf GitHub: [https://github.com/freeCodeCamp/freeCodeCamp/freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp)
2. Click the "Fork" Button in the upper right-hand corner of the interface ([More Details Here](https://help.github.com/articles/fork-a-repo/))
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 ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
> [!TIPP] Du kannst FreeCodeCamp lokal überspringen, wenn du einfach Dateien bearbeitest. 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.
> [!TIPP] Denken Sie daran, wenn Sie Dienste wie Auth0 oder Algolia verwenden möchten Sie müssen Ihre eigenen API-Schlüssel für diese Dienste erwerben und die Einträge entsprechend im `bearbeiten. nv` Datei.
#### 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.
> [!HINWEIS] Wenn Sie die MongoDB nicht in einem anderen Setup als der Standardeinstellung laufen lassen die URL unter `MONGOHQ_URL` im `gespeichert. nv` Datei sollte gut funktionieren. 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
> [!TIPP] Du musst MongoDB nicht jedes Mal starten, indem du es als Hintergrunddienst installierst. 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.
> [!HINWEIS] Sobald Sie bereit sind, öffnen Sie einen Webbrowser und **besuchen Sie <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] Der API-Server dient APIs unter `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:
> [!WARNUNG] Wenn du eine ausstehende Pull-Anforderung hast, die du aus dem `Master` Branch deines Gabels gemacht hast Sie werden sie am Ende dieses Schrittes verlieren.
>
> 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
```
ODER
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, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
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/German/how-to-setup-wsl.md
View File

@ -1,129 +0,0 @@
# Set up freeCodeCamp on Windows Subsystem for Linux (WSL)
> [!HINWEIS] Bevor Sie diesen Anweisungen folgen, stellen Sie sicher, dass Ihr System die Anforderungen erfüllt
>
> **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
~
<unk> 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 für Windows** ermöglicht die Installation und Ausführung von Datenbanken und Diensten wie MongoDB, NGINX, etc. Dies ist nützlich, um häufige Fallstricke bei der Installation von MongoDB oder anderen Diensten direkt unter Windows oder WSL2 zu vermeiden. 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/German/how-to-use-docker-on-windows-home.md
View File

@ -1,15 +0,0 @@
# 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.

615
docs/i18n/German/how-to-work-on-coding-challenges.md
View File

@ -1,615 +0,0 @@
# How to work on coding challenges
Our goal is to develop a fun and clear interactive learning experience.
Designing interactive coding challenges is difficult. It would be much easier to write a lengthy explanation or to create a video tutorial. But for our core curriculum, we're sticking with what works best for most people - a fully interactive, video game-like experience.
We want campers to achieve a flow state. We want them to build momentum and blast through our curriculum with as few snags as possible. We want them to go into the projects with confidence and gain a wide exposure to programming concepts.
Note that for Version 7.0 of the freeCodeCamp curriculum, we are moving toward [an entirely project-focused model with a lot more repetition](https://www.freecodecamp.org/news/python-curriculum-is-live/).
Creating these challenges requires immense creativity and attention to detail. There's plenty of help available. You'll have support from a whole team of contributors to whom you can bounce ideas off and demo your challenges.
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
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: Eindeutige Kennung (alphanumerisch, MongoDB_id)
title: Challenge Title
challengeType: 0
videoUrl: 'url of video explanation'
--- ## Beschreibung
<section id='description'>
Eine Beschreibung der Challenge und was benötigt wird, um
</section>
## Anweisungen
<section id='instructions'>
Anweisungen zu geben, was genau getan werden muss.
</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.
Zum Beispiel:
```bash
$ mongo
MongoDB shell Version v3.6.1
verbindet zu: mongodb://127.0.0.1:27017
MongoDB Server Version: 3.4.10
...
$ ObjectId()
ObjectId("5a474d78df58bafeb3535d34")
$ 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\]\[Objektklausel\]
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 (e.g. "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:
```md
Use <code>parseInt</code> to convert the variable <code>realNumber</code> into an integer.
```
- References to file names and path directories (e.g. `package.json`, `src/components`) should be wrapped in `<code>` tags.
- 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**. See example below:
**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.
````md
The following is an example of code:
```{language}
[YOUR CODE HERE]
````
````
- Zusätzliche Informationen in Form einer Notiz sollten formatiert werden `<strong>Hinweis:</strong> Rest der Notiz Text... Wenn mehrere Notizen benötigt werden dann listet alle Notizen in separaten sentences mit dem Format `<strong>Notizen:</strong> First note text. Second note text.`.
- Use single-quotes where applicable
**Note:** The equivalent _Markdown_ should be used, where applicable, in place of _HTML_ tags.
## 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
### Seed code comments
We have a [comment dictionary](/curriculum/dictionaries/english/comments.js) that contains the only comments that can be used within the seed code. The exact case and spacing of the dictionary comment must be used. The comment dictionary should not be expanded without prior discussion with the dev-team.
Comments used should have a space between the comment characters and the comment themselves. In general comments should be used sparingly. Always consider rewriting a challenge's description or instructions if it could avoid using a seed code comment.
Example of valid single line JavaScript comment:
```js
// Only change code below this line
````
Example of a valid CSS comment:
```js
/* Only change code above this line */
```
If a challenge only has a single place where code changes are needed, please use the comments in the following example to instruct the user where changes should be made.
```js
var a = 3;
var b = 17;
var c = 12;
// Only change code below this line
a = a + 12;
b = 9 + b;
c = c + 7;
```
If a challenge has multiple places where the user is expected to change code (i.e. the React challenges)
```jsx
class MyComponent extends React.Component {
constructor(props) {
super(props);
this.state = {
text: "Hello"
};
// Change code below this line
// Change code above this line
}
handleClick() {
this.setState({
text: "You clicked!"
});
}
render() {
return (
<div>
{ /* Change code below this line */ }
<button>Click Me</button>
{ /* Change code above this line */ }
<h1>{this.state.text}</h1>
</div>
);
}
};
```
### Translation of seed code comments
There are separate comment dictionaries for each language. The [English vesion of the comment dictionary](/curriculum/dictionaries/english/comments.js) is the basis for the translations found in the corresponding non-English versions of the files. The non-English version of the Chinese comment dictionary would be located at `/curriculum/dictionaries/chinese/comments.js`. Each dictionary consists of an array of objects with a unique `id` property and a `text` property. Only the `text` should be modified to encompass the translation of the corresponding English comment.
Some comments may contain a word/phrase that should not be translated. For example, variable names or proper library names like "React" should not be translated. See the comment below as an example. The word `myGlobal` should not be translated.
```text
Declare the myGlobal variable below this line
```
> [!NOTE]
>
> We are working on an integration to make it possible to work on i18n for the comment dictionary.
## 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. Dies ist ein optionaler Abschnitt
#### Relevante Links
- [Link Text](link_url_goes_here)
- [Link Text](link_url_goes_here)
--- ## Hinweise
### Hinweis 1
Tipp geht hierher
### Hinweis 2
Hinweis geht hierher
--- ## Lösungen
<details><summary>Lösung 1 (Klicken Sie auf Anzeigen/Verbergen)</summary>
```js
Funktion myFunc() {
Konsole. og('Hallo Welt!');
}
````
#### 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. Dies wurde noch nicht vollständig abgeschlossen, aber Folgendes sollte sich der letzten Struktur annähern:
``mdx
--- id: Einzigartige Kennung (alphanumerisch, MongoDB_id)
Titel: 'Challenge Title'
ChallengeType: Integer, definiert in `client/utils/challengeTypen. s`
videoUrl: 'url of video explaination'
forumTopicId: 12345
--- import Script von './script. dx';
## --step-description--
Beschreibungstext in Markdown
```html
<div>
Beispielcode
</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">
Weitere Antworten
</p>
<hr />
<p spaces-before="0">
Antwort 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">
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>

54
docs/i18n/German/how-to-work-on-the-docs-theme.md
View File

@ -1,54 +0,0 @@
# 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:
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
docsify serve docs
```
Install `docsify`:
```console
npm install -g docsify
```
and serve the `/docs` directory
```console
docsify serve docs
```
Alternatively, if you have installed freeCodeCamp locally (see the local setup guide), we bundle the CLI with the development tools so you can run any of the below commands as needed from the root of the repo:
### Serve and launch the documentation site only
```console
npm run docs:serve
```
### Serve the documentation site alongside freeCodeCamp locally:
```console
npm run develop
```
> The documentation site should be available at <http://localhost:3200>

99
docs/i18n/German/how-to-work-on-the-news-theme.md
View File

@ -1,99 +0,0 @@
# How to work on freeCodeCamp.org's developer news theme
The developer news also known as [`/news`](https://www.freecodecamp.org/news) site is powered by [Ghost](https://ghost.org/). We use a custom theme for the look and feel of the site. The source code of the theme is available here: <https://github.com/freeCodeCamp/news-theme>.
## The Theme
Ghost uses a simple templating language called [Handlebars](http://handlebarsjs.com/) for its themes. The theme used on `/news` is based off of the default [casper theme](https://github.com/TryGhost/Casper).
The default theme pretty heavily so that it should be fairly easy to work out what's going on just by reading the code and the comments. Once you feel comfortable with how everything works, Ghost also has a full [theme API documentation](https://themes.ghost.org) which explains every possible Handlebars helper and template.
**The main files are:**
- `default.hbs` - The main template file
- `index.hbs` - Used for the home page
- `post.hbs` - Used for individual posts
- `page.hbs` - Used for individual pages
- `tag.hbs` - Used for tag archives
- `author.hbs` - Used for author archives
One really neat trick is that you can also create custom one-off templates just by adding the slug of a page to a template file. For example:
- `page-about.hbs` - Custom template for the `/about/` page
- `tag-news.hbs` - Custom template for `/tag/news/` archive
- `author-ali.hbs` - Custom template for `/author/ali/` archive
## Development
1. Get Ghost installed locally.
```sh
npm install -g ghost-cli@latest
mkdir ghost-local-site
cd ghost-local-site
```
```sh
ghost install local
ghost start
```
> Note: Currently freeCodeCamp uses Ghost version `2.9.0`, so make sure you are using a version higher than that.
Be sure to run `ghost` commands from the `ghost-local-site` directory. Follow additional instructions on [Ghost's official documentation](https://docs.ghost.org) if are not familiar with its interface.
2. Fork and clone the repository in your theme directory:
```sh
cd content/themes/
git clone https://github.com/YOUR_USERNAME/news-theme.git
```
3. Make sure you have all the pre-requisites.
The theme styles are compiled using Gulp/PostCSS to polyfill future CSS spec. You'll need [Node.js](https://nodejs.org/). Make sure that your Node.js version is compatible with `ghost`.
4. Install dependencies and develop the theme
```sh
npm ci
npm run develop
```
5. Now you can edit `/assets/css/` files, which will be compiled to `/assets/built/` automatically.
6. Access the development site.
a. Enter `http://localhost:2368/ghost/` into your address bar. Continue with the setup prompted on the page (if running ghost for the first time).
b. _(One-time only, during setup)_ Restart Ghost, on a separate terminal once to ensure the theme is available.
```sh
cd ghost-local-site
ghost restart
```
c. _(One-time only, during setup)_ Once you've done this, go to `http://localhost:2368/ghost/#/settings/design` and scroll to the bottom. Make sure you click activate on the `freecodecamp-news-theme`.
7. Zip the final code and make a pull-request
The `zip` Gulp task packages the theme files into `dist/<theme-name>.zip`, which we can then upload to the production site.
When you make a PR, please make sure you have run the below script prior to commiting the code and sending a PR.
```sh
npm run zip
```
## Other Reference and resources
### PostCSS Features Used
- Autoprefixer - Don't worry about writing browser prefixes of any kind, it's all done automatically with support for the latest 2 major versions of every browser.
- Variables - Simple pure CSS variables
- [Color Function](https://github.com/postcss/postcss-color-function)
### SVG Icons
The theme uses inline SVG icons, included via Handlebars partials. You can find all icons inside `/partials/icons`. To use an icon just include the name of the relevant file, eg. To include the SVG icon in `/partials/icons/rss.hbs` - use `{{> "icons/rss"}}`.
You can add your own SVG icons in the same manner.

43
docs/i18n/German/index.md
View File

@ -1,43 +0,0 @@
The [freeCodeCamp.org](https://freecodecamp.org) community is possible thanks to thousands of kind volunteers like you. If you want to contribute your time and expertise, we would be excited to welcome you aboard.
> [!HINWEIS] Bevor Sie fortfahren, nehmen Sie sich bitte eine kurze 2 Minuten Zeit, um unseren [Code of Conduct](https://www.freecodecamp.org/code-of-conduct) zu lesen. We strictly enforce it across our community so that contributing to freeCodeCamp.org is a safe, inclusive experience for everyone.
Happy contributing.
You are welcome to:
- Create, update and fix bugs in our [curriculum](#curriculum).
- Help us fix bugs in freeCodeCamp.org's [learning platform](#learning-platform).
- _(Coming Soon)_ Help us translate freeCodeCamp.org to world languages.
We answer the most common questions about contributing [in our contributor FAQ](/FAQ.md).
## Curriculum
Our curriculum is curated by the global freeCodeCamp community. This way, we are able to incorporate expert knowledge from volunteers like you.
You can help expand and improve the curriculum. You can also update project user stories to better-explain concepts. And you can improve our automated tests so that we can more accurately test people's code.
**If you're interested in improving our curriculum, here's [how to contribute to the curriculum](how-to-work-on-coding-challenges.md).**
## Learning Platform
Our learning platform runs on a modern JavaScript stack. It has various components, tools, and libraries. These include Node.js, MongoDB, OAuth 2.0, React, Gatsby, Webpack, and more.
Broadly, we use
- a Node.js based API server
- a set of React-based client applications
- and testing scripts to evaluate camper-submitted curriculum projects.
If you want to productively contribute to the curriculum, we recommend some familiarity with these tools.
If you want to help us improve our codebase...
**you can either use Gitpod, a free online dev environment that starts a ready-to-code dev environment for freeCodeCamp in your browser.**
[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
Or you can...
**[set up freeCodeCamp locally](how-to-setup-freecodecamp-locally.md) on your machine.**

456
docs/i18n/German/moderator-handbook.md
View File

@ -1,456 +0,0 @@
# 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. Sie können dies oft sofort sagen, wenn der Beitragende sich nicht die Mühe gemacht hat, die Kontrollkästchen im Pull-Request Template anzukreuzen, oder verwendet einen generischen Pull-Request-Titel wie "Änderungen gemacht" oder "Aktualisierungsindex.
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; Wenn es irgendwelche Unklarheiten bezüglich der richtigen Vorgehensweise bei einem Thema gibt Sie können @raisedadead zu diesem Thema markieren und dann den `Discussing` Label hinzufügen.
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.
Wenn du bemerkst, dass jemand den [-Verhaltenskodex](https://code-of-conduct.freecodecamp.org) bei GitHub gebrochen hat oder Pull Requests mit böswilligen Inhalten oder Code öffnen, E-Mail dev@freecodecamp.
## 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. **Stellen Sie sicher, dass es den Verhaltenskodex verletzen sollte.** Nicht alle Verstöße gegen den Kodex waren als solcher beabsichtigt. 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. Melde mich zurück und bestätige, dass du sie gelesen hast. 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. **Lösche Nachrichten** Moderatoren können Nachrichten auf Discord löschen. 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. **Benutze nicht @everyone oder @here** Nutze nicht @everyone oder @here unter keinen Umständen! 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. **Droht nicht,**zu bannen oder zu unterbrechen. Wenn ein Camper den Verhaltenskodex verletzt, droht nicht, sie zu verbieten oder auszusetzen, und warnt sie nie in der Öffentlichkeit. 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. **Schlagen Sie sich nicht vor, ein Moderator zu sein** Sehen Sie sich nicht als oberhalb der Community an. You are the community. Und die Community hat dir vertraut, etwas Seltenes zu schützen, das wir alle teilen - ein _, der_ Platz für neue Entwickler willkommen heißt. 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. **Widerspricht nicht anderen Moderatoren** Wenn du mit der Aktion eines Moderators nicht einverstanden bist mit ihnen privat sprechen oder sie im #mod-chat Channel ansprechen. 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. **Sprechen Sie mit anderen Moderatoren** Wir haben nur einen Raum für Moderatoren. 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. **Vorübergehend inaktiv** Wenn du aufgrund von Ferien nicht länger als Moderator aktiv bist, Krankheit oder irgendeinen anderen Grund, vergewissern Sie sich, dass die anderen im #mod-chat Channel informiert werden. 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
> [!HINWEIS] Ein Benutzer wird automatisch vom Aussetzen unseres Verhaltenskodexes benachrichtigt. 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!
## 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. 😊
--- > Fühlen Sie sich frei, die [Style-Anleitung zum Schreiben von Artikeln zu referenzieren](https://github. om/freeCodeCamp/freeCodeCamp#article-title) für dieses Repository auf die korrekte Formatierung eines Artikels, so dass deine Travis CI Build passt. ✅
>
> 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. 📝
````
### Verschmelzungskonflikte
> Wenn PR Konflikte hat, die gelöst werden müssen.1
```markdown
Hey @username
Wir würden gerne in der Lage sein, Ihre Änderungen zusammenzuführen, aber es sieht so aus, als hätten Sie einige Merge-Konflikte.
```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. 😊
--- > Wenn Sie mit dem Merge Konfliktprozess nicht vertraut sind Schauen Sie sich GitHubs Leitfaden auf ["Merge Contrat"](https://help an. ithub.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 ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
```
### Closing invalid pull requests
> When PR is invalid.
```markdown
Hey @username
Thank you for opening this pull request.
This is a standard message notifying you that we've reviewed your pull request and have decided not to merge it. We would welcome future pull requests from you.
Thank you and happy coding.
```

82
docs/i18n/Greek/FAQ.md
View File

@ -1,82 +0,0 @@
### 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 comprehensive reference for first-timer-friendly projects. And it includes a lot of open source contribution tips.
### Can I translate freeCodeCamp's curriculum?
Yes. We will roll out the tools for translating freeCodeCamp's curriculum soon.
Eventually, we intend to localize freeCodeCamp into several major world languages, starting with: Arabic, Chinese, Hindi, Portuguese, Russian, and Spanish.
### 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 these GitHub issues are for codebase-related issues and discussions – not for getting help with learning to code. Whenever in doubt, you should [seek assistance on the forum](https://forum.freecodecamp.org) before creating a GitHub issue.
### 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 work on a feature for academic credits?
Yes. Please note we are unable to commit to any timelines or paperwork that may be a requirement by your college or university. We receive many pull-requests and code contributions by volunteer developers, and we respect their time and efforts. Out of respect for all of our other contributors, we will not give any PR special priority just because it happens to be school-related.
We request you to plan ahead and work on code contributions 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 special issues that are designed for people who have not contributed to the freeCodeCamp codebase before.
### 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. Please be sure to mention details in the pull request description to help us understand and review your contribution – even if it's just a minor change.
Please do create an issue if you want to discuss bigger aspects of the codebase or curriculum.
### How can I get an issue assigned to me?
We typically do not assign issues to anyone other than long-time contributors. Instead, we follow the below policy to be fair to everyone:
1. We are most likely to merge the first pull request that addresses the issue.
2. In the case of multiple contributors opening a pull request for the same issue at around the same time, we will give priority to the pull request that best addresses the issue. Some of the things we consider:
- Did you include tests?
- Did you catch all usecases?
- Did you ensure all tests pass, and confirm everything works locally?
3. Finally, we give priority to pull requests which follow our recommended guidelines.
- Did you follow the pull request checklist?
- Did you give your pull request a meaningful title?
### 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 `#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. If you ask us questions on the related issue threads, we will be glad to clarify. Be sure to search for your question before posting a new one.
Thanks in advance for being polite and patient. Remember – this community is run mainly by volunteers.
**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`**

38
docs/i18n/Greek/_sidebar.md
View File

@ -1,38 +0,0 @@
- **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)
---
<!-- The section below should not use relative linking -->
- **中文社区贡献指南**
- [成为专栏作者](/i18n/Chinese/news-author-application.md)
- [文章翻译计划](/i18n/Chinese/news-translations.md)
- [视频翻译计划](/i18n/Chinese/video-translations.md)
<!-- The section above should not use relative linking -->
---
- **Flight Manuals** (for Staff & Mods)
- [Moderator Handbook](moderator-handbook.md)
- [DevOps Handbook](devops.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)

708
docs/i18n/Greek/devops.md
View File

@ -1,708 +0,0 @@
# DevOps Handbook
This guide will help you understand our infrastructure stack and how we maintain our platforms. While this guide does not have exhaustive details for all operations, it could be used as a reference for your understanding of the systems.
Let us know, if you have feedback or queries, and we will be happy to clarify.
# Flight Manual - Code deployments
This repository is continuously built, tested and deployed to **separate sets of infrastructure (Servers, Databases, CDNs, etc.)**.
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).
## Trigger a build, test and deploy
Currently, only members on the developer team can push to the production branches. The changes to the `production-*` branches can land only via fast-forward merge to the [`upstream`](https://github.com/freeCodeCamp/freeCodeCamp).
> [!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.
# Flight Manual - Server Maintenance
> [!WARNING]
>
> 1. The guide applies to the **freeCodeCamp Staff members only**.
> 2. These instructions should not be considered exhaustive, please use caution.
As a member of the staff, 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/Greek/how-to-catch-outgoing-emails-locally.md
View File

@ -1,100 +0,0 @@
> **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/Greek/how-to-help-with-video-challenges.md
View File

@ -1,199 +0,0 @@
# 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/Greek/how-to-open-a-pull-request.md
View File

@ -1,179 +0,0 @@
# How to open a Pull Request (PR)
A pull request (PR) enables you to send changes from your fork on GitHub to freeCodeCamp.org's main repository. Once you are done making changes to the code, you can follow these guidelines to open a PR.
## 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.
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
> [!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/Greek/how-to-setup-freecodecamp-locally.md
View File

@ -1,546 +0,0 @@
Follow these guidelines for setting up freeCodeCamp locally on your system. This is highly recommended if you want to contribute regularly.
Some of these contribution workflows – like fixing bugs in the codebase or curriculum – need you to run freeCodeCamp locally on your computer.
> [!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.)
### How to prepare your local machine
Start by installing the prerequisite software for your operating system.
We primarily support development on Linux and Unix-based systems. Our staff and community contributors regularly work with the codebase using tools installed on Ubuntu and macOS.
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 ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
> [!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, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
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/Greek/how-to-setup-wsl.md
View File

@ -1,129 +0,0 @@
# 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/Greek/how-to-use-docker-on-windows-home.md
View File

@ -1,15 +0,0 @@
# 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.

622
docs/i18n/Greek/how-to-work-on-coding-challenges.md
View File

@ -1,622 +0,0 @@
# How to work on coding challenges
Our goal is to develop a fun and clear interactive learning experience.
Designing interactive coding challenges is difficult. It would be much easier to write a lengthy explanation or to create a video tutorial. But for our core curriculum, we're sticking with what works best for most people - a fully interactive, video game-like experience.
We want campers to achieve a flow state. We want them to build momentum and blast through our curriculum with as few snags as possible. We want them to go into the projects with confidence and gain a wide exposure to programming concepts.
Note that for Version 7.0 of the freeCodeCamp curriculum, we are moving toward [an entirely project-focused model with a lot more repetition](https://www.freecodecamp.org/news/python-curriculum-is-live/).
Creating these challenges requires immense creativity and attention to detail. There's plenty of help available. You'll have support from a whole team of contributors to whom you can bounce ideas off and demo your challenges.
And as always, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [our Discord server](https://discord.gg/pFspAhS).
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 (e.g. "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:
```md
Use <code>parseInt</code> to convert the variable <code>realNumber</code> into an integer.
```
- References to file names and path directories (e.g. `package.json`, `src/components`) should be wrapped in `<code>` tags.
- 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**. See example below:
**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.
````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 single-quotes where applicable
**Note:** The equivalent _Markdown_ should be used, where applicable, in place of _HTML_ tags.
## 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
### Seed code comments
We have a [comment dictionary](/curriculum/dictionaries/english/comments.js) that contains the only comments that can be used within the seed code. The exact case and spacing of the dictionary comment must be used. The comment dictionary should not be expanded without prior discussion with the dev-team.
Comments used should have a space between the comment characters and the comment themselves. In general comments should be used sparingly. Always consider rewriting a challenge's description or instructions if it could avoid using a seed code comment.
Example of valid single line JavaScript comment:
```js
// Only change code below this line
````
Example of a valid CSS comment:
```js
/* Only change code above this line */
```
If a challenge only has a single place where code changes are needed, please use the comments in the following example to instruct the user where changes should be made.
```js
var a = 3;
var b = 17;
var c = 12;
// Only change code below this line
a = a + 12;
b = 9 + b;
c = c + 7;
```
If a challenge has multiple places where the user is expected to change code (i.e. the React challenges)
```jsx
class MyComponent extends React.Component {
constructor(props) {
super(props);
this.state = {
text: "Hello"
};
// Change code below this line
// Change code above this line
}
handleClick() {
this.setState({
text: "You clicked!"
});
}
render() {
return (
<div>
{ /* Change code below this line */ }
<button>Click Me</button>
{ /* Change code above this line */ }
<h1>{this.state.text}</h1>
</div>
);
}
};
```
### Translation of seed code comments
There are separate comment dictionaries for each language. The [English vesion of the comment dictionary](/curriculum/dictionaries/english/comments.js) is the basis for the translations found in the corresponding non-English versions of the files. The non-English version of the Chinese comment dictionary would be located at `/curriculum/dictionaries/chinese/comments.js`. Each dictionary consists of an array of objects with a unique `id` property and a `text` property. Only the `text` should be modified to encompass the translation of the corresponding English comment.
Some comments may contain a word/phrase that should not be translated. For example, variable names or proper library names like "React" should not be translated. See the comment below as an example. The word `myGlobal` should not be translated.
```text
Declare the myGlobal variable below this line
```
> [!NOTE]
>
> We are working on an integration to make it possible to work on i18n for the comment dictionary.
## 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>

54
docs/i18n/Greek/how-to-work-on-the-docs-theme.md
View File

@ -1,54 +0,0 @@
# 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:
```console
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
docsify serve docs
```
Install `docsify`:
```console
npm install -g docsify
```
and serve the `/docs` directory
```console
docsify serve docs
```
Alternatively, if you have installed freeCodeCamp locally (see the local setup guide), we bundle the CLI with the development tools so you can run any of the below commands as needed from the root of the repo:
### Serve and launch the documentation site only
```console
npm run docs:serve
```
### Serve the documentation site alongside freeCodeCamp locally:
```console
npm run develop
```
> The documentation site should be available at <http://localhost:3200>

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