+ Checking status on GitHub Actions (screenshot) +
++
+
+ 
+
+
+` tag and Crowdin has caught that.
+
+> [!WARNING]
+> You have the option to save a translation in spite of errors. If you do, by clicking "Save Anyway", you should also tag a proofreader or project manager and explain why the QA message needs to be ignored in this case.
+
+## Translation Best Practices
+
+Follow these guidelines to ensure our translations are as accurate as possible:
+
+- Do not translate the content within `` tags. These tags indicate text that is found in code and should be left in English.
+- Do not add additional content. If you feel a challenge requires changes in the text content or additional information, you should propose the changes through a GitHub issue or a pull request that modifies the English file.
+- Do not change the order of content.
+
+If you have any questions, feel free to reach out to us in our [translators chat room](https://chat.freecodecamp.org/channel/translators) and we will be happy to assist you.
diff --git a/docs/i18n/portuguese/how-to-translate-the-website.md b/docs/i18n/portuguese/how-to-translate-the-website.md
new file mode 100644
index 0000000000..6ce0c5dc60
--- /dev/null
+++ b/docs/i18n/portuguese/how-to-translate-the-website.md
@@ -0,0 +1,204 @@
+The client/react side of our website is translated into various world languages using [react-i18next](https://react.i18next.com/) and [i18next](https://www.i18next.com/).
+
+> [!NOTE]
+> Curriculum lesson content is [translated separately](./how-to-translate-files.md).
+
+## File Structure
+
+The files for translating the website are located in the `client/i18n` folder. Each language has a folder within that containing JSON files with the translations.
+
+The values in the `translations.json` file contain the majority of the text that appears on the website. The keys are used in the codebase to get the correct text for whatever language is set. This file needs to have the exact same keys in all languages.
+
+The `intro.json` file contains the key-value pairs for the introduction text on the certification pages.
+
+The `motivation.json` files are not required to have the same quotes, compliments, or array length. Just the same JSON structure. These are not translated via Crowdin.
+
+The `trending.json` file contians the titles and links for the trending news articles in the website's footer. These are not translated via Crowdin.
+
+The `meta-tags.json` file contains the information for our website's meta tag information. These are not translated via Crowdin.
+
+## Adding a Language
+
+To add a new language, create a folder with the language name as the title next to the other languages and copy the JSON files from another language into your new folder.
+
+In the `all-langs.js` file, add the language to the `client` array in the first variable. Then, follow the instructions in the comments to add the rest of the necessary variables.
+
+## How to Translate
+
+Translating the `intro.json` and `translations.json` are done through [our translation site](https://translate.freecodecamp.org). View our [translation documentation for that site](/how-to-translate-files.md).
+
+Modifications to the `trending.json`, `meta-tags.json`, and `motivation.json` files should typically only be done by staff.
+
+## Running it Locally
+
+Set the `CLIENT_LOCALE` variable in your `.env` file to the locale you want to build.
+
+> [!NOTE]
+> The value needs to be one of the client languages available in `config/i18n/all-langs.js`
+
+## How to Structure Components
+
+### Functional Component
+
+```js
+import { useTranslation } from 'react-i18next';
+
+// in the render method:
+const { t } = useTranslation();
+
+// call the "t" function with a key from the JSON file:
+{t('key')}
// more details below
+```
+
+### Class Component
+```js
+import { withTranslation } from 'react-i18next';
+
+// withTranslation adds the "t" function to props:
+const { t } = this.props;
+
+// call the "t" function with a key from the JSON file:
+{t('key')}
// more details below
+
+// export without redux:
+export default withTranslation()(Component);
+
+// or with redux:
+export default connect(...)(withTranslation()(Component));
+```
+
+## Translate Using the "t" Function
+
+### Basic Translation
+
+```js
+// in the component:
+{t('p1')}
+
+// in the JSON file:
+{
+ "p1": "My paragraph"
+}
+
+// output:
+My paragraph
+```
+
+### With Dynamic Data
+
+```js
+// in the component:
+const username = 'moT';
+
+{t('welcome', { username: username })}
+
+// in the JSON file:
+{
+ "welcome": "Welcome {{username}}"
+}
+
+// output:
+Welcome moT
+```
+
+The above example passes an object to the `t` function with a `username` variable. The variable will be used in the JSON value where `{{username}}` is.
+
+## Translate with the \ Component
+
+The general rule is to use the "t" function when you can. But there's a `Trans` component for when that isn't enough, usually when you have elements embedded in the text. You can use the `Trans` component with any type of react component.
+
+### Basic Elements Nested
+
+```js
+// in the component:
+import { Trans } from 'react-i18next'
+
+
+ fcc.greeting
+
+
+// in the JSON file:
+{
+ "fcc": {
+ "greeting": "Welcome to freeCodeCamp"
+ }
+}
+
+// output:
+Welcome to freeCodeCamp
+```
+
+You can place the key inside the component tags like the above example if the text contains "simple" tags with no attributes. `br`, `strong`, `i`, and `p` are the default, but that list can be expanded in the i18n config.
+
+### Complex Elements Nested
+
+Other times, you will want to have certain text inside another element, an anchor tag is a good example:
+
+```js
+// in the component:
+
+
+ placeholder
+
+
+
+// in the JSON file:
+{
+ "check-forum": "Check out <0>our forum."
+}
+
+// output:
+Check out our forum
+```
+
+In the above example, the key is set in the attributes of the `Trans` component. The `<0>` and `` in the JSON represent the first child of the component, in this case, the anchor element. If there were more children, they would just count up from there using the same syntax. You can find the children of a component in the react dev tools by inspecting it. `placeholder` is simply there because the linter was complaining at me about an empty `` element.
+
+### With a Variable
+
+```js
+// in the component:
+const email = 'team@freecodecamp.org';
+
+
+
+
+ {{ email }}
+
+
+
+
+// in the JSON file:
+{
+ "fcc": {
+ "email": "Send us an email at: <0>{{email}}"
+ }
+}
+
+// output:
+Send us an email at: team@freecodecamp.org
+```
+
+In the above example, the key and a variable are set in the attributes of the `Trans` component. `{{ email }}` needs to be somewhere in the `Trans` component as well, it doesn't matter where.
+
+## Changing Text
+
+To change text on the client side of things, go to the relevant `.json` file, find the key that is being used in the React component, and change the value to the new text you want. You should search the codebase for that key to make sure it isn't being used elsewhere. Or, if it is, that the changes make sense in all places.
+
+## Adding Text
+
+If the text you want to add to the client exists in the relevant `.json` file, use the existing key. Otherwise, create a new key.
+
+The English file is the "source of truth" for all of the `.json` files sharing the same name. If you need to add a new key, add it there. Then, add the key to **all** of the `translations.json` files.
+
+> [!NOTE]
+> Use English text for all languages if the file is translated through Crowdin. The tests will fail if you don't.
+
+It would be nice to keep the keys in the same order across all the files as well. Also, try to put all punctuation, spacing, quotes, etc in the JSON files and not in the components or server files.
+
+> [!NOTE]
+> The underscore (`_`) is a reserved character for keys in the client side files. See [the documentation](https://www.i18next.com/translation-function/plurals) for how they are used.
+
+## Helpful Documentation
+
+- [react-i18next docs](https://react.i18next.com/latest/usetranslation-hook)
+- [i18next docs](https://www.i18next.com/translation-function/essentials)
diff --git a/docs/i18n/portuguese/how-to-use-docker-on-windows-home.md b/docs/i18n/portuguese/how-to-use-docker-on-windows-home.md
new file mode 100644
index 0000000000..d336c2b94d
--- /dev/null
+++ b/docs/i18n/portuguese/how-to-use-docker-on-windows-home.md
@@ -0,0 +1,15 @@
+# How to use Docker on Windows Home
+
+There are a few pitfalls to be avoided when setting up Docker on Windows Home. First of all, you have to use [Docker Toolbox](https://docs.docker.com/toolbox/toolbox_install_windows/) as Administrator. Unfortunately Windows Home does not support Docker for Windows Desktop, so Toolbox must be used instead. It has to be run as Administrator as the installation uses symlinks, which cannot be created otherwise.
+
+Once you've installed the toolbox, run Docker Quickstart Terminal as Administrator. This will create a `default` virtual machine if it does not already exist. Once that has happened, close the terminal and open VirtualBox (again as Administrator). You should be able to see the `default` machine. The site is quite resource-intensive, so stop the virtual machine and raise the settings as much as you can - memory in particular. It has been confirmed to work with 4GB of ram.
+
+Once you're happy that Docker is working, clone the freeCodeCamp repository to a directory inside `C:\Users`. These directories are shared giving Docker access to the local directories, which it needs during installation.
+
+If you see messages like
+
+```shell
+bash: change_volumes_owner.sh: No such file or directory
+```
+
+when you `npm run docker:init` this is likely the culprit.
\ No newline at end of file
diff --git a/docs/i18n/portuguese/how-to-work-on-coding-challenges.md b/docs/i18n/portuguese/how-to-work-on-coding-challenges.md
new file mode 100644
index 0000000000..4791df79d3
--- /dev/null
+++ b/docs/i18n/portuguese/how-to-work-on-coding-challenges.md
@@ -0,0 +1,493 @@
+# 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 [the contributors chat room](https://chat.freecodecamp.org/channel/contributors).
+
+With your help, we can design an interactive coding curriculum that will help millions of people learn to code for years to come.
+
+The content for each challenge is stored in its markdown file. This markdown file is later converted to HTML using our tools to create interactive web pages.
+
+You can find all of freeCodeCamp.org's curricular content in the [`/curriculum/challenges`](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/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.
+
+ [](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.
+
+## Challenge Template
+
+````md
+
+---
+id: Unique identifier (alphanumerical, MongoDB_id)
+title: 'Challenge Title'
+challengeType: Integer, defined in `client/utils/challengeTypes.js`
+videoUrl: 'url of video explanation'
+forumTopicId: 12345
+---
+
+# --description--
+
+Challenge description text, in markdown
+
+```html
+
+ example code
+
+```
+
+# --instructions--
+
+Challenge instruction text, in markdown
+
+# --hints--
+
+Tests to run against user code, in pairs of markdown text and code block test code.
+
+```js
+Code for test one
+```
+
+More instructions in markdown syntax
+
+```js
+More code
+```
+
+# --seed--
+
+## --before-user-code--
+
+```lang
+Code evaluated before the user’s code.
+```
+
+## --after-user-code--
+
+```lang
+Code evaluated after the user’s code, and just before the tests
+```
+
+## --seed-contents--
+
+Boilerplate code to render to the editor. This section should only contain code inside backticks, like the following:
+
+```html
+
+
+ Hello world!
+
+
+```
+
+```css
+body {
+ margin: 0;
+ background-color: #3a3240;
+}
+
+.main-text {
+ color: #aea8d3;
+}
+```
+
+```js
+console.log('freeCodeCamp is awesome!');
+```
+
+# --solutions--
+
+Solutions are used for the CI tests to ensure that changes to the hints will still pass as intended
+
+```js
+// first solution - the language(s) should match the seed.
+```
+
+---
+
+```js
+// second solution - so if the seed is written in HTML...
+```
+
+---
+
+```js
+// third solution etc. - Your solutions should be in HTML.
+```
+
+# --question--
+
+These fields are currently used for the multiple-choice Python challenges.
+
+## --text--
+
+The question text goes here.
+
+## --answers--
+
+Answer 1
+
+---
+
+Answer 2
+
+---
+
+More answers
+
+## --video-solution--
+
+The number for the correct answer goes here.
+
+
+````
+
+> [!NOTE]
+>
+> 1. In the above sections, examples of `lang` are:
+>
+> - `html` - HTML/CSS
+> - `js` - JavaScript
+> - `jsx` - JSX
+
+## Numbering Challenges
+
+Every challenge needs an `id`. If you don't specify one, then MongoDB will create a new random one when it saves the data; however, we don't want it to do that, since we want the challenge ids to be consistent across different environments (staging, production, lots of different developers, etc.).
+
+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 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 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 `\`` backticks. For example, HTML tag names or CSS property names.
+- References to code parts (i.e. function, method, or variable names) should be wrapped in `\`` backticks. See example below:
+```md
+Use `parseInt` to convert the variable `realNumber` into an integer.
+```
+- References to file names and path directories (e.g. `package.json`, `src/components`) should be wrapped in `\`` backticks.
+- Multi-line code blocks **must be preceded by an empty line**. The next line must start with three backticks followed immediately by one of the [supported languages](https://prismjs.com/#supported-languages). To complete the code block, you must start a new line which only has three backticks and **another empty line**. See example below:
+- Whitespace matters in Markdown, so we recommend that you make it visible in your editor.
+
+**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.
+
+The following is an example of code:
+````md
+```{language}
+
+[YOUR CODE HERE]
+
+```
+````
+
+- Additional information in the form of a note should be surrounded by blank lines, and formatted: `**Note:** Rest of note text...`
+- If multiple notes are needed, then list all of the notes in separate sentences using the format: `**Notes:** First note text. Second note text.`
+- Use single-quotes where applicable
+
+**Note:** The equivalent _Markdown_ should be used 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:
+
+```css
+/* Only change code above this line */
+```
+
+If a challenge only has a single place where code changes are needed, please use the comments in the following example to instruct the user where changes should be made.
+
+```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 (
+
+ { /* Change code below this line */ }
+
+ { /* Change code above this line */ }
+ {this.state.text}
+
+ );
+ }
+};
+```
+
+### Translation of seed code comments
+
+There are separate comment dictionaries for each language. The [English version of the comment dictionary](/curriculum/dictionaries/english/comments.js) is the basis for the translations found in the corresponding non-English versions of the files. The non-English version of the Chinese comment dictionary would be located at `/curriculum/dictionaries/chinese/comments.js`. Each dictionary consists of an array of objects with a unique `id` property and a `text` property. Only the `text` should be modified to encompass the translation of the corresponding English comment.
+
+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 needs to be done without just restating the challenge description and/or instructions. This is an optional section
+
+#### Relevant Links
+
+- [Link Text](link_url_goes_here)
+- [Link Text](link_url_goes_here)
+
+---
+
+## Hints
+
+### Hint 1
+
+Hint goes here
+
+### Hint 2
+
+Hint goes here
+
+---
+
+## Solutions
+
+Solution 1 (Click to Show/Hide)
+
+```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)
+
+
+````
+
+## 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 (replacing `challenge-title-goes-here` with the full title of the challenge):
+
+ ```
+ npm run test -- -g challenge-title-goes-here
+ ```
+
+Once you have verified that each challenge you've worked on passes the tests, [please create a pull request](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/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.
+
+### Useful Links
+
+Creating and Editing Challenges:
+
+1. [Challenge types](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/client/utils/challengeTypes.js#L1-L13) - what the numeric challenge type values mean (enum).
+
+2. [Contributing to FreeCodeCamp - Writing ES6 Challenge Tests](https://www.youtube.com/watch?v=iOdD84OSfAE#t=2h49m55s) - a video following [Ethan Arrowood](https://twitter.com/ArrowoodTech) as he contributes to the old version of the curriculum.
diff --git a/docs/i18n/portuguese/how-to-work-on-the-docs-theme.md b/docs/i18n/portuguese/how-to-work-on-the-docs-theme.md
new file mode 100644
index 0000000000..ec30f81b45
--- /dev/null
+++ b/docs/i18n/portuguese/how-to-work-on-the-docs-theme.md
@@ -0,0 +1,55 @@
+# 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/main/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
diff --git a/docs/i18n/portuguese/how-to-work-on-the-news-theme.md b/docs/i18n/portuguese/how-to-work-on-the-news-theme.md
new file mode 100644
index 0000000000..59f1f2360e
--- /dev/null
+++ b/docs/i18n/portuguese/how-to-work-on-the-news-theme.md
@@ -0,0 +1,99 @@
+# 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: .
+
+## 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 is commented pretty heavily so that it should be fairly easy to work out what's going on just by reading the code and the comments. Once you feel comfortable with how everything works, Ghost also has a full [theme API documentation](https://themes.ghost.org) which explains every possible Handlebars helper and template.
+
+**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 (replacing `YOUR_USERNAME` with your GitHub username):
+
+ ```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/.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.
diff --git a/docs/i18n/portuguese/index.md b/docs/i18n/portuguese/index.md
new file mode 100644
index 0000000000..02f6c26883
--- /dev/null
+++ b/docs/i18n/portuguese/index.md
@@ -0,0 +1,52 @@
+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).
+- [Help us translate](#translations) 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).**
+
+## Translations
+
+We are localizing freeCodeCamp.org to world languages starting with Chinese and Espanol. We will be expanding the translations to more languages. It's our dream to provide you with resources to learn, no matter the world language you speak.
+
+To help us with this massive effort, we have integrated our open-source code-base & curriculum with [Crowdin](https://crowdin.com/).
+
+**If you're interested in translating, here are the guides to translate our [curriculum](how-to-translate-files.md), the [learning platform](how-to-translate-the-website.md) and our [Contributing guidelines](https://translate.freecodecamp.org/contributing-docs).**
+
+## 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.**
+
+[](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
+
+Or you can...
+
+**[set up freeCodeCamp locally](how-to-setup-freecodecamp-locally.md) on your machine.**
diff --git a/docs/i18n/portuguese/moderator-handbook.md b/docs/i18n/portuguese/moderator-handbook.md
new file mode 100644
index 0000000000..21718c96fb
--- /dev/null
+++ b/docs/i18n/portuguese/moderator-handbook.md
@@ -0,0 +1,505 @@
+# 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. We must 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:
+
+```markdown
+Thank you for your pull request.
+
+We are closing this pull request. Please add links and other details to the challenge's corresponding guide article instead.
+
+If you think we're wrong in closing this issue, please request for it to be reopened and add further clarification. Thank you, and happy coding.
+```
+
+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 same part of that same file. GitHub has a tool for addressing these merge conflicts right on GitHub. You can try to address these conflicts. Just use your best judgment. The pull request's changes will be on top, and the Master branch's changes will be on the bottom. Sometimes there will be redundant information in there that can be deleted. Before you finish, be sure to delete the `<<<<<<`, `======`, and `>>>>>>` that Git adds to indicate areas of conflict.
+
+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:
+
+
+
+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:
+
+```markdown
+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.
+
+```markdown
+Thank you for reporting this issue.
+
+This is a standard message notifying you that this issue seems to be a request for help. Instead of asking for help here, please click the **"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 it as `first timers only`, otherwise label it as `help wanted`. Use other labels as appropriate.
+- If the issue is more significant, flag it as `bug`.
+
+ 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.
+
+```markdown
+Thank you for reporting this issue.
+
+This is a standard message notifying you that this issue appears to be very similar to issue #XXXXX, so we are closing it as a duplicate.
+
+If you think we're wrong in closing this issue, please request for it to be reopened and add further clarification. Thank you and happy coding.
+```
+
+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:
+
+```markdown
+Thank you for reporting this issue.
+
+This is a standard message notifying you that the problem you mentioned here is present in production, but that it has already been fixed in staging. This means that the next time we push our staging branch to production, this problem should be fixed. Because of this, we're closing this issue.
+
+If you think we're wrong in closing this issue, please request for it to be reopened and add further clarification. Thank you and happy coding.
+```
+
+#### 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 judgment 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 and intentionally violates the Code of Conduct, the moderator will proceed as follows:**
+
+- Ban the offending person from the Discord Server. 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.
+- Report a short summary of the event in the #mod-log channel. Here's an example of what such a summary might look like:
+
+```
+Banned: _@username_
+Reason(s): _Spamming, trolling_
+Evidence: _One or more links to the offending message(s)_
+```
+
+- 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.
+
+3. **Creating a Private Discussion**
+
+There may be situations where you need to address a concern with a camper privately. This should not be done through DMs, as this can lead to situations where you claim one thing and the camper claims another. Instead, use the bot's functionality to create a private discussion:
+
+- Call the `!fCC moderate private @username` command, where `@username` is the _Discord mention_ of the user. If you are calling this command from a private channel (such as #mod-chat), you will need to parse the mention manually: Ensure you have Developer Mode turned on in your Discord settings, then right-click on the user's avatar and select `Copy ID`. Replace the `@username` parameter with `<@!ID>`, where `ID` is the value you copied earlier. The result should look like: `!fCC moderate private <@!465650873650118659>`.
+- The bot will create a new channel under the `private` category and add the `@username`-mentioned camper and all moderators with the `Your Friendly Moderator` role. While all moderators are added to the channel for transparency, the moderator who calls this command should be the only one to interact with the camper unless they request assistance.
+- When the conversation is complete, call the `!fCC moderate close` command _in the private channel_ to have the bot close and delete that channel.
+
+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 an advertisement and/or a self-promoting message/image (social media).
+
+In all other situations - even situations where the code of conduct is violated - Moderators should not delete the 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** If a camper is breaking the code of conduct, don’t threaten to ban them, and never warn them in public. Instead, talk to them privately using the bot's `private` command. No one else in that channel needs to know that you banned/suspended the person - 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 on the server or not.
+
+## Moderating our Chat Server
+
+Moderating the chat server is very similar to moderating the Discord server, but there are a few key differences:
+
+1. **No Ban functionality**
+ At this time, Rocket.Chat does not have a flow for banning users. Users can be muted (so they are prevented from chatting in a room) or kicked from a room.
+2. **Modified Bot Commands**
+ The moderation bot in the chat server was developed with a smoother UX in mind. Some of the commands have been modified. Use the `!fCC modHelp` command to view the available functionality. Bot commands in the chat server do NOT require a user mention as they do with Discord.
+3. **No Role Mentions**
+ Unlike Discord, Rocket.Chat does not allow you to mention all users by a specific role - this means you cannot ping all moderators at once.
+
+## 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 to some of our repositories.
+
+## How we retire inactive moderators
+
+Please note that we will frequently remove mods whom we think are inactive. When we do this we will send the following message:
+
+> 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 chat server](https://chat.freecodecamp.org/channel/contributors). 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: Create a private channel for the user and the mod team. This can be done with the bot's `private` command.
+
+- 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
+
+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: ` `
+
+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.
+
+
+
+Thanks for reading this, and thanks for helping the developer community!
+
+## Reply Templates
+
+These are some of the standard reply templates that you may use while reviewing pull requests and triaging issues.
+
+> 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 CI build. ⚠️
+
+Once you resolve these issues, We will be able to review your PR and merge it. 😊
+
+---
+
+Feel free to reference the [contributing guidelines](https://contribute.freecodecamp.org/#/how-to-work-on-coding-challenges?id=testing-challenges) for instructions on running the CI build locally. ✅
+```
+
+### Syncing Fork
+
+> When PR is not up to date with the `main` branch.
+
+````markdown
+Hey @username
+
+We would love to be able to merge your changes but it looks like the branch is not up to date. ⚠️
+
+To resolve this error, you will have to sync the latest changes from the `main` branch of the `freeCodeCamp/freeCodeCamp` repo.
+
+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. 🔄
+````
+
+### 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
+
+This PR seems to make similar changes as the existing PR <#number>. As such, we are going to close this as duplicate.
+
+If you feel you have additional changes to expand upon this PR, please feel free to push your commits and request this PR be reopened.
+
+Thanks again! 😊
+
+---
+
+If you have any questions, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [the contributors chat room](https://chat.freecodecamp.org/channel/contributors).
+```
+
+### 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.
+```
+
+> When PR adds links to external resources.
+
+```markdown
+Thank you for your pull request.
+
+We are closing this pull request. Please suggest links and other details to add the challenge's corresponding guide post through [a forum topic](https://forum.freecodecamp.org/new-topic?category=Contributors&title=&body=**What%20is%20your%20hint%20or%20solution%20suggestion%3F**%0A%0A%0A%0A%0A**Challenge%3A**%0A%0A%0A**Link%20to%20the%20challenge%3A**) instead.
+
+If you think we're wrong in closing this issue, please request for it to be reopened and add further clarification. Thank you, and happy coding.
+```
+
+### Closing Invalid Issues
+
+> When an issue relates to the camper's code.
+
+```markdown
+Thank you for reporting this issue.
+
+This is a standard message notifying you that this issue seems to be a request for help. Instead of asking for help here, please click the **"Get Help"** button on the challenge on freeCodeCamp and choose the **"Ask for help"** option, which will help you create a question in the right part of the forum. Volunteers on the forum usually respond to questions within a few hours and can help determine if there is an issue with your code or the challenge's tests.
+
+If the forum members determine there is nothing wrong with your code, you can request this issue to be reopened.
+
+Thank you and happy coding.
+```
+
+> When an issue is duplicate of an earlier issue
+
+```markdown
+Thank you for reporting this issue.
+
+This is a standard message notifying you that this issue appears to be very similar to issue #XXXXX, so we are closing it as a duplicate.
+
+If you think we're wrong in closing this issue, please request for it to be reopened and add further clarification. Thank you and happy coding.
+```
+
+> When an issue is fixed in staging.
+
+```markdown
+Thank you for reporting this issue.
+
+This is a standard message notifying you that the problem you mentioned here is present in production, but that it has already been fixed in staging. This means that the next time we push our staging branch to production, this problem should be fixed. Because of this, we're closing this issue.
+
+If you think we're wrong in closing this issue, please request for it to be reopened and add further clarification. Thank you and happy coding.
+```