` invece di `<0>0>`.
+
+## Tradurre il curriculum
+
+
+
+Crowdin separa un documento in "stringhe" (strings) da tradurre, in genere frasi. Ogni stringa è tradotta individualmente. Con riferimento all'immagine sopra:
+
+1. Una stringa evidenziata in verde ha già una traduzione proposta.
+2. Una stringa evidenziata in rosso _non_ ha una traduzione proposta.
+3. Una stringa con testo in grigio non è traducibile. Questo è il caso per blocchi di codice e altro contenuto che non deve essere tradotto. Non sarai in grado di selezionare queste stringhe nell'editor.
+4. Se un contributore ha già proposto una traduzione ad una stringa, Crowdin mostrerà qui queste proposte. Non sarai in grado di salvare una traduzione identica, invece se una traduzione è accurata dovresti usare l'icona `+` per darle un voto positivo. Una traduzione che è inaccurata può ricevere un voto negativo con l'icona `-`.
+5. Crowdin proporrà delle traduzioni basate su Memoria di Traduzione (Translation Memory - TM) e Traduzioni Automatiche (Machine Translation - MT). La Memoria di Traduzione si riferisce a stringhe simili o identiche che sono state tradotte/approvate in altri file. Le Traduzioni Automatiche si riferiscono a traduzioni raccomandate dalla loro libreria integrata.
+6. Questo è il pannello di modifica, dove puoi scrivere la tua proposta di traduzione per la stringa selezionata.
+7. La stringa attualmente selezionata nell'editor è evidenziata in giallo.
+8. Qui vedrai dei tag indicanti lo stato della stringa. `Done` significa che la stringa ha almento una traduzione proposta. `Todo` significa che la stringa non ha alcuna proposta di traduzione.
+9. Qui puoi vedere la finestra dei commenti. Se hai domande o dubbi su una particolare stringa, puoi lasciare un commento sulla stringa qui perché altri traduttori li vedano.
+10. Questi due pulsanti dei pannelli nasconderanno i pannelli a sinistra (documento) e a destra (commenti).
+
+> [!NOTE] Se vedi una stringa nascosta (hidden string) che include una traduzione, per favore faccelo sapere usanto la [chat room dei contributori](https://chat.freecodecamp.org/channel/contributors) così potremo rimuovere la traduzione dalla memoria.
+
+Quando hai finito la traduzione per una stringa, usa il pulsante `Save` per salvare la tua traduzione in Crowdin. Altri contributori potranno quindi votare la tua traduzione e i revisori potranno approvarla.
+
+Sentiti libero di tradurre quante stringhe vuoi, non ci sono step additionali richiesti quando completi un intero file o proponi una nuova traduzione. Usare il pulsante `Save` è tutto quello che serve per memorizzare una traduzione.
+
+> [!NOTE] Se vedi qualcosa nel file originale inglese che è inaccurato o non corretto, per favore non aggiustarlo con il processo di traduzione. Invece lascia un commento sulla stringa per farci sapere che c'è una discrepanza o crea una issue su GitHub.
+
+## Tradurre la Documentazione
+
+Tradurre la documentazione per contribuire è un processo simile alla traduzione dei file del curriculum.
+
+> [!NOTE] La documentazione per contribuire è creata tramite `docsify`, e ci sono regole speciali per riquadri di messaggio come questo. Se vedi una stringa che inizia con `[!NOTE]`, `[!WARNING]`, o `[!TIP]`, queste parole non devono essere tradotte.
+
+## Votare le traduzioni
+
+Crowdin ti permette di votare le proposte di traduzione esistenti. Se provi a salvare una traduzione, potresti vedere un messaggio che indica che non puoi salvare una traduzione duplicata: questo significa che un altro contributore ha proposto una traduzione identica. Se sei d'accordo con quella traduzione, usa il pulsante `+` per darle un voto positivo.
+
+Se vedi una traduzione che non è accurata o non è chiara come la stringa originale, usa il pulsante `-` per darle un voto negativo.
+
+Crowdin usa questi voti per dare un punteggio alle proposte di traduzione per una stringa, e questo aiuta il gruppo di revisione a determinare quale traduzione è la migliore per ogni stringa.
+
+## Controlli di qualità
+
+Abbiamo attivato alcuni step per il controllo di qualità che verificano che una traduzione sia per quanto possibile accurata: questo aiuta il team di revisione a revisionare le traduzioni proposte.
+
+Quando provi a salvare una traduzione, potresti vedere un messaggio di errore apparire relativamente alla tua proposta di traduzione.
+
+
+
+Questo messaggio appare quando il sistema QA (Quality Assurance) di Crowdin identifica un potenziale errore nella traduzione proposta. In questo esempio, abbiamo modificato il testo di un tag `` e Crowdin se ne è accorto.
+
+> [!WARNING] Hai la possibilità di salvare una traduzione anche se ci sono degli errori. Se lo fai usando il pulsante "Save Anyway" (Salva comunque), dovresti anche taggare un proofreader o un project managet e spiegare perché il messaggio QA dovrebbe essere ignorato in questo caso.
+
+## Buone pratiche per le traduzioni
+
+Segui queste linee guida per assicurati che le nostre traduzioni siano il più possibile accurate:
+
+- Non tradurre il contenuto dei tag ``. Questi tag indicano testo trovato nel codice e dovrebbero essere lasciati in inglese.
+- Non inserire contenuto aggiuntivo. Se pensi che una sfida richieda delle modifiche nel testo o informazioni aggiuntive dovresti proporre i cambiamenti tramite una issue su GitHub o una pull request che modifica i file inglesi.
+- Non cambiare l'ordine del contenuto.
+
+Se hai domande, scrivi nella [chat room per i contributori](https://chat.freecodecamp.org/channel/contributors) e saremo lieti di assisterti.
diff --git a/docs/i18n/italian/how-to-use-docker-on-windows-home.md b/docs/i18n/italian/how-to-use-docker-on-windows-home.md
new file mode 100644
index 0000000000..185b350e96
--- /dev/null
+++ b/docs/i18n/italian/how-to-use-docker-on-windows-home.md
@@ -0,0 +1,15 @@
+# Come usare Docker su Windows Home
+
+Ci sono alcuni pericoli da evitare quando si setta Docker su Windows Home. Per prima cosa devi usare [Docker Toolbox](https://docs.docker.com/toolbox/toolbox_install_windows/) come amministratore. Purtroppo Windows Home non supporta Docker per Windows Desktop, quindi deve essere usata la Toolbox. Essa deve essere eseguita come Amministratore in quanto l'installazione utilizza collegamenti simbolici che non possono essere creati altrimenti.
+
+Dopo aver installato la toolbox, esegui Docker Quickstart Terminal come amministratore. Questo creerà una virtual machine di `default`, se ancora non esiste. Dopo averlo fatto, chiudi il terminale e apri VirtualBox (ancora come Amministratore). Dovresti essere in grado di vedere la macchina di `default`. Il sito richiede molte risorse, quindi ferma la virtual machine e alza le impostazioni per quanto puoi, soprattutto la memoria. È stato confermato che lavora con 4GB di ram.
+
+Una volta che sarai felice perché Docker sta funzionando, clona il repository di freeCodeCamp in una directory all'interno di `C:\Users`. Queste directory sono condivise dando a Docker accesso alle directory locali, di cui ha bisogno durante l'installazione.
+
+Se vedi messaggi come
+
+```shell
+bash: change_volumes_owner.sh: No such file or directory
+```
+
+quando usi `npm run docker:init` questa è molto probabilmente la causa.
\ No newline at end of file
diff --git a/docs/i18n/italian/how-to-work-on-coding-challenges.md b/docs/i18n/italian/how-to-work-on-coding-challenges.md
new file mode 100644
index 0000000000..0047b8c0c3
--- /dev/null
+++ b/docs/i18n/italian/how-to-work-on-coding-challenges.md
@@ -0,0 +1,491 @@
+# Come lavorare sulle sfide di programmazione
+
+Il nostro obiettivo è quello di sviluppare un'esperienza di apprendimento interattiva divertente e chiara.
+
+Progettare le sfide di programmazione interattiva è difficile. Sarebbe molto più facile scrivere una spiegazione lunga o creare un video tutorial. Ma per il nostro curriculum di base, ci atteniamo a ciò che funziona meglio per la maggior parte delle persone - un'esperienza completamente interattiva, come il videogioco.
+
+Vogliamo che i camper raggiungano uno stato di flusso. Vogliamo che costruiscano slancio e sfondino attraverso il nostro curriculum con il minor numero di intoppi possibile. Vogliamo che entrino nei progetti con fiducia e che si espongano ampiamente ai concetti di programmazione.
+
+Nota che per la versione 7.0 del curriculum freeCodeCamp, ci stiamo muovendo verso [un modello interamente orientato al progetto con molta più ripetizione](https://www.freecodecamp.org/news/python-curriculum-is-live/).
+
+La creazione di queste sfide richiede un'immensa creatività e attenzione ai dettagli. C'è un sacco di aiuto disponibile. Avrai il supporto di un intero team di collaboratori a cui puoi rimbalzare le idee e mostrare le tue sfide.
+
+E come sempre, poni liberamente le tue domande [nella categoria 'Contributors' sul nostro forum](https://forum.freecodecamp.org/c/contributors) o [nella chat room per i contributori](https://chat.freecodecamp.org/channel/contributors).
+
+Con il tuo aiuto possiamo creare un curriculum interattivo di programmazione che aiuterà milioni di persone a imparare a programmare per gli anni a venire.
+
+Il contenuto di ogni sfida è immagazzinato nel suo file markdown. Questo file markdown viene successivamente convertito in HTML utilizzando i nostri strumenti per creare pagine web interattive.
+
+Puoi trovare tutto il contenuto del curriculum di freeCodeCamp nella directory [`/curriculum/challenges`](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges).
+
+## Imposta lo strumento per il curriculum
+
+Prima di lavorare sul curriculum, è necessario impostare alcuni strumenti per aiutarti a testare le modifiche. È possibile utilizzare qualsiasi opzione delle seguenti:
+
+- È possibile [impostare freeCodeCamp localmente](how-to-setup-freecodecamp-locally.md). Questo è **altamente raccomandato** per contributi regolari/ripetuti. Questa configurazione ti permette di lavorare e testare le modifiche.
+- Usa Gitpod, un ambiente di sviluppo online gratuito. Facendo clic sul pulsante qui sotto si avvierà un ambiente di sviluppo ready-to-code per freeCodeCamp nel tuo browser. Ci vogliono solo pochi minuti.
+
+ [](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
+
+- Modifica i file sull'interfaccia di GitHub facendo clic sull'icona della matita per il file corrispondente. Anche se questo è il modo più veloce, **non è raccomandato**, perché non sarai in grado di testare le modifiche su GitHub. Se i nostri manutentori concluderanno che i cambiamenti che hai fatto devono essere testati localmente dovrai seguire i metodi illustrati sopra.
+
+### Come lavorare sui progetti di pratica
+
+I progetti di pratica hanno degli strumenti addizionali per aiutare a creare i nuovi progetti e gli step. Per saperne di più, leggi [questa documentazione](how-to-work-on-practice-projects.md)
+
+## Template delle sfide
+
+````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--
+
+Testo di itroduzione alla sfida, in markdown
+
+# --hints--
+
+I test da eseguire sul codice scritto dall'utente, in coppie di testo markdown e blocco di codice col codice del test.
+
+```js
+Codice per test uno
+```
+
+Altre istruzioni in sintassi markdown
+
+```js
+Altro codice
+```
+
+# --seed--
+
+## --before-user-code--
+
+```lang
+Codice eseguito prima del codice dell'utente.
+```
+
+## --after-user-code--
+
+```lang
+Codice eseguito dopo il codice dell'utente, ma prima dei test
+```
+
+## --seed-contents--
+
+Codice di partenza da far apparire nell'editor. Questa sezione deve contenere solo codice in backtick, come il seguente:
+
+```html
+
+ Hello world!
+
+```
+
+```css
+body {
+ margin: 0;
+ background-color: #3a3240;
+}
+
+.main-text {
+ color: #aea8d3;
+}
+```
+
+```js
+console.log('freeCodeCamp is awesome!');
+```
+
+# --solutions--
+
+Le soluzioni sono usate dai test CI per assicurarsi che i cambiamenti alla sezione hints facciano eseguire i test correttamente
+
+```js
+// prima soluzione - il linguaggio deve combaciare con il seed.
+```
+
+---
+
+```js
+// seconda soluzione - quindi se il seed è scritto in HTML...
+```
+
+---
+
+```js
+// terza soluzione ecc. - La tua soluzione deve essere in HTML.
+```
+
+# --question--
+
+Questi campi sono usati per le domande a scelta multipla delle sfide di Python.
+
+## --text--
+
+Il testo della domanda va qui.
+
+## --answers--
+
+Risposa 1
+
+---
+
+Risposta 2
+
+---
+
+Altre risposte
+
+## --video-solution--
+
+Il numero della risposta corretta va qui.
+````
+
+> [!NOTE]
+>
+> 1. Nella sezione sopra, esempi di `lang` sono:
+>
+> - `html` - HTML/CSS
+> - `js` - JavaScript
+> - `jsx` - JSX
+
+## Numerare le sfide
+
+Ogni sfida ha bisogno di un `id`. Se non ne specifichi uno, MongoDB creerà un nuovo id casuale salvando i dati; ma non vogliamo che questo accada, visto che vogliamo che gli id delle sfide siano consistenti su tutti i diversi ambienti (staging, production, diversi sviluppatori, ecc.).
+
+Per generarne un nuovo in una shell (assumendo che MongoDB sia eseguito separatamente):
+
+1. Esegui il comando `mongo`.
+2. Esegui il comando `ObjectId()`.
+
+Per esempio:
+
+```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")
+````
+
+Il risultato è un nuovo id, per esempio sopra `5a474d78df58bafeb3535d34`.
+
+Una volta che hai il tuo id, mettilo nel file markdown nel campo `id` in cima, per esempio
+
+```yml
+---
+id: 5a474d78df58bafeb3535d34
+title: Challenge Title
+```
+
+## Dare un nome alle sfide
+
+Dare un nome alle cose è difficile. Lo abbiamo reso più semplice dando dei limiti.
+
+Tutti i titoli delle sfide devono essere espliciti e seguire questo schema:
+
+\[verbo\]\[complemento oggetto\]
+
+Ecco alcuni esempi di nomi di sfide:
+
+- Usare la notazione in senso orario per specificare il padding di un elemento
+- Condensare array usando .reduce
+- Usare la notazione a parentesi per trovare il primo carattere in una stringa
+
+## Istruzioni e descrizione di una sfida
+
+Le frasi dovrebbero essere chiare e concise con minimo utilizzo di linguaggio tecnico. Se il linguaggio tecnico è usato, deve essere subito seguito da una definizione in linguaggio comune.
+
+I paragrafi devono essere corti (1-4 frasi circa). È più probabile che vengano lette alcune frasi corte invece di un muro di testo.
+
+Il testo della sfida dovrebbe usare la seconda persona ("tu") per aiutare ad avere un tono colloquiale. In questo modo il testo e le istruzioni sembrano parlare direttamente al camper che lavora sulle sfide. Cerca di evitare la prima persona ("io", "noi", "facciamo").
+
+Non usare link a siti esterni. Questi interrompono il flusso. I camper non dovrebbero mai cercare qualcosa su Google durante queste sfide. Se ci sono risorse di cui pensi che il camper possa beneficiare, aggiungile all'articolo della sfida nella guida.
+
+Puoi aggiugere diagrammi se necessario.
+
+Non usare emoji o emoticon nelle sfide. freeCodeCamp ha una comunità globale, e il significato culturare di una emoji o emoticon può essere differente nelle varie parti del mondo. In più, le emoji possono avere un aspetto diverso su diversi sistemi.
+
+I nomi propri dovrebbero usare le maiuscole correttamente quando possibile. Qui sotto trovi una lista di parole come dovrebbero apparire nelle sfide.
+
+- JavaScript (lettere maiuscole in "J" e "S" e senza abbreviazioni)
+- Node.js
+- Anche se a volte inaccurate, le forme senza trattino di "back end" e "front end" dovrebbero essere usate, poiché sono le forme più comuni.
+
+### La regola dei due minuti
+
+Ogni sfida dovrebbe essere risolvibile entro 120 secondi da un nativo inglese che ha completato tutte le sfide precedenti. Questo include l'ammontare di tempo necessario a leggere le istruzioni, comprendere il codice di partenza, scrivere il loro codice e avere tutti i test superati.
+
+Se servono più di due minuti a completare la sfida hai due possibilità:
+
+- Semplificare la sfida, o
+- Dividere la sfida in due sfide.
+
+La regola dei due minuti obbliga te, designer della sfida, a rendere le tue istruzioni concise, il tuo codice seed chiaro, e i tuoi test diretti.
+
+Teniamo traccia di quanto tempo serve ai camper per risolvere le sfide e usiamo questa informazione per identificare sfide che devono essere semplificate o divise.
+
+### Modularità
+
+Ogni sfida dovrebbe insegnare esattamente un concetto, e quel concetto dovrebbe apparire nel titolo della sfida.
+
+Possiamo rinforzare concetti introdotti in precedenza tramite ripetizione e variazioni, per esempio introducendo gli elementi h1 in una sfida e gli elementi h3 alcune sfide più tardi.
+
+Il nostro obbiettivo è di avere migliaia di sfide da due minuti. Queste possono scorrere insieme e rinforzare concetti già introdotti in precedenza.
+
+### Formattare il testo delle sfide
+
+Ecco le linee guidee di formattazione specifiche per il testo delle sfide e degli esempi:
+
+- Le parole chiave del linguaggio vanno in `` \` `` backtick. Per esempio i nomi dei tag HTML o i nomi delle proprietà CSS.
+- Riferimenti a parti di codice (come nomi di funzioni, metodi o variabili) dovrebbero essere in `` \` `` backtick. Vedi gli esempi seguenti:
+
+```md
+Usa `parseInt` per convertire la variabile `realNumber` a un numero intero.
+```
+
+- I riferimenti a nomi di file o percorsi di cartelle (come `package.json`, `src/components`) dovrebbero essere in `` \` `` backtick.
+- I blocchi di codice multi-riga **devono essere preceduti da una riga vuota**. La riga successiva deve iniziare con tre backticks seguiti immediatamente da uno dei [linguaggi supportati](https://prismjs.com/#supported-languages). Per completare il blocco di codice devi iniziare una nuova riga, scrivere tre backtick e poi **un'altra riga vuota**. Vedi l'esempio seguente:
+- Gli spazi bianchi hanno significato in Markdown, raccomandiamo di renderli visibili nel tuo editor.
+
+**Nota:** Se devi usare un esempio di codice in YAML, usa `yaml` invece di `yml` per il linguaggio a fianco dei tre backtick.
+
+Il seguente è un esempio di codice:
+
+````md
+```{language}
+
+[IL TUO CODICE QUI]
+
+````
+````
+
+- Informazioni aggiuntive nella forma di una nota dovrebbero essere circondate da linee vuote, e formattate così: `**Note:** Resto del testo della nota...`
+- Se è necessaria più di una nota, elencale in frasi separate usando il formato: `**Notes:** Testo della prima nota. Testo della seconda nota.`
+- Usa virgolette singole dove necessario
+
+**Note:** L'equivalente _Markdown_ dovrebbe essere usato invece di tag _HTML_.
+
+## Scrivere i test
+
+Le sfide dovrebbero avere il numero minimo di test per verificare che un camper abbia compreso il concetto della sfida.
+
+Il nostro obbiettivo è comunicare il singolo punto che la sfida sta cercando di insegnare, e testare che abbiano capito il punto.
+
+I test delle sfide possono fare uso delle librerie di asserzioni Node.js e Chai.js. E, se necessario, il codice generato dall'utente può essere acceduto dalla variabile `code`.
+
+## Formattare codice di seed
+
+Ecco linee guida specifiche di formattazione per il codice seed delle sfide:
+
+- Usa due spazi per indentare
+- Le istruzioni JavaScript finiscono con un punto e virgola
+- Usa virgolette doppie dove possibile
+
+### Commenti del codice seed
+
+Abbiamo un [dizionario dei commenti](/curriculum/dictionaries/english/comments.js) che contiene gli unici commenti che possono essere usati nel codice seed. I commenti devono essere usati esattamente in quel modo, ricopiando maiuscole, minuscole, e spazi. Il dizionario dei commenti non deve essere allargato senza previa discussione con il team di sviluppo.
+
+I commenti dovrebbero avere uno spazio tra il carattere del commento e il testo del commento. In generale, i commenti dovrebbero essere usati raramente. Considera sempre la possibilità di riscrivere la descrizione o le istruzioni di una sfida se ti permetterebbe di evitare di usare un commento nel codice seed.
+
+Esempio di un commento a linea singola in JavaScript:
+
+```js
+// Only change code below this line
+````
+
+Esempio di un commento CSS valido:
+
+```css
+/* Only change code above this line */
+```
+
+Se la sfida ha un unico punto dove il codice ha bisogno di cambiamenti, per favore usa i commenti nel seguente esempio per istruire l'utente su dove dovrebbe fare i cambiamenti.
+
+```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;
+```
+
+Se la sfida ha diversi punti dove l'utente deve fare cambiamenti al codice (come in una sfida React)
+
+```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}
+
+ );
+ }
+}
+```
+
+### Traduzione dei commenti nel codice seed
+
+Ci sono directory separate per ogni lingua. La [versione inglese della directory dei commenti](/curriculum/dictionaries/english/comments.js) è la base per le traduzioni trovate nelle corrispondenti versioni non-inglesi del file. La versione non-inglese della directory dei commenti cinese si trova in `/curriculum/dictionaries/chinese/comments.js`. Ogni directory consiste di un array di oggetti con una proprietà `id` unica e una proprietà `text` che contiene il testo del commento. Solo `text` dovrebbe essere modificato per includere la traduzione del corrispondente commento inglese.
+
+Alcuni commenti potrebbero contenere delle parole o frasi che non devono essere tradotte. Per esempio, nomi di variabili o nomi propri di librerie come "React" non dovrebbero essere tradotti. Vedi il commento seguente come esempio. La parola `myGlobal` non deve essere tradotta.
+
+```text
+Declare the myGlobal variable below this line
+```
+
+> [!NOTE]
+>
+> Stiamo lavorando su un'integrazione per rendere possibile lavorare su i18n per il dizionario dei commenti.
+
+## Suggerimenti e soluzioni
+
+Ogni sfida ha un pulsante `Get a Hint` (Ottieni un suggerimento), cosicché un utente possa avere accesso a suggerimenti e soluzioni che sono stati creati per la sfida. I suggerimenti e le soluzioni del curriculum si trovano nei topic [del nostro forum](https://forum.freecodecamp.org/c/guide) nella categoria `Guide`.
+
+Se trovi un problema con i suggerimenti e le soluzioni delle sfide puoi inviare i tuoi suggerimenti aprendo un topic nella [categoria contributors](https://forum.freecodecamp.org/c/contributors) sul forum. Moderatori e utenti con un livello di fiducia 3 rivedranno i tuoi commenti e decideranno se includere o meno i cambiamenti nel topic corrispondente.
+
+### Aggiungere nuovi topic per i suggerimenti e le soluzioni delle sfide
+
+Segui i seguenti step quando crei un nuovo topic per le soluzioni e i suggerimenti di una sfida.
+
+1. Inizia seguendo gli stessi passaggi per creare un nuovo argomento, ma rivedi il successivo per creare il titolo.
+2. Il titolo dell'argomento dovrebbe iniziare con `freeCodeCamp Challenge Guide:` concatenato con il titolo effettivo della sfida del curriculum. Ad esempio, se la sfida è chiamata "`Chunky Monkey`", il titolo dell'argomento sarebbe "`freeCodeCamp Challenge Guide: Chunky Monkey`".
+3. `camperbot` dovrebbe essere il proprietario di questi argomenti/post, quindi dovrai chiedere a un amministratore di cambiare la proprietà del post principale a `camperbot`.
+4. Una volta creato il nuovo argomento, verrà creato un id del topic nel forum. Esso si trova alla fine dell'URL dell'argomento del forum. Questo id deve essere aggiunto alla parte frontale del file di sfida del curriculum tramite il normale processo di pull request per il pulsante `Ottieni un suggerimento` in modo da collegarlo all'argomento.
+
+### Linee guida per il contenuto dei topic dei suggerimenti e delle soluzioni
+
+Quando proponi una soluzione da aggiungere al topic relativo a una sfida, devi includere tutto il codice. Questo include sia il codice seed originale sia i cambiamenti necessari per superare i test. Dovresti usare il seguente template per creare nuovi topic per suggerimenti e soluzioni:
+
+````md
+# [Qui il nome della sfida]
+
+---
+
+## Spiegazione del problema
+
+Qui un riassunto di cosa deve essere fatto senza includere semplicemente le istruzioni e la descrizione della sfida. [This is an optional section]
+
+#### Relevant Links
+
+- [Link Text](link_url_goes_here)
+- [Link Text](link_url_goes_here)
+
+---
+
+## Hints
+
+### Hint 1
+
+[Suggerimento 1 va qui]
+
+### Hint 2
+
+[Suggerimento va qui]
+
+---
+
+## Solutions
+
+Solution 1 (Click to Show/Hide)
+
+```js
+function myFunc() {
+ console.log('Hello World!');
+}
+````
+
+#### Spiegazione Del Codice
+
+- La spiegazione del codice va qui
+- La spiegazione del codice va qui
+
+#### Collegamenti utili
+
+- [Testo del collegamento](link_url_goes_here)
+- [Testo Collegamento](link_url_goes_here)
+
+
+````
+
+## Testare le sfide
+
+Prima di [creare una pull request](how-to-open-a-pull-request.md), devi verificare che i cambiamenti che hai fatto non causino inavvertitamente problemi con la sfida.
+
+1. Per testare tutte le sfide esegui il comando seguente nella directory root
+
+````
+npm run test:curriculum
+```
+
+2. Puoi anche testare un blocco o un superblocco di sfide con questi comandi
+
+```
+npm run test:curriculum --block='Basic HTML and HTML5'
+```
+
+```
+npm run test:curriculum --superblock=responsive-web-design
+```
+
+Puoi anche testare una sfida singola con i seguenti step:
+
+1. Spostati nella cartella `curriculum`:
+
+ ```
+ cd curriculum
+ ```
+
+2. Esegui i seguenti comandi per ogni singolo file in cui hai fatto cambiamenti (rimpiazziando `challenge-title-goes-here` con il titolo intero della sfida):
+
+ ```
+ npm run test -- -g challenge-title-goes-here ```
+
+Una volta che avrai verificato che ogni sfida su cui hai lavorato passi i test, [per favore crea una pull request](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/docs/how-to-open-a-pull-request.md).
+
+> [!TIP] Puoi impostare la variabile d'ambiente `LOCALE` nel file `.env` alla lingua usata nelle sfide che devi testare.
+>
+> I valori attualmente accettati sono `english` (inglese) e `chinese` (cinese), con `english` come valore di default.
+
+### Link utili
+
+Creare e modificare sfide:
+
+1. [Tipi di sfide](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/client/utils/challengeTypes.js#L1-L13) - cosa significa il valore numerico del tipo della sfida (challenge type) (enum).
+
+2. [Contribuire a FreeCodeCamp - Scrivere Test per le sfide ES6](https://www.youtube.com/watch?v=iOdD84OSfAE#t=2h49m55s) - un video che segue [Ethan Arrowood](https://twitter.com/ArrowoodTech) in quanto contributore della vecchia versione del curriculum.
diff --git a/docs/i18n/italian/how-to-work-on-localized-client-webapp.md b/docs/i18n/italian/how-to-work-on-localized-client-webapp.md
new file mode 100644
index 0000000000..8425bb99d2
--- /dev/null
+++ b/docs/i18n/italian/how-to-work-on-localized-client-webapp.md
@@ -0,0 +1,267 @@
+# Come lavorare su webapp client localizzate
+
+La app client basata su react che alimenta la nostra piattaforma è costruita usando Gatsby. È tradotta in varie lingue internazionali usando [react-i18next](https://react.i18next.com/) e [i18next](https://www.i18next.com/).
+
+Puoi scoprire di più su come configurare l'applicazione client localmente per lo sviluppo seguendo [la nostra guida alla configurazione in locale](/how-to-setup-freecodecamp-locally). Di default, l'applicazione è disponibile solo in inglese.
+
+Una volta che avrai configurato il progetto localmente dovresti essere in grado di seguire questa documentazione per eseguire il client nella lingua di tua scelta dall'elenco delle lingue disponibili.
+
+Questo può essere utile quando stai lavorando su una caratteristica che riguarda specificatamente qualcosa che coinvolge la localizzazione e ti richiede ad esempio l'etichetta di un bottone in una lingua diversa.
+
+> [!TIP] Non hai bisogno di seguire questo documento per tradurre il curriculum di freeCodeCamp o per contribuire alla documentazione. Invece, leggi [questa guida](./how-to-translate-files.md).
+
+Andiamo a vedere come funzionano il framework e gli strumenti.
+
+## Struttura dei file
+
+La maggior parte dei file per tradurre la piattaforma si trovano nella cartella [`client/i18n`](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/client/i18n). Ogni lingua ha una directory al suo interno che contiene file JSON con le traduzioni.
+
+```console
+ config/i18n
+ └── all-langs.js
+ ...
+ client/i18n
+ ├── configForTests.js
+ ├── config.js
+ ├── locales
+ │ ├── chinese
+ │ │ ├── intro.json
+ │ │ ├── links.json
+ │ │ ├── meta-tags.json
+ │ │ ├── motivation.json
+ │ │ ├── translations.json
+ │ │ └── trending.json
+ ... ...
+ │ ├── dothraki
+ │ │ ├── intro.json
+ │ │ ├── links.json
+ │ │ ├── meta-tags.json
+ │ │ ├── motivation.json
+ │ │ ├── translations.json
+ │ │ └── trending.json
+ ... ...
+ │ ├── english
+ │ │ ├── intro.json
+ │ │ ├── links.json
+ │ │ ├── meta-tags.json
+ │ │ ├── motivation.json
+ │ │ ├── translations.json
+ │ │ └── trending.json
+ │ └── espanol
+ │ ├── intro.json
+ │ ├── links.json
+ │ ├── meta-tags.json
+ │ ├── motivation.json
+ │ ├── translations.json
+ │ └── trending.json
+ ├── locales.test.js
+ ├── schema-validation.js
+ └── validate-keys.js
+```
+
+Alcuni di questi file sono tradotti sulla nostra piattaforma di traduzione (Crowdin), altri no.
+
+**File tradotti con la nostra piattaforma di traduzione:**
+
+- Il file `translations.json` contiene la maggior parte del testo che compare sugli elementi dell'interfaccia utente. Le chiavi sono usate nel codice per ottenere i testo corretto per qualunque lingua sia impostata. Questo file deve avere le stesse identiche chiavi in tutte le lingue.
+
+- Il file `intro.json` contiene le coppie chiave-valore relative al testo introduttivo sulle pagine delle certificazioni.
+
+ Se vuoi aggiungere/aggiornare le traduzioni per le chiavi, per favore [leggi questa guida](/how-to-translate-files.md).
+
+**File NON tradotti con la nostra piattaforma di traduzione:**
+
+- I file `motivation.json` non devono avere per forza le stesse frasi, complimenti o lunghezze degli array. Basta che abbiano la stessa struttura JSON.
+
+- Il file `trending.json` contiene i titoli e i link ai nuovi articoli di tendenza all'interno del footer del sito.
+
+- Il file `meta-tags.json` contiene le informazioni per il meta tag del nostro sito.
+
+ I cambiamenti su questi file sono tipicamente fatti dallo staff. Se vedi qualcosa fuori dall'ordinario, ti raccomandiamo di metterti in contatto con noi sulla [chat dei contributori](https://chat.freecodecamp.org/channel/contributors).
+
+## Testare la app client in una lingua internazionale
+
+Puoi testare la app client in ogni lingua disponibile nell'[elenco delle lingue](https://github.com/freeCodeCamp/freeCodeCamp/blob/6b4a6a02568b809fc216ea8566ff5df446d1da4e/config/i18n/all-langs.js#L5).
+
+```js
+ const availableLangs = {
+ client: ['english', 'espanol', 'chinese'],
+ ...
+ };
+```
+
+Se stai testando una nuova lingua, crea una cartella con il nome della lingua come titolo accanto alle altre lingue e copia i file JSON da un'altra lingua alla tua cartella.
+
+Aggiungi la lingua all'array `client` come visto sopra nel file [`config/i18n/all-langs.js`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/config/i18n/all-langs.js).
+
+Successivamente, segui le istruzioni nei commenti nello stesso file per aggiungere/aggiornare il resto delle variabili secondo necessità.
+
+Infine, imposta la variabile `CLIENT_LOCALE` nel tuo file `.env` alla lingua che vuoi sviluppare e hai finito.
+
+## Come strutturare i componenti
+
+Se stai lavorando su una caratteristica o un bug per la client web app, ad esempio aggiungendo nuovi elementi di interfaccia utente sulla pagina delle impostazioni, dovresti seguire le linee guida qui sotto. Ti aiuteranno a preparare i componenti per la localizzazione in tutte le lingue supportate.
+
+### Componenti funzionali
+
+```js
+import { useTranslation } from 'react-i18next';
+
+// nel metodo render:
+const { t } = useTranslation();
+
+// chiama la funzione "t" con una chiave dal file JSON:
+{t('key')}
; // altri dettagli sotto
+```
+
+### Componenti classe
+
+```js
+import { withTranslation } from 'react-i18next';
+
+// withTranslation aggiunge la funzione "t" alle props:
+const { t } = this.props;
+
+// chiama la funzione "t" con una chiave dal file JSON:
+{t('key')}
// più dettagli sotto
+
+// esporta senza redux:
+export default withTranslation()(Component);
+
+// o con redux:
+export default connect(...)(withTranslation()(Component));
+```
+
+## Tradurre usando la funzione "t"
+
+### Traduzione di base
+
+```js
+// nel componente:
+{t('p1')}
+
+// nel file JSON:
+{
+ "p1": "My paragraph"
+}
+
+// output:
+My paragraph
+```
+
+### Con dati dinamici
+
+```js
+// nel componente:
+const username = 'moT';
+
+{t('welcome', { username: username })}
+
+// nel file JSON:
+{
+ "welcome": "Welcome {{username}}"
+}
+
+// output:
+Welcome moT
+```
+
+L'esempio qui sopra passa alla funzione `t` un oggetto con una variabile `username`. La variabile verrà usata nel valore JSON al posto di `{{username}}`.
+
+## Traduci con il componente `Trans`
+
+La regola generale è usare la funzione "t" quando puoi. Ma c'è un componente `Trans` per quando questo non basta, solitamente quando hai elementi incorporati nel testo. Puoi usare il componente `Trans` con ogni tipo di componente react.
+
+### Elementi di base annidati
+
+```js
+// nel componente:
+import { Trans } from 'react-i18next'
+
+
+ fcc.greeting
+
+
+// nel file JSON:
+{
+ "fcc": {
+ "greeting": "Welcome to freeCodeCamp"
+ }
+}
+
+// output:
+Welcome to freeCodeCamp
+```
+
+Puoi inserire la chiave all'interno del tag del componente come nell'esempio qui sopra, se il testo contiene tag "semplici" senza attributi. `br`, `strong`, `i`, e `p` sono quelli predefiniti, ma la lista può essere ampliata nel file i18n config.
+
+### Elementi complessi annidati
+
+Altre volte, vorrai avere un certo testo all'interno di un altro elemento, un buon esempio è il tag anchor:
+
+```js
+// nel componente:
+
+
+ placeholder
+
+
+
+// nel file JSON:
+{
+ "check-forum": "Check out <0>our forum0>."
+}
+
+// output:
+Check out our forum
+```
+
+Nell'esempio sopra, la chiave è impostata negli attributi del componente `Trans`. I tag `<0>` e `0>` nel JSON rappresentano il primo figlio del componente, in questo caso l'elemento anchor. Se ci fossero più elementi figli, verrebbero contati a partire da lì, usando la stessa sintassi. Puoi trovare i figli di un componente negli strumenti per sviluppatori react ispezionandolo. `placeholder` è lì semplicemente perché il linter protesterebbe per un elemento `` lasciato vuoto.
+
+### Con una variabile
+
+```js
+// nel componente:
+const email = 'team@freecodecamp.org';
+
+
+
+
+ {{ email }}
+
+
+
+
+// nel file JSON:
+{
+ "fcc": {
+ "email": "Send us an email at: <0>{{email}}0>"
+ }
+}
+
+// output:
+Send us an email at: team@freecodecamp.org
+```
+
+Nell'esempio sopra, la chiave e una variabile sono impostate negli attributi del componente `Trans`. Anche `{{ email }}` deve essere da qualche parte nel componente `Trans`, non importa dove.
+
+## Cambiare il testo
+
+Per cambiare il testo sul lato client, vai al relativo file `.json`, trova la chiave che viene usata nel componente React e cambiane il valore con il nuovo testo che vuoi. Dovresti cercare quella chiave nel codice, per assicurarti che non venga usata da qualche altra parte. O, se lo è, che il cambiamento abbia senso ovunque.
+
+## Aggiungere testo
+
+Se il testo che vuoi aggiungere al client esiste nel relativo file `.json`, usa la chiave esistente. Altrimenti, crea un'altra chiave.
+
+Il file in inglese è la "fonte della verità" per tutti i file `.json` che condividono lo stesso nome. Se hai bisogno di aggiungere una nuova chiave, aggiungila lì. Dopodiché, aggiungi la chiave a **tutti** i file `translations.json`.
+
+> [!NOTE] Usa del testo in inglese per tutte le lingue se il file è tradotto tramite Crowdin. Se non lo fai, i test falliranno.
+
+Sarebbe utile anche tenere tutte le chiavi nello stesso ordine in tutti i file. Inoltre, prova a mettere tutta la punteggiatura, spaziatura, virgolette, etc nei file JSON e non nei componenti o nei file del server.
+
+> [!NOTE] Il trattino basso (`_`) è un carattere riservato alle chiavi nei file per il lato client. Vedi [la documentazione](https://www.i18next.com/translation-function/plurals) per il suo utilizzo.
+
+## Documentazione utile
+
+- [Documentazione react-i18next ](https://react.i18next.com/latest/usetranslation-hook)
+- [Documentazione i18next](https://www.i18next.com/translation-function/essentials)
diff --git a/docs/i18n/italian/how-to-work-on-practice-projects.md b/docs/i18n/italian/how-to-work-on-practice-projects.md
new file mode 100644
index 0000000000..ba5fe6b043
--- /dev/null
+++ b/docs/i18n/italian/how-to-work-on-practice-projects.md
@@ -0,0 +1,123 @@
+# Come lavorare sui progetti di pratica
+
+La cartella `tools/challenge-helper-scripts` contiene strumenti per aiutare a facilitare la creazione e il mantenimento del curriculum basato su progetti di freeCodeCamp.
+
+## Creare un nuovo progetto
+
+Esegui `npm run create-project`. Questo apre un'interfaccia utente a linea di comando che ti guida attraverso il processo. Una volta finito, dovrebbe esserci una nuova sfida nel curriculum inglese che puoi usare come primo passo del progetto. Ad esempio, se hai creato un progetto chiamato `test-project` nella certificazione Web Design Responsivo, sarebbe in `curriculum/challenges/english/01-responsive-web-design/test-project`.
+
+Se vuoi creare nuovi passi, i seguenti strumenti semplificano quel processo.
+
+## create-next-step
+
+Uno script eseguito una sola volta che aggiungerà automaticamente il prossimo passo basandosi sull'ultimo numerato come `part-xxx.md`, dove `xxx` rappresenta il numero a 3 cifre dell'ultimo passo. Il codice seed della sfida userà il codice seed di quella precedente, rimuovendo i marcatori delle regioni editabili (MRE).
+
+**Nota:** Questo script esegue anche [reorder-steps](how-to-work-on-practice-projects#reorder-steps).
+
+### Come eseguire lo script:
+
+1. Vai alla directory del progetto.
+2. Esegui il seguente comando npm:
+
+```bash
+npm run create-next-step
+```
+
+## create-empty-steps
+
+Uno script eseguito una sola volta che aggiunge automaticamente un determinato numero di passi a partire da un passo specifico. Il codice seed della sfida per tutti i passi creati sarà vuoto.
+
+**Nota:** Questo script esegue anche [reorder-steps](how-to-work-on-practice-projects#reorder-steps).
+
+### Come eseguire lo script:
+
+1. Vai alla directory del progetto.
+2. Esegui il seguente comando npm:
+
+```bash
+npm run create-empty-steps start=X num=Y # dove X è il numero del passo da cui iniziare e Y è il numero di passi da creare.
+```
+
+## create-step-between
+
+Uno script eseguito una sola volta che aggiunge automaticamente un passo in mezzo a due passi consecutivi già esistenti. Il codice seed della sfida userà il codice seed della sfida al passo di partenza già esistente, rimuovendo i marcatori delle regioni editabili (MRE).
+
+**Nota:** Questo script esegue anche [reorder-steps](how-to-work-on-practice-projects#reorder-steps).
+
+### Come eseguire lo script:
+
+1. Vai alla directory del progetto.
+2. Esegui il seguente comando npm:
+
+```bash
+npm run create-step-between start=X # dove X è il passo iniziale di partenza
+```
+
+## delete-step
+
+Uno script eseguito una sola volta che cancella un passo esistente e poi riordina i passi rimanenti nella cartella del progetto e che aggiorna l'array della proprietà `challengeOrder` nel `meta.json` del progetto secondo il nuovo ordine dei passi.
+
+### Come eseguire lo script
+
+1. Vai alla directory del progetto.
+2. Esegui il seguente comando npm:
+
+```bash
+npm run delete-step num=x # dove x è il numero dello step da eliminare.
+```
+
+## reorder-steps
+
+Uno script eseguito una sola volta che riordina automaticamente i file dei passi nel markdown del progetto basandosi sui nomi dei file. Aggiorna anche l'array della proprietà `challengeOrder` nel `meta.json` del progetto secondo il nuovo ordine dei passi.
+
+### Esempi di funzionamento
+
+Diciamo che inizi con la seguente struttura:
+
+```bash
+part-1.md
+part-2.md
+part-3.md
+part-4.md
+part-5.md
+part-6.md
+```
+
+A un certo punto decidi che hai bisogno di eliminare `part-2.md`, perché quel passo non è più necessario. Inoltre, decidi di dividere `part-4.md` in tre passi invece di uno.
+
+Per ottenere questa ristrutturazione, avresti bisogno di eliminare `part-2.md` e poi aggiungere un `part-4a.md` e un `part-5b.md`. La nuova struttura della cartella assomiglierà alla seguente:
+
+```bash
+part-001.md
+part-003.md
+part-004.md
+part-004a.md
+part-004b.md
+part-005.md
+part-006.md
+```
+
+Adesso serve che i nomi dei file vadano da `part-1.md` a `part-7.md`, poiché ne hai rimosso uno ma ne hai aggiunti due, con una differenza netta di un file. Inoltre, la presentazione di ogni file sotto un passo rimosso o aggiunto dovrà essere modificata rendendo il valore della chiave `title` uguale al nuovo numero del passo. Ad esempio, dopo aver rinominato `part-3.md` in `part-2.md`, dovrai cambiare il titolo di `part-2.md` da `Part 03` a `Part 02`.
+
+Vedi qui sotto per gli effettivi cambiamenti necessari alla cartella del progetto:
+
+```bash
+part-001.md
+part-003.md rinominato in part-002.md e titolo cambiato in "Part 2"
+part-004.md rinominato in part-003.md e titolo cambiato in "Part 3"
+part-004a.md rinominato in part-004.md e titolo cambiato in "Part 4"
+part-004b.md rinominato in part-005.md e titolo cambiato in "Part 5"
+part-005.md rinominato in part-006.md e titolo cambiato in "Part 6"
+part-006.md rinominato in part-007.md e titolo cambiato in "Part 7"
+```
+
+Insieme ai cambi qui sopra, la chiave `challengeOrder` nel file `meta.json` del progetto deve riflettere il nuovo ordine dei passi. Questo è necessario perché ogni passo sotto la cancellazione e/o l'aggiunta di un passo cambia il `title` associato ad ognuno degli `id` delle sfide ai passi interessati.
+
+### Come eseguire lo script
+
+1. Vai alla directory del progetto.
+2. Esegui il seguente comando npm:
+
+```bash
+npm run reorder-steps
+```
diff --git a/docs/i18n/italian/how-to-work-on-the-docs-theme.md b/docs/i18n/italian/how-to-work-on-the-docs-theme.md
new file mode 100644
index 0000000000..58364d1c16
--- /dev/null
+++ b/docs/i18n/italian/how-to-work-on-the-docs-theme.md
@@ -0,0 +1,54 @@
+# Come lavorare sul tema dei documenti
+
+> [!NOTE] Un rapido promemoria per ricordarti che non è necessario configurare nulla per lavorare sul contenuto del sito di documentazione.
+>
+> Per lavorare sulle linee guida per i contributori, puoi modificare o aggiungere file nella cartella `docs` [disponibile qui](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/docs). Quando le modifiche verranno unite, saranno rese disponibili automaticamente sul sito di documentazione.
+
+## Struttura del sito di documentazione
+
+Il sito viene generato utilizzando [`docsify`](https://docsify.js.org) e servito utilizzando le pagine di GitHub.
+
+In genere non è necessario modificare alcuna configurazione o costruire il sito localmente. Nel caso in cui tu sia interessato, ecco come funziona:
+
+- Il sorgente della homepage per questo sito è disponibile in [`docs/index.html`](index.html).
+- Serviamo questo file come SPA (Single Page Application) usando `docsify` e GitHub Pages.
+- Lo script `docsify` genera il contenuto del `file markdown` nella directory `docs` su richiesta.
+- La homepage è generata dal file [`_coverpage.md`](_coverpage.md).
+- la navigazione della barra laterale è generata da [`_sidebar.md`](_sidebar.md).
+
+## Servire localmente il sito di documentazione
+
+Clona freeCodeCamp:
+
+```console
+git clone https://github.com/freeCodeCamp/freeCodeCamp.git
+docsify serve docs
+```
+
+Installa `docsify`:
+
+```console
+npm install -g docsify
+```
+
+e servi la directory `/docs`
+
+```console
+docsify serve docs
+```
+
+In alternativa, se hai installato freeCodeCamp localmente (vedi la guida di installazione locale), impacchettiamo il CLI con gli strumenti di sviluppo in modo da poter eseguire uno qualsiasi dei comandi sottostanti dalla root del repo quando necessario:
+
+### Servire e avviare solo il sito di documentazione
+
+```console
+npm run docs:serve
+```
+
+### Servire il sito di documentazione accanto a freeCodeCamp localmente:
+
+```console
+npm run develop
+```
+
+> Il sito di documentazione dovrebbe essere disponibile su
diff --git a/docs/i18n/italian/how-to-work-on-the-news-theme.md b/docs/i18n/italian/how-to-work-on-the-news-theme.md
new file mode 100644
index 0000000000..b1e7b91c7e
--- /dev/null
+++ b/docs/i18n/italian/how-to-work-on-the-news-theme.md
@@ -0,0 +1,99 @@
+# Come lavorare sul tema delle news degli sviluppatori di freeCodeCamp.org
+
+Le notizie degli sviluppatori conosciute anche come il sito [`/news`](https://www.freecodecamp.org/news) è alimentato da [Ghost](https://ghost.org/). Usiamo un tema personalizzato per l'aspetto del sito. Il codice sorgente del tema è disponibile qui: .
+
+## Il Tema
+
+Ghost utilizza un semplice linguaggio di modellazione chiamato [Handlebars](http://handlebarsjs.com/) per i suoi temi. Il tema utilizzato su `/news` è basato sul [tema casper](https://github.com/TryGhost/Casper) predefinito.
+
+Il tema di default ha molti commenti così è abbastanza facile capire cosa sta succedendo semplicemente leggendo il codice e i commenti. Una volta che ti senti a tuo agio con il funzionamento del tutto, Ghost ha anche una completa [documentazione API per i temi](https://themes.ghost.org) che spiega ogni possibile helper Handlebars e modello.
+
+**I file principali sono:**
+
+- `default.hbs` - Il file del modello principale
+- `index.hbs` - Utilizzato per la home page
+- `post.hbs` - Utilizzato per singoli post
+- `page.hbs` - Utilizzato per singole pagine
+- `tag.hbs` - Utilizzato per archivi di tag
+- `author.hbs` - Utilizzato per archivi d'autore
+
+Uno trucco davvero pulito è che è anche possibile creare modelli una tantum personalizzati solo aggiungendo lo slug di una pagina a un file di modello. Per esempio:
+
+- `page-about.hbs` - Modello personalizzato per la pagina `/about/`
+- `tag-news.hbs` - Modello personalizzato per l'archivio `/tag/news/`
+- `author-ali.hbs` - Modello personalizzato per l'archivio `/author/ali/`
+
+## Sviluppo
+
+1. Installare Ghost localmente.
+
+ ```sh
+ npm install -g ghost-cli@latest
+ mkdir ghost-local-site
+ cd ghost-local-site
+ ```
+
+ ```sh
+ ghost install local
+ ghost start
+ ```
+
+ > Nota: Attualmente freeCodeCamp utilizza la versione Ghost `2.9.0`, quindi assicurati di usare una versione superiore.
+
+ Assicurati di eseguire i comandi `ghost` dalla directory `ghost-local-site`. Segui le istruzioni aggiuntive sulla documentazione ufficiale di [Ghost](https://docs.ghost.org) se non ha familiarità con la sua interfaccia.
+
+2. Forka e clona il repository nella directory del tuo tema (sostituendo `YOUR_USERNAME` con il tuo username di GitHub):
+
+ ```sh
+ cd content/themes/
+ git clone https://github.com/YOUR_USERNAME/news-theme.git
+ ```
+
+3. Assicurati di avere tutti i prerequisiti.
+
+ Gli stili del tema sono compilati usando Gulp/PostCSS per rispettare le future specifiche CSS. Avrai bisogno di [Node.js](https://nodejs.org/). Assicurati che la tua versione Node.js sia compatibile con `ghost`.
+
+4. Installa le dipendenze e sviluppa il tema
+
+ ```sh
+ npm ci
+ npm run develop
+ ```
+
+5. Ora puoi modificare automaticamente i file `/assets/css/`, che saranno compilati in `/assets/built/`.
+
+6. Accedi al sito di sviluppo.
+
+ a. Inserisci `http://localhost:2368/ghost/` nella barra degli indirizzi. Continua con la configurazione richiesta sulla pagina (se stai eseguendo ghost per la prima volta).
+
+ b. _(Una sola volta durante la configurazione)_ Riavvia Ghost in un terminale separato per garantire che il tema sia disponibile.
+
+ ```sh
+ cd ghost-local-site
+ ghost restart
+ ```
+
+ c. _(Una sola volta durante l'installazione)_ Una volta fatto, vai su `http://localhost:2368/ghost/#/settings/design` e scorri verso il basso. Assicurati di cliccare attiva su `freecodecamp-news-theme`.
+
+7. Zippa il codice finale e fai una pull request
+
+ Il task `zip` di Gulp impacchetta i file del tema in `dist/. ip`, che potremo poi caricare sul sito di produzione.
+
+ Quando fai una PR, assicurati di aver eseguito lo script sottostante prima di effettuare il commit del codice e di inviare una PR.
+
+ ```sh
+ npm run zip
+ ```
+## Altri riferimenti e risorse
+
+### Funzionalità PostCSS Utilizzate
+
+- Autoprefixer - Non preoccuparti di scrivere prefissi del browser di alcun tipo, è tutto fatto automaticamente con il supporto per le ultime 2 versioni principali di ogni browser.
+- Variabili - Semplici variabili CSS pure
+- [Funzione Color](https://github.com/postcss/postcss-color-function)
+
+### Icone SVG
+
+Il tema utilizza icone SVG in linea, incluse tramite dei partial di Handlebars. Puoi trovare tutte le icone all'interno di `/partials/icons`. Per usare un'icona basta includere il nome del file pertinente, ad es. Per includere l'icona SVG in `/partials/icons/rss.hbs` - usa `{{> "icons/rss"}}`.
+
+È possibile aggiungere le proprie icone SVG nello stesso modo.
diff --git a/docs/i18n/italian/index.md b/docs/i18n/italian/index.md
new file mode 100644
index 0000000000..136827e915
--- /dev/null
+++ b/docs/i18n/italian/index.md
@@ -0,0 +1,49 @@
+La comunità [freeCodeCamp.org](https://freecodecamp.org) è composta da migliaia di volontari come te. Se vuoi contribuire con il tuo tempo e le tue competenze, saremo entusiasti di darti il benvenuto a bordo.
+
+> [!NOTE] Prima di procedere, prenditi due minuti per leggere il nostro [Codice di condotta](https://www.freecodecamp.org/code-of-conduct). Lo applichiamo rigorosamente in tutta la nostra comunità in modo che contribuire a freeCodeCamp.org sia un'esperienza sicura e inclusiva per tutti.
+
+Happy contributing.
+
+Sei invitato a:
+
+- Creare, aggiornare e correggere bug nel nostro [curriculum](#curriculum).
+- Aiutarci a correggere i bug nella [piattaforma di apprendimento](#learning-platform) di freeCodeCamp.org.
+- [Aiutarci a tradurre](#translations) freeCodeCamp.org in tutte le lingue del mondo.
+
+Rispondiamo alle domande più comuni su come contribuire [nelle nostre FAQ per i contributori](/FAQ.md).
+
+## Curriculum
+
+Il nostro curriculum è curato dalla comunità globale freeCodeCamp. In questo modo, siamo in grado di incorporare conoscenze esperte da volontari come te.
+
+Puoi aiutare ad espandere e migliorare il curriculum. Puoi anche aggiornare le user story del progetto per spiegare meglio i concetti. E puoi migliorare i nostri test automatici in modo da poter testare più accuratamente il codice degli studenti.
+
+**Se sei interessato a migliorare il nostro curriculum, ecco [come contribuire al curriculum](how-to-work-on-coding-challenges.md).**
+
+## Traduzioni
+
+Stiamo traducendo freeCodeCamp.org nelle maggiori lingue del mondo. Alcune delle certificazioni sono già attive in [Cinese (中文)](https://chinese.freecodecamp.org/learn) e [Spagnolo (Español)](https://www.freecodecamp.org/espanol/learn/). Ti raccomandiamo di leggere [questo annuncio](https://www.freecodecamp.org/news/world-language-translation-effort) e di condividerlo con i tuoi amici per coinvolgerli in questa iniziativa.
+
+**Se sei interessato a tradurre qui trovi [ come tradurre le risorse di freeCodeCamp](how-to-translate-files.md).**
+
+## Piattaforma di apprendimento
+
+la nostra piattaforma di apprendimento è basata su un moderno stack JavaScript. Ha vari componenti, strumenti e librerie. Queste includono Node.js, MongoDB, OAuth 2.0, React, Gatsby, Webpack, ecc.
+
+In linea di massima utilizziamo
+
+- un server API basato su Node.js
+- un insieme di applicazioni client basate su React
+- e gli script di prova per valutare i progetti di curriculum presentati dai camper.
+
+Se vuoi contribuire attivamente alla piattaforma di apprendimento, ti raccomandiamo di familiarizzare con questi strumenti.
+
+Se vuoi aiutarci a migliorare il codice sorgente...
+
+**Puoi anche usare Gitpod, una piattaforma gratuita che avvia un ambiente di sviluppo pronto per l'uso con freeCodeCamp nel tuo browser.**
+
+[](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
+
+Oppure puoi...
+
+**[eseguire freeCodeCamp localmente](how-to-setup-freecodecamp-locally.md) nella tua macchina.**
diff --git a/docs/i18n/italian/moderator-handbook.md b/docs/i18n/italian/moderator-handbook.md
new file mode 100644
index 0000000000..c5ed7454a9
--- /dev/null
+++ b/docs/i18n/italian/moderator-handbook.md
@@ -0,0 +1,540 @@
+# Il manuale ufficiale del moderatore di freeCodeCamp
+
+Questo manuale ti aiuterà a moderare diversi luoghi nella nostra comunità. Questo comprende le conversazioni e le interazioni nelle issue e nei thread delle pull request su GitHub, nel forum della community, nelle chat room e sulle altre comunità ufficiali che ospitiamo.
+
+> [!NOTE] Tutti i moderatori di freeCodeCamp sono moderatori di tutta la comunità. Cioè confidiamo che tu sorvegli uno di questi posti.
+
+Puoi fare da moderatore su qualunque piattorma ti interessi di più. Alcuni moderatori aiutano solo su GitHub, mentre altri aiutano solo sul forum. Alcuni sono attivi ovunque.
+
+L'idea di fondo è che vogliamo che ti diverta ad essere un moderatore, e che tu investa il tuo poco tempo in luoghi che sono di tuo interesse.
+
+> "Da grandi poteri derivano grandi responsabilità." - Zio Ben
+
+Come moderatore, il carattere è più importante dell'abilità tecnica.
+
+Ascolta. Sii Utile. Non abusare del tuo potere.
+
+freeCodeCamp è una comunità inclusiva ed è necessario lasciarla così.
+
+Abbiamo un unico codice di comportamento che governa la nostra intera comunità. Meno sono le regole, più facile sarà ricordarle. Puoi leggere queste regole e impegnarti a ricordarle [qui](https://code-of-conduct.freecodecamp.org).
+
+> [!NOTE] Come moderatore, ti aggiungeremo a uno o più team su GitHub, ai forum della community & ai server delle chat. Se ti manca l'accesso a una piattaforma che vorresti moderare, per favore [contatta un membro dello staff](/FAQ?id=additional-assistance).
+
+## Moderare GitHub
+
+I moderatori hanno due responsabilità principali su GitHub:
+
+1. Fare lo smistamento e rispondere alle issues
+2. Verificare e fare il merge delle pull request (cioè controllo qualità).
+
+### Moderare gli issue di Github
+
+Usiamo il repository principale [`freeCodeCamp/freeCodeCamp`](https://github.com/freeCodeCamp/freeCodeCamp/issues) per tenere traccia delle issue su tutti i nostri repository. Riceviamo nuove issue ogni giorno e di tutte deve essere fatto lo smistamento, assegnata un'etichetta e data attenzione. Questo è anche un ottimo posto per iniziare ad aiutare contribuendo al codice open source.
+
+#### Smistamento delle issue
+
+[Lo smistamento (triage)](https://en.wikipedia.org/wiki/Triage) è un processo in cui si decide con quale priorità rivolgere l'attenzione ad ogni nuovo problema riportato. Abbiamo una lunga lista di etichette che usiamo per contrassegnare priorità, categoria, status e scopo di ogni issue.
+
+Puoi aiutarci ad organizzare e fare lo smistamento delle issue riportate applicando etichette da [questa lista](https://github.com/freeCodeCamp/freeCodeCamp/labels). Solitamente, è disponibile una descrizione accanto all'etichetta che ne spiega il significato.
+
+Per favore, fai particolare attenzione alle etichette `"help wanted"` e `"first timers only"`. Queste devono essere aggiunte ai thread che pensi possano essere aperti a potenziali contributori per creare una pull request.
+
+Un'etichetta `"first timer only"` dovrebbe essere applicata per problemi banali (es. un refuso) e dovrebbe includere informazioni addizionali. Puoi usare questo [modello di risposta](/moderator-handbook?id=first-timer-only-issues) per lo smistamento.
+
+#### Chiudere issues e pull request stantii, obsoleti e inattivi
+
+- Le issue e le pull request stantie sono quelli che non hanno visto alcuna attività dall'autore per 21 giorni (3 settimane dall'ultima attività), ma solo dopo che un moderatore ha richiesto più informazioni/modifiche.
+
+- L'attività è definita come: Commenti che richiedono un aggiornamento sulla PR e sullo smistamento come l'etichetta `status: update needed` etc.
+
+- Se il contributore chiede ulteriore assistenza o anche del tempo, quanto sopra può essere rilassato e rivisitato dopo che è stata data una risposta. In ogni caso, i moderatori dovrebbero usare il loro buon senso per prendere una decisione sullo status in sospeso della PR.
+
+> [!TIP] Ti consigliamo di usare questa lista di [modelli di risposta](https://contribute.freecodecamp.org/#/moderator-handbook?id=reply-templates) mentre smisti le issue.
+
+### Moderare le pull request
+
+Le pull request (PR) sono il modo in cui i contributori sottopongono cambiamenti al repository di freeCodeCamp. Dobbiamo eseguire il Controllo Qualità sulle pull request prima di decidere se fare il merge, richiedere delle modifiche o chiuderle.
+
+#### Tipi di Pull Request
+
+1. **Modifiche alle istruzioni delle sfide**
+
+ Queste sono le modifiche ai testi delle sfide - la descrizione, le Istruzioni o il testo dei test.
+
+ Puoi anche farne la revisione direttamente su GitHub e decidere se fare il merge. Dobbiamo fare un po' attenzione su questo perché milioni di persone incontreranno questo testo lavorando sul curriculum di freeCodeCamp. La pull request rende il testo più chiaro senza allungarlo troppo? Le modifiche sono rilevanti e non troppo pedanti? Ricorda che il nostro obbiettivo è che le sfide siano più chiare e più corte possibile. Non sono il luogo per dettagli incomprensibili. I contributori possono provare ad aggiungere link e risorse alle sfide.
+
+ Puoi chiudere le pull request non valide e rispondervi con questi [modelli di risposta](https://contribute.freecodecamp.org/#/moderator-handbook?id=closing-invalid-pull-requests).
+
+ Se la modifica va bene, assicurati di lasciare un'approvazione con un commento "LGTM". Una volta che una pull request riceve almeno due approvazioni (inclusa la tua) dai moderatori o dal dev-team, puoi procedere e farne il merge.
+
+2. **Modifiche al codice delle sfide**
+
+ Queste sono modifiche al codice in una sfida - il seed della sfida, la soluzione della sfida e le stringhe di test.
+
+ Queste pull request devono essere scaricate (pull) da GitHub e testate nel tuo computer locale o su Gitpod per assicurarti che i test della sfida possono essere superati con la soluzione corrente, e il nuovo codice non introduca errori.
+
+ Alcuni contributori potrebbero provare ad aggiungere test addizionali per coprire casi limite pedanti. Dobbiamo fare attenzione a non rendere le sfide troppo complicate. Queste sfide e i loro test dovrebbero essere più semplici e intuitivi possibile. Ad eccezione delle sfide sugli algoritmi e della sezione di preparazione al colloquio di lavoro, gli studenti dovrebbero essere in grado di risolvere ogni sfida entro due minuti.
+
+ Puoi chiudere le pull request non valide e rispondervi con questi [modelli di risposta](https://contribute.freecodecamp.org/#/moderator-handbook?id=closing-invalid-pull-requests).
+
+ Se la modifica va bene, assicurati di lasciare un'approvazione con un commento "LGTM". Una volta che una pull request ha ricevuto almeno due approvazioni (inclusa la tua) dai moderatori o dal dev-team, puoi procedere e farne il merge.
+
+3. **Modifiche alla piattaforma**
+
+ Queste modifiche al codice cambiano la funzionalità della piattaforma freeCodeCamp stessa.
+
+ A volte i contributori cercano di apportare cambiamenti senza troppe spiegazioni, ma per le modifiche al codice, dobbiamo essere sicuri che ci sia un'autentica necessità di cambiamento. Queste pull request dovrebbero fare riferimento a un'issue esistente su GitHub dove vengono discusse le ragioni della modifica. Quindi puoi aprire la pull request sul tuo computer e testarla localmente.
+
+ Dopo averlo fatto, se le modifiche funzionano, non farne ancora il merge. Puoi commentare le pull request scrivendo "LGTM", quindi menzionando **"@freeCodeCamp/dev-team"** in modo che possano dare un'occhiata finale.
+
+4. **PR automatizzate (Dependabot)**
+
+ Alcune PR sono aggiornamenti di dipendenze automatizzati fatti attraverso un'integrazione. Non dovresti fare il merge o approvare queste PR. Uno dei membri del dev-team si prenderà carico di rivedere queste PR automatizzate e di farne il merge.
+
+#### Come rivedere, fare il merge o chiudere le pull request
+
+##### Assegna a te stesso una pull request:
+
+Prima di tutto, quando scegli una pull request da rivedere, dovresti assegnarla a te stesso. Puoi farlo facendo clic sul collegamento "assign yourself" sotto la parte "assegnatari" nella colonna di destra dell'interfaccia di GitHub.
+
+A seconda del tipo di pull request, segui le regole corrispondenti elencate in precedenza.
+
+##### Assicurati che i controlli di CI (Continuous Integration) siano superati:
+
+Prima di fare il merge di qualsiasi pull request, assicurati che GitHub contrassegni come superati tutti i controlli da fare (segni di spunta verdi) sulle pull request. Se noti che uno dei controlli non va a buon fine, indaga e chiarisci la causa principale. La modifica che viene apportata blocca i nostri test? Il sito verrà creato correttamente se la PR sarà unita? Questi controlli sono fondamentali per la stabilità della piattaforma.
+
+> [!WARNING] L'unione di una PR che non supera i controlli CI/CD può causare difficoltà a tutte le parti interessate, incluso il team di sviluppo e i contributori.
+
+##### Gestire i conflitti di merge:
+
+A volte ci sarà un conflitto di merge.
+
+Ciò significa che un'altra pull request ha apportato una modifica alla stessa parte di quello stesso file. GitHub ha uno strumento per affrontare questi conflitti di unione direttamente su GitHub. Puoi provare ad affrontare questi conflitti. Usa il tuo miglior giudizio.
+
+Le modifiche della pull request saranno in alto e le modifiche del ramo Master saranno in basso. A volte ci saranno informazioni ridondanti che possono essere cancellate. Prima di finire, assicura di cancellare i simboli `<<<<<<`, `======`, e `>>>>>>` che Git aggiunge per indicare le aree in conflitto.
+
+Se non sei sicuro, chiedi assistenza a uno degli altri moderatori o al team di sviluppo.
+
+##### Fare il merge di una pull request valida:
+
+Se la pull request sembra pronta per il merge (e non richiede ulteriori approvazioni, ricorda che ne servono almeno due), puoi procedere e unirla. Assicurati di utilizzare l'opzione predefinita **"Squash and Merge"**. Questo ridurrà tutti i commit della pull request a un singolo commit, rendendo la cronologia di Git molto più facile da leggere.
+
+> Dovresti quindi commentare la pull request, ringraziando il contributore in modo personale.
+
+Se l'autore della pull request è un "contributore per la prima volta" dovresti anche congratularti con lui per la sua prima pull request unita al repository. Puoi guardare nell'angolo in alto a destra nel corpo della PR per determinare chi ha contribuito per la prima volta. Mostrerà `First-time contributor` come nella figura:
+
+
+
+ Badge first time contributor sulle pull request (screenshot)
+
+
+
+
+
+
+Se la pull request non sembra pronta per il merge, puoi rispondere educatamente dicendo all'autore cosa dovrebbe fare per prepararla. Si spera che rispondano e che la loro pull request sia più vicina ad essere pronta.
+
+Se hai bisogno di una seconda opinione su una pull request, vai avanti e lascia i tuoi commenti sulla pull request, quindi aggiungi l'etichetta "discussing".
+
+##### Chiudere una pull request invalida:
+
+Spesso una pull request avrà richiesto uno sforzo minimo. Puoi capirlo immediatamente quando il contributore non si è preoccupato di selezionare le caselle di spunta nel template per le Pull Request o ha utilizzato un titolo generico per la Pull Request come "made changes" o "Update index.md".
+
+Ci sono anche situazioni in cui il contributore sta cercando di aggiungere un collegamento al proprio sito Web, includere una libreria che ha creato o apportare una modifica frivola che non aiuta nessuno tranne se stesso.
+
+Puoi chiudere le pull request non valide e rispondere con questi [modelli di risposta](https://contribute.freecodecamp.org/#/moderator-handbook?id=closing-invalid-pull-requests).
+
+#### Altre linee guida per i Moderatori su GitHub
+
+Anche se avrai accesso in scrittura al repository di freeCodeCamp, **non dovresti mai inviare il codice direttamente ai repository di freeCodeCamp**. Tutto il codice dovrebbe entrare nella codebase di freeCodeCamp sotto forma di una pull request da un fork del repository.
+
+Inoltre, non dovresti mai accettare le tue proprie PR. Esse dovranno essere riviste da un altro moderatore, proprio come qualsiasi altra PR.
+
+Se noti che qualcuno infrange il [codice di condotta](https://code-of-conduct.freecodecamp.org) sulle issue di GitHub o apre pull request con contenuto o codice dannoso, invia un'email a `support[at]freecodecamp.org` con un link alla pull request incriminata, e possiamo considerare di bandirli completamente dall'organizzazione GitHub di freeCodeCamp.
+
+## Moderazione del Forum
+
+Come Moderatore, aiuterai a mantenere la nostra comunità un posto piacevole in cui tutti possano imparare e ricevere aiuto. Avrai a che fare con post segnalati e maneggerai spam, argomenti fuori tema, e altre conversazioni inappropriate.
+
+Nota che una volta che sarai un moderatore sul forum, inizierai a vedere suggerimenti ai moderatori in blu sui membri del forum, come "questa è la prima volta che [person] ha creato un post - diamogli il benvenuto nella community!" o "[person] non ha creato post per molto tempo - diamo loro il bentornato."
+
+![Un testo blu che dice "this is the first time [person] has posted - let's welcome them to the community!](https://i.imgur.com/mPmVgzK.png)
+
+Queste per te sono opportunità di dare loro il benvenuto e farli sentire ancora più speciali. Non sai mai quale persona marginalmente coinvolta possa diventare il nostro prossimo super aiutante, supportando molte altre persone nel loro percorso di programmazione. Anche la più piccola gentilezza può innescare una cascata di buone azioni.
+
+### Eliminazione dei post del forum
+
+I moderatori del forum possono cancellare i post degli utenti. Dovresti farlo solo nei seguenti casi:
+
+1. Qualcuno ha postato immagini pornografiche o graficamente violente.
+2. Qualcuno ha postato un link o del codice di natura malevola e che potrebbe danneggiare altri camper che ci cliccano sopra.
+3. Qualcuno ha inondato un thread con un sacco di spam.
+
+### Affrontare lo spam
+
+Al primo post di spam di un utente, mandagli un messaggio spiegando il problema e rimuovi il link o il post come appropriato. Lascia una nota sul profilo dell'utente spiegando le azioni che hai intrapreso. Se il problema persiste, allora impedisci tranquillamente all'utente di postare (usando l'opzione silenzia sul pannello Amministratore Utente). Manda all'utente un avvertimento con il Codice di Condotta. Spunta la casella nel messaggio privato che indica che il tuo messaggio è un "ammonimento formale."
+
+You can ask questions and report incidents in the [staff forum section](https://forum.freecodecamp.com/c/staff).
+
+### Affrontare conversazioni off-topic
+
+Post o argomenti che sembrano essere nel posto sbagliato possono essere ri-categorizzati o rinominati in qualunque modo sia appropriato.
+
+In circostanze eccezionali, può essere appropriato per un moderatore dividere una discussione in più thread.
+
+Di nuovo, se hai problemi o domande, fai un post con le tue azioni nella categoria Staff e tagga un altro moderatore se vuoi che riveda le tue azioni di moderazione.
+
+### Utenti Minorenni
+
+I nostri [Termini di servizio](https://www.freecodecamp.org/terms) richiedono che gli utenti di freeCodeCamp abbiano almeno 13 anni. Se un utente rivela di avere meno di 13 anni, mandagli il messaggio sottostante e cancella il suo account (se la cancellazione non è disponibile, sospendere l'account è sufficiente).
+
+**Manda anche un'email a `support[at]freecodecamp.org` per eliminare l'account dell'utente.**
+
+```markdown
+OGGETTO: Agli utenti sotto i 13 anni non è permesso usare il forum secondo i Termini di Servizio
+
+Ci è stato segnalato che hai meno di 13 anni.
+ Secondo i [termini di servizio di freeCodeCamp](https://www.freecodecamp.org/news/terms-of-service), devi avere almeno 13 anni per utilizzare il sito o il forum. Elimineremo sia il tuo account freeCodeCamp che il tuo account del forum. Questa restrizione ci mantiene in conformità con le leggi degli Stati Uniti.
+
+Per favore, iscriviti nuovamente una volta compiuti 13 anni di età.
+
+Grazie per la comprensione.
+```
+
+## Moderazione di Facebook
+
+Se vedi qualcosa che sembra violare il nostro [Codice di Condotta](https://code-of-conduct.freecodecamp.org/), dovresti eliminarlo immediatamente.
+
+Alcune volte le persone posteranno cose che credono essere divertenti. Non realizzano che ciò che hanno detto o condiviso potrebbe essere interpretato come offensivo. Dovresti eliminare quei post, ma non necessariamente bannare la persona. Si spera che l'utente capirà che ciò che ha postato era inappropriato perché il post è stato cancellato.
+
+A meno che non sia un'offesa oltraggiosa che non può essere ragionevolmente attribuita a una differenza culturale o a un fraintendimento della lingua inglese. In tal caso, dovresti fortemente considerare di bloccare il membro dal gruppo Facebook.
+
+## Moderare le chat
+
+Ecco come i moderatori affrontano le violazioni al [Codice di Condotta](https://code-of-conduct.freecodecamp.org/) sulla nostra chat:
+
+1. **Assicurati che l'utente intendesse violare il Codice di Condotta.**
+
+ Non tutte le violazioni al CdC sono volute. Un nuovo camper potrebbe postare una grossa quantità di codice con l'intento di aiutare, inconsapevole che questo può essere considerato spam. In questi casi puoi chiedergli di incollare il codice tramite servizi come CodePen o Pastebin.
+
+2. **Se il camper viola chiaramente e intenzionalmente il Codice di Condotta, il moderatore procederà come segue:**
+
+ Silenzia o espelle dalla chat la persona incriminata. Per espellere o silenziare qualcuno, clicca con il tasto sinistro sulla sua immagine del profilo, seleziona i tre puntini e seleziona "Rimuovi dalla stanza" o "Silenzia l'utente" per impedirgli di mandare altri messaggi. Dopodiché, riporta un breve riepilogo dell'evento sul canale #mod-log. Ecco un esempio di come potrebbe apparire un tale riepilogo:
+
+ ```
+ Kicked: _@username_
+ Reason(s): _Spamming, trolling_
+ Evidence: _One or more links to the offending message(s)_
+ ```
+
+3. **Creare una discussione privata**
+
+ Potrebbero esserci situazioni in cui hai bisogno di rivolgerti a un camper in privato. Questo non dovrebbe essere fatto tramite messaggi diretti, che possono portare a situazioni in cui tu sostieni una cosa e il camper ne sostiene un'altra. Invece, usa la funzione del bot per creare una discussione privata:
+
+ - Chiama il comando `!fCC private username`, dove `username` è lo username del camper.
+ - Il bot creerà un nuovo canale, e vi aggiungerà il camper menzionato e tutti i moderatori con il ruolo `Your Friendly Moderator`. Anche se vengono aggiunti al canale tutti i moderatori per trasparenza, il moderatore che ha chiamato il comando dovrebbe essere l'unico ad interagire con il camper a meno che non abbia bisogno di assistenza.
+ - Quando la conversazione è completa, chiama il comando `!fCC close` _nel canale privato_ per fare in modo che il bot chiuda ed elimini quel canale.
+
+4. **Cancellare i messaggi**
+
+ I moderatori possono cancellare i messaggi sulla chat. Si dovrebbe esercitare questa facoltà solo in quattro specifiche circostanze:
+
+ - Qualcuno ha postato immagini pornografiche o graficamente violente.
+
+ - Qualcuno ha postato un link o del codice di natura malevola e che potrebbe danneggiare altri camper che ci cliccano sopra.
+
+ - Qualcuno ha inondato la chat con un sacco di messaggi di spam al punto tale (solitamente utilizzando bot) di rendere la chat completamente inutilizzabile.
+
+ - Qualcuno ha postato una pubblicità e/o un messaggio/immagine di autopromozione (social media).
+
+ In tutte le altre situazioni - anche le situazioni in cui il codice di condotta è stato violato - i moderatori non dovrebbero cancellare i messaggi poiché sono importanti testimonianze storiche. Quando cancelli un messaggio, assicurati di averne fatto prima lo screenshot! Lo screenshot può essere riportato sul canale @mod-log.
+
+ > [!NOTE] Se il messaggio contiene materiale di cui sarebbe illegale fare lo lo screenshot, copia il link al messaggio - fornisci quel link a @raisedadead per inoltrarlo al team di Affidabilità e Sicurezza di Discord.
+
+5. **Non usare @all o @here**
+
+ Non usare @all o @here in nessun caso! Ogni singola persona nella chat riceverà una notifica. In alcuni casi, decine di migliaia di persone.
+
+ Invece, se vuoi che le persone vedano un annuncio, puoi fissarlo in cima al canale per permettere a tutti di vederlo.
+
+6. **Non minacciare di prendere provvedimenti**
+
+ Se un camper rompe il Codice di Condotta, non minacciarlo di prendere provvedimenti da moderatore, e non ammonirlo mai in pubblico. Invece, parlagli privatamente usando il comando `private` del bot. Nessun altro all'interno della chat ha bisogno di sapere che hai bannato/sospeso una persona. Se una violazione era chiaramente involontaria e non richiede una sospensione o una conversazione privata, rendi il camper consapevole delle sue azioni senza farlo sembrare un ammonimento. Ad esempio:
+
+ - Un camper posta un muro di testo per chiedere aiuto:
+
+ Moderatore: @username, Per favore usa CodePen o Pastebin quando riporti grandi quantità di codice.
+
+ - O, se devi proprio spiegare il perché:
+
+ Moderatore: @username, per favore usa CodePen o Pastebin quando riporti grandi quantità di codice, perché disturba la chat per tutti e può essere considerato spam secondo il Codice di Condotta.
+
+ - Per violazioni lievi e non intenzionali del codice di condotta:
+
+ Moderatore: Questo è un promemoria amichevole che invita tutti a seguire il codice di condotta: https://code-of-conduct.freecodecamp.org/
+
+7. **Non vantarti di essere un moderatore**
+
+ Non vederti come al di sopra della comunità. Tu sei la comunità. E la community si è affidata a te per proteggere qualcosa di raro che tutti condividiamo: un luogo _accogliente_ per i nuovi sviluppatori.
+
+ Se ti vanti di essere un moderatore, le persone potrebbero sentirsi a disagio intorno a te, nello stesso modo in cui si sentono a disagio accanto ad un agente di polizia, anche quando non hanno fatto niente di male. Questa è semplicemente la natura umana.
+
+8. **Non contraddire gli altri moderatori**
+
+ Se sei in disaccordo con l'azione di un moderatore, parla con loro in privato o faglielo presente nel canale #mod-chat. Non scavalcare mai l'azione di un moderatore e non contraddire mai gli altri moderatori pubblicamente. Invece, discuti a mente fredda su `#mod-chat` e convinci il moderatore che egli stesso dovrebbe annullare il ban o cambiare il proprio punto di vista.
+
+ Ricorda: siamo tutti nella stessa squadra. Vogliamo dare dignità al ruolo dei moderatori e presentare un fronte unito.
+
+9. **Parla con gli altri moderatori**
+
+ Abbiamo una stanza solo per i moderatori. Usala! Se ti senti a disagio nel gestire una determinata situazione, chiedi aiuto ad altri moderatori. Se pensi che qualcosa dovrebbe essere discusso, fallo. Fai parte di una squadra, e noi apprezziamo il contributo di ogni membro! Anche quando sei completamente in disaccordo con qualsiasi cosa in queste linee guida o nel Codice di Condotta!
+
+10. **Inattività temporanea**
+
+ `Temporaneamente inattivo` Se non sarai attivo come Moderatore per un po' a causa di vacanze, malattia o qualsiasi altro motivo, assicurati di farlo sapere agli altri nel canale #mod-chat. In questo modo sapremo se possiamo contare sul fatto che sei regolarmente attivo sul server oppure no.
+
+## Come diventare un moderatore
+
+Supponi di stare aiutando le persone con costanza nel tempo. In quel caso, il nostro Team dei Moderatori se ne accorgerà e uno di loro ti suggerirà come possibile moderatore al [nostro staff](https://forum.freecodecamp.org/g/Team). Per diventare moderatore non ci sono scorciatoie.
+
+Se verrai approvato, ti aggiungeremo al nostro Team dei Moderatori su [GitHub](https://github.com/orgs/freeCodeCamp/teams/moderators), sul [forum](https://forum.freecodecamp.org/g/moderators) e sulla chat.
+
+> [!NOTE] Per GitHub: Dopo essere stato accettato come moderatore, riceverai l'invito a una repository Github. Dovrai andare all'[invito all'Organizzazione GitHub di freeCodeCamp](https://github.com/orgs/freeCodeCamp/invitation) per essere in grado di accettare l'invito.
+>
+> Questo è necessario per consentirci di darti i permessi di scrittura su alcuni dei nostri repository.
+
+## Come congediamo i moderatori inattivi
+
+Per favore ricorda che rimuoviamo frequentemente i moderatori che riteniamo essere inattivi. Quando lo facciamo, inviamo il seguente messaggio:
+
+```markdown
+This is a standard message notifying you that, since you don't seem to have been an active moderator recently, we're removing you from our Moderator team. We deeply appreciate your help in the past.
+
+If you think we did this in error, or once you're ready to come back and contribute more, just reply to this message letting me know.
+```
+
+## Come funzionano le stanze dei contributori
+
+Chiunque è il benvenuto nella [stanza dei contributori sul nostro server di chat](https://chat.freecodecamp.org/channel/contributors). È la chat room designata per i moderatori e per i camper che contribuiscono alla nostra comunità in altri modi, anche attraverso i gruppi di studio.
+
+Diamo per assodato che i contributori leggano qualunque messaggio in cui siano nominati direttamente con `@username`. Tutto il resto è opzionale, ma sentiti libero di leggere qualunque cosa venga postata da chiunque, e interagire.
+
+## Affrontare i sollecitatori
+
+Potresti essere avvicinato da organizzazioni che vogliono collaborare o diventare un co-brand di freeCodeCamp in qualche modo. Una volta che ti sei reso conto che questo è ciò che vogliono, **smetti di parlare con loro** e dì loro di mandare una email a `team[at]freecodecamp.org`.
+
+Riceviamo proposte del genere continuamente e lo staff è nella posizione migliore per giudicare se valga la pena che la comunità intraprenda quelle relazioni (cosa che succede raramente).
+
+## Affrontare richieste sulla salute (mentale)
+
+Potresti incontrare situazioni in cui gli utenti ricercano consigli medici o stanno affrontando problemi di salute mentale e cercano supporto.
+
+Per una questioni di policy, dovesti evitare di parlare di questi temi privatamente. Se la situazione dovesse riflettersi su freeCodeCamp, vogliamo che le conversazioni siano registrate. Chiarifica che non siamo medici professionisti ed incoraggia l'utente a cercare aiuto professionale.
+
+Per quanto a volte sia difficile, evita di dare suggerimenti o consigli diversi dall'indirizzare l'utente verso l'aiuto professionale!
+
+Se questo accade sul server delle chat: Crea un canale privato per l'utente e il team dei moderatori. Questo può essere fatto con il comando `private` del bot.
+
+- All'utente viene garantita privacy
+- La chat pubblica non è più interrotta
+- Altri membri del team possono contribuire, nel caso tu sia a disagio nell'affrontare la situazione da solo
+
+URL utili:
+
+http://www.suicide.org/international-suicide-hotlines.html
+
+## Una nota sulla libertà di parola
+
+A volte le persone difenderanno qualcosa di offensivo o aggressivo che hanno detto, come "libertà di parola."
+
+Questo fumetto di XKCD riassume perfettamente il pensiero di molte comunità a proposito della libertà di parola. Quindi se qualcuno difende qualcosa nel nome della "libertà di parola", sentiti libero di mandarglielo.
+
+
+
+Grazie per aver letto e grazie per l'aiuto alla comunità degli sviluppatori!
+
+## Modelli di risposta
+
+Queste sono alcune delle risposte standard che potresti voler usare mentre verifichi le pull request e fai il triage delle issues e delle pull request.
+
+> Puoi crearti le tue con la feature integrata di GitHub [**risposte salvate**](https://github.com/settings/replies/) oppure utilizzare quelle qui sotto.
+
+### Ringraziamenti
+
+```markdown
+Thank you for your contribution to the page! We are happy to accept these changes and look forward to future contributions. 🎉.
+ 🎉
+```
+
+### Ringraziamenti e congratulazioni
+
+> Per ringraziare ed incoraggiare chi contribuisce per la prima volta.
+
+```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. 📝
+```
+
+### Errore di compilazione
+
+```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. ✅
+```
+
+### Sincronizzare le fork
+
+> Quando la PR non è allineata con il ramo `main`.
+
+````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
+````
+
+Se stai usando una GUI, puoi semplicemente cercare il comando `Add a new remote...` e usare il link `git://github.com/freeCodeCamp/freeCodeCamp.git` visto sopra.
+
+Una volta che avrai sincronizzato il fork e superato la build, saremo in grado di rivedere la tua PR e farne il merge. 😊
+
+---
+
+Sentiti libero di fare riferimento all'articolo [Sincronizzare un fork](https://help.github.com/articles/syncing-a-fork/) su GitHub per ulteriori informazioni su come mantenere aggiornato il fork con il repository di upstream. 🔄
+````
+
+### Conflitti in fase di merge
+
+> Quando una PR ha dei conflitti di fusione che devono essere risolti.¹
+
+```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. 📝
+````
+
+¹ Se una persona che contribuisce per la prima volta ha un conflitto di merge, i manutentori risolveranno il conflitto per lui.
+
+### Duplicati
+
+> Quando la pull request è una ripetizione o un duplicato.
+
+```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).
+```
+
+### Chiudere le pull request non valide
+
+> Quando una pull request non è valida.
+
+```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.
+```
+
+> Quando una PR aggiunge link a risorse esterne.
+
+```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.
+```
+
+### Chiudere le issue non valide
+
+> Quando un issue è inerente al codice del camper.
+
+```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.
+```
+
+> Quando un'issue è il duplicato di un'issue precedente
+
+```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.
+```
+
+> Quando un problema viene risolto durante lo 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.
+```
+
+### Issue etichettate come first timers only
+
+> Quando un'issue è ritenuta idonea per chi contribuisce al codice per la prima volta.
+
+```markdown
+Thanks for opening this issue.
+
+This looks something that can be fixed by "first time" code contributors to this repository. Here are the files that you should be looking at to work on a fix:
+
+List of files:
+
+1. ...
+2. ...
+3. ...
+
+Please make sure you read [our guidelines for contributing](https://contribute.freecodecamp.org/#/), we prioritize contributors following the instructions in our guides. Join us in [our chat room](https://chat.freecodecamp.org/channel/contributors) or [the forum](https://forum.freecodecamp.org/c/contributors/3) if you need help contributing, our moderators will guide you through this.
+
+Sometimes we may get more than one pull requests. We typically accept the most quality contribution followed by the one that is made first.
+
+Happy contributing.
+```